Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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: enter image description here
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), enter image description here
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?
enter image description here

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.

share|improve this question
add comment

4 Answers

up vote 13 down vote accepted

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:

MS Word Ribbon Pages style drawer with toolbar

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:

enter image description here

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.

share|improve this answer
    
Quite an insightful method :) –  rk. Mar 23 '13 at 2:53
    
Great explanation! I'll try to digest it some more :) –  Pasha S Mar 23 '13 at 2:56
    
Thanks. I get lucky sometimes. I really have found it helps me - it was inspired from using Mac apps with a full set of the default menu for desktop apps, that didn't actually do anything; decided building that first made a lot of sense. :) –  Josh Bruce Mar 23 '13 at 3:05
    
Sometimes you have software full of commands in menu and submenus. So crowded, that nobody finds needed functions or complain about them (thinking they aren't there, but they are). To improve findability of commands a toolbar with visible commands is a very, obvious way one can go. This was the origin of Ribbon's invention and increased findability of functions dramatically. Personally, I am struggling with this, forced to use Office 2003 at my new employer - used to Office 2007. It's so annoying. Ribbons story here: istartedsomething.com/20080308/office-2007-interface-prototypes –  FrankL Mar 24 '13 at 19:32
add comment

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.

share|improve this answer
4  
+1 For alluding to the old adage: Good design is not running out of things to add, but running out of things to take away. –  Josh Bruce Mar 23 '13 at 2:14
    
Sorry I forgot to mention that. Yes, the application is a text editor, more specifically it is an IDE, so that the target audience consists of experienced users. –  Pasha S Mar 23 '13 at 2:26
1  
In that case, check out the UI for Sublime Text 2 on the Mac - no toolbars - pretty interesting. –  Josh Bruce Mar 23 '13 at 2:45
1  
Hah, just wrote about that in the edit :) –  rk. Mar 23 '13 at 2:49
    
There is a Windows version of Sublime Text 2 as well. It's hard to tell, but maybe that's what made me think about toolbars in the first place :) –  Pasha S Mar 23 '13 at 2:55
show 2 more comments

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.

share|improve this answer
    
Interesting approach! I guess you can put the Save button into the same category. However can you explain some more about the Undo/Redo buttons? Say, you ran Undos up to the beginning of the Undo history. Undo button becomes grayed out. But don't you get the same information from trying to perform another Undo and getting nothing? Would it help if there was some other, more conspicuous indicator when you press Ctrl+Z and there is nothing to undo? Or if there was a message in status bar saying "Redo available" or "Undo unavailable"? –  Pasha S Mar 24 '13 at 8:20
    
@user958624 — Sure, the Save button also helps me in this way by telling me whether the file is saved or not. –  Nicolas Barbulesco Mar 24 '13 at 10:27
    
@user958624 — “But don't you get the same information from trying to perform another Undo and getting nothing?” That would require me to perform the action in the first place. In addition, what would be “getting nothing” ? How could I know whether the action changed something in my file ? By analysing the state before and the state after, and by asking myself whether there is a difference ? I don't want to do that ! –  Nicolas Barbulesco Mar 24 '13 at 10:32
    
@user958624 — As you suggest, there could be an error beep when the action asked is impossible. But that would require me to perform the action in the first place. And the error beeps could become a little annoying. –  Nicolas Barbulesco Mar 24 '13 at 10:35
add comment

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
share|improve this answer
    
Yes, I will definitely add all those other control methods too. One-by-one, starting from the ones you listed, and followed by voice recognition, hand gestures, and mind reading :) In this question however I'm focusing on toolbars, otherwise the topic would become overly broad. –  Pasha S Mar 23 '13 at 5:18
    
Sure, i just pointed out the other ways because in the end you have to consider them all at the same time, and not one by one. If you go for customisable toolbar, then you should have customisable everything for instance. That's how Notepad++ works, you can customise the toolbar, the keyboard shortcuts and the right click menu, and all the 3 reference the same functions. –  gotson Mar 23 '13 at 6:57
1  
Don't forget the first way to access functions : the menu. –  Nicolas Barbulesco Mar 23 '13 at 22:49
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.