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.
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

1 Introduction & Requirements

1.1 Brief overview of Looks API

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.

1.2 Benefits of using Looks

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.

1.3 Things to be careful about with Looks

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.

2 User View

2.1 Non-solution

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.

2.2 Proposed Solution

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.

2.3 Scenarios

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.

2.4 Terminology

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".

3 System-Wide UI Impact

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.

4 Mockup of possible NetBeans 4.0 UI

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

5 Notes

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...

Project Features

About this Project

ui was started in November 2009, is owned by Jiří Kovalský, and has 44 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
Please Confirm