Slashdot Mirror

It goes back to before there were any demos, as far as I know. It goes back to the 80's, to research done by Bill Buxton (whose overview of multitouch history is very informative). In fact, it may even go back further to 1982, according to "Tog" (see the section on "Multi-Touch Interface History"). So, there's no way Apple could have any (legitimate) patents on this particular gesture.

Some others have suggested that these patents wouldn't be a big deal, as one could always use different gestures. The problems with this suggestion is that not all gestures are equal. Some are more natural than others. The pinch gesture, for example, is as natural as it gets: it's merely a logical extension of dragging, as what you're really doing is just dragging two points with two fingers. It doesn't feel like a "gesture", but simple direct manipulation. Look at how successful this gesture has been. It may even have been invented several times independently. I, for one, would not give up the "pinch". Thankfully, Apple has no legal ground to stand on with respect to that gesture.

To some extent, things this was also a communications problem. Edward Tufte has analyzed the Challenger and Columbia disasters and concluded that they largely occurred because critical information became obfuscated as it moved up the decision tree. Take a look at his analysis of the Columbia disaster:

http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001yB&topic_id=1&topic=Ask+E.T.

Challenger has similar issues. I can't find a direct cite for it but this page:

http://www.asktog.com/books/challengerExerpt.html

does an OK job of excerpting the ideas.

int things_done = 0;
char* p = NULL;
for (;;) {
*p = malloc (BUFSIZE);
if (p) {
if (do_something (p)) ++things_done;
}
if (p) free (p);
/* invariant false HERE only */
p = NULL;
}

At every execution point, you can write the invariant that either p is NULL, or p contains a valid pointer from malloc(). *Except* exactly the one point in the code flow where the next statement serves the purpose of re-establishing that simple invariant.

If p fails to malloc() I don't bother to create an error pathway. I just use it as a guard against the code that follows. Do nothing is cheap. You'll fall through to the bottom in no time. At the bottom, test whether the routine accomplished its tasks.

Fewer error pathways, simpler invariants. You get what you pay for. Avoid side effects, and always always always handle zeros and empty structures correctly.

By the time you get to this point in your coding evolution, you'll be wanting to write your statements in functional map/reduce form, because that is all that remains to express, now that the code is reduced to its Dijkstra essentials.

An accessible surface form matters most for code that is either badly specified or badly commented, forcing you to read the code to determine the code's intended purpose. Reverse engineering purpose from the code itself is not a higher zen-fu coding practice.

Accessible surface form becomes a minor concern if you are reading code to determine whether the code correctly implements a specification you already comprehend.

Migrating between PHP and Ruby, it's the difference in surface form you must first surmount. Sometimes the immediacy of a challenge is confused with the magnitude of the challenge. We tend to overestimate comfort and underestimate utility.

http://www.asktog.com/SunWorldColumns/S02KeyboardVMouse3.html

Consider, though, the primary goal of making people more productive. How can someone spending twice as long at a given task be more productive? They can't, particularly when one considers the reason the subjective time seems so short: the intensity of the user's total mental engagement in performing the manipulation. Under such circumstances, the user must set aside the original task of writing or editing a document in favor of figuring out what key to press and how many times to press it. While the mouse users are dragging and pressing a

Donald Norman Design of Everyday Things (ISBN-13: 978-0385267748) He will get you thinking about the implications of your interface design; this classic may be hard to find but he has other books out as well. While his examples focus on mechanical objects the thought process and criticisms provide insights into how to think about the end user in your design and avoid become someone "Who won an award" for their design. Once you read teh book you'll get what I mean. http://www.jnd.org/

Bruce Tognazzini Tog on Interface (ISBN-13: 978-0201608427) A bit dated but the concepts and idaeas are what matters. He has a website as well as other books. http://www.asktog.com/

Finally, there are classics by Edwin Tufte you may want to checkout as well. He focuses on displaying information (mostly quantitative) in a manner to support understanding; and hates PowerPoint type presentations with a passion. Tufte has a website as well. http://www.edwardtufte.com/ His one day course ie excellant.

