Property Sheet - new design

author: Dusan Pavlica      last update: 22.12.2003

 

Content

• Overview
• Summary of known problems
• Scenarios and user needs
• Competitors sketch
• UI ideas
• UI specification
• Other issues

 

Overview

A Property Sheet is a window in which users can display or change values of one or more object properties. We use it on many places in the IDE, but sometimes without really good reason or unseemly. Usability and look of Property Sheet component aren't acceptable too. We found these reasons important for creating new design of Property Sheet. Let's focus now on a terminology which will be used in this document:

Fig 1. Explorer View showing Explorer with Property View in lower half.

 

Property Sheet - Refers to all the property tabs associated with the node; can appear in the Property View, Tools -> Option window, specialized window, such as the lower part of the component inspector or in a dedicated property window launched from the "Properties" context menu of the node. By default, if a node has properties, the "Properties" tab will be the first tab in the Property Sheet.

Property View - the UI display consisting of an inspecting property sheet and property sheet toolbar. There are two types of property views - dedicated and non-dedicated. See JLF Advanced Topics for more on this subject.

Property Tab - one tab of the property sheet that provides a logical grouping of properties that provide the user with an understanding and easy way to navigate the type of properties associated with a node

Property - intrinsic and extrinsic parameters of the object, that is parameters that describe the object and how the specific object should be handled. For example, intrinsic parameters could be the Name property and the class it extends and extrinsic parameters could be what the executor is and the database driver class.

Non-Dedicated Property View - a context sensitive property view that contains the property sheet of the current selection or placement of cursor and the property sheet toolbar (See fig 1). It appears by default at the lower half of the Explorer View, or can be launched from the View->Properties menu item. The context sensitivity makes it different than a "Dedicated Property View".

Dedicated Property View - property view that is launched from the "Properties" context menu of the node that shows the associated property sheet and property sheet toolbar. The contents do not change as selection changes. It must be dismissed by user explicitly.

 

Summary of known problems

There are many types of problems with Property Sheet, but three main are Usability, Strange look and Implementation too. Let's mention some of them shortly:

• Too many Property TABS is strange at all (big problem in the Enterprise edition when count of TABS is so huge).
• Unnecessary Toolbar at the top of PS. But if the toolbar goes away, an alternative visual element must be provided that indicates if help is available and permits the user to click it to get context-sensitive help.
• Selecting of In-line editors inside Property Sheet isn't intelligent enough, could be betterment a lot.
• Usability and keyboard navigation in Property Sheet could be improved e.g. for invocation of Custom Property Editor.
• Visual design with plastic rows, gray color in the background and purple text is strange. The purple text on the gray bg seems to indicate that the
  text is non-editable
• We use Property sheet as a center piece of the UI in the all IDE. We should slowly move away from these sane usage to a custom task-based UI (wizards, custom dialogs, etc.), especially in the Enterprise edition.

 

Scenarios and User needs

User could have different needs and expectation of work with Property Sheet. We use Property Sheet in more manners in the IDE and main role for Property Sheet isn't defined clear. Let's describe some typical cases when user work with PS.

Search of one property

1. User could know name of property but doesn't know its category. Then search by name is really quick in a simple list instead more TABs
2. User knows name of category but name of property doesn't remember. Only scrollable list isn't optimal for this case. Any visible categorization is requisite. Type of this category visualization depends on differences among property types.
3. User don't know if object has concrete property, but would like to find it among many of them quickly.

 

Meaning of property

User needs to know meaning of concrete property in the Property TAB, but support of this case isn't good solved now. We have a tooltips over cells but for keyboard user it isn't so useable, because he couldn't reach this info easily and quick. There is shortcut for invocation of tooltip, but who knows about it...
We have context sensitive help button in the Toolbar too, but there are some problems with its usage:

1. It's hard to perceive that help button change its state (from disable to enable).
2. User doesn't know about association between help buttons and Property TABs or separate rows.

Multiple changes of property by more objects

