Strong opinions, weakly held

The trouble with icons

Scott Rosenberg, in discussing the new version of Microsoft Word, makes the following observation about icons:

Maybe I’m unusual, but I have always found the dizzying array of toolbar icons in Office programs profoundly unhelpful. Icons are fine when they are small in number and used constantly (think of the stop, reload, back and forward buttons on your browser). But when you have a multitude of complex tools and features, as in Word, you never really get the hang of what all those little hierogylphs really mean.

I was thinking about the applications I use, and how often I wait on the tool tip to figure out what an icon actually does. The other day I was using an application that I don’t use very often, and I had to wait over every icon to get some of the most basic things done. Part of that was my unfamiliarity, and the other part was that the icons just weren’t very well designed, so their use was not obvious.

On the other hand, pulldown menus are no pleasure cruise, either. When I’m using Microsoft Word or some other feature-heavy application, I almost always find it difficult to remember which menu I need to scour for whatever it is I want to do. At least with icons I can see them all at once and make an educated guess based on appearance and context when I’m searching for a feature.

I’d also be interested to know how many different toolbar buttons people recognize on sight in any complex application that they use. I am extremely familiar with Eclipse, having used it daily for many years at one time. The toolbar in the Java perspective has 24 icons with no files open and at least 27 if I’m editing a Java file. I use five of them regularly. I recognize maybe 10 or 12 of them. Looking over them now, I see that most of them offer functionality that I usually access via the keyboard or via context menus.

I don’t really have any conclusions to offer here, other than that it seems like user interfaces with a lot of redundancy make sense. In Eclipse, most features can be accessed from a toolbar, from pulldown menus, from context menus, and via the keyboard, and I use a mixture of those methods depending on which feature I’m using. I’m sure if you talked to another Eclipse user, they’d access the same features in completely different ways. That’s one good reason why getting rid of the pulldown menus in Office may not make the most sense. If I’m used to enabling and disabling “Track Changes” from the pulldown menu, it doesn’t matter if I can do it from the Ribbon, or a button, or the keyboard, learning a new way to approach the problem is going to slow me down.


  1. I think it’s only an issue in the transition period. Part of the goal with the new Office UI was to make the functionality more discoverable since 95% of users don’t have a clue what all Word (eg) can do. And if you know the keyboard shortcuts, I get the impression they will mostly remain the same.

    As for your bigger point, I think redundancy in UI is probably worse, because it means knowledge will be less easily transferred (if you do most things through menus or accelerators, but I use the toolbars, we aren’t going to efficiently share tips about where certain functionality can be found), it adds to the feeling of feature bloat (deserved or not), and it introduces that many more opportunities for bugs and bad user experiences. Jensen Harris’s horror stories about adding task panes as a third UI mechanism brought this point home to me quite strongly.

    I dunno. I’m excited about the new Office UI, but then I rarely use the product. It’ll be interesting to see how rank and file Office users react, or if it even gets adopted by big organizations.

  2. NeXT did it right with the vertical menu bar. Also, every menu and sub-menu could be torn off and left floating. Imagine being able to tear off many of the sub-menus in Word or Excel or BBEdit or OmniGraffle or Photoshop or other applications that you regularly did deep into the menus with. If you know you’re going to use a particular sub-menu a lot (even just for a few minutes), just tear it off and let it float above your document, perhaps right next to the area you’re working in so you can easily and quickly select some text / objects and click on menu commands.

  3. Good UI goes like this:

    Make it easy to understand (i.e., native language descriptions instead of hieroglyphs) for rarely used functions/applications; the latter being something like a Monthly Expense app or an Annual Review program.

    Make it fast and easy to use (simple toolbar icons/keyboard shortcuts) frequently accessed functions/applications. So, for a word processor the two frequently-used functions might be file open/save and print/email.

Leave a Reply

Your email address will not be published.


© 2019 rc3.org

Theme by Anders NorenUp ↑