Human Interface Guidelines - London Hackfest Notes

The current Gnome Human Interface Guidelines are in the Gnome Documentation Library.

The guidelines are showing their age. On Tuesday 2010-02-23, Calum Benson, Brian Cameron, Willie Walker, Matthew Paul Thomas, Garrett LeSage, and Hylke Bons discussed how to revise and update them. These are their notes.

HIG Three Point Zero

What the HIG is

  • A collection of guidelines and patterns that will help you to reuse well-tested solutions to common problems in human-computer interaction.
  • Anything else?

What the HIG isn't

  • A set of rules that, if slavishly followed, will result in a usable, accessible application.
  • Anything else?

Format and access points

  • Should Glade have context-sensitive help that opens the appropriate part of the HIG?
  • Should we make a printed version available through or similar (all profits to the GNOME Foundation?)

Ideas for improving the structure

  • Consider using RFC must/should/may wording for guidelines, to indicate approximate levels of importance?
  • Remove duplication of layout information between controls pages and layout pages
  • Remove duplication of keyboard shortcut defaults - single section for default shortcuts
  • Visual table of contents for window types and control types (integrate the currently-separate GTK+ widget gallery)
  • Visual cheat sheet for each section (mockup showing you most of what you need to know)
  • Adding a simple smoketest page describing common usability failings
  • Advice for developers on dealing with bug reports, and mailing list questions
  • Split out icon guidelines (e.g. Tango)
  • Separate guidelines for mobile applications? Or forkable for mobile OSes
  • In each section, give a pointer to the GTK/Glade/etc techniques necessary (e.g. indentation of controls)

Things that are missing

  • Notification bubbles
  • Animations - not too obvious, not too excitable, subtle and informative
  • Changes since Gnome 2
  • Top differences from Windows, Mac OS X, Java/Swing
  • Notes about how particular things differ from Windows/Mac OS X/Java
  • Wizards/assistants
  • Resolution-independent layout guidelines?
  • Full-screen mode guidelines (how to get in to and out of)
  • Consistent use of tab controls (fix at toolkit level?!)
  • Integrated reminders about accessibility (e.g. text fields without labels still need accessible names)
  • When and when not to remember state
  • Appropriate default focus for windows
  • Correctly filling out .desktop files

Target audience and use cases

  • New developers — want a quick guide to what’s different/distinctive in Gnome
  • Existing developers, developing a new application — what should it look and work like?
  • Existing developers, with existing application — want to get in and out as fast as possible
  • Bug reporters and triagers — want a reference for what is or isn’t a valid bug report, to cite in Bugzilla
  • UI designers from other platforms

Possible patterns/guidelines

NOTE: For latest list of potential patterns, see the current HIG analysis

What is GNOME's HIG purpose, what is the "concept" behind GNOME's UI

  • Simple - No useless options presented to the user, no confusing options
  • Elegant - clean visual layout, unecessary clutter, alignment of elements
  • Universally accessible - Everyone can use it, 3 - 93 years, no-matter what disability, background, language
  • Obvious, discoverable, learnable - common operations should be visible, should be easy to learn advanced operations
  • Helpful - requiring as little work from the user as possible, staying out of the user's way, anticipating the user's needs, presenting them with what they are most likely to need
  • Scalable - apps work as well on laptops and netbooks supporting one or two users with local resources (home directory, printer, DVD burner etc.) as they do in a university or workplace supporting thousands of users with distributed resources.

Possible formats

  • Wiki/website for pattern library?
    • Have some process around categorising patterns (stable/experimental? alternative patterns for different types of device?), accepting/obsoleting patterns, inviting submissions from maintainers/users
    • Should allow us to be more 'nimble' about updating our guidelines
  • Mallard for more static, long-term guidelines?



Design/HIG/Planning/2010-02-23-Notes (last edited 2014-06-20 09:44:12 by AllanDay)