Inline toolbar usability

Question

Hi,

I have an entity that can be modified, saved and deleted and so it would be fitting that it would have a toolbar at the top of the window that you can press one of those action buttons. The parent entity can be submitted.

However, this entity also has child entities that can be modified, saved and deleted. Is it usability best practice to have a grid of the child entities on the parent entity screen and then open a new window with the child entity values (that can be saved, deleted, etc), or can I have another toolbar for those child entities. Each child entity can be submitted.

For example (inline):

//

[Parent Entity]

|------------------Toolbar --------------------|

[New Child Entity] [Save] [Delete] [Submit]

|------------------Toolbar --------------------|

[Parent Entity fields]

[Child Entities Grid]

|------------------Child entity Toolbar --------------------|

[Save] [Delete] [Submit]

|------------------Child entity Toolbar --------------------|

[Child Entity fields]

//

You would select a child entity from the grid which would set the Child Entity fields.

I currently have the child entity as a separate window, but am loathe to have multiple popups. Is there a guide to how many popups are usable?

Thanks

Answer 1

Generally, the best balance is to have the grids of parent and child entities on the same page, with edit-in-place for both parent and child grids. A single menu/toolbar at the top applies to both grids. This is fairly common practice with master-detail relations, such as you describe for your app. For example it’s used by Windows Explorer and Microsoft Outlook.

The Save command saves any changes since the last save, whether it be creation, modification, or deletion of parents, children, or a mix. Delete deletes whatever is currently selected –one or more parents, one or more children, or even selected text within an attribute (e.g., text box contents). The New command (or Create or Insert) creates a new default entity for whatever grid has focus. This design provides the users with:

• Single simple set of commands –there’s no need to distinguish Submit from Save, for example. There’s one-click “just save it” assurance.

• Minimal clutter and fewest redundant toolbars, allowing users to see and manipulate as many data objects as possible with minimal scrolling or other manipulations.

• Minimal navigation effort and learning overhead –no need to learn separate windows (the multiple popups you rightly want to avoid) or commands for parent and child entities.

• No modes that can reduce flexibility, disrupt the user’s flow or train of throught, or even force the destruction of their work (e.g., they can’t submit a new object because of a key violation with another obsolete object, but they can delete the obsolete object because they’re in a mode for creating a new object).

The primary disadvantage is the potential for users to confuse what object(s) the toolbar commands currently apply towards. You don’t want them thinking they’re deleting a child when they are in fact deleting the parent (along with all its children). To avoid this, you need use appropriate graphic design to:

• Make clear exactly what is selected: an entire parent, entire child, or attribute within an entity. Only one thing should appear selected at a time. Be consistent, generally using the same colored reverse-video (light on dark) for the entire selected content, and avoid using reverse-video for anything else. Consider using a grid’s current record marker or “object control” to distinguish selecting an entity (entire row of a grid) from an attribute within the row.

• Distinguish between the active parent and a selected parent. The active parent is the one associated with whatever you’re showing in the child grid. There is always exactly one active parent. A selected parent is one explicitly chosen by the user (e.g., by clicking the object control or current record marker) for some action such as Delete. There may or may not be a selected parent. There may be multiple selected parents (e.g., by shift- or control- clicking). Generally the active parent has a more subtle graphics than a selected parent. A simple current record marker (e.g., an arrow in the left margin) may be sufficient. Look at file managers such as Windows Explorer (where the folders are the parent and the files are the children) for other ideas for distinguishing active from selected.

• Possibly back up these graphics with dynamic toolbar control labels. When the parent is grid active, label Delete with “Delete [Parent Class Name]” and likewise when the child grid is active. Use tool tips if space does not allow this much text.

• Include a means to clearly indicate the current grid (this is primarily needed for signaling what entities New will create). An enhanced border around the grid or the grid title may be sufficient. Otherwise accentuating the grid title (similar to that done for active windows) may also be good.

• Provide Undo. If the user does accidentally blow away a parent when a child is intended, then one click should reverse the damage. All rich apps should have undo anyway. If necessary, also include a warning for deleting parent or child (as opposed to deleting some text of an entity attribute).