(Push the Button)

We have been inspired by GNOME.  Moved to act by the ideas, ideals, and opportunities.  Encouraged to stay as we grow ourselves and as a community.  We know that the true measure of strength is not how much you can take but how much you can afford to give.  And we have demonstrated that, by sharing, we can all succeed.

GNOME is a story that continues to inspire me.  And in my eight years and counting, if I have achieved little more than making one person feel hopeful for and empowered to change their future, I will feel very good about the work we are doing.

As we march towards GNOME 3, I feel very strongly that our truest measure of success won’t be the technology, design, or ideology – but simply this: Will we continue to inspire?  I am very hopeful.  The signs are looking very good.  Back in June I asked, “Will a new crop of heroes emerge?”  Well, let me tell a short story and let you decide.

In November and again in early January, we posted some new design proposals for GNOME Shell.  Many of them went into a release of the design document and SVG mockups.  Others came out of discussions on IRC.  Now, nearly all of these changes are complete.  That shouldn’t surprise you too much if you know some of the hackers on the original Shell core team.  Those dudes are among the best we have.  However, that’s not how it went down.  It has been much more interesting than that.

Mockup from 6 January 2010

There are actually a lot of changes introduced here but I’d like to point out a set of exemplary and highly visible changes:

1. A new linear workspace presentation
2. Added undo functionality into the core system
3. New look for App running indicators
4. Updated presentation of the left dash and App Menu item in the Top Bar
5. Allow close windows directly from the window picker
6. No icons on desktop backdrop
7. Include eject buttons for removable media

All done.  Now let’s look at how, when, and by whom.

1. On Jan 22, Maxim Ermilov pushed the fix for bug 593844. Jan 23, Florian Müllner pushed a few more refinements.
2. Feb 5, Maxim Ermilov wrote the fix for bug 608933.
3. Jan 7, Florian Müllner pushed a fix for bug 606257.
4. Jan 7, Colin Walters pushed fixes for bug 605491.
5. In Nov and Dec, Florian Müllner pushed a few patches for bugs 602532, 603691, etc.
6. Feb 3, Maxim Ermilov pushed the fix for bug 591912
7. Nov 27, Florian Müllner pushed a fix for bug 602976.

You all know Colin Walters (Debian, Rhythmbox, Fedora, Mugshot, D-Bus, hacker man-machine) but you may not yet know Maxim and Florian because from what they tell me they are pretty new contributors to our community – but hell they sure know how to make an entrance.  Stay tuned.

By no means has the rest of the Shell community been slacking.  A ton of work is going on a bit behind the scenes and on the rapidly evolving Message Tray.  In the next few days we’ll be discussing the the next iteration of UX mockups and designs as well as exciting plan for evaluation of some of the claims we’ve made in our design process so far.  Come be a part of the action.

Over the last few weekends I’ve been working with Christian Hammond to try to get our notification specification, libnotify, and notification-daemon story in order.

Bugeye by bensonkua

Long story made short – things had become a bit fragmented over the last year or two.  A number of people tried valiantly to move the spec along but were unsuccessful in getting their changes published.  Everyone on the planet that was shipping libnotify and notification-daemon shipped them with a different set of patches.  This meant we had lots of different micro-forks of both the implementation and specification.  We even had a hard time agreeing on the version numbers for the specification.  Version 0.10 happened after version 1.0 was published.  Yikes, what a mess.

Some downstream distributions either decided to try to differentiate by writing their own notification-daemon implementation or writing custom bubble themes.  This kind of differentiation or fragmentation is dangerous (or at best anti-social) and should usually be viewed with some skepticism.  I should not be spared from this criticism either since I wrote a new theme that we used in Fedora 12.  (It is now included upstream)

So, out of respect for the original authors and innovators I put some time in to try to straighten this all out.

The canonical implementations have a new home:

• http://git.gnome.org/browse/notification-daemon/
• http://git.gnome.org/browse/libnotify

The notification specification source has a new home:

• http://git.gnome.org/browse/libnotify/tree/docs

The bug tracker does too:

• https://bugzilla.gnome.org/browse.cgi?product=notification-daemon
• https://bugzilla.gnome.org/browse.cgi?product=libnotify

We still need to find a place to host the new 1.1 version of the specification on the GNOME web site.  After discussing this with Fred Peters it seems like http://library.gnome.org/devel/references#standards is an appropriate place for it.  Hopefully we can decide in the next few days.

