On Friday at the GNOME London UX Hackfest, Charline from Canonical gave us some details on an icon usability study she had run recently for the Launchpad icon set. Here’s my notes from the session:

Methodology

• The study was done as a surveymonkey.com survey.
• The study was for Launchpad, so a link to the survey was posted to Launchpad’s blog to attract Launchpad users. After 3 days, the survey had gathered 125 respondents.
• The icons were presented in context, since the context would inform the user’s interpretation of the icon in real usage
• Then users were asked to help interpret what each icon meant
  • First question: “this icon means….” and asked the user to fill out, free-form
  • Second question: “i have the following percentage of confidence in my answer” so we can tell how much of a guess it was on the user’s part or how sure they were of their interpretation.
  • Third: “when do you expect to find this icon?”
• Then, users were asked to provide a second / alternate interpretation of the icon, filling out the same three fields for it: this icon means… percentage certainty/confidence…. where do you expect to find

Lessons Learned

• You can’t do more than 5 or 6 icons per survey. It’s too much work for the respondents… the rate of people who don’t complete the survey grows high if you ask too much of them.
• After only 3 days, the survey had 125 respondents – a very fast response rate! Posting to a blog that users follow was an effective way to get respondents in this case.
• We can start to understand how people read icons and see some design rules and guidelines if you analyze enough icon interpretations. For example, with the edit icon, most users realized that it meant edit, but they also gave it a strong association with attention / warning / danger. Very different meanings…. a recommendation would be to change the color or shape so it wasn’t yellow and didn’t have an ‘!’-like design in it.

One of the topics Garrett made sure to bring up at the GNOME London UX Hackfest was how us designers could continue to collaborate after the hackfest was over. This has been a recurring issue, as us designers meet every year or so, at GUADEC, at UX hackfests, or at GNOME Boston Summits (or even other FLOSS events like LinuxTag) and we get some great collaborate work done during the events – but it peters off after we get settled in back home after the events.

On Friday morning Hylke, Garrett, jimmac, and myself had a discussion with the developers in the room to explain the kinds of FLOSS tools we felt we’d need to be able to collaborate on designs more effectively when we’re remote from each other. This broke down into two main sets of needs:

Challenge A: Designer <=> Designer collaboration tools

Jimmac, Garrett, and Hylke have been using DropBox as a method of sharing design work (SVGs, PNGs for icons and UI mockups) for a whlie now. It’s been a quite effective tool for them to use, but as they pointed out, it is not open source and they would prefer to use a FLOSS tool.

Here’s a little bit on how the Dropbox workflow works:

• A designer gets an invite to Dropbox.com from another designer, granting both of them an extra 250MB on top of the standard 2GB allowance.
• The designer signs up for a Dropbox account at Dropbox.com .
• The designer installs the Dropbox client for Linux. It functions as a sort of plug-in to Nautilus – it puts a folder called ‘Dropbox’ in your home directory (you have to option to place it anywhere you like under your home) and it also has a little applet that sits in your notification area – when other folks upload files to a shared folder it lets you know there are updates.
• Say the designer is working on a totally awesome GNOME mockup in Inkscape – if they save it out to one of the folders in their Dropbox folder, anyone subscribed to that folder will instantly get a copy of it! No extra work needed on the designer’s part – no need to upload it, get a link, send out the link, wait for other designers to comment on it – it automatically gives a copy to any subscribed designers and notifies them that it’s available.
• Dropbox lets you view a log of all the changes in your shared folders and who is doing what – so it’s easy to follow along on what your fellow designers are up to, and to strike up a conversation on what another designer is working on. Without this kind of event logging system, it’s hard for designers to know what the other designers are working on which leads to less opportunity to strike up a conversation or give/receive quick design feedback.
• Dropbox also lets you manage who can read/write files in your shared folders.
• Shared folders take away from your 2GB+ limit. You can earn more space in your dropbox by sending invitations and if you join via invitation, but there is an upper bound to the amount of space you can be awarded.
• You do not have to accept invitations. You can reject them, which you might want to do to make sure you still have space left for your projects.
• Dropbox has built-in version control, and (if we understand correctly) the backed-up / previous versions do not deduct from your Dropbox account space usage.
• We’re not sure if, when you unsubscribe from a folder, if you can ever unsubscribe?
• Dropbox doesn’t resolve conflicts. Instead, it makes copies of folders. This gets a little annoying when you have a file system involved that doesn’t understand the difference between UPPERCASE and uppercase.
• Dropbox is smart in that if you delete all of the contents of a folder you are subscribed to, it does not delete the contents but instead treats your action as an unsubscribe action. So you won’t erase the whole folder for everyone else when it was clear you meant to unsubscribe.
• If you copy a file to a specific folder under your Dropbox folder, you can generate a URL to give to people who do not have Dropbox accounts so you are able to share it with them.

Dropbox Screenshots

It goes without saying – we would love such a system to be available under a free and open source license! Bastien Nocera and Rob Taylor had a discussion about how this might be achieved in FLOSS and seemed to have some feasible ideas. I’m not sure whether they settled on git or wizbit, or even something else – although those were a couple of possibilities that came up during the discussion, and the codename ‘sparkle-pony’ was mentioned…

