Reported by: Anonymous

 

Duration: 5

 

Supplier: Apple

 

Alias: 

 

Product: 

 

Bug: Years after its introduction, Firewire remains flakey.  Firewire disk drives often fail to mount, although frequently then mounting without difficulty after restarting Mac OS X.  Sometimes all the data on the drive is lost.  Bug fixes result in partial solution, with the problems recurring after subsequent OS updates.

 

Class of Error: Refusal to admit that a very serious problem has not been fully solved and to devote sufficient engineering resources to identify and fix an obscure and intermittent issue, possibly with multiple causes.

 

Principle:  Reliable performance is a cornerstone of the successful user experience.

 

Discussion: Having hard drives be unreliable makes backup much more difficult and expensive.

 

Bug first observed: 2000

 

Bug on list since: Jan 2005

 

Bug: Disk Drive Timeout

 

Reported by: Darrin Cardani

 

Duration: at least 20 years

 

Supplier: All as far as I know, but definitely Apple

 

Alias: “Wait until I'm done thinking about it...”

 

Product: The Finder, and most other products that include network connectivity.

 

Bug: When the Finder realizes that a network disk is no longer connected, you have to wait up to 2 minutes to do anything else in the Finder as it tries to reconnect.

 

Class of Error: "threading is hard!"

 

Principle: During long operations, the user should be able to do something else while the computer thinks about whatever it's doing.

 

Proposed Fix: If the Finder realizes it has lost connectivity with a network drive, it should first offer the user the choice of trying to reconnect immediately or just forgetting about it. Then, if the user agrees to reconnect, it should start a thread to do the reconnection, allowing the user to do something else in the meantime.

 

Discussion: I'm guessing this bug started back when the system could only do cooperative multi-tasking and it was just easier to have the Finder halt until it could remount the drive. But now that we have all the power of a fully preemptive OS, it should be a non-issue.

 

Bug first observed: I first ran into it around 1990, but I'm sure the problem existed before then.

 

Bug reported to Supplier: OK, I admit I've never reported it because it always seemed so bloody obvious!

 

Bug on list since: Jan 2005

 

 Operating Systems, Browsers, et. al.

 

Bug: Inappropriate OK/Cancel

 

Reported by: Dimiter Simov

 

Duration: [?]

 

Supplier: Everyone

 

Alias:  “Would you like soup or salad? OK  Cancel”

 

Product: All

 

Bug: When the program has something to tell the user, it does it through a message box, and the way to continue is to click a button that says Yes, No, OK or Cancel.

 

 Class of Error: 

 

Principle: 

 

Proposed Fix: Modeless feedback is not always possible, nor is it achievable in the foreseen future, so build a message box that accepts all kinds of message closings.

 

Discussion: The problem is that the buttons used to end a message have no intrinsic relation to the content of the message. Designers and developers use them because the 'system' will not let them use something else or because that's how it has always worked or because it's too much work to make a custom message box.

 

Copywriters often have to tweak their texts in order to make them match the endings, although picking endings that are appropriate for the message text is a more natural approach. Users suffer too; they are prone to make mistakes in this context. It is a well known fact that people prefer to scan not read, and if they can avoid reading, they will do it. So when they scan and see OK and Cancel (the two most visible elements) at the end of the message they have no idea what the message is about, so they either read the text or click the button that feels safer, looks nicer, is closer to the mouse, or whatever they decide their reason to be.

 

Consider an example: Standard: You made some changes, do you want to save them. OK/Cancel Better: You made some changes. What do you want to do with them? Discard the changes / Save the changes

 

Bug first observed: 1993 - when I first started using a computer. (I did not know then it was a bug.)

 

Bug on list since: Jan 2005

 

Bug: Defective Disk Copy

 

Reported by: Anonymous

 

Duration: 5

 

Supplier: Apple

 

Alias: 

 

Product: Mac OS X

 

Bug: Mac OS X does not make an accurate copy of a disk.  In Mac OS 9, if you drag a disk to another, you get an exact copy that works correctly.  In Mac OS X, if you drag a disk to another, it produces a defective copy that will not boot.

 

Class of Error: Laziness

 

Principle: Failure to properly hide the OS' internal details must never result in data loss or loss of function.

 

Proposed Fix: Disk utilities such as Carbon Copy Cloner have for years been able to copy a disk. Using the GUI to copy a disk should always result in an accurate copy.

 

Discussion: It is unbelievable that the GUI fails to use the tools built into the OS to correctly copy disks.  Backup utilities mostly would not be needed if the file copy operation used by the GUI worked correctly.

 

Bug first observed: 2000

 

Bug reported to Supplier: 2000

 

Bug on list since: Jan 2005 

 

Bug: Dumb File Copy

 

Reported by: Anonymous

 

Duration: 20 years

 

Supplier: Apple

 

Alias: 

 

Product: Mac OS 9, X

 

Bug: Files are slowly copied (rewritten) even when there is no difference between the source and destination.

 

Class of Error: Failure to detect and skip time consuming operations that do nothing

 

Principle: Don't waste time performing operations that result in no change, when it is easy to detect that such useless operations are unnecessary.

 

Proposed Fix: Third party utilities have been around for years to do smart copying.  This should be built in.

 

Discussion: Backup utilities mostly would not be needed if the file copy operation used by the GUI worked correctly.

 

Bug first observed: 1980's

 

Bug on list since: Jan 2005

 

Bug: Non-moveable window modal dialog boxes

 

Reported by: Tog

 

Duration: Since release of OS-X

 

Supplier: Apple

 

Alias:  Back to the Future

 

Product:  OS-X and every product that runs on OS-X

 

Bug: When you attempt to Save As... a document, a great hulking dialog sweeps open, covering most or all of the document, demanding a new name. Unfortunately, you can’t see the document you’re working on anymore, so often you have to close the dialog to work out exactly what the name should be.

 

Class of Error:   Deciding that “cute” is more important that “useful.” Continuing lack of User Testing.

 

Principle: It should be possible to "tear off" window modal dialog boxes.

 

Proposed Fix: Dragging on "Save As..." and similar dialogs should “tear them off” the top of the underlying window

 

Discussion:

 

We got rid of modal dialogs at Apple in around 1986 because we found that users often needed to see the document itself in order to formulate the name.  Humans have not evolved a lot in the ensuing years and cannot be expected to have developed the eidetic memories necessary to preclude the need for moveable dialogs.  In 1980, thinking a dialog need not be moveable reflected an understandable lack of knowledge.  Now, it is just embarrassing.

 

Bug first observed:2001

 

Bug on list since: Jan 2005

 

Bug: Page-orientation in wrong place

 

Reported by: A. Schmitt

 

Duration: 20 years

 

Supplier: Apple

 

Product: OS-X

 

Bug: Setting the orientation for printing takes place elsewhere

 

Class of Error: Illogical and unpredictable option location

 

Principle: Consistency with Expectations

 

Proposed Fix: Place portrait/landscape settings in the Print dialog, since they have only to do with printing

 

Discussion: This is a glaring bug that has driven me nuts on the Mac since forever.

The page portrait/landscape setting can only be changed via "Page Setup" dialog. Or the page scale, or paper size. But some(many)times, you want to change them after you've selected "Print..." Why can't these be changed when printing, there in the printing dialog? Instead, you have to cancel the print dialog, go find and select the Page dialog, save that, and go back and try the print dialog again. So why isn't the "Page Setup" information a part of the "printing" dialog?

 

In fact (I wonder), Why are these two separate at all???

 

Curious minds want to know.

 

Discussion by Tog: “Page setup” can be claimed to affect the document, rather than the printer, since the resulting values are stored with the document.  In the Mac’s original 128k of RAM world, you could only have a small slice of the application resident at any one time.  Having the rationale that page setup was different than printing allowed the early Mac OS developers to break it away into its own unit.

Many people now have more than 128 of RAM.  In fact, many people now have more than 128 meg of RAM.  I suspect we could now combine the two.  Since the current print dialog is horrible anyway, this would provide a good excuse to do something about it.

 

Bug on list since: Jan 2005 

 

Bug: Can't position disk icons on desktop

 

Reported by: Colin Biggin

 

Duration: Since System 7

 

Supplier: Apple

 

Alias: "Can't get no Sat-Disk-Faction"

 

Product: Finder

 

Bug: We can position on the desktop any file or folder or alias or pretty much anything EXCEPT one: disks (or partitions of disks)... these magically MUST get positioned by the finder at the top right. Why? OK, I understand that as the default but if I move them, why isn't my new position saved?

 

Class of Error: User-frustration

 

Principle: The user is in control

 

Proposed Fixes:  Fix the automatic positioning so it actually works.   Allow the user to right-click on these icons and turn them into Windows-style volume icons that can be moved to the user’s desired locations.

 

