Slashdot Mirror

Yeah, top left is quicker to access with the mouse. The OS 9 apple menu is also easier to hit, since it's in the corner and effectively infinitely large in two directions because there is no margin to the left or top; you can't 'overshoot' the icon (I'm sitting on OS X now and can't double-check that there's no margin to the left [there is one on OS X--shame on Apple], but I believe there are none).

There's all sorts of margin around the Start menu, and it's easy to overshoot it unless you move your mouse more slowly. Fitt's Law, dontcha know. Quoth Bruce Tognazzini:

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

While at first glance, this law might seem patently obvious, it is one of the most ignored principles in design. Fitts's law dictates the Macintosh pull-down menu acquisition should be approximately five times faster than Windows menu acquisition, and this is proven out. Fitt's law dictates that the windows task bar will constantly and unnecessarily get in people's way, and this is proven out. Fitt's 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 they seem to be avoided at all costs by designers.

Use large objects for important functions (Big buttons are faster).

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 along the side of the display.

It's the same principle, though: a user-editable menu holding a variety of system-wide functions (launching apps, settings, etc.).

There was a study done to answer this very question. The GUI is faster, even when the test was slanted to favour keyboard usage! As I said before, using the CLI gives you a cognitive workout, and thus seems perceptually faster since you need to do more to get it to work. Mousing around a GUI is much faster, but seems slower since it is easier and requires less thought. Please don't make me reiterate myself. Modern GUI's are not "stupid"; they are sophisticated aides to productivity and ease of use.

Now don't get me wrong, commandline utilities are great for basic scripting tasks and remote administration, but modern GUI research as manifested in OS X and Windows XP has superceded the commandline in usability and speed for all tasks that matter. Get into the 21st century, you damn luddite! There are so many new developments in software technology that require a GUI to fully manifest, like A/V editing, NetMeeting-style conferencing, and of course gaming. The CLI freaks are retarding themselves by sticking with such antiquated technology.

Often stated, but wrong. Sorry, but the stopwatch doesn't lie. And it doesn't even take into account the lost time when somebody "rm's" the wrong directory or file or group of files.

As any study, this one also is rather uninteresting unless it is exactly specified (a) what has been studied, (b) how the test persons have been selected, (c) how the test was performed exactly, and (d) what data were gathered and how they were interpreted.

The cited website does not provide any information that would qualify it as a publication that is up to even the lowest standards in science. This does not imply that the study really is worthless or unscientific, but at any rate it is not possible to judge about it (or its findings) from the website.

That's a pretty angry view you take there. It's also, in my experience, a pretty inaccurate view.

HCI is not about taking an idiot off the street and letting them write an opera; it's about taking the skills and experience a user already has, and letting them go from there. An idiot off the street should be able to figure out how to play Chopsticks, possibly learning it in the process. A musician should be able to write a better opera more easily. Somewhere in there, the idiot off the street should be able to step up with the computer's help.

Put in more abstract terms, and put very simply, user interface design is about minimizing the investment in first learning the software, tooling the learning curve for maximum slope, and - here's the part you missed - letting the computer be as useful as possible. It may be voudoun, but that doesn't mean that its not difficult to do right, that people can't tell when you do it wrong, or that it doesn't actually make things better.

Get your head out of your ass, and go Ask Tog

I'll admit I engaged in a bit of exaggeration and satire to make my point. But that should be obvious, so I'll not apologize.

Believe me, we want to make it easy for the user. The easier the software is to use, the happier people will be with it, the better it will sell, the less you'll have to go back and rework interface elements.

I'm sure you and I believe that to be true, but the evidence seems to demostrate the opposite: we try to make easy software, but we continuously fail. It is perhaps because, as Alan Cooper said in his book, programmers make rotten designers for end-users. We see things differently and in different ways than the average user.

That's generally as it should be... if I'm working on a handy little Unix utility, I generally shouldn't bother to slap a GUI around it and design a nice icon; what my users are going to want is a solid set of (long and short) commandline options, a useful configuration file, and the ability to pass in data on stdin.

And that is good design--for an experience Unix user. It is standardized and ubiquitous. It is exactly the same as, say, the MacOS desktop, only implemented differently. If you use GNU tools you know that "--help" will give you a list of commandline options. You know that "man foo" will bring up the manual page for foo. I have no issue with this.

I do have an issue when you expand that into the ordinary computer user's world. They don't have the years of Unix background to rely on for experience, they don't know where to start. All they want to do is write a letter/balance their checkbook/look at porn. The Unix way is more complicated than what they need.

A good designer will say "let's do this and this to make it so Joe Average can use this program". A programmer says, as evidenced by the posts in this thread "Joe Average just needs to learn how to do it the Unix Way. If he can't, well, I guess he's just stupid".

People who learn the keyboard shortcuts for their apps do generally have far better performance.

Often stated, but wrong. Sorry, but the stopwatch doesn't lie. And it doesn't even take into account the lost time when somebody "rm's" the wrong directory or file or group of files.

The flipside is that advanced users tend to recommend applications that have very powerful interfaces, which newer users tend to have trouble with because they're so highly optimized: vim, emacs, Excel, Photoshop, ksh...

If somebody wants to look at their digital photos, I'll recommend Picture Viewer. If they want to resize, rotate, perhaps adjust colors, I'll recommend PhotoDeluxe or something similar. If they want to do pre-press work, or some other complex and complicated work, I'll recommend Photoshop.

In addition, what people recommend is a poor standard for quality. People recommend what they know: if you ask a construction worker what kind of drill to get, he'll recommend the Hole-Hog. If the guy asking for the recommendation is just trying to put up a shelf in his den, he's going to be sorely surprised when this highly recommended Hole-Hog punches right through the entire wall instantly, and will probably wish he had just gone to Wal-Mart and bought the $20 Black and Decker.

take a look here:
A Quiz Designed to Give You Fitts

And there are many research efforts underway to replace the inadequate "desktop metaphor" (Lifestreams is one interesting idea).

-Kevin

Ximian has an answer for that: Red Carpet (usually) works great. Lately they've had some signature deficiencies, and there have been some dependencies that got missed WRT GIMP modules last night.

Beyond that Linux has much more comprehensive on-line documentation than Windows, in my estimation.

Case in point: I bought a Mitsume IDE CD-RW drive for my wife's school. I couldn't make any of the Windows software recognize it as a writer. I swapped it out for an older Mitsumi drive in my Linux box, and it worked just fine! Go figure. (I took the older drive to school, and *it* worked!)

I think a previous poster was right: Windows is thought to be easy because it's ubiquitous. People mistake familiarity for ease. Bruce Tognazzini talks about this idea.

Ximian has an answer for that: Red Carpet (usually) works great. Lately they've had some signature deficiencies, and there have been some dependencies that got missed WRT GIMP modules last night.

Beyond that Linux has much more comprehensive on-line documentation than Windows, in my estimation.

Case in point: I bought a Mitsume IDE CD-RW drive for my wife's school. I couldn't make any of the Windows software recognize it as a writer. I swapped it out for an older Mitsumi drive in my Linux box, and it worked just fine! Go figure. (I took the older drive to school, and *it* worked!)

I think a previous poster was right: Windows is thought to be easy because it's ubiquitous. People mistake familiarity for ease. Bruce Tognazzini talks about this idea.

Tog is wrong.

Or more specifically, Tog is overgeneralizing. His research quite reasonably focuses on casual users of software. This does't make sense for people who make heavy use of a particular piece software. Moving your hand off the keyboard when doing heavy duty text data entry is a huge speed hit. It's a big speed hit for transcription, for entering order information, for typing source code, for writing a novel.

A mouse is a great and important invention. But it's not a silver bullet. Tog has made the mistake of generalizing his fairly specific research into faulty universal solutions. When I saw Tog's article on how traffic engineers are stealing his life I realized that his ego was completely out of control. The man has grown too comfortable living on his prior research. He's become closed minded, a mistake in a field that is still very young.

Mice are great. Going back to the keyboard only days is a hideous mistake. But keyboard shortcuts can provide a very real speed boost for frequent operations.

So I thought that windows should expire after some amount of disuse. They should _become_ something like bookmarks (searchable by metadata (title, keywords, URL, full text, etc.), and also organized in a timeline, and also organized in a graph of branching - which link did you follow to get there?) automatically.

On either a tiled or overlapping desktop, the constant is that being able to minimize or collapse windows to remove them from the screen is important. But on a tiled desktop it would be even more important than usual. And I think the GUI mechanism for selecting from all open windows (including minimized ones), which one to view, is very important. I've recently fallen in love with the KDE "external taskbar". I put it in the upper right, enable auto-hide, and now it's very Mac-like, and compliant with Fitts's Law - I can slam the mouse up into that corner and I get a nice list of open windows, organized by which desktop they're on, without regard to whether they are minimized or not. There is enough space to show more of the title bar than you get on a typical minimized icon in WindowMaker, or a on one of those taskbar buttons on Windows or Gnome, yet, it still doesn't take up a lot of real estate, and still has mini-icons too. I can manage many more windows effectively this way. And it's rather like a stack of books (an approach to organizing information which has been advocated elsewhere).

Anyway for many purposes I like the idea of a tiled desktop; especially for "reference materials" which I need to glance at, but not interact with quite as much. But I think the user needs a very straightforward choice when spawning a new window, whether to take up space in the tile matrix for it. Maybe something like click with middle-mouse button on a link, to open it in a new tile-space; and click with left-mouse to open it in the same space, in a new window lying on top of the old one. So each tile-space becomes a stack of windows. (And I'm imagining a GUI in which most navigation is a lot like navigating hyperlinks.) Of course, every time you must make room for a new tile-space, it's liable to cause most other windows to be resized; and controlling that is tricky. Using virtual desktops effectively can help with that. It needs to be easy to move windows from one desktop to another, _and_ place them into the desired tile-space, in one fell swoop, without a lot of mousing around, or thinking too hard.

Maybe there should be a window manager which gives you a choice for each desktop - tile or overlap. I would bet quite a lot of money that will be done by somebody in the next few years.

My friends always laugh at me when I say that I hate using the mouse because when I'm really tooling along on my computer reaching for the mouse slows me down....I'm glad someone else finally understands this!

Your friends are laughing at you because, although using the keyboard "feels" faster, nonetheless you are wrong.

My friends always laugh at me when I say that I hate using the mouse because when I'm really tooling along on my computer reaching for the mouse slows me down....I'm glad someone else finally understands this!

Your friends are laughing at you because, although using the keyboard "feels" faster, nonetheless you are wrong.

My friends always laugh at me when I say that I hate using the mouse because when I'm really tooling along on my computer reaching for the mouse slows me down....I'm glad someone else finally understands this!

Your friends are laughing at you because, although using the keyboard "feels" faster, nonetheless you are wrong.

Unfortunately for your example, Tog was researching Macs, not Windows. Tognazzini also is on record as saying that performing a task on Windows takes up to five times longer than on a Mac, due to several bad design decisions. See here for more info.

You only think that's true. One of the key discoveries in the science of human-computer interaction was that users frequently perceive easy tasks as being slower than harder ones, even though the reverse is true.

In one study of this phenomenon (Tognazzini, Tog on Interface, 1992.), users were asked to do the same task using the keyboard and the mouse. The keyboard was powerfully engaging, in the manner of many video games, requiring the user to make many small decisions. The mouse version of the task was far less engaging, requiring no decisions and only low-level cognitive engagement.

Each and every user was able to perform the task using the mouse significantly faster, an average of 50% faster.

Interestingly, each and every user reported that they did the task much faster using the keyboard, exactly contrary to the objective evidence of the stopwatch.

Taken from here under the section labelled "Reduce Subjective Time".

Sure they've added rendering this, and office app that, but they still blow it on the most important usability stuff. They still don't label toolbar buttons. They still have the same ridiculously small buttons that have ridiculously slow access times and icons that are so small they don't mean a damn thing. You try to tell these people about something like Fitts Law but they really don't want to hear that. I'm sure some people will argue with me about this. Some people, linux developers especially, do not want to pay attention to 20 years of HCI research. And its precisely these people who should be held up as the shining example of why linux in its current form will never reach the desktop.

A case in point: Every WM I can remember seeing handles menus the same way. Microsoft came up with the idea that the menu bar should be beneath and ajacent to the title bar, and everyone has followed down that road. Better designs put the menu at the top of the screen but the design of both X11 toolkits and the sundry WMs makes it all but impossible to do this. Menus need to be properties attached to the window, which the WM can then display where it chooses, not the app.

Ditto for scroll bars. Right now, if you use apps designed for different WMs, you get multiple types of scroll bars, posibly in different sizes and locations. Instead, fix X11 to understand the difference between windows and viewports, and let the WM draw the scroll bars, just as it draws the title bar.

1. Q: Why did apple ever go with one mouse-button?
   A: The one mouse button was thought up by a guy named Jeff Raskin who is largely responsible for starting the Macintosh project at Apple. He thought that mouses with more than one mouse button would be confusing for new users. This might seem like an oversight, but when you consider how uncomplex graphical interfaces were back than and the fact that virtually no computers in mass production had mice as an essential navigational tool, it really isn't.
   
   
2. Q: How can you mac users live without the right-click contextual menu?
   A: Because we can use the regular pull down menus to bring up a menu. If you take a look at *NIX & Windows UI's, you often see that not all menu items for the program are in the pull-down menus. Often, there are some commands that you can only access through right-clicking (i.e. the contextual menu). When this is the case, you're going to need a 2nd mouse button. Contrast this with the mac paradigm, where is it a cardinal sin to have commands that are not listed in the pull-down menus.
   
   
3. Q: Won't going up to a pull-down menu take you longer to do than right-clicking?
   A: No and yes. Unlike other platforms, macs have the pull-down menubar at the top of the screen instead of on each window, like you usually find on Windows or GNOME or KDE (yes, KDE does have a mac menubar mode, but not by default). A menubar at the top border of the screen has been proven in usability labs to be far faster to access than menubar stuck on a window, because the user can ram the mouse pointer into the top of the screen to click on the inital menu item and they can't overshoot. This illustrates a principle of Fitt's Law, which states that things on the borders are faster to access than things that aren't because they are infinitely large . To learn more about Fitt's law, go here . This being said, contextual menu (i.e. right-clicking) is faster IF you can do it anywhere to bring up the same menu anywhere on the screen, because the mouse pointer can be anywhere and the menu will appear right under it. Unfortunately, bringing up a contextual menu in windows/GNOME/KDE almost always requires that you first land the mouse on a tiny visual target. If you have to click on a tiny 15x10 pixel icon in an e-mail program to bring up a contextual menu for it, any speed advantage of right clicking is negated.
   
   
4. Q: I hear some mac users say that they don't need a 2nd mouse button because they've go all those keyboard combinations. I don't understand.
   A: The reason that mac users use those keyboard strokes is because Apple was smart enough to have the keyboard complement the mouse instead of replacing it. Just like right-cliking is supposed to do on windows. Notice that the command key most often used on macs for the keyboard combinations is located in a spot that is in the center of the keyboard, so a user doesn't have to stretch their fingers 3 miles to hit an out of the way key. Also notice that keyboard strokes using the command key make use of the two most dextrous fingers of the human hand: the index finger and the thumb. The result is that keyboard shortcuts on a mac are easy to do, and they can be done easily with one hand. Why don't Windows users use keyboard shortcuts as often as mac users? Because microsoft was stupid and tried to have the keyboard replace the mouse instead of complmenting it. They added those underline thingies on all the menus (technically, they're called mnemonics), which are far less efficient because you have to hit two sets of keys "Alt+firstletter Alt+secondletter" to use them. This added so much visual clutter and so jammed the users mental keyboard-menu associations that most Windows users also filtered out the keyboard shortcuts (i.e. Ctrl+letter). There is even less incentive to use keyboard shortcuts on windows because the ctrl key that makes use of them is far at one end of the keyboard, which makes keyboard combinations with keys in the center of the keyboard very hard to do with one hand and impossible to easily with the two most dextrous fingers of the human hand (the thumb and index finger). One final advantage of mac keyboard shorcuts is that the command key is represented in the menu system by a symbol that take up one character's worth of menu real-estate as opposed to "Alt" or "Ctrl", which take up 3-4 characters of menu real-estate.
   
   
5. Q:Shouldn't apple add more mouse buttons?
   A: Yes. I don't think you'll find many mac users who are against having more than one mouse button, but they are against some dumb windows/unix geek who knows nothing about macs and who refuses to learn anything about the way they are designed arrogantly assuming that the machine is unusable in some sort of way.

Actually, http://www.asktog.com/TOI/toi22KeyboardVMouse2.htm l is probably better.

Still not really a *study*...

Does http://www.asktog.com/TOI/toi06KeyboardVMouse1.htm ldo any good?

I suspect the results would be different with Windows' less efficient menu system. (Yes, I use windows) And personally, it sometimes takes me a minute to *locate* my mouse, let alone move my hand to it ;)

Sigh. This again. One day an Apple-topic story will be posted on /. without the "one-button-mouse" troll being sounded, and then the world will promptly end.

One more time, with feeling then: Apple's choice of a one-button mouse had nothing to do with any alleged "artistically elitist" inclination, but was a conscious, deliberate choice based on thousands and thousands of hours of actual usability testing. You can second-guess the decision as much as you like in hindsight, but the cold hard fact is that they made it only after actually assessing the data.

Many usability professsionals have sharply criticized microsoft for the adaptive menus feature and Clippy found in Office 2000. Let me add that in Word 2000, there is no "one-stop shopping area" for all the user's configuration needs. Configuration choices are spread throughout the entire program, being found both in "Options" and "Customization" menu selections. One particularly stupid thing I remember was that many spelling options were found under "Options", but the option for the feature that corrects text as you type was found in "Configuration". Finally, those toolbar buttons in O2K are damn near useless. A toolbar button can serve two purposes: it can give a user a graphical representation of what a command does (if the icon is descriptive enough), and it provides a faster way to performing a command than navigating menus (if the toolbar button is large enough). If a toolbar button is very small, it is not fast to access, in accordance with Fitts' Law , which states that the time to access a target is the function of its distance and its size. If a toolbar button has a tiny and undescriptive icon, it really doesn't give a good graphical representation of the command. Microsoft programs (barring IE) generally have both these problems. If Microsoft had added labels to the toolbar buttons like they were supposed to do, the toolbar buttons would be far more descriptive and be faster to access. But that would make O2K more usable and microsoft is anti-usability, despite everything they say. One of the few things GNOME does really well is toolbar buttons: their toolbar icons are big and are labelled. There is a far, far greater chance that a user will use a GNOME toolbar button to execute a command than those tiny, useless things that clutter microsoft programs.

Not that I disagree with the rest of the post. StarOffice is very inadequate in many ways, just like O2K. If you have the choice of inferior or damn inferior, the obvious choice is the first one. But there is advantage in StarOffice: you have the source code to make it not suck. If you can read all those code comments in German. ;)

Reading the summary, and having a lot of respect for what the authors had to say on other topics convinced me it wasn't worth my while to bother with WAP.

The WAP Usability Report (available in PDF form for $26) reports on a study where 20 people were given WAP enabled phones for a week and asked to report back on their experiences. The study was done in London because of the advanced state of WAP services there. Read the summary here.

• 70% of users reported they would not use WAP within a year
• One user calculated it was cheaper to buy a newspaper and throw away everything but the TV listings rather than use WAP to check the BBC schedule

our basic conclusion is that WAP usability fails miserably; accomplishing even the simplest of tasks takes much too long to provide any user satisfaction. It simply should not take two minutes to find the current weather forecast or what will be showing on BBC1 at 8 p.m.

• Jakob Nielson
• Don Norman, author of The Design of Everyday Things, Things that Make Us Smart and The Invisible Computer
• Bruce "Tog" Tognazzini, one of the original designers of the Macintosh UI and author of Tog on Interface. Check out Tog's Software Design Bookstore to learn how to write software that doesn't suck. Read Top 10 Reasons the Apple Dock Sucks.

I link these and a couple other useful sites in my brief section on Some Web Application Design Basics in Use Validators and Load Generators to Test Your Web Applications:

I'm not talking about pretty rollover buttons here, folks.

You need to understand that many web sites are developed with investments totalling many millions of dollars, only to have the effect of driving away any user who might have the misfortune to stumble across them, with much resulting heartbreak and the loss of fortunes.

Reading the summary, and having a lot of respect for what the authors had to say on other topics convinced me it wasn't worth my while to bother with WAP.

The WAP Usability Report (available in PDF form for $26) reports on a study where 20 people were given WAP enabled phones for a week and asked to report back on their experiences. The study was done in London because of the advanced state of WAP services there. Read the summary here.

• 70% of users reported they would not use WAP within a year
• One user calculated it was cheaper to buy a newspaper and throw away everything but the TV listings rather than use WAP to check the BBC schedule

our basic conclusion is that WAP usability fails miserably; accomplishing even the simplest of tasks takes much too long to provide any user satisfaction. It simply should not take two minutes to find the current weather forecast or what will be showing on BBC1 at 8 p.m.

• Jakob Nielson
• Don Norman, author of The Design of Everyday Things, Things that Make Us Smart and The Invisible Computer
• Bruce "Tog" Tognazzini, one of the original designers of the Macintosh UI and author of Tog on Interface. Check out Tog's Software Design Bookstore to learn how to write software that doesn't suck. Read Top 10 Reasons the Apple Dock Sucks.

I link these and a couple other useful sites in my brief section on Some Web Application Design Basics in Use Validators and Load Generators to Test Your Web Applications:

I'm not talking about pretty rollover buttons here, folks.

You need to understand that many web sites are developed with investments totalling many millions of dollars, only to have the effect of driving away any user who might have the misfortune to stumble across them, with much resulting heartbreak and the loss of fortunes.

Reading the summary, and having a lot of respect for what the authors had to say on other topics convinced me it wasn't worth my while to bother with WAP.

The WAP Usability Report (available in PDF form for $26) reports on a study where 20 people were given WAP enabled phones for a week and asked to report back on their experiences. The study was done in London because of the advanced state of WAP services there. Read the summary here.

• 70% of users reported they would not use WAP within a year
• One user calculated it was cheaper to buy a newspaper and throw away everything but the TV listings rather than use WAP to check the BBC schedule

our basic conclusion is that WAP usability fails miserably; accomplishing even the simplest of tasks takes much too long to provide any user satisfaction. It simply should not take two minutes to find the current weather forecast or what will be showing on BBC1 at 8 p.m.

• Jakob Nielson
• Don Norman, author of The Design of Everyday Things, Things that Make Us Smart and The Invisible Computer
• Bruce "Tog" Tognazzini, one of the original designers of the Macintosh UI and author of Tog on Interface. Check out Tog's Software Design Bookstore to learn how to write software that doesn't suck. Read Top 10 Reasons the Apple Dock Sucks.

I link these and a couple other useful sites in my brief section on Some Web Application Design Basics in Use Validators and Load Generators to Test Your Web Applications:

I'm not talking about pretty rollover buttons here, folks.

You need to understand that many web sites are developed with investments totalling many millions of dollars, only to have the effect of driving away any user who might have the misfortune to stumble across them, with much resulting heartbreak and the loss of fortunes.

Reading the summary, and having a lot of respect for what the authors had to say on other topics convinced me it wasn't worth my while to bother with WAP.

The WAP Usability Report (available in PDF form for $26) reports on a study where 20 people were given WAP enabled phones for a week and asked to report back on their experiences. The study was done in London because of the advanced state of WAP services there. Read the summary here.

• 70% of users reported they would not use WAP within a year
• One user calculated it was cheaper to buy a newspaper and throw away everything but the TV listings rather than use WAP to check the BBC schedule

our basic conclusion is that WAP usability fails miserably; accomplishing even the simplest of tasks takes much too long to provide any user satisfaction. It simply should not take two minutes to find the current weather forecast or what will be showing on BBC1 at 8 p.m.

• Jakob Nielson
• Don Norman, author of The Design of Everyday Things, Things that Make Us Smart and The Invisible Computer
• Bruce "Tog" Tognazzini, one of the original designers of the Macintosh UI and author of Tog on Interface. Check out Tog's Software Design Bookstore to learn how to write software that doesn't suck. Read Top 10 Reasons the Apple Dock Sucks.

I link these and a couple other useful sites in my brief section on Some Web Application Design Basics in Use Validators and Load Generators to Test Your Web Applications:

I'm not talking about pretty rollover buttons here, folks.

You need to understand that many web sites are developed with investments totalling many millions of dollars, only to have the effect of driving away any user who might have the misfortune to stumble across them, with much resulting heartbreak and the loss of fortunes.

For example, for right-hand users the mouse and cursor will naturally gravitate to the top left of the screen, and this is where Apple decided to put the Apple, File and Edit menus. Flicking your mouse to the upper left is an incredibly easy movement, and then - twack! you hit the corner and the menu is there, just under your mouse button. Microsoft decided to put the Start button in the lower left, requiring the user to cramp his/her hand. And the corner pixel is inactive, so you actually have to stop the mouse movement just before the cursor hits the corner -- or go on and hit the corner and then navigate back a few pixels. And then you can click, with your hand in an incredibly unergonomic position. The Win95 UI is full of this kind of design errors.

Essentially, Microsoft has taken the (old) Mac OS UI, removed all the nice usability details, spread the result onto 90% of the desktops of the world, and now even CNet says that it's better than the new-and-revamped Mac OS interface! I think this is disturbing and sad.

For anyone interested in UI design, Bruce Tognazzini has written lots of articles on his website www.asktog.com. Tog was closely involved in designing the Mac user interface, and has a cartload of UI design knowledge as well as a good pen hand.

--Bud

For example, for right-hand users the mouse and cursor will naturally gravitate to the top left of the screen, and this is where Apple decided to put the Apple, File and Edit menus. Flicking your mouse to the upper left is an incredibly easy movement, and then - twack! you hit the corner and the menu is there, just under your mouse button. Microsoft decided to put the Start button in the lower left, requiring the user to cramp his/her hand. And the corner pixel is inactive, so you actually have to stop the mouse movement just before the cursor hits the corner -- or go on and hit the corner and then navigate back a few pixels. And then you can click, with your hand in an incredibly unergonomic position. The Win95 UI is full of this kind of design errors.

Essentially, Microsoft has taken the (old) Mac OS UI, removed all the nice usability details, spread the result onto 90% of the desktops of the world, and now even CNet says that it's better than the new-and-revamped Mac OS interface! I think this is disturbing and sad.

For anyone interested in UI design, Bruce Tognazzini has written lots of articles on his website www.asktog.com. Tog was closely involved in designing the Mac user interface, and has a cartload of UI design knowledge as well as a good pen hand.

--Bud

Actually, Bruce Tognazzini wrote an article about this same issue not too long ago on his popular AskTog site. This issue is not new to the TiVo, RePlay (which markets a TiVo-like product) just did similar things to all their customers.

The article really makes some excellent points regarding software downgrades and manufacturer responsibilities.

Actually, Bruce Tognazzini wrote an article about this same issue not too long ago on his popular AskTog site. This issue is not new to the TiVo, RePlay (which markets a TiVo-like product) just did similar things to all their customers.

The article really makes some excellent points regarding software downgrades and manufacturer responsibilities.

You said, There's no need for 2 shift keys if a single one were properly placed somewhere more centrally.

This is incorrect, IMHO. Something I realized as I began to type faster is that my high school typing teacher's advice was right-on: never ever use the same hand for SHIFT and the key it's modifying. At high speed it's hard to time that SHIFT, especially when you're hand's already contorted to hit two keys. What often happens is that your other hand will hit a key before you let go of shift. By SHIFTing with the opposite hand you maintain a better cadence on the keys and are more efficient.

I also disagree that the CAPS LOCK key should be small. It's large for a reason - (i) for efficiency it has to be hit with your pinky, your least-coordinated digit, and (ii) depending upon the previous key press (e.g. 'G' ot 'T'), your finger might have a (relatively) substantial distance to travel. This interaction os governed by Fitt's Law : "The time to acquire a target is a function of the distance to and size of the target."

Now consider that the CAPS LOCK key, while rarely used, is critical. For instance, typing 'CAPS LOCK' without it would be slow and painful. But it's use is only justified if the extra acquisition time is less than the time it takes to use the SHIFT key (for short groups like 'RMS,' using SHIFT can be faster). So the faster you can hit the CAPS LOCK key, the more efficient you'll be in cases of long groups of capital letters. This doesn't happen often, but that's one reason why it's so important: you don't have much chance to practice.

I like your other ideas, though.

question: is control controlled by its need to control?
answer: yes

Basic intelligence is not effected by education, or the tools used to acquire information. A computer will allow someone to take advantage of a superior intellect, but it will not increase the intellect. Great post. Tog had a great chapter in his book Tog on Software Design were he explains some of the downfalls of our educational system. He pointed out that teachers didn't allow calculators in the classroom for years. I graduated in '93, yet I was still required to learn out to calculate square roots (a button that has been on every calculator in the US since I was born). Did that increase my intelligence? No. Did it improve my ability to understand the situations that I might need to apply square roots? No. Too many people (including our own schools) confuse knowledge with content. Rather than memorizing facts and dates, we should teach our children how to find those facts and dates, should they ever need them. We should then spend the remaining 7.5 hours in the school day to teach them the concepts - how those facts effect the world, and their lives. Computers are simply the next misunderstood technology. What people fail to realize about computers, is that they will never go away. Computers are here to stay. Those who are familiar with them will have the world's knowledge at their fingertips (a phrase that finally has meaning). As you pointed out, the children who are growing up with the internet will not end up any smarter than the rest of us... but their knowledge will be much more applicable in the future, than will be the content I was forced to memorize when I was young.

Raskin has some curmudgeon in him. Just read this page on what Raskin thinks we should do with the word "intuitive".

Unlike Tog, who seems to think that anything the Mac interface does is The Right Way To Do It, Raskin appears to receive some influence from actually experimentation.

On the other hand, going hard-over against modal interfaces seems a little odd. As far as I know, only one study has ever been done on this sort of thing: "A Comparative Study of Moded and Modeless Text Editing by Experienced Editor Users", by Poller, M.F., Garter, S.K., appearing in Proceedings of CHI '83, pp 166-170.

One interesting conclusion from that study:

Moded errors do not seem to be a problem for experienced vi users. The vi group made few moded errors, and those few were rapidly corrected. Futhermore, modeless editing may not totally avoid moded type errors, since the emacs group made errors that were similar in nature to the vi moded errors.

Now look at privacy policies like Microsoft's. Sure they've "fixed" it. But I note that they haven't removed this piece.

Microsoft reserves the right to change the terms, conditions, and notices under which the Passport Web Site and Passport Services are offered. You are responsible for regularly reviewing these terms and conditions. Continued use of the Passport Web Site or Passport Services after any such changes shall constitute your consent to such changes.

Web services are nothing more than subscription software sites. And privacy agreements can be "upgraded" at anytime. Show me one site that promises that their privacy agreement will never become less restrictive. And if you can, promise me that the agreement will survive a bankruptcy proceeding or even a sale of the company.

You have no privacy guarantees, on the web or off. In fact, it's worse off the web - see this Red Rock Eater Digest analysis of the new medical privacy rules, and then consider going to Defend Your Privacy and filling out the petition there.

But don't worry. Your video rental records are secure.

How can we possibly claim that one way us more natural than another to do an unnatural task? I hate to raise Tog's name again (I have seen it quite a bit on /. lately), but he has a very interesting article on this subject: Intuitive vs. Familiar. Writing with a pen isn't more natural... it's just more familiar (to most of the world). Personaly, I would rather use a keyboard... but then again, I choose vi over most gui text pads. Had the simpler interface always been available, I might have not become so familiar with my keyboard.

Aqua is a very good UI.

A former Mac interface designer seems to think otherwise.
--
Obfuscated e-mail addresses won't stop sadistic 12-year-old ACs.

Information on Fitts' Law: http://www.asktog.com/columns/022DesignedToGiveFit ts.html

Apple does it best with their "Human Interface Guidelines" document.

...Except that Aqua doesn't really follow these guidelines. Sure, it looks awesome, but many will say that it's most prominent feature, the "Dock", is more of a marketing "ooh ahh" then a usable interface.

Of course, when people say that "design" will save the world, they usually mean their idea of design, which might not jibe with yours or mine.

No timothy, when they say "design", I beleive they are referring to things like usability testing. In other words, taking a software package to groups of users, and designing statistically sound experiments to see what users find easy and fast to use. In other words, users ideas of good design - not yours, not mine.

If you're interested, maybe read some sites on design.

Moreover, I think they are also saying that VC's should at least be aware of what theoreticians are thinking about so they make better use of their investor's dollars

Tog sez: Window's take on the Mac WIMP GUI was to do many widgets the opposite for the sake of being different.

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

Bruce Tognazzini is a really, really bad source for information. Anything he says should be taken with a huge, industrial sized grain of salt. He's got a history of writing articles on subjects he clearly does not understand. Witness his article How Programmers Stole the Web, in which he argues that the web has been ruined because it is not programmed in his favorite language, BASIC!! It's also worth mentioning that the Mac's user interface was developed before he created the user interface group at Apple, and that his entire approach to UI criticism amounts to little more than "The original Mac interface rules, everything different sucks". I know that UI design is hardly an exact science, but this guy treats his most subjective opinions as if they are universal laws. I make it a point not to take a single thing he says seriously.

The last thing Aqua is is Usable. It is a usability disaster. Read Tog's comments or the Ars Technica reviews (this one, for example. Aqua is not a usability wonder, it is marketing schlock...

(disclaimer, i am a loyal Mac User, and you would have to pry my powerbook running Platinum from my cold dead fingers. This said, When Aqua hits, i will be running windows...)

The last thing Aqua is is Usable. It is a usability disaster. Read Tog's comments or the Ars Technica reviews (this one, for example. Aqua is not a usability wonder, it is marketing schlock...

(disclaimer, i am a loyal Mac User, and you would have to pry my powerbook running Platinum from my cold dead fingers. This said, When Aqua hits, i will be running windows...)

Maybe Raskin will eventually figure out something for those people who "just want it to work" and have to deal with an Enterprise-level directory structure filled with documents of widely varying types.

Until he shows me at least a prototype, heck a screen mockup, Jef Raskin can just shut up.

On second thought, Bruce Tognazzini already prototyped one of those for Sun. See The Starfire Project for more details on a really powerful but very usable system.

Maybe Raskin will eventually figure out something for those people who "just want it to work" and have to deal with an Enterprise-level directory structure filled with documents of widely varying types.

Until he shows me at least a prototype, heck a screen mockup, Jef Raskin can just shut up.

On second thought, Bruce Tognazzini already prototyped one of those for Sun. See The Starfire Project for more details on a really powerful but very usable system.

if GUIs were designed better then the mouse wouldn't be quite as useless.

(i bet you all thought that was a goatse.cx link, didn't you?)

- j

As a disclaimer, I use a Mac everyday for work and play. However, I've been required to work on all manner of machines, including Sun, SGI, Linux, and Windows (of course). I have to say that I find MacOS the easiest to use as far as mouse operation. I think the main reason is the location of menus at the top of the screen. Refer to Fitt's Law.
Excuse the Tog link, I know he's a little arrogant, but I found the linked article rather enlightening.

I do enjoy the multiple desktop feature that I've used in various X windows systems, and I wish that MacOS did that.

Actually, there's five locations on the screen that are all equally fast to reach by mouse. Tog has an excellent article on this, I'd recommend you read it.. It's called A Quiz Designed to Give You Fitts, look at question 3 of the Quiz.