Two issues regarding the use of arrows in the user interface

[fkohrt]

I have one more general suggestion (regarding ambiguous use of arrows) and one more specific suggestion (regarding ambiguous toggle states for "Filter by fields").

An entry in the classic Table of Contents looks like this:

A click on the arrow pointing rightwards will reveal the hierarchy below the entry:

Additionally, the arrow pointing rightwards is turned into an arrow pointing downwards. This indicates that the entry is in expanded state.

The Locator plugin behaves different in various ways. For once, it's not possible to reveal hierarchies of multiple entries at the same time. This is because a horizontal line divides an indicator of the path to the current entry from the hierarchy below that entry:

Clicking on the arrow beneath some entry will "open" that path and therefore move the entry name above the horizontal line. The area below the horizontal line now only contains the hierarchy below that entry:

This makes the Locator plugin more similar to browsing directories than to expanding an hierarchic tree. Yet, it uses the same arrows as the classic Table of Contents, which I found confusing at first. It might therefore be beneficial to not use arrows as the "buttons" that change the current location in the hierarchy.

Looking again at the image directly above (the one showing the Locator plugin), one will infer from the user experience of the classic Table of Contents that "Filter by fields" is already expanded because it uses an arrow pointing downwards. However, the opposite is true. The locator plugin uses a different arrow language. Clicking on the arrow beneath "Filter by fields" will reveal the real contents of this node:

Users will never discover this until explicit informed about this, because previous experience with classic Table of Contents contradicts this behaviour. I therefore suggest to use a different approach to show the toggle state of the "Filter by fields" functionality. It should not be mistaken for an already revealed entry of some kind.

To sum it up, I have identified two issues:

1. The classic Table of Contents expands a tree, while the Locator plugin behaves similar to a directory browser. Using the same symbol set (arrows) makes it hard to understand how the Locator plugin works.

2. The "Filter by fields" functionality uses a different arrow language than the classic Table of Contents. Both expand an entry, but an expanded arrow for "Filter by fields" is pointing upwards, while for the classic Table of Contents it would point downwards. Similar for the unexpanded state, where the arrow for "Filter by fields" is pointing downwards, while the classic Table of Contents would have an arrow pointing rightwards.

[bimlas]

@fkohrt,

Thank you very much for your comments! Because I designed the plugin the way it is clear to me, I don't see these kinds of bugs myself, even though many people don't understand the way the Locator works because of such little things, so I'm sure I can make the plugin clearer by fixing bugs like this.

This makes the Locator plugin more similar to browsing directories than to expanding an hierarchic tree.

Absoulutelly right! Based on this, I think the best solution is to use a directory icon instead of arrows to indicate the items that can be opened. In this case, "Filter by fields" could also use the usual arrow markings, as it would not conflict with the markings next to the elements.

There is a problem with this solution: If the direction of traverse is inverted, the arrow icon is currently inverted to make it clear in which direction we are moving in the hierarchy (see https://bimlas.gitlab.io/tw5-locator/#View%20items%20with%20different%20templates%2C%20mindmap%20features -> Invert direction). I can't mark this with the directory icon.

What do you think about this? Do you have another idea?

[fkohrt]

Based on this, I think the best solution is to use a directory icon instead of arrows to indicate the items that can be opened. In this case, "Filter by fields" could also use the usual arrow markings, as it would not conflict with the markings next to the elements.

Yeah, I agree!

There is a problem with this solution: If the direction of traverse is inverted, the arrow icon is currently inverted to make it clear in which direction we are moving in the hierarchy

Interesting, I didn't even know about this feature! (And I only now discovered the "Tree is based on field" setting, crazy!)

Some file explorers have icons for parent folders, such as the KDE Breeze icon set:

(see Breezeicons-places-22-folder-open.svg and Breezeicons-actions-22-go-parent-folder.svg in Wikimedia Commons)
A bunch of others are available at the Noun Project with search terms such as parent folder, folder arrow or folder up.
All these have the drawback that they might not fit perfectly to the native TW icon set, so at least the "regular directory icon" and the "inverse directory icon" should be from the same designer.

Something different: As I understand it, the inverted direction is useful for identifying the current "path" of some tiddler by first clicking on the "Browse hierarchy of tag" button in the tiddler toolbar (first image) and then selectively move up (second image):


I found it confusing at first that, while being deep down in the family tree, clicking on the "Browse hierarchy" button just adds the current tiddler to the part above the horizontal line, as if "P. F. Chang's Lemon Pepper Shrimp" were a descendant of "Josephine Ford". Because, before a user used the "Browse hierarchy" button, the part above the horizontal bar was always ordered strictly hierarchically, while that button can "break" this hierarchy. So maybe insert a dotted line (or something else) above the newly added entry (in this case above "P. F. Chang's Lemon Pepper Shrimp") so people know that there's no guaranteed relationship between those two.

[fkohrt]

Based on this, I think the best solution is to use a directory icon instead of arrows to indicate the items that can be opened.

But, rethinking this, maybe the directory metaphor fails altogether because (1) the icons should indicate behaviour (when clicking the button), not existing hierarchy (when seeing the icons in the part above the horizontal line) and (2) other relationships (such as which tiddler links to which) fit even less than tags to the hierarchic notion of directories.

So maybe outbound (for the regular direction) and inbound arrows (for the inverted direction) are more appropriate, e. g. the icon "outbound" rotated 90° and the icon "inbound" rotated -90°. Or maybe this icon combined with this icon...