Friday, December 26, 2014

Usability project - week 3 (scenarios)

I encourage everyone to follow our progress in the GNOME Usability Project. I'm planning to post each "assignment" on my blog every week. I figure this will help others who might want to apply to the Outreach Program for Women in future years, so they can "follow along" with what we are doing. Or, if you have more experience in usability testing, feel free to leave a comment on our work.

In planning your usability test, after you understand and agree to the personas that represent your users, your next step is to document the scenarios under which these personas will use the program. This is key to performing a good usability test. The success of your usability test depends on how well you understand how the program will be used (and in turn, how well you understand this depends on the completeness of your personas).

This week, let's examine scenarios. Use these questions to guide you:
  • What is a scenario?
  • Can you identify scenarios for GNOME, for each of the personas you imagined last week? Do they overlap? In what ways are they similar or different?
  • What is the difference between a scenario and a scenario task?

These websites may provide more information as you consider this week's topic:

Scenarios inform the next part of our usability project: scenario tasks. Once you define the scenarios for your users, you can generate the scenario tasks. Consider these questions:
  • How do your scenarios break down into separate tasks?
  • What parts of GNOME will be exercised by your scenario tasks?

Of course, you may not be able to test all of your scenario tasks in a single usability test. Your testers may become weary of a usability test longer than about an hour. So as your final step for this week, consider what scenario tasks will help you most in your usability test. What features do you want to examine in GNOME? Reflect on how your scenario tasks expose features of GNOME, and compare that to the features you want to examine.
image: Outreach Program for Women

Wednesday, December 17, 2014

Usability project - week 2 (personas)

I encourage everyone to follow our progress in the GNOME Usability Project. I'm planning to post each "assignment" on my blog every week. I figure this will help others who might want to apply to the Outreach Program for Women in future years, so they can "follow along" with what we are doing. Or, if you have more experience in usability testing, feel free to leave a comment on our work.

In studying usability, we first need to understand who are the users. How you design the program may differ based on who uses it. Are your users mostly developers? Or are they mostly image experts? Or are they "general" users with "average" knowledge?

Good designers start with personas to define their users. By using personas that everyone agrees to, the designers and developers (and everyone else on the project) can discuss how changes to the product will affect each representative user. This avoids ambiguous discussion like "But what about the user who wants to do —?" or "But this works for me." With personas, the conversation becomes "How does this change benefit ‘Amanda’?" or "What can we do to make things easier for ‘Steve’?"

This week, let's research and discuss personas. Consider these aspects:
What is a persona?
Can you find (Google?) more information about personas and how they help in usability testing? At what point in a project would you create personas?

Can you identify personas for usability testing in GNOME?
What users does GNOME aim for? This is a different audience than the users for GNU Emacs, for example. What persona types would you propose for GNOME? Pick one, and create (write) a persona for that example.

I considered personas for my usability study, but decided not to include them in my capstone project. Why didn't I use personas? Can you find a reference or note in my capstone? (Hint: it's in an appendix.)
I think you'll find these topics are inter-related.

Some websites that might help you in discussing personas:
image: Outreach Program for Women

Wednesday, December 10, 2014

Usability project - week 1

I am proud to be part of the Outreach Program for Women ("OPW"). In this cycle of the program, I will be mentoring the GNOME Usability Project. I'll be working with Sanskriti Dawle, who will be sharing her experience via her blog.

I encourage everyone to follow our progress. I'm planning to post each "assignment" on my blog every week. I figure this will help others who might want to apply to OPW in future years, so they can "follow along" with what we are doing. Or, if you have more experience in usability testing, feel free to leave a comment on our work.

As we get started with week 1, discuss your initial thoughts on usability. Some questions that should help guide you:
  • What does "usability" mean to you?
  • Can you find (Google?) a definition of "usability"?
  • Some researchers in this area make a distinction between "big U" Usability and "small u" usability - why is that, and how are they different?
  • What are we trying to get out of "usability"?

These are great questions to start off our usability project. I find it's a good idea to create this "baseline" for first impressions about the topic, and you can expand on that as you go.

A few references that you might consider in discussing this topic:

You might also review "What is usability?" from my capstone "Usability Themes in Open Source Software" (Hall, 2014).

You are welcome to follow our usability project!
image: Outreach Program for Women

Saturday, December 6, 2014

Usability A/B testing

If you work in usability, you should be aware of A/B testing: presenting two versions of a product to a test participant, and asking which they prefer.

A/B testing is a popular and easy way to improve a system through iterative testing. By its nature, A/B testing requires some iteration to get it right: Think about when you visit the eye doctor, and you look through the sets of lenses: "Which looks better, number 1 or number 2? Now, number 2 or number 3?" And so on.

This style of testing can be extended to websites and web applications, by releasing one version of a site to a subset of visitors, and another version of the same site to a different subset of visitors. For example, a website might expose certain users to a different navigation sidebar, and compare how well those users can navigate the website versus those users who see the old navigation sidebar. With enough web users, the web designers can quickly determine (through traffic analysis) which navigation sidebar is more effective.

A recent article in Fast Company demonstrates another company using A/B testing, in an interesting way: the Adore Me lingerie company. From the article:
For each bra, Adore Me shoots multiple versions of images to run on its website. The distinctions between the pictures might include different models wearing the same set in the exact same position, or the same model in the same set in a different position, for example. Then, like any good tech company, it tests the options to find out which one sells better.

Through its research, Adore Me has found that the right model matters even more than price. If customers see a lacy pushup on a model they like, they'll buy it. Put the same thing on a model they don't, and even a $10 price cut won't compel them. Pose matters as well: the same product shot on the same model in a different posture can nudge sales a few percentage points in either direction. Another test found that a popular model can sell a more expensive version of the same garment.

The tinkering—which seems incremental—adds up, and has helped the company maximize sales. In four years, Adore Me has matched the sales of competitors like La Perla, bringing in $5.6 million in revenue, according to Inc.

Aside from model, A/B testing also revealed the model's pose can influence sales, too: "Hand on hip, a popular pose among Instagrammers trying to make their arms look skinny, doesn't resonate nearly as well as a hand on the head, for example. (That slight change can double sales, according to internal research.)"

This style of usability testing requires coordination between several groups: most importantly, the website must be geared to support traffic analysis in a way to help determine the best sellers: "For every thousand people that come on the site, 500 will see picture A, another 500 will see picture B and over time, one will sell better than the other."

As you plan your next usability tests, consider how A/B testing might be applied to examine how users interact with your system. If you crunch the numbers, you can discover interesting and useful results that will improve the next iteration of your product.
image: Adore Me

Wednesday, December 3, 2014

Usability in business

