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
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.
No comments:
Post a Comment