I have to give credit where it is due.  Most of what I’ve done is merging the changes from Andrew Walton and Aurélien Gâteau.  Thanks dudes for continuing to do the right thing and pushing changes upstream – even or especially when it was hard.  And thanks to Christian Hammond, Mike Hearn, and J5 for their vision and hard work in getting us to this point.

Now, hackers we need you.  Please grab these from git and test them out and file bugs.  I’d like to do a release in the next few days but it would be great if they got some testing before then.  Thank you!

Things have been rolling along in GNOME Shell land.  We’ve been experimenting and evolving the design as we go.

If you were reading this and this carefully you may have noticed links to a design document for the Shell.  I’ve just put out a long overdue update for that document.

Please read the GNOME Shell Design PDF and let us know what you think.  Higher resolution versions of some of the figures used in the document may be found here.  We’ll be adding these to the wiki soon.

Once you’ve read the document please grab the Inkscape SVG mockups and try to make them better.  I’m sure that you can.  My drawing skills are not exactly legendary.

Looking forward to hearing your thoughts and seeing your modifications.

As usual find us on IRC #gnome-shell on GimpNet or http://mail.gnome.org/mailman/listinfo/gnome-shell-list .

Make sure to try it out too.  It is really easy to use from jhbuild.  See http://live.gnome.org/GnomeShell#building

I’d like to expand a bit on one of the Fedora 12 polish items Matthias already blogged about.  Better Tooltips.

As most of you know, tooltips are the little window-like pop-ups that (hopefully) provide helpful information about a user interface element (widget, control, etc) as you hover over it.  It seems to me they were originally used to provide textual assistance for the case where the user is unsure what a tool will do when activated.  And were particularly useful when the tool had no intrinsic text.  However, since then their use has expanded and become more generalized.  They are used for quite a few different things today and can contain more than simple text.

Now granted, you have probably never been consciously annoyed by tooltips.  More likely you haven’t really thought a lot about them at all.  But that doesn’t imply there is no room for improvement.  I spent a few hours examining my own interactions with tooltips and I came up with a few things that bothered me.  These basically fall into the categories of: color, shape, and position.

The issues with color and shape are fairly obvious.  Yellow! boxes!  right out of the mid 90s.  The issues with positioning are a bit more subtle.

Before

Notice how the tooltip:

• Obscures what you are looking at
• Gets all up in your shit
• Does not appear in a stable position
• Appears to be more closely associated with the pointer position than the thing that is providing the tip

How about something like…

After

Niiice!

Thanks Matthias.

Things are brewing in the Fedora Desktop community.  Red Hat designers, engineers, and many active Fedora community members have been working hard to make the GNOME user experience great.  Some enthusiasts may notice a bunch of this work showing up in Karmic today (congratulations to our friends on another fine release!).  Though of course we’d encourage you to check out Fedora 12 in a couple weeks too.  We are sure Fedora 12 is going to be our best release yet.

We’ve also been thinking a lot about how we need to improve and where we need to go – and specifically, how we can better serve your needs and improve your experience.  Clearly, we have a lot we need to change and there are many challenging decisions ahead.  But it is my personal promise to you that we will get there and it will be awesome.  Consider this a declaration of intent… to be awesome.

We know what we do well.  We drive innovation upstream.  We have some of the most trusted and talented people around and we are tirelessly producing amazing stuff.  Every day I feel honored to be listed among the rockstars on the Fedora Desktop Planet.  Though sadly, it is our fault that so few know what we’re up to.  And we aim to improve this.  We hope to improve the transparency of our activities.

We know that many of you feel that we’ve been catering to the most vocal members of the enthusiast community and ignoring your needs.  We aim to improve this.  We want to raise our standards and your expectations.

We are one of the world’s most trusted advocates for software freedom.  Free Software runs in our blood here.  But we know that freedom is not enough.

We can’t do any of this without your help.  We need your feedback.  What are we doing well?  What are we doing wrong?  What can we do for you?

As with any good partnership the responsibility runs in both directions.  We promise to listen.  But we also hope that the community is up to the challenge of providing high quality – high signal – feedback.  We need real partners in this endeavour.

So please join us.  Show up, and be awesome.

Follow our latest shenanigans on twitter (as fedoradesktop) or our Planet feed.  If you are a Fedora Desktop user, share our goals, and are an active upstream contributor or contribute to the Fedora Desktop user experience and you’d like to be added to the planet, please let me know.

Or, as always, join us in #fedora-desktop on GimpNet.

Thanks.

