Thoughts on Pattern Library categories

Most of you probably know that one of the things we’d like to do for GNOME 3.x, alongside a refreshed HIG, is produce and maintain a GNOME UI Pattern Library. (An example of what we mean by a GNOME UI Pattern is this semi-fictional example.)

I’m thinking we’d probably want a homepage that both allows you to search by text/tag, and browse by category (something like this quick mockup.) Which would, of course, mean picking some categories.

From a quick survey of other pattern libraries (which are mostly geared to web design) and the type of stuff the current HIG covers, here’s a first stab at what that list might look like.

  • Feedback: Showing messages, notifications and progress indicators.
    Examples: Alert messages, notification messages, InfoBar usage, status bar usage, focus indication, audio feedback.
  • Input: Enabling the entry of different types of information.
    Examples: Sliders, audio input, video input.
  • Layout: Arranging information and controls in a window.
    Examples: Frames, grouping, spacing, anatomy of creation vs viewer vs browser vs utility apps.
  • Navigation: Enabling users to move around and between documents and different parts of the application.
    Examples: Tabbed windows, sidebars, location bar, zoom controls, media transport controls(?).
  • Search: Enabling users to find items or information that may not be immediately visible.
    Examples: Find dialogs, in-place searching, filtering, auto-completion, Boolean queries.
  • Selection: Allowing the choice of one or more items from many.
    Examples: Marquee selection, keyboard selection, pattern matching.
  • Social: Maintaining contact information, and interacting with other users.
    Examples: Adding information to address books and calendars, Showing online presence, Initiating chat.
  • Workflow: Relating to the process/mechanics of using an application to achieve a particular goal.
    Examples: Desktop integration, undo/redo, drag-and-drop, extending open/save/print dialogs.

Feedback welcome… any obvious ones I’ve missed, or ones that seem redundant?

FWIW, I’m not sure nailing the list now is either entirely necessary or entirely possible. There’s no reason we can’t adjust them as the library grows, and I hope we’ll have some sort of tagging capability to handle the patterns that don’t fit neatly in a single category anyway. But it’s always good to start from as solid a foundation as we can ๐Ÿ™‚

GNOME Usability Hackfest

Back in the Dublin office today after last week’s GNOME Usability Hackfest in London, during which I didn’t blog nearly enough.

My main goal for the week was to help figure out a plan to revise the GNOME Human Interface Guidelines, which I originally helped to write almost a decade ago, but which really haven’t kept pace with the changes in either hardware or software technology over the past 5 years.

The notes from all the discussions we had aren’t all that impressive to look at, but I think the key thing is the general agreement to have less monolithic text, and switch to more of a pattern library approach. This should allow us to react much more quickly to changing trends in GNOME UI design, maintain related patterns for different types of devices such as desktop, touchscreen and stylus devices, and even allow individual distros to customize the library with their own unique, in-house patterns if they so desire. (Which hopefully won’t be too much, but it’s clear that, for example, the GNOME-based Moblin UI is a different beast from the vanilla GNOME desktop, so the Moblin team will likely want to maintain some patterns of their own.)

I’ve already started to draft up a template for what a GNOME UI pattern might look like, and hope to flesh things out a bit more over the next couple of weeks.

Of course, many other things were discussed at the hackfest as well. Nautilus and gnome-shell were hot topics, as was the old chestnut of a GNOME control centre redesign—on that front, I ended up moderating a couple of card sorting sessions during the week where we had users categorize 100 settings into groups of their choice. Charlene from Canonical presented an Empathy usability report, partly to discuss the findings, but mostly to discuss how best to present such reports to GNOME developers. And of course, Seth’s vision of a future GNOME desktop hit the headlines, making it to Ars Technica almost immediately!

On the community front, some ideas for improving the tools we use to analyse and report usability data were also discussed. And there was a strong presence from the accessibility community, to keep us all honest when coming up with anything new.

