Hi Lutz, hi community! As requested, I would like to share my thoughts with you concerning the UX project proposal. Your introductory e-mail addressed many of my perceptions and concerns of the last years. Therefore I'd like to answer in more detail and by giving some randomly chosen examples that relate to OpenOffice.org.
INTRODUCTION Generally, the idea of being user centered is very good – no matter if the project is called UI or UX, if it is an incubator project or already an accepted one. At the moment, it is my impression that user related topics cannot be appropriately discussed. That's a pity, because of the numerous changes that have been done towards and after OpenOffice.org version 2.0. Originally, many of these changes were intended to attract a broader user base by providing more features or by easing the use. Some of the modifications do not seem to attain the goals (see beneath). MISSION / TASKS My ideas what could be worked on or what just could be supported are stated below. Please note that this list is not exhaustive. It is just a start... a) Collect Ideas Collect ideas by directly asking users, work with the marketing people, evaluate other software, formulate ideas out of forum discussions or create significant user surveys. b) Evaluate Ideas Check the obviousness, completeness, ... of new ideas or specifications that already exist at Sun. The ideas that have been successfully evaluated may be transformed to the feature specifications (or something similar). c) Evaluate the Usability After the well discussed features/changes have been implemented, a final evaluation could be carried out. This is just to ensure that the specification fits well to the user's needs and their mental model. d) Review of the current state Similar to point c), the current design should be continuously reviewed. This may be necessary to take advantage of new possibilities like new control elements or new operating system techniques. One (heavily stressed) example is a careful and meaningful use of desktop animations provided by 3D acceleration. Additionally, users may be influenced by a general design change of home components. This changes their “reality” and we may have to update OpenOffice.org to fit their expectations how some things should work. Finally, the tasks mentioned above cover topics of both requirements engineering and requirements management as well as user centered design. INFRASTRUCTURE a) Wiki I would propose a shared wiki for the common development and the discussion of well-defined topics (e.g. “New feature 'Online Update Information'”). If these discussion turn out to be complete, feature specifications or Issuezilla change requests could be derived for the implementation. b) Mailing list Additionally, a separate UX mailing list should be provided to ease the exchange of ideas. Optionally, it could be used to announce new feature specifications which can be reviewed by the community. c) Issuezilla (optional) I'm not sure about the next one: I'd like to see some kind of Issuezilla topic to collect issues that cover the perception of the user. I hope an hypothetical example makes this more clear: Maybe some users think it is a good idea to edit their document in the view “web layout” to remove the unwanted spaces between the pages. But they insist in having a direct link to open the print preview. (By the way: print preview is disabled during “web layout”.) Maybe they do not understand why they first have to change to the “print layout” view just to check their final page layout. I think that this (I said it...) example is not really an pure UI issue. At this time the users may want to provide their impressions. I don't think that the difference between UI/UX is obvious to the general user who is willing to provide feedback via Issuezilla. Therefore it may be possible to keep “UI” topic. An alternative could be to encourage users to send their comments to the UI mailing list. d) Personal Meeting (optional) Another idea that I thought about is to have some kind of regulars' table. By experience, the discussion of UI/UX topics is easier (to me) if some people can discuss the ideas/issues together in one place. I'm sure this is a bit critical considering the international development work in the project. But if somebody living in the region of Stuttgart (Germany) is interested in... NECESSITY Hereafter, I have stated some subjectively selected examples of the current design of OpenOffice.org based on the everyday experience. You may skip them if you like ;-) Please note that I use the German version of OpenOffice.org. Therefore I'm not sure if all the UI translations I made are correct. Sorry for that in advance! One additional comment: These examples were not selected according to their nitpicking factor. a) Learning Curve / Consistency / Usability 1. I know that the “formatting brush” is known as huge improvement in OpenOffice.org 2.0. From my point of view, the only reason to include this function was to compete with Microsoft Word. Sadly, users of Word are often over-strained by the use of formatting tools due to their complex design. I think that was the reason for Microsoft to invent this tool. From now on the users could copy and paste their formatting. Even though I don't like this approach this feature may be possible to attract everyday Word users. On the other hand, OpenOffice.org features a similar feature called “watering can (paint bucket)” in the stylist window. It is used to “flood” text with the current paragraph style or text style. The previous procedure in OpenOffice.org pre 2.0 was to create a new style (even from the selected text) and to “flood” it to the text. It don't think that the difference between “brush” and “watering can (paint bucket)” is too obvious... 2. An example for less consistency is the “Document Recovery” dialog that appears after the crash of OpenOffice.org. I have no clue why there is a white stripe with an additional sub-title between window title bar and the actual dialog. 3. An example for missing usability may be the newly designed dialog for the links (Link below). The buttons at the right side are e.g. evenly spaced. The order of the lower two buttons is “Help” and “Close”. In contrast to that, the dialog for managing document templates (File -- Document template -- Manage) does contain a button order that begins with “Close”, then “Command” and after that “Help”. Other dialogs like “Format Characters” (Format -- Characters) do have a horizontal button layout “OK”, “Cancel” and “Help” at the bottom. One world, three choices ;-) (Link: http://specs.openoffice.org/appwide/links_dialog/links_dialog.sxw) b) Attractiveness of OpenOffice.org Some of the dialogs look quite dated. They seem to be unchanged since StarOffice 3.0 (or even before, but I can't prove that) and were designed to fit on low resolution screens. Today, the attractiveness and usability may be improved by a new layout or even a complete new task procedure. An example for a good dialog is the fresh “Search/Replace” dialog (Writer: Edit -- Search & Replace) that offers a really good button layout. The minimum disadvantage is that there is there is no clue which special characters for regular expressions are available. The user needs to open the help (two clicks and some scrolling to go) to get information on the placeholders. An example for an dialog that really needs some polish is the “Load templates” dialog (Can be accessed by opening the stylist window -- New template from selection... -- Load templates). c) Relationship to other application software Sometimes it may be necessary to identify similar features in other application software and to provide procedures or additional help to ease the familiarization process for the user. d) Relationship to various desktop systems Another necessity could be to work with other community members which use OpenOffice.org or some components in other projects. Some ideas were stated below: 1. Ubuntu Linux for example uses OpenOffice.org. Sometimes it would be a good idea to discuss system wide settings like key bindings that may interfere with the ones in OpenOffice.org. If this happens he may blame OpenOffice.org for the bad help text that describes the key bindings. 2. Manage the button order of e.g. “OK” and “Cancel” for the Gnome users. At the moment their Human Interface Guidelines define a “reversed order” (in contrast to Microsoft Windows or KDE). CLOSING WORDS I really hope that nobody is offended by the examples I gave. I just wanted to share some of my overall impressions to explain my thoughts... Of course, it will be necessary to discuss/criticize the ideas stated above. By the experience of my job, the challenging part of UX will be to serve all the people and their different needs. Therefore it will nearly never be possible to satisfy everyone. But that's why it's a great opportunity for us. Finally, I'm really looking forward to work with you! ... Presuming your acceptance ... ;-) Best regards, Christoph Am Dienstag, den 16.01.2007, 13:04 +0100 schrieb Lutz Hoeger: [...] > I would like to propose an OpenOffice.org User Experience (UX) project. [...] > Please feel free to share your thoughts on this proposal. Again, I would > like to have the discussion taking place at the mailing list > [EMAIL PROTECTED], but I will summarize and cross-post to [EMAIL PROTECTED] > and users@ as > appropriate. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