Things are underway here at the GNOME Boston Summit.   After a quick introduction we took proposals for sessions.  Owen is posting a schedule to the wiki now.  We’re going to be posting regular updates to our Twitter feed.  We’re also hanging out on IRC in #boston on GimpNet.  So, feel free to come on down and talk to us in person – or join us online.

One of the things Jeremy Perry and I have been working on in the GNOME Shell design is a way to make application launching work better.  You can see some of this in the following mockup:

Activities Overview Concept (drawn by Jeremy)

As you can see there.  We need short “brand” names for the Favorite apps.

So, in preparation for GNOME Shell, a few of us have been looking into how we should handle application names in GNOME 2.28 – since GNOME 2.28 is primarily a prepatory release for GNOME 3.0.  We need to make a decision on this soon.

First, some background.

What is a name?

Applications, like many things, have a few different names associated with them.  Such as:

• Unique Identifier — rhythmbox.desktop
• Generic name — Media Library
• Brand Name — Rhythmbox

This is analogous to what we find in the consumer pharmaceutical world:

• Chemical Name — 7-chloro-1,3-dihydro-1- methyl-5-phenyl-2H-1,4-benzodiazepin-2-one
• Generic Name* — diazepam
• Brand Name — Valium

Note: I’m ignoring differences between INN, BAN, USAN for this.  And also ignoring the fact that generic drugs are usually exact copies of the same chemical substance.
Also see:  this and this.
For both drugs and applications, generic names are meant to be a substitute for a brand name.  They are not classifications, categories, or descriptions.  For example, an alternate for Tylenol may be called acetaminophen / paracetamol but it belongs to the categories of analgesic and antipyretic.

In the open source world, our application naming system is described in a nearly universally adopted freedesktop.org specification.  However, the specification does not address how these names can and should be used.  Nor does it address how a name should relate to an application icon.  These are things that we (GNOME) must decide.

How are names used?

Let’s go back to our drug example again to think about how these names are used.  At least in the US, Tylenol is like Firefox (ha, Mozilla.com wishes!) in that it is a very widely recognized brand among consumers.  So, for our purposes let’s suppose a new relatively unknown brand of orally administered analgesic: Livernol.  There are a few different ways this name is used:

1. Local Pharmacy

   Kelly goes to the store with the intention of finding something to ease her headache.  She probably won’t know the name Livernol, she may ask the pharmacists if they can recommend something like Tylenol or that can help with headaches.  They may hand her Livernol and she can confirm from the descriptions on the label that it is will help with headaches and may be compared with Tylenol.

2. Medicine Cabinet

   Kelly has another headache (she is a designer who works with open source software).  She staggers to the bathroom and grabs the bottle of Livernol on the shelf.  No need to read the descriptions since she knows what it is.  However, she may consult the documentation if she has forgotten how to use it.

3. Talking to Experts

   Gosh darn headaches won’t stop.  Kelly goes to the doctor.  She tells the doctor that she gets headaches frequently and the analgesic she takes doesn’t seem to help.  The doctor asks her what analgesic and then looks looks up the chemical name and then details about it.  He informs her that this isn’t the best choice for her since it doesn’t treat her specific problem and it has a number of unwanted side effects.

4. Online Pharmacy

   Now she is looking for something else on an online store since she didn’t find it in the local one (or didn’t trust the recommendations).  The doctor scribbled on a note “napro…” something.  Oh here it is, the store generic Naproxen Sodium.  Label descriptions and reviews confirm it is good for severe headaches.

[Public service announcement: consult your doctor to make sure Tylenol is right for you]

So what does this have to do with software?

In GNOME Shell we want to handle the above scenarios separately.

1. When looking for something new you can either browse or search through a rich set of information
2. When you already know something you want to optimize for easy access
3. When you need help or just want to share information you need to be able to talk about it unambiguously
4. When you don’t find what you need on your computer, it should be simple to find and access more online.

Matthew Paul Thomas has discussed some specifics of naming on the GNOME development mailing list before.  I agree with what he says there.

So what rules govern the use of Name and GenericName?

Proposed guidelines:

• When Name is the same as GenericName, the GenericName should be removed
• The desktop entry Name value, application menu (for GNOME shell), window titlebar (for GNOME 2.x), documentation, and about dialog should all use the same name
• The desktop entry Name value should be the brand name unless the application is a simple (single purpose), core GNOME built-in and does not have an established external brand identity (web site, online help, etc)
• Brand names should be considered carefully but can’t be relied on to indicate functionality in many languages
• Application icons should supplement names of all kinds and are critical to recognizing already known applications

Examples:

• It doesn’t make sense for Dictionary or Calculator (GNOME is implied) to be separately branded.
• It is fairly clear that something like Firefox or Rhythmbox is branded.
• Totem which actually do bit more than the generic name implies (It is a little strange that Movie Player plays songs and youtube – according to the description) but the name isn’t known outside of GNOME for the most part.
• gedit is tough because the name doesn’t “read” well and it is a pretty core component. However, it does have an external presence and the authors feel it should be called gedit.

That’s nice but how do we handle this in the current panel?

Frederic Peters made a nice proposal to XDG list to add another entry to the spec to over the case where the two names are used in menus.  The primary reason for this was to try to avoid problem translating the combined use of Name and GenericName.  I was initially in favor of this approach.  However, the proposal was not well received.  After discussing the proposal with Owen Taylor, Matthias Clasen, and others I don’t think we can rely on this solution for a few reasons.

• We will only need this solution in GNOME for a single release.  It isn’t required for the GNOME Shell.
• It will take a significant amount of time for all desktop files in existence to be updated to use the new key.
• We will need to create a fallback solution for desktop files that don’t have FullName.
• It isn’t clear that translations should fundamentally alter the design of the menu entry layout.
• It isn’t clear how you can do much better with a translated key than we can with a programmatic layout (given the constraints of a menu and that we don’t want to combine the strings).
• We aren’t trying to concatenate the names.  The names are substitutes for one another – so articles and grammatical combinations are not needed.
• There seems to be tepid support for programmatically adding both Name and GenericName to the GNOME menu items using a translated format string i18n(”%1$s – %2$s”) or similar
• Using a separator isn’t ideal but then the menus are just terrible interfaces for launching anyway
• After actually trying out the approach in the menus – it doesn’t look that bad

So, concretely, what do we need for 2.28?

1. We need to patch the panel to support showing both Name and Generic Name to workaround the fact that menus are very poor ways to discover new things.
2. We need to fix a lot of our desktop files to use Name and GenericName correctly:  GNOME Goal,  tracker bug, Fedora wiki page.
3. Consider renaming applications that have really poor names.
4. Ensure that application names perform well in GNOME Shell

I will bring this up on the GNOME desktop development list.  Discussion should happen there.

Just because a tool exists that allows you to do something does not mean it is the right thing to do.

Sometimes we realize it was not worth doing in the first place.

Tobacco Smoke Enema Kit

Sometimes we realize there are better ways to accomplish the same goal.

Olden Shower

And so it is with widget tool kits as well.

I urge you to avoid using the GtkProgressBar’s dreadful activity-mode.  You know the one – where the “progress” bar pulses from side to side and back again.

If possible, figure out a way to estimate the duration of an action so you can use the progress bar for what it is designed for.  If you can’t then maybe something like an activity spinner/throbber is more appropriate.  Code that simply calls gtk_progress_bar_pulse very likely needs to get fixed.  We should probably update our Guidelines too.

Unless you have an Anamorphic Equalizer please don’t pulse all over my screen.

(I really wanted to include a Dead Ringers reference but it didn’t quite get the same point across)

If you are lucky enough to be with us in tropical Las Palmas and attended Owen’s keynote today you saw a preview of some of the new ideas we’ve been toying with for the GNOME Shell.  One of these concepts, that we think should be pretty fun, is what we’ve been calling the Message Tray.

Jeremy helped me put together a nice animated mockup of what it may look like.  Check it out!  Or you don’t have the magic for that format, you can check out the stills.

Concept design for the shell - click for a demo

This concept builds on an idea that we discussed at the GNOME UX Hackfest last fall and is informed by a variety of prior art and the research of Eric Horvitz and others.

Basically, the HCI literature is full of studies that have found that messaging (in the broadest sense) accounts for a significant percentage of user task interruptions.  But at the same time, messaging (especially instant messaging) is one of the most important applications for personal computing devices today.  One of the most fun too.  As we connect to an increasing number of information sources and friends, managing disruptions has become a real challenge.  The primary goal of the Message Tray is to provide the user with enough information to quickly assess an event but limit the severity and duration of the preemption.  Another important goal is to allow but not compel the user to respond to the event – again quickly and with limited disruption.  Another side effect of information overload and frequent disruption is that it far too easy to forget what we are doing and what we want to do.  So, the tray also provides an important reminding function for messages that the user has deferred addressing.

More specific goals include:

• permit the user to stay focused on the primary task
• provide awareness of new notifications
• remind for unseen messages
• direct attention to high priority messages and alerts
• use an unobtrusive display
• provide a uniform interface for messages, notifications, and alerts
• allow the user to control the information display

