Lutz Hoeger
Contents
On our way to build up a vibrant User Experience community
Sun's StarOffice User Experience (UX) team is about to evolve into an OOo UX community. Some small steps already have been taken (feature specifications, guidelines, etc.), but these are all rather dispersed, and the "glue" is still missing. Even more important, so far this is a Sun-only activity, and the community hasn't been involved yet.
That's why Stefan Taxhet and I met to discuss steps towards founding or becoming part of an OOo UX community. We didn't finish, and I would like to open the discussion at this point, to get broader feedback and to involve more people.
When thinking about these steps, I am always keen to know, how we can find out if any of the steps is successful, how we can measure success. Also, I would like to distinguish between steps that lead to real contributions vs. steps that just generate "activity" but do not contribute directly to the product or project OOo. With contributions, I do not refer to code contributions, but to anything that the Sun UX team contributes to the normal development process of StarOffice (specs, competitive analyses, usability tests, ...; see User Experience Community here).
The following are steps, Stefan and I came up with, and an initial attempt to classify them into {A} for activity vs. {c} for contribution. There is no particular order yet.
One last remark, regarding my use of the terms "User Experience" vs. "User Interface" and "Usability": "User Experience" (UX for short) embraces the latter two, and goes beyond them. It includes the full scope of how a (potential) user gets in contact with the product OOo, installs it, uses it, gets support and everything. This is a wide scope, and I would like to restrict it to product related UX, and exclude as much of UX related the OOo project (e.g. the web site) as possible in this context.
Steps to Create a Vibrant OpenOffice.org User Experience Community=
UX Project
- Do we need a separate UX project on OOo?
- Pro: A separate project is a well established mechanism for an interest group to identify themselves with the subject.
- Pro:
- Con: UX is a very tightly integrated part of the development process. Most of the UX work takes place when changing or developing features, so most of the actual results are captured elsewhere already (e.g. in specifications or issues). It doesn't make sense to duplicate this work.
