User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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.
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).
Oct 2, 2017 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...
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):
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):
Then there's the arrows-to-the-side method:
Kuqin:
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.
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.
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:
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:
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.
