Best practice for single-level parent-child control groupings

Question

I have a data relationship like Teachers -> Children. The goal is to select a Teacher in order to manipulate the more user-relevant Child data. You can add a new Teacher, but you can also add a new Child to the teacher.

Is there a good way to structure this layout so that the Add/Edit/Delete buttons do not appear confusing?

My first stab at a layout involved a drop down list of "Teachers" and a grid of sorts to adjust the properties of each "Child". I set the Add/Edit/Delete adjacent to the drop down on the same line. The grid is below with a toolbar containing the Add/Delete buttons for the Children. This seems clunky.

Any common controls that might help or thoughts?

Answer 1

Perhaps a simple tree structure (a la Windows Explorer) with appropriate styling could do the trick. Consider this website: the answers are your teachers, and the comments are your children. They are basically listed one after the other, with children appearing under their teacher (comments under answers), but the styling and explicitly named links (eg. add comment) make it obvious which button affects which item.

For example, you could provide a list of teachers with edit and delete buttons on their left hand side (this website shows certain buttons only on mouse-over to avoid the clutter, which may or may not be appropriate in your case). At the bottom of this list, an "add teacher" button makes it obvious how to add a new teacher to the list. On the right hand side of each teacher, a "students (nb)" button shows, at a glance, how many children take lessons with this teacher and allows the unfolding of the list of these children. Being styled very differently (think answers vs comments), the children are not confused with the teachers, even though they appear in the same list. On their left are the expected edit and delete button, and at the bottom of the list, the "add child" button. The idea is to provide consistent functionality (edit / delete on the left, add at the bottom) for both teachers and children, but contrasting visuals to avoid confusion. Collapsible student lists allow the user to see more teachers at once, making it easier to find the one he/she is looking for.

Using trees has many advantages:

• Users mostly already know how to use them
• They are efficient on large screens as well as small
• They are easy to navigate (just scroll away)
• etc.

Answer 2

When in doubt, split it into multiple screens/pages, think about RESTful application scaffolding, present users with an index list of teachers. Clicking a "view children" button next to the teacher will display a index list of children. Clicking a child will show details or edit that child. An "Add" teacher or child button at the top of the index listing page is standard. It's always tempting to cram multiple levels of data into one interface, but this should only be done if you have a clear idea of why and how.

Answer 3

A lot depends on the screen size that you're designing for. Generally a large screen allows (and hence users expect) to see more levels on one page, but for a smaller screen sirtimbly's solution is good. i.e. show either teachers or children on a page so that it's clear which you're dealing with, while not wasting limited screen real estate with something that I'm not focused on.

If you're on a larger display, you have more space in the first place, so consider "Add teacher" and "Add child" buttons. That way they are unlikely to be confused. Clarity should be more important than brevity.

Answer 4

Off hand, a well-featured master-detail design may provide you the greatest user efficiency and flexibility. The top/left of the window has a scrollable pane holding a table of teachers, while the bottom/right has a scrollable pane holding a table of students. The Students pane shows the students of the teacher that currently has focus (there is always exactly one); a single click on any teacher immediately re-populates the Students table with the appropriate students.

Usually you can have a single Insert button and a Delete button that each act on the active pane (whichever one was last used), which may be indicated by a highlighting (e.g., a colored border or title bar). Ideally, users can edit either table’s fields in place, so there is no need for an Edit button. This design minimizes navigation “excise” associated with multiple-page/window designs.

The design is best when you have relatively large number of teachers and students per teacher, while there are relatively few fields per student and teacher so everything works well in a couple tables. It’s a particularly good design when the users are expected to make multiple changes on a mix of teachers and students or when they need to compared teachers with each other and student of a given teacher with each other. However, this basic design can be enhanced to work well with other conditions too:

• Making the panes resizable allows users to adjust for varying numbers of students and teachers. You may want to allow users to “close” either pane so they can fill the window with just teachers or just students of a given teacher, when they need to focus on only one data class.

• If either teachers or students have a large number of fields, you can include an additional “overflow” pane for secondary fields laid out like a form.

• If the user does not edit or compare teachers often in a session (e.g., usually they just need to work on the students), then you can layout the Teacher pane more compactly like a form rather a table, and show only one teacher at a time. If the number of teachers tends to be few, then the user can change teachers with “paging” controls in the Teacher pane, although your dropdown list is actually a good idea too. If there are a lot of teachers, then provide filtering/querying controls in the toolbar and/or in a separate dialog.

I compare various ways of handling parent-child relations at Taking Panes.