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

Latest revision as of 17:55, 24 February 2008

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 10:14, Dec 15, 2006 (CET)

Somewhere in the middle of writing I got stuck. In fact, I felt like getting far too detailed before the big picture becomes clear. So I decided to take an alternative approach. The very first thoughts about this project - the original content moved down a little, and I kind of start over with the big picture first.

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

Building up a vibrant user experience community on OpenOffice.org

Steps Towards a Vibrant OpenOffice.org User Experience Community

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 analysis, usability tests, ...; see User Experience Community).

The following are some steps 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.

UX Project

• e.g. http://ux.openoffice.org
• Would we want to take over the existing UI project http://ui.openoffice.org, or shall we create a new project?
• Do we actually 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 guidelines.
  • 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 useful, 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.
• Platform guidelines are the easier part, I guess, because they are somewhat static. So what we need is just a plain list of existing platform design guidelines, like Windows UI huidelines, GNOME guidelines, Apple HIG, JLF, ... (see UI Style Guides).
• To a large extent, OOo-specific guidelines exist in people's mind only. Putting them into documents and making them available to any OOo UI developer, is what we need to do here (see User Interface Guidelines).
• 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 discuss current design projects. The meetings were used to discuss open design issues, brainstorm about alternatives, and to simply re-iterate on the existing design, by looking at it from a wider angle. Such meetings could be conducted on-line, 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 successful
• Goal/Measure: ?

Blogs

• Today, blogs are amongst the more popular ways to tell others about any news. Though there is a lot of activity in the blog space, I don't think any real contributions (i.e. deliverables like patches, specifications, guidelines, etc.) come from there.
• Classification: {A}

Mailing Lists / Web Forums

• Mailing lists still are the #1 communication channel for members of a project.
• Non-members (i.e. non-subscribers) can browse archived mailing list content through a web interface.
• Maybe a web forum provides even more persistence and is more open - easier accessible - than a mailing list
• This is similar to the blog thing above. Mailing lists may be better suited for discussions. But typically won't deliver any contribution in the sense of deliverables.
• Classification: {A}

To-Do List

• What needs to be done in the UX space? And what is currently going on?
  • Major development projects requiring UX support?
  • ToDos within the project (site maintenance, etc.)
  • Upcoming events: IRC meetings, design meetings, etc.
• Classification: {C}

IIT / IRT for UX

• This is plain metrics, measuring the initial response time and the issue inactivity time (IIT). Both for patch issues only, so far. Maybe want this for any kind of issues, including RFEs in particular. And of course, specific to to the UX project.
• 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

User Research

• Usability test data, reports and videos
• Site/Customer/User visit reports
• Personas
• to be explained further
• Classification: {C}

RFEs

• to be explained further

How do Other Open Source Projects Deal With User Experience?

• Drupal: http://drupal.org/contribute/usability
• Fedora: http://fedoraproject.org/wiki/Usability
• Mugshot: http://developer.mugshot.org/wiki/Design_thinking
• Tango-project: http://tango.freedesktop.org/
• Better Desktop (Novell/OpenSUSE): http://www.betterdesktop.org/wiki/index.php?title=Main
• GNOME: http://developer.gnome.org/projects/gup/, last modified Apr 2006
• NetBeans: http://ui.netbeans.org/index.html, last modified Jan 2007