OpenOffice Impress toolbar click map

More information on what they’re doing can be found over on the GullFOSS Blog.

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.

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…)

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

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

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

Last week I had cause to revisit the issue (for much the same reason as before—updating the OpenSolaris UI spec), hoping that things would have improved and I wouldn’t have to suggest too many tweaks to the OpenSolaris layout to keep things nice and consistent.

Unfortunately, it doesn’t look like much has changed though, really, which is kind of disappointing. (Especially as seeing this bug marked as resolved had built up my hopes a little…)

Caveat: as in my original post, the latest release of Ubuntu (8.10, GNOME 2.24.1) was the closest I had to a community build when I was doing the comparison. So things may really be a little better or worse than they appear here, or may have been fixed in 2.25/2.26.

So I hacked up a quick diagram showing all the menus and sidebars where bookmarks and places appear, and aligned them on the “Home Folder” entry since that was about the only one that was consistently placed. Here’s what I came up with:

Side-by-side comparison of bookmarks/places in Ubuntu 8.10

The plusses:

• The two Places menus on the panel (one in the menubar applet, one in the main menu applet) are now identical, at least in Ubuntu. This is good to see, although most users won’t see both at the same time anyway.
• The Go and Places menus in Nautilus (browser mode and spatial mode respectively) are pretty consistent with each other too.

The minuses:

• Inconsistent appearance/placement of mounted media, Computer, Desktop, Templates, File System, and CD/DVD Creator between sidebars and menus.

Of course, it would be wrong to complain without offering any proposals, and I’ll get to that—just haven’t got time today. The current draft of the OpenSolaris 2009.04 UI spec does include my first quick attempt, but that’s currently based more on “least amount of work to fix” rather than “what might be most useful”… and we all know that’s not really the way to do it, right kids?

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.

But despite taking a keen interest in GNOME usability for the thick end of a decade, I haven’t specifically commented on any of their mockups.  Why not?

Because if we’re serious about this undertaking, now isn’t the time to debate the merits of major design changes among ourselves. It’s the time to go out, talk to our users, watch them using GNOME, and work out what needs to change, what might be cool to change, and (just as importantly) what needs leaving alone. And that’s before we even think about making any more mockups.

And when I say “our users”, I’m not talking about the usual suspects here, either.  I mean the silent majority who don’t show up at GUADEC, don’t hang out on mailing lists or IRC, and don’t file bugs.  The ones who might not even use GNOME through choice, but might just have got out of bed one day to find it’s been installed on their office or school computer, or on the kiosk in their library.  And the ones who don’t even know they’re running GNOME at all, but who just know they have some desktop or mobile device that doesn’t look exactly the same as Windows does at home, but that it kind of works the same.

With all due respect to those who’ve put their ideas on the line so far, making visionary mockups of a brave new world isn’t usually all that difficult—although it’s certainly fun Making mockups that meet well-researched, documented user requirements takes a bit more effort, though, and refining those mockups into a product based on iterative feedback from a representative sample of users is, well, a lot of hard work.  You only need to look at the amount of software that sucks for proof of that.

With that in mind, let’s do it!

(FWIW, I did some further waffling on this theory in my response to Stormy’s mail on the usability mailing list recently.)