Draft of Looks UI Design
Author: Ian Formanek
$Revision: 1.1 $
Document History: available in
CVS
- Abstract:
This document briefly describes Looks API from the perspective of
user-level concepts and discusses possible ways to use it and
visualize it in the NetBeans IDE's user interface.
- Contents:
- 1 Introduction & Requirements
- 1.1 Brief overview of Looks API
- 1.2 Benefits of using Looks
- 1.3 Things to be careful about with Looks
- 2 User View
- 2.1 Non-solution
- 2.2 Proposed Solution
- 2.3 Scenarios
- 2.4 Terminology
- 3 System-Wide UI Impact
- 4 Mockup of possible NetBeans 4.0 UI
- 5 Notes
Looks API is a new API which was introduced in experimental stage in
NetBeans 3.3 timeframe, and is planned to be made stable and part
of NetBeans APIs in NetBeans 4.0 release.
So what are those Looks? In short, Looks provide the ability to
change the appearance and behavior of any Node in NetBeans.
The things that are possible to change are:
- Display name
- Icon
- ToolTip (short description)
- Properties
- Children (subnodes)
- Customizer
- Actions in Popup Menu
- Default Actions (invoked on double-click)
There are 2 possible usage scenarios:
- Extend current Node's capabilities - e.g. the I18N module can
add a new PropertySet to nodes representing Java sources.
This PropertySet (tab with properties in the PropertySheet)
would contain properties specific to internationalization
for that particular Java source.
- Provide completely new Look for a Node that can quite
dramatically change the way the Node looks and behaves.
E.g. in a situation where some module provides just basic
functionality for certain data type visualization/editing,
a new module providing extra advanced functionality could
provide its own Look that replaces the basic one (or is
available as a second available view). This way the Node
representing the file would appear with much richer
and possibly very different set of functionality.
There are many potential benefits that introduction of Looks could
bring, and more will probably be discovered in the future.
The major benefits that can be seen in present time are:
- Flexibility - with single consistent approach, which
is flexible enough, the user can customize the IDE's explorers
to his particular working style. With the consistent usage of
Looks this might be fairly intuitive yet powerful.
- Extensibility - one of the fundamental problems
NetBeans faces is a) how to reflect its extreme flexibility in
the UI and b) how to make the UI extensible by modules in a way
that does not affect its usability. Looks might introduce a way
to extend UI by add-on modules in a way that is natural and
straightforward to the user.
However great and flexible Looks are, they are not a panacea to all
problems in the IDE, and they are not going to be the sole way of
presenting the user interface in the future.
One of the basic problems is that Looks only address the
Explorer Tree/PropertySheet-based user interface. The nodes
concept is used a lot in current NetBeans UI, but the
Tree/PropertySheet based UI, although very consistent, pure
from OO-perspective and simple for the programmer to code, is
not optimal from the user perspective, and level of usability and
intuitiveness in generally lower than that of a custom-built
user interface. Custom built UI, by using richer set of
components, smart layout and dynamic behavior, can usually achieve
higher level of intuitiveness and guide the user in completing the
particular task smoother.
Part of the Looks usage guidelines need to addresses this by
clearly specifying the ways Looks should/should not be used.
The default and easiest way to visualize Looks would be to add a
"Look" property to the Node's properties or "Set Look>" action to
its context menu.
This approach is very clean, flexible and easy to implement,
however introduces many problems from UI perspective:
- nodes can use different looks arbitrarily in the tree, making
different subtrees appear and behave differently
- by having the looks local to each node, doing any global
customization (like changing look on all nodes of a specific
type) would require either some other place to be able to
select the default look (e.g. in options), or necessity to go
and change the look on all instances one by one.
- should the look selection on all nodes be persistent? Ignoring
implementation difficulties (e.g. not all nodes represent
files with filesystem.attributes to store metainfo about
selected look), if the answer is "Yes", then it only
makes the problem with differently configured subtrees
worse (I change look on some node and week later am confused
because I forgot about it). If the answer is "No", then
the usefulness of setting looks is seriously limited, as prior
to each operation after each IDE restart I have to go and
change the Look. If the answer is "Yes for some nodes, No
for the rest", it has the problem of identifying clearly
to the user which of those groups particular node belongs to.
To make the long story short, the discussions held about Looks UI
lead fairly quickly to the conclusion that for the reasons stated and
some others, this is not the way Looks should be used and presented
for the mainstream IDE usage.
The proposed incorporation of Looks is limiting its usage to 2
different ways, primarily to address the potential problems coming
from too eager use of Looks:
- Usage of Looks globally in an explorer - the Look selection
and configuration is present in the explorer's toolbar
and affects the root node of the explorer (which then controls
also the appearance/behavior of the whole subtree).
- Using looks combined with the "Open In New Explorer" concept
for cases where it is desirable to use a different look in a
separate explorer.
Both of those usages are persistent across IDE runs.
The global looks in explorer are presented in the explorer's
toolbar as a Combo Box displaying all the available looks for the
explorer's root node. The Looks should have a meaningful order and
be grouped in related groups divided by separator.
The last item might be "Custom..." which would allow to further
customize the look to be used and potentially save the customized
look in the list of available looks (??? this needs some more
thinking and analysis)
The "Open in New View As" menu item would be present in all nodes
where appropriate (or all to achieve consistency?), and would have
a submenu listing all looks available for that Node. Upon selecting
a look from the submenu, a new Explorer would be created and docked
somewhere (this is an open issue related to the future of the window
system), with the selected node as root using the selected Look.
Some additional guidelines:
- When to use Look vs. new explorer (explorer tab in
NetBeans 3.X) : to be defined, at this
point it seems reasonable to try to minimize creation of new
explorers as much as possible, in favor of providing new look.
The module developer should only create a new explorer if a
major new functionality is provided or if the new
functionality covers a new separate stage in the development
cycle which deserves separate UI.
- It shall be preferable to provide the same level of
functionality across all looks. I.e. it is not desirable that
certain functionality only works in some look, and requires the
user to switch the look before she can use it (it is OK if the
functionality is more easily reachable in some looks vs.
others though). This might not be realistic to achieve 100%,
but should be seen as a good practice in using looks.
Scenario 1:
The user switches the global look in the
explorer for it to better suit the task he is going to perform at
that moment. Example: Switching the explorer to VCS Histories
during more complex VCS operations (merging, searching histories).
Scenario 2:
The user changes the global look in the explorer to better suit
his working style.
Example: (If possible with Looks API) The user changes the
explorer look to display/hide subnodes under document nodes.
Scenario 3:
The user changes the look in the outline to be able to see things
and operations specific for the task she needs to perform.
Example: Switching between Bean properties and Java structure
in the outline.
Scenario 4:
The user uses certain Node in certain look frequently, so he
opens it in a new view using the specified look. The View is
then docked somewhere (open issue) for regular use.
Example: JDBC Database Explorer opened in a special look in
a separate explorer window.
The term "Look" is not quite suitable for the real usage in the UI.
The proposed term for Looks in the UI is
"View As" and
"Open New View As".
Introducing Looks in the global explorer and outline changes to
certain extent the way the user interacts with the IDE. The user is
now able to use the same view (Explorer/Outline) to view and operate
with the same underlying data in different ways depending on the look
selected. The "Open In New Explorer" concept is extended with ability
to select Look used in the new explorer.
The images here show Looks as described in
Section 2.
The images include some other concepts planned or considered for
4.0, just to put the Looks UI into the bigger context of changes.
Figure 1 - NetBeans IDE 4.0 Mockup with Looks in Explorer (click for full size picture)
Figure 2 - Explorer Looks Combos expanded
Figure 3 - Open New View As popup menu action on a node in Explorer
Open Issues
- Does this reflect all possible usecase scenarios? Isn't the
limitation to global usage too strong?
- Who defines reasonable and meaningful order of looks,
properties, actions.
- Where do the new explorers opened via "Open in New View As"
open?
- Which look is used by default?
- How to group looks together into related groups?
- Should all nodes have the "Open in New View As" action in
their popup menu?
- Should the explorer that opens on the "Open in New View As"
action also contain the toolbar with Look selection?
- Plenty others, this is just very rough first draft...
