Current HIG Analysis

This is a quick and systematic review of the current HIG (2.2.1), with a view to helping decide which content could be replaced by one or more UI patterns, which needs to remain written down in a 'book', and which may no longer be relevant.

  • 'Possible UI Patterns' not necessarily implying that each bullet point should be a separate pattern, just noting down ideas that our pattern library as whole ought to convey.
  • Current HIG chapter titles may not be appropriate for any future document, have just used them here for ease of reference.

Chapter 1 - Usability Principles

This introductory chapter talks about the fundamental usability principles that should be embodied by the GNOME desktop and its applications. Text could be tightened up a bit, and maybe there's scope for one or two new principles in light of current direction (something around mobility, social networking/connectivity?).

Possible UI patterns: nothing obvious.

Chapter 2 - Desktop Integration

Integrating into the Applications menu -> integrating into Applications pane of GNOME Shell. Could probably be covered by a UI pattern or two.

Stuff about gconf keys to be replaced by GSettings. (Do we think this is still in scope for the HIG?) MIME-type guidelines currently just a pointer to some old GnomeVFS docs. Should we just provide concrete steps in the HIG instead? Status notification: need to figure out guidelines for showing status in panel and OSDs. Could perhaps all be covered with a few patterns.

Possible UI patterns:

  • Examples of good integration into GNOME Shell; incorporate guidance on good/bad application names, descriptions and tooltips.

  • Feedback during application startup. Appropriate use of cursor change, show application window ASAP, what to show in application window until it's fully loaded and interactive. No splash screens :)

  • Appropriate (and inappropriate?) use of system status notification, gnome-shell message tray, OSDs.

References:

Chapter 3 - Windows

I suspect we could probably replace almost all of this chapter with a good selection of UI patterns.

Possible UI patterns:

  • One or more patterns for each unique type of window: application, system preferences, property sheet, modal/modeless dialog, alert, toolbox/palette, wizard, progress window (although I think we generally want to do away with those and embed progress in parent window) etc. Show which titlebar buttons, titles, icons, alert wording, button layout etc. are appropriate for each.
  • Could also take one step further back and have general patterns for each common type of application: document editor (e.g. text, graphics, audio, video), browser/viewer (e.g. file, web, help), utility (e.g. calculator, character map), game. Main differences between them would likely be certain standard menu/toolbar items, navigation models, ability to handle multiple documents, presence/absence of open/save/import/export facilities.
  • May be some patterns related to stock/common dialogs, especially those that are extensible... e.g. adding thumbnail preview area or Play/Stop buttons to File Open dialogs.

There is much wider discussion to be had here around anything fundamental we might want to change for 3.x. E.g. in Preferences dialogs, we really need to figure out this time what combination of Reset/Undo/Defaults buttons to mandate. In application windows, we may want to revisit the whole "Should we really need a Quit menu item?" debate.

Chapter 4 - Menus

Much of this chapter is a description of stock menu items, and where they should normally appear in an application's menu structure. Could probably just have one pattern for each. And/or, if we were to go with the 'pattern for each common type of application' idea mentioned in Chapter 3 notes, we could use those patterns to show where stock menu items for that type of application should normally appear.

Probably still want to maintain a table of commonly-used shortcut keys somewhere. (Not necessarily just for menus; window manager and toolkit-level would be useful too.)

Possible UI patterns:

  • 'General' menu layout illustrating grouping guidelines, use of ellipsis (do we want to revisit the current guideline here that confuses a lot of people?), capitalization style etc. (Cf. ยง4.2.1 in current HIG: "A Typical Drop-Down Menu".)
  • One pattern per common menu: File, Edit, View, Insert, Format, Go, Bookmarks, Windows, Help.
  • Context menus, showing typical general ordering and guidance on what functions to include.
  • Appropriate use of two items vs. single dynamic item (e.g. should Reload/Stop, Play/Pause be separate?)
  • Appropriate use of two radio button items vs. single checkbox item (latter only suitable when two items are logical/natural opposites).

Chapter 5 - Toolbars

Again, very little here that couldn't just be done with a few choice UI patterns, I think.

Since toolbars are fairly closely related to menu bars, it may be that some toolbar patterns are really menu+toolbar patterns, or part of the possible 'different types of application' patterns mentioned in Chapter 3.

