Re: Gnome-keyring terminology and UI wording



You might want to involve the usuability mailing list in this discussion. 

Pat

Alexander Larsson wrote:
> 
> Hi, i've recently introduced a new module in the gnome desktop, and I'd
> like some help with deciding on the way it is exposed in the user
> interface.
> 
> Here is a short description of the module:
> http://mail.gnome.org/archives/desktop-devel-list/2003-November/msg00555.html
> 
> The current integration of gnome-keyring into the ui is pretty minimal.
> There are a couple of checkbox in the default gnome-vfs authentication
> dialog (in libgnomeui), and there is the gnome-keyring-ask app that the
> keyring daemon launches to get passwords (for unlocking and creating new
> keyrings) and to ask if apps are allowed to read some password.
> 
> Today I polished the UI for gnome-keyring so that it at least doesn't
> look like total ass, but I think we need to think some about what
> terminology and wording to use in these user visible dialogs.
> 
> Here is what the UI currently looks like:
> 
> the authentication dialog has two checkboxes at the bottom (defaults to
> both unchecked):
> 
> [ ] Remember password for this session
> [ ] Save password in keyring
> 
> the first means the password will be stored in the "session" keyring
> (which is not saved to disk), and the second one saves the password in
> the keyring the user specified as the default keyring. (If both are
> selected the password is saved in the default keyring)
> 
> Gnome-keyring-ask has four dialogs:
> 
> Unlock keyring: (gnome-keyring-ask -k)
> 
> +-------------------------------------------------------------------+
> |
> |  Enter password for default keyring to unlock
> |
> |  The application 'File Manager' (/usr/bin/nautilus) wants
> |  access to the  default keyring, but it is locked.
> |
> |  [---entry----]
> |                                               [Deny] [OK]
> +-------------------------------------------------------------------+
> 
> When app creates new keyring with no password: (gnome-keyring-ask -n)
> 
> +-------------------------------------------------------------------+
> |
> |  Choose password for new keyring
> |
> |  The application 'File Manager' (/usr/bin/nautilus) wants
> |  to create a new keyring called 'foobar'. You have to choose
> |  the password you want to use for it.
> |
> |  [---entry----]
> |                                               [Deny] [OK]
> +-------------------------------------------------------------------+
> 
> 
> Choose password for default keyring (gnome-keyring-ask -d):
> 
> +-------------------------------------------------------------------+
> |
> |  Choose password for default keyring"
> |
> |  The application 'File Manager' (/usr/bin/nautilus) wants to
> |  store a password, but there is no default keyring. To create
> |  one, you need to choose the password you wish to use for it.
> |
> |  [---entry----]
> |                                               [Deny] [OK]
> +-------------------------------------------------------------------+
> 
> Ask for access for a specific keyring item: (gnome-keyring-ask -i)
> 
> +-------------------------------------------------------------------+
> |
> |  Allow application access to keyring?
> |
> |  The application 'File Manager' (/usr/bin/nautilus) wants to
> |  access the password for '127.0.0.1' in default keyring.
> |
> |                                [Deny] [Allow Once] [Always Allow]
> +-------------------------------------------------------------------+
> 
> At some point we will also get a keyring manager ui that allows you to
> list the availible keyrings, change settings of the keyrings and manage
> the items in the lists. Similar to the MacOS X one that you can see at:
> http://developer.apple.com/documentation/Security/Conceptual/keychainServConcepts/02concepts/chapter_2_section_4.html
> 
> I'm not sure we should expose the term "keyring" in the user in the
> interface. MacOS X use "Keychain", and KDE uses "wallet" I believe.
> Since we allow people to create several keyrings, and the keyrings can
> have different properties like lock-on-idle etc, we probably do need to
> expose them in the UI. The question is how.
> 
> I'm also not sure about whether to show the pathname of the app when
> referencing it like that, however thats the only part of the app
> reference thats nominally secure, since the display name ('File
> manager') is just what the applications choosed to call itself.
> 
> Another issue is the checkboxes in the authentication dialog. Is that
> easy enough to understand? Will people be confused by the fact that
> there is two checkboxes? Maybe it should be a radio button with a third
> "don't remember" state (although i don't like do-nothing alternatives).
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc
>                    alexl redhat com    alla lysator liu se
> He's a Nobel prize-winning small-town vampire hunter who hangs with the wrong
> crowd. She's a time-travelling extravagent detective married to the Mob. They
> fight crime!
> 
> _______________________________________________
> gnome-doc-list mailing list
> gnome-doc-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-doc-list

-- 
**********************************************
Patrick Costello, GNOME Documentation
Phone: 		01 819 9077 [ext 19077]
**********************************************



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]