February 22, 2006
Pop quiz, hotshot. What do these toolbar icons do-- and what application are they from?
Okay, maybe that's a bit too monochrome. Does color help?
Okay, let's try something less abstract. Does a more traditional look help?
So we can see there's some kind of VCR-like functionality, and some arrows. And Furrygoat's Law is at work, because I smell some RSS in there.. somewhere. Perplexing.
I think you can see where this is going. Sometimes, the best icon choice isn't an icon. It's a word. Jef Raskin explains in his book The Humane Interface:
Icons contribute to the visual attractiveness of an interface and, under the appropriate circumstances, can contribute to clarity; however, the failings of icons have become clearer with time. For example, both the Mac and Windows 95 operating systems now provide aids to explain icons: when you point at the icon, a small text box appears that tells you what the icon stands for. The obvious reaction, which I have observed repeatedly when users first see this facility, is-- why not just use the words in the first place?
Instead of icons explaining, we have found that icons often require explanation. If you wanted to obscure or to encode an idea to keep it from prying eyes, substituting icons for the words might not be a bad start. The problem with icons can be considered an issue of diminished visibility: the interface presents an icon, but the meaning of the icon is not visible, or it may give the wrong message to someone for whom the graphic is unfamiliar or has a different interpretation. For example, an icon that shows the palm of an upraised hand indicates "halt" in the United States, but signifies "here's excrement in your face" in Greece.
Now take a look at this alternate, ultra-minimal toolbar skin:
Which of these toolbar skins would you rather use?
I'm not proposing that all icons be replaced with words. Of all the user-created toolbar skins on this page, the best are invariably a combination of icons and words. Graphics alone isn't enough.
Consider Microsoft Word with all possible toolbars visible:
Which of these toolbar buttons are decipherable to you? My eye is inexorably drawn to the toolbar buttons with icons and text. The rest are lost in a morass of 16x16 graphics noise.
It's experiments like this that convince me the Office 12 UI team is really on to something with the ribbon. Even the traditional menu seperators are plumped up with text now.
Posted by Jeff Atwood
Excellent post and definitely agree that text more often is better than icons. The challenge while designing some software like Word vs. a browser is that a browser has limited functionality while Word has so much functionality in it you hardy remember whic icon helps you do what. What would be nice is if somehow the application would try and manage the most used icons (just like it does now for the desktop icons in Win XP) and allow the user to search/discover anything he expects the application should have.
Firefox has a similar setting, but it's buried in the "customize" section under "View" - "Toolbars".
If people have to think too long about your icon, they aren’t going to use it. I’m confronted by horrible icon choices in the elevator all the time. Especially when I see someone running towards the door and I want to hold it for them. I’m confronted with two icons.
So I have to stop and figure out which way the little arrows are going, which is usually enough time to allow the doors to shut and me to feel bad about not having held them. While two buttons marked “Close” and “Open” don’t take long for me to process. The shorter amount of time to process means that I press the correct button and get to hold the door for whatever PhD or Noble Prize winner is trying to get on the elevator with me. Other times I end up pressing the alarm button like an idiot.
See, the icon for "open elevator doors" is so bad the HTML filter ate it.
In my view there are two things in using icons
1) Learning and familiarity : Lets assume that everyone uses word only then we sort of learn or rather adapt to the icons. Adaptation is from picture and location - we tend to go left for any file operation and right for alignment etc.
2) Real estate : As stated by others, text takes up more space and very hard to come up with appropriate short forms. What would you say for "align text left"? It is easier to convey using icon.
In my view icons or any form of visualization is more dominant than text. We are slow when we have to parse text due to its non-continuous nature. But main questions is how and where you show icons.
Eyes going for text naturally in word image is due to breaking of continuity not because it is conveying more information in first glance. All are equal perceptually.. if we had all text and 2 icons then our eyes would have been drawn to icons.
This is ongoing research and very hard to get :) Windows with more than 10 yrs of development and research still confuses people !
My 2 cents
Well icons take lesser space on the screen then tekst buttons. But if icons take the entire screen, then something is clearly wrong. Some people have 100 icons on the desktop?
Furthermore I feel sorry for those who work with nothing but office, but again they probably learn to use shortcuts ( I hope ).
It is my belief that dropdown menus are better then toolbars. Because they are better grouped and can be accessed from the keyboard. I tend to use ALT + F - S alot when I am to lazy learning shortcuts or moving my eyes through the toolbars. Seems very logical that the new office combine the dropdown and the toolbars. But again it ends up to how they are implemented.
The worst thing about Toolbars is when they are moveable. It is ofcause nice when you can customize stuff .. but if the functionality is not bulletproof it can be a pain. Sometimes you cant get the toolbar back because you somehow made it invisible because you clicked on the moveable part of the toolbar in a hurry.
Originally the intent of toolbars (at least in Word, Excel, etc) (well, as far as I, at the time a lowly developer on the Word team, recall) was quite limited - it was to increase the "speed of use" for common tasks. There was nothing on the Word 2.0 toolbar that wasn't simply a shortcut to a dialog available on the menu. For example, where File/New took two clicks to get to a dialog full of choices and then one more to click OK, the "New" toolbar button just made a new default document in one click.
In this world it kinda made sense that discoverability wasn't the most important factor in designing the toolbar. While you were learning to use the app (or a new feature) you could just use menus and dialogs. Once you'd gotten experienced enough with something to wish you could do it with fewer clicks, you'd go find it on the toolbar. Thereafter is was merely important that you be able to quickly _recognize_ the icon. (And that they stay in more or less the same place).
Over time (for good and bad reasons) this simplicity has evaporated. Now there are toolbar buttons that bring up dialogs, commands that exist only on toolbars, toolbars that reconfigure themselves based on what you're doing, and all manner of other "disasters" that would have had the Word 2.0 designers in tears.
Bring on the Ribbon!
Something I always wonder about is what Asian programmers users (working in Chinese derivative writing systems) think about Icons.
I mean, when most/some of your written language is based on on Iconography, why would you ever try to use a silly non-standard picture to represent something that you already have a word for? Sure, sometimes you need 2 or 3 characters to represent an idea, but those 2-3 fixed-width 16x16 images will convey tons more information that your average garbage US GUI icons, which are almost meaningless on their own.
Of course icons are worthless without tooltips. If I had actually been using the app(and assuming they actually did use tooltips) I could have figued out the functions of the icons in a few seconds. Of course, it would be much faster if the text was on the buttons, but there might be issues with using text as well.
The number one reason I can think of is localization. If you have a word in english that fits perfectly, how can we be sure when the application is localized to another language, that it won't be a much longer word. Space is usually a consideration when designing toolbars. If we're talking about a windows application, liquidity is not as easily achieved as it is on a web app. If you use a combination of icons, with localized tooltips, then we can worry less about the length of a word.
Icons do add some aesthetic appeal, but I agree, if it detracts from usability, then something else needs to be considered.
Marty brings up a good point: localization. That's a tough nut to crack through out the visual UI and not just limited to toolbar buttons.
I've always agreed with what Raskin has said and I too think the Office guys are really going to push the envelope in usability with the ribbon.
I know that when I create a visual UI (boring internal use banking applications), the obligatory toolbar has only the absolute universal icon buttons and everything else is an icon/text combo button. Plus a menu choice, plus a keyboard shortcut.
I can remember when toolbars first hit the scene with Ashton Tate's Full Impact on the Mac. Before then, Excel only had menus...Word: menus only. Only Paint programs had buttons and that was in the pallet. Oh how times have changed...
I worked for a couple of years on a web browser ("WinWeb") way back in the 1995-1997 period.
Back them I formulated the law that 'every application wants to be a web browser', which still seems to be the case to me.
I'd never seen Word with every toolbar enabled.
That's just confusing as all hell. I know no one would ever need all of those open at once, but still. Yikes!
ah my. this has been going on for decades. the latest to write about it (that i've seen) is Mr. Spolsky. he refers to it as the difference between ease of use and ease of learning.
icons, and mouse generally, are geared to ease of learning ("we can fire anyone and get somebody cheaper who can learn FooBar in an afternoon"), rather than ease of use (vi/emacs users Never Use the mouse), which is what unix/database VT-220 systems can do, still. character mode interface is highly useable.
the AJAX hype is yet another attempt to turn the browser/http into a hard-wired X-window client/server experience. active record in Rails, along with bound controls in VB (hiss, boo from the java kiddies), are too.
but, a disconnected block mode interface system will never compete with stuff that was built 15 years ago, if ease of use is the criterion.
Localization is a cop-out. Icons don't localize worth a damn, either:
For example, an icon that shows the palm of an upraised hand indicates "halt" in the United States, but signifies "here's excrement in your face" in Greece
So you have the same problem, whether you use icons or text. Actually, if you use icons only, you have an even worse problem: you need the tooltip to explain the icon and THAT has to be localized.
So it's a lose-lose scenario. Localization doesn't matter one way or the other.
Of course, it would be much faster if the text was on the buttons
I like the way IE does this; it offers a choice via the right-click menu on the toolbar: show text labels, no text labels, selective text on right. It's interesting which icons get "selective" text when you turn that on.. I suppose it's the more obscure ones.
No one has all the toolbars in Word open at once. The toolbars group related commands and this is very useful. Making a toolbar movable away from the top of the window is useful as well because I can move the toolbar closer to the object I am working on.
Pictoral icons are good idea, if done well. Have you seen the Lotus Notes icons? They suck.
Have you seen the Lotus Notes icons? They suck
Let's not go there. Really. :P
"Localization is a cop-out."
I don't think it's a cop-out at all. It's something that is becoming more and more of a consideration when developing a software product. And when designing a space-constrained toolbar, you cannot assume that words will be even close to the same length in different languages.
Just a simple, common example: I use the spanish version of Mozilla Thunderbird. Instead of "OK" buttons everywhere, there are "Acceptar" buttons everywhere. That is a length of 2 versus a length of 8.
Now go and look at that fully toolbarified Microsoft Word you have a screenshot of. Now imagine every single one of those icons with text along with the icon. Also, look at the one toolbar that primarily does have text along with icons(the New Frame Left, Right, etc). In the space that it took to have those four buttons, the toolbar two above that one has managed to fit 17 icons. It could get even worse(or better!) when localizing.
In the space that it took to have those four buttons, the toolbar two above that one has managed to fit 17 icons. It could get even worse(or better!) when localizing.
Marty, this is a constant cost. You have to localize the tooltips and help for those features no matter what you do.
"How many icons can I fit in a 160x160 grid" is NOT a user friendly way to design a UI.
We can't optimize for ease of development to the detriment of the user. It sounds like that's what you are proposing.
Totally agree. There is not an 'icon standard' who represents what the developer try to achieve when you click some graphic.
It's interesting that some have characterized icons as favouring discoverability over useability. It speaks of a fundamental misunderstanding of the benefits a GUI has to offer. (And it's a common point of view amongst those who think the industry has no finer text editor to offer than vi.)
I think toolbar icons are the exact opposite - they are about improving speed of access for expert users at the cost of higher initial learning cost.
And this is often a Good Thing.
Just as I don't want to look at uncoloured code any more, I don't want to look at a mass of undifferentiated text to represent my menu options.
In fact a set of totally abstract toolbar icons would be preferable to no icons at all. One of the reasons I prefer office-style menus with icons next to the menu items with toolbar equivalents is that I can recognize the picture I'm looking for faster than I can read the text.
It really doesn't matter what the picture looks like. Take the Build icon in Visual Studio - what the heck is that meant to be? I've never known. But I know it's the build icon. (OK, not a great example, as I always use the keyboard shortcut...unless my hand is already on the mouse. But it does illustrate that it really doesn't matter what the picture looks like as long as it's distinctive.)
I live in fear of your horrifying vision of toolbars full of nothing but plain text on a featureless gray background. ;-)
Take the Build icon in Visual Studio - what the heck is that meant to be? I've never known. But I know it's the build icon. (OK, not a great example, as I always use the keyboard shortcut...unless my hand is already on the mouse. But it does illustrate that it really doesn't matter what the picture looks like as long as it's distinctive.)
We're really agreeing here, because I didn't propose text-only UIs. Buttons with text *and* graphics work best, as in your example.
...uh...except my example is just graphics.
I see no text next to the build button. (There's a tooltip if I hover, sure, but then are you telling me there weren't tooltips on the first set of buttons you posted?)
What version of Visual Studio are you running?
Oh, sorry, I was thinking of something else. Maybe I made the conceptual leap between "mousing over the icon once and associating the tooltip with the icon" and "having the tooltip text permanently next to the icon" too quickly.
Move along. Nothing to see here, other than a sea of undifferentiated pixels.. ;)
I think the thing that stands out about the text only menu would be these points:
- Once you know the icons, it takes less than a blink to spot the one you are looking for and click it.
- No matter how familiar you are with the program, you have to read every word on the toolbar left to right until you find the same button (for the Find button, that's about 2-3 blinks).
As noted before, menus tend to only come on in context or when the user switches them on for a particular task, so for most applications they are not overwhelming. Yet, the new ribbon concept may suffer from a nasty problem - if the developer fails to estimate all the contexts correctly, will the command you need 'right now' be available?
I find the fuss all the more interesting because I am hampered by the same painful but simple usability issues multiple times a day that have remained unfixed since the Window 3.1 days: 1) the tendancy for the keyboard to spontaneously switch into overtype mode, semi-randomly and without warning, usually just by clicking on another paragraph in the document and starting to type, and 2) the insistance that the default (and sometimes only mode) of Paste is 'with formatting' despite the fact that this is almost never useful and often creates wierd formatting issues that can not be undone (paste as plain text should be default, in my view).
Am I the only one that think's the Greeks are wasting a pretty good gesture on "here's excrement in your face"? I haven't been - is the faci-al* application of feces a common practice, or even idiom?
*f a c i a l is flagged as questionable content