ooo ux project? and general confusion
By mprove on Dec 06, 2007
// just wrote this in response to a thread on the project leads list
I cannot fight the impression that this thread is somehow related to the User Experience project on OOo. Let me try to catch up and start with a response to Bruce:
I was just looking around the UX project site. What is the role of this project in OOo development? It seems to me like they have some good ideas*, and I would love to see some of this in OOo 3.0. But if they're not now a formal project, do they actually impact development?
Well, we are part of the game. Each iTeam that works on a feature which impacts the user interface has a user experience engineer on board. We propose and design menus, dialogs, UI strings, interaction flow and take care for the consistency across the application. In doing this we represent the user in order to deliver a new feature that makes sense and is usable.
This is happening for years, at least since the specification workflow was formally introduced for OOo 2.0. In January this year we started to build up a user experience community on OOo, because there is much more to do than the original StarOffice User Experience Team could handle. Today, the 50th members joined our group. And some of them have already contributed to new features in OOo ? new notes and 2 page layout come to mind. (BTW . I wrote an article for a British HCI magazine: "User Experience for OpenOffice.org") As you can see, the incubator status for our project does not limit our effectivity. But you are right, after nearly a year we should propose to the community to change our status to 'accepted'.
...just because they allow for a lot of contributions without going into the process of discussing on the issue or understand the spec process.
Discussions on our list email@example.com are an important forum to exchange ideas and to learn from each other. From time to time specifications are posted and discussed in order to improve the design and to share the knowledge how to deal with specifications. They are the single most important tool to gain influence on the shape of OOo. I consider inspiring discussions -- sometimes even pushing the envelope beyond current constraints -- a necessary phase to provide guidance for future OOo development. It has nothing to do with not "understanding the spec process".
So everything is great? I suppose not.
The User Experience team should contribute to the grant concepts and vision for OOo. Where Kay was doing this bottom up -- User Experience has to provide the top down vision. For example, using File-Open to launch an extension does not fit into the user's mental model of an application. This needs to be discussed and considered, and even user tested. The radical component based approach sounds also compelling, but without designing a coherent surface for the user, OOo might fail like Apple's OpenDoc framework did in the past. We've done a poor job in explaining our role to the OOo community. That's why the Community Council at OOoCon had nothing smart to say when it came to UX. (OOoConCommunityCouncilQA.odt) Once more: I consider it our (UXTeam's) fault not to have sufficiently informed the community about our activities and potential contributions.
Another thought by Kay:
But what customers don't know can't be required by them. Even (very) big companies failed in the market (completely) while they were extensively listening to their customers
We miss the feedback of those professionals who offer services, development and support around OOo. They should be members of the user experience project to point the needs and what the future should be. By interacting with developers, who have the technology knowledge and the future of it, this could lead to good new features because they are between both.
Yes, acknowledged and agreed. User Experience can support the requirements engineering process. Either by just doing it or by educating others, maybe from OOo's marketing project. Kay is right. Users know about their daily tasks in the office. But this does not make them experts who create concepts and visions for their tools. Whenever you talk to them, shut up your mouth and listen. Say "Thank you!", go home, and consider what you have *not* heard. That's the sweet spot of user research.
(BTW - this is also the reason why I do not find the results from user surveys very useful.)
So, we may want to make ease-of-use part of a vision ... or is it a constraint? ;-)
Sure, this is an sarcastic statement. This question wouldn't even come to my mind. Usability and usefulness (and robustness and performance and accessibility) should be key to OOo.