Anyhow, such a tool would make it much easier for us designers to collaborate in terms of being aware of what the other designers are working on, easily obtaining source files for mockups, and being able to share our own work without any extra time and effort stacked on top of our usual workflow.

So that’s where our discussion went with regards to designer-designer collaboration.

Challenge B: Designer <=> Developer collaboration tools

We also talked pretty briefly on a potential web application that these mockups/files could automagically (remember, we’re talking ponies here) be posted to it with an inline comment-system for providing mockup feedback. One cool idea – if I send a link to my mockup’s page in IRC, a bot sitting in a GNOME IRC channel will see the link and associate any comments about it automatically with that mockup and post the feedback from the IRC user right into the mockup’s page in the web app!

Anyone would be able to view these mockup pages in the application, meaning it’s easy to send a link to a developer to get his feedback (which he could provide in the comments field) and and you post revisions to the mockups it would maintain the ‘family tree’ of the mockup so you can go back and refer to previous versions if needed, but it’s also clear to the developer which mockup is the latest.

I had posted a very rough idea of such a webapp to my blog a few days ago, and Robby & Josh from Isotope 11 have been working on a prototype of it.

On top of this, of course, it would be awesome if Canonical open-source the Use-case mapper John Lea presented last Tuesday so then individual mockups could be linked together in a chronological path so you can get a good feel for how the user’s path through the interface would look.

Other ideas that came up:

• Flickr-style ‘notes’ on top of mockups so people can give feedback on specific areas within the mockup image.
• Similar to the flickr-style ‘notes’, allow for areas within the flat mockup image to be drawn out so you can click them to visit the next mockup. (E.g., so I can draw a box over the ‘next’ button in the mockup and make it go to the page for the mockup of the next screen.)

Raw Notes

Here are the raw notes I took down from some brainstorming Garrett and I did on the topic throughout the hackfest. Also below find the whiteboard from the designers-ask-for-a-pony session on Friday morning:

• Communicate
  • We should share IM usernames – Jabber or AIM
  • IRC channel – #gnome-design
• Tools
  • file dumps (dropbox?)
  • synching (would be nice nautilus feature, to web space hosted anywhere)
  • version-control (could be built-in with client-side git, even if you don’t have access to sersion control server-side)
  • sharing / publishing
  • sharing work with developers
• share mockups
• talk about mockups
  • threaded discussions?
  • comments
  • mailing lists / email == fail, too difficult to keep up with
  • chat – too ephemeral
  • blogs – too much time/effort to post – don’t end up doing as often as you want. Better if stuff is built-in / automatic so it’s not extra work
• Remote whiteboarding == would be a total win. Coccinella – kind of buggy though
• Need to manage sources – eg SVGs – alongside exported mocks
• notification of what the other designers have been up to
• need a nice on-boarding process for folks less familiar with FLOSS / less-willing to deal with quirks
• shared designer complaint list / shared workarounds. If we back each others’ complaints about our tools up, we’re a louder voice and maybe can have more influence over bug fixes that would support a designer workflow (e.g. we would all support each other’s bugs against say Inkscape if we ran into them as well, and share the workarounds/solutions to get the job donein the meantime.)
• sanity-check my design tool – quick feedback tool – operate based on broadcast – eg. ‘anybody have time to give me a quick sanity check on http://url?&#8217;
  • maybe an identi.ca / twitter group would help serve this purpose?
  • website like pleasecritiqueme.com?
• UI path tracing through mockups (e.g. like Canonical use-case mapping tool)
• Maybe setup a photoblog using zenphoto and/or word press for quick critique mockup feedback?
• Sharing with other FLOSS designers – KDE designers or designers who work on particular apps…

P.S. You can now view all my GNOME UX Hackfest posts at my GNOME UX Hackfest blog category page.

Ivanka and I had a great discussion on Monday at the GNOME London UX Hackfest about how what free & open source tools / integration we need for a good FLOSS usability data capture workflow. While I still have to document them properly, you can get a sneak peek at our notes from this discussion in a whiteboard photo I took:

One of the wishlist items that came up is if there was a way we could set marker points within our large and long usability test video files, in order to be able to document and skip to points of interest within the file quickly, and also so that we would be able to export small and short clips of video to be able to share widely. You see, not only is it timely to view an entire usability test video – they are very large and unwieldy, and expensive to host which makes it tougher for us to share the great data we’re gathering. For example, the markers I’d love to set up in a usability test video file would be to indicate where test task 1 started, where test task 2 started, so on and so forth. I’ve been talking with super-hacker Bastien Nocera about how marker-setting might possibly be achieved in a totem plug-in. For him, it may kill two birds with one stone as newer video file formats have a notion of chapters within the file and totem does not currently display them.

There’s more ideas I’d like to mock up here (including a full-screen variation of the mockup) but I’m leaving for the day so I wanted to make sure I shared what I got for now. Also, the markers on the timeline are not going to be possible – although I would love a way to have the ticks highlight to show the markers selected on the right on the timeline itself – but there is no ‘active’ or ‘highlighted’ mode for the tick widget if I understand correctly. :-/