Possible UI patterns:

  • Patterns showing good examples of which buttons do/don't have labels (since current default is 'labels beside buttons', which I presume is carrying on into GNOME 3.0?)
  • Consistent UI for allowing user to show/hide/customize toolbars. (Where are we on providing a toolbar editor widget, and does it leave any scope for inconsistency that we'll need to address here?)
  • Toolbar tooltips : might want to think about a richer format than we currently have, e.g. include keyboard shortcut, say why disabled items are disabled.
  • Zoom controls

  • Media player transport controls (assume we don't have a convenience/compound gtk+ widget for that yet?) -- cue the old 'should Play/Pause be separate buttons, and should we have a Stop button' arguments :)

References:

Chapter 6 - Controls

General

Possible UI patterns:

  • Sensitivity, when to disable controls v. hide controls.
  • How to show/deal with controls that are locked by sysadmin (i.e. mandatory gconf settings). Should there be a way to 'unlock' those controls if you know the root password?

Text entry fields

Possible UI patterns:

  • Laying out groups of text entry fields (e.g. name/address forms) -- show label alignment and positioning, left-edges of text fields aligned. When to align right edges of text fields, and when not.
  • How to indicate units. If the units are fixed, should we mandate: "Length (cm): [ 12]", or "Length: [ 12] cm", or something else? If units are variable, should we mandate "Length: [ 12][ cm v]" (with dropdown of available units), or "Length: [ 12cm]" (where user can just type desired units along with value), or combination of both?

Spin boxes and Sliders

Some useful information in this section about when to use a spin box, rather than a slider or some other widget.

Possible UI patterns:

  • Using/labelling tick marks on sliders.
  • Slider controls linked to spin boxes; how to lay out and when to use together, rather than one or the other alone.

Buttons

I suspect most of the stuff we can say about buttons will be implicit in other patterns, such as those for preference dialogs, alert boxes etc.

Check Boxes, Radio Buttons and Toggle Buttons

Possible UI patterns:

Possible UI patterns:

  • When to use drop-down list rather than a group of radio buttons or a list box. (Might all be covered by a single pattern, 'Presenting mutually-exclusive options', or something...)
  • Proper usage on toolbars

Possible UI patterns:

  • Text completion, typeahead -- is this all built-in to the widget these days (gtk-demo suggests not), or do we still need to spell out the way it should behave?
  • Immutable vs mutable combo lists. (Although can't actually think of anywhere that an immutable combo list is actually useful, off-hand...)

Scrollbars

Quite a few guidelines here about what *not* to do. Should we have 'Negative UI Patterns' for this sort of thing? (My gut feeling is 'no'.)

Possible UI patterns: Can't really think of any useful ones that just show you how to use scrollbars. Good scrollbar usage will probably be implicit in several other patterns, though.

Lists

Possible UI patterns:

  • Simple checkbox list -- if/when clicking checkbox should select the row, and if/when it should select the button without changing the row selection? (We may decide it should always change the row selection, but I know I've designed things myself where it's convenient to separate the two actions.)
  • Simple radio button list -- as per checkbox list.
  • Sortable lists (correct use of arrows in column headers -- will we finally agree on which direction means which sort order?!)
  • Lists with secondary sorting (i.e. sort by X, then by Y)?
  • 'Rich format' lists, i.e. things like gEdit Plugin Preferences dialog, which combines checkboxes, icons, and different styles of text.
  • Allowing user to add/remove arbitrary items to a list (probably using Add/Remove buttons).
  • Allowing user to edit list items. When to use in-place editing? Should there always be an Edit button, even if in-place editing is allowed? What to do when in-place editing isn't sufficient (e.g. need to edit in a sub-dialog)?
  • Creating/editing multi-column lists. Keyboard nav particularly important here... should be possible to enter multiple rows/columns of information at once without having to use the mouse. (Example I worked on recently -- network config dialog, where user can enter multiple rows of IP address/subnet mask information for a single NIC.)

Trees

(Many patterns we think of for Lists will probably also apply to Trees.)

Possible UI patterns:

  • Indicating that something has 'happened' within a collapsed branch. E.g. In the contents sidebar of a document viewer, how to indicate that the currently-viewed page is in a currently-collapsed branch of the contents tree. Or in a mail app, how to indicate that new mail has arrived in a folder that's in a currently-collapsed branch of your mail folder tree.

Tabbed Notebooks

Possible UI patterns: Ask AllanDay, he's done a lot of work on this :)

References: Allan's tab thoughts

Progress Bars

Probably covered by the set of 'Feedback' patterns, below.

Status Bars

Probably some wider discussion to be had here about the role of status bars in 3.x, looking at what we currently show in status bars and whether there's a more appropriate way to show that information. They are somewhat of a dying breed, e.g. in Mac OS X, only the web browser really has a status bar these days.

Assuming we keep them around, use of status bars should be covered in individual patterns where appropriate. General status bar might include examples of general layout (e.g. show text messages on left, and graphical indicators on right, for LTR locales?)

Frames and Separators

Usage should be largely implicit in other patterns, with perhaps some information in the companion 'book' about general layout principles in 3.x.

Chapter 7 - Feedback

Covers a wide range of stuff, all sorts of things we could probably talk about here. Current HIG has a good introduction to what makes a 'responsive application', and the well-researched levels of 'acceptable response times' that require different types of feedback.

Possible UI patterns:

  • Feedback during different types of drag-and-drop operations
  • Showing progress for interruptible v non-interruptable processes (e.g. when/where to show Stop or Cancel button, and the difference between Stop and Cancel).
  • Showing progress in the background (e.g. on panel) for long processes
  • Showing app-specific progress in application's status bar.
  • What additional detail to show along with a progress bar, and where (overlaid on progress bar, or above/underneath?), for common types of operation such as copying/uploading/downloading files, installing software, .
  • Showing estimated time remaining -- calculate on total time taken for overall progress so far, not how long the latest 'chunk' of the process took, especially for network operations. What to show when ETR gets near zero -- still show estimate in exact seconds, or something fuzzier/more realistic like "less than a minute", "less than 30 seconds", etc.?
  • Progressive disclosure of results -- for longer query operations (e.g. a database search), showing results as they become available (either immediately or at short, regular intervals) so that the user may select and act on them before the entire set of results is available. Note that separate progress indication still required so that user can differentiate between 'search complete' and 'search ongoing but not currently finding any matches'.

Chapter 8 - Visual Design

Another wide-ranging topic that possibly doesn't need any specific patterns of its own. General philosophy possibly best covered in the companion 'book', with all the patterns in the library embodying those principles.

If we still have to tell people how many pixels to leave between two controls, we've failed :(

Chapter 9 - Icons

Just point people at the Tango style guidelines for icon design/colour guidelines?

Section on high contrast icons needs updating; SVG now preferred format, although we haven't switched over to the SVG icon theme by default yet. Low Contrast icon stuff can now be completely removed.

Chapter 10 - User Input

Mouse Interaction

Again, probably nothing here that needs its own specific UI patterns. There are some good guidelines here (e.g. use of drag/drop modifiers) that probably need to be centralized in the companion doc, though, and implemented and referenced in individual UI patterns where relevant.

Keyboard Interaction

Tables of standard shortcut keys might be useful to keep somewhere centralized as well, although should also be mentioned in any patterns where menu items are used.

Chapter 11 - Language

Labels

Again, probably some general guidance about capitalization etc. needed in the companion book, referenced by individual patterns where necessary.

Warning and Error Messages

Can probably be covered by a couple of good Alert patterns (Chapter 3).

Online Help

Not much to say about this, other than ensuring patterns show a consistent way to access it. Those 'ways' may be something we want to discuss, however... e.g. is having a clunky 'Help' button in a random selection of windows still appropriate these days, or should we just be doing it all via the menus, with a richer selection of Help options available there than just 'Contents' and 'About'?

Note: One thing current HIG doesn't cover, because GNOME docs guys at the time weren't keen on it, is Inline Help -- short instructions near controls or groups of controls. Despite that, it's not uncommon to see inline help in GNOME nowadays. So we probably want to thrash out some guidelines with the docs guys, and include in our patterns where appropriate.

Chapter 12 - Checklists

This was a pretty lousy attempt at getting developers to do a certain amount of usability/sanity checking before they unleashed a new GNOME application on the world.

We'd obviously still like them to do that, but with developers being somewhat more aware of usability issues these days, and the GNOME community (perhaps) having UX Advocates around in future to liaise with developers early on, these lists are probably a bit out-dated.

Design/HIG/Planning/CurrentHigAnalysis (last edited 2014-06-20 10:18:19 by AllanDay)