[Tfug] Progress indicators

Paul Lemmons paul at lemmons.name
Wed Jan 14 23:37:40 MST 2009


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
>>
Progress indicators should have one main purpose that should not be 
lost. That being that it indicates progress. I have seen some very 
clever ones and some really stupid ones. The worst ones are those that 
indicate progress of each task and not the over all. You see this little 
blue bar zip to the end quickly, seemingly hundreds of times, giving you 
no real information. Even the bars that are inconsistent in the speed at 
which it reflects completeness are better than those.

The most clever I have seen was actually done by Microsoft in the 
install of Age of Empires. They had some little fellows with hammers 
building a wall or castle or something and it was cool to watch. When 
the edifice was finally erected, the program was installed. Probably 
overkill but still it was interesting enough to make an impression and 
cause me to comment positively on something that Microsoft did.

The done vs. remains is a not answerable for everybody. Some like to see 
progress, others like to know how much is left. To meet the needs of 
both whatever progress meter you design should have a visual means to 
determine both. An example might be a graphical representation of two 
buckets. A character walks between them with a dipper carrying bits from 
one bucket to the other. I can ether watch one bucket dran and see 
progress or watch the other fill to visually note how much is left until 
it is full.

I do prefer the meters that travel at a steady rate. I can see where 
this might be difficult to actually accomplish but still it is my 
preference.

I am not a minimalist. There is a certain "class" and "professional 
polish" that should be applied to any product that goes to market. The 
fancy graphics may seem like a huge waste of time but they usually offer 
the first impressions of the product. If I see a blank screen with a 
twirler in the middle I wonder if that same laziness pervades the whole 
product. If I see something that shows skill, polish and artistic talent 
during an install, I expect good things to follow. It is the way the 
brain works; especially for the average non-technical user.

The visual paradigm would change once the application is running, 
though. If you are writing an FTP client you need your status meter to 
be useful and a natural addition to the visual art and appeal of the 
application.The buckets example above would be difficult to do right in 
this scenario.

If you are going to use a plain old standard, progress bar then it does 
not really matter if it fills left to right or right to left or bottom 
to top or any other direction so long as it is obvious where you are at 
and that it represents the progress of the complete task.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3296 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20090114/65539fe3/attachment-0002.bin>


More information about the tfug mailing list