Let's say that user selected item in a tree structure component and hits +. We want to enable her to move items in this structure and we wonder: is it more idiomatic to move the item downwards or upwards?

With arrow keys, the decision would be easier, but we want to use them for navigation, not movement.

  • Are you asking about adding items to the tree? Or just moving things around? – Wanda Oct 2 '17 at 9:13
  • 31
    Plus sign is usually used for expanding a tree. You seem to be using the plus sign in a different context. An image would help. – Adnan Khan Oct 2 '17 at 9:27
  • In a tree structure I would automatically assume 4 directions: up /down and to parent node/make subnode. If this is the case, I would assume + to move deeper into tree. – Gnudiff Oct 2 '17 at 11:34
  • Make a mockup and see what people do. I imagine they'll try it and if their object goes the wrong direction they'll use [-] to place it correctly. If they learn which is which right away, then BINGO! If they keep clicking the wrong button, then you have your answer. – Ken Mohnkern Oct 2 '17 at 12:58
  • 2
    Also, more abstractly: please note that there is no "downwards" in a tree structure, there is only "upwards." What you're asking only exists in the one direction and the closest thing to "downwards" that you might have is "depth-first-wards" where we linearize the tree into a list and then move downwards in it. – CR Drost Oct 2 '17 at 18:00
up vote 32 down vote accepted

The plus key is very arbitrary and does not map well with the intention of moving up/down. Also it is mostly used to expand the tree node (i.e. windows explorer).

I would suggest a different key combination for moving : ctrl + up/down arrow. So the arrow keys are used for navigating, but combined with the control key they move the object. This seems to be the most intuitive key combination.

  • 3
    Ctrl+arrow usually scrolls the view. Notepad++ uses Ctrl+Shift+arrow moving the current line, Visual Studio uses Alt+Arrow. – CodesInChaos Oct 2 '17 at 11:26
  • 1
    @CodesInChaos yes, Ctrl + Shift + arrow is probably makes the most sense – icc97 Oct 2 '17 at 14:53
  • Agreed. Plus only works for moving things with direct context, and that context almost always has incremental numbers tagged onto it. If there is a graph or a list with indexes, then people might be able to intuitively figure it out though. If that suits the intended audience however, is another story. – Ryan Oct 2 '17 at 16:40

The Windows TreeView control uses the '+' and '-' keys for expanding/collapsing the currently selected node by one level (it uses '*' for expanding the entire tree below the selected node). I suggest that using '+' or '-' for moving nodes would be confusing to people used to the Windows UI.

Oddly, however, I can't find a definitive (i.e. MS) reference to this behaviour any more.

Consider using a modifier key, e.g., Ctrl+Up or Ctrl+Down. You could use the Shift key, but that's usually reserved for selecting things, so using that could also be confusing.

  • And, perhaps, Ctrl-Left could be used to "promote" an entry up a level (assuming it makes sense to do so). Not so sure about Ctrl-Right to move down a level, as it wouldn't be obvious which "child node" to move it in to (or whether to create a new node of which it is the only child). – TripeHound Oct 2 '17 at 11:34

I suppose using mouse and drag'n'drop is not an option in your application, is it? If only keyboard input is allowed, then it might be tricky if you can't use up/down arrows (which would seem natural). I would say that the use of + and - signs depends on the sorting of the tree - is it sorted in increasing or decreasing order? If it's in increasing order, I would think that + button moves the element down. But that's only me and it would definitely be a good idea to test it on some users.

Anyways, I would definitely add some explanatory text above the tree structure explaining what + and - do.

By the way, when I look at my numeric keyboard, the - sign is above the + sign, so for me it would be natural to use - for going up and + for going down...

enter image description here

  • 1
    What about keyboards that don't have those keys there? Mine doesn't for example ;) – Wanda Oct 2 '17 at 10:21
  • That's why I'm saying it would be natural this way for me. But, as you've pointed out, this can depend on many variables - i.e., laptop vs. desktop computer, keyboard language.... That's why I think it's very difficult to say what is more natural... – Jaroslav M Oct 2 '17 at 11:32

