User Experience/Improved Options
|
|
|---|
|
Quick Navigation Team Communication Activities |
Contents
Introduction
History
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...
Problem
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).
Proposal
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... :-)
Requirements
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
|
| (ID) | (Requirements Text) | (Source) | (Description) | New |
| Searching for the Place to Change the Options | Look up and open the options dialog(s). | |||
| (ID) | (Requirements Text) | (Source) | (Description) | New |
| 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, ...). |
New
|
| 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." |
New |
| (ID) | (Requirements Text) | (Source) | (Description) | New |
| Changing an Option | Changing the value of an option to adapt OpenOffice.org to fit the personal needs. | |||
| (ID) | (Requirements Text) | (Source) | (Description) | New |
| Applying an Option | Making a changed option active. | |||
| (ID) | (Requirements Text) | (Source) | (Description) | New |
| 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. | (Source) | 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? |
New |
| 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. |
New |
| (ID) | (Requirements Text) | (Source) | (Description) | New |
| Protect Options from Being Changed | Protect some options from being changed accidentally or restrict changes for some users. | |||
| (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 |
| (ID) | (Requirements Text) | (Source) | (Description) | New |
| Getting Help on Options | Understanding what certain features are used for. | |||
| (ID) | (Requirements Text) | (Source) | (Description) | New |
| Exchanging Options with Other Users | Exchaning settings with other user, e.g. importing/exporting a set of configuration settings. | |||
| (ID) | (Requirements Text) | (Source) | (Description) | New |
Competitive Analysis
(to be added)
Definition of Terms
(to be added)
Design Proposals and Mockups
(to be added)
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 adquate 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 to make OpenOffice.org the office suite which fits to the user's needs!
