Options Guideline
Document History
[September 17, 2002] Version 0.1 -- Inception
[September 26, 2002] Version 0.2 -- Public Draft
Table of Contents
Introduction
This document is meant to be a quick start guide explaining the basic concepts
of the Options System Redesign. More details about the contents of the redesign
can be found in the accompanying documents.
References
The Base Options Spec describes the main contents
of the Options System. The Advanced Options Spec
describes how the Advanced Options Dialog should behave and the Options
User View describes more user action details and system semantics details.
Concepts and Interaction
There are two major changes in the redesign that affect how options are handled
and what needs to be done to integrate successfully into the new system:
- The Division of options into Base and Advanced categories
- The use of customers to manipulate and present Base Options
The first change, dividing options into two categories, affects what options
will be presented to the user straight away. By default the user will see Base
Options and only after a gesture (clicking on a button) will Advanced Options
be revealed.
Base Options are defined as those options necessary and useful for the
user to successfully work within the IDE.
Advanced Options are those options that are obscure or seldom used in
the IDE.
Each module writer needs to analyze module options and develop an understanding
of how the different options are used. In general, the Base Option set should
be kept small; however, a small number of Base Options should not come at the
expense of making the user look in Advanced Options regularly.
Advanced Options should provide a way to affect every aspect of the
environment -for users who wish a high level of customization. Base Options
should provide all the functionality to get work done in a reasonable way.
In either Base or Advanced Options all options are categorized by a tree structure
on the left of the dialog. The Options Category Tree provides categories
that are user task centric. Where are particular options comes from is not as
important as the role it plays in solving a user's problem. To that end the
Options Category Tree should reflect names and structure that deal with the
objects a user is looking to act on.
The second point, that Base Options will be presented in customizers affects
the amount of effort needed to integrate a module into the new options system.
Using a customizer facilitates:
- clear communication of what options are through improved naming schemes
or in-panel text
- better interaction for options with interdependencies
- a more familiar interface for selecting, and editing configuration data
As the number of Base options grows the amount of work to design and implement
the options panels and any supporting business logic grows as well.
Two varieties of Options customizers, or panels, exist.Dedicated Panels
contain options from only one module. Shared Panels are campsites that
contain panels from different modules. Shared Panels may represent options from
a variety of different sources -the general Environment
Options panel is one example -or it may consist of options for one functional
group that happens to be implemented in several modules as XML support is.
Shared Panels may have additional common UI elements that enable navigation
through the various panels included. Navigation between shared panels is done
with a combo-box as in the Fonts and Colors panels.
Module Semantics
The Options System is designed to be flexible with the module architecture
of NetBeans. That said, it is also intended to be tailored for the particular
use of the IDE. Each release of NetBeans will include a review of the options
included and their presentation. The addition or subtraction of modules will
result in interface changes of varying magnitude. This is markedly different
from the current approach where options can be removed or subtracted for the
property sheet model with little attention to the UI.
When a new module is added to the system it can either:
- add a category to the Options Category Tree, or
- add a panel to a Shared Panel (thereby add itself to an existing category).
Adding a new category can be done anywhere in the Options Category Tree; either
a root node, a leaf node or anything in-between. This is up to the module developer
to work out what location fits well into the system and best suits the user's
expectation and task.
An options panel that gets added to an existing Shared Panel will need to be
designed to fit within the available space of the Shared Panel. When this fails
a combo-box will be added to the Shared Panel to navigate through each of the
options panels. If a navigation combo-box is already present then the new options
panel is added to the choices and no other visual change is made.
In reverse, removing options from the system first removes the panel from the
category. If the category is then empty the category is removed from the Options
Category Tree.
Options Guidelines
For UI guidelines refer to the Java Look and Feel Guideline and the NetBeans
UI Guideline.
There are few considerations that need to be covered when designing options
panels.
- bring all task related options into one panel
- consider option interactions -options that interact should be on the same
panel and never divided between Base and Advanced Options
Additionally, all options panels need to provide:
- category information
- a name for use in a combo-box (it may not be used but it must be available)