It's often educational to see how other people do this. I see a few general trends.

Up and down arrows on every row. This is horrible and should in my opinion be avoided, since it handles multiple clicks very, very poorly indeed. However, as a drag-drop hint it could work:

OneSync (drag-drop hint):

OneSync (drag-drop hint)

ASP Snippets:

ASP Snippets

Sdevireddy (this one shows in an animated fashion why this is terrible UI: to move something up multiple rows, you have to click and reposition the mouse for each row to move up):

Sdevireddy


Then there's the arrows-to-the-side method:

Kuqin:

kuqin

Telerik:

Telerik


Then there's the way everyone and their dog does it: Internationalized "Move Up" and "Move Down" buttons. With words on. So people actually know what you mean.

Move Up

Move Up

Move Up

Move Up


Then there's plusses and minuses. I could find exactly zero examples of this in the wild, which is a good reason to wonder whether it's the right thing to do.

On the other hand, if it's a thing you MUST do, we can see something else from the above examples: button position matters.

If you have the '-' button above the '+' button, then '+' will be interpreted by the user as increasing the selected item's position number within the list; moving it down from position zero.

If you have the '+' button above the '-' button, then '+' will be interpreted as moving the selected item higher in the list; moving it up towards position zero.

Either of these is a valid way to do it. I'd personally go for plus-on-top, but the most important part is what position the buttons are in.

given than your primary cue is button position, you don't even need to have plus and minus. You can have a camel icon, and a banana icon. If you have camel above banana, appropriately vertically-centered to the right of the list, then "camel" will be guessed to raise the item up in the list. Users will just assume there's some reference they're missing.

  • None of those are tree structures, they're all just lists or tables. So you can't really display an up / down arrow in a tree structure. However your idea of mapping the + / - to the position in the list is a good one. They would have to display the position. You'd also probably start at position one rather than zero (that's only for array indexes). – icc97 Oct 2 '17 at 15:00
  • 2
    @icc97 True. Trees are lists, but you're right: there's an extra issue with user expectations in the action "move up". In a tree with two branches, each with two sub-branches (A(Aa, Ab), B(Ba, Bb)), what does it mean to move Bb "up"? Does it remain a child of B, and move before Ba? Or does it move up in the tree? If so, does it go between A and B, or after B? And if you move B "up", does it become a child of A below Ab, or does it move above A? If the former, does that still happen if A is collapsed? My intuition is a stepwise move visually up, just like a list: but that may not be desired. – Dewi Morgan Oct 2 '17 at 15:37

Plus/minus icons symbols can be associated with navigating or manipulating a tree structure.

Symbols used within tree structures to afford navigation often have 2 jobs:

  1. Convey the presence of child nodes
  2. Allow you to expand and inspect those nodes

In this context the user is consuming information. Reading only, not creating nor updating nor destroying any data model.

In most cases such symbols are prepended to parent items, which builds nicely on the mental model of bulleted lists.

Most of the time I see open/closed folder symbols, down/list-facing arrow symbols and of course plus/minus symbols used for this job.

I believe you are talking about a different job - manipulation of the taxonomy, specifically moving items around within the tree structure.

Again in CRUD terms, that is an update operation since the user is not only consuming some data model but potentially altering it. So the context is now different.

As such, the choice of symbol isn't the only design variable you have to work with to convey that distinction. I would argue it is probably a secondary to:

  1. Symbol location, relative to the list item
  2. Widget state ("read" vs "update" context)

In the nested read-only tree structures I see, the symbol's proximity is the same as an ordinary list bullet. That's how I know what I'm looking at. It's a nested list.

In looking at a tree which I can edit or manipulate, I would ask for some additional cue to convey the ability to move things around within that tree.

If I'm interpreting your comment correctly, I think you're saying that we're talking strictly about the context of a selected node. This is important state context that can make symbol meaning conditional, albeit in a very practical way.

There a million ways to accomplish that and rather than offer a prescriptive answer I'd encourage you to just focus on what you need the symbol to do/convey and in exactly what context of the local widgets. That will make the choice of symbol simpler.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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