Anyway! I would love to hear your ideas.

This is how I feel like my blog has been working out lately:

I don’t think I can be as diligent in responding to comments to my blog anymore. It’s making me feel really unhappy and constantly attacked. I do not understand what outcome people who post comments like this expect.

I am really quite unaccustomed to this kind of behavior at this scale. I am really against censorship in principle, but I think I’m probably going to have to put all comments on my blog under moderations because of this. I really wish I didn’t have to though. Please be more thoughtful when you post comments to people’s blogs.

This morning Charline from Canonical presented a report on an empathy usability test she’s completed. These are rough notes split into topics:

Usability reports in general

• There was some discussion of the usage of user quotes in usability reports and their utility
• Audiences for test:
  • People who report bugs, developers
  • Some confusion over how testing on Ubuntu would have effected the test results – e.g. how did notify-osd behave to the user…
  • Usability folks
• Consider referencing products / screenshots that show a solution to the problems presented as inspiration
• When users fail to do a task, it would be useful to document the paths they tried / the mental model they had that failed. Even things they wanted to do that could never work in the current implementation – could be good ideas for a way the UI could work.
• Indicate how many users said something. If only one user suggested something, that should be clear from what all or most users said.
• We need help to get these filed as bugs. Would community members be willing to support usability by splitting reports like these into actual bug reports?

On-Board Experience

The on-board experience in empathy confusing. There’s one status for multiple accounts, but sometimes accounts don’t share the same status.

Ideas:

• present list of networks on left pane
• sniff out accounts from web browser
• allow users to authenticate using web browser when possible
• sniff out accounts from evolution

Identity information & Display of user information

Overall users were anxious because their own information was not being displayed in empathy and they felt a lack of control over it.

• People didn’t know how they appeared to other people
• “I used 2 different names and would like to know how my name is displayed. I don’t know how to check which name is in use!”
• “I can’t see me that worries me bc I don’t know how exactly how I am being seen or not seen.”
• “Available” status dropdown at drop looks like a filter and not status.
• people not sure if the camera was turned on or off – worried people can see me without my knowing
• Is this person willing to be contacted by camera? having a camera doesn’t mean you’re willing be contacted by it (e.g. if they are at work)
• Some discussion of camera icon – wasn’t a problem for users to interpret in empathy but apparently the gmail camera icon sucks and confuses people
• People didn’t have a problem mechanically changing their alias but they didn’t understand where it was put into place. What is the difference between login ID and alias? There are actually local and remote aliases in empathy… in actuality, its usage is inconsistent based on the networks involved.
• “I’m not sure what I’m doing. I cannot fill in my name as I want it to be shown.”
• “Now I have a light bulb and no green light beside my nework. I don’t know if I am available anymore. How come Jenny is available and I am not?”

Displaying information around people

They expected to find all the information concerning them in one place and the information concern others accessible through their names. They didn’t see aggregate information about people.

Interacting with Others

They didn’t understand how to chat with two people at the same time. “If you can add an individual contact, you should be able to add a group in the same way.”

The technical challenge here is every service has different concepts of group chat. Some have ad-hoc group chat, some have an inflexible concept of rooms. What if the two users you want to chat with together are on different networks. If one friend is on MSN and one is on Jabber – then it’s not possible.

To create a group, people try to invite others to a room. The Skype application uses the concept of a room really well.

Sending and receiving files

• Confusion around the icon for file sending. They didn’t associate the arrow icon with receiving a file.
• Once the file was received – they would click on the sender’s name, expecting the file to be showing there. They looked around to find it. Where did I download it to?
• GNOME’s way of handling bluetooth files is awesome and is a model maybe we should follow here?
• People would have liked to get some information about the file so they would know where to store it – is it a photo? music?
• In Google Talk, you can send someone a file if they are offline / about to go offline and they can get it when they come back online?
• Some mention of Yahoo! messaging’s shake-window feature and how irritating it is

Creating Groups – treating groups differently

User: If I have the same contact with many different accounts, I could group them under the same group? The system should indicate if I can treat all my contacts in the same way or if there are some things I can’t do depending on which account.

I tried to create a group and I can’t create it – is it because they’re from different accounts? So I can’t put them together?

I can’t see which people can be treated the same way and which can’t be.

Tab interaction

• Very positively received. They felt it was very natural.
• A known area of failure is having 20+ conversations at once.
• One tab issue that came up – where users detached the tabs and put them back together – their instinct was to drag & drop to put tabs together, but they dragged and dropped from the top and it didn’t work. People didn’t figure you have to drag from where the name is. One way Mac tried to handle this is to have a drag and droppable icon to represent the document in a document window up in the titlebar. Makes it easy to move the folder you’ve already got open rather than have to go one level up to grab the folder icon.
• Some discussion about if you’re talking with person a in one tab and person b in the other, concern about confidential info that person in tab a can see but not person in tab b, especially with copying & pasting.

Searching conversations

People weren’t sure what they’d be searching – all the conversations you had forever? Or would you be searching for a specific person? They had to try it a few times to figure out what kinds of results they would get. They liked the feature where they could see conversations on the calendar, but confused about what to expect at first.