When user works in the Form editor e.g., then he would like to set the same property for more components. It could be done by multi selection of components. Sometimes user isn't familiar with multi selection in the Form editor, then he switches between the Form editor area (the Component inspector) and Properties in the Form. Then we should specify what type of possible design are optimal for this use case.

 

Exploration of object's properties

Another use case is when user explores object and would like to obtain utmost information about it. Then he use Property Sheet as a help more then place for change of properties. This case we solve with current Property Sheet which is still visible. But better way is to invoke Properties or specific Customizer from Context menu.

 

Navigation between categories

With current TABs are easy visible all categories, but navigation between more rows is cross-eyed a bit (it means that row's moving during TAB's selection).

With a Tree Table user could have problem to see all category, when each category node is expanded. There is chance to have them colpased at the start, but then it's hard to find any property quick. User that is familiar with content of categories could close categories which are unnecessary for her. But novice should have all categories expanded by default.

And when Table is used, then there is no category visible. This isn't acceptable by users that know categorization of properties very well. Intermediate user could be able to browse through this Properties Table list or will require to switch into view with categorization. Basic user will need help for any properties and it doesn't depend on categorization.

 

Another Ideas for exploration

• Long Table versus too many TABs. Typical usage for navigating in these two cases.
• Context (un)sensitivity of Property Sheet. E.g. let's try to select any method in the Source editor and then select any other row.
• Search group of properties. What is ideal design for categorization.

 

Competitor sketch

I tried to find usage of Properties in another IDEs and not only in IDEs for Java programming. I could say that we are to much Property Sheet centric compared to them.

IDEA hasn't any special component for showing of property.

Eclipse has really minimum properties in their Property window. It's used mainly for information about file.

     


JBuilder8 uses property panel mainly in the Designer. It has Grey background and categorization is simple (only Properties TAB and Events TAB). There is possibility to change count (level) of properties in a Context menu by Exposure menu Item. Navigation through properties is quite quick. Combo boxes usually uncurl immediately after click on them. This behavior for one click action in properties is usual in their properties.

.NET has fine and clear look of Properties component. They use symbol plus and minus for category node instead our strange puller. Then they have thin grey left column with the same grey like category's rows have. Usability of navigation and intelligence of Property's editors is quite good but could be improved more. Three dots for customizers   appears only after selecting appropriate property. Help system is solved very well by area under properties called Description and it could be turned on/off in Context menu. This area is able to provide help for each of row or category.  Toolbar comprises button for sorting (categorized and alphabetical) and button for Dynamic help. There was Dynamic help button too in the old version of .NET (see Figure). They don't use TABs but Event's properties could user switch on/off by another Event button in the Toolbar.

     

Delphi has combination of TAB, Table and Tree Table look. TABs are used only minimally for distinguish between real Properties and Events. They provide change between Table and Tree Table in Context menu by menu Items Arrange>by Category and Arrange>by Name. When it's sorted by Name then it's displayed as Tree Table but without category nodes. When it's sorted by Category, then nested Tree Table is shown and default state is collapsed. There is another possibility how to narrow down amount of properties visible in one moment. User could set filtering of  property's categories by menu item View>list of all categories with checkboxes.

  

 

UI ideas

Next chapter is about Property sheet design ideas. It's only introduction to problematic before we define UI specification.

 

TABs, TREE TABLE or TABLE ?

It's clear, that we use TABs for Property Sheet unseemly. Count of TABs in any modules is bewildering for user. We could say, that more then one row of TABs isn't good design in general. Let's realize, that user change complete all row order by selecting only one TAB from non active row. User could orientate oneself in categories quickly by first look at the first hand, but exploration of them or search of any unknown property costs so many mouse clicks (plus scrolling in a long list of properties) on the other hand.

Then we have to chance to use Tree table instead of all TABs. But then user could have problem with mixing completely different property types. Let's look at the Form editor's properties for example. There are three (or four) TABs, with similar meaning (Properties, Other properties and Accessibility), but Events and Code Generation have different type of content. It isn't correct to mix these TABs altogether.