My favorite expert on UI is Bruce Tognazzini. His site at http://www.asktog.com/ has been quite useful to me. I don't agree with everything he says, but it's always gets me thinking, always challenging me to approach development from a human perspective.

I've heard (and from my experiences I think is true) that people who are good at development are not necessarily the best for design, and vice versus. There's always exceptions, and I'm sure some on this site will say that they can do both well. If I was independently writing a software (for the general population) I'd want someone to do the UI, because my mind doesn't work that way.

Besides making UIs that look 'pretty' these are ideas that I've been pointed to in classes here and here. They are useful for both developers and designers of GUIs.

http://www.asktog.com/columns/000maxscrns.html

It's not logical at all. Why should moving one folder delete an existing one?

As for the warnings etc, how many users actually read those warning pop-ups? And if they do read them do you reckon they'd understand exactly what was meant?

Mac's are usually pretty good for usability. I'm surprised they'd make such glaring errors, such as not protecting a User's work, not letting them undo, and having strange behaviour which is difficult to learn on the basic file-system interface, which in theory any user should be able to figure out how to operate on the first go.

See: http://www.asktog.com/basics/firstPrinciples.html for more info on usability.

With large monitors growing ever more affordable, there's sure to be a lot more people who start noticing the menu bar silliness.

I think you're missing the reason why the menu bar on the Mac is where it is, namely Fitt's law:

http://en.wikipedia.org/wiki/Fitts'_law

http://www.asktog.com/columns/022DesignedToGiveFitts.html

The menu bar on top of the screen is faster, despite being further away from the curser than the menu bar on top of the window.

semantical difference--'infinite' in this context means the far edge of the target, ie. the window/screen, so that when you 'throw' your mouse at it, it can only go so far. therefore, the idea of the 'distance to center' is a misnomer, imo. perhaps I didn't read closely enough?

I'm surprised nobody's mentioned Bruce Tognazzini in this post, the orginal Apple Human Interface guru, and popularizer of Fitts' Law in the UI world: A Quiz Designed to Give You Fitts

In some ways it reminds me of a trackpad. Very cool looking and futuristic (back when they were first introduced) until you try to use it for anything, at which point it becomes a burden which slows down and degrades the accuracy of all of your pointing and selection operations.

Besides, once I get to eliminate my desk, end table, couch, and bed, where should I put my keyboard - or will they come up with a 60wpm on-screen soap-mouse-pick keyboard?

Slow news day? More like OLD news day. My first thought was--what the fuck is this, early 2001? OS X has been out for SIX FUCKING YEARS--who cares that some douchebag just now spent 30 days with it?

The use of, benefits of, and shortcomings of Mac OS X have been thoroughly documented on a thousand* different sites. It's not like it's even a new version--10.4 has been out for TWO EFFING YEARS!!! Where has this retard been? (Reminds me of the NewsRadio episode when Bill discovered rap.)

Up next: 30 days spent breathing air and drinking water--a Hard OCP exclusive!

* the funny thing is, "thousand"--usually an exaggeration--is in this case a drastic understatement. Googling for 'os x review' yields 67,400,000 matches. Just in case anyone has been under a rock and wants to read some good reviews by smart people, here are a couple:
Review of 10.3 by Bruce Tognazzini, Apple employee #66
Detailed technical review of 10.4 from ars.tecnica with links to reviews of every version of OS X, ever
Typical review from a Mac site
Review of 10.4 from PC World

Also, this Sun video from 1992 - http://www.asktog.com/starfire/index.html - had most or all of the concepts as in the Microsoft video, but with extra cheesy flavor. It is 15 years old though, so maybe they deserve a bit of slack.

MS spends millions on usability testing, are we all to be so stupid to conclude that their research in this area is not somewhat valid?

