Difference between revisions of "Lutz Hoeger"

From Apache OpenOffice Wiki
Jump to: navigation, search
m
(Moved "Build up a Vibrant User Experience Community" to an own page)
Line 1: Line 1:
[[User Experience Community]]
+
I belong to the [[User Experience Community]].
  
==On Our Way to Build up a Vibrant User Experience Community==
+
My current projects (as of Oct 20, 2006) are
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.
+
* [[Build up a Vibrant User Experience Community]]
 
+
* Project Without a Name (landing page & more)
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===
+
* 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 conrtent 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
+
  
 
[[Category:User Experience]]
 
[[Category:User Experience]]

Revision as of 10:50, 20 October 2006

I belong to the User Experience Community.

My current projects (as of Oct 20, 2006) are

Personal tools