GNOME Bugzilla – Bug 600949
Deleting accounts from the treeview is weird
Last modified: 2010-01-19 13:44:20 UTC
Lot of people consider than the current UI to delete accounts (delete button in the treeview) is more Moblin-y than GNOME-y. We should maybe remove it (in the GNOME version at least) and add a 'Delete' button in the bottom of the list as suggested on these mockups: http://live.gnome.org/Empathy/AccountsAndSettings Note that in this mockup the icon displayed in the tree view shows the status of the account (which is bug #599153).
Patch implementing this: http://git.collabora.co.uk/?p=user/xclaesse/empathy.git;a=shortlog;h=refs/heads/remove-account
I took some time looking at how the different GNOME applications handle this. In most case, the Add and Remove buttons are on the right of the tree view: Epiphany's preferences (the language treeview), Evolution's accounts UI, gnome-session-properties, bluetooth-properties, gnome-keyboard-properties, network-manager connections properties and even in Empathy's account IRC widget. Unfortunately we can't reuse this pattern here as we already have the account widget on the right. The second common pattern is to put the remove button on the bottom of the treeview close to the "Add" one: GTK+'s file chooser, the background chooser, software-properties-gtk. Nautilus's bookmarks UI. So we basically have 2 options: A) Put the "Remove" button in the right pane (the account widget). B) Put it at the bottom of the treeview near the "Add" button. B) seems better to me and more coherent with the rest of GNOME apps. We already have a lot of informations in the account widget (including buttons). Furthemore, most users won't have a lot of accounts so the "Remove" button won't be that far of the selected account in the treeview. This change won't affect the Moblin version of course.
I think B is obviously the only sane proposition. Can I push my branch?
I'd like to get some more input from other contributors first.
I'd love to see a screenshot of the patched Empathy first, though I agree with the rationale behind it.
So you have 4 examples of the remove button close to the Add button. I don't know what software-properties-gtk, so can't say anything about that. For the others, in both the Gtk file chooser and the background chooser you can't edit the selected thing in the same widget, so it's not the same pattern. In the background chooser i find it hard to discover (it's also quite far away from the items for some reason). I also wonder if any real user can figure out what the Remove button does in the GTK file chooser (it took me some time to figure it out after i opened it for this bug).. The nautilus bookmarks dialog is plain weird, you seem to be able to remove and edit bookmarks, but can't add them :) My main dislike with having the remove button under the treeview is that if you select an account there is a big area on the right of the treeview where you edit the account, but when you want to remove it you need to look somewhere else. (This is my general dislike of buttons under a treeview btw, you select something in the list and then something somewhere else, maybe far away, becomes sensitive and does shit) The obvious down-side of having the delete icon behind the selected item in the treeview is that it's not a common pattern in gnome (although, tbh, i don't think that's such a big issue). The suggestion to move it into the account editting widget seems more appealing to me. Especially since we're rethinking the enable button as well (the current winning suggestions for that seems to be to move it to the top and try to make it more clear what it does and easier to find). Having remove in the same area might be sensible. Added Nick to the CC to get some feedback from an actual UI designer :)
Thanks Sjoerd. Actions should be visually grouped so it's clear what they apply to. Having the delete action inline on the account makes it clear that the action is applying to the account as a whole and exactly what it will delete (i.e. only that account). For the reasons Sjoerd states we've observed problems with the 'bottom of the list' design in the past. The second 'best' location to show the account removal action would be in the right hand pane. It'll take a little bit of work to rearrange those settings so it makes sense but tbh that's work we should've done more of anyway in the last round of design. As for the 'common pattern' thing, we intend to spend more time working on settings across gnome over the next few releases... ;-)
*** Bug 594386 has been marked as a duplicate of this bug. ***
From bug #594386 : To add an account, I click on a button below the treeview. To remove an account, I click on a trash image in the treeview. I think it doesn't look consistent. Here are two possibilities I see: + remove the trash images, and add a remove button below the treeview + add a special item in the treeview "Add account". When selected, it would do what we can see when clicking the add button right now. I think the second solution might be the best, because I don't think it's really nice to change the content of the dialog when the user clicks on a button (it's confusing).
I'd agree with "B". As I stated in another bug report, my first instinct was to assume that the delete function mas a modal indicator showing me that my credentials were bad. I changed my password a number of times before figuring it out. Users are used to the add/delete buttons. I agree that the proximity to the account has a certain advantages, but this goes against the defacto flow of gnome, IMHO. If the intent is to change the listbox paradigm, then this should be done across the gnome application space and documented in HIG. Let's get consensus. Changing one application is just making it tough on users.
Now that the treeview also display the status of accounts, it's definitely too crowded and we should really move this "delete" icon. Moving it back below the treeview seems the easier solution for now. Xavier: could you please rebase your branch on top of master? Be sure to keep the current UI for Moblin.
I definitely agree with you Guillaume. FYI: http://blogs.fedoraproject.org/wp/mclasen/2010/01/15/old-promises/ With the patch it would look consistent with the screenshot in Matthias blog. I've heard that there is a Usability Hackfest in London in February (?). Maybe there could be discussed what gnome-policy could be defined for such cases?
Updated branch: http://git.collabora.co.uk/?p=user/xclaesse/empathy.git;a=commitdiff;h=d9364ce3c97b72e1ff96a499ff6343e4efa49d05
Looks good.
Merged, thanks :)
Created attachment 151756 [details] thunderbird 3 screenshot some more input on this one, as I just discovered how thunderbird 3 is handling this!