Multiple instances of a Property Editor

Question

I am designing an application in which several kind of user objects have properties. When clicking an object, the properties of the object would be shown in a pane similar to the Properties pane in Visual Studio. This pane allows to view and edit the properties of one or multiple objects that are selected. (similar pane can be found in many other applications, such as Expression Blend, Adobe Lightroom, etc...)

I also want to be able to Pin the currently inspected object to a Property Editor so it remains there (I mean the objects stays in the Property Editor. I am not talking about the auto-hide feature). Then the user can select another object and is able to compare the two objects simultaneously, and see two property editors.

Do you know any software doing that? I am looking for the right user interface pattern and paradigm to implement such feature.

Some models I thought could work:

Model 1 - The user can instantiate as many property editor as he wants. Only 1 instance of the Property Editors opened is the Default One. The default Property Editor shows the currently selected object. The user is able to click a Is Default icon on the Property Editor to tell which one is the Default. Clicking Is Default on an instance will remove the Is Default state of the previous default instance.

Model 2 - The user can instantiate as many property editor as he wants. Every instances of the Property Editor can be pinned. When a Property Editor is pinned, the object bound to it remains in it, and can't be changed by the current selection. Issues: when selecting an object, which one of the un-pinned Property Editors will show the object? What if all Property Editors are pinned?

Model 3 - The Property Editor instances are created automatically by the framework. By default, one Property Editor is shown. Property editor instances are created automatically when an object is pinned. When a Property Editor is pinned, another new empty instance is created, ready to receive the selection. The Property Editors are stacked horizontally, and the system always keep only one Default Property Editor. Un-pinning a property editor destroys it automatically.

Which model is the best? Do you have other suggestions?

Answer 1

I’d avoid Model 2 with its complication of discriminating and managing multiple pinned and unpinned properties panes because of the issue you cite. I also don’t understand what an unpinned non-default pane means, so it may confuse your users too. Seems to me either a pane repopulates when object selection changes or it doesn't. What else is there?

Models 1 and 3 are similar as I understand it. Both have no more than one default properties pane, but they differ in how the user designates it. Just to make sure I have this straight:

Model 1

• User selects Object A to compare. The app populates the default pane with A’s properties.

• User selects a command like “New Properties Pane.” App opens a new pane. The new pane becomes the default (I think that’s best, but it’s not necessarily required).

• User selects Object B. The app populates the default pane with B’s properties.

• Repeat last two steps for additional objects if necessary.

Model 3

• User selects Object A to compare. The app populates the default pane with A’s properties.

• User selects the Pinned command. App opens a new pane which becomes the default.

• User selects Object B. The app populates the default pane with B’s properties.

• Repeat last two steps for additional objects if necessary.

The Winner?

The primary difference is exactly where users to click instantiate a new default properties pane and how it’s labeled.

I’m inclined towards Model 1 because it’s an overall simpler UI. You’re going to need a command to open a properties pane in either model because you’re going to need to allow users to close (all) properties panes so they can declutter the screen. In Model 1 the same command to open the first property pane is also used to add new ones. Model 3 has an additional command to learn and distinguish.

I’m not sure if the “is default” control is necessary for Model 1. I don’t expect users will need to swap the default too much. More often, keeping the properties (by selecting New Properties Pane) and dismissing the properties (by closing the pane) will be separate actions conceptually and temporally. "Is default" seems like a complication with little benefit.

Research Questions

In any case, you’re apparently building a novel UI, so you’re going to have to do some user research and usability testing to get it right. Here are some questions that only user research can answer:

• How does this fit the users’ mental model of the comparison task? Do they think, “I’ve Object A. Now I have to figure out how to show Object B at the same time”? That fits well with Model 1. Or do they think, “I’ve Object A. Now I have to figure out how to keep it here when I go get Object B”? That suggest something more like Model 3.

• When the new default pane opens, should it be blank or populated with the currently selected object? The former may prompt the user, suggesting “okay, I’m ready for you to select a new object.” The latter is more consistent and may better indicate that the new properties pane is the default –because by definition the default always has the properties of the currently selected item. The latter is also necessary if the default isn’t automatically shifted to the new pane –otherwise, you’ve no way to populate a new properties pane (except via right-click).

• Do users recover from closing the default pane? If the user closes the default pane, you can’t automatically change one of the remaining panes to be default (if there are any) because that would risk wiping out data the user wants to preserve. If users close the default, will they understand that they have to select New Properties Pane to see properties for the selected object?

• How do you visually distinguish the default pane from the others? This is necessary because users may forget which is the default and not know where to look. They also need to be able to tell by a glance of the screen if there’s no default or if they’re about to close the default since that has ramifications.

• What is the best terms and metaphors to use? Does “default” and “pinned” make sense to users? Or should it be “dynamic” and “locked”? “Liquid” and “frozen”? This will affect how you want to visually distinguish the default pane and how you describe it in your documentation.

Alternatives

I admire your efforts to provide users a properties pane that flexibly supports both easy population on object selection and a means to do side-by-side comparisons. However, consider the possibility that it may not be worth it. It may not be worth the added complexity for the users or the extra research and development you have to do. Consider if one of these more conventional alternatives might be sufficient:

• Simple Single Properties Pane. Here there is at most only one properties pane visible which always shows the current object. If populating the properties pane is fast (<500 ms), then the user changing object selection can produce an animation effect that naturally draws the eye to any differences in the property values. If the users’ task is to identify differences, this may make it easier than side-by-side comparisons. A simple augmentation is to include Back and Forward buttons on your properties pane to allow users to switch among their history of selections without a lot of mouse slewing and possibly scrolling of the master pane to find the objects. It would be pretty handy in general for reverting the selected object.