Discussion by Tog: OS-X currently mishandles automatic volume icons.  It will quite often put the icons for two different volumes right on top of each other.  It will also often fail to mount a volume at all, It further seemingly places the icons in random order, with the exception that the root volume ends up at the top.

 

Windows avoids all of this by not having dynamic volume icons at all.  I don’t favor the Windows solution, but it does have advantages, and Mac should offer static icons as a by-volume option.  That enables the user to pre-set the locations of their normally-used volumes, such as their primary and back-up disks, then have any temporary volumes, such as CD-ROMS, dynamically appear.  Static icons, as with the Windows, would appear with red question marks should, for example, the back-up disk be off line.

 

Bug first observed: 1983

 

Bug reported to Supplier: I've never reported it... but I should... just to see what message I get back. I'm sure it would be something like: "Not a bug. That's just the way it is... cretin!" [You never know.  I wrote the Apple Store in September 2004, suggesting they “decrypt” their 1-800-My-Apple phone number by also showing the digits and, three months later, received a very polite note saying they had made the change, which they had.]

 

Bug on list since: Jan 2005

 

Bug: Difficult to resize windows

 

Reported by: B. Bartram

 

Duration: Since release of OS-X

 

Supplier: Apple

 

Product: OS-X

 

Bug: Unlike NeXTStep, Windows, et. al., OS-X windows can only be grown from the lower right hand corner

 

Class of Error: Retrograde design

 

Principle: The user is in control

 

Proposed Fix: Adopt contemporary sizing capabilities

 

Discussion: As a PC user who recently purchased a Mac for video editing, it burns me every time I try to resize a window in OSX.  How come on my PC I can select any of the four sides of a window and change its dimensions, but my “more stylistically designed and user-friendly” Mac only allows me to drag from the lower-right corner?  This means, to get the window sized and where I want it, I have to first place the upper-left corner, then drag out the lower-right, making the whole process takes about 5X longer than it should.

 

Discussion by Tog:  Often, not being able to size a window by anything other than the lower right-hand corner “handle” is simply a bother.  Other times, such as when the bottom of the window is either off-screen or hidden beneath a floating object, it becomes a real problem.  The only way to recover is to maximize the window, then manually shrink it to the desired size.  This kind of operation will always interrupt the current cognitive flow, causing the user to lose far more time than even the duration of the recovery operation.  The recovery is often further exacerbated by applications that maximize to the full size of huge screens even though the largest practical width is far narrower and even though the Apple Guidelines have always said, "Don't do that!" (I trust the Adobe Acrobat people are listening.)

 

Bug on list since: Jan 2005 

 

Bug: CD-ROM eject button missing

 

Reported by: Matt

 

Duration: 25 years

 

Supplier: Apple

 

Product: OS

 

Bug: New users can’t find the disk eject button; experienced users can’t eject disks during abnormal operation

 

Class of Error: Designers aren’t users

 

Principle: The User is in Charge

 

Proposed Fixes by Tog: Put in a real button, or at least drill a hole for a paper clip

 

Discussion: There is no button near the CD-ROM slot to eject the CD.  I realize this is supposed to make things prettier.  I realize you can eject CDs either by dragging them to the trash or by pressing the eject key on the keyboard.  The first of these is lousy because most users think that CDs are hardware, so why would you graphically eject one?  The second is lousy only because it is so far from where you put the CD in; it's not obvious where to look for the key, especially on desktop systems.  The first time I encountered this, I looked for 2 or 3 minutes for the eject key and ended up having to Google.

 

Discussion by Tog: Starting with the Lisa, Apple’s systems engineers commandeered the eject buttons.  On many of Apple’s latest computers, the soft eject button is crammed onto some key somewhere not every close to the disk drive slot.  Instead ot labeling it with, oh, I don’t know, words, they’ve used the universal symbol for “what the heck is this?”

 

Lately, they’ve further degraded usability by removing the time-honored paperclip hole, through which generations of experienced Mac users have triggered a mechanical eject.  This further degradation brings the Mac in line with VCRs, which also die with the last tape in place.  Not that the tape is in place by the time the VCR reaches the landfill.  Instead, there’s a large hole hammered through the case.  (The VCR couldn’t be brought to the repair shop, because of the nature of the tape involved.)  I suspect we will see a new generation of PowerBooks strewn across the landfill, pried apart to release the last CD-ROM inserted.

 

Really, guys at Apple.  I know your boss doesn’t actually use the product, but some of us out here do.  Think about it before you cave in on saving 0.5 cents by not drilling a hole.

 

