Category: Usability

Different day, same Places

A couple of years ago, I bemoaned the inconsistency of our presentation of bookmarks and places.

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
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? 🙂

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.

On the new shell

It’s great to see Vincent, Owen, Federico, Karl et al. thinking about bold ways to bring the GNOME desktop into the 21st century.  With guys like that motivated to make it happen, we certainly have more than a fighting chance.

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

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…

Red cheese

Daniel, I suppose the first question is “why does it need to be red?” Anything that animates is going to catch the user’s attention anyway, so I don’t see any great harm in keying the background to the theme.

That said, since gtk+ 2.10, haven’t themes been able to support additional named colours, to highlight things like ‘errors’ and ‘warnings’ where appropriate? So shouldn’t Clearlooks and the other themes be providing these now? Or did we just never decide what the standard list of named colours should be? :/

CHI 2008

Back in Dublin after spending last week at CHI 2008 in Florence. I posted a few entries over on Sun’s design blog while I was there: [Day 1] [Day 2] [Day 3] [Day 4]

Main takeaways of GNOME interest, in no particular order:

  • I/we really need to get the HIG moving again, preferably in a less monolithic fashion
  • It will be really cool to see what sort of insight the InGimp data analysis gives us, and whether it would be feasible/worthwhile transferring the idea to GNOME.
  • There still really aren’t many people working on open source usability projects, even in academia :/

Seven new pennies

Not liking the new British coins all that much, I have to say.

Apart from the fact they look a lot like the cardboard money that I used to have in my toy cash register many years ago, they don’t look very friendly to tourists who might have little or no English, and/or just bad eyesight. I’d have thought the first rule of currency design would be to use biggish numbers, not just (in some cases, tiny) words?