The conversation view is a time-focused view. We wonder if they would want a more people-centric view.

Minor issues / Wishlist / bugs

• When you first open empathy, it starts the icon but it doesn’t open a window. People didn’t know if it was open or not. Grey icon not noticeable.
• Default settings were an issue – people didn’t expect that their contact list would be in alphabetical order. They expected it to be sorted by status.
• The ‘offline’ grey box icon looks like a checkbox, some users thought it was clickable
• People didn’t understand the little broom icon for clearing fields. Better to have a grey X within the entry field itself. Some people thought they had to click the broom to activate their account and lost what they had just typed.
• People couldn’t figure out how to create favorite status messages. The empty star icon was too pale and was not noticed.
• People had an interesting way to use customized messages. They thought the message was like a status update like in facebook rather than be associated with the icon. So they typed ‘please don’t disturb’ next to the green icon.
• People didn’t understand the dialing pad sidebar was for. They clicked on sidebar and saw it and were mystified.
• Sometimes button in the account dialog is ‘save’ and sometimes it’s ‘login’ – sometimes they didn’t want to log in, they just wanted to create the account.
• One icon conveys several meanings for status – invisible and offline use the same icon.
• There’s an edit custom messages – but no favorites.
• When wanting to add a contact, users didn’t understand what ‘identifier’ meant. Vocabulary was confusing.
• “It is one thing to have a camera, but another to know if [my buddy] wants to use it.”
• Button missing besides status box. There’s an invisible button beside the status area in the main window that is a shortcut to the accounts dialog.
• Notifications – users liked that it flashed to signify urgency? When you first go online there’s a notification of who in your contacts is online. One of the users was a very heavy IM user, and when he gets online he’d have 300 people there and that notification would be unmanageable for him.
• Sometimes there’s a ‘find’ button to search, sometimes you have to click ‘enter’ and there is no button to search. Between the ‘search’ and ‘conversations’ tab of the search window.
• There’s not a lot of distinction between sound and notification, so why are they in two different tabs in preferences?
• Renaming accounts – people had a tough time getting this to work. They didn’t understand what alias meant, and they wanted to rename their accounts. They didn’t think in terms of their username, but in terms of the network.
• Users would like to know when someone is offline or busy – how long ago did that status change take place? E.g. if someone got offline 2 minutes ago, might be able to still send an email or phone call – but if it was 16 hours ago, different situation.
• People thought the use of color in looking at previous conversations is not contrasting enough at a glance – the difference between green and blue is not contrasty enough.
• One person asked for some branding – if they knew the application was ‘empathy’ – it doesn’t call itself empathy anywhere. They didn’t know where they were. One user said, ‘the interaction in the application, feels more like an email than with IM. IM is friendlier, and less formal. More feedback and interaction when using the app – but this feels more like email and more formal.’ A little discussion here about extroverted apps like AOL vs more introverted apps like email.

Charline will be making the slides available shortly.

OSD & Panel Icons

Yesterday jimmac and hbons worked on Moblin icons, with the idea we could use the style for GNOME OSD (on-screen display, e.g., when you change your system volume, the big speaker icon pops up) and possibly the panel / applet icons.

Why use the moblin style? It’s much quicker to put together than the high-res icons (it can take 15 hours straight to do one of these); the Moblin style requires much simpler artwork. The style, because of its simplicity, could potentially be good high-contrast / accessible icons as well.

How do you get the Moblin icons?

git clone git://git.moblin.org/moblin-icon-theme

Challenges

We’d like complete coverage but won’t have it immediately. We should have a fallback – the Ubuntu folks suggested using a suffix for naming/calling icons from apps. E.g, if an application that wants to use this style they need to explicitly ask for it, if it doesn’t exist it falls back to the normal icon. (I’m not 100% sure how accurate my notes are here.)

One issue with the style is that it doesn’t work for every background color. There are a couple of potential solutions here:

1. Add an extra stroke of the shape in an inverse color around the outside of the icon, similar to how Tango icons have two outlines, one light one dark.
2. Pick the colors from the gtk theme.

One other challenge is they don’t work at smaller sizes right now; we potentially have to adapt them for smaller sizes. Since screens are getting more dense these days, we could consider doing 22×22 or 24×24 as the small size?

There is a single Inkscape SVG with all the icons, and a script renders the individual icons. It takes 20 minutes though; it’s inefficient.

To do

What work needs to be done to make this happen for GNOME?

• Icon recoloring – make it possible to recolor the icons to work on any background. Can we implement them so they pick the color from the GTK theme settings?
• We need additional icons for GNOME Shell that are not in the current Moblin set: battery, network, status are some examples.
• We need to see if the Moblin icon theme license will be an issue for GNOME usage. Moblin is Creative Commons Share-Alike 3.0 => is it compatible with GPL? Will this cause any issues?
• Consideration: in the indication of extremes – if volume is all the way up or all the way down – color it so it is visually different?

How to get involved

The mailing list gnome-themes-list might be the place to continue the conversation.

Nautilus discussion

John from Canonical showed us some mockups he had done to try to simplify Nautilus. We discussed them a bit. Here are some random notes from the discussion:

• remove combo box to change nautilus view, just use menu?
• frustration that nautilus is becoming like midnight commander, not beautiful to use, too complicated
• dont like split pane idea, why not use two windows? split-pane seems universally disliked by GNOME designers.
• snap to side-by-side like in windows 7 would be good and would remove need for split-pane.
• search in nautilus sucks
• confusion between magnifying glass icon for search vs zoom
• Things to consider removing from ui:
  • zoom controls
  • tabs
• Things to add to ui
  • undo
  • search folders
  • sharing / collaboration – share with
  • context-sensitive actions toolbar

Improving GNOME Designer Collaboration

Two main features that would make life easier:

• Easier syncing of files
• Version control

Garrett and jimmac use Dropbox for this today, but it is not open source and is capped at 2 GB.

Canonical Use Case Mapper

John showed us Canonical’s Use Case Mapper, which will hopefully be open-sourced at some point so GNOME designers can use it. It interfaces with Google docs at the moment.
The template it uses in Google docs is public.

Special bonus tips that happen when us designers are in the same room

Both of these gems are from Garrett:

• I kept trying to take pictures with my digital camera when my memory card was not in it. Garrett’s tip: leave your memory card door open when it’s out so when you pick up your camera you know right away the card’s not in it.
• In Gimp, filters> edge-detect > difference of gaussians, radius 1: 30, radius 2: 2 – results automagical cleanup of whiteboard photos (like the one in my post before this)

Hope these notes are useful for you.

Why does this keep happening? I think we go back home and work in individual silos again – and when we meet next it’s difficult work I think to resolve the different perspectives behind the progress we’ve made over the past year. It seems we then keep trying to redo the vision, maybe with the notion that this time will be the time we’ll figure out how we can all work together. I think though, not only are the tools for us to work together non-existent (there are some that have cropped up over time that help; e.g., Garrett and jimmac collaborate a lot using Dropbox) – but necessarily we’re working for different organizations that have different focuses and our free time is limited.

So what if we drew out a loose map of the big-picture vision, and as we necessarily work within our silos, pin that work to some piece of that vision map and fill the map in together each time we meet so we have an idea of how we’re progressing? Then it’s easier for our separate pieces coalesce in a more coherent manner when we get together and we can make forward progress together and feel like we are designing together more.

Anyway, here is a snap shot (nice and clean thanks to Garrett’s whiteboard photo Gimp tip) of our whiteboard from a rough stab at laying out some potential components for this vision:

Here are the components:

1. Application Launching
2. Notifications
3. Switching contexts (apps/windows/documents)
4. Support flow/focus
5. Provide the date/time (maybe not the hugest function, but…)
6. Sync & share / collaborate
7. Project management / to-do management
8. Store my personal database

Some other random ideas generated from this discussion:

• When I use GNOME to create as opposed to consuming, there’s an awful lot of data about me GNOME knows that it should be applying to the things I create. For example, why should I have to fill out the Dublin Core metadata entries for every single Inkscape document I create? Why aren’t I automagically added to the author field? GNOME knows who I am….
• When my file touches another person’s computer, what if a log entry was added to the file. Then it’s emailed to someone else, and when it lands on their computer another entry – so on and so forth until the file has a history so you know where it’s been…
• When someone collaborates on a file I created, their name is added to the list of authors in the metadata…
• Having your desktop be your facebook rather than facebook. E.g., if Seth is in my address book, I can see not only his contact information, but documents and other stuff he’s created that he sent me, my chat logs with him, his blog posts, other output from his online identity…. but gathered automagically, not so I have to gather all these links on my own. E.g., how the Palm Pre grabs your contacts’ facebook avatars to display when they call you – it grabs that data for you.
• Suggesting licenses to reconcile / suggest a license for a work you’ve created when it uses sources of varying licenses (or alerting you when they are incompatible)
• Version control – even on remote servers…. if you have git on your client, make your local project folder a git repo, and then you can sync it to a remote server, along with all of the git metadata so you can even have version control when the remote server you’re synching too doesn’t have version control installed / available to you
• You interact with files differently based on whether or not you created them or consume them (they’re from somewhere else)
• You interact with files differently based on whether or not you are actively working on them / with them vs. you finished with them and they’re archived. (For the former, you kind of want them in your face; the latter you don’t mind searching for them.)
• Have offline-disk access. E.g., store metadata about disks you’ve plugged into your machine in the past but don’t necessarily have connected now
• Synching files to work with other people
• Synching files so that they’re available across the devices you own (laptop, desktop, phone, etc)
• context-sensitive notifications, maybe one-shot notifications. I’m waiting for Ray to come online today, but I don’t want a notification every time he logs on or off. Just this one time. Vs. I always care about when he comes on or offline, but I don’t care to be notified about anyone else’s goings on.

For some of these, there are already pieces in GNOME that will help make them possible. However, they aren’t integrated as a coherent whole yet. This list is not to say that anything that already exists in GNOME today is meant to be thrown out or done over.

Anyway this is just a random brain dump but I wanted to make sure it was captured and shared. Sorry it’s not more polished.

Any ideas on where this should go or how this framework should be constructed?


