 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> But Windows progress bars do, in fact, go both forwards and backwards,
> seemingly at random. ;-)
The best is when it gets to 99 or 100% and then *starts again* at 0% !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> But Windows progress bars do, in fact, go both forwards and backwards,
>> seemingly at random. ;-)
>
> The best is when it gets to 99 or 100% and then *starts again* at 0% !
Or when it goes from 0% to 100% in about 0.1 seconds, and then sits at
100% for 25 minutes... Yeah, that's real useful, guys.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scott com> wrote:
> > But Windows progress bars do, in fact, go both forwards and backwards,
> > seemingly at random. ;-)
> The best is when it gets to 99 or 100% and then *starts again* at 0% !
There actually are some programmers out there (even pros) who have actually
not understood the idea of the progress bar. They seem to think it's something
akin go the spinning wheel which is often used when the total time is unknown
(ie. the spinning wheel simply indicates that something is being done, but
the program has no way of knowing how much will be done).
Other programmers (sadly a lot of them) understand the purpose of the
progress bar, but they don't understand how it should be used so that it's
actually informative to the user. The most typical error is that if the
task done by the program consists of dozens of sub-tasks (such as eg.
installing a dozen of files), the progress bar is used to indicate the
progress of each individual subtask instead of using it to indicate the
overall progress. Thus the progress bar becomes useless (and more akin to
the spinning wheel).
More competent programmers (or program designers) will put *two* progress
bars in the UI: One to indicate the progress of the sub-task and the other
to indicate overall progress. That's a whole lot more informative (although
the sub-task progress bar is not so useful if each sub-task is very fast to
perform, but more useful if they are slowish operations).
Of course even then there's room for incompetence: For example, a progress
bar that updates too rarely and makes big jumps, or which pauses for too
long at the beginning or the end (nothing is more confusing than having
the overall progress bar at 100%, but the program still doing things for
several tens of seconds). Of course depending on the task in hand it may
be quite difficult programmatically to update the progress bar smoothly,
but still...
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> There actually are some programmers out there (even pros) who have actually
> not understood the idea of the progress bar. They seem to think it's something
> akin go the spinning wheel which is often used when the total time is unknown
Yes, some programs just have some kind of wheel that lets you know that
it's doing *something*, even if it can't estimate how long it will take.
Which is fine - the problem comes when they make it look like it's a
"progress" indication, when in fact it isn't.
> The most typical error is that if the
> task done by the program consists of dozens of sub-tasks
> the progress bar is used to indicate the
> progress of each individual subtask instead of using it to indicate the
> overall progress. Thus the progress bar becomes useless.
Indeed.
> More competent programmers (or program designers) will put *two* progress
> bars in the UI: One to indicate the progress of the sub-task and the other
> to indicate overall progress. That's a whole lot more informative.
Yes. Although it still sometimes has the problem that some subtasks are
extremely fast, while others are insanely slow. Still, it does at least
provide a monotonically-increasing bar which fills up when the task is
done. It's just harder to estimate time remaining.
(Don't even get me started on "estimated time remaining"...)
> Of course even then there's room for incompetence: For example, a progress
> bar that updates too rarely and makes big jumps, or which pauses for too
> long at the beginning or the end.
Yeah, I hate that!
> Of course depending on the task in hand it may
> be quite difficult programmatically to update the progress bar smoothly,
> but still...
If you can't estimate progress in a meaningful way, don't pretend that
you can. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> If you can't estimate progress in a meaningful way, don't pretend that
> you can. ;-)
I actually had that problem with a puzzle solver I had to make for our
first iPhone game. (There's a glimpse of it here:
http://gamesandinnovation.com/2010/02/10/hopido-design-post-mortem/ )
The problem was that when the puzzle was large enough, the progress
would often advance like
0% -> 0.000001% -> 0.000002% -> ... -> 0.000158% -> 2.026041% -> 2.026042%
-> 5.0% -> 80.0% -> 100%, or similar. Just putting the percentage on
screen was not informative at all, no matter what I tried. (Often the
percentage would look like the program had halted completely because it
changed only so little that it would have required like 8 decimals to
show the change.)
What I ended up doing instead was to show the current search path as
lines of changing colors over the puzzle, updating a few times per second.
Doesn't tell you much about the progress, but shows clearly that the
program is doing something.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> If you can't estimate progress in a meaningful way, don't pretend that
>> you can. ;-)
>
> What I ended up doing instead was to show the current search path as
> lines of changing colors over the puzzle, updating a few times per second.
> Doesn't tell you much about the progress, but shows clearly that the
> program is doing something.
Right. And IMHO, that would be a correct solution. It makes it clear
that something is happening, without giving the user inaccurate progress
indications.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> (ie. the spinning wheel simply indicates that something is being done, but
> the program has no way of knowing how much will be done).
Not in Windows! :-) Try turning of the remote computer while you're
copying files to it with Explorer. Do you think those fluttering pages stop
flying from one folder to the other? NooooOOOoooo...
> the overall progress bar at 100%, but the program still doing things for
> several tens of seconds).
I will say I've seen this happen when the flush() call at the end actually
takes 30 to 90 seconds. Once you figure out what's going on, it's not that
bad, tho.
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Clearly I need to download the proper
> interpretter/compiler to answer these questions myself with a bit of
> playing around :-)
>
> OK so after Googling Haskell, implementations, GHC, go to the GHC page,
> latest release, "STOP!" they recommend I get the Haskell Platorm
> instead, oh goody a .exe installer link :-) I'll let you know in 54 MB
> time how I get on...
...so how did you get on?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> ...so how did you get on?
Other things came up ... I'm easily distracted...
Specifically, I wrote a simple graphical n-body gravity simulator (I *love*
C# and XNA) to explain a couple of things to my girlfriend, I've been
working on the GUI for my program to download and display tracks from my GPS
unit, and the Formula 1 season started :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> ...so how did you get on?
>
> Other things came up ... I'm easily distracted...
Heh, figures. ;-)
> Specifically, I wrote a simple graphical n-body gravity simulator (I
> *love* C# and XNA) to explain a couple of things to my girlfriend,
That's *advanced*, right there! o_O
I'm pretty sure if I tried to explain the rules of gravitation to a
girl, I wouldn't _have_ a girlfriend for very long...
(So much for "the gravity of love", eh?)
> I've
> been working on the GUI for my program to download and display tracks
> from my GPS unit, and the Formula 1 season started :-)
Oh. Another F1 fan...
Heh, oh well. I was expecting the reply to be "I can't think of anything
that Haskell would be useful for". ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
