GNOME Bugzilla – Bug 150305
UI reorganization as discussed on desktop-devel-list
Last modified: 2005-03-26 01:03:35 UTC
Reinout van Schouwen <reinout@cs.vu.nl> requested that I file the following suggestions as an enhancement bug. The discussion of gnome-keyring-manager was initiated by a user complaining about the UI of the application. == Points from my email to desktop-devel-list follow == 1. When you open the keyring manager, you are presented with a list of items in the 'default' keyring, with the caption "Items". In the user's mind, what goes on a keyring? Keys do! The "Items" caption should therefore be changed to "Keys", or the more verbose "Keys on this keyring". 2. Below the list of keys on the keyring, there is a section entitled "Item Attributes". I would be all for removing this section from the window entirely. Most of the information in it is present in the key's name, and all of the information is available in the "Advanced" dialog box, so there's really no point in duplicating it here - it's just visual noise. The key name is enough for a user to identify the correct key; they can click "Advanced" if they need more information. Perhaps the "Advanced" button should be renamed to "Key Properties", and moved up next to the list of keys. 3. The expandable "Show Secret" section does not visually express the link between the selected key and itself. Is it the keyring's secret or the selected key's secret? I should be able to tell at a glance. Moving the "Show Secret" section into the "Key Properties" window would fix this. So would modifying the "Show Secret" caption to read "Show secret for <keyname>" As to the "Drag this image to copy the secret" widget, I had never seen this style of control before and it took some playing to figure out what it is. A "Copy Secret to Clipboard" button would probably eliminate some head-scratching. 4. The caption for the Advanced Editor window should read something along the lines of "Key Properties for <keyname>". In a window list, "Advanced Editor" isn't clear about what the window actually is. Is that a text editor with a file open via a VFS SMB connection, or a property window for a key? ;) 5. Also in the Advanced Editor view, it seems that we have two separate editors visible at the same time! Attributes and Application Access Rights should probably be on separate tabs in this window. 6. Once I discovered the window that lists _keychains_ , I was surprised it wasn't the first window to appear when starting the application. I'm guessing the editor for the default keychain is shown in an effort to avoid confusing the user. I'll reserve judgement on this behaviour - I don't like it but I can see how it might be beneficial to some users... although it might be quite confusing if the key the user was looking for was on another keyring and they didn't know it. == End content from email == It's obvious that the designers of the gnome-keyring-manager UI have put a lot of effort into fitting in with the 'spatial' model. It just looks like there was some scope creep between some of the windows, and there is some terminology and clarification that needs to happen. Hope this helps, thanks for listening.
Created attachment 33040 [details] A possible new UI for g-k-m This design for the keyring manager is similar to that of gconf-editor, which, while dispensing with the spatial model, may make more sense for use in g-k-m. In this UI, the keyrings are listed on the left-hand side, in a tree view. locked and unlocked status is indicated by a padlock icon. Keys are listed in the top right treeview, along with an icon indicating their type. Key attributes are shown in the bottom right. So Ideally, everything would be directly editable in place (ie keyring names, key names, passwords, locked and unlocked states), and the user could drag and drop keys between keyrings. Some issues that remain to be dealt with are what to do with ACLS (should they be shown along with the key attributes, or in a seperate window, or not at all), non-standard key attributes (maybe we should just ignore them, and let them be dealt with by the application that uses them), and deleting keyrings / keys (should there be buttons for this?, or is it enough to have key bindings, context menus, and options accessible from the menubar?)
Hi, just to note that Fer and I had worked out a new design of managing keys, not to say that a management app is completely out of the question; just that we should probably focus our efforts on the management interaction before this manager app. http://mail.gnome.org/archives/usability/2004-October/msg00135.html
Fer, James, Jimbob and I discussed this briefly in IRC and had some ideas. We came up with: 1. Have several default keyrings: High Security (asks for password every time its accessed), Medium Security (Times out after 10 minutes or so), and Low Security(Open for the entire session). 2. Patch libgnomeui to put a dropdown with the available keyrings in the authentication dialog, next to [x] Remember Key. 3. Name the keyrings "high", "medium", and "low", and letting apps provide translated strings. I would further suggest that a plain-language explanation of the behaviour implied by the selected keyring should also be present in the auth dialog... "The Medium Security keyring requires that you enter your password after 10 minutes of disuse. We recommend you use this key for xxx and yyy." The more we help users to make good security decisions, the better.
Cool, a couple comments since I've done some work with usability and security research. While I think the possibility of having different keyrings for a higher and a lower security can bring better protection to peoples privacy. I have to dissagree on several points here. 1. High and Low security at most. More levels than that and it will be too difficult to figure out where which types of keys should go. I would suggest that we figure out defaults for each level and what types go in there. i.e. any passwords not sent over plain text (SSL and SSH and others) are in the High, while others are in the Low. At the same time, the best usability would be achieved through only one ring, avoiding all this confusion; i'm unsure and need to think about this more. 2. this is not going to be terribly useful, people will not manage their keys properly. this needs to be done for them, possibly similar to how i suggested. with plain-text/securely transmitted passwords. 3. the terms are completely foreign for normal people, so I don't think this will make much difference. Not that the terms are meaningless, but much of it has to do with the fact that people don't know how those terms match up to the passwords they use. A UNIX account that is only used by a person for email might be considered high security by you since it also has shell access, but people won't know that and probably mark it low. 4. much work has gone into this and it simple doesn't seem possilbe to provide a 'plain-language' description of security to people. Either they aren't interested in learning the differences in security issues or it's just too complicated and confusing. Think of your parents accessing websites through which a SSL certificate is invalid. The web browser pops up a nice error dialog explaining the security issues and give the person their options. Someone interested in learning more and doing the "right thing" would read the dialog and then carefully decide. Almost all users do not do this, the have a goal of accessing the site and any error message you provide, not matter how well explained is not going to convey the proper gravity of the situation to them.
Bryan, some good points. If we allow the applications to decide which keyrings they will use for what, we can hide the complexity of picking a keyring from the user. Therefore, we can have high, medium, and low and the user would *never* have to pick one - the application would do the picking based on the kind of key being saved. From the libgnomeui perspective, this means that the "Keyring" combobox proposed above for the auth need not be shown by default. In order to cater to users who _DO_ understand keyrings, though, I propose the combobox be visible in the auth dialog ONLY when there are keyrings other than the default ones present. In that case, the combobox could provide a default "Recommended" option that would select the keyring recommended by the application, along with the other available keyrings. I'm not sure what this would require in code - (an api change in whatever call shows the auth dialog to support 'hinting' for recommended keyring?), but from the users point of view, this kind of arrangement would appear to cater to both Mom and myself.
Further to my above post - perhaps applications that do not provide the 'keyring hint' should cause the combobox to be displayed as well, but with the Recommended keyring set to Low.
After reading all of the UI discussions I have a few comments. I really like Bryans idea of letting the users manage their application specific keys inside of each application. I think this means the UI needs to be split out into a separate library so that the applications will not have to roll their own UI implementation of dealing with keys. However, I still think there should be an admin program that can mange all keys. Individual applications should libgnome-keying-ui (or whatever) but there should also be a gnome-keyring-manager to be able to remove all keys. To me, being able to clear all of the passwords in the session keyring is a use case that needs to be handled.
We've moved on to a new UI. I'll close this bug for now, but if anyone thinks a complete redesign is needed on the new one, we can re-open the bug.