Keyboard Preferences Design Review

The following is a design review of the GNOME Keyboard Preferences dialog, otherwise known as gnome-keyboard-properties. It is being conducted on a Ubuntu 9.04 system. It is a work in progress so any comment or discussion is welcome.

Review

The current dialog contains five tabs. Screenshots are taken from gnome-control-center on git.gnome.org.

General

• See bug 615258

Analysis:

Redesign:

Layout

• Most of this has been implemented. The exceptions are bug 615521 and bug 615565.

Analysis:

Redesign:

Notes

• Keyboard switcher applet is activated when more than one layout is present in the list.
• '(Default)' label is attached to the top entry in the layout list. This is removed when 'New windows use active window's layout' is checked.
• 'Separate layout for each window' is greyed out when only one layout is present in the list.
• 'New windows inheret active layout' is greyed out when 'Separate layout for each window' is unchecked/greyed out.
• The 'Move up' and 'Move down' buttons should be greyed out when there is no layout selected.

Tooltips

• See bug 605509

Accessibility

• See bug 615521

Analysis:

Redesign:

Mouse Keys

• See bug 605515

Analysis:

Redesign:

Typing Break

• See bug 169091

Analysis

• 'Typing Break' is a confusing term.
• Work break reminders (and Repetitive Strain Injury) are not specific to keyboards or typing.
• Recommendation: remove the 'Typing Break' tab. A better solution would be a 'GNOME Work Break' applet.

Keyboard Shortcuts

• See bug 78102

• MatthewPaulThomas has suggested that the Keyboard Shortcuts preferences dialog (aka gnome-keybinding-properties) should be a tab in the Keyboard Preferences dialog. This would locate all the keyboard preferences in a single dialog and would reduce the number of entries in the System Preferences menu.

Notes

• The use of 'pointer' and 'mouse pointer' follows GNOME Style Guide recommended terminology.

Discussion and comment

SergeyUdaltsov: In relation to the layout management:

Yes, if you have one layout, 'Separate layout' checkbox should be hidden. To be fixed after the UI freeze.

• That's great.

• (AllanDay: 2009-09-14 16:08:27)

'Selected layouts' - they are selected for usage. What would be the better wording here? 'Add' exactly means 'add one more layout'. If you want to have one (and that one is not what you currently see), add it (and remove the old one). Is it really so confusing?

• Some aspects of it are potentially confusing... As already described, 'Selected layouts', 'Add...' and 'Remove' don't conform to the semantics of 'I want to change my keyboard layout'. The other thing is that the order and grouping of the elements in the dialog. 'Separate layout for each window' is grouped with and comes before 'Selected layouts', 'Add...' and 'Remove'. This suggests that 'Separate layout for each window' has something to do with those items - it suggests that they have something to do with layout switching, which they don't always (from the users persective).

• (AllanDay: 2009-09-14 16:08:27)

  • Upon reflection, I am pursuaded that the list with 'Add...' and 'Remove' does work. The playcement of the 'Separate layout for each window' check box is the bigger concern. See the version 2 sketch above...

  • (AllanDay: 2009-09-18)

• I'm unsure whether you need a heading for the layouts list if you keep the dialog in the current form - it already contains headings like 'Layout'. It might be that 'Selected layouts:' only adds noise.

• (AllanDay: 2009-09-14 16:08:27)

  • Removing the label... Actually, an interesting idea. Regarding the 'Separate layout' checkbox - it is true, that checkbox really has something to do with selected layouts - it enables/disabled the 'Default' column.

  • (SergeyUdaltsov: 2009-09-14 20:13:38)

Yes, the semantics of the default layout is unclear. The column name "Default" can be changed to "Default for new windows" or something. About "default for user" (actually, for the session) - I do not know, how to give a hint. Just to put some explanation under the list? ... But users do not read anything longer than 3 words, you know...

• I don't think there's a problem with the label. 'Default' gets its meaning from the context in which it is found.

• (AllanDay: 2009-09-14 16:08:27)

  • Unfortunately the context is quite vague, in both cases - default for the session and default for the new window. I am not sure that in either case user immediately realizes how that default is going to be used. Mentioning the context explicitly would be useful, I guess.

  • (SergeyUdaltsov: 2009-09-14 20:13:38)

    • Why is it vague? It should be obvious if the user has a good idea about the settings they are using... (I'm not saying a more explicit statement rather than just 'Default' isn't a good idea, btw.)

    • (AllanDay: 2009-09-18)

'Reset to Defaults' affects model/layouts/options. But having a separate button row just for it ... looks like a waist of space.

• It is a bad idea to have lots of vacant space, but it is also useful to logically separate dialog elements into groups using spacing. It makes sense to have 'Reset to Defaults' on its own from the perspective of intelligability since there isn't anything similar to 'Reset to Defaults' in the dialog.

