This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex

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.

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:

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:

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:

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:

References:

Chapter 6 - Controls

General

Possible UI patterns:

Text entry fields

Possible UI patterns:

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:

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:

Possible UI patterns:

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:

Trees

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

Possible UI patterns:

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:

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.


2024-10-23 11:03