Difference between revisions of "User experience/Community/Build Up a Vibrant Community"

Revision as of 09:41, 1 November 2006

This page is still in DRAFT status. It hasn't been finished yet.
If you'd like to contribute to it, please feel free to do so! 
--Lutz Hoeger 09:00, 23 October 2006 (CEST)

On Our Way to Build up a Vibrant User Experience Community

Sun's StarOffice User Experience (UX for short) 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.

So why would we want to change this? And why now?

• The OOo development process becomes generally more open, which is documented by activities like GullFOSS. UX engineering is closely tied to the development process, and as we open the entire process, UX needs to happen more publicly, too.
• There have always been great offerings for UX engineering from the community, but no central point to coordinate them, no single point of contact to get an overview about what's required, etc.
• The OOo developer community grows, and so does the demand for UX engineering. Patch issues are a good example for this: Sun's UX team has supported quite a number of submitted patches lately, with the number growing continuously.
• People are actively asking for an OOo UX community, like Pierre-André on his blog

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 involve more people and to get broader feedback.

When thinking about such steps, I am always keen to know, how we can find out if any of them are successful, and how we can measure success. Also, I think it makes sense to distinguish between the results. Some are real contributions vs. others that are "just" activity but do not contribute directly to the product or project OOo. With contributions, I refer to anything that the Sun UX team contributes to the normal development process (specs, competitive analyses, usability tests, ...; see User Experience Community).

The following are some steps, Stefan and I came up with, and an initial attempt to classify them ({A} for activity, {C} for contribution). There is no particular order yet, and the list is probably incomplete. Feel free to add whatever you think is missing.

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. 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 project related UX, i.e. the user experience of the OOo web site etc., as far as possible in this context.

Steps Towards a Vibrant OpenOffice.org User Experience Community

UX Project

• http://ux.openoffice.org
• Do we really 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: This would be a good place to capture any general work, like guide lines.
  • 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, and there may not be sufficient content and traffic to justify an own project. Projects with no news and no own content are bad.
• Classification: ? worst case: neither {A} nor {C}, best case: a lot of {A} that leads to many {C}
• Goal/Measure: Measuring just activity (like subscribers or people who post something) doesn't tell too much about how much value is contributed to the product. Measuring contributions may be subject to individual rating - some may find a guideline usefull, where others don't need it or maybe even have a conflict.

HCI Guidelines

• Designing the OOo user interface involves guidelines. Some of them are tied to the platforms on which OOo is supposed to run (and to look and feel non-alien), and some are OOo-specific. So far, many of the latter exist in our brains only. Transforming these into documents and make them available to any OOo UI developer seems to be suited well for a collaborative approach.
• Classification: {C}
• Goal/Measure: number or ratio of guideline docs (co-)edited by non-Sun people

Design Meetings

• Sun's UX team used to have Design Meetings, to present current projects. The meetings were used for discussing open design issues, brainstorm about alternatives, and to simply get re-iterate on the existing design, by looking at them from a wider angle. Such meetings could be conducted online, too.
  • Pro: Easy to jump into existing design discussions without having the need to read through the entire project history first.
  • Pro: There is a fair chance for our designs to become better, the earlier people can give feedback.
  • Con: The discussions may turn to arguing about taste only and not produce any result.
• Classification: {A} primarily, {C} only if sucessful
• Goal/Measure: ?

Blogs

• Classification: {A}

Mailing Lists / Web Forums

• A web forum provides more persistence and is more open than a mailing list
• Classification: {A}

To-Do List

• Product and project contributions
• Classification: {C} primarily, {A} only if sucessful

IIT / IRT for UX

• to be explained further
• Classification: {A}

Specs

• to be explained further
• Measure: Non-Sun spec authors (Won't work, more about this later)

i-Teams

• to be explained further

Usability Tests

• to be explained further
• Classification: {C}

RFEs

• to be explained further

How do Other Open Source Projects Deal With Usability?

• Fedora: http://fedoraproject.org/wiki/Usability