• (AllanDay: 2009-09-14 16:08:27)

  • May be you're right. I will try to put it on a separate row. But I guess the 'Print' belongs to the same row as 'Add'/'Remove'.

  • (SergeyUdaltsov: 2009-09-14 20:13:38)

    • Part of having the 'Reset to Defaults' on its own row was to ensure there was an equal length for each of the buttons, btw. It was for aesthetic reasons in the context of that design.

    • (AllanDay: 2009-09-18)

The 'Print' button (give it a try!) allows to send the current (selected in the list) layout to printer. Some people like to have layout printed (and pinned on the wall of cubicle)

• Maybe labelling the button 'Print layout' would be helpful?

• (AllanDay: 2009-09-14 16:08:27)

  • What else could you print here? Also, if 'Print layout', then 'Add layout' and 'Remove layout' as well;)

  • (SergeyUdaltsov: 2009-09-14 20:13:38)

    • Well, I thought the button might print my current keyboard settings! :P I think the difficulty here is that it isn't typical to have printing functionality in a preferences dialog - there's no prior experience to guide user expectations.

    • (AllanDay: 2009-09-18)

Apply System-wide' is an Ubuntu-specific button, let's not discuss it here;) Actually, the way it is implemented in Ubuntu (at least 9.04) is broken in some ways...

• I wondered if that might be the case. I need to do some testing on a proper GNOME install.

• (AllanDay: 2009-09-14 16:08:27)

The "Switch between multiple layouts" checkbox might be actually slightly confusing. If you have that box checked, then you selected one layout, then changed that box to unchecked - should that single layout be automatically copied to the list? Or, if in the opposite direction, when you uncheck that box, should the first(?) layout be automatically copied to the layout chooser button on the top? My personal humble position regarding that idea ... not strictly "no go", but "worth further discussion, perhaps some improvement".

• Yes, you'd have to get the interaction between the different layouts right. The combo box for selecting a single layout would have to grey-out when 'Switch between multiple layouts' is checked. The list of available layouts should inheret the item in that combo box when 'Switch between multiple layouts' is checked.

• (AllanDay: 2009-09-14 16:08:27)

  • One note - it would not be a combo box. It would be a button - just like the 'Keyboard model' button

  • (SergeyUdaltsov: 2009-09-14 20:13:38)

    • Yes, a button. Sloppy of me.

    • (AllanDay: 2009-09-18)

Regarding the "Default" column in the list - I do no think it is good to use it for both semantics. The "default for the session" layout should be the first one in the list. Otherwise there will be confusion - what would be the second layout? For example, if I have 3 layouts "us","ru","de", then chose "ru" as "default for the session", what would be the second one in the loop? Or, in terms of XKB, would it be "ru","de","us" or "ru","us","de"?

• Ah yes, very good point. I'll have a think about that. Sergey: can you see there being a problem with making the first layout in the list the default when 'Separate layout for each window' is both checked and unchecked? To restate the question: is there a reason why you couldn't use list position to determine the default in both situations?

• (AllanDay 2009-09-14 16:08:27)

  • Yes, there is a problem. That way, you cannot reproduce the use case "No default layout for new windows at all". With radios, you can do that.

  • (SergeyUdaltsov: 2009-09-14 20:13:38)

    • I hadn't realised that you could do that. I've incorporated that feature into the new sketch I've done (see above).

    • (AllanDay: 2009-09-18)

Thank you for raising a number of interesting issues!

• I hope it's helpful. Thanks for your reponses, they're really useful. I'm going to have another think about this and update the page with what I come up with.

• (AllanDay: 2009-09-14 16:08:27)

I've come up with a new sketch for the layouts tab which is based on the above discussions. I think it looks nice. (AllanDay: 2009-09-18)

SergeyUdaltsov: Round two.

First of all, you can understand my amusement while looking at the buttons "Move Up/Down". These buttons were there some while ago, were removed because they take too much space, and simple DnD does the job.

• That is pretty funny. I think we can come up with a design where those buttons don't make the dialog too complex. The reason I put them in my new sketch was for reasons of discoverablity. If they are not there, there is nothing in the interface to suggest that reordering of items in the list is possible or has any effect.
• DnD does provide functionality, but not discoverability. Buttons not only advertise the presence of such functionality, but provide the opportunity to use tooltips to provide further explanation.

• (AllanDay: 2009-09-23)

  • DnD alone is also not an accessible solution, a keyboard equivalent is always required.

  • (CalumBenson: 2009-09-29)

About the list. I would prefer to keep it as large as possible, because some names are rather long (again, I already had buttons Add/Remove on the side, at some point;)

• Ha ha, another suggestion that you've already done at some point. I bow down to your superior experience. Those buttons can go below the list.

• (AllanDay: 2009-09-23)

The idea to have same default layout for both session and new window is probably nice. I just have doubts in relation to the label "New windows inherit active layout" (I guess, you actually mean "no default layout for new windows", same as "none of radios selected" currently, right?). IMHO it could be somewhat unclear (too long?) to uneducated user

