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

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

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!

Worked on a new gnome-session.  XSMP is one step closer to the curb.  Mostly worked to make the logout handling more reasonable.  See http://live.gnome.org/SessionManagement/GnomeSession and http://www.gnome.org/~mccann/gnome-session/docs/gnome-session.html for more information.  Hope to consolidate the various session inhibit APIs for 2.26.

Used this new, rather generic, session framework to manage the GDM greeter session.  This makes it possible to trivially support sharing functionality with the normal user sessions.  Things like gnome-power-manager, orca, metacity, etc. just work.  This is important because it ensures that a user will have a consistent experience - and it makes the software easier to maintain and support.

GUADEC was great.  A beautiful city and lots of interesting people to talk to.  Enjoyed trying tripe.  Sad to have missed the Boat Party because I preparing to give my talk first thing the next morning.  Slides are available (evince seems to have trouble with them).

Finally moved (more or less) to the Boston area.

Attended the first Linux Plumbers Conference in Portland, Oregon.  Thanks to the Linux Foundation for sponsoring me.  Overall a really great conference (except for David almost falling off a cliff). It is important for us to build a solid platform.  I gave a short talk in the D-Bus/Desktop miniconf.  Slides are available.

Recently participated in the GNOME User Experience Hackfest.  I worked in the GNOME shell brainstorming group.  It was really awesome.  Everyone was positive, energetic, and focused on moving things forward.  We should really do more of these along the way to GNOME 3.0.  I feel really good about what we were able to accomplish in just a few days time.  I plan to write more about this in the next few posts.

I hope that others may find this useful.  Please let me know if you have any suggestions, comments, or corrections.

The first question we needed to answer was: how does the user enable accessibility features?  So, first, we took a look at how this works in the user’s desktop session.

If the user is persistent they may find the Assistive Technologies dialog in the GNOME Preferences menu.  It looks something like this:

Even if the user is able to read or navigate this dialog (accessibility features are off at this point) they may not really know what to do here.  Hopefully, she will know that to be able to use most accessibility tools the “Enable assistive technologies” option must be enabled, and that she must logout and log back in before it will take effect. [1]

After the next login the assistive technology framework will be enabled but she still has not started any tools to take advantage of it.  To do that she’ll need to go back to the Assistive Technologies Preferences dialog and set these up.  To configure tools like a screen-reader, magnifier, etc. she’ll need to click the Preferred Applications button.  And will get a dialog that looks like this:

Assuming that she is able to actually read and navigate this dialog, the first thing she’ll need to determine is which disability class she falls into, Visual or Mobility.  The next thing she must do is determine which tool she prefers.  On my system, the options available for Visual tool are: Orca, Orca with Magnifier, GNOME Magnifier without Screen Reader, and Custom.  And the options for Mobility are typically: GNOME OnScreen Keyboard, Dasher, and Custom.  The options have no effect unless the “Run at Start” option is enabled and even then it only takes effect on the next login.

She may also need assistance using the keyboard.  For this she’ll need to click on the “Keyboard Accessibility” button on the “Assistive Technologies Preferences” dialog.  It will bring up a dialog like this:

This dialog allows her to enable the Sticky Keys, Slow Keys, or Bounce Keys features as well as the keyboard shortcuts for them.  The following keyboard shortcuts may be used:

• Press-and-hold Shift for eight seconds to enable or disable the slow keys feature.
• Press Shift five times to enable or disable the sticky keys feature.

These keyboard shortcuts or gestures are quite useful.  They allow the user to change the behavior of the keyboard directly without the need to navigate to the preferences dialog (which may be very difficult for some people).  However, if this keyboard shortcut is used accidentally by an unwitting user the results can be extremely bad.  In fact, the user may consider the computer broken. [2]  Therefore, we make an attempt to alert the user when the behavior of the keyboard has changed dramatically.  When Slow Keys is activated using the keyboard shortcut we pop up the following dialog:

And for Sticky Keys:

Again, the intended audience for these dialogs is not the user who knowingly activates the accessibility feature but rather the user who accidentally activates it.  However, for that purpose they are entirely inadequate.  There are two basic problems with this approach.  First, due to focus-stealing-prevention the dialog will most likely be placed behind the currently used window and therefore will not be visible.  Second, once the dialog is dismissed there is not further indication that the behavior of the system is significantly changed.

That is how it works now in the user’s GNOME desktop session.

Unfortunately, this manner of operation is incompatible with the login screen.

For the login screen we must have:

• No required pre-configuration
• Accessibility enabled by default
• No ability to define “custom” tools by specifying an arbitrary command line (for security)
• Well known shortcuts that have well known actions
• Ability to enable features at a finer level of granularity than Visual/Mobility
• An obvious indication when the keyboard/input behavior has changed
• A quick way to enable and disable accessibility features

And ideally we would have some consistency in experience and controls between the login screen and the user’s session.  This is particularly important when the user doesn’t already know the state the computer is in (ie. if a user’s GNOME desktop session is currently active or the login window is active, etc.).

