Property Sheet

Problem

People need to efficiently modify a lot of properties.

Solution

Provide a list of property name-value pairs that lets people directly change the values.

Context

• You a have fairly computer savvy audience.
• Your solution involves selection and editing of objects that can be modified independently with minimal validation.
• You have more than a few properties to edit.

Rationale

This pattern is most common in complex visual tools such as drawing and visual modeling tools and other visual designers such as those in integrated development environments. It works because such tools inherently support an object-oriented paradigm, where people work with objects as discrete things on a surface. People select an object, usually by clicking on it, and then the tool lets them modify the various properties of that object by showing a straightforward list of properties and values with minimal added context or workflow. And by showing the list of properties, people come to a better understanding of the object and what can be done with it.

Further, it has become a convention, almost a standard approach to modifying objects in tools like these, so people who have used them (mostly computer-savvy folks like developers, designers, and business analysts). So people are familiar with it and may even expect it in those environments.

That said, property sheets are not necessarily the best option. If you only have a few properties, they can be overkill, or if you can support direct manipulation of an object, that is usually better because it doesn’t require people to do a mental mapping of how changing a property will affect the object and it is more natural to just make the change on the object itself than to go to a separate property sheet. Yet even if you support direct manipulation, a property sheet can be a good compliment for more precise control over values (e.g., the X-Y point values for location instead of dragging an object to a place on the design surface).

Implementation

The core thing in this pattern is to enable the selection of an object and then to show a panel with the list of properties and their values, allowing people to edit the values directly or through a helpful control such as a picker of some sort.

Usually the property sheet stays visible and just changes its contents as different objects are select, but you might see them in a Modal Panel of some sort where an object is selected in the panel (e.g., via a tab or drop-down) or implied, such as a settings dialog for a document. If it stays visible, you may need to handle the case where multiple objects are selected; in that case, it’s usually best to either only show the common properties, if there are any.

The most recognizable layout is a two-column layout with the property name on the left and the value on the right; however, the layout can be more flexible to accommodate what makes more sense for you situation. The example from OmniGraffle is a good example of an alternate layout, which allows for more usable entry of property values. Visual Studio, on the other hand, uses a standard two-column approach and allows for sorting the properties by alphanumeric or category to help people find what they’re after.

The labels should be recognizable for the people using them. In the case of Visual Studio, it makes sense to show the literal property names (as they are in code) so that developers can directly associate the names in the property sheet with the object properties they see in code. In situations where people don’t see the underlying actual property names, it makes more sense to use names that are potentially more human-friendly.

In terms of editing the values, the most basic approach is direct textual manipulation; however, as with data entry in general, if you can use a more domain-specific editor (like a color picker for colors, font selector for fonts, slider for number range, date picker for dates, etc.), it is better. Sometimes it can be valid to launch a dialog for more complex or compound values (like Visual Studio does for editing collection-type values).

If direct editing is supported, the value should be committed when people hit Enter or leave the field. If they press escape, return it to its prior value. If a dialog is launched, you can do the same thing for individual properties in the dialog or wait until a “Commit” action is selected to commit the changes to the object. Usually, providing immediate feedback is more desirable, if you can do it and not leave the object in an unsuitable state.

Help Me Get There

Infragistics has some tools that can jumpstart your efforts to implement this pattern. Broken down by technology, they are as follows.

ASP.NET

Property Sheet pattern can be implemented using the built-in editing features of the following ASP.NET grid controls: WebGrid, WebDataGrid. Check out the samples browser to see it in action.

Windows Forms

You can use the NetAdvantage for Windows Forms WinTree control to implement this pattern. If you download the NetAdvantage for Win Client bundle, you can find a sample in the WinForms sample browser called Property Grid to see it in action.

Sources

Jennifer Tidwell, Designing Interfaces

Tags

Data Entry, Builders and Editors, Page Layout.