While my blog focuses on usability in open source software, it's important to note that usability is important everywhere. Cloud systems such as Gmail, Evernote, and Dropbox could not exist without good usability. In these systems, it's unrealistic to expect users to be trained before they can use the software. These applications need to be easy to use "out of the box," without any training. At most, the software needs to be "learn as you go," in a way that allows users to uncover and discover functionality in a natural way. People just want to use the software to get their work done, quickly and easily.

In business, most corporate applications have not been managed that way. In corporate culture, the desktop is highly controlled, including which applications you can use to do your job. And the software isn't always friendly. Before you can use the financial system to run reports, most users would expect to attend a training seminar. It's just that hard to use.

But that is all changing. I was glad to see this article in CIO Magazine from design consultant Harold Hambrose, about a new dawn for system design. In brief, Hambrose asks. "Are you building business apps that employees love to use and can pick up without training? If not, you need a different kind of design team."

Hambrose highlights one important difference between corporate software and consumer applications: "Technology outside the enterprise is strikingly different because people want to use it." (emphasis mine)

To answer this challenge, Hambrose introduces the design researcher. From the article:
Their perspective is different from a business analyst who will ask, “How do you do your job? What data do you need?” Instead, they may inquire, “Why do you do your job this way? Tell me about the decisions that you make. Why are these important? What is success for you? For your organization?”

If you are interested in usability, you can leverage your experience towards the new design researcher role. Forward-thinking CIOs will be looking to make their enterprise software easier to use—and something their employees want to use.

Friday, November 28, 2014

What you think about desktop colors

Ten days ago, I asked you to tell me about your impressions of different colors. By responding to a quick survey, you described colors using words other than colors. For example: descriptions such as sad, happy, sea, forest, or sky. 58 of you responded to that survey. I wasn't looking for an academic exercise, so I didn't need a large N. I'm very happy to have almost 60 people respond to the survey. Thanks!

The survey included fifteen colors. I chose these colors to approximate the colors used from MacOS X Yosemite, Windows 8, and GNOME 3.14, although I intentionally added some randomness and similar colors to provide a blind.

My goal was to see what emotions or thoughts came to mind based on the colors used in each operating system. What did these colors mean to you?

First, let me briefly explain the analytical process. My survey asked you to "Please use a single word to describe each color." Not everyone followed that instruction; some of you entered phrases or lists of individual words for each color. Thanks, but that does make the analysis more difficult. Fortunately, in these cases, the first word in the phrase or list was representative of the response. So in analyzing the data, I only used the first word provided.

Then, I only had to group colors together to each operating system—including desktop, icon, and window colors. Based on the colors in the survey, I only needed to match five colors to each operating system. Color names (in quotes) are borrowed from the X Consortium color names, most of which are also W3C web color names:

MacOS X Yosemite (from Wikipedia)
MacOS X Yosemite
color:"Dodger Blue"
color:"Orange"
color:"Light Pink #1"
color:"Silver"
color:"White"
Windows 8 (from Wikipedia)
Windows 8
color:"Dodger Blue"
color:"Royal Blue #4"
color:"Dark Green"
color:"Dark Red"
color:"Sky Blue #1"
GNOME 3.14 (from gnome.org)
GNOME 3.14
color:"Black"
color:"Dodger Blue"
color:"Sky Blue #1"
color:"Silver"
color:"White"

From these colors, what associations do you make with each operating system. I find it helpful to demonstrate through word clouds. I used the word cloud generator from ABCya.com to create these images:

MacOS X Yosemite
MacOS X Yosemite: top 5 associations:
8 blank
7 cool
6 snow
6 sky
6 girl
Windows 8
Windows 8: top 5 associations:
22 sky
13 forest
8 cool
7 brick
6 calm
GNOME 3.14
GNOME 3.14: top 5 associations:
22 sky
16 dark
9 night
9 blank
8 cool

This provides an interesting comparison:

  • Mac OS X colors provide affiliations with open, soft, and calm adjectives.
  • Windows 8 colors compare to dark but calm descriptors.
  • GNOME 3.14 colors correlate to open, calm, and moody attributes.

As I mentioned in my previous post, colors have an important role in good design. Designers must remain sensitive to how different people perceive colors, while honoring typical color conventions. In user interface design, colors also affect the mood of an application. As seen in this comparison, users perceived the darker colors used in Windows and GNOME as moody, while the lighter colors used in MacOS X suggest an airy, friendly interface.

This is not to say that colors dictate or predict the usability or user friendliness of a user interface. However, we do know that colors do play a role in how users perceive the usability of a system. As uncovered in a 2003 study, users perceive aesthetically pleasing interfaces to be easier to use. In the study, the same website rendered with an atypical contrasting color scheme fared poorer usability than the same website with a pleasing, harmonizing color scheme.

This may be why users at large perceive the GNOME desktop to have poor usability, despite usability testing that demonstrates GNOME actually has pretty good usability. The dark, moody colors used in GNOME provoke feelings of tension and insecurity. Bang(1991) included color in her analysis of how people perceive images, mentioning that white or light colors feel "safer" than darker colors, because we can see well in the day but not at night. This is especially true of background colors. Of all the "dark" colors, the top associations were forest, brick, deep, and night. Also, the top associations with "black" were dark, night, darkness, and deep.

Open source software projects can learn from these color associations. GNOME currently uses a dark color scheme. These colors correlate to open, calm, and moody attributes. Meanwhile, the lighter colors used throughout MacOS X provide affiliations with open, soft, and calm adjectives. It is not surprising that users typically view MacOS X as having stronger usability. Certainly, Apple has put a lot of effort into usability testing in MacOS X, but I believe their choice of light colors was a conscious one. Even people who do not use MacOS X as their primary desktop describe MacOS X as easy to use.

I recommend that GNOME adopt lighter colors in future releases. Avoid dark colors, especially in backgrounds or the desktop wallpaper. Embrace light, airy colors in the interface instead of somber, melancholy color tones.

Examine the GNOME 3.14 screenshots at gnome.org. I am using the new GNOME 3.14 release, from Fedora 21 beta. I like the light background image; this is a blue that suggests sky, summer, and clear (from the color survey results). The light grey application backgrounds are also good, but the dark grey application backgrounds are not. GNOME should eliminate the black background in the top bar, in favor of a black-on-white theme. Similarly, change the black background in the Favorites launcher (at left) to a lighter grey or white background.

By adjusting the color theme, GNOME can influence how users perceive the usability of GNOME. Without major changes to the interface or design, GNOME would sharply improve its reception, and attract new users while encompassing the needs of current users.

Tuesday, November 18, 2014

Color and usability?

We all know that colors have an important role in good design. Designers must remain sensitive to how different people perceive colors, while honoring typical color conventions: green means Go, red means Stop, etc. Additionally, users will associate user interface controls that use the same or similar colors to mean the same thing.

