g r o t t o 1 1

Peeve Farm
Breeding peeves for show, not just to keep as pets
  Blog \Blôg\, n. [Jrg, fr. Jrg. "Web-log".
     See {Blogger, BlogSpot, LiveJournal}.]
     A stream-of-consciousness Web journal, containing
     links, commentary, and pointless drivel.


On My Blog Menu:

InstaPundit
USS Clueless
James Lileks
Little Green Footballs
As the Apple Turns
Entropicana
Cold Fury
Capitalist Lion
Red Letter Day
Eric S. Raymond
Tal G in Jerusalem
Secular Islam
Aziz Poonawalla
Corsair the Rational Pirate
.clue

« ? Blogging Brians # »





Book Plug:

Buy it and I get
money. I think.
BSD Mall




 10/6/2003 -  10/8/2003
 9/29/2003 -  10/5/2003
 9/22/2003 -  9/28/2003
 9/15/2003 -  9/21/2003
  9/8/2003 -  9/14/2003
  9/1/2003 -   9/7/2003
 8/25/2003 -  8/31/2003
 8/18/2003 -  8/24/2003
 8/11/2003 -  8/17/2003
  8/4/2003 -  8/10/2003
 7/28/2003 -   8/3/2003
 7/21/2003 -  7/27/2003
 7/14/2003 -  7/20/2003
  7/7/2003 -  7/13/2003
 6/30/2003 -   7/6/2003
 6/23/2003 -  6/29/2003
 6/16/2003 -  6/22/2003
  6/9/2003 -  6/15/2003
  6/2/2003 -   6/8/2003
 5/26/2003 -   6/1/2003
 5/19/2003 -  5/25/2003
 5/12/2003 -  5/18/2003
  5/5/2003 -  5/11/2003
 4/28/2003 -   5/4/2003
 4/21/2003 -  4/27/2003
 4/14/2003 -  4/20/2003
  4/7/2003 -  4/13/2003
 3/31/2003 -   4/6/2003
 3/24/2003 -  3/30/2003
 3/17/2003 -  3/23/2003
 3/10/2003 -  3/16/2003
  3/3/2003 -   3/9/2003
 2/24/2003 -   3/2/2003
 2/17/2003 -  2/23/2003
 2/10/2003 -  2/16/2003
  2/3/2003 -   2/9/2003
 1/27/2003 -   2/2/2003
 1/20/2003 -  1/26/2003
 1/13/2003 -  1/19/2003
  1/6/2003 -  1/12/2003
12/30/2002 -   1/5/2003
12/23/2002 - 12/29/2002
12/16/2002 - 12/22/2002
 12/9/2002 - 12/15/2002
 12/2/2002 -  12/8/2002
11/25/2002 -  12/1/2002
11/18/2002 - 11/24/2002
11/11/2002 - 11/17/2002
 11/4/2002 - 11/10/2002
10/28/2002 -  11/3/2002
10/21/2002 - 10/27/2002
10/14/2002 - 10/20/2002
 10/7/2002 - 10/13/2002
 9/30/2002 -  10/6/2002
 9/23/2002 -  9/29/2002
 9/16/2002 -  9/22/2002
  9/9/2002 -  9/15/2002
  9/2/2002 -   9/8/2002
 8/26/2002 -   9/1/2002
 8/19/2002 -  8/25/2002
 8/12/2002 -  8/18/2002
  8/5/2002 -  8/11/2002
 7/29/2002 -   8/4/2002
 7/22/2002 -  7/28/2002
 7/15/2002 -  7/21/2002
  7/8/2002 -  7/14/2002
  7/1/2002 -   7/7/2002
 6/24/2002 -  6/30/2002
 6/17/2002 -  6/23/2002
 6/10/2002 -  6/16/2002
  6/3/2002 -   6/9/2002
 5/27/2002 -   6/2/2002
 5/20/2002 -  5/26/2002
 5/13/2002 -  5/19/2002
  5/6/2002 -  5/12/2002
 4/29/2002 -   5/5/2002
 4/22/2002 -  4/28/2002
 4/15/2002 -  4/21/2002
  4/8/2002 -  4/14/2002
  4/1/2002 -   4/7/2002
 3/25/2002 -  3/31/2002
 3/18/2002 -  3/24/2002
 3/11/2002 -  3/17/2002
  3/4/2002 -  3/10/2002
 2/25/2002 -   3/3/2002
 2/18/2002 -  2/24/2002
 2/11/2002 -  2/17/2002
  2/4/2002 -  2/10/2002
 1/28/2002 -   2/3/2002
 1/21/2002 -  1/27/2002
 1/14/2002 -  1/20/2002
  1/7/2002 -  1/13/2002