When I specified the Mac hierarchical menu algorthm, I called for a V-shaped buffer zone, so that users could make an increasingly-greater error as they neared the hierarchical without fear of jumping to an unwanted menu. As long as they are moving a few pixels over for every one down, on average, the menu stays open. Apple hierarchicals are still far less efficient than single level menus, but at least they are less challenging than the average video game.

The Windows folks instead leave the hierarchical open for around a half-second before jumping down. Thus, as in so many of the other areas of their OS, they mimic the Mac without getting it right. They have decoupled cause and effect by 1/2 second, a long, long time in human-computer interaction. If you happen to get to the hierarchical within that half-second, the Windows behavior is indistinguishable from the Mac. If you don't, the behavior is just weird and few users can figure the rule out.

MS spends millions on usability testing, are we all to be so stupid to conclude that their research in this area is not somewhat valid?

When I specified the Mac hierarchical menu algorthm, I called for a V-shaped buffer zone, so that users could make an increasingly-greater error as they neared the hierarchical without fear of jumping to an unwanted menu. As long as they are moving a few pixels over for every one down, on average, the menu stays open. Apple hierarchicals are still far less efficient than single level menus, but at least they are less challenging than the average video game.

The Windows folks instead leave the hierarchical open for around a half-second before jumping down. Thus, as in so many of the other areas of their OS, they mimic the Mac without getting it right. They have decoupled cause and effect by 1/2 second, a long, long time in human-computer interaction. If you happen to get to the hierarchical within that half-second, the Windows behavior is indistinguishable from the Mac. If you don't, the behavior is just weird and few users can figure the rule out.

"OS X does not ignore the last two decades worth of human/computer interaction research."

Actually they have.
See
http://www.asktog.com/columns/044top10docksucks.ht ml
http://www.macworld.com/news/2005/12/21/services/i ndex.php

Not, of course, that the pinch interface is new either. Is there anything in the iPhone that is new, or is it just Apple doing what they do best—combining a whole lot of great but pre-existing ideas, well, into a single unified package?

Tog's research is only part of the answer. When he's not sharing his insane conspiracy theories about traffic engineers, Tog tends to ignore parts of the problem that are inconvienent to his theories. In particular he tends to ignore expert users. If you're doing the same thing over and over again it ceases to be aboue spending "two seconds to decide upon which special-function key to press," it's muscle memory. Ever watch someone do bulk data entry on a mouse-less terminal? Once you learn to tab between fields it's extremely efficient. No moving your hands to mouse, locating the mouse pointer, and clicking on the next field. Type field, tab, type field, tab, type field, enter to submit. Conversely, whenever I've seen people use Tog's precious mouse in such interfaces I'm subjected to lots and lots of waiting while they type in a field, grab the mouse, locate the mouse pointer, click the next field, and move back to the keyboard.

The same goes for Ctrl+S. For Joe Random User who doesn't use a given piece of software very often, yes, shortcuts are indeed slower than mouse and menu. But for someware you use heavily and commands you use frequently it's faster. It's faster because Tog's core claim: that you're spending two seconds remembering what shortcut to use, is nonsense. You start thinking "I was to save" and before the thought is fully formed you've mashed Ctrl+S and gone on to the next task. Even with Tog's pet-UI designs like sticking menus at the top of the screen you've got to move to the mouse, slam it to the top, more carefully adjust it left and right to the menu you need, and carefully drag down to the specific item you want. Assuming you commit such a finicky procedure to muscle memory it's not possible to make it as fast.

If you've got good software and spend a lot of time using it, it should eventually become second nature; you move beyond thinking about which command you want for 90% of what you do.

If you can find them, watch someone really skilled at data entry whiz through form submission without a mouse. Check out a programmer really in touch with his editor of choice. I knew a man who knew Visual Studio's interface so well that he flew through it faster than I could have decided which menu I wanted.

Because they're faster. Just like it's faster to use Control+S to save a document than it is to use the mouse to open the file menu, position the pointer over the save entry and press the button.

