 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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...
She wasn't interested in space before she met me, it's only when she saw
Saturn through the telescope that she thought it was really cool and started
to read a lot about it - she asks lots of questions. But it's a very fine
line to tread, if I try to make things too simple I get the "I'm not dumb -
god who did you date before me" line, but go too far the other way and you
get "ok i don't understand, i give up, don't bother".
> Heh, oh well. I was expecting the reply to be "I can't think of anything
> that Haskell would be useful for". ;-)
Well that too :-) I guess I just don't do much of the sort of stuff Haskell
would be really good for. OOC are there any "classic" examples of real life
stuff Haskell does better than other languages? Might give me some ideas.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> 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...
>
> She wasn't interested in space before she met me, it's only when she saw
> Saturn through the telescope that she thought it was really cool and
> started to read a lot about it - she asks lots of questions. But it's a
> very fine line to tread, if I try to make things too simple I get the
> "I'm not dumb - god who did you date before me" line, but go too far the
> other way and you get "ok i don't understand, i give up, don't bother".
Hmm. Apparently you have a very cool girlfriend...
[I'm not going to continue this train of thought any further. I don't
want to depress myself.]
>> Heh, oh well. I was expecting the reply to be "I can't think of
>> anything that Haskell would be useful for". ;-)
>
> Well that too :-) I guess I just don't do much of the sort of stuff
> Haskell would be really good for. OOC are there any "classic" examples
> of real life stuff Haskell does better than other languages? Might give
> me some ideas.
Parsers, compilers, interpretters, simulations, anything that does
complex algorithmic processing. (I hear it's popular for things like
financial modelling and IC design.)
Hypothetically Haskell _should_ be an excellent choice for things like
cryptography and data compression, but in practise the performance tends
to be suboptimal.
Anything where correctness is more important than performance or even
possibly development cost. (I hear Haskell is sometimes used in
safety-critical fields like avionics - although you don't actually *run*
Haskell on embedded systems, you use it to generate the code that will
be run, with strong guarantees about correctness of the generated code.)
Anything where parallel processing is useful. In theory this is the
Killer Advantage of Haskell; normal Haskell programs consist of about
98% pure code, which is inherantly thread-safe and hypothetically easy
to parallelise. Again, in practise performance is a little too variable
to claim that Haskell is the killer language for compute-bound problems.
As examples of some of the above:
- The Haskell Platform comes with Parsec, an impressive parsing library
which I'm *sure* I must have documented here at least once before.
- GHC itself is written in 98% Haskell. (Stuff like the garbage
collector and the I/O subsystem is written in C.) Think about it - what
do compilers do? They parse stuff, and they transform code trees. These
are both tasks which Haskell is excellent at.
- There's a small cottage industry for writing things like theorum
provers, constraint solvers, neural networks, genetic algorithms and the
like using Haskell. Writing these things typically isn't difficult;
making it efficient is the tricky part. ;-)
- Hell, you may even remember that I wrote a small logic equation solver
a while back. Remember? It could not only join to lists together, but
also UNjoin them in every possible way. ;-) OK, not terribly useful, but
quite satisfying to get it to work...
- I personally have also written ray tracers, fractal generators,
compression and cryptography algorithms, and all sorts of other crazy
stuff. If that's your thing, Haskell is a great way to write code
quickly. (Not necessarily code that runs quickly, sadly.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