• Yes, that check box is supposed to mean 'no default layout for new window'. I am open to suggestions for renaming that label, but I do think it has to be expressed as an assertive statement of what the behaviour will be - ie. it should state how the new window acquires its layout. Stating the absence of a default does not communicate this. Do you have any suggestions for how to express this state?

• (AllanDay: 2009-09-23)

I've updated the design for the layouts tab. The buttons have been moved below the list. I've also suggested some tooltips. Feedback and comments are always welcome. (AllanDay: 2009-10-07

I'm not so much in favour of removing the Typing Break tab. The last thing we need is more clutter of the System admin menu. The fact that TB doesn't have much advanced functionality, is a feature. Also, let's not ignore the enhancement requests against TB in bugzilla. https://bugzilla.gnome.org/buglist.cgi?query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;component=Typing%20break;product=gnome-control-center

(ReinoutVanSchouwen: 2009-10-07)

• I'm not saying that the Typing Break feature is not useful or effective, just that it doesn't belong in the Keyboard Preferences dialog. The main reason is that RSI isn't just a keyboard/typing only thing. (I've suffered from RSI for years, and it never occurred to me to check in the keyboard preferences.) What is needed is a work break program/settings dialog. Where this belongs is another question, of course. I agree that it shouldn't be a default System Admin entry. Maybe it could be an app, or an optional settings dialog?

• (AllanDay: 2009-10-13)

  • How about turning the typing break feature into the GNOME Work Break applet?

  • (AllanDay: 2009-10-14)

SergeyUdaltsov: Round three. It is ok for me;)

• (SergeyUdaltsov: 2009-10-07)

SergeyUdaltsov: One little idea to discuss. Instead of "New windows inherit active layout" I will put its negation: "New windows get layout %s" where %s is the name of the first (topmost) layout in the list. For example: "New windows get layout USA Dvorak". Objections anyone? Of course, that checkbox is only enabled when "Separate layout for each window" is checked.

Anyway, the first attempt is committed to git. Please test and comment.

• (SergeyUdaltsov: 2009-10-15)

• Great work, Sergey! I'm currently setting up a testing environment - will let you know my thoughts once I've had chance to look at your changes.

• About 'New windows inherit active layout' - that checkbox was intended to set whether there is a default layout or not. When checked, new windows would use the layout of the current active window. When unchecked, new windows would get their layout from the default entry in the layout list (this would be communicated by the presence of the 'Default' string in the layout list). In your proposal, what will be the behaviour when the box is unchecked? (This behaviour needs to be communicated to the user.)

• (AllanDay: 2009-10-16)

• Allan, as you will see, I totally eliminated the second column in the list. I really do not see any need in that column now. The checkbox clearly indicates what layout will be used for new windows (if that checkbox is checked). If that checkbox is unchecked, the default (first) layout will not be automatically applied to new windows - exact opposite of your version.

• (SergeyUdaltsov: 2009-10-16)

Before printing a layout, how about viewing it? There should be a "Show" button for layouts! (It's accessible from the layout indicator right-click menu, but users shouldn't know that.) In fact, a "Show Layout" button can replace the Print button, because the layout preview allows you to print.

• That's a nice suggestion. Why not file it as a bug? AllanDay: 2010-05-05

• Another feature that'd be nice is "Change..." button for layouts - replace an existing layout by opening the layout chooser with the current layout pre-selected. Currently one has to remove a layout and add the replacement from scratch, and selection of both country and language is lengthy. A "Change" layout button would allow easily experimenting with e.g. different variants for the same language, as well as make mistakes in choosing a layout less annoying.

• Since the layout chooser already contains a layout preview with a Print Button, maybe "Show" and "Change..." can be unified into one feature? The current viewer accessible by indicator right click->"Show current layout" has one feature missing from the chooser - it highlights keys you press in real time.

(BeniCherniavsky: 2009-11-26, edited 2010-04-13)

• I'm not sure whether that would be duplicating the existing Add/Remove functionality that's in the dialog. AllanDay: 2010-05-05

It's looking much better and it's much easier to understand! My 2 esthetical cents though:

1. Don't use italics anywhere in a UI "except"; to emphasize on words.
2. The indentation of the Sliders in the Pointer tab was actually correct. because the checkbutton applies to the suboptions.

(HylkeBons: 2010-04-08)

• Thanks Hylke, I've updated the mockups. (AllanDay: 2010-04-08)

Comments

One thing that I got a Fedora bug about is that the list of layouts in the layout tab doesn't make it obvious at all that there is a hard limit of 4 layouts that can be selected at the same time. After you've added 4, the add button just goes insensitive without further explanation. That might be nice to address.

• Indeed. It's an oddity. If that behaviour is unavoidable, we need a way to feedback what's going on. I'll have a think about the best way to handle this. AllanDay: 2010-05-05

The hard limit is built into XKB, so it is pretty much unavoidable for the time being.

CategoryUsability