Filed under: GNOME, GNOME UX Hackfest ]]> http://mairin.wordpress.com/2010/02/24/gnome-vision-brainstorm/feed/ 15 mairin GNOME vision? http://mairin.wordpress.com/2010/02/23/gnome-ux-hackfest-photos/ http://mairin.wordpress.com/2010/02/23/gnome-ux-hackfest-photos/#comments Tue, 23 Feb 2010 13:55:12 +0000 mairin http://mairin.wordpress.com/?p=1633 ]]>







I’m posting my photos of the GNOME UX Hackfest on Flickr so check them out. I’m putting the tag ‘gnome-ux-hackfest’ on them.


Filed under: GNOME, GNOME UX Hackfest ]]> http://mairin.wordpress.com/2010/02/23/gnome-ux-hackfest-photos/feed/ 27 mairin GNOME UX Hackfest GNOME UX Hackfest Willie's accessibility talk GNOME 2010 UX Hackfest London UK http://mairin.wordpress.com/2010/02/23/painless-accessibility-tips-for-gnome-designers-and-developers/ http://mairin.wordpress.com/2010/02/23/painless-accessibility-tips-for-gnome-designers-and-developers/#comments Tue, 23 Feb 2010 12:36:37 +0000 mairin http://mairin.wordpress.com/?p=1629 Continue reading »]]>

This morning at the GNOME 3 UX Hackfest in London, Willie Walker gave us some tips for ‘painless’ accessibility.

First he reviewed the three main types of access users need us to support:

1: Some people can’t use the keyboard

These users use devices such as:

• head tracking
• eye tracking
• switch-based access (they press buttons on a switch – the accessibility layer translates these to keyboard stroke)

For head-tracking and eye-tracking, they hover over an area to cause a click. Some of these users can’t use keyboard or mouse at all. They may use a button/switch to interact and translate to keyboard.

You need to think about users who cannot use the keyboard at all.

2: Some people can’t use the mouse

These users use devices such as:

• switch-based access (they press buttons on a switch
• use joystick instead of mouse

A big category of users who cannot use the mouse are users who are completely blind. Since they cannot tell where on the screen the mouse is, they can’t use it. These users rely on keyboard access

To make sure you’re accounting for these users, try unplugging your mouse and see if you can use your interface:

• Can you get to all the functionality?
• Can you get to all the functionality efficiently How many keystrokes will it take??

3: Some people who can’t see the screen.

Users in this category:

• May be visually impaired with respect to their perception of colors. For some, particular color contrasts may be quite painful.
• May be visually impaired with respect to their ability to read text on the screeen.
• May be completely blind.



Design Implications

GNOME handles the presentation of content for users who are visually-impaired:

• Font-sizes and icon-sizes are adjustable.
• High-contrast themes are available.
• Screen magnification is possible. (no special design considerations needed here.)
• Reducing the screen output to text-only: screen readers that output both via audio and via Braille displays.

Here’s some tips for GNOME designers and developers to help ensure your design is more accessible:

• Make sure there isn’t any functionality available via the keyboard only.
• Be wary that your color choices might not be good for everyone and there should be a good way to override them. Whenever possible, pull your colors from the GNOME theme. Your colors should not be hard-coded, and must be override-able.
  Yes, your interface may not appear in colors that are in your brand book or evoke the emotion you wish to convey in your interface – but consider that the ability for someone to be able to use your software or not be able to use it at all also affects your brand as well.
• Be redundant in how you broadcast your design – for example, please do not rely on color as the sole or primary way to help users differentiate between two elements/modes/etc. of an interface. Have other elements of the design (position, labels, etc.) indicate this as well.
• Please be wary of custom toolkits/ widgets – they do not typically support accessibility. If you must use them, ask your developer to build accessibility into any custom widgets they may be writing for you.
• If areas of the interface do not have text (for example, a search area that is not labeled ‘search’), make sure you’re using the accessibility labels and descriptions. In glade, you can set these via the accessibility tab (it has a blue wheelchair icon.) Translators will be able to access these and translate them as well! They won’t appear in the interface but will be made available to the screen reader.
• When coming up with textual equivalents to interface elements:
  • Imagine someone speaking them aloud to you. You don’t want War and Peace every time you happen to highlight a UI element. Make them clear and succinct.
  • Think about differentiation. You don’t want to repeat the same string for every single item in a menu, for example – you want the differentiating text to come first. (Willie gave the example of a menu where the user hears ‘menu item new’, ‘menu item save’, ‘menu item open’, etc. etc. while navigating through. The info that helps the user differentiate between each item comes last – that makes it more difficult to use.)
  • Try to reduce chattiness. People get annoyed with chatty screen-readers. (To this end, orca even has a ‘shut up’ key.)
  • “Type into this field to perform a search” == BAD label. “Search’ == good label.
• Anything you can do to reduce keystrokes is really good for users who cannot use the mouse.
• This is common-sense anyway, but when designing keyboard shortcuts for your interface, make sure the ‘chording’ of the keystrokes is reasonable to access. E.g., don’t require users to play a fun game of twister and have to hit 6 keys at the same time!
• Mnemonics in GTK+ not only give users a visible keyboard shortcut to access a particular element of a UI, they automagically bind labels and form fields together, creating an association that also helps users associate the two elements together. Consider than while visually positioning elements together creates a relationship between them implicitly, there are users who do not have visual access and tools like mnemonics which explicitly associate the two UI elements are vital for those users who cannot visually discern the relationship.
• Use GTK frame widgets to group related areas of the interface together under a common label. This enables users to navigate between entire sections of UI rather than just field-by-field. Also, make sure you implement this using the GTK frame widget rather than just a label with indented widgets underneath it – the GTK frame widget actually creates an association between the frame label and the widgets below it that is not there if you implement it in looks but not in ‘spirit.’
• Wizard design: don’t keep focus on the next button! This might be the default behavior if you use glade, but it wastes the user’s time because they need to navigate above the next button – why not save them the keystroke? Also, this ensures that when a user lands on the next screen, that it starts off by reading the first item on the screen rather than ‘next’ (image going through a wizard, clicking ‘next’ to go to the next screen, and the computer tells you, ‘next’ on the following screen – how disorienting!

Calum asked Willie a really good question – how do assistive technologies handle dynamic UI elements? As Willie explained, we handle it okay but we could do better. Some common dynamic UI elements are progress bars, or monitoring graphs (eg the CPU usage monitor), or checkboxes that disable based on selections elsewhere on the screen. For the latter case – dynamically-disabled elements – when they are disabled, they are not accessible until the selections on the screen enable it again, so this case is handled okay. For progress bars and graphics, one thing we can do is announce every time it changes, or we can put some time constraints in there for announcement – announce every 3-5 seconds, for example. For progress bars in particular, we have a progress bar setting for orca: announce updates (yes or no.) This enables orca to announce every so many seconds the current status of the progress bar. For example, for a download progress bar: “10 percent. 25 percent. 73 percent.” We could handle these better, though.

So how accessible is your UI?

Willie put together a great Accessibility Smoke Testing Plan that you can run through to see how your UI stacks up for accessibility. The five steps summarized (please read Willie’s plan for the full version of these!):

1. Unplug your mouse. Is your UI usable?
2. Select the GNOME ‘High Contrast Theme’ and examine your UI for color and font changes.
3. Check your app out in Accerciser.
4. Check out your custom widgets in Accerciser.
5. Try your UI in Orca.

A little bit about how GNOME Assistive Technologies Work

• AT-SPI provides the ability for an external app (e.g. Orca and other assistive technologies) to look at the widget hierarchy and register for changes in that hierarcy. ‘let me know if something changes focus here.’
• GTK+ has something called gail (GNOME Accessibility Implementation Layer) – it turns GTK widgets into AT-SPI. Gail has an implementation for every widget in GTK. When you create a brand-new, custom widget you need to create a similar gail implementation for it to be accessible. You can test it via Accerciser.

How to learn more

• The GNOME Accessibility Developers’ Guide is a handy reference for developers to learn more about how to make their applications more accessible.
• Look at similar widgets or applications in GNOME to see how they implement accessibility.
• Mail the GNOME accessibility team at gnome-accessiblity-list@gnome.org – they would love to help you.

Filed under: GNOME, GNOME UX Hackfest ]]> http://mairin.wordpress.com/2010/02/23/painless-accessibility-tips-for-gnome-designers-and-developers/feed/ 23 mairin Willie's accessibility talk Willie & mpt try the ubuntu software installer using orca http://mairin.wordpress.com/2010/02/10/gnome-shell-usability-test-plan/ http://mairin.wordpress.com/2010/02/10/gnome-shell-usability-test-plan/#comments Thu, 11 Feb 2010 02:26:14 +0000 mairin http://mairin.wordpress.com/?p=1557 Continue reading »]]>

The need to test GNOME Shell

For the past couple of weeks I’ve been working with Jon McCann, Jeremy Perry, and Owen Taylor on developing a usability testing plan for GNOME Shell. It’s a work-in-progress, and I wanted to make a quick posting about the effort and where it’s going.

Now as you may have learned from earlier posts on various blog planets, or in Marina Zhurakhinskaya’s GNOME Journal article last November, GNOME Shell defines the user experience for GNOME 3, to address the more fully-networked computing environment of today as well as to reach a wider audience. A great change has occurred in the way technology affects people’s lives since the original GNOME 2 was designed, including the introduction of new and disruptive technologies such as micro-blogging, large-scale social networking, and the increasingly predominant availability and usage of web-based mobile phones. With so many streams of content and information we need to manage, and it’s hard to keep focused and on task on the desktop. GNOME Shell is designed to account for these changes, to make desktop computing delightful and comfortable in spite of the amount of information we need to process in the course of our work on the computer.

The GNOME Shell design is based upon a few assumptions about users’ desktop actions. While many of these assumptions are informed by seasoned, long-time GNOME hackers and designers working on it such as Owen and Jon, it’s important to define those assumptions and test them to make sure that they are valid. We wouldn’t want GNOME 3 and GNOME Shell to be built upon a shaky foundation. GNOME Shell is finally at the point where it’s stable and we’ve got enough functionality in place to run some tests on it.

