Table with actions per row

Question

One of the pages in our web app includes a table that typically has a few dozen rows for each user, and it takes most of the page's width (5-8 columns).

For each row, users can perform 3 possible actions.

What's the recommended way to let users perform these actions? We've considered a few options:

1. 3 small action buttons on the left-hand side of each row 1
2. 3 small action buttons on the right-hand side of each row
3. Drop down with the three actions
4. Other approaches?

I saw other questions with a great discussion on How to avoid repetitive actions in table rows?, but in this case, I'm more interested in the right place to put them.

Thanks!

Option 1 Illustration

Answer 1

3 small action buttons on the left-hand side of each row

With a LTR languages, one can assume users will first inspect the row (starting from the left) and only then decide to take action.

So placing the buttons on the left side is somewhat counter-flow.

3 small action buttons on the right-hand side of each row

Pros:

• Buttons are easily accessible. This is important if user perform a lot of these actions (a lot being that the main point of the table is to allow users to act on records).

Cons:

• More likelihood for errors (small buttons in close proximity).
• Small buttons will have icons, which have second-degree semantic.
• Takes more space than a dropdown.
• Not scalable - there's a limit to how many buttons you can put.
• More visual noise.

Drop down with the three actions

Cons:

• Requires an extra click.

Pros:

• Dropdowns can use text, which is clearer than icons.
• Less visual noise. Users only see actions when they need them.
• Takes less space.
• Can easily scale, even to dozen of actions.

Other approaches?

At least to combat the visual noise / space issue, you can only show these actions on hover (although such design won't work on touch devices). Like in Googles' Inbox:

Finally

I think it really boils down to how often these actions are used. In some systems, users must take action on each record, which means the extra click of a dropdown can reduce efficiency. But on systems where actions are less common, dropdowns are a good solution - reducing visual noise and saving space.

Answer 2

In terms of the order, the primary (in terms of user association) identifier for the data row should always be on the left in a left to right language localization.

Note that if you have a unique ID for each item, this may not be appropriate if it's not what a user themselves would primarily associate with that item, or the main feature they would generally sort/look for an item based on. Default column arrangement needs to be approached not from your context, but from the user's.

@Xabre's answer provides more details/source articles related to scanning and recognition.

In terms of control placement and format, there is always a conundrum between the visual load created by filling a portion of a screen with repeated controls (particularly when scrolling) and with speed of using those controls, along with making sure the controls are explicit enough in their action identification that they do not cause confusion.

Frequently, inline controls are made smaller or with simple icons, in order to fit within the space they're restricted to. This can be problematic for discoverability for people who are unfamiliar with your application. Even when you feel you have used icons whose purpose should be self-evident and which are relatively consistent globally to other similar applications.

A drop-down or accordion can have a great deal of success here, if the task related to this set of data is likely to only be performed once per list view. At that point, the primary time factor is likely to be finding (search) the correct row to operate on, and a small loss in time due to having to click to open the controls is likely to not be an issue.

Another strong option to consider (in fact, it's the selected answer for the question you linked) is having each row be selectable, with a set of operation controls provided in the top or bottom of the screen/pane which perform the associated action on all selected rows. Make sure to provide appropriate de-selection (and possibly select-all) controls if doing this.

I generally recommend locating all actions which will not change the current view context at the top of the data set pane, in order to clearly promote what actions can be taken on the following set of data. This also keeps the controls consistent with familiar paradigms in similar action-heavy list controls such as file tree viewers.

Google Inbox provides a fairly strong example here, with four primary controls and an ellipses dropdown menu exposed across the top when in multi-select mode, for performing actions across the entire selection set:

Note that while Google does locate the checkboxes for row selection on the left, their uniformity, small size, and otherwise low visual impact mean it is still very easy to scan down the left column for desired email titles. Their simple and repetitive nature helps them be easily attenuated visually and mentally without competing overly in the search task as distractors.

It is also possible to do row selection via having the user directly click/touch the row itself in order to highlight it (see the Windows Explorer example farther above) but be sure that it is clear to the user that this interaction mode is available and that it won't lead to changing the view context/navigating away. I usually prefer checkbox controls over this as they are more self-evident in their available interaction: it can be difficult to provide appropriate cues for discoverability without apprehension in multi-selects which appear to be a normal list of items (rather than a clearly self-contained multi-select control) short of using something like a checkbox control.

It's possible to mix both patterns, and have individual controls exposed via something like hover or expansion (such as when "opening" an email in google inbox, see below, which forces the controls to stay visible rather than only showing on hover) on each item, while alternatively being able to select multiple items (rows) and then operate on them from a top bar of commands. It is important that these modes block each other to avoid confusion: otherwise users can be left questioning what will happen when they use the controls on an individual row when multiple rows are selected.

This can particularly be a decent compromise between aesthetic choices and usability concerns. Alternating and/or multiple modalities of operation can be a two-edged sword in terms of usability. While offering more options for accomplishing a task provides flexibility to different approaches from people using it, it can also create confusion, particularly inter-user confusion. Personally, I think in this case these both have enough global conformity in terms of the presence of paradigm and shared context to be acceptable when presented together for most people, but it can be something to keep in mind.

Note: this isn't trying to claim Google Inbox is fantastic UX across the board, but it provided an apt example for this discussion. Note also the use of controls for each item along the right-hand side.

Answer 3

I think it depends on the main purpose of that table; if Update/Delete, put it first else put it last. In most cases though, you probably first want to identify what you want to edit/delete; in that case putting it at the left side forms clutter and is better to replace it with a checkbox and to than put the inline controls at the right side instead.

Also if there's room to place the actions inline, just put it there, else it's not discoverable and the cognitive load increases; unless there are a lot of actions, put the most used in-line and add a menu button for the less used actions.

Also, to decrease the time to scan, one could opt to put relevant data together in one column (e.g. instead of 'First name' & 'Last name' say 'Name'); again ordering data from left-to-right in order of most-useful.

Sources:

• http://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/
• http://deep.design/the-hamburger-menu/
• http://ui-patterns.com/patterns/Recognition-over-recall

Answer 4

I propose you do this like on YouTube (and the same solution is proposed in the accepted answer of the question you link to) when there is a table with videos you uploaded. There are some actions, like "Delete", "Publish", "Edit" etc. for each video.

The Table has one more column allowing selecting a video (this is typical checkbox). You can select multiple items at once and then perform the same action for each selected video. Of course there are also "Select/Unselect all" options.

What is important (and there is lack of it on YouTube, if I remember correctly) the table heading does not follow when you scroll the page down, so you need to select videos (even if it is only one), and then scroll up to the heading to perform the action. I would like it is always on top of the screen, not the page.

Answer 5

I will like to keep it very simple. Actions in row are OK only when there are only 2-5 records. But even then the action controls/buttons should be on right hand side because user scans/reads the record and then takes the decision on actions like edit, delete. But for long data tables i will suggest to go with the option to user to select the records on which he/she wants to take action and then click on action button. Specially when the action is to delete multiple rows, this works good. See the following image for more details: (In this example, I want to place edit in same row, but due to some tech challenges I had to place it next to delete action button.