User Experience/Improved Options
- 1 Introduction
- 2 Requirements
- 3 Design Proposals and Mockups
- 4 Status and Roadmap
Some weeks ago, a discussion started whether an option, which was estimated to be used rather seldom, could be removed from the „Tools – Options“ dialog (refer to email). This options dialog contains different settings for the current document, the OpenOffice.org modules and OpenOffice.org in general.
The dialog's complexity is the reason for discussing the removal of options regularly, which seem not to be essential for normal users and may be placed in the configuration files. Most often, there is no final decision if an option can be safely removed from the UI. This also happened to the „XML beautifier“ setting and so the options dialog stays untouched and keeps horrifying beginners and less advanced users...
See OOo 2.4 Options for the current list of options.
This complexity is why there is a need for a complete redesign of the OpenOffice.org options. Currently, the options are located in both the options dialog and configuration files with even more advanced configuration settings.
Let's assume we have different users with different skills. Those skills represent the position in the learning curve (examples for both skill level and some kind of scenario):
- User A: just a user (options are rarely used, only for providing user data like name and company)
- User B: very experienced user (needs the „XML beautifier“ to post-process the OOo files)
- User C: administrator (who wants to configure OOo in detail for the corporate network, e.g. disabling automatic online update)
Currently, the options dialog seems to address user types A and B at the same time. Unfortunately, user A might a bit overwhelmed by the sheer amount of options (there were enough examples for that). So what the main problem is, that we today only have 2 points in the learning curve (as discussed before, UI and config files).
The improved options dialog should try to "hide" some of the options for user type A, but make it available for the user B (e.g. "Advanced Options..."). For user C there is no problem at all, people like system administrator will invest effort to configure the system. So it is proposed to introduce another "point" in the learning curve, which may look like this:
So the steps height for accessing more functionality is reduced. User A might become more experienced by time and then try the advanced options. At least, there is hope for that... :-)
Scope of the Work
From experience, one product can hardly satisfy the different user's needs and is therefore configurable. The main goal of the activity Improved Options is to improve the the access and understandability for beginners, whereas the full functionality will be available for experienced users.
The grouping of options and their defaults will consider all known issues/disadvantages of the current design. Nevertheless, the current functionality of the options will not be part of the discussion and all today's features will be kept (e.g. adding single options by extensions).
If possible, the proposed solution will consider new interaction techniques / interface design to meet or outperform the competition.
The developed solution will respect the development resources available (e.g. providing a roadmap for step-by-step implementation). The outcome of this effort will be a detailed design proposal (e.g. structure of options, behavior description, mockups), which will be the basis for a future development specification.
Issues and Requests for Enhancements
Simple issue query searching for "tools" and "options" in several data fields of the component "framework".
Requirements Derived from Use Cases
The following list is intended to collect the requirements for the improved options. Please refer to the following example wiki page how this may look like at the end and how it works. To add another requirement, please:
- Think! Is this really a requirement which would be demanded (wished / required) by users? If yes, then please proceed...
- Get your own ID. Search for the highest number (e.g StR 6) in the subsequent list and increment it (e.g. StR 7) to use it for your requirement. At last when it comes to discussions in emails, this will ease to reference to your requirements idea.
- Use the template. For ease of use, a small template representing one line in the table has been added in the wiki source code. Please copy it and fill in your values (please don't overwrite it, because the other community member cannot benefit from it).
- Describe carefully! Please consider that your requirement has to be understood without any other explanations. So please don't hesitate to add the 'rationale', comments, information sources or other products implementing the desired feature. Sadly, the best idea is lost if it cannot be understood by strangers.
|ID||Use Case / Requirements Text||Source||Description||Status|
|General / Constraints||General requirements like accessibility or framework limitations.|
|StR 3||The user wishes, that the options are provided in his native language (options: e.g. options itself, settings, additional information).||Christoph||The options should be translatable / translated for users who are not capable of speaking English.||New|
|StR 5||The developer requires, that options can be added to the user interface providing the options.||Specification "Options Dialog for Extensions"||(Description)|| New
|Searching for the Place to Change the Options||Look up and open the options dialog(s).|
|Lookup a Desired Option||Searching up a desired option to be changed.|
|StR 2||The advanced user wishes, that the options dialog provides the ability to search for options (search: text based search for e.g. keywords or names).||Issue 81495||
It is assumed that advanced users remember the special wording inside the options and therefore do benefit from a search interface implemented into the options dialog (benefit: efficient lookup of settings). Implementation example: Search-as-you-type may find options by their names, settings, data types, descriptions, ...
|StR 4||The user requires, that the options dialog provides the ability to look up options in a hierarchy.||Christoph||
From experience it is known that some users strongly prefer a hierarchical structure instead using search functionality or looking through a plain list of entries. Therefore a hierarchy should be provided to group the options (grouping: e.g. according their functionality, the area which is affected, ...).
|StR 6||The novice user requires, that the he is able to clearly distinguish what part of OpenOffice.org will be affected by the given options (part: e.g. current document, all documents).||Mail 2008-07-10 by Frank||
Frank states in his mail: "... having a current document category. This is a major issue today, because nobody outside knows whether an option is a document or application setting."
|Changing an Option||Changing the value of an option to adapt OpenOffice.org to fit the personal needs.|
|Applying an Option||Making a changed option active.|
|StR 9||The user would like the ability to see the outcome of changes made in the options menu before closing the options menu||Issue 67133||
In the current options menu, users can make changes to things, such as the UI, which don't take affect (become visible) until after the options menu is closed, requiring the user to open and close the menu until the desired result is achieved.
|Reverting an Option||Revert an options value to e.g. the default value or restore the previous setting.|
|StR 7||The user requires, that he is able to revert selected options to the previous setting.||Christoph|| Some users may choose an option which is inadequate, but don't remember the previous ("safe") setting. It must be possible to revert the setting of options (or a part of them) to the previous setting. Previous setting means, the setting which was valid after applying the current setting of this option(s).
Open questions: Does that mean that the settings have to "survive" e.g. a restart of the computer?
|StR 8||The user wishes, that it is possible to revert selected options to the default settings (default setting: "factory setting").||Christoph||
Some users may "play around" with some options and not be able to figure out what kind of initial settings they had. So it seems to make sense to provide a functionality to revert the options (or a part of them) to the "factory setting". The "factory settings" describes the configurations settings available after a clean install of OpenOffice.org.
|StR 10||Users would like to be able to easily "save" and "load" options settings.||Jaron and Issue #?||
Some users want multiple options settings (a multilingual user for example).
|Protect Options from Being Changed||Protect some options from being changed accidentally or restrict changes for some users.||
|StR 12||Users don't want their settings to change when OOo has a version update.||Jaron and Issue #?||
When a user updates the OOo version the options menu resets to the default, "factory" settings.
Open Question: How would we handle "saved" options when versions add new or change current options?
|(ID)||(Use Case / Requirements Text)||(Source)||(Description)|| New
|Collecting Personally Interesting Options||Help the user to collect a list of options which are interesting for the user (e.g. for managing a set of regularly accessed options).||
|StR 1||The advanced user wishes, that options can be tagged with personal tags (personal tags: text tags provided by the user).||Mail 2008-07-12 by Leonard||The user may wish to add personal tags to the single configuration options to ease searching for them. Tagging can be assumed to be a generally known for structuring information.||Idea|
|StR 14||The average user wishes, that options he or she uses most often may appear in a popular options menu.||by Jaron (based on UI popularity options from other programs and the web)||Options the user changes most often could be displayed on the default option screen upon opening so the user has the quickest access to those options he/she uses most often.||Idea|
|Getting Help on Options||Understanding what certain features are used for.|
|StR 13||The user wishes, that the options functionality provides explanation on each option item (provides: either directly visible or accessible).||Mail 2008-07-22 by Jaron|| Implentation ideas:
|Exchanging Options with Other Users||Exchanging settings with other user, e.g. importing/exporting a set of configuration settings.|
|StR 11||Users would like to be able to transfer their options settings to other computers.||Jaron||
Users may desire to transfer their settings to additional computers. Computer system technologists may want to set multiple computers option settings during installation.
(to be added)
Definition of Terms
(to be added)
Design Proposals and Mockups
If you want to discuss the mockups, please add your comments right below it or start discussing it at on ux-discuss.
Proposal for the Advanced Options Handling
The rough proposal presented below focuses on advanced options instead of providing much insight how the basic options might be made available. It contains the basic structure of the advanced dialog and an example how searching could look like (rather wireframe like instead of being art).
This proposal attempts to stay simple while providing powerful features for even the basic users (tags, search, reset, etc.). It also attempts to not hide the features deemed unnecessary, but rather sort them so that the basic user with certain needs can pick them out easily and the user without those needs can easily ignore them. Furthermore, it uses only one dialog for users of varying skills to avoid inconsistency and possible confusion.
Status and Roadmap
Currently, the brainstorming season is on. Please add your ideas, your design proposals and future user interface mockups. In the next step, we will have to rate the requirements and the ideas and select an adequate design solution. If we (in terms of the OpenOffice.org community) are able to provide a satisfying proposal, then it has been promised to get support for the development of the improved options functionality (refer to email). Until we get close to development, a roadmap is not necessarily needed.
Thanks for helping us make OpenOffice.org the office suite which fits a user's needs!