My Five Answers…

… to the five questions on the GUADEC website.

1) Who are you and what do you do?

I’m Calum Benson, and I work for Oracle (neé Sun). As well as working on some GNOME-based projects for Solaris and OpenSolaris, I’m one of the authors of the original GNOME HIG, and I’m one of the maintainers of gnome-themes, where I mainly look after the high contrast themes.

2) How did you get into GNOME?

I was hired by Sun in 2000 when they started to replace CDE with GNOME in Solaris. I’ve been working on GNOME ever since, and have attended every GUADEC except Paris and Stuttgart.

3) Why are you coming to GUADEC?

To talk about, and hopefully get some work done, on the new HIG and UI pattern library that we’ve been planning to do for GNOME 3.x. I dare say one or two beers may also be consumed.

4) In 1 sentence, describe what your most favorite recent GNOME project has been. (Doesn’t have to be yours!)

Hmm. Sadly haven’t really been involved enough with any recent project enough to have a firm “favourite”, but SparkleShare could revolutionise the way designers work on GNOME. (Except me, because just at the moment it’s way too hard to get it working on OpenSolaris…)

5) Will this be your first time visiting the Netherlands?

Yes.

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 🙂

End of an era…

usability.gnome.org is no more.

Well, okay, that’s not quite true 🙂 The old developer.gnome.org sub-site it redirected to is no more, because all the content has moved, mainly to the Usability Project wiki. Hopefully we’ll get some new redirects in place soon.

This has left the online version of the development branch of the HIG without a home (the stable version, of course, moved to library.gnome.org a while ago). So for now, I’m hosting that here.

EDIT: D’oh, seems the development version was already online too, at http://library.gnome.org/devel/hig-book/nightly. I’ll dump the version from my homepage shortly.

HIG 2.2

I just bumped the stable version of the HIG to v2.2.  

Really it’s more of a 2.0.1 release, as none of the content has changed apart from the illustrations, which have all been updated to use the Clearlooks theme.  But given the number of people involved (Mihai Anca, Denis Anisimov, and Wouter Bron did the bulk of the illustrations) and the length of time it’s taken me to integrate them (about 9 months!), 2.2 seemed more appropriate…

(Unfortunately, nowadays you don’t get to see new versions of the HIG online until there’s a new release of gnome-devel-docs, and I know I just missed 2.24.0. But hopefully there’ll be another one along soon.)

Of course, this doesn’t address the more fundamental issue that the HIG now lags several years behind the curve of GNOME development. I’d like to think we’ll get around to doing something about that before the year is out.

Tab frenzy

Have to admit I cringe every time somebody adds tabs to an application. Not because I have anything against appropriate use of tabs (and I’ll reserve judgment on which of the recent additions are appropriate for another day), but because it’s such a wasteful duplication of effort, with each instance doubtless having its own inevitable little bugs and inconsistencies.

The HIG advises against document-level tabs in an app, largely because at the time, the usability team hoped GNOME would have a tabbed window manager in its not-too-distant future. The tab-related activity in the past week has me thinking me that we need this more than ever! App developers shouldn’t have to implement basic window management features, and (perhaps more importantly) users shouldn’t be restricted to grouping documents from the same application into tabbed windows–with a tabbed WM, they could still do so if they wanted to of course, but they’d also be free to group windows by task or project, or indeed any other way they wanted.

Is it worth starting to think a bit harder about how a tabbed WM might work (I don’t think we’ve ever sat down to try to design one for GNOME, although I know at least one tabbed WM has been implemented before)?  Or is it just something that’s just never likely to happen?

Rockstars and decadence

I started writing this as a comment on Andy’s post, but it ended up quite long so I decided to blog it instead 🙂

From a user’s perspective, I’m inclined to agree—to put it bluntly, I can’t really recall the last major innovation I saw on my GNOME desktop. After all these years, we’re still mostly working on things that Windows and, more recently, OS X, can do for us already if we’re prepared to pay Apple or Microsoft for the privilege.

Clutter is one such example—it’s a promising technology for developers, and maybe it will turn out to be a “way out” of the “decadence” Andy describes. But if we just use it to write clones of Front Row or CoverFlow or any of Apple’s other CoreAnimation-based apps, then Apple will have moved on again by the time we’re finished and we’ll just be playing catch-up again.

In any case, Clutter is just a toolkit, and toolkits don’t help us with the vague lack of coherence and integration on some parts of our desktop today, or the need for more clarity of purpose going forward. For that I applaud Havoc et al.’s vision of an online desktop—while it’s not one that desperately excites me personally, I don’t have anything better to propose, and having everybody focusing on something is surely better than nobody focusing on anything 🙂

As for the HIG—I really don’t believe that it stifles creativity any more than (say) Apple’s HIG stifles theirs, but it probably has been a victim of it’s own success to some extent. It was written six years ago, and as such, it describes the best practices for six-year-old GNOME apps. We do have plans to substantially revamp it, but it won’t happen overnight.

That said, the HIG shouldn’t drive major changes in GNOME’s UI, it should reflect them. But at the same time, the gtk guys (and others) need to know what changes to make for 3.0 that will support the sort of changes we might want to make going forward.

Everybody probably just needs to get talking and generate ideas to move that process along again, but I also wonder if maybe we don’t have enough rockstars in our community right at the moment—it’s much easier to reach a goal when two or three people are driving you there, than when a hundred people are all trying to make their own way.

I suck

I’ve been pretty badly neglecting my community duties recently… I have a backlog of ~2000 usability and HIG bugzilla emails to get through, and haven’t fixed any gnome-themes bugs in months. (I have at least started updating all the HIG images with the ones we got from the GHOPpers at the turn of the year, but still a good bit of work to do there, too.)

Sorry about that. I started making a bit of an effort this week to try and get through at least 10 of those bugzilla mails a day, and uploaded a few more of those HIG images last night too. I hope to continue in that vein for the next few weeks, at least…

HOPG – HIG screenshots

So, I’ve just noticed that some of the Google HOPG tasks involve updating the HIG screenshots.  I don’t know if the other HIG authors were alerted to this, but I certainly wasn’t.

Apart from a degree of discourtesy to the HIG authors, this oversight is surely particularly unhelpful to the people who claimed the tasks, as the maintainers who will ultimately decide if their work is fit for inclusion have not been around to offer advice as they were going along.

Also, FWIW, the draft version of the HIG already has several updated screenshots in it, so hopefully nobody has wasted their time duplicating those.  I’ll review what I can this week, but this is my last working week this year and I have other stuff taking priority.  So maybe Bryan, Seth, Anna etc. could help out here too, if they’re reading 🙂