Görkem Çetin, Mehmet Göktürk
“When you have only two pennies left in the world, buy a loaf of bread with one, and a lily with the other.” :Chinese proverb
Desktop-based open source operating systems, particularly Linux, have come a long way since the introduction of Linux 0.10 in 1991 and the first Linux distributions in early 1992. Linus Torvalds, the founder of Linux, started to market the usability of Linux version 0.10 when he wiped his data by autodialing to hard disk, overwriting the operating system with dial strings. While such usage scenarios are far from reality in today’s world, open source projects (particularly those focused on developers and administrators) and open source applications traditionally suffer from usability problems and a lack of user-centric design.
Several other factors have had a critical role in completely ignoring, or heavily limiting, the UCD approach in the Free/OpenSource software (F/OSS) community. Apart from the limited usability of X Window, the F/OSS community started focusing on end users with the launch of the KDE (K Desktop Environment) and GNOME projects. Communicating with end users and understanding their needs and their approach to computer usage introduced completely new problems for the F/OSS community. Moreover, since the early days, the F/OSS community has succeeded by relying only on its internal competences. With the advent of F/OSS desktop computing, the situation quickly changed, requiring a completely new set of skills. Interface design, visual communication, and information architecture became mandatory concepts for a winning desktop environment.
For the past three years we have investigated various project mailing lists, blogs, and bug-reporting tools. We conclude that usability in a distributed and collaborative project is formed through five major items:
- A collaborative environment and a set of tools to strengthen the communication of the project stakeholders
- A hierarchical, well-defined decision path that facilitates communication
- A trust-based relationship model between developers, users and HCI experts
- An initiator capable of making early design decisions
- An HCI expert with a background in user-centered design
Toward Institutionalized Usability Efforts. For the past 10 years, there have been many attempts to unify the standards of open source desktops. Backed by industry efforts, KDE and GNOME desktop environments are adopting similar formats for desktop entries, configuration files, or menu frameworks. While GNOME and KDE have very different origins with separate widget sets, libraries, and aims, we see the first steps toward one-desktop environment with a unique target of interoperability between two environments. However, there is room for improvement: The Qt library KDE depends upon flickering problems solved this August, and there are still issues with drag-and-drop protocols between GNOME and KDE applications after standardization efforts.
Institutionalized usability is gaining momentum in open source projects. Conducting studies in-house that are not tied to returning code to the community can produce results and reduce community discussions that are sometimes excessive. De Icaza, the developer of the GNOME user interface, mentions that usability isn’t something that’s sprinkled onto the project in the final stagesindeed, it must be part of the development process itself. The OpenSUSE (Novell) team has undertaken a three-month usability study with 60 test people comprising 13 tasks, which was the first of its kind after 15 years. Dan Winship, the UI architect of Novell, states:
”[...] If we had proposed the changes on the mailing lists, it would have started a huge discussion about what people hated about the design and how it should be different. And then we could have either (a) completely ignored everyone and done it ourselves anyway, or (b) had a long conversation about the merits of the design and then not actually finished the code in time for NLD10. Everything good in GNOME is good because one person or a small number of people working closely together made it good. Much of what is bad in GNOME is bad because lots of people have contributed without having a single vision of what the end result is supposed to be.”
According to Winship, endless debates that result in unwritten code harm the usability process of a product. Instead, designing with a small team is better for handling the usability issues in software with a unified vision.
How To Work Together? Our investigation shows that 27 percent of all bugs submitted to the KDE bug repository between 2004 and 2005 are in fact usability bugs. The high volume of requests, wish lists, and bug entries suggests a need to secure the help of a usability expert. Reitmayr and Mühling define three basic problems slowing development that get introduced if a user-engineered approach is employed. After working with several projects in openusability.org, their findings show that usability is still an unsolved issue in F/OSS: missing hierarchical decision paths, no definition of target users, and no definition of target users’ tasks and requirements all continue to be problems.
Even usability experts and end users reporting bugs for a Linux distribution face problems while taking an active part in Pardus Linux, a government-led Linux distribution developed by the Turkish National Institute of Electronics and Cryptology. Our two-year development and investigation on the Pardus project reveals that developers traditionally focus on technical features rather than spending their valuable time on emotional and interaction design. Occasionally, a strict time plan for marketing automatically reprioritizes the planned aims, requirements, and the list of bugs to be eliminated for the next release. Usually this prioritization is in favor of adding new features and not the proper handling of UCD process. Although this problem also occurs in institutionalized projects, F/OSS seems to suffer more.
According to Krysztof, the intended audience of most of 500 active F/OSS projects on Sourceforge are developers (67 percent), end users (62.2 percent), and system administrators (29 percent).
Most of the time, when we talk about usability, we particularly focus on a specific software application and not a set of applications. On the other hand, a Pardus Linux distribution contains slightly fewer than 700 applications, including more than 120 graphical applications installed on the desktop. Among these, only 5 percent of all applications are developed in-house. Each application presumably has a different author, project Web page, bug-reporting site, and mailing list, which should be tracked by distribution developers. Here we face the issue of covering usabilityi.e., when a user issues a bug report, this bug may or may not belong to one of the applications developed inside the institute. If this bug is connected upstream, then the developer should interact with the upstream developer for UI amendments. Most of the time, however, this process takes a long time, discouraging the distribution developers from solving these kinds of problems. Despite these issues during the development process, Pardus Linux is dubbed as “one of the most innovative Linux distributions focusing on usability” in many reviews worldwide.
Who You Gonna Call? (Usability-Bug Busters) Current remote usability methodologies lack a coherent, out-of-box solution that can be deployed in an organization for distributed, open source development. There have been attempts to develop tools that focus on the technical area. However, there’s a clear need for a social and collaborative usability space. Krietzberg proposes to create a collaborative knowledge space that could leverage the integration of research and practice and encourage interactions across disciplines. Such a knowledge space could also help the integration of usability experts and F/OSS developers and provide theoretical, practical, and speculative information about F/OSS usability. As Fred Sampson asks, “Who you gonna call?” This depends on whether we can define our collaborative environment and simple rules of communication between HCI experts and F/OSS developers in the near future.
There are still many unexplored areas in this field, leaving us with many questions: How can interaction designers work online with F/OSS developers? What kind of tool will help them collaborate effectively? How does early contribution or late involvement of usability engineers affect the project itself, outcome quality, or project duration? Still, many questions remain unanswered, and each deserves to form its own research area.
2. Çetin, et. al. An Analysis of Involvement of HCI Experts in Distributed Software Development: Practical Issues. Online Communities and Social Computing, ed.Douglas Schuler, HCI International 2007, LNCS 4564, 32-40. Springer, 2007.
5. Muehling, J., and E. Reitmayr. “Integrating Usability with Open Source Software Development: Case Studies from the Initiative OpenUsability.” Workshop proceedings, tOSSad Workshop on Governmental, Educational, Usability, and Legal Issues towards Open Source Software Adoption in an Enlarged Europe, Como, Italy, 2006. 65.
Turkish National Institute of Electronics and Cryptology
Gebze Institute of Technology
About the authors
Görkem Çetin is project manager at the Turkish National Institute of Electronics and Cryptology, Pardus Linux developer in the same organization, and a Ph.D. candidate at the Gebze Institute of Technology. He spent more than 14 years as an open source developer, trainer, mentor, and manager in various organizations.
Mehmet Göktürk is an assistant professor at the Gebze Institute of Technology in Turkey. His primary interests are usability, novel input devices, and attentive interfaces. He worked as a research associate at The George Washington University Human Computer Interaction Research Group.
©2007 ACM 1072-5220/07/1100 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2007 ACM, Inc.