[PATCH] Fix for bug 67661
Gioele Barabucci
ml at gioelebarabucci.com
Fri Feb 20 11:33:07 GMT 2004
On Friday 20 February 2004 09:07, Dr. Juergen Pfennig wrote:
> On Thursday 19 February 2004 22:58, Waldo Bastian wrote:
> > In similar situations I prefer to set the progress to 100% when the
> > action is finished and then set a timer to close it 1sec later.
> Ah! Effectively you want to keep the progress window open for at least a
> second to give the user a chance to click one of the "open" buttons. But
> should this not be implemented in SlaveBase::finish() ?
Usability prob: you can't "time" actions. Why "one" second? If he want to
click "open" when the action (copy, download...) is done, it should select
"keep this dialog open". If he is just starring at the progress and he sees
that the action is completed, the dialog don't go away and "Open" is now
active, then he will think "I can open it clicking on that button", it move
the mouse to the dialog and the dialog disappears: it took more that one
second to see the dialog, understand/interpret what the dialog shows, move
the cursor.
Instead we should just correct the progress calculation, wait something like
100ms (enought to catch 100% if you're starring at the dialog) and flush it
away.
> Another suggestion: please make these controls ("Open xxx", "keep open" and
> the display of the speed) optional. Most users get confused by so many
> details.
confused by the speed? or by a simple button that says "Open"?
wouldn't they be more confused by another option buried somewhere in kcontrol?
All I can say about that dialog is that maybe we should rename "keep open when
done" to "hide when done". I think the user should click something only to
deviate from the current setup. I mean, the user is seeing the dialog right
now, what he espect is to keep seeing it. If he don't care about it, he will
click, setting the check to a positive/proponitive state, on "hide when
done".
The same can achieved with current label, just the check has an inverted
state, that lead IMO to a different usability feeling.
PS: follows up to this in kde-usability.
--
Gioele
More information about the kde-core-devel
mailing list