British HCI group User Experience for OpenOffice.org

Matthias Müller-Prove in interfaces 71, Summer 2007

Introduction

Open source software (OSS) is a paradigm for developing software in a non-proprietary fashion by leveraging virtual communities of independent software engineers. Within these communities, software engineers share source code, contribute new features, and provide bug fixes and patches to a common code base. Eric S. Raymond provided the framework for OSS development in The Cathedral and the Bazaar by discussing the motivations and the social context of individual developers (Raymond 1999). The first rule of open source development is also the reason for an inherent usability problem: “Every good work of software starts by scratching a developer’s personal itch.”

The result is a self-referential system – developers develop for themselves rather than for the average user or the target audience. Usability engineering is considered as superfluous extra (cf. Nichols/Twidale 2003). However, to provide a good user experience, it is the user’s itch that needs to be scratched.

This article presents user experience activities in the context of OpenOffice.org. The author – co-lead of the User Experience Project – will discuss the status of building an open source community of usability professionals to improve the usefulness and usability of the application.

OpenOffice.org

OpenOffice.org is the leading open source office suite with about 85 million downloaded copies world wide. Since Sun Microsystems open-sourced StarOffice in October 2000, OpenOffice.org has become available for all major platforms and has been localized for almost 100 languages. The real size of the community is hard to measure. However, there are 62,000 registered mailing list subscribers, and 720 organizations signed the Joint Copyright Assignment to actively support the project (Goldman/Gabriel 2005, 131). One of the most important accomplishments is the development of the XML-based OpenDocument format (ODF) for text documents, spreadsheets, presentations, and drawing files. ODF became an ISO standard in 2006 and is further discussed by a technical committee at OASIS.

For many years Sun has sponsored a team of user experience professionals to work on StarOffice and OpenOffice.org. We have created a specification work flow process that governs the participation of engineering, quality assurance, user documentation and – last but not least – the user experience expertise for the development of each feature. Only when all representatives of the “implementation team” (iTeam) agree on design and code, can the modification be integrated into OpenOffice.org’s master build. The contributions of the user experience team are competitive analysis, dialogue and interaction design, UI terminology reviews, and in many cases writing the specification document. To that extent user experience is very well integrated into the development processes of OpenOffice.org.

In addition to competitive analyses, we conduct usability tests and perform site visits to distil overarching goals for the product. Despite the fact that these can be very time-consuming activities, they are necessary to bring us into a position to play a significant role in defining the strategy for the product. Speaking practically, user requirements can only be based on actual user data, which is collected with usability studies and user research.

User Experience Project

Quite recently – in January 2007 – a new User Experience Project was approved by the community. The main objective is to consolidate usability activities that are currently scattered all over the project in concept documents, specifications, the bug-tracking system, newsgroup discussions, private e-mail conversations, etc., and to create a visible and active open source community of usability professionals and interaction designers for OpenOffice.org.

The communication infrastructure has been rolled out: We have a home page, a wiki, a mailing list and an internet relay chat (IRC) channel for discussions. Furthermore, we blog on Sun’s engineering weblog for OpenOffice.org.

The official home page is located at the subdomain ux.openoffice.org. The way this site is hosted makes it a bit cumbersome to grant wide write access in a way that fosters contributions. Therefore we use a wiki as a space that invites people to collaborate on topics that matter to improve the usability of OpenOffice.org. The third channel of communication is our mail alias. This medium is well suited to actually drive discussions because mail messages are literally pushed to the subscribers. Last but not least, blog postings to Sun’s engineering weblog GullFOSS are tagged with “user-experience”. They inform the entire community and have the potential to attract new members from the blogosphere to our project.

All this integrates seamlessly with OpenOffice.org’s existing infrastructure, which makes us a good community team player. In other words, we do not require any special procedures to collaborate with other members of the community.

On the other hand, this might be the reason why it is so difficult to approach and join an existing open source project for people other than engineers. We are aware of this issue and try to be very clear about the scope of our project and how it is presented on the web.

User Experience Community Outreach
User Experience Community Outreach

Community Building

According to Esther Dyson, there are four basic principles, that need to be observed for any community to prosper. Otherwise the group can collapse. She says (Dyson 1998, 49):

To a certain extent, building a community is user-centred design. To choose to join and contribute, usability professionals who are interested in our open source project need to understand who we are, what we are doing, and how we communicate with each other. Therefore, user experience has an identity stated in a charter on our home page and expressed with a logo on every page that belongs to us. A membership list on the wiki makes us distinct from a casual gathering, and a ToDo list – also on the wiki to foster participation – shows the current issues for the team.

Although we are in the early stages of building the usability community for OpenOffice.org, the future looks promising. Since our inception, the number of participants who have expressed interest in the project has increased by a factor of four. Thus, compared to Sun’s user experience team of five usability experts for OpenOffice.org, the current project has 20 experts signed up. It turned out to be a good idea to announce our project at OpenUsability.org (Mühlig 2006), because a couple of people signed up after OpenOffice.org was added to the platform and started looking for usability support.

Accomplishments and Challenges

During the past five years the StarOffice User Experience Team has established a good reputation among the engineers and other stakeholders. Our contributions are rarely seen as unneeded effort that slows down the development process; rather, they are viewed as an important element that improves the usability of the product for our users. A series of usability tests – conducted by Sun during the development of StarOffice 8 / OpenOffice.org 2.0 – has convinced even the skeptical engineers that we contribute valuable and actionable usability issues to the tracking system. In addition to the daily work on iTeams, the creation of application specific guidelines has started to keep consistency among the modules of the office suite.

Despite our usability work becoming part of the open source process, we must continue to ensure that the user experience team remains responsive and agile. As new people join the project, they bring new user experience objectives and methods to our team, possibly even shifting our focus. Integration of new views should be seen as a positive change that increases our ability to improve OpenOffice.org for the end user.

Compared to the open source projects NetBeans and GNOME (Benson et al. 2004, Benson 2004) four challenges remain: (1) A proper definition of OpenOffice.org’s target audience is missing. User research might deliver scenarios and typical use cases, or even encapsulate site-visit data as personas supporting feature development. In general, requirements engineering is an area that needs more emphasis in the future to be well prepared for planning the next release.

(2) Concept workshops can also be effective, especially if all participants are at the same location. If they are conducted in a remote situation, brainstorming sessions with fast concept scribblings cannot be applied successfully. This is a challenge for any work group, and a distributed user experience team is no exception. The upcoming OOoCon 2007 in Barcelona will be a good opportunity to fill this gap.

(3) We are also looking for a collaborative, visual space to support a distributed team of user interface designers. As Bill Buxton said at CHI 2004, “a sketch without a social life is not a sketch.” Some kind of electronic cork board is needed to expose mockups and future design studies to foster innovation among the user experience team (cf. Goldman/Gabriel 2005, 274) and to stimulate the attention of OpenOffice.org’s engineering and steering committees.

(4) Finally, the specification process needs to be adjusted to allow open source participation. An additional wiki version of the specification template is a step in this direction.

Summary

The user experience community is a newly formed team with a growing significance for OpenOffice.org. We collaborate with the existing teams like marketing, development, QA – just to name a few – to improve the usability of the office suite. On the other side, we are still in the early stages of building the community itself; hence we have to continue to attract usability professionals to the project and to incorporate their points of view.

References

All URLs accessed in April 2007.

à propos

Incomming Links

By Matthias Müller-Prove. Created April 2007, Modified: 5/1/20