Re: Gnome-keyring terminology and UI wording
- From: Patrick Costello <Patrick Costello Sun COM>
- To: Alexander Larsson <alexl redhat com>
- Cc: gnome-doc-list gnome org
- Subject: Re: Gnome-keyring terminology and UI wording
- Date: Tue, 16 Dec 2003 15:38:54 +0000
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]