| |||||||||||||||||||||
| |||||||||||||||||||||
AskTog ReaderMail June, 1999
Apple Quicktime Player 4.0 a Real Dud
Dear Tog,
By now, you have seen the sporadic new UI that has shown up in QuickTime 4.0, particularly in the “QuickTime Player” application.
Not only is it an exercise in unfortunate design, it is also an indication of a disturbing trend at Apple: Top down, management driven, egotistical, user exclusive, different for the sake of being different user interface design.
And the recent success of products such as the iMac are only making matters worse. Different works!
I wonder if they have even noticed that a plastic shell to fix our round mouse design is selling so well. Even to Apple employees!
Given I still work there and haven’t quite given up, what tools might I use to fight back? I feel like everything I learned over 15 years of software development has been thrown away for sake of what someone in management thinks is “cool.” The use of reason is futile.
The only feedback upper management seems to listen to is that from our customers. Perhaps someone should lead a revolt from the outside?
Sigh, I still remember when a thoughtful process bent on doing the right thing by users thing led to innovation.
Help me, Tog. You’re my only hope.
Signed, Frustrated in Cupertino
Dear Frustrated,
I share your frustration. The round IMac mouse is the stupidest design for a product I've ever seen. About the only way you could top it would be to design a gun where the orientation of the barrel was similarly hidden.
Some people associated with the birth of the Macintosh think they can walk on water because the product eventually became successful. They "learned" that things like iterative design and users testing are immaterial, since they didn't do any and the product still sold. However, they were in denial of the facts.
The design of the Macintosh owes its success to the Lisa team, a team grounded in science and scientific methodology. The Mac team just lifted their results wholesale. That's the only reason the Mac design worked.
The folks at Isys Information Architects in their Interface Hall of Shame article have done an excellent job of reviewing the Quicktime 4.0 player, and suffice it to say that I echo almost all their comments. In two areas, however, I must disagree. I believe:
The Quicktime player does both of these things; it just does it badly. It would appear it does so either because the team failed to user-test or the ignored the result.
| The fact that you've chosen to make something look "real" doesn't mean you abandon 20 years of HCI research and the Apple Human Interface Guidelines. Nor do you need to.
The movie player has no drag region, so people don't necessarily realize they can move the player, a serious defect. However, nothing about this design precludes offering a drag region, except that no one apparently ever checked to see whether the design worked. The design has a lot of innovation, and that is OK too, but when you innovate, the need for user testing becomes critical. |
 |
In the hands of an amateur, slavish fidelity to the way a real-world artifact would act is often carried way too far. For example, in Quicktime 4.0, you cannot click on the little drag bar in the bottom center to open the "drawer" Instead, you must physically drag the bar down the screen. You cannot pass over the weird little buttons, like the one that looks like a shirt button on the right, and find out what they do. I guess since tooltips don't exist in the real world, the designers have eschewed them in their fake world. Another big mistake.
I believe that the basic approach to the new player is a valid one, and one that could be successful. The embodiment was botched, but the concept was good.
Writers need editing and designers need testing. Writers who refuse to either edit themselves or accept the opinion of others are doomed to be either very, very famous or total clods. The same holds true of desigers. If you are that one-in-a-million designer who is so good that you can serve up totally cryptic stuff and people will still beat a path to your door, then your name is Kai Krause. The rest of us need to develop a little self-discipline.
As for Apple, the Visigoths are at the door. I suspect you will see a lot more ego-driven design before things get better. I would suggest you do what I did, which was to move to a company that still prizes usability.
Tog:
In A Quiz Designed to Give You Fitts, you said: “When the icons are spread apart, users have a “buffer zone” between icons, where an incorrect acquisition will result in no action. When the targets are crowded together, however, the user has more chance to initiate an unwanted action. To avoid this possibility, non-label users learn to slow way down.”
Say, which Microsoft toolbars are you looking at, anyway? This part of your answer didn’t make sense to me and a cursory look at of the toolbars on Word97 and IE5 (on NT4) suggests that they do not have any buffer zone (or one too small to be useful). Which would seem to undermine your argument that the choice of labels vs. non-labels would affect the likelihood of users making an inadvertent selection (I agree about the performance issue, of course, as this is in accordance with Fitts’s law).
You said: “Another way to make the targets bigger, of course, is to always choose large icons, rather than small. Pity the “power-user” with the 4x4-pixel icons who thinks he’s going faster.”
Ahem, you might want to consider the viewpoint that said “power-user” might have another reason for using small icons and/or turning off the labels. Namely, they want or need to conserve that absurdly precious resource, screen real-estate! I have certainly encountered situations and users like this in my practice. I could even envision deliberately doing that in certain situations, as a conscious engineering tradeoff. (Philosophically, optimizing a UI design primarily according to Fitts’s law seems, in my opinion, a bit too narrowly focused.)
Jim Abbott
While there may be no physical buffer, there is a visual one, with a lot of white space between the objects in the toolbar. Non-programmers gravitate to the object itself, being unaware the that white space between has magical properties.
I am also well aware that our screens have too much stuff on them, be it toolbar icons or palettes or whatever. It is scandalous that we are still tied to a one-bit communications device, the mouse, with users having to find objects on the screen to indicate their desired action. Lets keep in mind that this technology was invented in the mid-1960s, and nothing much has happened since. We've rather outgrown it, and no amount of squeezing icon sizes is going to fix the problem.
-Tog
I’m working as a human user interface (HUI) designer for a company which produces custom-built computer-based training software using Java. We have a team of 4 HUI designers and an army of Java programmers. I’m trying to learn everything I can about HUI design and interaction design and have breathlessly read every word of your “Tog on Interface” book. A few days ago, I stumbled across your website and couldn’t wait to ask a question that’s been plaguing my company ever since I joined.
How do you (or anyone else) go about unambiguously documenting a HUI design that will be implemented by a separate team of programmers?
Though our HUI team has some programming experience, we’re not programmers. And we’re not just trying to document the graphic design of the software; more importantly, we’re trying to document the interaction design. We’ve tried to find books on this subject, but haven’t been able to locate any. It seems like this is a big hole in the documented HUI design process. Should the HUI team be learning UML? Or does a list of requirements and interaction sequences cut it? Why doesn’t anyone talk about this step of the process?
Any guidance you can supply would be greatly appreciated. Thanks.
Dustin Beltram
The two methods I have found useful are flowcharts and HTML prototypes. Of the two, prototypes are better. If you do flowcharts, they should not just be little boxes. Rather, mock up each page and connect it to the others with the appropriate lines and symbols. The last one I did like this, when printed out, covered a wall 12 feet long and four feet high. HTML has the advantage of often making it all the way into the product without changes, avoiding those interminable meetings with the engineer where you try to explain that the line is one pixel away from where it is supposed to be, while the engineer is looking at you bemusedly, wondering what possible difference it could make.
I asked Dustin, by the way, why they came up with human user interface (HUI) designer as a descriptive title, rather than the more common human interface or human-computer interaction, etc. Dustin pleaded ignorance, suggesting that perhaps folks wanted to leave open the possibility of creating user interfaces for other species. Then again, maybe his management has ambitions of replacing Dustin with another species.
-Tog
Linux for the second and last time
n reference to your comments about Linux, regarding the “disaster” of Linux and UNIX interfaces, I wanted to mention that I favor installing the gnuwin unix-like tools onto Windows machines. With gnuwin, you get a command-line shell and a healthy set of command-line-driven applications that make your Windows machine as UNIX-like as possible. (Note that I’m not talking about window managers and such.)
Why is this a good thing?
Because it’s better to have NO interface than a BAD interface!
(And I won’t bother ranting about why the Windows interface causes my blood to boil.)
andyhong
Even though I explicitly told those Linux people not to respond to my diatribe about Linux's plethora of interfaces, they did anyway. And you know why? Because they are a bunch of fanatics!
I like fanatics. And I like just about everything about Linux, with the single exception of its multiplicity of interfaces. I like that it is a result of a collaboration of love. I like that it works, and works well. I like that it is small and fast. I like that it is giving the Unix community a good swift kick in the pants. I like that it is freaking out Microsoft.
My experience in trying to change the Unix community, so they would realized the value of a single, consistent human interface is that it is similar to trying to get a bunch of fish to realize the value of a good pair of running shoes. It is so far out of their range of experience as to be meaningless. Linux is the son of Unix, and it's children are fish.
Fortunately, it doesn't matter to any great degree, because few real humans ever come in contact with either Linux or Unix. If those writing server systems want to use an interface from hell, far be it from me to stop them. And I agree with andy. A well designed command-line interface is better than a poor window interface. Or two poor window interfaces. Or three poor window interfaces.
See David Eisenberg's Comment of the Fortnight for further Linux insights.
Excel as a precedent for new designs
I am designing the next generation grade book application ( which is similar to a spreadsheet type application ), using Java/Swing. Our current grade book, Grade Machine, has about a million user base in the public schools around the country.
Two questions:
1) GENERAL: I am constantly told to refer to Microsoft Excel whenever questions of how the UI should behave. Can you give me an overall opinion of how you would rate the UI of Excel?
2) SPECIFICALLY: When you select a cell in Excel you are both selecting it and opening it for editing; i.e., the first character you type replaces all the current contents of the cell. To us programmers, this is known as one-click editing. The question is, when you click on the cell should all the text be hi-lited, or, as Excel does it, should just the selection rectangle appear?
>
---
Baiss E. Magnusson
Misty City Software
I would rate the UI of Excel as adequate. The importance of following its precedent, however, arises from its popularity, rather than its quality. If your user base does not particularly overlap with Excel’s, I see no reason you should be bound by the precedent. On the other hand, if even 15% or 20% of your users have already learned Excel, I would hesitate to change anything that would tend to confuse those users. Specifically, I would ensure that all the learned behaviors, such as the meaning of shortcut keys, etc., be faithfully reproduced.
The answer to question 2 can only be fairly discovered by user testing. Certainly, offering greater user feedback than Excel would not confuse Excel users, so that shouldn't affect the application. However, if people “get it” with more subtle feedback, I would tend to go with the more subtle feedback. If user testing, however, shows that, for example, people can learn the software quicker and easier with more dramatic feedback, then I would go with that.
Typically, I like to start off with subtle feedback, and augment it where user-testing shows it to be necessary. The problem with starting the other way is that non-subtle feedback almost always works in terms of the user catching on to what is happening. However, when you “shout out” all your feedback, you have nothing left to offer when “loud” feedback is really needed.
Political Activism Opportunity
Tog,
David Weinberger, Doc Searls, Chris “Rageboy” Locke and I have launched a site at http://www.cluetrain.com we hope will start a kickass conversation about a sea change we see coming as markets get even more internet-worked, employees get even more intra-networked—and most businesses continue trying to keep them apart.Best,
Rick Levine
Hi, Rick,
I agree with the sentiment of your site (and love the photo, although I doubt we'll be seeing any disclaimers that no animal was harmed in the making of this website), but I seriously question the outcome. I believe government and the corporations will continue their rapid fencing in of the www range until only the congnicenti will be able to move about without immediately tripping through the front door of a Starbuck’s approved cyberspace strip mall.
One only has to look at the growing mass of small retailers who dared to discount on the web and are now having their franchises pulled to “protect the brand image,” all with the concurrence of the US Supreme Court, to see how the endgame will play itself out.
Those who are not as jaded as I may want to check out this site. Activism has and will continue to work. It will be a crying shame if the web ends up being just another corporate shopping center.
When we use Windows’ GUI we open different windows all the time by various ways. But if wouldn’t close them, there will be too much windows so we simply couldn’t work at all. So we have to close windows - it’s probably most frequent operation. I don’t know how it works on Mac, but in Windows and Unix systems everybody uses that “Close” button on the title bar. This button may look different, but the meaning is the same: I think it’s VERY HARD to aim on it because:
- it’s very small.
- there may be other buttons (min,max) beside it.
- sometimes there are two or even three same “close” buttons from other windows behind it.
I have thinking about this problem for a long, but now I still don’t see the more convenient decision. I’ve heard that in your Starfire project to close window you should snap it on the screen with your finger. I think it’s good idea in the future, but in present days there appears no way to solve this problem.
With great respect,
Andrew Sedelnikov,
Russia, Tomsk,
Application programmer
I experience this same problem on Windows, but not on Mac. Some of it is easy to explain, since on the Macintosh, we cleverly put the close box far away from all other controls, since we figured that otherwise there would be trouble. On the Mac, also, disabled windows look disabled, with the close box and other title bar ornaments hidden from view. (You don't end up with 47 different menu bars on the Mac, either, so people don't have the tendency to try to control window A from window Q.)
More could be done, particularly in a 24-bit display world. In the real world, items further away from us are dimmer. Reducing the contrast of semi-hidden windows would sharply increase people's awareness of what windows were active.
Should you present links embedded in the text (a la Jakob Nielsen's www.useit.com), or on a sidebar (as you do in AskTog). I personally prefer links separate, for various reasons:
- It doesn’t invite people to leave your site, until they have absorbed everything you want to say
- One can provide better visual clues, in a cleaner way (other than simply changing the text color, or putting a colored border around an image)
- It is much easier to (semi) automatically process text and links separately
- One can establish a spatial reference, in the sense of having a place where the user knows he’ll always find the links (e.g., left sidebar)
Cheers,
Daniel
Daniel, I could not possible agree with you more. I think this is the key to AskTog's tremendous superiority over that UseIt thing of Jakob's (along with my rich use of graphics, of course).
Seriously, though, Jakob's method results in a stronger sense of immediacy. UseIt feels more like a daily newspaper, whereas AskTog has more of the staid quality of a monthly magazine.
Jakob's method is also faster for the author, an important element when maintaining a pro bono website. Jakob has not "burned out," whereas others have and more will follow.
All that said, for a site which is at least intended to show a profit, I prefer to find all referenced links at the end or beside the article, just so I don't feel so tempted to "leave town" right in the middle of an important thought.
As AskTog drifts further and further from profitability (the last person to buy a book through the AskTog Amazon Discount Link died of old age three years ago), you may well begin to see web links right in the middle of a sentence. Not now, of course, but eventually.
-Tog
Why do web-browsers crash?
For example, even simple (and probably very familar to you) HTML like:
<BODY BACKGROUND=”http://www.asktog.com/images/linbkg.jpg”>
is enough to crash IBM’s WebExplorer browser for OS/2.
Heck, even HTML like: <IMG SRC=”http://www.asktog.com/images/linbkg.jpg”> will do it -- there’s nothing “special” about the URL being part of a <BODY> tag.
Maybe, just the presence of strings like ‘JFIF’ or ‘Photoshop 3.0 8BIM’ or ‘File written by Adobe Photoshop’ is enough to “scare” the browser?
Who knows?
Melvin Klassen
Web browsers, along with every other kind of software, crash because that's the way we demand they be. Yes, they are poorly coded and poorly tested, but they are that way because all of us decided long ago that having the latest and greatest was far more important than quality.
The problem starts with the computer press, which routinely praises the most egregiously bad software as an immediate must-have. Then we early-adoptors get hold of it and, after rebuilding our hard disks which version 1.0 immediately and irreparably destroyed, tell everyone how wonderful it is.
The manufacturers of this dreck, for their part, simply declare everything "as-is" and have us attest to having read those endless disclaimers that essentially say, "I am a giant drooling idiot for using this crap you have foisted off on me and deserve everything that is about to happen to me, my family, and my immediate surroundings."
Until there is some legal liability to selling pre-alpha software as released products, we will continue to be offered pre-alpha software. And before we rush into passing laws, consider this: Things are still advancing so fast that really bad pre-alpha software may still be better than would last year's hot software, even if it were really cleaned up. On the other hand, it would be nice if we could at least move up to pre-beta.
If you think that people are not doing the best they can, however, check out this next letter from one of those nice folks at Microsoft. (Yes, I know, they were formally evil folks at Microsoft. But that was before Microsoft bought a large percentage of my employer, Healtheon.)
-Tog
Frustrations of a browser designer
Tog,
Today marks the third time someone has forwarded your column “The Sorry state of Web design” to me and I figured it was time for a response. I’m one of the UI designers on the Windows version of Internet Explorer. This article was great and I share many of your frustrations. Despite the current state of the web world, we have been trying to make things better.
Regarding web pages and content authors: They really are not given much direction by anyone. There are only a few predefined widgets and with the power of JavaScript authors are free to manipulate them in all kinds of strange ways. For the Mac and to some degree for Windows, there was a center of gravity for how to do things right. The web lacks one. There are dozens of books that given some direction, but it’s a fragmented mess of guidance. Most authoring tools do not provide preset widgets to reuse, and if they did, they’d all be different anyway since there is no documented standard for the vendors to refer to. The dev tools could help create consistency by making it easier to create default widgets, but without a guideline to aspire to there’s little motivation. Your points about training are right on - but at the same time, it’s also the low entry cost to publishing. It’s still relatively easy to create a web site—you don’t have to learn much before you can publish something. This is great and horrible at the same time. For Mac and Windows the dev entry costs were higher, so you had to learn a few things before you shipped anything.
In specific: Your suggestion for setting link colors is a good one - but HTML + javascript allows site authors to set their own colors and many of them do. The most painful aspect of this is when they set the visited link color to be the same value as the unvisited link color - you lose the breadcrumbs of which pages you visited. I see this with increasing frequency. Not sure why. We could enforce something in the browser, but we run some risks there. There is a constant tension with web site designers about who defines the user experience - it’s hard to take away flexibility that has already been granted to a developer. There is also a general reluctance for web developers to look to the Mac or Windows and learn from what was done there.
It’s also hard to get adoption of new features that require reauthoring, or for investing time into something that’s tied to a browser that only a fraction of their user’s use. At one point we tried to create a new standard that would allow web sites to indicate to the browser how documents were related to each other, so that we could do something smarter with their representations - I called them web collections (http://www.w3.org/TR/NOTE-XMLsubmit.html.) However, this died for several reasons during the W3C standards process, and it would have required authors and tools vendor to do work to support it. Early in the development of IE4 we supported a simple version of this, but cut the feature before final release for a variety of reasons. (You can see some simple pictures at http://www.microsoft.com/MIND/1196/PREVIEW1196.HTM.)
Regarding web browsers: In IE4 we introduced a feature called the history bar, designed to help users return to specific pages, but also to provide a single UI element that shows the entire trail the user has visited. We did our best to improve navigation without requiring any reauthoring of sites. Since the bar can remain on the screen while you browse, it can help reduce the navigation complexity presented by the different UIs of different sites. You can see a picture of the IE4 version at http://www.microsoft.com/windows/Ie/Features/history.asp In IE5 B2 we’ve added the ability to sort the view in different ways, as well as search the contents and titles of pages. The feature has documented usability wins, but sites can spoil them by poorly titling their pages. The Mac version has this feature, but the Windows version is a bit more robust.
I started working on a set of simple web site guidelines for web designers - there are many good ones out there, but I thought that one from the IE team or from Microsoft might provide some kind of grounding force between the multitude of different ones, or help force a better one to surface. But the further along this got the more I recognized that this was just one part of the problem. Convincing tool vendors, and the authors themselves that this stuff is important seems more critical. So this fell down my stack of useful things to do that aren’t a direct part of the product.
I’m sure you have ideas for how to make things better - I’d love to hear them if you’re willing to share. But I just thought I’d drop a line and let you know that we have been trying.
-ScottScott Berkun
UI Program Manager
Internet Explorer
Microsoft
Scott mentioned that he is seeing with increasing frequency authors turning off the browser's ability to display new and visited links in contrasting colors. This has happened because the standards setters and site development tool providers have violated one of the most fundamental principles of tool design:
Using style sheets, it is trivial for the rankest amateur to turn all links into the same color (as I was informed several months ago by several creative readers who sent me complaints about my site wrapped around pipe bombs). It is extremely difficult, in fact, in many of these style sheet tools to avoid turning all links into the same color.
Web browsers and the standards behind them are still amazingly crude, but perhaps the greatest need right now is for tools that help designers supply navigation support to the end users. The amateurs that make up the 99+% of site builders need the "canned expertise" that only professionals can supply. They need bread-crumb generators, table-of-contents builders, link indicators, and a wide variety of other tools that need to be easy to use and standard.
Thanks, Scott, for a particularly thoughtful letter.
-Tog
|
|
Don't miss the next action-packed column! Receive a brief notice when new columns are posted by sending a blank email to asktoglist-subscribe@yahoogroups.com. |
 |
| Contact Us: Bruce Tognazzini Copyright Bruce Tognazzini. All Rights Reserved |
