GNOME Bugzilla – Bug 619536
Indicate the active keyboard layout in 'Keyboard Preferences'->Layouts
Last modified: 2010-07-12 13:49:55 UTC
When you add a second, a third or an Nth keyboard layout in the Keyboard Preferences it quickly becomes unclear to users what exactly is the active keyboard layout. The Keyboard Preferences should highlight the currently active layout on the Layouts tab. This bug was originally reported by Nicolas Stack on Launchpad in Ubuntu at <https://launchpad.net/bugs/458376>. This bug was accepted as a papercut in Ubuntu.
I do not understand the real requirement. When you have >1 layout, in 2.30 you'll see the indicator in the notification area. The current state of the keyboard, the active layout, is a transient thing - the configuration capplet should not bother about it at all. The problem described in the original launchpad bug is distro-specific, it is Ubuntu's controversial 'Apply System-Wide' button. I guess it should apply not only the system-wide parameter, but also the current settings (or at least ask about that).
The problem is that it is not very clear to all users what the currently active keyboard layout is from the list on the Layouts tab. Many of them don't see or don't link the keyboard notification area icon to that list and many also don't know that the default keyboard layout is on top of the list. I would suggest to highlight the row of the currently active keyboard layout (for the user) or make the font bold. This would make it clear to the user what the active keyboard layout actually is.
As I said, if they have >1 layout, they will get the icon (well, unless the user explicitly disabled that behaviour in gconf). I think that using colors/bold attribute could confuse user. "Why is that row highlighed?!" I will think of it again. Perhaps will play a bit. No promises though. At this point I find that pretty confusing...
(In reply to comment #3) > > I will think of it again. Perhaps will play a bit. No promises though. At this > point I find that pretty confusing... Since this /might/ be re-considered.. Can we re-set the bug status, instead of a "wont fix" , to probably "needs info" ?
I played a bit. VERY confusing. There is usual "current" selection in the list (it is used by "Move Up"/"Move Down"/"Remove" buttons). And when I add 2ndary selection (active layout), the whole thing becomes a mess. 2 selections in one list - this is against any sane HIG.
(In reply to comment #5) > I played a bit. VERY confusing. There is usual "current" selection in the list > (it is used by "Move Up"/"Move Down"/"Remove" buttons). And when I add 2ndary > selection (active layout), the whole thing becomes a mess. 2 selections in one > list - this is against any sane HIG. The secondary select? oh! didnt read the earlier comments/suggestions. We just need to make the default layout displayed in Bold text, no need to keep the row highlighted/selected.
It does not matter how that 2ndary selection is implemented - bold or color. It is confusing because it interferes with the primary selection. And it has unclear semantics, in context of this dialog.
Created attachment 164991 [details] How Input Methods shows the default (In reply to comment #7) > It does not matter how that 2ndary selection is implemented - bold or color. It > is confusing because it interferes with the primary selection. And it has > unclear semantics, in context of this dialog. < not trying to haggle :) > Attaching a screenshot of the Ibus input methods prefs which is nearly a similar option, the Default input method is in bold here, it is clearer about which item in the list is the default one ,[without even requiring the read the info below]. Similar bold text is done in the Keyboard Layout Options itself. The Options which are bold are the ones which user has selected an option , while the rest which are in regular text are the inactive options. Bold == active is a semantic that is used often.
I do not see double selection in your screenshot. The problem is that we have two "current" layouts - the one explicitly selected by the user in the list (for example, by clicking on the list item). That's the one that is used by up/down/remove buttons. Let's call it "ui-current". There is also "current" layout which corresponds to the xkb group currently used by X server. That's the one that would be used in any text entry field. Let's call it "input-current". Currently the list deals only with ui-current layout, it is necessary (otherwise up/down/remove buttons do not make sense). If we start indicating both ui-current and input-current layouts, user would be confused. In your screenshot I see only one selected layout. I presume it is ui-current. Right?
Created attachment 165010 [details] Ibus , ui-current (In reply to comment #9) > > In your screenshot I see only one selected layout. I presume it is ui-current. > Right? Nah , that was the input-current . Attaching screenshot showing ui-current too.
Yes, the 2nd screenshot shows both ui-current and input-current. I think this is confusing - since from the dialog itself it is absolutely not clear WHY the first element is bold. Perhaps, this is worth raising on usability list - because to me it looks like issue for HIG: explicitly allowing or forbidding multiple ways of selection.
(In reply to comment #11) > Yes, the 2nd screenshot shows both ui-current and input-current. I think this > is confusing - since from the dialog itself it is absolutely not clear WHY the > first element is bold. > > Perhaps, this is worth raising on usability list - because to me it looks like > issue for HIG: explicitly allowing or forbidding multiple ways of selection. Well , if we dont want to show the text in bold. We could add "Active" next to the layout. Ex: USA (Active) Would prevent the concern that the user would get confused , and also is verbose.
This does not remove the semantics of "double selection" - which means confusing the user. So, I still do not see ANY benefit of having that information in the dialog, only overloading UI with unnecessary (and duplicated!) information. As I said, if Nlayouts > 1, the indicator appears in the notification area. The user should (one day, may be not immediately:) understand the connection between that indicator and the keyboard configuration - otherwise the whole kbd configuration system does not make sense to him. First question you'd expect: how would he know the current active layout if he closes the keyboard configuration? LOOKING AT THE INDICATOR. So, still WONTFIX
A comment from Matthew Paul Thomas in the Ubuntu bug report: "The general pattern is that when an item in a status menu opens a window, that window shows a superset of the information from the menu. The battery status menu shows the charge for a battery, and a menu item opens a window that shows the charge *and* other things. The sound menu shows the volume, and one of its items opens a window that shows the volume *and* other settings. The keyboard menu should show the current layout, and one of its items opens a window that should show the current *and* other settings. In each case, we should cater for people who want to access the information or settings without having the relevant menu in their panel at all. A simple solution to this is to add a column of radio buttons to the left of the "Layouts" list. Make sure the radio buttons do not interfere with drag and drop for items in the list. And make sure to update the radio buttons whenever I change the layout using the keyboard combo." https://bugs.launchpad.net/hundredpapercuts/+bug/458376/comments/9