As you can see from the mockup, the design of the Message Tray supports four modes of operation:

1. Hidden mode – tray is normally hidden off the bottom of the screen and remains hidden if the user is marked as “busy”
2. Notification mode – shows a one line summary of the notification or message along with an icon
3. Summary mode – a peripheral awareness (or low detail) mode showing an icon for each Message Source
4. Detail mode – an interactive mode showing more detail about each Message Source

One of the major advantages this system will have over any other that I’m aware of is the ability to quickly respond to messages from friends and coworkers without breaking my primary focus or switching away from my current application.  In fact, it becomes much easier to talk about your primary task.  We will be able to integrate chat deeply into the core GNOME experience.  At least for me, and pretty much everyone I know, that will be pretty damn cool.

You can read more about this and the rest of the GNOME Shell design concepts in a document I’ve put together to try to explain it to myself and others.  I should emphasize that this is a living document that we’ll try to keep up-to-date as things evolve.  Check it out and let me know what you think.

If you want to help or become involved in this evolution we’d love to talk to you anytime this week and especially at the GNOME Shell design BoF on Thursday.  Please see Marina’s blog post for some details of that.  Or drop by #gnome-shell on IRC or jump on the mailing list.

Are you a designer?  A messaging and chat expert?  A hacker extraordinaire?  We need you!

Please stay tuned for more previews and design discussions in forthcoming posts.

(with apologies to Toffler for the title – Third Wave has other connotations these days)

In the early days of personal digital computing things were pretty wild.  After all it was the 70’s and California (where much of the [computing] action was going down) was probably a pretty sweet place to be.  Unfortunately, I only know this second-hand – my parents lived near the Morningstar Commune in Sebastapol.  I digress.  So, maybe it was the drugs, maybe it was the spirit of the time.  But, nevertheless, ideas were – flowing!

Among those ideas are just about everything that we currently use to interact with our computers.  Take a look at Brad Myers’ “A Brief History of Human Computer Interaction Technology” for a retrospective.  Eventually, the drugs wore off.  The experimental 70’s came to an end.

Time to get real and sell, sell, sell – enter the corporate 80’s.  The “Office of the Future” was first sold commercially in 1981 as the Xerox Star.  It used a desktop-metaphor to help make these alien computing devices called PCs comprehensible to the humans.  Yup, just like your desk… sorta.  And then this company you’ve probably never heard of came along and made a product called the Macintosh in 1984.

Ok, so that’s pretty much the entire history of personal computing.  Well, not quite.  There was this sorta major event in 1995 that we still haven’t really recovered from.  Windows 95 / AOL / Netscape brought the internet to the world.  But somewhat surprisingly personal computers didn’t change much.

While the PC operating system world hasn’t really changed, the rest of the industry certainly has.  For example, my new phone (a Palm Pre) is a powerful computer, is a powerful Linux-based operating system – and it is beautiful, fun, functional, and damn near an entirely desktop-metaphor-free computing experience.  And I get it.

Well, what about this UNIX and Linux thing they talk about on the TV?  Yeah well, remember that wild and crazy time in the 70’s?  Some of those guys were droppin’ ‘C’-tabs and the trip lasted right up until June 2002.  At that point, Linux began to have a fairly viable desktop-metaphor-based environment.  Just like the rest of the PC gang… sorta.  Don’t get me wrong though.  The people who brought us GNOME 2.0 were heroes and visionaries.  Only it was very, very, long overdue and ushered in a new set of challenges.  Seth Nickell discusses this very eloquently in his GNOME Journal opinion piece “Experimental Culture”.  Check it out.

So, what do we do now?  Will GNOME 3.0 be the beginning of our third age, where we move beyond the desktop-metaphor?  Will a new crop of heroes emerge?  So far, things are looking good.  We’re already seeing some great contributions and exciting new ideas from people who are thinking about and working on GNOME Shell.  People who just get it and know that often a great design is anything but conservative.  Interested?  Stop by and say hey.

Join irc.gnome.org:#gnome-shell to participate in daily discussions or get help with running, developing, or designing for the GNOME Shell.

–

PS. Many new technologies go through very similar growth stages before they realize their own “language” or establish their own idioms.  Somewhat canonical and well-studied examples include film, automobiles, and television that initially used metaphors of theater, carriage, and the hearth respectively.  I’d also suggest that it is very human: childhood (play), adolescence (mimicry), adulthood (expression).  There is a fourth age as well – but once again, I digress.