Alternative way to display too many buttons

Question

I'm working with a user who wants to have everything at a push of the button. When viewing a record, he wants big buttons across the top of the screen to return to the search, return to the search with filters, jump to a related record, return to the main screen, etc.

I try explaining that sometimes more buttons, especially wordy buttons, do not make things easier, but actually clutter the interface and makes things more difficult. That point doesn't seem to make sense to him, and working with a tablet-size web browser, I've reached my limit for buttons I can display in a single row. I really don't want to create two rows of buttons.

What's another way to present lots of options, but still keep everything "at the fingertips"? He didn't seem too receptive of a drop down menu, but perhaps a combination of buttons and menus, or another method would work better.

Answer 1

Adding to Brian's comment, if the site is available for new users, you should definitely try to tell your client that if he is giving you the job he should trust your criteria. But it's better if you use information and examples to support your choice.

I can think of three ways to deal with lots of navigation options that are immediately accessible (sort of).

Navigation bars with text instead of buttons:

Hover to show more options (if you are designing for iPad / iPhone you will have to think of an alternative, maybe always show them for mobile and hide them for desktop, using media queries):

Two levels of navigation, one for main (structural) buttons and one for quick links or something like that. Maybe clicking (or touching) on the main could show you the second level:

These last two would be my proposed option (specially the blue one). If you have all buttons looking the same, none of them will grab the user's attention. I'm sure there is a hierarchy (if not it's something you could talk to your client about) and that it can be expressed more easily. Hope it helps.

Answer 2

If it is unlikely that every single button is going to be used frequently, it may be possible to run a "frequent" button row and then a separate menu for other buttons which may be used less frequently.

You mentioned that you are working on a tablet-size web browser so you might be able to take some inspiration from the new Windows 8 start menu or also Facebook's mobile/touch site with a menu of links which slide from the side using a swipe gesture.

Drop down lists can sometimes be awkward to use with touchscreens and if a user wants to access information quickly, larger sized buttons may be to their advantage. However, for desktop sites, dropdown lists may be more appropriate.

Answer 3

All features more or less need a place to click to be launched. But restricting that clickable area to be toolbar buttons only, when there are so many great things to work with (using menus, dropdowns, split-buttons, checkboxes, navigation, pages, dialogs, context-menus, keyboard shortcuts, ...), would inevitably create a cluttered toolbar.

Exactly which buttons that will be used and which that should go away or become something else is indeed a difficult task to sort out to start with. And after a couple of releases with functionality added, I promise the toolbar can become a Frankenstien's Monster of functionality. You are doing yourself and your clients a favor never letting it. :)

You can never make a toolbar from where all tasks are done. Structure and navigation is key to not only keep "everything at your fingertips", but also keeping the UI "clear" (a thought on that on Google IO 10).

The toolbar in the top of a window/page is typically for actions that are frequent or applies to the state of the entire window/page. Other actions are more conveniently placed next to what they affect, and some do not fit on that page at all, but should be found when navigating away to another page/dialog/window, typically viewing a record or returning to the results, which have its own actions and toolbar.

It is hard to say what you could do without more information about your context and design so far, but based on the examples you provided about [return to search], a button on one page should inmho simply not manipulate the content on another. For minimum confusion, the action that applies to a content should visually be placed next to that content, so that the user can see what the button does when clicking it.

One of them must be the typical thing to do considering the work flow, and I guess that it is returning to the search results the way they were when we left them. The other option should be a click away from the search result list, not from the viewed record itself.

There is just so much a user can focus on, at a time, anyway.