GNOME Bugzilla – Bug 593268
Make Enable/Disable accounts easier again
Last modified: 2010-01-05 06:13:28 UTC
Up until the MC5 merge, enabling and disabling an account was as simple as clicking the checkbox in front of an account name in the accounts window. This took 2-3 clicks (depending on how you open the accounts window). Now you have to select the account in the account window (2-3 clicks), find and click the enable checkbox (one click + search time), maybe scroll down (?) and press apply. So this is at least 2 clicks more, plus seek time etc :( I think it is not uncommon for people to enable/disable accounts depending on location, time-of-day or even moot. Given that Empathy does not seem to support separate status for separate protocols, this seems to be even more of an issue. Please move the enable checkbox back into the accounts list.
I agree, it would be good to make it easier. Imho, a first step would be to always display the "Enabled" checkbox at the top of the widget so user wouldn't have to look for it at a different place depending on the kind of account.
(In reply to comment #1) > Imho, a first step would be to always display the "Enabled" checkbox at the top That would certainly be a small improvement but you would still have to click accountA->enable, accountB->enable etc. Why was this changed in the first place? Getting it cleaner and easier to use than it was before is not possible I think.
I do agree that the current UI implies an extra click (Apply). May be the account list on the left could have an Enabled checkbox column. I personnaly disable the work account when I am at home, this would make it fast.
*** Bug 593357 has been marked as a duplicate of this bug. ***
Another thing to do -- beside making the Enable location predictable -- is getting rid of the Apply button. That's in the GNOME HIG guidelines, I believe?
I'd be fine with the Enable button being instant-apply, that would make perfect sense to me. But we're not going to get rid of the Apply button in this dialog, there is no sensible way to do instant-apply on account configuration. In most cases changing parameters will need a reconnect, something you don't want to do unless the user indicates that he finished updating the configuration. Some parameters always come in pairs (e.g. server and port), you don't want to auto-apply when the server field is filled in, but the port isn't yet. To come back to the port, this is a spinner, you obviously don't want to apply the settings everytime the user clicks up (which changes the port) as this is obviously not going to work. Another example is the password field, you don't want to apply the changes untill the user fully filled in the password entry. So the user needs a good way to indicate that he has fully filled in the password. For all this cases having an Apply button is a simple and intuitive solution. Please also note that the HIG is called a guideline for a reason :)
Unless located in the account tree view, having an instant apply Enable checkbox among "need to press Apply" settings would be inconsistent. Having it in the list would make it even faster: you don't even have to click on the account to display the correct enable checkbox. You save another click.
I agree with Pierre-Luc. I also agree that having the rest of the CM options instant-apply would be a bad thing.
Moving it back to the list, just like before, would be fast and consistent, yes. As for the Apply button -- could it be made so that settings are applied when the frame is closed? either if another account is selected, or if the entire accounts window is closed. But doing that just to avoid the Apply button would be rather silly, as well as giving a misleading impression that the settings are instant-applied.
*** Bug 593952 has been marked as a duplicate of this bug. ***
having to click on apply is really non obvious I though that empathy was failing to connect to those account until sjoerd pointed that apply is need on IRC today
*** Bug 594384 has been marked as a duplicate of this bug. ***
I also think current UI is ugly and inconvenient. Previous one was better in my opinion.
This patch move the enable checkbox back to tree view. Current behaviour is kept only for moblin. http://git.collabora.co.uk/?p=user/xclaesse/empathy.git;a=shortlog;h=refs/heads/enable-account
(In reply to comment #14) > This patch move the enable checkbox back to tree view. Current behaviour is > kept only for moblin. > > http://git.collabora.co.uk/?p=user/xclaesse/empathy.git;a=shortlog;h=refs/heads/enable-account Nack, account enablement shouldn't be in the treeview
Can you please explain why? It was always there since Gossip and nobody complained. You moved that to the right pane *only* because when moving to MC5 enable became an account setting like others, that get set with the apply button. That was only a technical reason, not UI at all. Now we changed to have it instal apply which is even worse because it is the only insta apply setting in the middle of settings that needs to by applied with the button. IMO, once accounts are configured the main purpose of the account settings dialog is to enable/disable accounts. It is really an important feature and useful to have in one click from the treeview. It is really common usage: Epiphany/xchat-gnome/gedit plugin dialog, spellcheck setting in empathy/epiphany/xchat-gnome/evolution, evolution accounts, nautilus column preferences, etc... actually I didn't find a single GNOME application that does not have that. So please gives good arguments to counter those!
(In reply to comment #16) > Can you please explain why? It was always there since Gossip and nobody > complained. > > You moved that to the right pane *only* because when moving to MC5 enable > became an account setting like others, that get set with the apply button. That > was only a technical reason, not UI at all. Now we changed to have it instal > apply which is even worse because it is the only insta apply setting in the > middle of settings that needs to by applied with the button. > > IMO, once accounts are configured the main purpose of the account settings > dialog is to enable/disable accounts. It is really an important feature and > useful to have in one click from the treeview. > > It is really common usage: Epiphany/xchat-gnome/gedit plugin dialog, spellcheck > setting in empathy/epiphany/xchat-gnome/evolution, evolution accounts, nautilus > column preferences, etc... actually I didn't find a single GNOME application > that does not have that. > > So please gives good arguments to counter those! +1! pls change this
As this UI decision is obvioulsy controversial let's try to be constructive and give arguments instead if limiting this to a "I like / I don't like" discussion. I do think the current UI makes sense on Moblin and that we should keep it for this version. The only potential change could be to move the Enable slider at the top of the widget. We should check with Moblin people what they think. I also do think that the current UI is not optimal on the GNOME desktop. We should at least move the "Enable" checkbox at the top of the widget. But could we do better than that? Some people seem to miss the old UI where it was possible to enable/disable accounts directly from the treeview. What was the arguments who lead to the removal of this checkbox? As Xavier said, this pattern is very common in GNOME applications it doesn't seem an idious idea to me to reuse it in that case. Thougts? Any (constructive) input is welcome.
(In reply to comment #18) > Some people seem to miss the old UI where it was possible to enable/disable > accounts directly from the treeview. What was the arguments who lead to the > removal of this checkbox? I explained that in comment #16
I think having either the Enable checkbox and the delete button makes the treeview way too crowded. Also, having the checkbox in the treeview and instant-applying IMHO makes it too easy to accidentally disable accounts. How about moving the big protocol icon that we have in the accounts page to the left of the label, make it a clickable toggle button, and use that to enable/disable accounts? Maybe with a smaller italic label (I love small italic labels) under the account name, labelled "Click the button to enable and disable this account).
(In reply to comment #20) > How about moving the big protocol icon that we have in the accounts page to the > left of the label, make it a clickable toggle button, and use that to > enable/disable accounts? This sounds like a bad idea to me... the "button" look and explaination text will only add visual complexity and the main problem (having to click the account, moving mouse, clicking enable/disable) is still 100% the same. I totally agree that the main use for this dialog after the initial setup is in fact being able to quickly enable or disable accounts and there is no better way to do this than having chackboxes in the list.
(In reply to comment #20) > I think having either the Enable checkbox and the delete button makes the > treeview way too crowded. I tend to agree with that. Especially as we plan to add an icon displaying the status of the icon.
That icon seems useless. I prefer the maemo5's way of adding a red line under the account with the error reason. That even justify the extra padding we added. Of course this change goes together with removing the delete icon from treeview. having both in tree view is clearly too much.
Nobody seems to have sane proposal... can I push my branch?
Xavier that's not exactly true. Some people (including Cosimoc and me) think that will make the treeview too crowded. At this stage I'd be tempted to move the enable/disable checkbox on the top of the widget as, I think, everyone agrees that's an improved. See how much it improves things and then reconsider to do more changes if needed.
(In reply to comment #25) > At this stage I'd be tempted to move the enable/disable checkbox on the top of > the widget as, I think, everyone agrees that's an improved. See how much it > improves things In short: not enough. I am sure everyone also agrees that enable/disable is a much more useful (and a lot more used!) operation than deleting accounts. So if anything, the enable/disable belongs directly into the tree view.
(In reply to comment #26) > In short: not enough. I am sure everyone also agrees that enable/disable is a > much more useful (and a lot more used!) operation than deleting accounts. So if > anything, the enable/disable belongs directly into the tree view. Completely agree.
comment #20 ++, basically, although I'm not sure about an image secretly being a toggle button
Can you please explain why empathy is different from ALL other app where the checkbox in treeview is just fine? Also could you please explain on what you base that treeview would be crowed if NOBODY complained since it got introduced in Gossip?
(In reply to comment #26) > (In reply to comment #25) > > At this stage I'd be tempted to move the enable/disable checkbox on the top of > > the widget as, I think, everyone agrees that's an improved. See how much it > > improves things > > In short: not enough. I am sure everyone also agrees that enable/disable is a > much more useful (and a lot more used!) operation than deleting accounts. We agreed that the 'delete' icon should leave the treeview, that's bug #600949. Let's focus on enabling/disabling in this bug.
(In reply to comment #28) > comment #20 ++, basically, although I'm not sure about an image secretly being > a toggle button Yeah that sounds wrong to me as well. But I do agree that we should prevent user from accidentally disabling an account. Especially as disabling an account can lead to terminating your audio/video session, disconnect all your tube applications, etc.
IIRC gossip had code for that (or at least when quit gossip) to popup a dialog with something like "Are you sure? You have chats open!" This kind of warning should probably be added, regardless to the solution we choose.
So, the user goal that I can see in this report is "can't change presence for accounts independently" since enabling/disabling is really a bit of a hack to do that. I believe the bug for that is https://bugzilla.gnome.org/show_bug.cgi?id=505000 Overall though, for GNOME I can certainly see value in getting UI out of the account list and into the account settings itself on the right hand side. This would require a rework of that area, but that's certainly something that's on my list to look at anyway since the checkbox widget is not as obvious to users on GNOME as our lovely Moblin lightswitch and we also have some infobar issues to deal with.
I think we all agreed that the "Enable" checkbox should be on the top of the settings widget instead of the bottom. I did that in the following branch. Let's see how it goes. If needed we'll investigate a better way to enable/disable account but I think that's already a good improvement. Nick: I didn't change the Moblin version. Let me know if you want to move the enable widget in Moblin as well.
Created attachment 150172 [details] [review] http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/move-enable-account-593268 libempathy-gtk/empathy-account-widget.c | 131 ++++++++++++++++--------------- 1 files changed, 69 insertions(+), 62 deletions(-)
Merged. Closing this bug for now. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
(In reply to comment #34) > I think we all agreed that the "Enable" checkbox should be on the top of the > settings widget instead of the bottom. I still find it ridiculous, it should be moved back to treeview... But anyway...
(In reply to comment #37) > I still find it ridiculous FWIW, this was exactly my thought when I tested the current implementation yesterday :(