In user interface design, particularly with open source software and usability, colors also affect the mood of an application. Darker colors may be perceived to be moody, while lighter colors may suggest an airy, friendly interface. It's no surprise that both iOS and Android have shifted to using bright colors in their icons and interfaces.

Colors must certainly harmonize for this to work, however. As uncovered in a 2003 study, users perceive aesthetically pleasing interfaces to be easier to use. In the study, the same website rendered with a different, contrasting color scheme fared poorer usability than the same website with a pleasing color scheme. Similarly, users learn best when applications use color in a standard way, such as links in a web page.

Recently, I began to consider the perceived (not actual) usability of open source software programs based simply on their choice of color. In particular, GNOME uses a high-contrast white-on-black top bar. The new GNOME 3.14 uses dark windows for some applications (such as Photos and Weather) which is different from the light colors in most other GNOME programs (such as Nautilus file manager). Could these colors affect how GNOME is perceived by new users?

To start, let's look at a few examples:

MacOS X Yosemite (from Wikipedia)
Windows 8 (from Wikipedia)
GNOME 3.14 (from gnome.org)

Note that MacOS X uses a lighter color theme, including a "greyed out" top menu bar and Dock. Windows 8 uses a dark blue background and darker primary colors for application tiles. GNOME 3.14 uses a muted color scheme which becomes especially pronounced when Activities View is active, as shown above.

What do these colors mean to you? Do you perceive colors to affect usability?

Help me to talk about how colors affect usability. I have set up a simple online survey that takes only a few minutes. In the survey, you will view 15 color samples. Describe each color using words other than colors. For example, you might describe the color using emotions (sad, happy) or environmental (sea, forest, sky) or other adjectives (confused, fuzzy).

This is not an academic exercise, although I believe it will be useful in discussing how color choice affects open source software and usability. I'll post a brief analysis in a few weeks.

UPDATE: Here are the results: What you think about desktop colors

Friday, November 14, 2014

Follow Friday

I contribute to lots of free software projects, although not as much as I used to. These days, I am an advocate for usability in free software, and I am probably best known for FreeDOS, a free version of DOS. I created FreeDOS in 1994 while I was an undergraduate physics student.

I am also working with GNOME to improve usability for everyday people. My M.S. capstone was the Usability of Open Source Software, in which I analyzed and discussed the usability of GNOME.

In that spirit of GNOME, and under the theme of "Follow Friday," I would like to point you to these blogs and resources about GNOME design:


The GNOME UX Design Team is a group of individuals work on the design of the GNOME user experience and developer experiences. The primary areas of work are core OS design, core application design, and the visual theme and icons.

GNOME Design is a small, friendly group, and we have strong links with designers across Free Software. We are always looking for new contributors, and everyone is welcome to contribute!

Tuesday, November 11, 2014

Groupon and GNOME

Update: “Groupon has agreed to change its Gnome product name to resolve the GNOME Foundation’s concerns. Groupon is now abandoning all of its 28 pending trademark applications. The parties are working together on a mutually acceptable solution, a process that has already begun.” ~gnome.org
While I reserve my blog for discussing usability in open source software, a recent issue has recently emerged that deserves a mention:

Groupon has launched a new platform, called Gnome. It's a proprietary tablet system with software which they describe this way:
"When it's complete, Gnome will serve as an operating system for merchants to run their entire operation and enable them to create real-time promotions that bring customers into their business when they need them the most." ~Eric Lefkofsky, CEO
This is disturbing because there is already a system out there called GNOME, a free-software desktop that acts as a platform for many popular free programs.

I don't know of any way to describe this other than Groupon is trying to steal the name from the GNOME Desktop. That's not right.

In the U.S. legal system, trademark owners need to fight to keep their marks when others use them inappropriately. And GNOME is planning to fight this, and they have started a fundraiser on PayPal to help pay for legal costs. Please help.

Friday, November 7, 2014

The importance of good design

I uncovered an interesting article from CIO Magazine, from back in June this year. Harold Hambrose writes in "A New Dawn for System Design" about an important fact about appealing to end users:
"Technology outside the enterprise is strikingly different because people want to use it. They aren’t trained to use it. No one spends a dime on change management. People take one look at the stuff, understand how it is relevant to their world, buy it and never look back (at least until something better comes along). The contrast between these tools and the typical enterprise system couldn’t be starker."
Hambrose makes the point that to design good software for the enterprise, we need to shift "enterprise" development to think more like "commodity" development. He says designs must be "human-centered (not process-centered)." And in doing so, Hambrose is essentially extolling the importance of good usability, and strong user experience.
Agile or rapid methods might be great for fast, iterative software development, but invite a designer into the exercise and you’ll learn how the design process allows for much more effective exploration and discovery. This isn’t the “design thinking” fad. This is “design doing” — technologists, business analysts, designers, researchers, executives and rank-and-file staffers defining possibilities together. They’re focused equally on the people that we need to perform, the technology we can deliver, and the business that must be served.
Right there, Hambrose discusses a user-focused approaching, designing the system for what users need to do, rather than what you want them to do, or how you want them to do it. By extension, Hambrose advocates designing every in-house corporate IT system as though it were a commodity: do people want to use your product? Can they use your product to do the things that they need to do?

Without using the word, Hambrose argues that all enterprise IT should have good usability, that they must focus on the user needs first. Whether you are a designer in industry or for an open source software project, the essential needs are the same: real people need to use your software to accomplish real tasks.

Friday, October 31, 2014

World Usability Day

I wanted to share this update from the Usability team where I work, at the University of Minnesota. World Usability Day is November 13, 2014. As in past years, the University of Minnesota is sponsoring an event to celebrate. This year the programming is centered around the theme of “Engagement” and will include panels such as:
  • “Engagement: What Does it Mean to Engage? What are we Working on?”
  • “Let’s Face It, We’re Not 16 Anymore: How Teenagers Read (and Misread) Higher Ed Home Pages” - Red Stapler winner for Best in Track at HighEdWeb 2014
  • “Lessons Learned about Engagement: Failures and Successes”
  • “Methods, Techniques, and Tools to Measure Engagement”

Sponsors
World Usability Day is sponsored by University of Minnesota’s IT@UMN User Experience Team, Libraries, and CLA Department of Writing Studies have partnered with The Nerdery, Macalester College, Metropolitan State University, and Thomson Reuters.
image: worldusabilityday.org

Friday, October 10, 2014

GNOME and Wayland

At GUADEC this year, I attended a great presentation about GNOME and Wayland. If you aren't aware, Wayland is an open source software project that manages communication between client programs and the display. In that respect, Wayland aims to replace X as the standard window system on Linux and Unix. Wayland also promises increased performance and security. While many complain that "Wayland doesn't respect network transparency," for most users I argue that network transparency doesn't matter so much. (But that's a debate for another forum.)

