Slashdot Mirror
Top Ten Persistent Design Flaws
jlouderb writes "Bruce Tognazzini former human interface evangalist at Apple, and currently a principal at web design firm Neilsen Norman Group has begun cataloging the top ten design computing flaws that we just live with with, but shouldn't have to. Only seven are found at his article, and (not surprisingly) three are Mac related. My favorite: the mysteriously dimmed menu options. Why are those darned things grey anyway?"
...but you presumably knew you WANTED to remove it.
- open, Apple just keeps the behavior consistent: the user should know they're done using the volume (unmount it) before they unplug it. This has been the behavior for 20 years. And no, I'm not saying just because something has been some way for a long time that it needs to remain, but I just don't see the problem. Not allowing a device to be removed, or "nagging", probably saves a lot of people from fucking shit up before they've properly saved and/or dealt with items on a removable volume, instead of allowing things to be unplugged wholesale. If the user unplugs something at an inopportune moment or with open files, how is the computer supposed to be able to deal with it? Cache up the changes and not tell you? Or tell you that something was removed when it wasn't supposed to be and tell you (and keep that behavior consistent even when you "might be done with it"), like Mac OS does?
What if a user has an open file, and yanks the drive? How does Windows "gracefully" deal with that? Answer: it can't.
You can pull the drive on a Mac, too - the difference is that the Mac will say, hey, you should have unmounted this first...hope you saved everything. And instead of doing something like auto-unmounting-without-nagging-when-no-files-are
As for the above, swap user with driver and you may see my point.
It would be trivial to have a small battery, on the DC side of the power supply instead of trying to hook up a UPS. Just 2 minutes worth of power to cleanly shutdown.
UPS is ok to weather the power shortage, a battery inside the power supply would allow for clean shutdown.
In my opinion, Scientology is a cult you should avoid.
It doesn't seem to include evil applications (or operating systems) that suddenly throw new windows on the screen to grab keyboard focus away from you just as you type something.
You lose your thread of thought AND the computer decides you said "OK" to "do you want to email your credit cards around the world" while you sit there wondering what just happened.
To summarise the summary of the summary: people are a problem. ~ h2g2
Item 1; Power failure crashing
In my experience, this affected Macs much less in a brownout situation than PCs. The Macs (at the time, desktop G3 systems) stayed up after a power blink of 0.5 sec, losing no data. I think current Mac OS hardware is more robust in this area, but this is not really a fault of the computer or the OS. No power, no computer worky. Sorry.
Workaround in a mission-critical area: Buy an uninterruptable power supply, petition Apple to make a computer with very expensive (but non-volatile) flash RAM, or use an Apple laptop, which has its own battery that makes it resistant to brownouts and blackouts.
Issue 2: The Dock in Mac OS X.
Grousing. In the old Mac OS 9 days, there was a Dock analogue called the Launcher. It was ugly, and I rarely set it up for users, but it worked. Some people still use it for their Classic apps in OS X.
Workaround: Many, most third-party. Apple's interface, until OS X was icon-centric for launching apps, rather than menu-centric (in Windows Start menu). The Dock is no more perfect than the Start menu, but at least it provides a consistent launcher for common apps, instead of having the user search through folders for the right app icon to launch.
Better: Have installers ask user to add icon for applications to the Dock, which isn't done most of the time, forcing users to search about in the Applications folder.
Issue 3: Dimmed menus.
A bit of a grouse, but logical. Some OS X apps by third parties HAVE shown info in the greyed out menu as to why the option is not available. I believe it is more programming efficient to leave a greyed out menu than to attempt to hide it (affecting where and the order of menus on the menu bar from one moment to the next, which would confuse the hell out of me).
I believe Tog's thought, of adding a special option in a greyed-out menu as to why this command is dimmed, could be useful. Otherwise I think he is blowing the issue up. Of course, the more complex the app (especially with palettes and THEIR commands, the more weight his argument holds.
Issue Seven: Disk Drive Nazi.
Not a problem, at least until removeable drives arrived.
The Mac OS has always been intelligent, preventing you as the user from accidentally ejecting or formatting a disk you are using, including network devices. This is a Good Thing. Compare this to the behavior in Windows, which will still allow you to eject media in use, causing All Kinds of Hell.
Workaround: His point seems more specific to USB and FireWire drives. Unless Apple creates a hardware lock that physically locks a device, preventing the thing from being removed, then there's not a lot to do there, except Apple making the OS more robust in screaming at people to tell the OS that the drive is to be disconnected before they physically remove it.
Vos teneo officium eram periculosus ut vos recipero is.
Agreed, many of his bugs were of the sort "this damn machine can't read my mind". They are good to have around though because if you solve them it could make you some money.
The one I found funny was the continuous save. Computers "used" to do things that way (in the 70's) and if the power went out not only was your in memory copy bad, so was the one on disk because it was saving when the power went down (well back then it was on casette but the damage was the same) and is corrupted. Thats not even thinking about the fact that writing to disk all the time would slow the application down to the speed of molasses flowing uphill in January. This isn't to say that there is no happy medium. I find that 5 minute saves are plenty for me and I prefer them to go into a "backup" file that the application can handle instead of being saved in my actual document.
"You can now flame me, I am full of love,"
Example: A post of "Often it is difficult to figure out why certain options are dimmed and under what context they will become active. I don't see a better alternative though other than better documentation..." attached to a story containing the solution of "Make grayed-out objects clickable, revealing what has caused the object to be dimmed and what the user can do about it."
First Noticed: 1996
Proposed Solution: Require the user to read the article. This could be implemented in a number of ways: either the referring home page to the message board should BE the article, or a page between the story and the article should contain some sort of code permitting posting. Or a mod of "-9999999, RTFA" should be added.
Kinda ironic the article brakes almost as many usability rules as it points out:
1) No alt tags - you've used images to number your list, yet no alternative text for blind users (or those with images off), this is a very well established as bad usability
2) Confusing title - you say top 10, but don't actually have 10 items on your list, an important aspect of usability is clarity, which your title lacks.
3) Consistency - you've divided each item into sub-sections, yet the sub-sections are inconsistent with from one item on the list to the next. If a sub-section is not applicable, I suggest you add, for instance: "History: N/A," this will save readers scrolling back and forth for a section they might believe to have missed
4) No submission form - You provide an option for people to submit suggestions for your list, yet fail to provide a basic HTML form for them to do this, instead you opt to let them do the work.
There are more, but I'll stop here, since I expect this to be modded down anyway. I hope you see the irony.
> 2 minutes worth of power to cleanly shutdown. UPS is ok to weather the power
> shortage, a battery inside the power supply would allow for clean shutdown.
It shouldn't even need to be enough to shutdown -- all it needs is to dump the
RAM and processor state (register contents and such) to a designated area on
the hard drive (or flash RAM dedicated to this purpose, or whatever) from which
the BIOS firmware can restore everything when power comes back. The OS would
not even need to know the power was ever out, except to fix the system time.
Cut that out, or I will ship you to Norilsk in a box.
Kind of like the fear I get when I hit "Shut Down" on our Windows server, when all I want to do is log out. (Not only that, but you have to press Start to stop the computer.)