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
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability