Push the Button

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

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.

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

Risk

And then the day came,
when the risk
to remain tight
in a bud
was more painful
than the risk
it took
to Blossom.

– Anaïs Nin

For the last couple of weeks I’ve been working pretty much non-stop to pick up where we left off after the GNOME UX Hackfest and drive the GNOME Shell / 3.0 designs forward.

I’ve been approaching the problem in a way that, I like to think, is consistent with the very strong goal-oriented design heritage of Owen’s team at Red Hat.

No matter what design process you use (personally I like to blend Design Thinking with the OODA Loop) you really ought to carefully observe the environment and history of the problem – both the failures and partial successes, and perhaps most importantly empathize with the innocent victims of related “designs”.

I’ve posted to the wiki a selection of some of the material I’ve been reading.

If you are new to the subject, I highly recommend the first book listed, “Beyond the Desktop Metaphor: Designing Integrated Digital Work Environments.”  Which is basically a collection and summary of a number of the papers that I list below it – but it adds a lot of context that you may find helpful.

The papers are all really interesting.  I encourage you to read as many as you can.  Doing so will almost certainly help you understand some of the design decisions that will come later.  And with any luck motivate you to get involved!

I should also note that I haven’t made any attempt to categorize the papers.  I’ll leave it as an exercise for the reader to determine why.  Hint: read Lansdale.

Something I may have missed?  If you have any suggestions please leave a comment.  Thanks.

We like to talk.  Sometimes we are willing to listen.  But not always.  Sometimes we are busy, sometimes we sleep, and sometimes we are just sick of listening to you.

I’ve tried to look at some of the ways we indicate these things.  There are clearly lots of applications that allow me to set my status.

Some of the terms defined in rfc2778 may help us understand what is going on here.

Immediately we can make a distinction between the status marker (away, busy, etc) and the explanatory text (“eating lunch”).  As Facebook and Twitter have shown, status descriptions aren’t just for away messages any more.  So, let’s consider that separately.

The rest of the status markers boil down to a combination of:

1. Can receive a message (online/open/available)
2. I am not here (away)
3. I don’t want to see messages (busy)
4. I don’t want you to see me (invisible)

Some notes on the specific applications

Empathy

As far as personal status goes, “offline” is pretty worthless.  I’m not offline, am I?  I can’t imagine ever needing to tell the system I’m offline.  Sure, the application (agent) may want to tell me that I’m not receiving messages due to network connectivity but that is a bit different.  The fact that the icon metaphors for offline and hidden are the same tells us something.  Why wouldn’t I just quit?

Also, hidden means something is difficult to find or see.  Invisible would have been a much better choice here.

I’m not sure that “away” is that useful.  More on that in a bit.

Pidgin

“Do not disturb” is not my status.  It is an implementation detail.  In any case, you can be “busy” without being such a jerk about it.  Furthermore, it is really not the sender’s fault if I am disturbed – it is the fault of my software.  It should calmly queue up messages for me while I’m busy.  And if I really meant “do not” then I would go invisible.

Also has the same offline and away issues as mentioned above.

iChat

Doesn’t seem to have a “busy” state.  Kind of cool to integrate the music into the message but again that is a bit orthogonal to setting the status.

Has the same old offline and away issues.

Adium

Doesn’t seem to have a “busy” state.  Has the same old offline and away issues.

Obviously parroting iChat.

Ekiga

Nothing original here.  Some of the same issues mentioned above.  Not sure what’s up with the ellipses.

Skype

Bizarro.  It includes some kind of slut-mode (called SkypeMe!) where all your privacy settings are ignored.

Also, unfortunately, it forces people to choose between “away”, “not available”, and “do not disturb”.  And like others has the wacky “offline” status.

Windows Live Messenger

I don’t like it.

Google Mail Chat

Apart from the custom message stuff I think it gets it pretty much right.  Available, busy, invisible.  Away is only set implicitly.  I like it.

Facebook

Only offers two states: online, offline.  As with Gmail, “away” is set implicitly.  This model works really well for a purely online service.  There is no way anyone would confuse the online and offline options in facebook with those offered in the local computer’s wireless tool.  Also, since facebook is a purely social experience – I would never be busy there.  I also really like how they separate my status, notifications, and friends.  Nice.

Icon Metaphors

I found this post has a nice overview of the icon metaphors used in a selection of IM clients: http://szeto.posterous.com/im-presence

(Apart from the obvious mistake that offline is not the same as invisible…)

From http://www.szetopia.com/im-presence

The post also includes a description of how he uses each of the states and some good recommendations.

Icon Naming

The icon naming specifications provide for the following icons:

user-away: The icon used when a user on a chat network is away from their keyboard and the chat program.

user-idle: The icon used when a user on a chat network has not been an active participant in any chats on the network, for an extended period of time.

user-offline: The icon used when a user on a chat network is not available.

user-online: The icon used when a user on a chat network is available to initiate a conversation with.

Seems like we don’t yet have icons for these.  I think that Lapo Calamandrei and others have been trying to find good metaphors to use.

So What?

Ted and the Ubuntu folks came up with some good ideas.  We tried to expand upon them a bit during the GNOME User Experience Hackfest.  Some random ideas include:

• Automatically set “away” status when idle
• “Hush” and queue all notifications when busy
• Keyboard shortcut for switching to busy status
• Should have some kind of highly visible indication of status
• Shouldn’t have to set status for each application separately
• Have a good way to describe what I’m doing
• Show my status text on the screensaver lock (http://bugzilla.gnome.org/show_bug.cgi?id=384509)

What do you think?  Have some cool or crazy ideas?  Let us know!