12/31/2001 -   1/6/2002
12/24/2001 - 12/30/2001
12/17/2001 - 12/23/2001
Thursday, November 14, 2002
12:05 - Progress Bars

(top) link

I was just burning a CD in iTunes, something I don't normally do very often, while trying to reproduce a problem that Joe User described in burning non-iTunes-created MP3s onto CDs. (I wasn't able to recreate the error. I hate when this happens-- everything works perfectly for the self-described advocate, but things break unaccountably when performing for an impartial third party who is prepared to pull no punches about things that break.)

But I noticed something that I think is new in iTunes 3.0: a timer on the CD-burning progress bar. I don't think earlier versions had the countdown. I don't burn many CDs, but I seem to recall that the last time I did it, there were separate "Burning" and "Verification" stages, and no timer for either one. This is a nice change.

And it brings up a little example of the Mac OS design sensibility, something that I find makes Mac apps (particularly those written by Apple) consistently more enjoyable to use than their Windows counterparts. That is the guideline that If you must display only a single progress bar for a process, that progress bar should cover the entire process, not just whatever intermediate subprocess you're in at the moment.

For the longest time, for example, Windows was coded so that if you had dragged a group of files from one disk to another to copy them, the progress bar would show only the progress on each individual file-- resetting as each file was copied-- rather than the entire process of copying the files, which is the command the user gave ("Copy this set of files"). Recent versions of Windows fixed this, by showing two progress bars, one of which is for the overall process; but the second bar is still reminiscent of the uselessness of the old way, fluttering between "empty" and "full" in an endless seizure-inducing flicker.

(Another favorite of mine is how Windows 2000 has a progress bar in one of the text-based startup screens. It's probably the shortest phase of the startup process, and only one of four or five major steps, the rest of which don't have progress bars. You wait for thirty seconds to get to the progress-bar screen, which then takes five seconds; then you wait another thirty seconds for Windows to come up and log you in. Joyous. Whereas while the gray-screen initial phase of the OS X boot process can be quite long, the progress bar that comes up after that phase completes is much more representative of the time actually required before you can use the machine.)

OS X has been reaffirming Apple's commitment to the usefulness of the "whole process" method, in areas like app installers and CD burning. It does make tons more sense-- after all, the user wants to know how much time is remaining before he can start using the machine again, not how long it is until the next in an opaque and mysterious series of steps, its description meaningful only to the software itself, is undertaken. There is some unavoidable inconsistency, naturally, and different programs handle it differently: the Installer program has no way of knowing how long the update_prebinding task ("Optimizing") will take, so it continues to report "Less than a minute remaining" while the "Optimizing" phase takes the five to ten minutes or so that it ends up requiring (though recently they've added a live-updating percentage counter, which is helpful). And iTunes gives you the slowly-rotating "barber pole" bar during the "finishing" phase at the end of a burn process. But other than that, a progress bar on a Mac typically means your meaningful progress, not just a piece of moving feedback to reassure you that the computer hasn't crashed.

It's a minor thing, but it's the minor things like this that Apple engineers sweat over.



UPDATE: Reader Jeff Borisch adds this rejoinder:

Silly Boy, the fluttering progress bar is part of the Windows PSYOPS campaign to make Windows appear much faster than the Mac.

"See look at that progress bar, this PC here is getting much more work done while the Mac whose progress bar just sits there practically still"

My point is, perception of performance is more important than reality.

My Mac advocate boss is repeatedly disheartened when he sits at the 2GHz Dell we have in the office and is astonished at how fast the screen redraws compared to his mac with 2 1GHz processors. I say "But do you get your work done any faster when you sit at this PC."

Not to mention when we unboxed said Dell, there was a clunking from inside the case. it was one of the exhaust fans and the baffle that sucks air over the processor flopping around unattached, doing no good at all. Good thing that P4s have that processor cycling overheating protection. Feh!

Touché.



Back to Top


© Brian Tiemann