Fedora Magazine recently posted a review of GNOME on Wayland in Fedora 21. Fedora 21 will come with GNOME 3.14, which already runs reasonably well on Wayland.

Wayland isn't really part of usability, so I won't dwell on this topic here. Rather, please visit the article and comment on it there.
image: Wayland

Anyone in the Bay Area?

A reader contacted me, and expressed an interest in learning more about Usability and UX Design in Open Source projects but doesn't have any connections in the Bay Area. I volunteered to do some kind of remote presentation (I'm in the US Midwest, in Minnesota) but I wanted to take an extra step to see if there are any of my readers who could speak at a design group on the topic of UI Design in the Open Source community and/or provide some guidance on getting involved.

If you are in (or near) the Bay Area, and are willing to talk on this topic, I'll leave it to you to get connected via the comments.

Thursday, October 9, 2014

Outreach Program for Women

I am proud to be part of the Outreach Program for Women ("OPW"). In this cycle of the program, I will be mentoring participants in usability testing. You can find a list of project ideas in the GNOME Wiki.

Interested in getting involved in usability testing? Maybe the OPW is for you! Here are the details for the usability project:
Usability testing (mentor: JimHall)

Benefits: By conducting usability tests of GNOME, you can help find areas in GNOME that can be improved, to make GNOME even easier for people to use.

Importance: GNOME needs to be an easy and elegant way to use your computer. With good usability, GNOME will be easy for everyone to use.

Requirements: Usability testing is not difficult, and anyone can do it, even if you have never done usability testing before. Conducting your own usability test will require you to meet with people, to ask questions. You can re-use the usability test scenarios we used in previous usability tests, or you can write your own (for example, to cover new functionality or programs not previously covered). You will need access to at least two computers: a desktop or laptop for testers to use, and another (preferably a laptop) for you to take notes on. Usability testing is best done in a quiet space away from other distractions; for example, you might use a classroom or meeting room.

Mentorship style: You'll be working independently, but I can help! We'll do online chat to help you learn about usability testing, and to get started with your own usability test. As you get ready for your usability test, I can help you to prepare materials and questions, and offer coaching on what to expect. Afterwards, I can help you to analyze the test results using a "heat map" method.

Project team: I would be happy to meet with you via online chat (video, voice, or text).

Note: My Master's capstone was the Usability of Open Source Software, in which I analyzed and discussed the usability of GNOME. I gave a keynote at GUADEC'14 on GNOME usability, and I have written several articles on usability for Linux Journal.
Usability is about how real people use software. It's not about how the program wants people to do things, but how people actually use the program to get things done. Good usability in GNOME means that the people who use GNOME can do so quickly and easily to accomplish their own tasks. It's important for us to occasionally go back to do usability testing on GNOME to make sure that new versions of GNOME remain easy for people to use.

Doing a usability test is basically about sitting down with people, one at a time, and asking them to do a few specific tasks in GNOME. Then you observe how these testers actually use GNOME, and make notes on what they say, where they are looking for features, and how easily they can accomplish the tasks. In a usability test, you aren't testing the user, but you are watching the user to see how easily they can use GNOME to do their work.

Usability is a great way to contribute to GNOME. With good usability, everybody wins!

If you have some time and would like to learn more about usability testing (and my usability tests with GNOME), you might be interested in reading my Master's capstone about usability themes in open source software (available in PDF or ebook formats.) It's kind of long, but if you want to get involved in usability testing and just want to basics, the sections that will interest you most are:

  • I. What is usability
  • IV. Usability test design
  • V. Usability test findings.
  • Appendix: Scenario tasks

Joining the OPW requires making a small contribution, which helps you to learn what the project would be like. I think a good first assignment would be to do a 1-person usability test, with a friend, using GNOME 3.14. This will help you understand how to do a usability test, and get a feel for the effort that goes into it. A full usability test would require at least five people (for my usability test, I included 12 people) but for a first experiment to get started, you can do a usability test with a friend. Preferably one who hasn't used GNOME before - or at least, not the latest release of GNOME.

You can use the questionnaire and scenario tasks from the appendix in my capstone paper, and the GNOME 3.14 test ISO image. (This is a test image, so you may experience problems .. you may want to run through the scenarios yourself before asking a friend to do the usability test.)

Begin the usability test by "setting the stage," and explain that the usability test is not testing your friend but instead is testing the software. So if they have problems doing the test, that's okay. Also explain that you will be taking notes throughout the test, so your friend should speak aloud what he or she is trying to do, and looking for. See pages 18-19 in the capstone paper. The test will probably take about an hour.

You may find the most difficult part of the test for you is to not give hints to what to do. If your friend gets confused and (for example) isn't able to find the Preferences, you can't suggest what to do. Just take notes on how difficult it was to find, and where your friend was looking for the feature. If your friend gets frustrated, that's okay - just make a note and move on to the next task or the next program.

The full project for OPW would use more testers. You would also construct a "heat map" analysis of the results, and write up a conclusion with the "themes" of your usability test findings. And you would need to create a presentation about your work, a few slides that you might share at a conference.
image: Outreach Program for Women

Friday, September 19, 2014

Excited about GNOME 3.14

When I studied the usability of GNOME for my Master's degree, I was pleased that the GNOME designers took the results seriously and created "usability bugs" based on my findings. And this summer, I spoke about the usability of GNOME at GUADEC, and was again pleased that the GNOME developer and user community also views usability as a serious and present topic. At GUADEC, I learned that several of the bugs based on my usability study would make it into the next version of GNOME.

And the next version of GNOME is almost upon us!

A few days ago, Jakub shared a preview of GNOME 3.14 via a "making of" video. The video provides a brief view into all the hard work going into this release.

One thing that surprised me in Jakub's video was icon animation. I didn't realize that would be featured in the new GNOME. Animation is an important part of user experience, or "UX." The user experience is not "usability" per se, but it is a related topic. UX refers to the emotional engagement of the user to the program. It may be divorced from usability, but typically if a program has good usability it will effect good UX, and programs that have poor usability tend to effect bad UX.

Icon animation makes the desktop seem more approachable. For example, clicking on an icon to reveal a submenu where more program icons spring into existence helps the user relate the action of clicking on one icon to the appearance of the new icons—because they can see the action occur. You can see examples of GNOME animations starting at about 1:10 in Jakub's video.

Today, Allan confirmed via his blog that GNOME 3.14 is on its way. Allan shares these features:

