[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