Lutz Hoeger

From Apache OpenOffice Wiki
Revision as of 09:34, 20 October 2006 by Lutz Hoeger (Talk | contribs)

Jump to: navigation, search

User Experience Community

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.

So 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 here).

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

  • 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: 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.
  • Classification: ?
  • Goal/Measure: ?

HCI Guidelines

  • Designing the OOo user interface involves many guidelines. Some of them are tied to the platforms on which OOo is supposed to run (and to feel non-alien), some are general but OOo-specific, and some - probably many - so far exist in our heads only. Transforming this into written documents 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

  • to be explained further
  • 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
Personal tools