Toolbar buttons - to be or not to be?

Question

I need to create a toolbar for my application, and let's assume that due to external constraints it must be a regular toolbar, not a ribbon. The application itself has a significant number of functions, and now the question becomes: how do you choose which functions to put on the toolbar?

The various user interface guidelines state that the toolbar must host "the most common functionality". However it is really unclear what does that mean. How often should a function be used to deserve being included on a toolbar? How do you do usability testing to understand which buttons should be on the toolbar, and how to detect if a button which is already there should be removed?

Based on my own experience, applications rarely get their toolbar functionality right. For example, Total Commander toolbar looks like this:
I never use any of the buttons except the ones I put there myself.

The Notepad++ toolbar is probably better (at least I understand what the majority of buttons do),
but even then I have difficulty imagining a user who would be using "Cut", "Copy", "Paste", "Undo" and "Redo" from the toolbar instead of using a keyboard shortcut. Also how often do you need to create a "User-Defined Dialog", or "Record a macro"?

Is it a good approach to throw in buttons just because there is a space for them? Or is Google Chrome's approach of keeping it to a bare minimum better?

I understand there is generally a benefit in having a toolbar button in that users can click it faster than selecting the same command from the menu. But there is also a cost associated with each toolbar button in that it clutters the interface and makes the other toolbar buttons harder to find. So how can I assess the cost/benefit ratio in this case?

EDIT: If it helps, the application I'm writing is an IDE, target users are programmers. It's a desktop application, initially developed for Windows only.

Answer 1

I'm assuming we are talking about a desktop app here. Further, I don't really know the type of app you are building, but can offer some help in studying the needs of the user without getting bogged down with the question of "how many clicks does it take to get to a good UX". Most of your examples seem to be on text editors; so, we'll go with that.

My recommendation is a somewhat odd one in comparison to the build it first and see how users use it - "it" being the toolbar itself.

Iteration number 0.1 - remove the toolbar entirely, and keyboard shortcuts - menus only. Let some internal folks (yourself included) use it for a little bit (if it's just you, spend a day or two playing with the app the way you would - you are going to use your own app, right?), and perform archeology with those users (concept taken from IDEO). What menu items are they going to over and over again? Do they actually ask/assume there is a keyboard shortcut before going to the menu (indication to possibly make one)? All you have to do is count the number of clicks to a particular menu item.

The benefit of approaching it this way is that, you are going to have to build the menu anyway - one of the most oft neglected pieces of an application released by individual vendors (at least for the Mac) - this method forces you to build one.

So, you know the hot buttons - the ones with the most clicks. Now for round 0.2 - create keyboard shortcuts for the menu items users clicked on the most. Again, measure these things. How often, after seeing the keyboard shortcuts, do your users start using them instead of the menu? These are probably great candidates to be in a toolbar somewhere.

Don't assume much of anything without testing your assumption (I've seen a lot of apps, or heard a lot of CEOs, where they said, "I know users, they'll want to..." - try to avoid that as much as possible.)

Now, you're ready to build a toolbar. You know the functions people use the most. You know the functions people try the fastest to learn the keyboard shortcut for. You also know the functions people assume already have keyboard shortcuts and what they should be. The functions where people went to the menu a lot, assumed already had a keyboard shortcut from 0.1, and started using the shortcut instead of the menu in 0.2 - may not need to actually go in the toolbar - because if they already assumed there was a shortcut for it in 0.1 and/or memorized the shortcut for it in 0.2 - means they will most likely default to that interaction methodology (cut, copy, and paste, for example).

The ones where people clicked the menu items a lot, didn't assume there was a shortcut in 0.1, but learned the shortcut shortly after seeing it for the first time in 0.2 - pretty good candidate to be in the toolbar (bold, italic, underline, for example). Anything that has a drop-down involved - pretty good candidate as well (font-face and -family, for example).

Now we get to the more obscure functionality and the archeology bit. Usually involving all those items people didn't actually click on a lot 0.1 or 0.2 (and you probably didn't add a shortcut for them either). But, when you watched the user trying to find it in the menu - they got frustrated and seemed to want to find it fast, but couldn't. These items are things you want to maybe consider making easy to access somehow, but not always "in the user's face". For example, let's compare the "styles" menu in MS Word to the styles drawer in Apple Pages:

In the Ribbon example from MS, the styles are always there - taking up space in the toolbar - despite many users not really using them that much and/or not writing documents that need to have the header style changed nearly as often as, say, changing to a bulleted list, which you can also do from the styles pane. In the Pages example from Apple, the style drawer is displayed when you hit the blue paragraph symbol - hides when you hit it again - optionally visible all the time or not based on user preference, but the toggle is in the toolbar.

Test this again as 0.3. After which you will discover those tertiary functions people don't use often. Aren't terribly upset they can't find and don't have shortcuts for. Then create a way for them to access them. In the case of Pages, this is handled through the inspector - which is just a dialog box that pops up with tabbed navigation:

Now, you have a fully (relatively speaking) functional menu, with shortcut keys based on actual usage not guessing. You have a pretty good idea of what should be available all the time in the toolbar. And, you have the items which you may want to be available quickly, but optionally. Looking at the items where user clicks were somewhere in the middle - use your best judgment (in Pages, for example, I never use that column button, but, if I ever need it - there it is; note it is also a drop down, which generally is prime territory for the toolbar).

In response to this being an IDE. Chances are these are computer geeks - and will most likely be using shortcuts more often than not. Which is fine using the "build a menu" first concept.

Hope that helps, because there really is no "if they click X number of times" rule I'm aware of.

Answer 2

First of all you will want to use card sorting to figure out which functionality goes in the same group. After that you want to keep the most used functions directly visible in the toolbar itself and the rest can be hidden in drop down menus.

How to decide what functionality is most used? Well, for that you will have to evaluate the core functionalities of the application you are building. If it is a text editor, then the usual text editing short-cuts, cut, paste, edit, etc. are usually a good option to keep in the toolbar. What kind of application are you making? I can be more specific if you can tell that.

Now, the notion of stripping down everything from the interface till only the essentials remain is the essence of good design. In browser it makes sense to remove everything but the page controls and search functionality visible (firefox, chrome, safari, etc.) Sadly, in the case of an application (which has many more functions than just viewing webpages, it is a more difficult task.

Finally, user testing is a good testing tool to see which functions are needed in the toolbar.

edit 1 From my personal experience, I can tell you the 2 extremes of text editor IDEs: Notepad++ with its full scale toolbar and Sublime Text with its stripped out interface with nothing but an overview of the code itself.

Let's compare these 2 editors(UI wise):

• Sublime text: The main feature is the text overview which you get here. Apart from that, no buttons, no toolbars to intimidate you and a standard text editor menu bar.

• Notepad++: You are faced with a monstrous toolbar with varied functions from text edit, macros, etc. and then there is the standard menu above it with some some additional IDE menus.

I know many programmers/developers who have been using sublime text as their main IDE. The main reason is the simplicity and the beauty of the interface. The main reason is, if the user is an experienced user, he is well aware of all the features a text editor IDE should offer. They can go inside the menus are customize the settings for their environment and that's it. The environment is not something which programmers change every now and then (on the fly). Hence, no need of a permanent toolbar. Sublime text hit this sweet spot and added the awesome overview feature to nail it.

Lesson: Beauty and simplicity won over bulky functionality.

Answer 3

Don't suppose the buttons in the toolbar are there only to be clicked. Don't estimate the usefulness of a button only by its clicks.

I thought of that when viewing your screen photo of Notepad++. In Notepad++, I very rarely click the Undo / Redo buttons, but I use them a lot. By just looking at them. These buttons, being grey or green, tell me whether there is anything to undo or to redo. And this is very useful to me. I miss these buttons in Eclipse.

Answer 4

What about a customisable toolbar where people could add/remove buttons, like on Microsoft Outlook ?

Each person has different preferences when it comes to UX, especially power users (and according to your post, the users will be programmers, so most likely power-users). So why not let them choose what they want to see in this toolbar ?

---

As a side note (and this may be a bit out of the initial scope of the question, but when it comes to UX, we should broaden our view) toolbar is not the only way to access your functions, there are various other ways you can explore (if they can be applied in your particular use case):

• keyboard shortcuts
• right click menu
• command line (some applications offer a console where you can run commmands)
• mouse/trackpad gestures