[Tfug] Progress indicators

[Stott, Will]

I 2nd this law and I motion for one step further! Make fun of the users while you make them wait! Yay! Progress bars need to step back in time when phrases like ID-10-T errors, pebkac, and picnic were secret forms of technical jargin that users weren't privy to. Let's have the progress bars tell them now! Maybe they could even shoot out audio clips! 

Ok, sorry for the moment of user abuse. Back to the regular schedule.

Will

----- Original Message -----
From: tfug-bounces at tfug.org <tfug-bounces at tfug.org>
To: bexley401 at yahoo.com <bexley401 at yahoo.com>; Tucson Free Unix Group <tfug at tfug.org>
Sent: Wed Jan 14 05:14:04 2009
Subject: Re: [Tfug] Progress indicators



Poag's Law:  All progress indicators lie.

Most users are satisfied just knowing that tangible work is being done, 
beyond just a spinning busy pointer or hourglass. For example, if 
they're downloading a file, show them how many KB/sec it's coming in at, 
rounded to 2 or 3 decimal places and updated 10-20 times per second, so 
they can see it flit around randomly.... Staring at a static, averaged 
speed reading that never changes is no fun for anyone.

One of the things I loved about my Commodore 64 was when intros that 
pirate groups slapped onto the front of releases would decompress and 
execute. Since memory was pretty scarce, usually screen memory was 
used...so the screen would randomly fill with garbled characters and 
flash all sorts of crazy ass colors..You at least knew something was 
happening, versus if it were done "cleanly" by not corrupting the screen.

Better to overinform the user into a state of amusement than underinform 
them into a state of suspicion.

Cheers,
Bowie




Bexley Hall wrote:
> Hi,
>
> What's the "best" way to convey to a user the "progress"
> made on completing a task?
>
> It seems like most indicators convey "work done" -- where
> work is usually defined as bytes moved, etc.
>
> Or, they are calibrated in completely bogus, nonlinear
> units (e.g., progress indicators that chug along merrily
> at a seemingly constant rate, then *jump* ahead, then
> *stall* -- even though the process is obviously
> continuing at the same "speed" as before, etc.).
>
> Does it make sense to use different means for different
> tasks?
>
> Or, do users tend to think of tasks in terms of the amount
> of *time* required ("Who cares if X bytes have been transfered
> and that represents 12.673% of the total...  how much of this
> is *finished* vs. how much REMAINS??")
>
> --don
>
>
>       
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>
>   


_______________________________________________
Tucson Free Unix Group - tfug at tfug.org
Subscription Options:
http://www.tfug.org/mailman/listinfo/tfug_tfug.org