New animations
Yes, the animations previewed by Jakub are there. See the video in Allan's post to see icon animation in Applications View.
Google Images in Photos
"The big news for 3.14 is that Photos will now pick up your Google photos, so any images you’ve uploaded with Picasa, Android, or posted on Google+ will be immediately available there."
Rewritten Adwaita
"Everything feels crisper, sharper, and a bit lighter. There’s also a lot of subtle animations now (thanks to CSS animation support in GTK+), adding to the feeling of polish."
Search More Things
"The number of applications that are feeding results to system search has continued to increase with 3.14, with two really useful new additions:" Clocks and Calculator.
GTK+ Inspector
A new tool for developers.

Update: I think what excites me most is seeing the results of my usability testing, and the improvement in GNOME 3.14. For example, Software includes several changes based on my usability test findings: New first run dialog which explains what the app does, and Moved the Install / Remove buttons down from the headerbar to a more prominent position.

The release notes for GNOME 3.14 should be posted next week.
image: gnome.org

When the canary dies, get out of the garden

Reported at Gigaom and elsewhere, Apple's "warrant canary" has disappeared, suggesting new Patriot Act demands. In this case, a canary refers to a statement on a website or in a report that states something about the company or its security. For example, a company might add a canary statement to their website's footer that "We have not been compelled to add a security backdoor to our products." If that canary statement disappears from the website, you can assume the company has been compelled to add a security backdoor.

Why the canary? Such demands are usually accompanied by a non-disclosure statement. The company cannot let its customers know that their products now have a backdoor. But a canary is different, a sort of compromise. Like the canary in a coal mine, when the canary statement disappears ("dies") it's time to get out.

When Apple published its first Transparency Report on government activity in late 2013, the document contained an important note (page 5, see PDF) that stated: "Apple has never received an order under Section 215 of the USA Patriot Act. We would expect to challenge such an order if served on us." Section 215 of the Patriot Act permits the National Security Agency to demand companies to hand over their business records in secret. It also vastly expands the FBI's power to spy on ordinary people living in the United States, and those served with Section 215 orders are prohibited from disclosing the fact.

Now, that canary statement has disappeared from Apple's reports. And as reported in Gigaom, Apple has become suddenly quiet on the subject.

However, Apple has recently announced a technical solution: Apple has reworked its latest encryption that prevents anyone but the device's owner from accessing data. It's not that Apple won't unlock the data for police, but Apple can't. In a page about "government information requests," Apple claims about the new features in iOS 8:
"On devices running iOS 8, your personal data such as photos, messages (including attachments), email, contacts, call history, iTunes content, notes, and reminders is placed under the protection of your passcode. Unlike our competitors, Apple cannot bypass your passcode and therefore cannot access this data. So it's not technically feasible for us to respond to government warrants for the extraction of this data from devices in their possession running iOS 8."
And that's good. Device encryption should be such that no one else can access your data. That's security. Unfortunately, it has taken until late 2014 for Apple to realize that.

So what's next? Last week, I was asked at an open source software event for my views on the future of free software and open source software. I responded that while the iPhone and iPad are "sexy" devices (and I have an iPad at home, which I use to watch videos and play games, but nothing of value) there will come a time with government spying that people will want to escape the "walled garden" of iOS. People will no longer want a company like Apple or Microsoft or Google to control their data; they will want to take back control of their own data and keep it safe.

That's where open source software will come to the rescue. Free software and open source software is peer reviewed. As open source software advocate Eric S. Raymond is quoted saying, "Given enough eyeballs, all bugs are shallow." It's highly unlikely a backdoor or other data surveillance method could escape detection in an open source software project, especially one with an active user-developer community.

Maybe the Apple canary is the start of that trend. Will people realize the importance of Apple's canary, that Apple is affected by FISA proceedings, and that user privacy is at risk? I think the user-private encryption in iOS 8 may delay the collapse of Apple's "walled garden," but I for one will no longer trust my Apple device.
photo: Majd Mohabek

Sunday, September 14, 2014

Contributing to free software

Over the weekend, the University of Minnesota Morris hosted a special event to help students learn about free and open source software. In partnership with OpenHatch, the event was titled "Open Source Comes to Campus" and provided an introduction to open source software, including a career panel, and hands-on opportunities to contribute to open source software projects.

During the afternoon workshop, I led several small groups in contributing to their first open source software projects. In my case, we helped out with FreeDOS, a project I started in 1994 to create a free version of DOS. During the afternoon, we contributed in two major ways:
With help from Emily, Josh, and Alek, we migrated old web pages into the FreeDOS Wiki. The overall project to convert old content will take weeks or months, and this workshop provided a great kick-off for our documentation clean-up efforts.

Daniel refactored the web code for the FreeDOS News page, which also feeds the news items on the FreeDOS website. Daniel made an immediate and lasting improvement to the FreeDOS website. Behind the scenes, the news code needed to be cleaned up. Daniel's fixes also allow visitors to link directly to a news item, necessary for sharing on Facebook and Twitter.
Other groups provided improvements to a free Senet board game and to a drone control system.

I am proud to have been a mentor for this event. What a great way to help students and to serve the campus! I look forward to next year's event!

Special thanks to Elena Machkasova and others in the Computer Science Club who planned this wonderful event.
Photo: Asheesh Laroia, last year's event at Morris

Friday, August 29, 2014

Five tips for a better user interface

Máirín Duffy writes at the Red Hat Developer Blog with 5 UX Tips for Developers. Duffy is a principal interaction designer with Red Hat, who works on the Fedora Engineering team and on the interaction design for Hyperkitty's UI. In her article, Duffy shares these five tips for a better user interface:
  1. Prioritize for the best impact
  2. Remove / prevent the extraneous
  3. Make it easy to access functionality
  4. Set reasonable defaults
  5. Design before you code
In the last point, Duffy provides this example:
"Do some quick sketches of how you think a feature might work—use one sheet of paper per screen involved. Show these sketches to others on your team, or even better, buy some friends who might be potential users each a cup of coffee and ask them to sit down with you and go through the screens. What problem are you trying to solve with the feature you’re working on? Explain the problem to your testers. Then ask them—without too much hand holding—to point at where on each screen they would think to go in order to try to solve the problem."
You should recognize this as a prototype. Creating a paper prototype is one of several methods in usability, especially early in the design/development process.

Sunday, August 24, 2014

The Year of the Linux Desktop - on your phone

Sean Michael Kerner recently wrote in eWeek about Linus Torvalds at LinuxCon. In a panel discussion, the moderator asked where Linus thinks Linux should go next. Linus's answer: "I still want the desktop."

In free software circles, we have been looking forward to the Year of the Linux Desktop since … well, forever. At home, I have used Linux as my desktop since around 1993, and I went full-time with Linux at home around 1998 (prior to this, my computer was dual-boot with Windows, to play games). At work, since 2002 I've been fortunate enough to run Linux full-time.

In discussing the changing landscape of desktop support, I've often said that the laptop and desktop will change dramatically over the next few years. That isn't really a novel concept; many industry analysts have predicted the same. In one vision of the future, the tablet and phone will merge with the laptop and desktop, providing a truly portable system. I believe that is the next step.

