UI Patterns and Techniques

Property Sheet

From the Curl Surge Lab IDE
Use when:	The UI presents an editable object to the user -- something built in a graphical editor, or a database record or query, or some domain-specific thing (like a car or a stock purchase). The user will need to change the properties or attributes of the object.
Why:	Most users are familiar with the concept of a property sheet -- a list of object properties or settings, set forth in a prescribed order, editable via controls appropriate for the property types (text fields for strings, dropdowns for one-of-many choices, etc.). Simply because they're conventional, well-designed property sheets are generally easy to use. Property sheets can also help the user build a correct mental model of the objects in the UI. A property sheet tells the user what the object's properties are, and what values are available for each of them. Especially in applications that mix WYSIWYG editing with programming (such as GUI builders, Web page builders, and time-based scripting and animation tools), property editors thus help the user learn how to use the system.
How:	The only commonality here is that the various edit controls are labeled with the names of the properties they edit. When the user is done filling in values, the new property values are written out to the object. These are the issues that usually come up when designing property sheets: Layout. Some systems use a two-column table, with controls that appear when the user clicks the values shown in the righthand column. (Visual Basic seems to be the de facto standard for this approach.) Others look more like dialogs than tables -- text fields beside controls. Use your judgement. Tables might be more recognizable as property sheets, but dialogs can be far more flexible in their presentation of the property-editing controls. Property order. Alphabetical? Categorized? Or an easy-to-read order that places the most commonly-edited properties at the top? They all have their place. Short property sheets (say, 10 or fewer properties) are usually best with the most common properties listed first. The longer the list gets, the more important it is to categorize them; but if a user is looking for one particular property by name, they may want to sort them alphabetically. As always, it's best to give users a choice. But you're still responsible for picking the right default order. Control choice. Fifty pages could be written about this. The short version: make sure the property's current value is always there to be seen; choose controls to constrain the input as much as possible, e.g. by using non-editable dropdown lists for one-of-many choices; use built-in fancy editors for specialized types like colors, fonts, and filenames. When to commit the new property values. Many UIs simply update the object with the new value as soon as the user is done typing or selecting a value. The more dialog-like property sheets may wait until the user deliberately commits the whole thing, e.g. by clicking on an "OK" button. But if your software can deal well with instant update, that gives the user more immediate feedback about the change they just made. "Mixed" values for multiply-selected objects. Some UIs solve this by showing no value at all, which can be dangerously misleading. Others show it with a sentinel value, like an asterisk "*", or the word "mixed."