Re: Progress dialogs patch
- From: "Nelson" "" <gnel cenobioracing com>
- To: nautilus-list gnome org
- Cc: usability gnome org
- Subject: Re: Progress dialogs patch
- Date: Wed, 30 Mar 2005 16:30:10 +0200 (CEST)
> On Wed, 30 Mar 2005 04:40:38 +0200, Martin Wehner
> <martin wehner gmail com> wrote:
>> On Mon, 2005-03-28 at 17:47 +0200, Sebastien Estienne wrote:
>> > of course we need the progresse dialog, but we don't need to have it
>> > in front of us all the time, that's why a little icon in a tray call
>> > allow us to see the current actions in progress by cliking on it (a
>> > bit like the progress dialog in firefox)
>>
>> Yeah, the progress dialog should be minimizable in the first place :)
>> I'm suprised nobody brought this up yet.
>> An option to minimize the progress into a panel progress applet would be
>> sweet too, but I for one rarely have more than one transfer going.
>>
> As far as i remenber, the mail app in mac os x use something a bit
> similar.
> And i think that evolution would also benefit from a progress bar that
> doesn't ofusc reading the mail. that's really not great to have this
> pop up with progress bar (sending/receiving) in from of you when you'd
> prefer to be able to read your mails.
>
> I think that this concept of progress bar not staying in the middle of
> the screen should be applyed to all task that don't need the
> completion of the progress bar before the user can work again.
>
> For example you don't need to have recieve all your mail, to start reading
> you don't need to have wait for your trash bin emptying until you can
> do something else.
>
> Somehow this kind pop up appearing and staying in the middle of the
> screen is a bit against the notion of "multitasking", because most
> people wait for his completion before doing something else!
>
HIG says about progress windows in [1]:
"Otherwise, a progress window should be raised above the application when
the application window itself is selected from the window list."
and
"Resizing.�Progress windows should be resizable if they contain
non-static information the user may want to copy (for example, the source
URL in a download progress window). Otherwise they should not be
resizable."
So maybe an enhacement should to be filed for HIG?, It seems HIG dont have
that "multitasking" notion and it assumes that if a progress operation is
being executing in an application *that operation* is the most important
thing happening in that application. While the multitasking view says that
there may be *more important* things to do in that application or in other
applications in the desktop than just seeing that concrete operation bar
increasing...
My ideal implementation details are:
- Dont show the progress window by default, automatically minimize the
progress window to a tray icon that symbolizes the operation and show a
popup notification saying the operation has started. In that point you
know the operation has started and you can continue working in other
desktop apps or performing other tasks in the same app (reading existent
mail while checking for new mail) without an extra click to minimize the
progress window.
- If you are interested in how the operation is being performed, you
mouseover the icon tray that simbolize the operation and a popup
notification says about percent of operation been performed.
- If you are *very* interested in how the operation is being performed,
you double-click the icon tray that simbolize the operation and the
progress window appears showing progress bar and all info about it
(filenames,etc), then when you are done you minimize the progress window
to its tray icon.
- When operation concludes a popup notification says how operation
concluded (success, error, aborted). Then, if operation concluded in
success, the icon tray (and so the progress window that represents)
disappeared in 5 seconds. Otherwise if operation concluded in error the
icon tray stays there until user takes care of it by, 1) click it to bring
up the progress window and see possible error messages or 2) ignore the
error by right-click it and choose close.
I think all this notification stuff should be integrated, as much as
possible, in a desktop api to make life easier to app developers and to
have a uniform and integrated desktop.
[1] http://developer.gnome.org/projects/gup/hig/2.0/windows-progress.html
PD: Sorry for the cross-posting to usability, I thought it was interesting...
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]