Where to place controls on a tree/list

Question

I have a chronological list of items. The user can operate on these items with three actions.

So each row has three actions (or buttons for example).

My dilemma is thus:

1. Having three buttons on every row seems a clumsy solution. Surely I shouldn't have to say the same thing twice.
2. I could remedy issue 1 by showing the actions only on hover, but then they are invisible when we don't hover over the item and as we all know hiding interface is bad.

What would you suggest?

Answer 1

Showing the actions only on hover is the way that 37Signals do it in many of their products, and so far I haven't seen any problems with it, other than it not being usable on touch devices. That is a big downside if your customers are likely to be using touch devices. With the prevalence of iPads, this is becoming a bigger concern.

Another possible method is to have an action bar, but only make the buttons active once an item has been selected. The advantage here is that the interface also allows interacting on multiple items at a time.

Although this is a touch example (iOS mail), the principle works just as well on PCs.

Answer 2

You can try having a clearly labelled “edit” mode, which will enable the buttons on each specific item. This might signal the user that, in order to manipulate the list, they have to push this button.

Answer 3

• Multiple selection:

  You can have checkboxes for each entry and an action bar on top of the control bar. So user may select a couple of entries and then press the button for required action.

• Single selection:

  If it is not relevant to apply actions to multiple entries in your case, then instead of checking boxes user may highlight an entry with a single click and then apply the required action. If user presses the action buttons before selecting an entry you can prompt user to select an entry first...

Answer 4

The usual solution when you have many commands for a collections of objects is object-selection-action syntax: provide a single non-scroll-away central location for the commands (e.g., a button bar or pulldown menu bar at the top) and provide a means to select and multi-select the items. You can supplement the centralize buttons with accelerators and a context menu (right click) to speed things up for experts. This is typical of desktop GUIs, which tend to be richer than web apps or mobile.

Object-selection-action should be considered when you’ve three or more commands per item –when you start using too much space for commands that could go to data. In this case, you’re right on the threshold, so you may want to reconsider the advantages of staying with separate buttons per object. It might be more familiar to your users if they’ve more experience with web apps than desktop apps, and it allows the user to execute a command on one item with a single click. Object-selection-action takes two clicks to complete a command (select item then a button), although expert users can make up for it if you support range multi-select through dragging or shift-clicking. Users used to web apps may not be expecting object-selection-action, and there is no standard way to indicate that selection is supported (but I’d try simply highlighting the first item on the list by default).