I've been thinking about the future of the desktop, and specifically the convergence of mobile devices and laptops. Some vendors have experimented in this space, with mixed success. It seems a matter of time until someone strikes the right balance, and this new device becomes the next "must-have" technology that displaces even the iPad.

I used to believe Apple would be the first to find the "right recipe" in merging mobile devices with the traditional desktop. They have the "right" mix of customer base, brand loyalty, and the engineering to do something truly remarkable in this space. But since Tim Cook became CEO, I also see Apple as currently less engaged in driving innovation, instead focusing on iterating products.

I think GNOME is in a good place to merge mobile and desktop—and with GNOME, I believe we will finally see a free desktop as the dominant platform. Here's my vision:

Most modern applications run in the Cloud (think Gmail) and very few applications actually need local computing power to run. Consider what programs you use everyday; I'd bet most of your time is spent in a web browser, and probably less than 25% using a traditional locally-run application. Perhaps "power" users are the only people who need to run big applications like GIMP that require huge amounts of RAM and CPU. The rest of us mostly need a device that connects us to the Internet using a keyboard and mouse to do our work via a web browser.

So, imaging doing your work from a laptop-like device, but the keyboard and display are only "slaves" to your mobile phone. This laptop-like device is effectively a wireless KVM. Pair your phone wirelessly with the "KVM" and your phone becomes your computer. You're still running all your apps on the phone, but the mouse & keyboard input and audio & video output goes through the "KVM." Disconnect the phone, or just wander out of range, and your data and apps go with you. Your laptop is essentially "in your pocket, on your phone." Reconnect the phone to the same or another "KVM" to bring up your apps right where you left them. You can pair your phone to multiple "KVMs" (think "home" and "office") but you can only connect to one at a time.

The magic of the "KVM" is in how the phone manages the display. In "phone" mode, the phone uses a traditional touch display. Connected to a "KVM," the phone's interface should adapt to suit a keyboard & mouse setup. Apps (web browser, music player, etc) should use an API that recognizes a "desktop" connection and changes their interface to one with the familiar GNOME top bar when connected to a "KVM."

GNOME is capable of making this merger between the phone an desktop. The look-and-feel of GNOME is similar to both phones and desktops; GNOME has chosen a cautious middle ground.

Here's looking forward to The Year of the Linux Desktop, with GNOME!
screenshot: mine; phone mockup: Fritz Franke

Friday, August 22, 2014

Updated GNOME HIG

At GUADEC, Allan Day discussed the GNOME Human Interface Guidelines, and mentioned that an updated version of the "HIG" was forthcoming. Allan has now shared the updated HIG, writing:
I’ve recently been hard at work on a new and updated version of the GNOME Human Interface Guidelines, and am pleased to announce that this will be ready for the upcoming 3.14 release.

Its goal is to help developers and designers take advantage of the new abilities at their disposal, without losing their way in the process. This is reflected in the structure of the new HIG: the guidelines don’t enforce a single template on which applications have to be based, but presents a series of patterns and elements which can be drawn upon. Each of these is accompanied by advice on when each pattern is appropriate, as well as alternatives that can be considered.
The updated HIG is really a "preview," but I'm sure it will soon be updated at the official HIG entry on the GNOME wiki. See Allan's blog for a screenshot of the new HIG elements.

What are my thoughts on the new HIG? I like it. It's not widely different from the current HIG, so previous GNOME users should have an easy transition. The interface elements are clean and distinct. I think new users will find this familiar enough to Windows or Mac that they will immediately understand how to get around. And that's an important part of usability: Programs should be familiar, or new users will not understand what to do. And it's important that GNOME programs use the same HIG: Programs should be consistent to each other, so users can apply what they learned in one program to other programs on the same system.

One suggestion would be to add a "checkmark" icon or some other indicator to the toggle button, so users can immediately see if the button is toggled. For example, if you were a vision-impaired user or an older user, would you be able to tell if a button was in the "toggled" state—especially if there weren't other "non-toggled" buttons on the screen for comparison? Most older people's color perception changes, and they lose contrast sensitivity. Adding some kind of marker to the "toggled" button would help—the on/off toggle (see HIG) is better for this kind of display, anyway.

What do you think of the updated HIG?
image: Allan Day

Wednesday, August 20, 2014

How to start a free software project

In the early 1990s, I was studying physics at the University of Wisconsin–River Falls. I did all of my work through MS-DOS: I wrote my papers using WordPerfect, I analyzed data in AsEasyAs (shareware spreadsheet program), and wrote my own DOS utilities to do other work and generally make life easier for myself. I dabbled in other systems, and by 1993, I had installed "Soft Landing" Linux as dual-boot on my '386 computer. That was really my first introduction to free software, although we had GNU Emacs on some of the computers in the campus Unix lab.

In 1994, Microsoft announced that "DOS was dead," that they would soon replace MS-DOS with the next version of Windows. No longer would you first boot your computer from DOS, then launch the Windows shell. Instead, Windows would completely "own" your computer. You can probably imagine how I, as a DOS user, responded to being "pushed" off my platform of choice. Windows 3.1x was not that great. Windows was clumsy and difficult to work with, but DOS was rock solid and did everything I needed. I did not want a future where everything was Windows-only.

So I decided to do something about it. If Linus Torvalds and others could write Linux, a free version of Unix—surely we could write our own version of DOS. After all, DOS was a much simpler operating system than Unix.

I announced my intentions on Usenet, a kind of bulletin board that was popular at the time. I wanted to write my own version of DOS, which we would release for free, with source code available to all. Within days, several developers volunteered to help. Within weeks, we counted our developers by the dozens. And thus FreeDOS was born.

The key to the success of FreeDOS was that we released our source code under a liberal license that allowed anyone to view and improve the programs. We used the GNU GPL for new FreeDOS programs, and found other programs on DOS software archive sites that were available under similarly free licenses. Users were encouraged to become developers, and submit bug fixes and new features to make FreeDOS even better.

If you weren't sure how to contribute to FreeDOS, we provided a list of "hot projects" that new contributors might find interesting. Non-developers were welcome to contribute too, and many did; and especially after I introduced the "Cats" library to support multiple languages within a single program, many non-developers contributed translations of FreeDOS programs into Italian, Spanish, French, and other languages. We collaborated via several mailing lists, supporting the FreeDOS kernel, general FreeDOS development, and FreeDOS users.

I think we did a lot of things "right" in FreeDOS to help our user-developer community to thrive. And reading a recent article by Matt Asay at ReadWrite, "Want To Start An Open Source Project? Here's How," our activities to support FreeDOS match a "best practices" list to support any open source software project. Asay's article suggests these things to make a project successful:
  1. Optimal market timing
  2. A strong, inclusive team of developers and non-developers
  3. An architecture of participation
  4. Modular code to make it easier for new contributors
  5. Code that is broadly applicable
  6. Great initial source code
  7. A permissive license
