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

From Apache OpenOffice Wiki
Jump to: navigation, search
 
m (Improve Category Sorting)
 
(35 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
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!
 +
--[[User:Lutz Hoeger|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==
 
==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 ([http://specs.openoffice.org/ feature specifications], [http://wiki.services.openoffice.org/wiki/User_Experience_Community#Guidelines 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.  
+
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 ([http://specs.openoffice.org/ feature specifications], [http://wiki.services.openoffice.org/wiki/User_Experience_Community#Guidelines 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 [http://blogs.sun.com/GullFOSS/ 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 [http://devadventure.blogspot.com/2006/10/usability-collaboration-in.html Pierre-André on his blog]
  
−
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.
+
[[Image:Build_Up_User_Experience_Community.png|center|thumb|Building up a vibrant user experience community on OpenOffice.org]]
  
−
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.
+
<br style="clear:both" />
  
 
==Steps Towards a Vibrant OpenOffice.org User Experience Community==
 
==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===
 
===UX Project===
−
* http:/ux.openoffice.org
+
* e.g. http://ux.openoffice.org
−
* Do we really need a separate UX project on OOo?  
+
* 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: 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.
+
** 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 conrtent are bad.
+
** 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}
 
* 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.
+
* 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===
 
===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.
+
* 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}
 
* Classification: {C}
 
* Goal/Measure: number or ratio of guideline docs (co-)edited by non-Sun people
 
* Goal/Measure: number or ratio of guideline docs (co-)edited by non-Sun people
  
 
===Design Meetings===
 
===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.
+
* 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: 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.
 
** 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.
 
** Con: The discussions may turn to arguing about taste only and not produce any result.
−
* Classification: {A} primarily, {C} only if sucessful
+
* Classification: {A} primarily, {C} only if successful
 
* Goal/Measure: ?
 
* Goal/Measure: ?
  
 
===Blogs===
 
===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}
 
* Classification: {A}
  
 
===Mailing Lists / Web Forums===
 
===Mailing Lists / Web Forums===
−
* A web forum provides more persistence and is more open than a mailing list
+
* 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}
 
* Classification: {A}
  
 
===To-Do List===
 
===To-Do List===
−
* Product and project contributions
+
* What needs to be done in the UX space? And what is currently going on?
−
* Classification: {C} primarily, {A} only if sucessful
+
** 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===
 
===IIT / IRT for UX===
−
* to be explained further
+
* This is plain metrics, measuring the [http://eis.services.openoffice.org/patchreport/irt_index.html initial response time] and the [http://eis.services.openoffice.org/patchreport/iit_index.html 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}
 
* Classification: {A}
  
Line 55: Line 85:
 
* to be explained further
 
* to be explained further
  
−
===Usability Tests===
+
===User Research===
 +
* Usability test data, reports and videos
 +
* Site/Customer/User visit reports
 +
* Personas
 
* to be explained further
 
* to be explained further
 
* Classification: {C}
 
* Classification: {C}
Line 61: Line 94:
 
===RFEs===
 
===RFEs===
 
* to be explained further
 
* 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
 +
 +
 +
[[Category:User Experience|Community/Build Up UX 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?

Retrieved from "https://wiki.openoffice.org/w/index.php?title=User_experience/Community/Build_Up_a_Vibrant_Community&oldid=67779"
Personal tools