http://www.asktog.com/TOI/toi06KeyboardVMouse1.htm l

We've done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

        * Test subjects consistently report that keyboarding is faster than mousing.
        * The stopwatch consistently proves mousing is faster than keyboarding.

This contradiction between user-experience and reality apparently forms the basis for many user/developers' belief that the keyboard is faster.

Some resources:
Apple's User Interface Guidelines; adapted from the NeXT/OpenStep Interface Guidelines (PDF).

There's also the Classic "Macintosh Human Interface Guidelines" for System 1 through OS 9 (have to hunt it down yourself), GNOME's HIG,KDE's, and Tog's.

Without reading through them all, I can't point out where they address BPs for reuse, management, etc., but I know it is touched on somewhat (although from a NeXT slant) in Apple and NeXT's guidelines.

I'm sick of hearing about how maximised windows are stupid and useless, and how I just don't understand.

On the other hand, having a 23" HD format monitor now makes me question Fitt's Law, which breaks down when the menu is waaay over there.

Me no understand.

Fitt's Law:

The time to acquire a target is a function of the distance to and size of the target.

Surely this explicitly takes into account the menu bar being waaay over there? Or have I misunderstood?

Fitts' law indicates that the most quickly accessed targets on any computer display are the four corners of the screen, because of their pinning action, and yet, for years, they seemed to be avoided at all costs by designers.

Use the pinning actions of the sides, bottom, top, and corners of your display: A single-row toolbar with tool icons that "bleed" into the edges of the display will be many times faster than a double row of icons with a carefully-applied one-pixel non-clickable edge between the tools and the side of the display.

When I saw a user with all of their windows maximized, I used to think that they were probably a novice user (or perpetual novice). Most non-technical folks do it this way.

Recently, I re-evaluated that opinion when I saw a developer using Eclipse maximized. His 17" monitor was clearly not usable with an application that had so many plugin panes simply because he didn't have room for anything else on his monitor if he wanted to size the window so that he could have all of the required views on the screen at the same time. I think that the maximized windows anti-pattern has more to do with the limitations of display size rather than because people are too stupid to do it the 'proper' way. In fact, I'd say, that the decision to maximize in a limited display is a sign that they're not so dumb after all.

However, on a large monitor, it is my opinion that mazimizing windows is a true anti-pattern because the benefits of drag and drop and multiple application interactions go away when you can only see one at a time. Most of these developers don't even know that, frequently, the easiest way to change directory in a CLI is to type 'cd ' and then drag a directory from the file browser to the terminal window. There are lots of similar GUI patterns that make working on a computer much easier.

Unfortunately, these things are often thought of as 'tricks' because the OS's have downplayed their use since users didn't seem to be using them. Most computer use is menu and wizard driven and there are very few applications that use a true OOUI.

It's one of those bizarre situations where the design was ahead of it's time and the lack of use of the features fed back to the designers who dropped the advanced features just before the technology caught up to the point where these advanced features would have actually been useful. I guess it doesn't matter that much because most users have been so heavily trained to use copy-paste and other broken metaphors instead of drag-and-drop and gestures, so that even though it may now make sense to use drag-and-drop more, nobody will bother because they're used to the old way.

It sort of reminds me of how an inferior technology like the old Palm torpedoed the prematurely advanced and poorly marketed Newton. Now we have to live with a bad paradigm.

On the other hand, having a 23" HD format monitor now makes me question Fitt's Law, which breaks down when the menu is waaay over there.

Same for airplanes. A modern Boeing airliner is far more complex than GNOME but jets don't fall from the sky on a daily basis.

A little off topic, but planes are a good example of how something can be technically fault free but still suck - even fatally. Take fuel tank selector valves. It's extremely unlikely that a valve will fail, but that's not the point. A pilot shouldn't have to monitor which tank fuel's coming from and switch tanks mid flight. Fuel should just be drawn evenly from all available tanks whilst keeping the plane in balance. Some planes do this, but an amazing number don't. In all probability, it was a counter intuative fuel tank selector that killed John Denver.