There's more to an open source software project than that, and Asay's article highlights several things you will want to consider as you start your own project.
image: mine (screenshot of FreeDOS)

Monday, August 18, 2014

Usability is not hard

In looking through some references, I googled a discussion item on LWN to discuss Allan Day's blog post "In Praise of Jim Hall." In the original post, Allan  reviews the usability study that I worked on with the GNOME designers (Allan, Jon, Jakub) and which I recently presented at GUADEC.

This comment from user drag caught my attention. It says, in part:
Studies of this type are very expensive and time consuming. You have to hire or have people on your team that are experts in software usability.

Then when you do your testing you have to get people that are not that familiar with the environment and then observe them as they interact with the UI and record their observations as they go through various tasks.

This is not easy and it's not cheap. No open source desktop has the resources, as far as I know, to actually sustain this sort of testing.
And:
Here is the claim I will actually make though:

Programmers who develop software are one of the least capable people when it comes to designing UI for the software they use.

Firstly because they lack the expertise… programmers tend to be a 'foot wide, mile deep' when it comes to technical knowledge. They know a huge amount about the specific things they work on. Unfortunately when it comes to things outside their specific type of software they work on they tend to be a bit clueless. Not that they are stupid or shortsided, [sic] that doesn't have anything to do with it.

And, secondly and far more importantly, they have a huge number of expectations and assumptions how people are going to use their software, as well as deep intimate knowledge about the software they are writing. This makes it extremely difficult, if not impossible, to step back and see the software from the perspective of a person that doesn't give a shit about the software, but just wants to accomplish something specific.

This is one of the biggest and most difficult problems that has plagued open source desktops from the beginning. The programmers who devote their time is fantastic and so on and so forth, but at a certain point you really need to pay money to hire experts.

And certainly usability is not decided through consensus.
Both statements are wrong.

As I discuss in my capstone "Usability Themes in Open Source Software" and in my presentation at GUADEC, usability testing does not need to be done by experts. Usability tests don't need to be highly formalized, or conducted in a lab by professionals. You can learn a lot just by setting up a simple usability test, then watching actual people use the software. With each iteration, usability testing identifies a number of issues to resolve and uncovers additional issues that, when addressed, will further improve the program’s ease of use.

Usability testing does not rely on a single method, however. There are multiple approaches to implement usability practices, from interviews and focus groups to formal usability testing. Whatever method you use, the value of usability testing lies in performing the evaluation during development, not after the program enters functional testing when user interface changes become more difficult to implement. In open source software development, the community of developers must apply usability testing iteratively throughout development. Developers do not require extensive usability experience to apply these usability practices in open source software.

The value of a usability test is to find areas where the program is difficult to use, so developers can improve the interface in the next version. The "hot spots" in the heat map show tasks that were difficult for testers, and which need attention from the designers or developers.
image: mine (screenshot of GNOME)

Thursday, August 14, 2014

Why companies like open source software

While this isn't related to the usability of open source software, I wanted to share this reflection about Linux in the enterprise. Companies take free software and open source software seriously. I can speak firsthand to this; I have introduced free software systems to every company I've worked for.

At my first job, I replaced aging Apollo/DOMAIN systems with low-cost Linux systems, running Slackware Pro. While we weren't ready to adopt Linux for everyone's desktop, we did deploy Linux to a few of our R&D developers. At my second company, I implemented Red Hat Linux 3.03 to provide DNS, NIS, NFS, and other core infrastructure services. And when I joined the University of Minnesota (in 1998) I introduced Linux for the first time in the university enterprise, replacing a 3-node IBM AIX SP system to support web registration. It was an immediate success, and changed the perception of "Linux in the enterprise" within the institution.

In each case, I did not "just" decide to bring Linux into the company. IT needs to be in support of the business; we cannot drive change simply for the sake of IT. So before I introduced Linux, I presented a business case for how free software would support the business. It wasn't all about saving money, although that was certainly one benefit. Rather, using free software was about modernizing the infrastructure, and streamlining operations. That is something any business professional can support.

These ideas are supported in a recent article from Howard Baldwin at ComputerWorld: "4 reasons companies say yes to open source." Baldwin's article presents a good overview of how companies perceive the value of free software and open source software. From the article:
When individual developers think of open source, they think "free." And with good cause: Who in their right mind wouldn't be interested in technology that they can get at no cost and use with few licensing restrictions?

When companies think of open source, these days they think "business agility," a quality they increasingly value above all others in the fast-changing marketplace.
According to the article, four key reasons why companies are taking open source software seriously:
  1. Open source keeps costs down
  2. Open source improves quality
  3. Open source delivers business agility
  4. Open source mitigates business risk
photo: Steve Wilson

Tuesday, August 12, 2014

Practical usability methods anyone can use

I was unable to attend Fedora's Flock 2014 conference in Prague (August 6–9) but I applaud the conference organizers for streaking the presentations and making these videos available via their YouTube channel. So while I was not there in person, I got to attend the presentations that were most interesting to me.

One such presentation was Karen Tang's "UX 101: Practical usability methods anyone can use," a crash course in UX methods:


However, I would argue that Karen's presentation wasn't so much about User eXperience ("UX") as it was about Usability. The two are very closely related, but UX relates the emotional experience of a user interacting with a product, while Usability refers to how easily the user can navigate and use the product.

Karen does a good job of highlighting the Usability process, walking her audience through the different ways to do a Usability test, and how to conduct a Usability evaluation.
image: Flock

Wednesday, August 6, 2014

In praise of GUADEC

