People need to efficiently modify a lot of properties.
Provide a list of property name-value pairs that lets people directly change the values.
- 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.
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).
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.
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.
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.
This one from Fireworks CS4 shows the Symbol Properties panel, which uses a stereotypical (extensible) property sheet.
The Properties panel ("inspector") itself has a more robust editing experience that is customized to particular types.
The primary example is from Visual Studio and shows the stereotypical two-column layout with property name-value pairs. At the top is a drop-down selector to change between objects on the design surface. Just below that is the ability to toggle between alphabetical and categorical arrangement. In category view, the categories group the properties into collapsible panels. It also toggles between object properties and events, with the same layout for both.
It supports an extensible framework for value editors. By default, it uses direct text editing; however, editors are associated with types of objects, so it will automatically show appropriate editors based on property type if a more specific editor is available.
This shows an early preview version from Microsoft’s Quadrant editor for their M languages. The interesting thing here is that it supports property sheet editing of every object in the system, including the design environment itself. By default, objects use the two-column layout for property sheet editing, but it supports more object-specific editors.
This example from OmniGraffle Pro 5.1 shows their approach to property sheets. They use floating , collapsible, magnetic panels. They group properties by panel (Syle, Canvas, Properties, Document) and using iconic selectors within them. You see a vast array of property value editors, including a standard two-column view for the “Note” properties view to add custom properties with values as key-value pairs.
This example from Microsoft Word 2007 shows the Modal Panel kind of property sheet. It also illustrates how you can create a property sheet that is barely recognizable as such, but each of these properties applies to the Paragraph object, at least as far as we’re concerned.
Microsoft Expression Blend uses a somewhat similar approach to Visual Studio, but they take liberties where it makes sense, as in the inline color pickers, iconic alignment selection, and they add a very cool feature of searching to actively filter the properties shown in the sheet.
Blend also has the idea of hiding less commonly used (“advanced”) properties. This can backfire big time if you don’t get it right, so be careful. When people click the down arrow, it expands the section with more properties.
Another interesting thing about Blend’s property sheet is the little squares next to each property indicate if it is a non-default value (it’ll be filled in white if so), and they provide access to a context menu that provides for some standard actions like resetting, assigning to a resource, converting to a resource, data binding, and more.
Infragistics’ Windows Forms toolset includes a tree that you can configure to provide a property sheet similar to that found in Visual Studio.
Jennifer Tidwell, Designing Interfaces