Sometimes a Word is Worth a Thousand Icons

Pop quiz, hotshot. What do these toolbar icons do-- and what application are they from?


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/02/sometimes-a-word-is-worth-a-thousand-icons.html

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.

|

and

|

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 :slight_smile: Windows with more than 10 yrs of development and research still confuses people !

My 2 cents
bye
Ketan

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!

Peter

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

Exactly!

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. :stuck_out_tongue:

“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. :wink: