I’d like to get some ideas on how to properly present deeply nested resources in CRUD operations.
Let’s say I have 4 levels of nested resources (resource 1, resource 2, resource 3, resource 4). I’d like to present the user with easily navigatable, non-confusing interface to allow them to navigate along the tree or to adjacent resources.
Idea 1 (Breadcrump w/ Links):
Resource 4 View:
Resource 1 > [resource] – Resource 2 > [resource] – Resource 3 > [resource]
<.. content of Resource 4 view (index/new/edit/show) ..>
Idea 2 (Breadcrump w/ Drop Downs):
Resource 4 View:
Resource 1 > [resource | V] – Resource 2 > [resource | V] – Resource 3 > [resource | V]
<.. content of Resource 4 view (index/new/edit/show) ..>
Idea 3 (sidebar trees):
Resource 4 View:
Resource 1 <.. content of Resource 4 view (index/new/edit/show) ..>
|__ Resource ..
|__ Resource ..
|__ Resource 2
…….|__ Resource ..
…….|__ Resource..
…….|__ Resource 3.
How would you do it? Do you have any examples?
Compared to breadcrumbs (either Option 1 or 2), the tree control (Option 3) excels more at handling a hierarchy than presenting the location of a resource in it. A tree is preferred if your users are going to be moving, copying, or comparing resources, or editing the hierarchy itself. It’s faster and easier for navigating if the user is doing a lot of moving around within the local neighborhood of the hierarchy (it takes only one click to select another resource on the same branch). Two or more branches of the hierarchy can be opened at once to allow easy switching back and forth. Any changes to the hierarchy are immediately apparent.
The tree control presents a compelling visual representation of the hierarchy. In my experienced, even novice computer users grasp the concept if they can grasp the concept of a hierarchy at all. In contrast, the linear representation of breadcrumbs can make users unaware a hierarchy even exists. The act of opening a level in a tree control to drill down into the hierarchy provides a strong visual link between the current level in hierarchy and the tree control. With breadcrumbs, the place where the user clicks to drill down and place the breadcrumbs appear are separate making for a tenuous association. Users often neglect to use breadcrumbs (opting instead for the Back button), and I suspect one reason is that, since they weren’t attending to the breadcrumbs while drilling down, they’re not sure the upper levels of the hierarchy in fact represent places they’ve already been.
For these reasons, a tree control is better for a user exploring a hierarchy. However, one could argue that if users have to explore your hierarchy, maybe you need to make a different hierarchy. Most of the time, you want users to zero right in on the resource they want, not muck about up and down dead ends looking for it.
For simply presenting a resource’s location in a hierarchy, the tree can be problematic. When there are large numbers of items in a level, upper levels can scroll out of view, disorienting the user: they can’t see the upper levels of the hierarchy and may even lose track of how deep they are in the hierarchy. It also adds to the work to jump to alternative resource several steps up in the hierarchy. A tree control also means the users have to explicitly close (collapse) levels they are no longer using. That’s helpful for working on a hierarchy, but adds work for simple navigation. Neglecting to close unused levels contributes to important information scrolling out of view. Finally, the tree control consumes more real estate than bread crumbs –real estate that may be better used to show the resources.
Bottomline: use the tree control if the task emphasizes the hierarchy more than the resources.
As for deciding between Option 1 and Option 2, I’d try Option 2. I doubt the addition of the dropdown arrows will confuse anyone, and some users will use them, saving themselves some time when navigating to other resources of a given level.
If the user’s task is simply to navigate to a particular set of parameters at the “leaves” of the hierarchy, I probably wouldn’t use any of the above options. Instead, I’d use a chain or stack of dropdown lists. At first, there is only one dropdown. When the user selects an item from the dropdown, a new dropdown appears opened below it and the user’s focus is automatically moved to it. This continues until the user gets to the end of the hierarchy, at which time the window displays the parameters using the appropriate controls (e.g., text boxes, option buttons, checkboxes). This keeps drilldown visually associated with the representation of the hierarchy while maximizing real estate for the parameters.