Its not obvious what the "Tags" (under title in the details panel) do

[tomwilkie]

Especially if you have a weirdly named host (such as 'default', which is what most docker-machine users seems to be ending up with). Perhaps an icon or short piece of text (ie host:default, container:foo, process:bar) would help?

[tomwilkie]

Node shapes!

[tomwilkie]

Suggestion is to put little node shapes next to the tags to make it clear what they refer to.

[pidster]

I don't think the header is necessarily the best place for this information.
The design should communicate the meaning of it more clearly, just adding icons won't do that.

[rade]

@davkal @foot suggestions?

[davkal]

I'd keep it a comma-separated list for information density. If that field is unclear, a label could help. Something like

CONTEXT: default, image123123

or

RELATED: default, image123123

I think icons could add information scent. I'd like to try it before ruling it out.

[rade]

Surely there must be a more interesting (and functional) way to show this information than a comma-separated list in the details panel. Isn't the information essentially hierarchical? Then why can't we visualise it as a hierarchy?

[davkal]

It's a network, not a hierarchy. A container has links to images and hosts. In the code we call them relatives. So we could render a network, but that needs a lot more space than a comma-sep list. I posit that it would not be proportionate to its importance.

[rade]

I posit that it would not be proportionate to its importance.

I posit that as it stands most people cannot figure out what information is being conveyed there.

[davkal]

I posit that as it stands most people cannot figure out what information is being conveyed there.

Hence my proposed changes. I just cautioned for a measured response, and not a giant tag cloud.

[davkal]

What this issue is missing, is that when you hover over the link default it will show you a tooltip "View in hosts: default". Progressive reveal.
That label needs changing though, since we're not immediately go to that topo.

[davkal]

I don't think the header is necessarily the best place for this information.

The idea behind placing it there was that of breadcrumbs. The node title is colocated with its relatives for context.
In a previous discussion we concluded that putting it anywhere else makes even less sense. Or can you see a good match somewhere else @pidster ?

[davkal]

The design should communicate the meaning of it more clearly, just adding icons won't do that.

If we didnt have the hover tooltip already, I'd support the prefix that @tomwilkie suggested. We can give that a try though. I'm just concerned with label overdose.

[pidster]

There's not enough space for the more familiar form of breadcrumb:

host > container > process

So why try to squeeze one into this space?

[pidster]

Some kind of tree fragment would probably communicate it better.

|_ hostname
    |_ container name**
        |_ process name

** You are here.

[foot]

I like the idea of making the data more structured a lot, showing the cross-topo relations is really powerful!

David and I iterated on a couple of designs for going down this road but to do it right its becoming a new feature in itself.
https://docs.google.com/presentation/d/105sX7499tGICoq1bC09xVfIuJBJ7Soi2L3wAgziglSk/edit#slide=id.g10c63b2e9d_1_105

Since then we've discussed more variations, perhaps inside the main white area too that needs a little more mocking.

To do it right would require a bit of time resources. I'm for doing that down the road but perhaps explore a simpler label option for now!

[davkal]

It's been boiled down to 2 issues: (1) Users dont know what those links are and (2) they can become unwieldy when a node has lots of relatives, e.g., a container image can be deployed on tens of hosts.

Proposal A: One line per relation, with an option to expand the list of relatives, a label clarifying the relation

HOSTS: default, 123.23.2.1
PODS: users-cb08840-dj03q,... +3 >
IMAGE: quay.io/weaveworks/user

with Pods expanded:

HOSTS: default, 123.23.2.1
PODS: users-cb08840-dj03q
    users-cb08840-dj0344,
    users-cb08840-dj23q,
    users-cb08840-dj0098 <
IMAGE: quay.io/weaveworks/user

this can be done w/o backend support, estimate 0.5 days

Proposal B: graphical tree, needs tree drawing implementation and backend support to clarify direction, estimate 4-6 days