Solution with one long TABLE without visible categories is the third case. Then there isn't problem with bad appearance of TABs or strange and width pullers. This TABLE design could be correct for small count of properties, but for bigger merge of current TABs (e.g. EJB module) will be this count really critical. We could say that these dependencies on Property Sheet aren't sane and we should try to cut back this bad usage anywise (e.g. by complex customizers assigned to nodes instead situate properties in the Property Sheet).

 

Look with TABs

In a case when we will choose variant with paucity of expressive TABs we need to decide about right place for them. You know, there is two possibilities (top or bottom place for them) and it depends on Window system redesign mainly.

Its appearance could be different then TABs of windows as well. There is demand, that user should distinguish window's TABs and inner "document" TABs somehow.

 

Look with Tree table

It's a shame that "Pullers" by a tree table node take up so much space. Then we have a visual problem with them on the left side of tables. There is a lot's of space on the left. And categories should be distinguish from sub-nodes well-marked. It will be done by:

1. Visible puller at the same row like category row
2. Another color of category row. Let's think about the same gray as table headers has
3. Align of sub-nodes texts to the right and it will start minimally as category text. But better is to move them a bit more to the right.
4. Pulers have really strange design, so it could be changed maybe

Optional chance for betterment of Property Sheet look is to fill left free space by sub-nodes with the same category's background color.

 

Selection of concrete property

There could be problem with quick selection of concrete property when user will manage long Table of properties. So, let's use auto scroll behavior of property list, when user focuses the same object (e.g. Another Button in Form editor or another Java object in Explorer). Why use this autoscroll ? It could minimize usage of Property sheet's scroll bar in some cases when user work with multiple similar object (e.g. in Form editor).

 

Toolbar of Property Sheet

Toolbar should be removed and sorting will be moved to the context menu, because it's not so frequently used. Customizer and Help button should be placed somewhere else. There are these chances:

1. Move Customizer into main Tool Bar and Help Button into mini statusbar (or Global Status bar if exists).
2. Create special area with context sensitive description, and both of buttons (customizer and help).
3. Use the same description area, but only with help button, then we have to set appropriate place for customizer button or remove it at all.

Experimental look with minimized count of Property TABs,
simple list of Properties and Description area

 

UI specification

This part of document describes UI specification of Property Sheet. It's about main look and functionality. It includes description of important Inline editors as well.

 

Main look of Property Sheet

I mentioned ideas and problems of possible look with TABs, Table or Tree Table in the previous chapter. And solution is presented bellow:

Preferred design is to use combination of Table and Tree Table in this way:

1. Use TABs but only limited number of them (three Tabs and one row are maximum) and mainly for categories, that have really different purport.
2. Use Tree Table for visible categorization of properties. Default state is with all nodes expanded. Expanded/Colapsed state should be persistent by each category.
3. Use Table for simple alphabetic listing of all properties. Then search by name of concrete property is really quick.
4. Use Tree Table for case when order of properties is arranged by Importance (as a Unsorted in the current state)

Details:

• There should be created API where each set of properties (e.g. Other properties, Events etc.) will have special parameter. This parameter will define representation by Set inside Property Sheet. It means, that each set could be visible like TreeTable category or special TAB.
• When more sets are merged together into one TAB, then should exist possibility to set appropriate name for this TAB.
• Then we should accomplish minimization of TABs (only for really important and logically different Sets) for all modules in the Netbeans and provide close assistance for other modules.
• More TABs at one line should be worked out in the Windows system redesign. There is option to have left and right arrows at the end of TABs row  (on the right side).

Design of Property Sheet inside area is shown bellow. First figure is Tree Table look with visible categories and second one is Table look with ordering by Name.

         

Exact colors for Property sheet

Following table of colors graphically shows exact color for each supported L&F:

 

Property Sheet ToolBar

Toolbar will be removed and its functionality will be placed into a Context Menu and to other places. Context Menu will include Menu Items that will switch between two looks of Property Sheet content and between sorting of Properties as well. Sorting by Type should be removed and sorting by Importance (new name for Unsorted) is still discussed. Customizer button should be displace somewhere else, but out of Property Sheet. This is open issue still. There is chance to have Customizer button in the new Form editor ToolBar when user in GUI Editing mode and leave customizer only in Context menu for Editing mode.