This is actually cross-posted from my at-work blog, Coaching Buttons. But I wanted to share it here for other GNOME folks to see, because equality in technology is a great thing. After hearing about unchecked harassment at US-based cons (example), I'm proud to stand with GNOME and GUADEC.
Lipton poster as an unfortunate example of casual sexism
In writing my reflections from GUADEC, the GNOME Users And Developers European Conference, I was excited to review several key presentations that caught my attention. GNOME is a great example of free software, demonstrating how many contributors can come together in a "great babbling bazaar of differing agendas and approaches … out of which a coherent and stable system could seemingly emerge only by a succession of miracles" (to quote Eric S. Raymond's description of open source software).

On another note, I was also pleased to see GUADEC has a very clear non-harassment policy, which says, in part:
GUADEC is dedicated to providing a safe and friendly conference experience for everyone, regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, age or religion. We do not tolerate harassment of conference participants in any form. Harassment includes offensive verbal comments related to any of the above qualities, deliberate intimidation, stalking, following, harassing photography or recording, sustained disruption of talks or other events, inappropriate physical contact, and unwelcome sexual attention.
GUADEC established several members as go-to people for harassment incidents (both women and men) and identified them to us during the welcome session. Everyone at the conference was provided the phone numbers and email addresses of the code of conduct support team. GNOME actively encourages women and minorities to get into coding, so a clear non-harassment policy is a must-have.

And it's not just lip service; GNOME's non-harassment policy got mentioned during my first night in Strasbourg, when several of us went to dinner. I connected with a group of other men after the pre-registration event, and we found a small restaurant a short distance from the city centre that was happy to seat all 11 of us. We had a great time until our drinks arrived. When the waiter engaged in casual sexism (he spoke almost no English, but the gestures were clear) one of our members spoke up and reminded the group about GNOME's non-harassment policy. I'm glad to say the reminder wasn't necessary; I don't recall that anyone in our group thought it was funny. A great example that even though it was before the conference, the non-harassment policy still applied and we shouldn't encourage the waiter's behavior.

On the first day of GUADEC, Marina Zhurakhinskaya shared a presentation about How to be an ally to women in tech. Marina's talk was a refreshing reminder on how to support everyone in free software. Marina talked about how women in technology often face the "unicorn syndrome"—if you are a woman working in technology, you will eventually be asked to give a talk about being a woman working in technology. Marina also discussed words to avoid when talking about people and technology, something I realized I fumbled when I gave my keynote. Notably: you can find examples everywhere of people who can't use technology; be careful of saying "the interface needs to be so simple that your mother could use it." (Oops. In my keynote, I said that I wanted GNOME to be something that my mom could use. That's something to work on.)

I am so glad to see these examples! Technology must be open to everyone. This is especially true of free software, where there should be no barriers to contribute. GNOME and GUADEC clearly have set expectations about appropriate behavior, and the GNOME community has achieved not only "buy-in" but ownership.
photo: mine (poster found in Strasbourg, an unfortunate example of casual sexism)

Monday, August 4, 2014

My slides from GUADEC

If you'd like a copy of my slides, I have shared them here: usability-themes-guadec-2014.

Note that my presentation used images as "backdrops" so I could talk about the content. So for the first half of the presentation, you may have some trouble in following along. The general outline is this:

1. Introduction.
Who I am, where I'm from. I have been involved in different free software projects since 1993. In 1994, I created FreeDOS, which is still used today to run classic DOS games, to run legacy business software, and to support embedded systems. I also recently got my Master's degree. My capstone project was a usability study of GNOME, working with Allan, Jakub, and Jon.
2. Software needs to be like a rock.
A colleague likes to use the phrase, "Software needs to be like a rock; it needs to be that easy to use." You don't think about how to use a rock; you just bang the rocks together. And software needs to be that simple to use, as well. That's important, because free software is competing for mindshare not just with other free software projects, but with MacOS, iOS, Chromebook, and Windows. Free software needs to be easy to use in order to attract and retain users. And that's where usability comes in.
3. What is usability?
Usability focuses on the user, on people. Because people use products to be productive, users are busy people trying to accomplish tasks, so users decide when a product is easy to use. If it's too hard to use, no one will use it. Usability is about being easy to learn, easy to use, easy to remember.
4. My usability study.
I worked with Allan, Jakub, and Jon to examine how well users understand and navigate the new design patterns in GNOME. This usability test covered five GNOME applications, and included testers of all ages and all experience levels.

Start with a definition of your users; GNOME includes everyone. Then create your test scenarios, using plain language that focuses on real tasks that real users would probably do. Be careful about time so you don't wear out your testers. See the slides for examples of actual scenarios used in the usability test.
5. My results.
I summarize my usability test results in a "heat map." Green and yellow represent no difficulty or little difficulty. Red and black show tasks where the user experienced extreme difficulty or was unable to complete the task. The heat map shows the tasks that represent areas of improvement in GNOME. In my talk, we had a great discussion about these usability areas. Allan has already created usability bugs in the GNOME Bugzilla.

It's best to run your own usability tests - but if you can't, at least follow these themes for good usability: Programs should be familiar to new users. Programs should be consistent to each other. Use menus carefully. Actions should produce obvious results. Buttons, labels, and icons should be located near to each other, or users will skip over them.

Sunday, August 3, 2014

GUADEC wrap-up

GUADEC 2014 was an exciting experience for me! This was my first time at GUADEC, although I've attended other, similar open source software conferences before: O'Reilly Open Source Convention and Penguicon both come to mind.

If you haven't attended GUADEC before, the general schedule is that each day kicks off with a keynote or similar session, then much of the rest of the day is devoted to general sessions, usually with a single closing presentation at the end of each day. The general sessions gave an option of two presentations per session.

There were so many great talks to choose from, but of course I could only attend some of the general sessions. I've just posted a few highlights from each of the four days of GUADEC. While I'm actually posting these almost a week later, I have back-dated each article to the corresponding day at GUADEC. I hope this will help you follow GUADEC, and perhaps interest you to join us next year!
image: gnome.org

Tuesday, July 29, 2014

GUADEC day 4

The final day of GUADEC saw eight general session presentations (four sessions, two presentations per session), a keynote presentation, lightning talks, and a preview of GUADEC 2015. A few highlights:

GNOME UX: the social dimension ~ Allan Day
Allan talked about user experience, which is tied to usability but distinctly different. In simple terms, the user experience (or "UX") reflects the user's overall emotional investment in using the software. Allan talked about software being "beautiful" as one element of the user experience, and he's right. Software needs to be both easy to use and pretty to look at, in order to attract and retain users. Allan also talked about keying into the social aspect of software to build a better picture of the user experience.
GNOME Outreach: a report from the war nobody is participating in ~ Sri Ramkrishna
Sri is part of the GNOME Outreach team, working on user engagement for GNOME. Part of Sri's job is to listen to what users are saying about GNOME, and bring them into a conversation. Eaching several "social" points from Allan's earlier presentation, Sri is doing the right things here. It's all too easy for anyone on the Internet to complain about change, but it's important to turn most of these "flames" into a discussion to learn how the user reacted to the change, and why, so we can feed that back into GNOME development. This continual feedback helps build the GNOME community and improves the functionality and usability of GNOME. And everyone benefits from that.
Builder, a new IDE for GNOME ~ Christian Hergert
I was particularly moved by Christian's presentation about creating a new integrated development environment ("IDE") for GNOME. Christian shared mockups and prototypes of Builder, and demonstrated how Builder will benefit developers to make them more efficient in creating GNOME projects. During his presentation, Christian also shared that he is taking the next year off from work, relying on his savings to let him work full-time on Builder. I don't write much code anymore, but I eagerly await to see what becomes of this project.
image: gnome.org