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