Monday, December 23, 2013

Guest post: In 2014, let's make open source software more usable

This is a guest post from my friend Asheesh from OpenHatch.org. Asheesh and I met at an OpenHatch event sponsored at the university where I work, the University of Minnesota Morris. It was a lot of fun to participate in this open source software event; I recommend your university also look at hosting a similar event for your students and community.

I want everyone to be able to choose free software and feel empowered. But right now, so much free software—even some of the most widely-used software—is barely usable.

If this is a problem that matters to you, too, and you're willing to put in 1-3 hours per week of volunteer time over 2014, I think we can make a huge difference in fixing this. You don't have to know anything about usability today to do this; you can learn as you go.

So, we need a volunteer to step up. But first, a story:

I had the opportunity to meet the founder of the FreeDOS project, Jim Hall, yesterday in Morris, MN. Having created a popular (within its niche) operating system project, he's come to realize that the next frontier for open source is not more code: it's building software that people can use to get things done.

Free software hackers often think of usability as a vague notion, wondering what to do when confused users issues in their bug trackers. By contrast, usability researchers like Jim do something concrete: they name a specific task a user should be able to do with that app, and then tell some users: "Do that task as well as you can. Narrate what you are thinking, and we'll record the screen." If the goal is to build software that people can use, the test is finding out if they can actually use it.

The results show that people often get stuck at the same points when trying to achieve a task. It's excruciating for developers, who want to help by saying, "The save button is right there." In Drupal, recordings of these experiments caused the community to change links and text within the admin module. When they did that, user confusion decreased.

We can say that "user confusion decreased" because usability is in fact measurable. In Drupal, they performed the same experiment a second time, with that UI widget changed, and asked: "How many users were able to achieve the task in the given time?" If that number increases, then we know we are getting somewhere.

Jim is going to run a handful of tests as part of his masters thesis. He's not the first in open source to care about usability—the now-defunct OpenUsability project began in 2006. The question is, when his masters thesis is over, will the community continue to understand how to do this important work?

Here's my plan:

We—the free software community—need someone to take the burgeoning interest in usability and turn it into something that becomes embedded in existing projects and grows from there. That's something you can do.

To do that, you'll need to set a goal that in 2014, you'll find two projects that are interested in improving their usability, run one user test for each project, and work with Jim to document how anyone can run these tests. The measure of success is if one new person in the world runs a user test on a project they care about and shares that result with the project's community.

I think that won't take more than 1-3 hours per week over 2014, most of which will be spent reading about usability, chatting with Jim, and writing documentation on how to run user tests.

I, and probably other people, can support you, help you find those two projects that want usability help, and help get the word out. We can work together to help you present your usability data in the clearest way so those projects understand the findings.

You'll know that you'll have begun to change the culture of open source software in one of the most high-impact ways.

Do you want to?

Saturday, December 21, 2013

Fedora 20 desktop impressions

EDIT: I received feedback via Twitter from GNOME designer Jon McCann, and I've added his comments below.

After having used Fedora 20 and GNOME 3.10 for about a day, my initial impression is that GNOME 3.10 has made big improvements with the desktop. Some of these changes are subtle, others more obvious. Let's look at some screenshots.

GNOME initial desktop, with Help
GNOME initial desktop, with Help

After installing Fedora 20, the first thing you see is the GNOME 3.10 desktop, with a Help application to get you started. That's a great way to introduce new users to the desktop, and a good way to provide balance for more experienced users who just want to get right into things. A few things to note:

I like the minimalist icons in the upper-right. It's immediately obvious that these represent your wireless connection, speaker volume, and battery charge. The down-arrow suggests that you can click on this area to get more (and you can).

The "Activities" hot-corner/button in the upper-left makes it clear how to get to new applications.

The simple white-on-black scheme of the top bar helps to provide better focus on the desktop and applications, rather than "blending" the top bar with the desktop metaphor.

GNOME certainly addressed some usability issues, but not the big ones.

I'm still not a convinced of GNOME's decision to put menus behind the application icon. Their compromise to usability is to include a down-arrow to suggest you can click on this, but in most applications that's just an option for "Quit" (which is the same as clicking the "x" icon in the upper-right of most applications, anyway). I understand from GNOME developers (and other folks, for example on Slashdot) that GNOME intends to move all application menus under this application icon. That doesn't seem to be a good move to me. My previous usability testing shows that users prefer menus that are obviously part of the application (think "menu bar"). The application menu in the black top bar doesn't stand out as part of the application experience.

EDIT: Apparently this is not correct. McCann reports "no intent to move all menus to app menu." Good to hear!

Activities - Show Applications
Activities - "Show Applications"

If you click on the "Activities" button (or just move your mouse into the upper-left "hot corner") you'll get a view of all applications that you currently have open, plus the "favorite" applications you use frequently on the left-hand side. If you click on the "3x3 grid" icon, you'll be able to "Show Applications" and see all the applications that you can run. I think this is really well done.

GNOME Evolution using Gmail linked account
GNOME Evolution using Gmail linked account

GNOME linking to online accounts
GNOME linking to online accounts

Another thing that GNOME 3.10 has done really well is to let you link certain online accounts with GNOME. For example, you can choose to link to your Google account, which lets you access your Gmail and Google Calendar using GNOME's Evolution application. This is a good feature for those who prefer to use desktop tools, similar to using Outlook on Windows.

GNOME overlapping windows

GNOME overlapping windows with Nautilus tiled to right side

However, I think I found a problem with how GNOME displays overlapping windows. I show two instances above, where one window (GNOME's Nautilus file manager) overlaps another (GNOME's operating system update tool). In GNOME, you can drag an application to the top edge of the screen to maximize the window, and that's what I've done with the update tool. You can also drag an application to either the left or right edge of the screen to "tile" the window over half the display. And I've shown that here in the second screenshot with Nautilus.

When the application hasn't been tiled, you get a nice drop-shadow effect, suggesting that one application window is "over" another. But when the application window has been tiled, you lose this shadow effect. Take another look at the second screenshot. Where does the Nautilus window end? How do you know when you've moved your mouse out of the Nautilus file manager, into another application? Perhaps this is a bug?

EDIT: Fortunately, McCann says "Lack of tile shadow is a bug" so I hope to see this fixed soon.

These screenshots also show a poor usability choice with the Nautilus file manager. You'll notice that other GNOME applications include a menu. Not so with the file manager. In this application, you don't even get a title bar. The application's menu is under the application icon in the black top bar. You click on the application icon to access features such as "New Window," "Connect to server," "Bookmarks," and "Preferences." So far, the file manager is the only application I've found that does this. All the other GNOME applications seem to use the application icon menu for "Quit."

I'll be interested to do another usability test with GNOME. How will average users with typical knowledge react to GNOME? Will they find it useful, or confusing? What will be the pain points? What works well for these users, and what areas could still be improved? I expect to start a usability test in February or March, with results in April or May. Watch this space.

