 |
|
| Computers Forum Index » Computer Architecture - Embedded » Progress indicators... |
|
Page 2 of 2 Goto page Previous 1, 2 |
|
| Author |
Message |
| Paul E Bennett... |
 Posted: Sun Nov 01, 2009 2:48 am |
|
|
|
Guest
|
D Yuniskis wrote:
Quote: ChrisQ wrote:
Paul E Bennett wrote:
In several systems I have done I have used the usual "-", "\", "|" and
"/" characters spinning on the spot for tasks that would take some
time. The selection of the next character in the set was keyed to the
end of a specific repetitive portion of the task. This is a real
indication of activity and is suitable for a user interface on a small
embedded system.
Yes. But, hard to ensure each "step" is roughly the same size
(temporally). Of course, for "activity" this isn't as
important. But, for (cumulative) "progress" it becomes moreso.
I never bothered with trying to ensure an even period of time between
updates. The real event it the changes were keyed from was the confirmed
completion of the transfer of a block of data, or the intermediate task
complete marker achieved.
Quote: I think one of the probelsm with (existing) progress indicators
is that the interface to the indicator has no real global
knowledge of the entire process. Like Paul's implementation,
it just shows "progress" in some general sense and something
else (hopefully) "counts" these events and uses them to
update the overall indicator.
I always prefer some real event. It does not take much code to do the
indicator and to just call it at the end of an achievement point seems to be
a simple thing to do.
Quote: We used that technique a lot on terminal based systems and Sun systems
still use it during initial boot. You can get a bargraph percentage
complete effect the same way with a bit of ingenuity.
I think I just got the idea from some really old DOS software. I liked the
effect and it seemed to fit a lot of the things I was doing at the time.
These days I am not so much into having to feed human users such details.
The thing about doing distributed embedded systems is the other end of the
link is another machine. Much easier to satisfy than a human.
Quote: IIRC, some of the Sun installers spawn a task that just "runs an
(idiot) indicator" without any ties to the "worker task". I.e.,
you can "kill -9" the worker task and the indicator will sit
there merrily "indicating" (activity). I'd have to dig through
my journals to see which installer it was...
That does not sound like a very worthwhile indicator. I prefer activity
indicators to be tied to some real event in the process.
Quote: Seems to me that the most important thing is always to communicate.
Never leave the screen static, so that the user thinks the system has
crashed. On modern systems, pc software installs have this stuff down to
a fine art...
I still consider it important that the activity indicator is tied to a real
event for its update so that when the task crashes the indicator will either
not update or disappear from the screen (preferrably the latter with a
report of teh crash). Had a bar-graph indicator on some PC software that got
so far then froze. No further progress from that task and you get to wonder
why the wait. The rest of the Windows system still seemed to be running.
Never did sus out the reason for the hang.
Quote: But PC installers subscribe to the same sort of philosophy
that the paper Nils cited seems to address. I.e., entertain the
user so he isn't (as) annoyed with the slow progress. And,
they are notorious for their nonlinearity. I.e., take away
all of the accompanying graphics and other distractions and
you don't really have any *useful* information on actual
progress until you are actually *done*.
Give me real information anytime.
--
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett at (no spam) topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
******************************************************************** |
|
|
| Back to top |
|
|
|
| D Yuniskis... |
| Posted: Sun Nov 01, 2009 6:00 am |
|
|
|
Guest
|
Andrew Smallshaw wrote:
Quote: On 2009-10-30, ChrisQ <meru at (no spam) devnull.com> wrote:
Seems to me that the most important thing is always to communicate.
Never leave the screen static, so that the user thinks the system has
crashed. On modern systems, pc software installs have this stuff down to
a fine art...
In my experience most Windows installers get this hopelessly wrong.
There are ahs to be some kind of estimation made for the time taken
by different phases - for example, one phase may be CPU bound,
another disk or network bound. Since the balance between the
performance of different components can't be anticipated it is
impossible to say how much time each phases takes. Also some phases
But, I am suggesting that this is a consequence of the
"progress indicator" being an afterthought. The developer(s)
were focused on making sure the right files got copied,
registry settings, etc. and the idea that they would have to
communicate their progress to the user was something they
shoehorned in, after-the-fact.
I'm sure that same developer was under the impression that
the "install" is a one-time event (no doubt they had
never heard of the Grand Unified Solution: "reinstall
windows"!  . And, they probably also thought it
would be a much quicker process than it actually turned
out to be!
Had they had the user foremost in their mind when they
were working on this, they would have figured out how
to put enough scaffolding in place to drape a suitable
indicator over! And, how to make that indicator as
accurate as possible.
(N.B. unlike applications/tasks that run often, the
installer can't benefit from "past experience" so it
has a harder task before it)
Quote: don't seem to be counted at all. How many installs have you seen
where the progress bar moves quite quickly but takes an eternity
to initally shift from 0%, or at the other end move from 99% or
even 100% to completion?
Or, hang at "100%" (um, ok, we're 100% done... how much *more*
than 100 do we need to go??)
I am always amused at applications that have a "pause" feature.
Watching the estimated time remaining on many of these while
*in* pause shows you how little thought went in to the
progress indicator estimation algorithm. E.g., if there were
X seconds left at the instant the PAUSE was initiated,
should't the "time remaining" *stay* fixed at X seconds
for the duration of the pause?? (yet many estimators
ignore the fact that this is a deliberate pause and,
instead, look at the "total elapsed time", divide it by
the "finished work" and project this "average time per
unit work" out for the remaining portion of the task -- so,
the estimated time remaining keeps *increasing*!)
Quote: My preference would be for textual descriptions of activity: e.g.
a simple message like "Parsing archive header" for a phases
expected to be fairly brief, or for a longer phases something with
a further indication of progress: "Processed 2 out of 2721524
thingies..." Of course, that can be misleading too: if thingy
processing takes an hour it may be tempting to think the job is
almost done when it is completed, when in reality you may only be
10% of the way through.
(sigh) I regret having to keep falling back to desktop examples
but that's probably the one thing we can all "relate" to (since
I suspect our individual application domains differ significantly).
I think the windows folks *try* to keep the user from getting *too*
bored/frustrated -- by breaking the install into lots of steps
so the user has the illusion (?) of progress being made. Note that
this is also true of the windows startup (i.e., how many different
times/ways does it say "Starting Windows"??)
But, for the most part, augmenting the display with descriptive text
won't help the average user understand how much progress is actually
being made:
OK, so you've parsed the archive header. Great! What *else*
do you have to do? Was parsing the header a *significant*
achievement/milestone? Or, was that a trivial task and
the really *hard* (i.e., time consuming) stuff still lies
ahead? What should I watch for to know that we are really
"getting somewhere"??
Unless the user is intimately familiar with the activities
that are involved (like digging a hole in the yard), more
descriptive information will only help if the process crashes
and the user is observant enough to tell the customer support
folks: "The last thing it said was..."
It's sort of like a "low fuel" indicator on a car dashboard.
Sure, it draws the user's attention to the fuel gauge (in
case he had been oblivious of the fact that he was running
low on fuel). But, does it tell the user anything that
will *truly* help him? I.e., how far can I drive before the
car simply *stalls*? Should I pull off the highway at *this*
exit and risk finding a gas station nearby -- even though
there are no signs on the highway that deliberately indicate
the presence of "services" at this exit? Or, should I
gamble that there will be another exit up ahead that
*might* have fuel available??
Granted, there (currently) are no ways of conveying any
*more* information to the user. But, then again, years ago
there wasn't a "low fuel" indicator, either! |
|
|
| Back to top |
|
|
|
| D Yuniskis... |
| Posted: Sun Nov 01, 2009 6:00 am |
|
|
|
Guest
|
Paul E Bennett wrote:
Quote: D Yuniskis wrote:
ChrisQ wrote:
Paul E Bennett wrote:
In several systems I have done I have used the usual "-", "\", "|" and
"/" characters spinning on the spot for tasks that would take some
time. The selection of the next character in the set was keyed to the
end of a specific repetitive portion of the task. This is a real
indication of activity and is suitable for a user interface on a small
embedded system.
Yes. But, hard to ensure each "step" is roughly the same size
(temporally). Of course, for "activity" this isn't as
important. But, for (cumulative) "progress" it becomes moreso.
I never bothered with trying to ensure an even period of time between
Of course! You're just making an "activity indicator" not a
"progress indicator". You just need to ensure that you get around
to tickling it "often enough" that there are no extraordinary
pauses that the user could mistake as a "crash".
You could, however, have used these calls to "update_indicator()"
to, instead, take a snapshot of the system time and write it to
a (diagnostic) log file. And, either used that to reflect
where you *think* you are in the overall process (step M of N)
or simply count the number of such steps and pretend they
were equal.
I.e., this is the sort of approach I think most progress indicators
take -- "after-the-fact". I think they put "markers" in the
process (whether it is an "installer" or any other lengthy
task) and then use those to advance a simple *counter* where
the "terminal count" is a value that is filled in pseudo-manually.
Quote: updates. The real event it the changes were keyed from was the confirmed
completion of the transfer of a block of data, or the intermediate task
complete marker achieved.
Understood. You're not just indicating the passage of *time*.
Quote: I think one of the problems with (existing) progress indicators
is that the interface to the indicator has no real global
knowledge of the entire process. Like Paul's implementation,
it just shows "progress" in some general sense and something
else (hopefully) "counts" these events and uses them to
update the overall indicator.
I always prefer some real event. It does not take much code to do the
indicator and to just call it at the end of an achievement point seems to be
a simple thing to do.
Exactly. Much easier than trying to accurately reflect *where*
in the process you are.
I think there is a threshold beyond which folks want more
hand-holding. Or, *need* it (psychologically to ease the stress
brought about by uncertainty)
Quote: We used that technique a lot on terminal based systems and Sun systems
still use it during initial boot. You can get a bargraph percentage
complete effect the same way with a bit of ingenuity.
I think I just got the idea from some really old DOS software. I liked the
effect and it seemed to fit a lot of the things I was doing at the time.
These days I am not so much into having to feed human users such details.
The thing about doing distributed embedded systems is the other end of the
link is another machine. Much easier to satisfy than a human.
And, you can get more information *from* that other end if you
so desire! I instrument all of my servers and agents so that
their clients can obtain useful performance metrics from
them (instead of having to instrument themselves).
Quote: IIRC, some of the Sun installers spawn a task that just "runs an
(idiot) indicator" without any ties to the "worker task". I.e.,
you can "kill -9" the worker task and the indicator will sit
there merrily "indicating" (activity). I'd have to dig through
my journals to see which installer it was...
That does not sound like a very worthwhile indicator. I prefer activity
indicators to be tied to some real event in the process.
Exactly. It was actually counterproductive. The first time
the installer crashed (or maybe I kill(1)-ed it?) and the
indicator remained on the display, I was thoroughly confused:
"I thought the installer process had terminated? Why is 'it'
still 'spinning'??"
I think it falls in the category of "try not to let the user
get bored or nervous -- but don't actually give him any
useful information!" The paper Nils cited is insightful in
that there is no attempt made to provide better information
to the user but, rather, to *placate* the user in the most
effective way...
Quote: Seems to me that the most important thing is always to communicate.
Never leave the screen static, so that the user thinks the system has
crashed. On modern systems, pc software installs have this stuff down to
a fine art...
I still consider it important that the activity indicator is tied to a real
event for its update so that when the task crashes the indicator will either
not update or disappear from the screen (preferrably the latter with a
Yup. Sort of like making a watchdog routine *smart* (instead of
just "please tickle this address")
Quote: report of teh crash). Had a bar-graph indicator on some PC software that got
so far then froze. No further progress from that task and you get to wonder
why the wait. The rest of the Windows system still seemed to be running.
Never did sus out the reason for the hang.
This is made worse by the fact that the indicator is not
linear. I.e., if the indicator is going to hang for some
period of time, *tell* me this *or* come up with a better
indicator.
It's sort of like emitting a message "expect 23 shift/reduce
conflicts" in a makefile just prior to it invoking yacc...
the message tells the user not to fret over the message
that then appears (assuming the message *is* as indicated!)
Quote: But PC installers subscribe to the same sort of philosophy
that the paper Nils cited seems to address. I.e., entertain the
user so he isn't (as) annoyed with the slow progress. And,
they are notorious for their nonlinearity. I.e., take away
all of the accompanying graphics and other distractions and
you don't really have any *useful* information on actual
progress until you are actually *done*.
Give me real information anytime.
Besides elapsed time/time remaining (i.e., work done/work remaining),
I don't think most users can appreciate any more specific information.
You can set up a black-box to catch your logging and later get
that from the user (as a diagnostic). But, if the process
"appears to hang" once, chances are it will "appear to hang"
the next time, too! (if it is a real hang *or* if it is not
a real hang but, rather, just a "slow point" in the activity's
progress).
I get annoyed that my Windows server pauses for a considerable
time while it is booting. Have I forgotten to plug the network
cable in? Is it "timing out" waiting for a reply from my name
server? Or, is one of my disks not spinning up properly (hard
to hear over the fan noise)? Or, is something getting ready to
crash?
Unfortunately, Windows doesn't tell me what it is doing so I
can't reassure myself that "all is well" but must, instead,
wait and hope.
By contrast, booting one of my *BSD boxes is a very verbose
activity. I can see why it may be "stuck" if it *does* get
stuck. I feel more "in the loop" and, thus, more comfortable
working with those machines.
I think newer devices are getting sophisticated enough
that you can't simply ignore the user anymore. When your
tasks were fast/simple (relatively speaking), the user rarely
had to wait. And, if there was a wait, the user *accepted*
it because processors weren't as capable -- the mere fact
that he could have an electronic address book in his
shirt pocket made those inconveniences tolerable. :>
But, as devices become more capable, they tend to do more and
the possibility/probability of the user being inconvenienced
by the device increases.
E.g., I have a design that periodically has to "vacuum"
its database(s). This can be time consuming. This can
interfere with the normal operation of the device. If I
just "do my thing" and force the user to wait "as long as
it takes (but no longer!)", the user will quickly become
annoyed with the product. I can put a faster processor
in, add more memory, etc. All of these add to the cost of the
product, increase its complexity, decrease its reliability,
etc.
Or, I can tell the user to change his usage habits to
allow me to do things at more convenient times (which
is contrary to my user philosophy). Or, for the user
to do things that are more convenient for *me*! (which
is even more despicable!)
Or, I can provide the user with *good* feedback about
the length of time the task will take so he isn't
left in suspense. Perhaps allowing him to defer that
maintenance operation at the expense of some run-time
performance, etc.
My experience has been that if the user feels part of
the process -- and not a slave to it -- he will tolerate a
lot of things that he would resent if they were unilaterally
"imposed" on him. |
|
|
| Back to top |
|
|
|
| Paul Carpenter... |
| Posted: Sun Nov 01, 2009 8:52 pm |
|
|
|
Guest
|
In article <hcisdv$j7m$1 at (no spam) aioe.org>, not.going.to.be at (no spam) seen.com says...
Quote: Andrew Smallshaw wrote:
On 2009-10-30, ChrisQ <meru at (no spam) devnull.com> wrote:
Seems to me that the most important thing is always to communicate.
Never leave the screen static, so that the user thinks the system has
crashed. On modern systems, pc software installs have this stuff down to
a fine art...
In my experience most Windows installers get this hopelessly wrong.
There are ahs to be some kind of estimation made for the time taken
by different phases - for example, one phase may be CPU bound,
another disk or network bound. Since the balance between the
performance of different components can't be anticipated it is
impossible to say how much time each phases takes. Also some phases
But, I am suggesting that this is a consequence of the
"progress indicator" being an afterthought. The developer(s)
were focused on making sure the right files got copied,
registry settings, etc. and the idea that they would have to
communicate their progress to the user was something they
shoehorned in, after-the-fact.
Simplest thing to do is just put up this instead
<http://www.pcserviceselectronics.co.uk/cartoon.htm#loading>
Share and enjoy...
--
Paul Carpenter | paul at (no spam) pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate |
|
|
| Back to top |
|
|
|
| Theo Markettos... |
| Posted: Mon Nov 02, 2009 4:51 pm |
|
|
|
Guest
|
Jim Stewart <jstewart at (no spam) jkmicro.com> wrote:
Quote: I'd be happy as a clam if I could just see
an hourglass when the machine is compute-bound.
Virtually no Windows apps give you an accurate
indication and it's one of my major gripes.
On my Linux machines I have little scrolling graphs in the system tray for
CPU load and network bandwidth, which are handy for indicating whether I'm
CPU bound, network bound, or quiet waiting for some network event to happen.
I can see them at a glance without having to do anything (for example, I'm
typing this in an SSH session and seeing blips for the network traffic
caused by my keystrokes).
Windows Task Manager will give you a little systray icon, but only providing
4 bits of state (quartiles of the current CPU load). Perhaps there are some
apps that will show data as a time vs load graph in the tray?
Theo |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Tue Dec 01, 2009 6:04 am
|
|