Should bulk-editing functions be hidden until a table row is selected, or is there a better solution?

Question

As an example, MailChimp displays subscriber lists in a table/data grid. Notice that while the user can select one or more rows using the check box at the left of each row, he doesn’t know what actions might be available once the row is selected—none are visible:

Next he selects a row. Notice that the Delete button is now visible.

I understand why this pattern was used. The designer feels that deleting a row is a less common task and doesn’t need to be visible at all times. It’s also true that if the Delete button were visible while no rows were selected, clicking it would yield no functional result. (The designer would have to present the button in a clearly disabled way, or offer an error message, etc.)

While I understand, this doesn’t mean that I’m perfectly satisfied.

Objections

• Lack of discoverability. It makes me uncomfortable that whole categories of interactions are flying on and off the screen. The user doesn’t see what actions he can perform on a row until he selects one. Depending on his familiarity with common interface patterns, he may not even anticipate that a hidden function will reveal itself, and thus he could feel little incentive to select a row.
• Bad use of proximity. The action button may be far removed from the check box, so that the user scrolls all the way to the bottom of the page to select something, then scrolls all the way up to the top of the page to perform the action.
• Bad feedback. Perhaps the user has scrolled to the bottom of the page to make his selection, and the Delete button has been eclipsed. In that case—depending on the knowledge of the user—he might not understand that anything has happened due to the lack of apparent feedback.

The last two could potentially mitigated with a “sticky” action bar. Proximity would still be an issue, although less so.

Conclusion

I understand why MailChimp has used progressive disclosure in the way they have, and I use the same pattern myself. It still feels wrong in some small ways, and I’m hoping for a better solution.

Answer 1

Bulk edit is a power tool.

Affordance, although discoverability might be a more relevant term here, isn't a big issue because this is not the only way to delete or edit items. You can always drill down into a specific item to manage it. So while you do have to "learn" it the first time around. Once you have, it's not a big deal.

Also remember an interface that allows bulk editing assumes you're dealing with a system that receive sufficient usage and contains some amount of complexity in the dataset. Otherwise, why would you need to have a bulk edit feature? The interface is now a tool, which under most circumstances, are used regularly. Discoverability matters less than efficiency.

Which goes to your next point: breaking proximity rules.

If the system makes you scroll to the top or bottom of the page to perform bulk actions and there are large amount of data on a page, then this is poor usability as you've mentioned. A "sticky" action bar like Gmail's bulk edit is what I'm used to when it comes to long scrolling tables.

Yes, the bulk actions might not be right next to your selected rows. However, the actions always appears in a consistent and expected location. And frankly bulk edit is a specialized enough action where having the user make a deliberate action to bring their mouse to the action bar isn't a bad idea. Bulk edits can affect a large number of records. User should be sure before they perform the action.

In terms of whether bulk edit actions should be hidden until rows are selected or not, it broils down to the # of actions available. If you have a lot, it makes sense to show them contextually to avoid cluttering the interface, otherwise you don't.

Answer 2

You're asking when it's OK to hide certain controls.

I came across one useful answer to this question is in the book, Designing from both sides of the screen, by Ellen Isaacs and Alen Walendowski.

This book talks about frequency and commonality as a way to assess whether a feature needs to be built, and also how prominent the feature should be in the user interface. The assumption is that since a program has lots of features, and they can't all be in the main UI—because as UX designers we neither want to overcrowd the UI nor overwhelm the users.

This grid is a gross oversimplification of their idea about where to present a feature's controls in the user interface.

Use the grid to look at the possible treatment for a particular combination of frequency and commonality. For a new feature, you estimate the amounts; for an existing feature, you measure user behaviour. In this grid, Frequent means nearly every time they use the software. As with any guideline, some other guideline may take precedence over this one, so you may choose not to follow this.

Disclaimer. I want to repeat: the above grid is an incomplete oversimplification. There are many more options and many nuances that the grid, above, omits. Also, while the basic concept is from Isaacs & Walendowski, these are not their words so any errors of interpretation are mine. :)

See this idea at work on a huge scale

If frequency-commonality interests you, I recommend you watch Jensen Harris tell The Story of the Ribbon on video (or slides + audio only), in which he describes how Microsoft gathered and analysed the data that informed the grouping of controls on the Office 2007 ribbon. Even if you dislike the ribbon, the video provides fascinating insight into the method.