As for dragging the disk to the trash, that has been fixed in OS-X.  Now, you drag the disk to a giant picture of the “what the heck is this?” symbol.  Progress marches on!

 

Note:  I want to thank my neighbor, Fred, for information on the VCR problem.  I had no idea...

 

Bug on list since: Jan 2005

 

Bug Name: Forced Formatting

 

Reported by: Mike Perry

 

Alias: The Ransom Note Effect

 

Slogan: “All Text Pasted Our Way!”

 

Duration: Since 1984

 

Supplier: Apple

 

Product: All Mac OSs

 

Bug: Cut and paste always retains as much formatting as possible.

 

Class of Error: “We know what you want better than you do.”

 

Principle: Software should just work without a lot of klutzing around.

 

Proposed Fix: Create global and document-level preferences that allow users to specify what formatting is pasted and what is not. Users could select to paste only the characters, the characters plus style formatting like italic, or all formatting including the font, color and size.

 

Discussion by Mike, with significant modification by Tog: This started out as a feature at the dawn of desktop publishing before there was email, before there was the Web. Users could lift material from their previous documents and paste it in without losing style information. Because people generally typed in the same size and using the same font, it worked cleanly and easily.

Today, people are routinely copying and pasting selections from the Web. There's no simple way for the user to block anything—weird colors and fonts are copied verbatim. No one writing applications seems to have realized that most users want text to take on the formatting, with the possible exception of style, of the target document rather than the source document. Adding to the frustration is that anything you yourself type after pasting in the 24 point Helvetica will now also be in 24 point Helvetica.

 

For serious work, the result is a disaster. Strong user demand drove InDesign to create a way around this bug for users. The reason is obvious. Someone creating a document in Adobe Caslon Pro doesn’t want to discover, after 50,000 copies are printed, that random portions of the book use some quirky font, often one that looks almost identical on the screen, though very different in print.

 

Discussion by Tog: Apple operated on the theory that receiving applications could strip off formatting information if they chose, whereas if it were never sent, options would be limited.  This is the correct strategy, and the fix has precedent in the “Paste Special” command in various GUI applications.  Unfortunately, Apple has failed to evangelize a fix to address the emerging problems caused by email and the Web, by telling developers to make it easier to follow the target document's style, rather than the source document's style.

