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


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