Since the approach used in the current GNOME session is inadequate for the login screen, for GDM 2.22 we went with an approach that is similar to one used on the Windows Vista login screen:

So far, this seems to work relatively well.  However, we still have very different configuration mechanisms at the login screen and in the user’s GNOME session.  We also received some complaints from users who had grown accustomed to the way the old GDM worked.  We should have a better story and we needed some expert advice.

So after a few conversations about these issues in the GNOME #a11y IRC channel, Will Walker offered to come down to the Red Hat office in Westford for an informal face-to-face meet-up.  Last week we took him up on the offer.  Will met with a few of us from the Desktop Team (Ray, Matthias, David, and me).  It was great to meet Will in person and I think it was very productive.

Will gave us a nice overview of the problem space, including descriptions of the various impairments that we try to address.  One of the things that really struck me was when he talked about empowering the user and how disabled users have the right to be independent and capable of using their computer without someone else helping them along or configuring it for them.  I think that is a pretty powerful idea.  And, actually, one that (at least to me) is pretty much at the core of GNOME.

During the conversation with Will I think we were able to agree on some core values for our work in this space:

1. Promote the independence of the user
2. Make it accessible to all by default
3. Provide a consistent experience and well known controls

So what does that mean?

1. We should make things “Just Work”.  We should make sure that people can do the things they need to do without someone else helping them.
2. This is about more than simply enabling accessibility features.  This means making sure that anyone can sit down at any GNOME system and operate it.  One side of this is making it easy for a disabled user to enable the accessibility tools they need.  The other side is making sure that we properly indicate when accessibility tools have modified the behavior of the system and provide easy ways to disable those same features.
3. We should probably aim to unify the interfaces provided at the login screen and in the user’s GNOME desktop session.  We should also establish a set of well known shortcuts and associated actions that may be used at any time.

One proposal for how to move toward these goals is to take advantage of the gnome-settings-daemon that is used by both the new GDM login screen and the user’s GNOME desktop session.  This daemon already handles the “AccessX” keys (Sticky, Slow, and Bounce) and displays the warning dialogs that I mentioned before.

When the keyboard shortcuts are enabled we could display a status icon in the notification area.

And, for example, when the keyboard shortcut for Slow Keys is used we could display a bubble giving the user the option to turn it off:

We could also use some of the ideas from the current accessibility applet and change the icon to indicate the current Slow Keys state.

When the user clicks on the status icon we could show a simple version of the preferences dialog that could look something like this:

□ Enable Screen Reader
□ Enable Screen Magnifier
□ Enable On-Screen Keyboard
□ Enable Predictive Input and Control

□ See more contrast in colors (High Contrast)
□ Press keyboard shortcuts one key at a time (Sticky Keys)
□ Ignore duplicate keypresses (Bounce Keys)
□ Only accept long held keypresses (Slow Keys)
□ Use a larger font size (Large Print)
□ Use visual cues for sounds (Visual Sounds)
□ Use alternate mouse gestures (Mouse Tweaks)

[ Close ]

Some things we were uncertain about were:

• What is the relationship between GOK and Dasher?
• How can we best represent the dasher option? (Predictive Input… isn’t so hot)
• Is GOK a reasonable virtual keyboard to support the tablet PC use case?
• Is there a way to combine Dasher and GOK?
• Should we show a button to launch a tool to perform more detailed configuration of these tasks?
• How should we handle some of the more exotic tools and needs?
• How can we best support tools like Orca that provide two different functions?

We agreed that once we establish the options that should be offered we would need to come up with a set of standard hot-keys for each of those options for users who cannot access the dialog directly.

Anyway, there is a lot more to think about and discuss.  An earlier version of this proposal was attached to Bug #526070.

We will be discussing this again an the GNOME Accessibility meeting in #a11y on GimpNet at 9:30AM EST (13:30 UTC) today (Monday).

What do you think?

[1] http://library.gnome.org/users/gnome-access-guide/2.22/enabling-accessibility.html.en

[2]  If you don’t buy that people think their computer is broken, check out the anger here: http://en.wikipedia.org/wiki/Talk:Sticky_keys

Tonight, though, is a departure.  There is a new brand of IPA to be had: FreeIPA 1.0.

Congratulations to our friends in the FreeIPA project on their 1.0 release!

I’m really proud that Red Hat has initiated this and is committed to making it an upstream project.  I think there is a lot of value there for us in the Free Software community.  Microsoft and Apple already integrate with similar technology but we can do better.  Check it out, hack on it, contribute.  1.0 is just the beginning.

* Technically American India Pale Ale

After a decade of working at Johns Hopkins University on the Hubble Space Telescope’s Advanced Camera for Surveys I have left that amazing team to join another…

I am happy to announce that as of mid-January I have joined Red Hat as a member of the Desktop Team. Yay!