Also, some research help: I know GNOME did usability testing in the past. If anyone can point me to their usability tests, please leave a link in the comments. (I haven't done much digging yet.)

Fedora 20 first impressions

I installed Fedora 20 on my laptop yesterday, and wanted to share some first impressions. The obvious place to start is with the installer; this is the first thing that any new user will experience when installing the operating system. I've written several installers myself (including several versions of the FreeDOS operating system installer) so I know first-hand that it's important to get this right for usability.

ZDNet has a hands-on walkthrough of Fedora 20's "Anaconda" installer. I'll point you to them for screenshots.

Most operating system install programs try to streamline the install process, and use a "procedural" method. That is, the installer walks you through each of the steps; you answer a few questions (preferred language, time zone, etc) then the operating system just seems to install itself. Fedora 20's installer uses a "hub and spoke" model for the install process. I find this interesting for some parts of the installation, but overall it gives the impression that you need to know something extra before you can do the installation.

My biggest gripe with the Fedora 20 installer is the "Installation Destination" section. This is where you set up the hard drive where you will install Fedora. I previously had installed Fedora 19 Xfce on this laptop, so all I wanted to do was to install overtop what I had. I was totally okay with losing my existing data; I had already backed up the few files I wanted to keep. But it just didn't seem obvious how to do that.

I went into this section, did my thing, thought it didn't work, went back into the section, re-did my disk setup, saved … before I finally decided that it was okay. This from someone who has been tinkering with Linux of different flavors since 1993. I know what I'm doing, but I really doubted myself when trying to do something as straightforward as re-installing Linux on this laptop. (See ZDNet's screenshot for this step.)

I will say that Fedora gets it right when the system is installing Linux for you. While the installation is happening in the background, you can also set up your login account and root password. (See ZDNet's screenshot for this step.) And it doesn't let you continue until you've done that, so even if you walked away and ignored the screen, you'll still have to complete those two steps before you finish. That's about the only time the Fedora 20 "hub and spoke" install process really feels natural.

I have a few other minor issues with the installer, but these are focused mainly on visual details and presentation style, not so much about "usability."

Friday, December 20, 2013

Tuesday, December 17, 2013

Fedora 20 is out

I've been looking forward to using GNOME 3.10 for a while now. I've previously commented on GNOME's poor usability, but GNOME 3.10 claims to feature an improved user experience ("UX"). These UX features include:
  • A new "Paginated Application View" when selecting programs you can run, rather that a scrolling list (this seems similar to an iPad, for example)
  • A customizable lock screen
  • Changes to scrollbars, so it's easier to move small distances
  • Fixes to the Settings application, including changing Date & Time, easier to configure Displays, integration of chat accounts into Online Accounts, combining all features of Universal Access into a single page, and allowing the user to set their background via their Flickr account.

As a major player in the open source software desktop, GNOME is often the focus of usability reviews. Calum Benson, Matthias Müller-Prove, and Jiri Mzourek included GNOME among their 2004 findings about Professional Usability in Open Source Software (see my other post). Similarly, Nichols and Twidale link to GNOME in The Usability of Open Source Software webpage. GNOME brings attention to usability, as suggested by their Usability Testing Suite wiki.

So with GNOME 3.10, I'm hopeful that the project has addressed the usability issues I mentioned previously.

However, I prefer to wait for developers and beta testers to shake out any bugs in this initial release. So I have been waiting for Fedora 20 to come out, which promised to include GNOME 3.10. Fedora is a mainstream Linux distribution, generally well-regarded by Linux users. But most important for my purposes, Fedora prefers the GNOME desktop.

Well, the wait is over - the Fedora Project released Fedora 20 today! Check out the release notes for details. Quoting from the release notes:

3.1.4. GNOME 3.10

3.1.4.1. GNOME Overview

Fedora 20 features GNOME 3.10. This latest version of the GNOME desktop will have a number of new applications and features:
  • Fine grained scrolling when dragging the scroll bar handle, or scrolling while holding the shift key.
  • Support for login and authentication with Smart Cards.
  • Header bars merge title bars and toolbars into a single element, giving more screen space to window content and improving presentation of application controls.
  • Improved Magnifier with caret tracking, press F7 to activate caret.
  • Lock screen background customization.
  • A new geolocation framework allows features like automatic timezone updates when traveling and location detection in Maps.
  • GNOME Documents support for OwnCloud
  • Drag and drop files between your computer and a Boxes guest. Windows guests will need http://spice-space.org/download/windows/spice-guest-tools/ installed, and Linux guests will need an updated version of spice-vdagent.
  • Boxes gains support for importing filesystem images.
  • Improved user interface for Contacts
  • Improved automatic scaling for high pixel density displays.
  • Improved application selection in the shell Overview.
  • Flikr integration with GNOME Online Accounts allows access to Flikr content in GNOME Photos.
  • Improved, integrated system status menu.
  • Redesigned gnome-tweak-tool, with improved design, extension integration, and expanded functionality.
  • A new application, GNOME Maps, brings a simple map application to the GNOME Desktop.
  • GNOME Music, a streamlined application for playing and sharing music.

I'm interested in the changes to scrolling, "header bars," and the other user interface improvements.

This is perfect timing; my M.S. capstone project (working title: "The Usability of Open Source Software") starts in January. I hope to refresh the usability study I conducted previously with GNOME on Fedora 17.

Sunday, November 17, 2013

Does GIMP have good or bad usability?

GIMP logoA year ago, I asked readers to suggest programs that have good usability (I also solicited feedback through colleagues via their blogs and their readers). Many people talked about GIMP, the open source graphics program (very similar to Photoshop). There were some strong statements on either side: About half said it had good usability, and about half said it had bad usability. However, I decided to skip GIMP in my usability study, as it is intended for people who do specific graphics work, and my usability test targeted the general user. But I didn't discuss the split opinions in the usability of GIMP.

In following up, it seemed that two types of users thought GIMP had poor usability:

  1. Those who used Photoshop a lot, such as professional graphics editors or photographers
  2. Those who never used Photoshop, and only tried GIMP because they needed a graphics program

screenshot of GIMP
screenshot of GIMP

Users who thought GIMP had good usability used Photoshop occasionally, such as hobbyist photographers or casual web designers.

Digging further, I believe this is because:

  • Those who only occasionally use Photoshop understand the concepts and terminology used in Photoshop and so are easily able to transfer their knowledge from Photoshop to GIMP.
  • But those who never used Photoshop were completely lost in the terminology and concepts. GIMP relies on layers for image construction (so does Photoshop). "Layers" are a difficult concept for someone who has never worked with them before.
  • And those who use Photoshop all the time were confused that functionality and features differed slightly from Photoshop, or was accessed differently, or used different terminology; these users were stymied by what they perceived as a dramatic change from Photoshop to GIMP.

So GIMP is an interesting case. It's an example of mimicking another program perhaps too well, but (necessarily) not perfectly. GIMP has good usability if you have used Photoshop occasionally, but not if you are an expert in Photoshop, and not if you are a complete Photoshop novice.

Monday, November 11, 2013

Stop listening, start watching

CITE World magazine (CITE = "Consumerization of IT in the Enterprise") posted an interesting article today entitled Stop listening to your users. It's a good reminder for how to create designs that respond to users' needs, how users actually need to interact with a system. Rather than ask for desired features and designing for that, information designers should observe their users' work flows and work habits instead.

"Instead of asking your users, watch them as they do their jobs and you are going to learn so much more. See what they do in the course of their day and what it takes to do their job. What are they doing now manually or with clunky business software that you could simplify and make easier?"

I recognize this as the basis for good information design, and a starting point for usability study.

The article shares advice for designers to "Listen, observe, iterate."

Listen
Sarmad Salim, director of application design and mobility at drug company Sanofi, suggests starting with a use case interview: "We don't ask them what they want, we ask them what they do."
Observe
Brian Katz, also works in mobility at Sanofi, adds that designers should go on "ride-alongs" where you follow the user around for the day and see how they use the app you so carefully designed.
Iterate
From there, simplify the process by finding innovative solutions, not just by "ticking a box" on a requirements document. Find ways to solve the process need, the workflow, that best suits your audience. And repeat. For example: Scott Blanford, CTO for retirement and individual technology at TIAA-CREF, created a "wikipedia-like" system for information retrieval, because it made the most sense for how people worked with information. "It's so simple when you think about it and makes so much sense, but nobody had ever done it before because they accepted the old way as the standard way of doing business, warts and all."

From the conclusion of the article:

"You shouldn't really stop listening to your users, but the point is you aren't always going to hear from them exactly what they need. In some cases they may know, but in many they may not, or at least they won't be able to articulate it in a way that enables you to build a solution that really improves their working lives. 
The best way to do that is go down on the floor or for a ride or wherever the employees who will be using the software work, and watch them and learn and put your expertise to work on the problem. 
And most of all. remember that the app is never really done. You need to keep iterating, refining, and improving because needs change -- whether your customer is internal or external -- and what you did last week might not apply forever."

Thursday, October 3, 2013

Good code never dies

There's an interesting article on GCN from Micheal Daconta. Daconta argues that "Good code never dies." Rather, and to paraphrase Marc Andreessen, software will "eat the world." By this, Daconta says that good source code on a robust, well-supported platform has a long shelf life, decades or more.

From the article, Daconta offers three reasons that good software will continue to proliferate:

Good source code has longevity.
For example, the Java Platform was released by Sun Microsystems in 1995 and is still growing strong and evolving today.
The power of open-source software.
Open source software, where the source code is available to the public for reuse, including modification, has been a global boon for innovation and improving the overall state of technological progress.
Source code maturity should be the gold standard.
The key mark of good software is that it fulfills its function, over time, robustly and reliably. Good source code is mature source code.
Daconta's measures for source code maturity are: It is being used in a production environment; It has aged in that environment and therefore has been executed by end-users; It has been tested in terms of coverage and corner cases; and It has been tested via automated regression tests. The most mature code will have fulfilled all of the above and run flawlessly under those constraints for the longest time.

How mature is your code?

Tuesday, October 1, 2013

Trust in open source software

The Guardian recently ran an interview with Microsoft's ex-Chief Privacy Officer, Caspar Bowden, where he discusses his shaken faith in Microsoft after NSA spying allegations. In the interview, the article mentions Bowden's use of open source software. I wish the article had expanded on this, as it addresses a major benefit of open source software. From the article:
Caspar Bowden, who between 2002 and 2011 was in charge of the privacy policy for 40 countries in which Microsoft operated – but not the US – told a conference in Lausanne, Switzerland, that he was unaware of the Prism data-sharing program when he worked at the company. 
"I don't trust Microsoft now," he said, adding that he only uses open source software where he can examine the underlying code. He also said he has not carried a mobile phone for two years. 
In June the Guardian revealed that an NSA program called Prism could demand data from a number of technology companies at will using court orders that were never rejected.

And that's all the article says about open source software.

According to Richard Stallman of the Free Software Foundation, “free software” means software that respects users' freedom and community. Roughly, the users have the freedom to run, copy, distribute, study, change and improve the software. With these freedoms, the users (both individually and collectively) control the program and what it does for them. Thus, “free software” is a matter of liberty, not price. According to Stallman, “free software” means the program's users have these four essential freedoms:

  • The freedom to run the program, for any purpose (freedom 0).
  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

The first part of freedom 1 (to study how the program works) is likely at the core of Bowden's switch to open source software. To be truly free software, users need to be able to examine to source code to see what the program does, or is trying to do. This benefits everyone, even if you are not a developer or someone who understands how programs work. The opportunity exists for user-developers to study the source code. This makes it increasingly difficult for bad behavior to go unnoticed, for an increasing number of people examining the source code. For very popular open source software projects, it's virtually impossible for "backdoors" and other surveillance behaviors to exist in open source software projects.

By using open source software, we are all safe. Open source software is the rising tide that floats all boats.

Sunday, September 29, 2013

OpenHatch open source software event in Morris

This weekend, I was excited to participate in an OpenHatch open source software event at my campus, the University of Minnesota Morris. Thanks to Shauna and Asheesh for providing a very engaging day with everyone, and to Nic, Elena, and KK for hosting the event.

I didn't do a specific headcount, but I'd guess we had more than 25 people in attendance, most of them students.

The purpose of the workshop was to help students get engaged in open source software. It was a very full day. We started by discussing communication tools common in most open source software projects (IRC and email), tools used in open source software (such as Git), and how to pick an open source software project you'd like to work with. Several of us also participated in a panel discussion about open source software, and answered questions about how folks can make a living in open source software.

In the afternoon, we divided into groups of interested students to actually contribute to an open source software project. I was fortunate to work with a student who helped me with Simple Senet, a simulation of the ancient Egyptian boardgame Senet. (Since there are two accepted by competing rulesets, we worked on a method to allow users to tweak the gameplay rules of Senet to the version they prefer. This solution allows the user to specify command line options that turn on or off certain options, including "ruleset groups" of common play options.) We got most of the way towards a solution during the afternoon session; I can take it from there and code the final implementation in a future version of Simple Senet.


Friday, September 27, 2013

The persistence of ctrl-alt-del

Just a quick note to share this video from the Harvard Campaign, interviewing Bill Gates from Microsoft. See the related article on GeekWire for discussion and a link to the video. The interview is very interesting, but from a programmer and usability perspective, I was drawn to Gates's comments starting around 16:30, in response to a question about Windows users having to press ctrl-alt-del to login.

The article summarizes Gates's response pretty well:
“You want to have something you do with the keyboard that is signaling to a very low level of the software — actually hard-coded in the hardware — that it really is bringing in the operating system you expect, instead of just a funny piece of software that puts up a screen that looks like a log-in screen, and then it listens to your password and then it’s able to do that,” Gates said. 
The Microsoft co-founder said that there was an option to make a single button for such a command, but the IBM keyboard designer didn’t want to give Microsoft a single button. So Microsoft decided to use “Ctrl+Alt+Del” as a way to log into Windows. 
“It was a mistake,” Gates said, drawing a big laugh from the crowd.
While this was certainly a laugh line, it's interesting to comment on the origins of ctrl-alt-del. It actually originated in the early MS-DOS days. The core of MS-DOS could receive "interrupts" from the hardware to capture certain events. One important event was the ctrl-alt-del key combination; if you pressed these keys at the same time, MS-DOS would immediately reboot. Microsoft included this as a way to recover the system if MS-DOS "hung" and stopped responding to the user.

When Microsoft later introduced Windows NT (a completely redesigned operating system that imitated the then-familiar look of Windows 3.1, where Windows 3.1 still ran on MS-DOS) Microsoft was concerned that "bad guys" would create a screen that mimicked the Windows NT login screen, to capture people's usernames and passwords. This would be bad news in a corporate environment, for example.

So Microsoft had users initiate the login function by pressing the ctrl-alt-del key combination. If you were running a fake screen (probably running on MS-DOS) meant to capture your password, the system would immediately reboot. But not Windows NT. That way, you knew you were always using Windows NT.

While this may not be a very visible usability issue, it's worth reflecting that the ctrl-alt-del key combination has stuck with us today. A "hack" originally introduced in MS-DOS remains as a vestige in today's Windows operating system. The "three finger salute" (as ctrl-alt-del is sometimes affectionately known) has a certain persistence.

Thursday, September 26, 2013

GNOME 3.10 now available

I saw that GNOME 3.10 was released today. From the announcement: "The release comes six months after 3.8, and contains 34786 changes by approximately 985 contributors. It contains major new features as well as a large collection of smaller enhancements. 3.10 provides an improved experience for users, as well as new capabilities for application developers."

The major features include:
  • Support for the new, faster Wayland graphics system
  • A new, redesigned system status area
  • Merging titlebars and toolbars into a single "Header Bar"
  • New core applications, including including Music, Photos, Notes, Software and Maps

But most important to me: GNOME 3.10 claims an improved user experience. These UX features include:
  • A new "Paginated Application View" when selecting programs you can run, rather that a scrolling list (this seems similar to an iPad, for example)
  • A customizable lock screen
  • Changes to scrollbars, so it's easier to move small distances
  • Fixes to the Settings application, including changing Date & Time, easier to configure Displays, integration of chat accounts into Online Accounts, combining all features of Universal Access into a single page, and allowing the user to set their background via their Flickr account.

Additionally, GNOME 3.10 advertises clearer text, smart card support, and improved support for low-vision users by caret and focus tracking in the magnifier, among other changes.

I'll admit that I'm looking forward to trying this release. However, I prefer to wait for developers and beta testers to shake out any bugs in this initial release. Perhaps I'll wait until December, when Fedora Linux 20 is due out; Fedora uses GNOME as the default desktop, so will include GNOME 3.10.

As a major player in the open source software desktop, GNOME is often the focus of usability reviews. Calum Benson, Matthias Müller-Prove, and Jiri Mzourek included GNOME among their 2004 findings about Professional Usability in Open Source Software (see slides, PDF). Similarly, Nichols and Twidale link to GNOME in The Usability of Open Source Software webpage. GNOME brings attention to usability, as suggested by their Usability Testing Suite wiki (last edited 2012-05-27 13:34:01 by JanCBorchardt).

So with GNOME 3.10, I'm hopeful that the project has addressed the usability errors I mentioned previously. I'll advise that large open source projects like Fedora that depend on many "upstream" projects like GNOME often slip their release dates. While the Fedora Project currently estimates "2013-12-03" for the release, note that this already has slipped from the original estimate of "2013-11-26." By the time Fedora 20 actually gets released, it may be late December 2013 or early January 2014. And on an academic note, this would be perfect timing; my M.S. capstone project starts in January 2014.

Friday, September 13, 2013

Supporting multiple languages

This is much more technical than is needed for a discussion about Open Source Software & Usability, but since having a program operate in your preferred language affects software usability, I thought I'd briefly explain how software supports multiple languages. Adding support for different languages is easy. If you are a programmer working on an open source software project, I encourage you to become familiar with these or similar methods. By including different languages, you increase your program's audience, and you find new ways for people to contribute to your project (by translating your program into other languages).

Most programming languages provide some kind of support for multiple languages. The most common is the catgets method used in the C programming language. The "cat" in catgets refers to a "message catalog," and the "gets" refers to "get a string from that message catalog." You can think of a "message catalog" as a list of all the messages that a program will need to print out, and a "string" is just a message.

I've previously mentioned that I do a lot of work in open source software, much of it in the FreeDOS Project. I wrote a version of "catgets" for FreeDOS, so I think I can explain how catgets works:

Programs first need to open a "message catalog" before they can use it. This is done using the catopen function. The catopen function figures out what language you use and opens the right message catalog for that language. So programs have a different message catalog for each language they support.

The catopen function returns with a special code that the program can use to refer just to that "message catalog." A large program might use several message catalogs. But to keep things simple, I'll show you with just one message catalog.

Once the program has opened the message catalog, it can get messages from that catalog using the catgets function. For example, if the program wants to say "Hello" it gets that message (called a "string") from the message catalog. Each message (or "string") has a specific number assigned to it—actually, it has two numbers assigned to it, one number for the "message set" and one for the "message" itself. A program might put all error messages into one set ("1") and all information messages into another set ("2"). Let's assume the message "Hello" might be message 1 in in the "information" message set ("2").

Since catopen already figured out what language you want to use, catgets will always pick messages from the right language.

When the program is done, it needs to close the "message catalog" using a function called catclose.

To a programmer writing a simple program called "Foo," it all comes together like this:
catalog_number = catopen("Foo", MCLoadAll); /* You don't need to know what "MCLoadAll" means for this example */


string = catgets(catalog_number, 2, 1, "Hello"); /* In case "catgets" can't find message 1 in set 2, it just gives you "Hello" */

puts(string);


catclose(catalog_number);
And somewhere, the program has separate "message catalogs" for English, Spanish, German, … and so on.

Creating the message catalogs is fairly straightforward. Under catgets, this is actually a two-step process: write a file containing all the messages that your program will use, then use gencat to convert this into a message catalog that can be easily opened by catopen.

For example, a message file (foo.msg) might look like this:
$set 1
1 Error reading file.
2 Abort!

$set 2
1 Hello world!
2 I like pie.
In that file, error messages are in one set ("1") and all information messages are in another set ("2"). So message 1 in set 2 (information) is "Hello world!"

At the command line, the programmer can convert this message file ("msgfile") into a message catalog ("catfile") using the gencat command:
gencat catfile msgfile

Wednesday, September 11, 2013

What killed Linux on the Desktop

I recently found Miguel de Icaza's 2012 article, "What Killed the Linux Desktop." It's basically de Icaza's "exit memo" when he decided to quit open source software, and move entirely to Apple's Mac OSX. While I disagree with many of de Icaza's views, I wanted to provide an accurate summary of his article. de Icaza iterates two basic ideas that he believes went wrong on the Linux desktop:

1. The developer culture

In de Icaza's view, the problem with Linux on the Desktop is rooted in the developer culture that was created around it.
The attitude of our community was one of engineering excellence: we do not want deprecated code in our source trees, we do not want to keep broken designs around, we want pure and beautiful designs and we want to eliminate all traces of bad or poorly implemented ideas from our source code trees. 
And we did. 
We deprecated APIs, because there was a better way. We removed functionality because "that approach is broken," for degrees of broken from "it is a security hole" all the way to "it does not conform to the new style we are using."
In essence, de Icaza argues that the Desktop became a moving target. Developers created new ways to do things, and deprecated the now-outmoded methods. While this happens in proprietary software, as well, the cycle is often much shorter in open source software.

2. Incompatibilities between distributions

Fragmentation and differences between similar Linux on the Desktop implementations was also a major factor, according to de Icaza. "Either they did not agree, the schedule of the transitions were out of sync or there were competing implementations for the same functionality."

In de Icaza's view, having to support different desktop environments that were all "Linux" killed the ecosystem for third party developers trying to target Linux on the Desktop. You would try once, do your best effort to support the "top" distro (such as Fedora or Ubuntu) only to find out that your software no longer worked six months later.

de Icaza argues that few developers are interested in stabilizing and supporting a standard API. "Backwards compatibility, and compatibility across Linux distributions is not a sexy problem. It is not even remotely an interesting problem to solve. Nobody wants to do that work, everyone wants to innovate, and be responsible for the next big feature in Linux."


In short, de Icaza says Linux on the Desktop lost the race for a consumer operating system to the likes of Windows and Mac OSX, both of which have stable APIs that programs can rely on for many years. "Meanwhile, you can still run the 2001 Photoshop that came when XP was launched on Windows 8. And you can still run your old OSX apps on Mountain Lion."

While the various Linux on the desktops are the best they have ever been (Ubuntu and Unity, Fedora and GnomeShell, RHEL and Gnome 2, Debian and Xfce plus the KDE distros) yet we still have four major desktop APIs, each popular and slightly incompatible versions of Linux on the Desktop. Different OS subsystems, different packaging systems, different dependencies and slightly different versions of the core libraries. This model works great for pure open source, where an open source distribution can simply recompile programs to run on the new platform, but does not work well for proprietary code that need certain operating assumptions to remain true. Shipping and maintaining applications for these rapidly evolving platforms is a big challenge.

Thursday, August 29, 2013

With usability, everyone wins

Having demonstrated a usability test in my last post, where do we go from here? I hope I"ve shown usability should not be just tacked onto a project. Usability needs to be part of the design of open source software, and addressed as a process. As open source software developers, we are generally very good at applying good software development practices to our work. Now we need to take the next step and bring usability into that practice.

Our next challenge in open source software is to find ways to incorporate usability into our development culture. This is a big step. Most open source programs are written by developers for other developers. Developing features takes priority, and we rarely look at how users will try to access that functionality.

In open source software, the community plays a strong role in testing new releases. Unfortunately, left on their own with no structure to usability testing, open source software testers will respond with simple bug reports: “This feature is confusing.” That's not helpful feedback. Or, usability bugs may not be afforded the same status as functionality bugs.

The approach to identify usability issues in open source software, therefore, needs to be more structured. Open source software developers can apply a variety of methods, although the ideal would be to conduct formal usability tests at every major release.

Usability testing for open source software projects doesn’t need to be performed in a lab; a project can find ways to “crowdsource” usability testing with the user community. For example, the open source web content management system Drupal streamed usability testers as they undertook a usability test. This allowed Drupal developers all over the world to observe the usability test without having to travel to a single location. When open source developers can watch testers experience problems with the software, they better understand the issues and how to address them.

Another simple method is usability testing by “flash mob.” Just intercept people in a public space and ask them to try out a few scenarios and share their experiences. If your test subject is willing to spare a few minutes, and with a “mob” of individual testers and evaluators, you can glean valuable information in a short amount of time. This idea of “flash mob” usability testing can be extended to other domains, too. If your open source software is web-based, you might conduct similar impromptu usability tests by intercepting website visitors.

You don't have to be an expert to apply usability tests in open source software. Anyone can do it. You only need to watch users try to use the software, and usability issues will immediately become obvious. As few as five testers will give you consistent information that you can use to make your open source software even easier to use. With good usability, everyone wins.

Wednesday, August 28, 2013

My own usability test

To demonstrate the formal usability test, I reviewed three common open source software projects. I solicited advice here and on other forums, asking which open source software programs to test. Sorting through the suggestions, three open source software projects met the criteria for the usability test:

  1. Gedit (a text editor)
  2. Firefox (a web browser)
  3. Nautilus (a file manager)


I didn't ask for a specific level of technological expertise, as I was looking for typical users with average knowledge. In most formal usability tests, it’s common to give each tester a small gratuity; I gave out free pop and candy.

Seven people volunteered for my usability test. They ranged in age from about 20 to about 40, three men and four women. Most claimed “low” experience with computers, and almost all used Windows as their primary desktop. Each tester started with a fresh instance to test against: their own account on a laptop running Fedora Linux. Since everyone had a separate account, they started from the same “default” settings.

At the start of the usability test, I gave each tester a brief background. I explained that this was a usability test, so it was about the software, not about them. If the tester experienced problems during the test, that was okay and we could move on to the next section. I was there to observe their interaction with the software, not to judge. I would take notes and watch what was happening on their screen.

I also asked each tester to speak aloud what was going through their mind during the usability test. For example, if they were looking for a Print button, they should simply say, “I’m looking for a Print button.” And I encouraged them to track the mouse on the screen with their eyes so I could observe where they were trying to find menus and buttons.

During the usability test, I presented the testers with a number of scenarios, each providing a brief context and an action they were asked to complete. For example, after asking testers to navigate to the BBC News website in the Firefox browser, one scenario asked them to increase the font size for the site. Importantly, the scenario does not use the same wording as the menu action that applies the font change:
You don't have your glasses with you, so it's hard to read the text on the BBC News website. Please make the text bigger on the BBC News website.

Overall, the usability test included nineteen scenarios, which testers completed in 30-40 minutes.

So, what were the usability issues? Interestingly, almost everyone experienced the same four issues:

  1. Change the default font in Gedit.
  2. Change the default colors in Gedit.
  3. Create a bookmark or shortcut to a folder in Nautilus.
  4. Search for a file in Nautilus.

In Gedit, testers were very confused about how to set the default font and colors. Part of this confusion stemmed from thinking of the editor as if it were a word processor such as Microsoft Word, which uses icons on the toolbar to accomplish either action.

In Nautilus, testers became frustrated while trying to create a bookmark or shortcut to a folder (used for a project that collected photos, and was saved under the Pictures folder). The only user who successfully created the bookmark only did so by accident.

Similarly, most testers found searching for a file in Nautilus a difficult task. They did not realize that the Search function starts from the current folder, not from their Home directory. Only two testers were able to use Search successfully. Of these, one happened to click on the Search button from their home directory. The other tried changing options in the drop-down Search action until they eventually picked a combination that worked. One tester gave up with Search and simply navigated into each folder in turn to find the file they were looking for.

And while GNOME was not part of the usability test, almost all testers experienced difficulty with the GNOME “Activities” menu hot corner. In the GNOME desktop environment, the “Activities” menu shows the list of available programs plus a view of the running applications. Users can bring up the “Activities” by clicking the menu icon in the upper left corner of the desktop, or simply by moving the mouse into that corner (the “hot corner”). Usually right away in the first scenario, testers would “overshoot” the program menu they were looking for, and hit the GNOME hot corner. Although testers were able to recover from the hot corner, it caused frequent disruption throughout the test.

What worked well for usability? Throughout the test, I observed four themes of good usability that allowed all testers to quickly pass through those parts of the usability test:

1. Familiarity
Testers commented that the programs seemed to operate more or less like their counterparts in Windows or MacOS X. For example, Gedit isn't very different from Windows Notepad, or even Microsoft Word. Firefox looks like other web browsers. Nautilus is quite similar to Windows Explorer or MacOS X Finder. To some extent, these testers had been “trained” under Windows or MacOS X, so having functionality (and paths to that functionality) that was approximately equivalent to the Windows or MacOS X experience was an important part of their success.

2. Consistency
User interface consistency between the programs worked strongly in favor of the testers, and was a recurring theme for good usability. Right-click worked in all programs to bring up a context-sensitive menu. Programs looked and acted the same, so testers didn't have to “re-learn” how to use the next program. While the toolbars differed, all programs shared a familiar menu system that featured File, Edit, View, and Help.

3. Menus
Testers preferred to access the programs’ functionality from the menus rather than via “hotkeys” or icons on the toolbar. For example, the only toolbar icon that testers used in the Gedit scenarios was the Save button. For other scenarios, testers used the drop-down menus such as File, Edit, View, and Tools.

4. Obviousness
When an action produced an obvious result, or clearly indicated success—such as saving a file in the editor, creating a folder in the file manager, opening a new tab in the web browser—testers were able to quickly move through the scenarios. Where an action did not produce obvious feedback, the testers tended to become confused. The contrast was evident when trying to create a bookmark or shortcut in the Nautilus file manager. In this case, Nautilus did not provide feedback, failing to indicate whether or not the bookmark had been created, so testers were unsure if they had successfully completed the activity.

These are good lessons in open source software and usability. Your program's user interface doesn't have to be a beautiful impediment to understanding. Instead, leverage existing user interface paradigms: Be consistent with other programs on the same platform, whether other open source software or proprietary software. Use menus that are clearly labelled. Ensure every action has a result that is obvious to the end user, especially if that result indicates failure.

Monday, August 26, 2013

Applying usability tests to your own programs

Let's walk through a usability test, to show how open source software developers might apply this method to their own programs. Remember, the purpose of a usability test is to uncover issues that general users have in using the program. This is a practical test of its ease of operation, and as such differs from quality assurance or unit testing.

To start, define a set of written scenarios that represent how typical users with average knowledge would use the program. You aren't looking to test every feature of the program, just the tasks that most users would want to do. Make your scenarios realistic; provide a short description of each scenario and ask the tester to perform tasks within that context. Write scenarios that don't lead the tester by using the product's words for actions, especially if your typical users of average knowledge might not know those words.

For example, if you want to evaluate an editor, your scenarios might ask the tester to enter a short text document, save it, and make basic edits to the file. For a web browser, your scenarios could ask the user to search for a website, bookmark a site, or save a copy of a web page for offline use.

Invite testers for a usability test. You don't need very many people, five testers will give you great results. Give the tester one scenario at a time, each on a separate piece of paper, and ask them to complete the tasks. Observe what they do in the program: the routes they take to accomplish the tasks, and the problems they encounter. Take plenty of notes.

The most difficult part of a usability test is watching a tester struggle to locate a menu or button. While the right action may seem apparent to you, the value is in learning and identifying what is not obvious for a user. Do not give hints. If a tester is unable to finish a scenario, that’s okay; just move on to the next scenario.

At the end, ask followup questions of your tester. For example, you might ask “You seemed lost when you tried to do X, what would have made it easier?” Or perhaps “What were you expecting to see on the screen when you were doing Y?” As a wrap-up, ask the tester to describe what worked well in the program, and what features should be improved.

Friday, August 23, 2013

Applying Usability in Open Source Software

Open source software developers have created an array of amazing programs that provide a great working environment with rich functionality. At work and at home, I routinely run Fedora Linux on my desktop, using Firefox and LibreOffice for most of my daily tasks.

But as great as open source can be, we've all shared or heard the same comments about certain open source programs:

  • “___ is a great program … once you figure out how to use it.”
  • “You can do a lot in ___ … after you get past the awkward menus.”
  • “You’ll like using ___ … if you can learn the user interface.”

That’s the problem, right there. People shouldn't have to figure out how to use a program, aside from specialized tools. Typical users with average knowledge should be able to operate most programs. If a program is too hard to use, the problem is more likely with the program than with the user.

Most open source programs are written by developers for other developers. While some large open source programs such as GNOME and Drupal have undergone usability studies, most projects lack the resources or interest to pursue a usability evaluation. As a result, open source software programs are often utilitarian, focused on the core functionality and features, with little attention paid to the user interface.

So, how can open source developers easily apply usability to their own programs? It depends. Typical methods run the gamut from interviews and focus groups to heuristic reviews and formal usability tests.

However, such formal practices are often antithetical the open source software community. Open source developers mostly prefer functionality over appearance. While some projects may have a maintainer who dictates a particular design preference, most programmers view menus and icons as “eye candy.”

With that in mind, open source software developers should consider the usability methods that apply well to the culture of open source software development. I propose this list:

Heuristic review
An experienced usability expert reviews a program design, and presents a marked-up list back to the developer with suggestions for improvement.
Prototype test
Ask testers to evaluate a mock-up of a program design, even if that design is just screenshots on paper.
Formal usability test
Testers use the program according to a set of scenarios, and an observer notes where they have problems.
Questionnaires
Testers use a program against a set of scenarios, then fill out a questionnaire about what worked well and what should be be improved.

You don’t need years of usability experience to apply usability in open source software development. Developers can learn a lot just by sitting down with a few users and watch them use the software.

Whatever method you choose, the value of usability testing is doing it during development—not after the fact. Apply usability testing a few times; at each round of testing, you will have identified a number of issues that you can fix, and further improve your project.

Thursday, August 22, 2013

A parallel analysis via Molly Bang

I'd like to follow up on the user interface analysis via Molly Bang by way of analyzing a static image using Bang's methods. Bang’s method is well suited for interpreting imagery, providing a basis to evaluate shapes and patterns within an image.

For simplicity, let's analyze a webcomic that may be familiar to many of you: “Piled Higher and Deeper” (PHD) is a webcomic about life in academia. The artist and author, Jorge Cham, earned his PhD in Mechanical Engineering at Stanford University, and later became a full-time instructor and researcher at the California Institute of Technology from 2003-2005. Cham now works on the comic full-time.

The PHD comic website claims over fourteen million monthly pageviews and over one million unique monthly visitors. Readers to the PHD website represent over eight hundred different fields of study from over one thousand different schools worldwide. Comics get their topics out of the socio-cultural environment from which they originate and for which they are produced. PHD reaches a mostly internal audience of fellow academics and offers a rhetorical view about life in academia. Rhetoric is the set or system of principles regarding the functional application of conventional signs for the purpose of getting someone to think something or want to do something. The comics in PHD do not advocate a specific action, but do evoke an exigence to awaken its readers from complacency, stirring its audience out of a neutral state.

PHD comic #1436 The Evolution of Intellectual Freedom originally published 20 July, 2011, describes research choices at different times in an academic career. Ostensibly organized in a two dimensional chart, the webcomic represents research preferences for undergraduate students, graduate students, assistant professors, tenured professors, and emeriti professors. At each moment, a character expresses their optimism or pessimism towards research options; the undergraduate student and emeritus professor both claim they will “research whatever I want” while the graduate student, assistant professor, and tenured professor assert they will perform the research desired by others, such as the assistant professor’s tenure committee.


“The Evolution of Intellectual Freedom” presents these six moments in time without panels or frames. In comics, panels typically fracture both time and space, and gutters between panels allow the reader to connect these moments to mentally construct a continuous, unified reality. Instead, “The Evolution of Intellectual Freedom” uses the two dimensional chart as an outer frame to infer the passage of time, referencing graphs where a variable (on the vertical axis) is visualized over time (on the horizontal axis). Gutters are implied by the spaces separating the characters. The comic uses these scene-to-scene transitions to transport the reader across time in an academic career.

Now let's go back to Bang for the analysis. Molly Bang's book, Picture This, illustrates ten basic principles present in powerful pictures: Smooth, flat, horizontal shapes give us a sense of stability and calm. Vertical shapes are more exciting and more active; they imply energy. Diagonal shapes are dynamic because they imply motion or tension. The upper half of a picture is a place of freedom, happiness, and triumph, while the bottom half of a picture feels more threatened, heavier, sadder, or constrained; objects placed in the bottom half also feel more grounded. The center of the page is the most effective “center of attention.” It is the point of greatest attraction. White or light backgrounds feel safer than dark backgrounds. Pointed shapes are threatening, while rounded shapes or curves are secure or comforting. Larger object in a picture are perceived as stronger. Audiences associate the same or similar colors much more strongly than the same or similar shapes. Contrasts enable perception of patterns and elements.

Applying Bang’s method does not require all ten basic principles to examine “The Evolution of Intellectual Freedom.” Applying only a few principles permits interpretation of the image:

Diagonal shapes imply motion or tension.
The graduate student, assistant professor, and tenured professor are drawn using diagonal lines. The graduate student stoops over a computer terminal, with both his body and the monitor tilted on a diagonal. The assistant professor is depicted running, using diagonal lines to draw arms and legs. The tenured professor, while seated, suggests tension through an arched body and crossed legs, both on a diagonal. Even the emeritus professor and tombstone are drawn using diagonal lines, implying tension without motion.
The undergraduate includes some diagonal lines in his left arm posture, but otherwise is drawn using only vertical and horizontal lines. This is the only character who is without tension.

The upper half of a picture is a place of freedom, happiness, and triumph, while the bottom half of a picture feels more threatened, heavier, sadder, or constrained.
“The Evolution of Intellectual Freedom” uses the two dimensional chart as an outer frame. All characters are drawn on the bottom of the image, suggesting these figures are sadder or more constrained. The graduate student, assistant professor, and tenured professor reflect this in claiming their research interests are controlled by outside interests.

Audiences associate the same or similar colors much more strongly than the same or similar shapes.
No two characters in the comic share the same or similar colors. However, the emeritus professor and tombstone are both colored grey, suggesting the grave belongs to the emeritus professor. The relationship is further implied by the interruption in the emeritus professor’s statement, which connotes that the emeritus professor expired before he was able to conduct research according to his own agenda.
While audiences associate the same or similar shapes less strongly than the same or similar colors, shape does imply relationships between objects. The undergraduate and the emeritus professor are both drawn in the same pose: right arm extended and pointing upwards with a single extended digit, elongated round mouth, arched eyebrows, and pointed nose. This evidence suggests the two characters are the same person, young and old, before and after his professional career.

Sunday, August 18, 2013

User interface analysis via Molly Bang

I'd like to share some brief thoughts about how one might discuss user interfaces. Analysis about what "works" in user interface design might come from any number of sources. Jakob Nielsen is one obvious reference; Nielsen is an author, researcher, and consultant on user interfaces, especially Web usability, Web design strategy, and user-centered methodology. Janice (Ginny) Redish is another resource; Redish is a recognized specialist in plain language writing for the web user experience (UX) research, and consultant specialist in usability.

However, we may also base an analytical discussion of imagery on the work of American illustrator Molly Bang. Her book, Picture This, illustrates ten basic principles present in powerful pictures:
  1. Smooth, flat, horizontal shapes give us a sense of stability and calm.
  2. Vertical shapes are more exciting and more active; they imply energy.
  3. Diagonal shapes are dynamic because they imply motion or tension.
  4. The upper half of a picture is a place of freedom, happiness, and triumph, while the bottom half of a picture feels more threatened, heavier, sadder, or constrained; objects placed in the bottom half also feel more grounded.
  5. The center of the page is the most effective “center of attention.” It is the point of greatest attraction.
  6. White or light backgrounds feel safer than dark backgrounds.
  7. Pointed shapes are threatening, while rounded shapes or curves are secure or comforting.
  8. Larger object in a picture are perceived as stronger.
  9. Audiences associate the same or similar colors much more strongly than the same or similar shapes.
  10. Contrasts enable perception of patterns and elements.
(Bang, Molly. Picture This: How Pictures Work. San Francisco: Chronicle Books, 2000.)

Let me take a moment to briefly explore a few user interface concepts using Bang's principles:

Bang's principle that the "upper half of a picture is a place of freedom, happiness, and triumph" while "objects placed in the bottom half feel more grounded" (4) seems to be mirrored in the Mac interface vs the Windows interface. MacOSX places the "menu bar" at the top of the screen: File, Edit, View, etc. while both MacOSX and Windows locate the "action bar" at the bottom (MacOSX calls this the "Dock" while Windows labels it the "Taskbar," but both do essentially the same thing: represent currently-running programs, and provide a menu to start new programs). Mac users may relate to adjectives such as "freedom, happiness, and triumph" - and if they've ever wondered why, it may be because their program interaction is at the very top of the screen. GNOME 3 puts the "Activities" menu at the top of the screen - but it uses a black background (see next).

The idea that "light backgrounds feel safer than dark backgrounds" (6) is important in understanding why I decided to switch my "Aura-like" Xfce desktop from a dark theme to a light theme. I mentioned the darker colors made things more difficult to read, and the light grey theme ("Adwaita") provided much better visibility. But it was also a matter of not "feeling" right. With the dark theme, I sometimes felt lost. Changing to the light grey theme immediately changed my perception; things seemed easier to use, even when I had changed nothing other than the color. Interestingly, the black "Activities" menu bar in GNOME 3 may contribute to users' negative reaction.

That "rounded shapes or curves are secure or comforting" (7) may explain the recent (last five years?) trend with user interfaces to provide rounded edges. Of course, Apple's original Macintosh computer (1984) used rounded corners. Today, MacOSX and many Linux desktops (including GNOME 3) make use of rounded edges, both for the desktop and for program windows. Xfce and Microsoft Windows use "hard" corners for the desktop, but round corners for program windows.

Contrast (perception of patterns and elements, 10) and colors (associate the same or similar colors, 9) may be significant elements in successful user interfaces. I'll return to this idea in a later discussion.

Monday, July 29, 2013

Fedora 19 Xfce as a work desktop

I wanted to follow up on using Fedora 19 Xfce at work, and talk about the overall experience of running Linux as my work desktop. Consider this a "macro level" view into usability. Rather than focus on the particulars of a specific program, I'll address the suitability of Fedora 19 Xfce as a desktop replacement. Does Fedora 19 Xfce perform adequately as a work desktop? Does it contain the essentials for the day-to-day tasks in an office environment?

Note that I'm not discussing a home desktop in this post. At home, users might choose to run all kinds of software: games, educational or "edu-tainment" software, photo management, music, … as well as programs that folks in a office need to use: web browsers, file manager, and "Office" suite programs. The home desktop may require a deeper "dive" into software use. I'll leave that for another blog article, or maybe for a different blogger to respond to.

Before starting, I created a list of the programs I use on my Linux laptop. I conveniently divided the list into three sections: Regular use (daily, or more than weekly), Occasional use (less than weekly), and Rare (less than monthly). After moving to Xfce, I found that I didn't use some of these programs at all, where previously I thought I used at least occasionally.

In most cases, transitioning to the Xfce equivalent was transparent. Here's my list of Linux programs that I use now under Fedora 19 Xfce:

Regular use (daily, or more than weekly)
  • Web browser: Google Chrome*
  • File manager: Xfce Thunar
  • Office suite: LibreOffice*
  • Terminal: Xfce Terminal
  • Password manager: KeePassX*
  • Software updater: yum
  • PDF viewer: GNOME Evince
  • Flash plugin: Google Chrome Flash plugin
  • Dropbox (×)

Occasional use (less than weekly)
  • Radio: Tunein.com (via web)
  • Photos (×)
  • Text editor: Xfce Leafpad
  • Solitaire: Aisle Riot*
  • Calculator: Galculator
  • Graphics: GIMP*
  • Drawing (×)
  • Viewer: Evince*
  • Scanner (×)

Rare (less than monthly)
  • Programmer's editor (×)
  • Emulator (×)
* marked items were installed separately; except for Google Chrome, these were part of Fedora 19, but not included by default in Fedora 19 Xfce.

A few notes:

It's not surprising that I haven't yet installed (×) several programs that I use only occasionally or rarely; after all, I've only been using Fedora 19 Xfce for about two weeks. In reflecting on the programs that I actually need, I probably will only bother installing a program (SimpleScan) that lets me use my scanner. I sometimes need to scan things, but I prefer not to manage personal photos (Shotwell) on my work laptop, and I don't do vector drawing (Inkscape) anymore. I also am taking a "time out" from some of my other open source software work, so I don't currently need a programmer's editor (GNU Emacs) or DOS emulator (DOSemu). When I eventually need them, those programs are easy to install.

I also don't use Dropbox anymore. I haven't even bothered to install Dropbox on Fedora 19. I originally installed Dropbox to try it out for work, so I could experiment with "cloud storage." But I have only used Dropbox to make backup copies of a few personal files. We have a "private" cloud storage system at work, and I use that for all my important files.

While I use Google Docs for almost everything, sometimes I need to print out a Word file or Excel spreadsheet that someone sends to me. If the file is very big, I may prefer to use LibreOffice to view and print the document, rather than opening it in Google Docs and printing from there. In that respect, LibreOffice is only an office viewer in my day-to-day work.

Under GNOME, I used Rhythmbox to listen to Internet radio stations. I usually like to stream music from HBR1, but it turns out there's a channel for that on TuneIn.com. Now I just open a new tab in my web browser, and click on my bookmark to listen to music while I work. (You can also stream directly from HBR1.com, but TuneIn lets me listen to other stuff, as well.)

The only GNOME program I continue to use under Xfce is GNOME Evince (technically, Galculator and a few others are compiled using GNOME libraries, but aren't GNOME projects per se, and work fine under Xfce). Evince has a nice user interface for viewing and printing PDF files, much nicer than other PDF viewers I've tried.

Does Fedora 19 Xfce perform adequately as a work desktop? Does it contain the essentials for the day-to-day tasks in an office environment? I think the answer to both is yes. I can do everything I need to do under Fedora 19 Xfce. Less technical folks would have an easier time, I think; most users do not need a terminal or password manager, for example. The Xfce desktop is easy to navigate, and programs are easy to use. Everything listed above has good Familiarity, Consistency, Menus, and Obviousness. My only complaint is that installing printers is confusing.

This was an interesting diversion into a specific desktop use case, exploring Xfce at a "high level" view to see how well it performs as a desktop replacement. However, I prefer to use this space for exploring OPEN SOURCE SOFTWARE & USABILITY, so I don't expect to return to this topic again on this blog.

Thursday, July 25, 2013

Using Fedora 19 Xfce at work

Allow me to expand on my previous post about Fedora 19 Xfce and usability. Going beyond merely the usability of the Xfce desktop, how does it perform at work? Since I've been using Fedora 19 Xfce for about two weeks, I thought I'd share some thoughts about Fedora 19 Xfce at work. While this isn't a typical topic for this "Open Source Software & Usability" blog, Linux aficionados may appreciate my views on using Fedora 19 Xfce as a day-to-day office desktop.

I opted not to attempt a "dual boot" configuration on my work laptop. If this were my home machine, that might be a different story. But at work, I didn't want to mess with the standard desktop; as a CIO, I don't want to make things more difficult for our support staff.

Fortunately, we had an unused external USB drive. It's a little old, but perfectly suitable to boot Linux. It was a fairly straightforward affair to connect this spare drive to a spare laptop to install Fedora 19 Xfce.

1. The install program has poor usability.

Fedora used to have a very simple, easy-to-use installer. You answered a few simple questions using point-and-click or drop-down menus, then the installer did everything else for you.

In the Fedora 19 installer, everything has changed. (Actually, I believe this changed in the Fedora 18 installer.) The installer now presents a warning label that the disk doesn't have enough room. When I clicked into the disk setup tool, I was given the option to "reclaim" space, but I really didn't understand what that meant. There was no button or other option to just "install," despite the fact that I planned to install only Linux on this drive. If I were a user with "typical" knowledge and "average" skill, I would likely be afraid to use this installer, lest it do the wrong thing.

The installer's progress bar is equally confusing. Usually, when a program displays a progress bar and a message to indicate the percent complete (such as, "Installing … 50%") you might expect the progress bar to indicate the same "percent complete" as the text message. Not so during the Fedora 19 installation. The installer displayed a message that it was installing system software, and it was "50%" complete, yet the progress bar displayed something like two-thirds complete. I quickly decided not to trust the progress bar. And it's a bad sign when your users decide not to trust your software.

The installer is a Fedora issue. My recommendation to the Fedora Project folks is to reconsider the new installer, and try to move back to a more streamlined installer that can be easily used by a user with "typical" knowledge and "average" skill.

2. Adding printers is confusing.

After installing Fedora 19 Xfce on the external drive, I rebooted into the desktop. Things went very well until I tried to add a printer.


The process was awkward, almost "klunky." You'd think adding a printer would be done under the "Printer" menu item. Not so; you must click the giant "+" icon. While I eventually figured it out, the action wasn't immediately obvious. Not a major obstacle, but menus would help. The user interface for adding printers needs some work.

3. The desktop works well.

Overall, I am very satisfied with how Xfce performs as a modern desktop. A user with "typical" knowledge and "average" skill should be able to easily navigate the Xfce desktop. Unlike GNOME, programs in Xfce use menus. Everything worked pretty much the same, and menu items had obvious actions and responses.

To be fair, I understand that GNOME does have a menu, located in the top bar next to the "Activities" menu. This isn't an obvious place for a menu, since it separates the menu with the program that uses it. That's an interesting UI decision for GNOME. I would argue GNOME fails the Obviousness criteria here, where Xfce succeeds.

4. Installing programs isn't obvious.

Once I installed Fedora 19 Xfce, I realized not all my favorite programs were installed by default. For example, I chose to install Evince (a PDF file viewer), GIMP (a graphics program), Google Chrome (web browser), KeePassX (a password manager), and LibreOffice (an office program). I needed to download Google Chrome separately, and I knew that, but the others were optional packages in Fedora 19.

There's no obvious menu item for "Add new programs" or "Install Fedora 19 packages" or something similar. Eventually, I tried the "Yum Extender" program, remembering that "yum" is a command-line package manager program that lets you install or remove packages. But "Yum Extender" doesn't accurately describe the action that it performs.

Once I ran "Yum Extender," it was fairly easy to install the new packages I wanted. But I'll admit that I used "yum" on the command line to install the Google Chrome package; that was easier than figuring out how to install a local package from "Yum Extender."

In a future post, I'll share some thoughts about the programs themselves.

Fedora 19 Xfce and usability

Fedora 19, codenamed "Schrödinger's Cat", was released on July 2, 2013. After about a week, I finally installed this on my laptop to explore the usability in Xfce. I've previously mentioned that Fedora has lost me. Before giving up entirely, I tried the alternate Fedora Xfce distribution, and found I liked it.

Since I've been using Fedora 19 Xfce for about two weeks, I thought I'd share some thoughts on the desktop. First, let me acknowledge this isn't the default Xfce desktop; I've applied a few changes. Here is my current desktop:


It's no secret that I love the "Aura" desktop on Google's Chromebook / ChromeOS. The Aura desktop has a simplified look that is both easy for new users and flexible for power users. Aura provides very good usability: The desktop is familiar to both Windows users and Mac users, and the desktop functions more or less like the desktops on these other platforms. Since (almost) everything in the Chromebook runs inside the browser, programs share consistent behavior. Menus are not immediately visible, but are available. Actions provide obvious feedback.

Overall, if the Aura desktop were available on a "stock" Linux distribution and had the ability to launch local programs like LibreOffice or a terminal, it would be a great desktop for most folks.

So while I like the usability in the Xfce desktop, I like the usability of Aura a lot more. But if you are technically capable, you can dramatically modify the appearance of Xfce to make it look and act like anything - like Aura. And I've modified my Xfce desktop to something similar to the Aura desktop. It works really well and I find it is even easier to use than the default Xfce desktop.

You may notice I have "tweaked" the desktop settings from my previous modifications. A few differences:
I'm using a light grey theme instead of a dark grey theme. The other theme was great for a few days, but the darker colors made things more difficult to read. This light grey theme ("Adwaita") provides much better visibility.
I've added a volume control ("Audio Mixer") next to the Notification Area.
I modified the clock style so it also displays the date next to the time. I sometimes need to look up the date, and this saves me the step of having to hover my mouse over the clock to display today's date.
I changed the Applications Menu icon to be a series of three lines, instead of the "3x3 grid." Icons are metaphors for things or actions, and the "3x3 grid" icon works well for the Aura desktop because Aura's Application Menu is presented as a grid of available applications. But Xfce's Application Menu is a hierarchical list, so the "3x3 grid" icon didn't accurately represent the action. In my mind, I didn't associate the "3x3 grid" icon with the Application Menu, even though I gave it that icon. But the series of three lines ("view-list-symbolic") provides a more accurate metaphor for the action it instantiates.

Otherwise, I find the Xfce desktop to be very pleasant. While I haven't done a formal usability study of Xfce, my heuristic usability evaluation is that Xfce meets all four of the key themes for good usability: Familiarity, Consistency, Menus, and Obviousness. The menus are there, and everything is consistent. The default Xfce uses a theme that is familiar to most users, and actions are obvious. Sure, a few areas still need some polish (like the Applications menu, and some icons) but Xfce already seems pretty solid.

Friday, June 21, 2013

Linux is faster than Windows

It's not really part of the "open source software & usability" sphere, but I found this ZD Net article very interesting: an anonymous Microsoft developer admits Linux is faster than Windows. While I generally am skeptical of "anonymous" sources, I find this one credible.

The article also highlights the strengths of the open source software model: By working collaboratively in the open source software model, developers resolve issues that a single programmer might find impossible. An open source program can quickly grow from an interesting proof of concept used by only a few developers to a mature, stable application that benefits many general users.

Here are a few snippets from the anonymous developer that I found most insightful:
Granted, occasionally one sees naive people try to make things better. These people almost always fail. ... See, component owners are generally openly hostile to outside patches: If you're a dev, accepting an outside patch makes your lead angry (due to the need to maintain this patch and to justify in shiproom the unplanned design change), makes test angry (because test is on the hook for making sure the change doesn't break anything, and you just made work for them), and PM [project manager] is angry (due to the schedule implications of code churn). There's just no incentive to accept changes from outside your own team. You can always find a reason to say "no", and you have very little incentive to say "yes".
There's also little incentive to create changes in the first place. On linux-kernel, if you improve the performance of directory traversal by a consistent 5 percent, you're praised and thanked. Here, if you do that and you're not on the object manager team, ... your own management doesn't care.
In order for open source software to thrive, it requires excellent and open communication among all its participants. Open communication breaks down barriers, allowing people to collaborate as peers. And communication in several forms is critical to the success of open source software. Through this interchange of ideas, developers work together for rapid and continual improvement.

As the anonymous developer mentions, in open source software projects, developers are congratulated and praised for improvements. Open source communities are generally a meritocracy anyway, where the best ideas rise to the top through peer review and open discussion. However, proprietary software such as Microsoft's tend to operate in a more defensive mode; unplanned changes (even improvements) are not welcome.

It's no surprise that Linux and open source software outpaces Windows in performance. Now we need to do the same with usability and user experience. That's one reason I started this blog, to study and discuss usability in open source software.