Many thanks, of course, to Google and Canonical for sponsoring the event, and particularly to the latter for hosting us in a 27th floor office so we didn’t need to waste money on the London Eye ๐Ÿ™‚

“The Future of UI Will Be Boring”

In the midst of all the hype, speculation and (in many cases) nonsense being talked about whatever it is Apple are going to be unveiling next week, it was refreshing to read Scott Berkun’s reminder of why keyboards and mice definitely won’t be going away anytime soon.

(His follow-up post, about the Limits of Innovation, is worth a read too.)

GNOME usability futures

Didn’t blog about this at the time as I guessed anyone who was interested would be on the usability list anyway, but in retrospect that’s probably not true so I’ll summarise here as well.

Just prior to the Boston Summit, mostly in response to some prodding from Brian, a few of us started kicking around some ideas for dragging GNOME’s usability activities into the 21st century. General areas for discussion include:

  • improving the HIG (e.g. turning it more into a visual pattern library with code samples, with a wordier secondary document for issues that still required it)
  • novel ways to gather valid usability data for GNOME (e.g. instrumenting applications, online surveys, remote usability testing via webcam/voip)
  • possibility of a Foundation-funded mobile usability lab, similar to the one Mรกirรญn demonstrated at the Boston Summit
  • .

Anyway, if you want to join in the discussion, it’s mostly happening over here.

Planning for change

This sort of thing always worries me. I really wish we had a more formal way of alerting users that functionality was going to go away, rather than just pulling the rug from under their feet when they install a new release.

At Sun, and I’m sure at most other companies that support software products, we have to tell our customers in advance when (certain) features are going away. We can’t just drop them from one release to the next because we’ve gone off the idea.

Personally, I’d like to see GNOME manage this a lot better, perhaps (from the end user’s perspective) via a section in the GNOME release notes that said which features we intended to remove from the next release. The impact of such changes would then have to be thought through well in advance, and there’d be plenty of time to remove the feature, fix any related issues, and properly update the documentation prior to its actual disappearance. And users would have time to prepare for the change, and have the opportunity to raise any sensible objections before the fact, rather than after it.

(This thought isn’t especially new, nor directly aimed at the proposed Windows capplet removal… although I do know that’s a decision that would generate support calls for Sun users and customers, who always scream when anything related to their sloppy focus settings breaks, changes or goes away. Many of them have been using sloppy focus on UNIX desktops since before GNOME or even Linux were first thought of, so it’s not a feature we like to mess with…)

Control Center Refresh redux

Quick follow-up on my last post about some ideas for a GNOME control center refresh.

Kristin and Jenya are running a usability study on three control center designs in the Sun labs this week (current GNOME control center as a baseline, plus two of their alternative designs). There will be 10 participants over three days, a mixture of “developers, technical end users, and technical students”.

We will of course share the results as soon as we have any to share ๐Ÿ™‚

Control center refresh

Some of you have probably heard that some folks at Sun have been working on a proposal for a tidied-up GNOME control center shell. Well, at long last, here are some details!

First of all, I should say that I actually have little personal involvement in this project—it’s being led by Kristin Travis and Jenya Gestrin of Sun’s xDesign team… I’m just abusing my position on Planet GNOME to plug what they’re doing ๐Ÿ™‚ And as yet, there’s no production code to speak of, just mockups and Flash prototypes, so there’s still plenty of scope for feedback.

You can download the latest protoypes, peruse numerous mockups, and read about the design process to date (including a usability study on the capplet categorisation) on the Usability Project’s Control Center Whiteboard pages.

Latest control center mockup
Latest control center mockup

Feedback welcome here, on the control center mailing list, or direct to Kristin and Jenya.

gnome-shell on OpenSolaris

Kudos to Brian for getting gnome-shell up and running on OpenSolaris—since I’ve barely touched a Linux distro in the past year or so, this has really been the main thing that’s been stopping me from taking a proper look at it, and getting involved in what’s clearly going to be an important part of GNOME’s future. I guess I don’t have any excuses now ๐Ÿ™‚