I have a window showing a number of objects that can be individually hidden or recolored. Accordingly, in a sidebar each has a checkbox and a color swatch that launches a color picker when clicked:

example tree view

However, as shown, the objects also occupy a structure that resembles a (Unix) filesystem: the user has organized them into groups ("directories", but not nested), and each may have more than one name in the same or separate groups. No name or group is privileged or canonical. (The number of groups is almost always 5 or fewer, likely with no more than 25 entries each. Any one object probably has no more than 6 names in total.)

Thus the groups and the names of the objects form a tree that is important to the user, but adding the objects themselves (as "children" of their names) weakens the structure to that of a DAG. The rendering is of the objects, so it is meaningless for a single object's various names to have different colors or visibilities.

What controls can I present to the user that

  1. convey the hierarchy of groups and names,
  2. convey the connection among different names for the same object,
  3. display the colors in association with every name (to allow quick consultation without any gestures), and
  4. minimize confusion from synchronizing the properties "of the names"?

The example image shows one simple strategy: a in group bar and a and b in group foo are all the same object, while two other objects have just one name each. The layout certainly satisfies #1 and #3. However, #4 isn't good: clicking any of the three checkboxes for the shared object must update all three (and similarly for the colors). Moreover, this sameness is only reliably detectable by interacting with them (so #2 is not met); it might be mere coincidence that they have the same color and checkbox state, and the same name ("a", here) might or might not refer to different objects in different groups.

Note that no editing of the structure or names ever takes place; this interface controls drawing the objects and is not involved in creating, deleting, grouping, or naming them.

  • To be honest, there should be a better way to represent visually what you ask as a problem other than make people read and understand 20 lines of text. Otherwise probably my bad but not get a point even I read many times. Commented Aug 31, 2018 at 16:53
  • @ErhanYaşar: If I knew the final visual representation, there wouldn’t be a question. The “base” interface without accounting for sharing is a tree view with a checkbox and color swatch on every leaf, as I said; I would think visualizing that is easy enough for UX people. Commented Sep 1, 2018 at 15:34
  • 1
    I didn’t mean viusalizing the answer of your question, rather you might prefer to visualizing the problemmatic parts to be easily understandable. This way it can not be understood I suppose and there can not be an easy answer if you don’t try to explain “the real problem”. It’s like going to doctor and saying I have a pain without not showing where it is. Commented Sep 2, 2018 at 8:55
  • @ErhanYaşar: I added an example image illustrating one (trivial) approach. Does that help? Commented Sep 4, 2018 at 6:38
  • Can you confirm that each "instance" of the same object can have a different name and a different color, and that the same object can have several "instances" in the same group? What makes all of these instances the same object?
    – jcaron
    Commented Sep 4, 2018 at 12:24

2 Answers 2


Not really convinced, but you could try a table layout:

enter image description here

Each row is for one underlying object. Each column is a group.

Of course, this means that as the number of groups gets larger, you need more width.


I'm not sure that a tree is the right visual structure here. You're right that a tree implies a DAG, and what you have here is a collection of objects with attached tagging data.

I don't have a concrete solution to show you, since there are a whole family of solutions to the problem "How do I show tags against a set of unique objects", and I don't know which one best fits in with the rest of your UI.

I'd perhaps go with listing the objects as their own ui element, probably as a product card, with an inset colour swatch that opens a colour picker. You could then show each name and directory as a separate "tag" along the bottom of the card.

I'd also probably extend the ui to include a "tag page", so the user can click on a tag and see all the objects in it, each as their own product card. That way they can navigate the collection either by name or by directory, but will initially see a collection of unique objects as product cards.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.