Reader Chris Thomas reports that Apple itself has added to TextEdit a "Paste With Current Style" option that mimics Word. Unfortunately, the TextEdit command requires a total of four keys to be held down simultaneously for the keyboard "shortcut," with no simple way to use an easier shorcut. (Yes, I know you can remap anything to anything, and so can I, but 99% of Mac users can't.) Tex-Edit Plus only requires three keys held down simultaneously, but moves the option to level two of a hierarchical menu. Still not the right solution.

 

Bug first observed: 1984

 

Bug Reported to Supplier: circa 2000

 

Bug on list since: Jan 2005

 

Bug Name: Drawer-itis

 

Reported by: M, with credit to Deeje

 

Duration: Since 2001

 

Supplier: Apple and OS-X and its application developers.

 

Alias: ÔYour point was?’

 

Product: Too many OS X applications

 

Bug: Drawers everywhere, used for things they aren’t good for and/or aren’t recommended for, on top of which the implementations are inconsistent and often very poorly thought out, and the standard appearance of drawers does a poor job of indicating what they are supposed to be: sub-windows belonging to a main window.

 

Class of Error: Ooh a new toy! We thought it’d be cool!

 

Principle: Match the tool to the job, make it work right and consistently.

 

Proposed Fix: Replace usage of drawers with UI elements better suited to the task at hand, e. g., panes, toolbars, pallets etc., for the kind of high usage stuff that’s been stuffed into drawers against both Apple’s HI Guidelines and reason. Do so in every case.

 

(Sorry ÔApple’, there doesn’t appear to be anything a drawer is the best way of doing.)

 

Instead use sheets, panes, toolbars, pallets etc for the sort of secondary controls the HIG suggests putting in drawers.

 

Discussion: see “Mac OS X UI Thoughts: Source Lists don’t belong in Drawers”: http://blog.deeje.tv/musings/2004/11/mac_os_x_ui_tho.html

 

Discussion from Tog:  Drawers are being misused by Apple and by developers.

 

The most comical, if frustrating, use I’ve seen was in QuicKeys X2, almost worth its cost just for its humor value.  They had the current script step in the main window, with the source list of steps in the drawer.  It was a case of the tail wagging the dog, specifically recommended against in the Apple Guidelines. 

 

The problem arose because different kinds of steps require different display area. Some have few options, with just a tiny dialog a few lines high, while others have many options and grow the window to almost full screen height to display them all.

 

They should have been computing the maximum necessary size and fixing the window to that size, as was done with Apple Mail, which also breaks the Guidelines.  That would allow the step list to remain full-height and stable.  Instead, QuicKeys X2 window changed height with each move up and down the list of steps, expanding and shrinking the step list with it. One second, you’d see all the steps, the next you’d see only the top few, with the current step hidden, one more cursor key press and you were back to seeing them all. The result was, as you scrolled through the list, both the main window and the drawer with the steps themselves jumped around as though their pants were on fire.

 

X2 was eventually replaced with X3.  The new one had an interface not nearly as humorous.  However, while some of the missing functionality was restored from previous versions, they veered off once again into left field when it came to graphic design, often taking up three lines when one was called for, making it impossible to see the entire script.  They had gotten beaten on for the stupid drawer trick, however, lacking any design skills, were fated to just move on to the next set of design errors.

 

It’s a lesson to be learned by engineering managers who insist on saving a few bucks by forcing engineers to do design:  The best you can expect is a trail strewn with differing failures, showing little or no forward progress, the exact same outcome you’d experience if you insisted that and HCI designer like myself write your system software, something I have neither the talent nor training to accomplish.  To borrow an example from the building trades, architects tend to make lousy carpenters and carpenters tend to make lousy architects.  Accept that we have differing strengths and stop wasting your customer’s time and money with either junky designers or junky coding.  Hire people appropriate to the task.

 

Such fiascos also make you wonder why Apple released a half-developed object like drawers without even the most rudimentary user-protections.  If the focus is in the drawer, why is an application even allowed to shrink the main window, dragging the drawer with it?  Oh, wait!  I know!  Apple closed all their usability labs because they are all a big waste of money.

 

Bug on list since: Jan 2005

Bug Name: The disk drive nazi

Duration: >25 Years

Supplier: Apple Computer Inc.

Slogan: "No computer for you!"

Product: Lisa & Macintosh

Bug: "Unauthorized" removal of floppy or hard disks is punished severely

Class of error: "You're not in charge; we are"

Principle: The user is in charge and should be free to carry out any activity at any time without fear of reprisals

Discussion:

In 1979, the Lisa development team decided that users would not be permitted to remove disks without permission, saving the team from having to work out a way to recover from such an unplanned event. While this was a sharp reversal from the Apple II philosophy, given the Lisa team's RAM limitation (around a thousandth of what many people enjoy today), it was a reasonable compromise.

Let's move forward a quarter century or so. I now use a PowerBook computer. For backup, I've connected an external hard disk using FireWire or, as it's known in the human-oriented world of Windows, IEEE-1394. Periodically, I drag a few newly-created files onto the external disk. Otherwise, it just lays there humming.

In October of 2004, 25 years after the Lisa team's short-cut decision, I put my PowerBook into sleep mode, unplugged my auxiliary hard disk, and travelled 3000 miles to Europe to deliver a series of talks driven by slides from my Macintosh. When I attempted to wake the computer up, however, it failed. Nothing, including an emergency start-up CD-ROM, would allow me to reboot and recover.

Two weeks later, when I returned to the USA, I plugged in my auxiliary hard disk, pressed Power, and the computer started up normally.

Microsoft's GUI, from the beginning, gave users the freedom to remove their floppy disks without notice, recovering quite smoothly from the surprise events. (They haven't done as well with USB hard disk removal.) A solution exists. Heaven knows, Microsoft has copied enough from Apple. Turn about is fair play. Once Apple works out the hard disk version of the fix, Microsoft will copy that, too, making everyone happy.

Immediate Proposed Fix One: Repair boot routine so the system doesn't permanently hang if a previously-used auxiliary disk is not found.

Immediate Proposed Fix Two: Make system "aware" when boot has failed and have it offer a "safe mode" boot, as Windows has been doing for some time now. I later learned that OS-X has a safe-mode boot, triggered by pressing Shift while rebooting and holding your foot out the window. Apple has provided the magic sequence on their website, so, should you face a problem and can't remember the sequence, just search the Apple site—oh, wait! You can't search the site because your system won't boot!

Permanent Proposed Fix: Copy Microsoft's approach, giving Mac users the freedom to plug and unplug without punishment.

Bug first observed: 1979

Observer: Tog

Bug reported to Apple: 1985 (once we had enough RAM to handle a fix: 512k)

Bug on list since: Jan 2005