Look of Context Menu:

Context menu should look like is described bellow.

• User could switch only between two sort of types (by Category and by Name). Menu Item "Unsorted" will be extracted, but Category and properties within each Category will be sorted by importance. Sort by Type is removed too.
• Possibility for switch on/off only editable properties remains.
• Description Area is able to show or hide by menu item "Show Description Area".
• Last Menu item is Help which has the same behaviour like the Help button in the Description Area.

+-----------------------------------+
| (o) Sort by Category              |
| ( ) Sort by Name                  |
+-----------------------------------+
| [x] Show Editable Properties Only |
| [x] Show Description Area         |
+-----------------------------------+
| Help                              |
+-----------------------------------+
       

Default preset:

• Sorting by Category should be visible by default. It means, that expanded Tree Table will be used first.
• Show Editable Properties Only will be checked by default.
• Show Description Area by default too. User, that isn't so familiar with IDE will appreciate it.
• All these settings should be persistent.

 

Description Area under Property Sheet

This area is intended for information about content of Property Sheet and provide quick information by navigating properties.

Description Area has these three parts:

• Title with bold text "Description Area" - Title will display name of current selected place (category, property, TAB of Property Sheet etc.) and is inteded for user's orientation. Text is bold.
• Main text area - There is described a meaning of property, which is just selected. If row with category name or TAB of Property Sheet is chosen, then help text for this category appears here.
• Help Button - User is able to invoke Java Help linked with concrete Property or Category if help information exist. Figures bellow shown three states of Help button. First has non active button, second has active button linked to some Java Help content and third state appears when mouse cursor is above it.

     

Details:

• Description Area will lay at the bottom of the Property Sheet.
• When content of Property Sheet is scrollable, then Description Area is out of that scrolling.
• Height of the Description Area is customizable by mouse dragging.
• Text should be taken from Tool tip assigned to each property and category.
• There should exist possibility to set different text then which is in appropriate Tool tip.

 

Property Sheet content behaviors

This part of document is specification of Property Sheet content and its important behavior. It covers three main parts:

• In-line editors
• Error marking
• Quick navigation

 

In-line editors

There are two states  (Display mode and Editing mode) of In-line editors as it's in the current implementation. But difference is in easier invocation of Editing mode. Let's mention three most important changes:

• Button with three '...' is visible still, not only in Editing mode. Then it could be used immediately by mouse click or by CTRL+Enter key press.
• True/False type of value isn't visible as a ComboBox anymore, but pair of RadioButton (True/False) is used by default (what about simple Checkbox without Label?...should be tested)
• ComboBox is invoked after first click (not by second as it's now), which selects concrete property cell too.

 

Error marking

When a value of a property becomes invalid (e.g. missing file) then is necessary to provide expressive marking of that value in the Property Sheet. Removing such kind of marking when the value is valid should be provided too. Any modules in our IDE have this feature, but it looks different. Sometimes is used different front or background color or warning which isn't visible and readable good. Solution is to display a visible Glyph before appropriate property's value. This glyph should disappear when user invokes Editing mode.

I saw, that it have been implemented yet, but there is this issue too: http://www.netbeans.org/issues/show_bug.cgi?id=20734

 

Quick navigation

I mentioned one improvement of quick navigation in a chapter about UI ideas. I named it Auto Scroll behavior. Another one could be useable in situation, when user needs to find property quick in really long list of properties or somewhere among more categories. It could be done by this way:

1. User is focused in the Property Sheet.
2. User will start to write a character.
3. Popup dialog with Search Label and Textfield will appear and characters will be visible in that Textfield area.
4. Property Sheet will automatically scroll to the property which matches these written characters.
5. By  ESC or Enter key press that popup disappears.
6. Last automatically selected property stay selected.

Design of this functionality could be included later in a case when we will agree with implementing it. Or it could be part of Windows System Redesign at all.

 

Other Issues

• About process of minimizing TABs at all. New API for TABs exists and every module has to cooperate close on this issue.