[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: KDE Wallet notification
From:       Maciej Pilichowski <bluedzins () wp ! pl>
Date:       2009-02-07 20:51:28
Message-ID: 200902072151.28630.bluedzins () wp ! pl
[Download RAW message or body]

On Saturday 07 February 2009 16:26:12 Peter wrote:

> The notice is really an user interrupt and should 
> behave like one: Mark the active app, disable further notices, call
> the password app, enable notices, return to the marked app.

I am not sure about this -- the switch to the password-app is done on 
demand, but the return is done automatically. In general I dislike 
any automatic switches (and thus I use very prohibit focus stealing 
policy).

You also cannot tell for sure if the user does not like to stay a 
while with the app to perform further steps. 

> A few issues:
>
> 1- The user _should_ want to confirm authentication and returned
> afterwards, not when the password has been entered. (difficult)

I don't understand this step -- the difference between authentication 
and the password, user authenticates by entering the password.

> 2- One notice should handle several requesting apps.

How do you handle the notifications then? 

> 3- Returns can be cancelled by the user.

How? This also forces the complex logic underneath -- I prefer 
simplicity, if the user want to return, she/he simply switches back. 
So the action is explicit, on demand, user is in control.

> 5- Notices should _not_ nest, so while the user is entering one
> notice password, the notice should be disabled, or show the return
> app.

You mean because they are of the same category, or because of the 
importance of the password dialog?

> 6- The result of handling the notice should be the same as though
> no notice had been given, i.e. the password app should still have
> its field hidden (or would be hidden if the field were shown).

The first part I understand, the second not :-) but I hope we agree.

> 7- Handle several requesting apps in order, randomly, or user
> defined.

I think it is overcomplex. I think time-order will be sufficient (but 
maybe I am missing specific use-case you have in mind).

> The notice should appear on top of all other apps, but never over
> the active (focused) view. 

Which is impossible to do in general.

> It should not have any buttons, but accept a left-click (go to
> app), or right-click (dismiss with no or some repop delay). 

100% disagree. Notifications as any other parts of KDE should be 
self-explanatory, it is not place for magic, to clap your hands twice 
to get the lights off, and cough once to get the heat up.

If there is a feature "accept" it should presented exactly as it 
is -- "accept". We should not invent obscure UI, which requires to 
read manuals to use them. And secondly -- we should not redefine 
meanings.

> If 
> keyboard access is possible, that would be great, too (Enter or
> Escape).

Notifications can be focused?
 
> This means I do not want to be
> taken to some app and left there because I may not know how to get
> back to where I was!

If you think of disturbing the user the harm is already done, if you 
are thinking about the user who launches two apps at the same time 
and don't know how to switch between them (like taskbar), I can 
hardly believe she/he handles such matter as kwallet requests on 
his/her own.

> After handling several password apps, I may be 
> totally confused. By remembering where I've been and taking me back
> there, I'll feel more confident in responding to notices.

The problem is how to to it in nice manner.

Btw. this might be a little off-topic -- a notification log would be 
very useful. This would mean I could ignore X notifications, because 
I have important work, but when I am done, I could get back and see 
what required my attention.

Cheers,
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]