So making software (or any human-machine interface) fault free isn't enough. It has to be intuative, and it should take care of some things automatically when it make sense to do so. That's hard to do right.

I remember when my Mac-fan friends defended the use of brushed metal for some apps ("Supposed to evoke a hardware device," etc) and plain for others. Then out came GarageBand with its wooden interface, and all the other interfaces Apple introduces on a whim, and all you can do is commiserate with Tog.

Question 5

Explain why a Macintosh pull-down menu can be accessed at least five times faster than a typical Windows pull-down menu. For extra credit, suggest at least two reasons why Microsoft made such an apparently stupid decision.

Microsoft, Sun, and others have made the decision to mount the menu bar on the window, rather than at the top of the display, as Apple did. They made this decision for at least two reasons:

Apple claimed copyright and patent rights on the Apple menu bar
Everyone else assumed that moving the menu bar closer to the user, by putting it at the top of the window, would speed things up.
Phalanxes of lawyers have discussed point 1. Let's deal with point two. The Apple menu bar is a lot faster than menu bars in windows. Why? Because, since the menu bar lies on a screen edge, it has an infinite height. As a result, Mac users can just throw their mice toward the top of the screen with the assurance that it will never penetrate and disappear.

Unless, of course, I'm testing them at the time. I did a test at Apple where I mounted one monitor on top of another, with the menu bar at the top of the lower display. The only way the user could get to the top monitor way by passing through the menu bar enroute.

I then gave users the task of repeatedly accessing menu bar items. When they first started out, they penetrated into the upper screen by around nine inches on average, just because their mouse velocity was so high. Then they learned they had to slow down and really aim for the menu. By the time they adjusted, their menu-access times became so ponderously slow, they took around the same time as the average Windows user.

The other "advantage" usually ascribed to a menu bar at the top of each window is that they user always knows where to look for the items pertaining to the task they are carrying out. This is silly. Users may do various tasks within a given window, and the menu items may change. Not only that, but a great many perverse applications exist, particularly in the Sun world, where the menu bar you need to access is not even in the window in which you are working! That is truly bizarre and mind-bending.

Microsoft applications are beginning to offer the possibility, in full-screen mode, of a menu bar at the top of the display. Try this out in Word or Excel. It is much faster. Microsofts general cluelessness has never been so amply displayed, however, as it is in Microsoft Visual Studio, which has a menu bar at the top of the screen with a one-pixel barrier between the screentop and the menu. Talk about snatching defeat from the jaws of victory.

There is not much to see here, no.

The mockups were made by fans of Apple, and Apple fans love flashy new features Features FEATURES! That is what you can find in these mockups.

If you are looking for good UI design, look elsewhere.

Anyone looking to improve MacOS X should look here first: http://www.asktog.com/ .

Apple interfaces are successful not because of customization. In fact, you're usually stuck with what they give you. However, they clearly put a lot of thought into usability. Those interfaces work because they're clean. I don't necessarily like the visual style, but I appreciate the simplicity.

Yeah, Apple's UI is wonderful, isn't it?

So intuitive. So clean and simple.

Let's be honest with ourselves here. Apple's UI sucks. It just sucks less than anybody else's; like democracy, it's the least worst idea anyone's come up with. But that doesn't make it perfect.

If the user interface is designed well, you'll know exactly what to do, just as you'll know intuitively how to really redact text.

If you're asking me to tell you how such a properly designed UI will work, you're asking the wrong person. It'd be interesting to get someone like Bruce Tognazzini to give their take on it. Right now, all we can be fairly sure of is that the UI isn't working because people are constantly choosing the wrong tool for the job.

Apple worked on things like piles in the early '90s.

right right right: The Challenger: An Information Disaster

Tog on Interface and Tog on Software Design.

Tog on Interface and Tog on Software Design.

Regarding mouse vs. keyboard efficiency: http://www.asktog.com/TOI/toi06KeyboardVMouse1.htm l is a good starting point on the mouse-speed vs keyboard-speed debate. I cringe every time I have to ^C ^V, and Tog advocates it, but the material on perceived vs real speed is worth looking at.

If you're editing over a remote link, it really depends how limited you are in the protocols you can use. If you've only got telnet/ssh, you're probably screwed. If, however, you can run something on the other end, then you've got a world of opportunity, as this (remote access) is the kind of thing that plan 9 and inferno excel at. Using a straight telnet/ssh link these days makes me feel like I've got one arm tied behind my back.

For using acme remotely, the best option is to run something, for example u9fs to export the files you wish to edit, then import the filesystem, whereupon you can use acme to edit the files in it. It's also possible to run acme remotely, (by using inferno or drawterm and making a cpu connection), but the graphics speed will then be predicated on the speed of your connection, which can make this unrealistic.

Well of course it all comes down to what you mean by usability. Of course OS X is vastly superior under the hood. But I'm talking interfaces here, and the interface just isn't as good.

Tog has a bit to say on this, and I agree with him on most of it. And that's Panther (10.3), remember OSX starts with Cheetah(10.0). Cheetah was an absolute disaster from a UI design point of view, and while it's been improving with each release, (and Tog updates without seeming to leave the previous articles available, or I'd point you to the Jaguar articles as well - some things have improved, but many are still the same) it's still far from the level of simple, consistent UI design that OS9 had. OS 10 was NeXT, of course, and the NeXT interface was quite good, but in the process of making it *look* prettier they really managed to screw a lot of stuff up.

The dock is an absolute trainwreck, so much so that instead of discussing it in that article he just links to another. And he's right. While the NeXT dock did basically one thing, and quite well, so many additional functions were added to the dock for OS 10 that really became overloaded and practically unusable for any of them. And Apple has this annoying patronising tendency that expressed itself in this case by them locking out the sort of customisability that could have otherwise mitigated this. Finder is extremely annoying. The biggest problem, for me, is the way it absolutely insists on throwing up a spinning beach ball for 30 seconds EVERY time I come across a video file that quicktime doesn't understand and absolutely refuses to let you disable the previews to prevent that. You can set them not visible, but it still insists on calculating them anyhow.

I could go on and on, but reading Tog will save a lot of space here. OS 9 really was a lot better from a UI design standpoint. Unfortunately it didn't have the underpinnings necessary for serious usage either. But OS 10 would have been a lot better if they'd simply duplicated the OS 9 GUI, or left the old NeXT GUI alone, IMOP.

Why do I need to know whether it's JPEG encoded or TIFF encoded? Why can't it just be a picture?

It sounds like they're trying to recognize Sun's vision of the future. Put simply, every display is interactive and data can be transitioned from the realm of paper to bits simply by laying pages directly on the display for a few seconds. It's the kinda thing that probably won't work as advertised initially but could open the door to a really, really kickass interface.

so he doesn't realise that software is supposed to be obtuse to learn, frustrating to maintain

Well, he most have used the OSX dock.
http://www.asktog.com/columns/044top10docksucks.ht ml

http://www.asktog.com/Bughouse/10MostWantedDesignB ugs.html

Agree 100%. Also the dock is an absolute useability nightmare.

Not only that, but I personally hate the look and feel of Aqua. It's way too bubbly and distracting for me.

I actually prefer KDE with Plastik to Aqua.

In fact, the inability to natively change the theme in OSX is what keeps me *off* of Macs.

More to the point, the engineers just weren't capable of expressing their concerns in a way that made sense to managers. The managers weren't stupid. They lacked domain knowledge and the engineers couldn't express what they knew in a way that made sense. When they tried charts, they made it worse.

  See Tufte's graphs:

badly excepted here: http://www.asktog.com/books/challengerExerpt.html

reviewed here http://www.statview.com/support/techsup/faq/Tufte/ tufte.shtml

When will interface designers learn that it's faster if you don't have to take your hands off the keyboard every three seconds?

Actually, there are a large number of studies that say the opposite is generally true, even for expert users who know the keystroke commands from memory (indeed, one could argue that the letter and symbol keys on a keyboard are all examples of this). The time 'saved' by keeping your hands on the home row is more than wasted by the time that it takes to recall a key-combination. It doesn't seem that way because you are actively thinking about the command, so your time sense is focused on the activity, whereas the time spent mousing around is more or less 'blank time', since the hand-eye coordination needed to match the pointer to the pointed item is more or less 'handled in hardware' once the decision of which command to use is made.

Naturally, there are several cases where keyboard commands are faster than menus, however. One is when there is a very common operation which has a permanently assigned action key, with no key-combos. Another is in the case of an expert user entering a complex, multi-operation command line, versus having to gesture the same actions; however, a case such as that is generally complex enough that the real optimal solution is to create a script of the command, even for a single use instance (some systems, such as Oberon, facilitate this by allowing you to invoke any arbitrary selected text as a script - indeed, in Oberon a menu item is nothing more than a section of text that is pinned to a given location and 'pre-selected' so that it activates on a single click). Third, multi-level menus require the user to select and target successive items, which is the same cause of slow-down in keystroke commands. Fourth, there are many cases of poorly considered 'graphical' tools that require multiple passes to home in on the target (Raskin's example of a 'visual thermometer' that requires you to adjust the height of the 'mercury' column versus simply entering the degrees into a textbox, comes to mind). Finally, 'adaptive' menus are invariably worse than keystrokes, because the changes disrupt the pattern of actions. In each of these last three cases, the reason the mouse is slower is because the layout of the UI stymies the ability of the user to habituate to them, making it a matter of design rather than a flaw with pointing devices themselves.

Ironically enough, given all the 'quick bars' around in certain systems, the worst response time in most cases is for using icons. The problem is that you have to associate the icon with not only the image it represents, but also the action it causes, and the connection between them is not always as obvious to a user as it was to the developers. The difficulty increases rapidly with the number if icons on the screen, especially if there are two or more similar icon images that need to be differentiated. Many design theorists today argue that icons should only be used sparingly, and only to represent specific physical devices (i.e., a disk drive).

What we really need are more designers who understand usability analysis, and actually use it to determine how much effort a given design takes to use.


Usability in Website and Software Design
AskTog Interaction Design Section
The Raskin Center for User Interface Design
Human-Computer Interface Institute at CMU
Human-Computer Interaction Resources on the Net
Bibliography of Human-Computer Interface Studies
Usability Tips and Tricks
Overiview of GOMS Analysis
Us

One thing that should definitely be covered is the 3-way "Save file" dialog that comes up when exiting a program/shutting down, and similar dialogs, that offer "Yes", "No", and "Cancel".

Which reminds me of #2 in the list of Ten Most Wanted Design Bugs, which proposes to "[c]onvert your existing software and write new software to perform Continuous Save, so users cannot lose more than the last few characters typed or gestures entered." Even better, include some Dead Simple Versioning, where the user creates some kind of "milestone" in the history to be able to revert any time. As a bonus, create an automatic milestone every time the application quits. No more saves!

I meant to read his articles on the Dock _and_ his articles on Fitt's law.

That said, check out:
http://www.asktog.com/columns/022DesignedToGiveFit ts.html
Question 4

http://www.asktog.com/columns/044top10docksucks.ht ml
Item 4

I meant to read his articles on the Dock _and_ his articles on Fitt's law.

That said, check out:
http://www.asktog.com/columns/022DesignedToGiveFit ts.html
Question 4

http://www.asktog.com/columns/044top10docksucks.ht ml
Item 4

Huh. Well, I'll buy your argument if you'll tell me how you get to the top of the screen in an instant. I can't, as far as I know -- it's further to roll the mouse to the top than it is to the top of a window, barring the single exception where the window is at the top anyway (in which case it takes just as long.) [. . .] So -- how do you get right to the top of the display with less moves than it takes to get to the top of a window that is, for instance, showing its title bar at the bottom third of the display?

One of many fallen apples... One of the better user interface gurus...
http://www.asktog.com/

Edges (e.g. menubar in Mac OS) and corners of the computer display are particularly easy to acquire because the pointer remains at the screen edge regardless of how much further the mouse is moved, thus can be considered as having infinite width.

I know I'll get flamed for this, but I don't think macs are the pinnacle of userfriendliness everyone else thinks. I do love macs, they are generally much easier than Windows. At work I use a mac, at home I have linux, I prefer linux. Here is why:
The dock sucks. I don't care what anyone says, this guy is right. Bruce Tognazzini founded apple's human interface group that so many rave about. So he knows what he is talking about. I think the ejecting disks to the trash is idiotic. I tried to help one lady who insisted that if she dragged her flash disk to the trash it would delete it, we had to back everything up before she would even try it. I hate how you have to use a mouse for everything. I use a mouse as little as possible (I even usually browse the internet sans mouse), I find it quicker when I know hotkeys. Same for about any other program with a gui, if it is well designed there are keyboard shortcuts that are faster than the mouse.

I have other gripes too, but these are pretty good examples of why I don't think macs are the most user friendly things ever.

I'll start by comparing screen corners to pie menus:

To quote Tog on Fitts' Law: "The time to acquire a target is a function of the distance to and size of the target." He points out that "the screen edge is, for all practical purposes, infinitely deep."

But the advantage of "screen corners" is just an indirect and wasteful application of Fitts' Law, which pie menus exploit much more directly, efficiently and flexibly than "screen corners". Tog's "screen corner" argument is just an ex post facto application of Fitts' Law: an after-the-fact rationalization, not the reason they originally designed the menu bar that way. If Fitts' Law was really the reason Apple designed their menu bar that way, then why aren't there four menu bars, one at each edge of the screen? Apple never mentioned Fitts' Law in their infamous menu bar patent.

Pie menus "slices" are better than "screen corners" or "menu bars" because:

Screen corners and edges are static and fixed in number, so they only enable a small fixed number of global commands at once.

Pie menus are dynamic and context sensitive, so each pie menu can have multiple slices, with a different set of functions associated with each, including submenus. The screen only has four corners and four edges, but pie menus are extremely reliable with eight items, and can support up to 12 items reliably.

Pie menus also support submenus, so you can have an infinite combination of pie menu items, depending on the context you click on, instead of just four screen corners or four menu bars.

Each pie menu item is easier to hit than any screen corner, because every pie slice target area starts directly adjacent to the cursor and extends all the way out to the screen edge, and beyond!

Screen corners and menu bars flaunt Fitts' Law by requiring you to physically move the mouse a large distance, and they usually leave the cursor far away from the object you're manipulating.

Pie menu target area "slices" extend all the way out to the edge of the screen and beyond, so their area is quite large, but you don't have to actually move all the way to the screen edge to select them. You simply move the cursor outside of the small inactive area in the pie menu center. Each "slice" target area starts out directly adjacent to the cursor, in a different direction, and occupies a large area extending out to the edge of the screen.

Fitts' Law relates the target seek time and error rate to the target area and distance from the cursor. The bigger the target and the closer the target, the faster the seletion and fewer errors. Pie menus maximize the target area and minimize the target distance, so consequently they minimize both the speed and error rate, as Fitts' Law predicts.

Pie menus have been empirically proven to be 20% faster than the linear menus, and about half the error rate ("A Comparative Analysis of Pie Menu Performance"; by Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman; Proc. CHI'88 conference, Washington D.C.)

Screen corners are worse than pie menus, because they actually have smaller target areas than pie menu slices, and actually maximize the distance from the cursor by putting the target as far away from the cursor as possible.

Tog claims the screen edge target area is "infinitely deep", but in practice you never move the cursor an infinite distanc