• Simple Multiple Properties Dialogues. Here, property panes do not populate on object selection. Users open a modeless properties dialogue by selecting Properties command for the current object (or double-clicking it), and the dialogue is always “pinned” to that object. This is good when properties are rarely needed –when users only occasionally need to change a property and close the dialogue. It’s also supports side-by-side comparisons well.

• Table View. I don’t know how you’re presenting your master objects, but you could provide the option to display them all in a sortable and/or filterable table showing all properties of interest as columns. This is best when you expect comparisons among many objects, saving the user from having to open and manage multiple property panes one at a time. Property values are aligned directly on top of each other for easier comparisons than with separate properties panes. It assumes that your objects have mostly the same properties. The table can either show only properties shared among all objects, or the union of all properties with “N/A” values for objects that don’t have the properties.

• Multi-selection/Single Column. In some apps with simple single property panes/dialogues, the properties panes and dialogues follow the convention that when multiple objects are selected, only property values shared by all objects are displayed; the rest are blank. This may be sufficient if the task is to identify what is the same or different for all objects (but doesn’t tell the user how they’re different). It also allows users to easily change a property to the same value for multiple objects at once. It's faster than your models, taking fewer clicks to see the properties shared by all objects. However, it requires fairly high expertise -many users don’t know how to multi-select. On the other hand, this is combined Simple Single Properties Pane, which may already be sufficient for your non-expert users. Sounds like you're were going to have multi-selection/single column behavior anyway. Maybe you're already done.

• Multi-selection/Multiple Column. Alternatively, when the user selects multiple objects, the properties pane expands presenting a separate column of property values for each object. To compare objects, the user selects one object then Ctrl-selects the remaining objects, or drag-selects all objects to populate the properties pane all at once. This is more compact than a separate pane per object. Like Multi-selection/Single Column, it's faster than your models. Like Table View, it also aligns the property values (side-by-side) for easy comparison. But also like a table, it only works well if the objects generally have the same properties. It’s a novel design that isn’t particularly discoverable, so it assumes regular or trained users and you shouldn’t try it without user testing. On the other hand, like Multi-selection/Single Column, this is combined with Simple Single Properties Pane which may be enough for your non-expert users.

Answer 2

No app comes to mind that has multiple instances of property editors, but a side-by-side comparison of documents is supported by MS Word, Excel, and many other apps. It's usually done in a split screen, vertically or horizontally.

It sounds like that kind of solution won't be relevant to you, so what I would do is this: -Click on an object displays its properties in the properties pane. -Double click / context menu item / toolbar action on an object turns the properties pane into a tab control, displays there the properties of the second item, and brings it into focus. (basically "open in new tab").

This way you can also create more than two property editors in the same real estate (but I think I wouldn't go over three or four). This won't allow you to compare them side by side, but comparing two tabs is still much much easier than switching between two objects who control the same grid.

And you could always provide the functionality of detaching these tabs if you really need them in a separate container, but it seems to me like it would mean a lot of headache both for you and the user.

EDIT

As an afterthought: you should bear in mind that in any case, if you add a second Properties editor, you're entering a world of pane ;)

• Once it's displayed, and then a third object is selected, how do you decide which pane should display its properties - the first or the second (or a new one?)?
• Do you allow displaying the properties of the same object in two different panes?
• If yes, can it be edited in either? Will they sync then? Or is one of them read-only? Which one, and is this logic clear to the user?
• If you select two objects, then both panes display them separately - but if you want to change a property shared by both, now you need to do it in two places instead of one (if you support group editing).
• What if you select three objects? How do you decide which ones to display?

Most of these have relatively easy answers, but they need to be given thought, and they need to be consistent with the rest of the app. It's asking for trouble.

EDIT Concerning the models you added:

1 - I think the notion of "default reflects selection" is good, but the ability to change the default one is an overkill, it would just confuse users. If I understand right, under this model the way to display two different items is: select one, create a new property editor, move the Default flag to the new editor, select another. This is very cumbersome and difficult to grasp. It's easier to define "open this object in editor X", than "each time define which editor is going to display the next selected item".

2 - I don't think it makes sense that pinning a container bounds it to an object. You can pin an object to a container, but pinning the container itself is a very standard action that controls the layout, not its content. It would be misleading and confusing.

3 - I think this is the most straightforward model of the three you suggested. It's the simplest to understand, predictable and logical. However, it would drive the user absolutely crazy within one minute of use. Selection is probably the most frequent action a user makes in an app like this one, and he performs many selections every minute. To have each click open a new large component on the screen is somewhat suicidal.

If the tabs suggestion doesn't work for you, I would have one default editor, and let the user open other editors via a specific command, not the usual selection click. The other editors will be "floating" and will not respond to selection, so you can't change the object inside (or, you can do that with another specific command).

Answer 3

What I'd do would to create an interface (NOT a "class" of type "interface") which receives all the objects which properties are going to be shown in the properties pane. Such interface would parameters for sorting the properties in different desired ways ex.
1.- Show each object's properties all together
2.- Sort properties by name (which would mix all objects properties)

In this scenario I go for a new Model other than those you proposed, in this you have ONLY ONE properties pane and all the properties of the selected objects are shown here just sorted differently.

I can't either think of any application that works this way, but I think having all the properties in one single pane would simplify the process for the user :)