views:

312

answers:

4

For tasks that will take more than a few seconds, a good user interface, in my opinion, should provide a progress bar along with appropriate information on the progress of the operation. (Microsoft kindly provide User Interface Guidelines on this topic, but I want a status panel that is a bit more advanced.)

The "task" class I am using is able to log messages, and if the messages are important enough (warning or error), I would like to display them on the progress panel. It would also be nice with a graphical indication when warnings or errors have occured (a warning or error icon perhaps). If there are many such messages, a text box, a list view or perhaps some report control could be appropriate here.

There could be a cancel button while the task is running, and after the task has been completed, a "View log" button would also be nice.

To summarise, I have a good idea how to implement my status panel, but I would really like some input on this. Did I miss something important? Am I going overboard on this? Are there perhaps any components like this already available out there?

+1  A: 

You have here a similar Status Panel specifications which can give you some ideas on what could be included into this kind of GUI:

In sort, define your goals and scope of this Status Panel before listing the design details.

Note: with too much options on it, you will evolve it into a "Control Panel" ;-)

VonC
This specification is for a running service, not for a single task, so not exactly what I'm looking for.I realise that the term "status panel" is a bit ambiguous, so I am rephrasing my question to use the term "progress status panel" instead.
Ola Eldøy
Fair enough. I was more referring to the process of specifying your (status/control/progress) panel than to the actual content of the specification.
VonC
+2  A: 

For logging, you should probably actually have another higher level of error. These are the levels I usually implement (as swiped from DEC back in the 80's).

  1. DEBUG - a very low-prioity message that the developer just put in to help diagnose what's going on in the event something goes awry.
  2. INFORMATIONAL - No problem, just reporting progress the user might be interested in.
  3. WARNING - Something that could possibly be an issue in some situations, but may also be just fine.
  4. ERROR - A definite problem. The user must be informed, but the program will try to keep going.
  5. FATAL - A problem so bad that the program can't go on.

The second is, since you are calling this a "progress panel", I assume you are planning on implementing some kind of progress bar. There has actually been a fair bit of research into progress bars. The main thing is that, whatever you do, don't let the bar get slower as it progresses. That makes it seem to drag on forever.

Lastly, it sounds like you are considering some sort of status message line. If you are looking for some good status messages, I suggest you use some of these. :-)

T.E.D.
+1  A: 

You'll want to view log messages while in progress, not just at the end. If a bug occurs, it'll often be before the task is done, and the UI thinks everything is still chugging along. It can be really annoying to find this is happening, and yet the only visible log message (without going to some external file somewhere) is some random informational message far removed from the actual problem.

(I don't know whether you're already doing this, as it's not clear from your question. If you are, hats off.)

Paul Brinkley
This is exactly what I'm trying to do. The log message should be displayed in the progress panel if it's "serious" enough (i.e. error or warning).
Ola Eldøy
+1  A: 

I think it's important that your main progress bar fill up exactly once, and there is always indication of progress.

I've just recently done something very similar at work. The tasks were long, with many subtasks. The interface I ended up with was a double progress bar, which were actually the first and last of a stack of progress bars.

The API is something like

StartNewTask(Caption,NumberOfSubtasks)
EndTask 
SetProgress(Caption,NumberOfSubtasksFinished)

StartNewTask pushes a new bar on the stack, and EndTask pops one.

SetProgress sets the progress of the most-recently-pushed progress bar, and ripples up the changes to parent bars. For example:

StartNewTask('Doing 2 things',2)
 SetProgress('Done 1 now',1)
 StartNewTask('Big Subtask',40)
  ...
  SetProgress('Done some subtasks',10)

Now, there are 2 progress bars shown, the second at 25% (10/40) and the first at 62.5% (1/2 + 10/40*2)

Like I said above, if you've got >2 tasks in the stack, I only show the first and last (first gives overall progress and never goes backwards, second gives indication of current activity)

You could extend this by giving a weighting to each subtask, i.e.

StartNewTask(Caption,[ListOfSubTaskWeightings])

To make the top progress bar smoother.

Additionally, developers can show all progress bars to see why it takes ages, and I think you could make decent logs out of it.

Greg