Figuring out a usability testing methodology

‘So, Mo,’ you might say, ‘why don’t you do some usability tests of GNOME Shell with your swanky usability lab kit, like you did for Fedora Community?’ Well, Fedora Community is an application that, at this point in time, focuses quite heavily on supporting a particular domain: make Fedora package maintainership easier. To test how successfully Fedora Community does this, sure, you do usability testing to see how it goes when folks using the application try to complete tasks related to package maintainership. GNOME Shell, however, isn’t an application. It’s an environment in which a wide spectrum of users are meant to complete tasks within any number of different domains – within a variety of different applications. If I can’t successfully write a book report on To Kill A Mockingbird while using GNOME Shell, for example, how much of that is related to GNOME Shell, how much is related to my word processor, how much of that is related to my internet browser? Or, to analogize, if I built a highway, how helpful would it be to make sure I can make a trip to Grandma’s house, the supermarket, and to the local national park using it?

What are the considerations you should make when building a highway?

• What speeds is the highway meant to support? Make sure turns and ramps are banked appropriately to support these speeds, make sure the angles in the turns are safe to make at those speeds, and that the materials used to build the road can withstand that level of usage.
• Under what weather conditions might the highway be under? (If it’s in New England, think snow and ice! In Oahu, not so much.) Can the chosen material withstand the weather conditions?
• How is the terrain along the planned route? Can the path of the highway be routed such that it avoids dangerous or difficult-to-navigate paths such as along a cliff face?

Can testing the trip to Grandma’s house on the highway expose issues in the design decisions made in building the highway? Maybe if it happens to snow during the trip, you might uncover some issues, but it would really be based on chance. Would you feel safe on a highway tested based on the success of arbitrary trips along it, or would you rather it be tested in a fashion targeted to expose any issues that might be present in the design decisions made in its construction?

Usability testing GNOME Shell to see how well folks can download and listen to music and send emails to their Grandpa I think is like testing a highway’s safety based a trip to Grandma’s house: you might get lucky and incidentally happen to uncover a flaw in the design, but more likely you’re going to cover issues that aren’t directly related to the design (the car I’m driving isn’t comfortable to ride in!) My colleague Ben, who is a seasoned usability professional with over 15 years’ experience, suggested a methodology where we make a catalogue of various design assumptions followed in GNOME Shell’s design thus far and treat them as research hypotheses we could construct targeted tests for. For example, if we assume users find it easier to search for documents than browse for them for a file tree, we could construct the following test:

• Assign a user the following task: “You’re trying to create a print-out calendar for next month to plan your schedule. Download the OpenOffice template for a calendar available at some URL. Now, open up the calendar file.”
• Observe whether or not the user browses the file hierarchy to open the document up after saving it. How long does it take them to find it when asked to find it? How many clicks? Do they seem annoyed?
• If the user browsed for the file, ask them to search for it. If they searched for it, ask them to browse for it. Again, note how long it took them to find the file – how many clicks – and their general mood.
• Present the user with a quick, 3-4 Likert scale-based questionnaire to assess which method they preferred and how they felt about each method.

This way, the tester does not need to rely on chance that the user is going to open a file on the file system and can be prepared for when they do so to observe in a manner focused on a particular design hypotheses. In this example, the tester can be focused on whether or not the user finds searching or browsing more comfortable, so they can filter out other design issues that might just happen to crop out in the process in order to focus on running the test.

This, of course, is not to say more scenario-based and task-oriented usability studies are not useful. I just want a test method that will target specific design assumptions so I can run a series of tests on that assumption to help decision-making, rather than test various tasks and hope some issues related to the particular design assumptions I’m interested at the time to come up. It will be important to do scenario-based and task-oriented usability studies to complement this work however, especially to identify potentially problematic design assumptions we didn’t think to test.

Ideally, we’d do a longitudinal study so we could better get at how users interact with GNOME Shell over time and after they’ve become familiar with it. These types of studies necessarily take a long time, however, and a lot of investment, so we want to make sure GNOME Shell is ready before we get into that. I think we probably need more confidence in the hypotheses we’ve set out to test first, so we know we won’t be wasting our test subjects’ and our own time with a longitudinal study at this point.

The current test plan status – and how you can help



Right now, with the help of other folks, I’ve written up 36 design assumptions / hypotheses to test. The next steps are to figure out some test plans for them. Since testing 36 hypotheses is no small feat, I think first I’ll pick the top ten in priority and develop hypotheses for them first. I’ll be working on that next.

The first cut of the test plan is on the live.gnome.org wiki with those 36 hypotheses. I would love to hear what you think about them and if you have ideas for other GNOME Shell design assumptions you’d like to see tested. I would also love to hear your ideas on how we might devise some tests for each hypotheses. I’ve set up a page for commentary on the wiki so please feel free to add your comments and suggestions! (Although of course you can feel free to leave your feedback in the comments area of this blog post instead.)


Filed under: Gnome Shell Tagged: desktop, GNOME, Gnome Shell ]]> http://mairin.wordpress.com/2010/02/10/gnome-shell-usability-test-plan/feed/ 112 mairin