How do you deal with complex data entry, creating related records within a record within a record?

Question

The database I am dealing with consists of objects that are related to each other in multiple (non-hierarchical) ways (documents, persons, places, events,...).

To create a new record the user has to choose from various select lists of other objects or create a new object record, which then might lead to the creation of new object records and so on...

In any case it might be a long way for the user to complete the creation of a record and she might have to add information later on.

See the screenshot for further understanding:

Click to enlarge

I'm not sure how to solve this problem: A wizard might be to restrictive. What about subforms that slide out, when needed? A tree layout as navigator? Any suggestions?

Thank you for your input.

Answer 1

I would describe this situation as: dynamic nested workflows.

• Dynamic because you cannot tell ahead of time how deeply nested the workflow will be (user may not create any new objects, or may create multiple carriers and persons).
• Nested because the workflows for creating a carrier and then a person are nested within each other.

The dynamic nesting makes it difficult to lay out this kind of workflow in a wizard.

A common UX for nested workflows is stacked modals. The reason for this is, the subworkflow(s) need to be completed before progress can be made on the parent workflow, so modal windows provide appropriate blocking behavior to ensure this happens. Here are some stacked dialogs from a Microsoft Windows interface:

Stacked modals are not a great layout in general because they create visual clutter, but remember that in a UX hierarchy, functionality and usability wins over aesthetics, so in the case of nested workflows that usually drives the design choice.

Answer 2

I've worked with several "flexible" databases which were very powerful. However, when it came to the user interface, the only way my users would be able to handle it was if they were first an expert at that sort of system, and none of my users ever were.

Instead of thinking that the system you described is a definition of the user flow, think that the system does not define a user flow at all, and that you get to build the front end to flow naturally for your users, even to the point of letting them skip some parts and fill them in later. You still have to figure out a natural flow for your users and guide them through it, though, and it sort of sounds like that work hasn't been done yet.

If you do end up needing to provide an advanced way to look at the data, and you have too many options for tabs, the tree structure on the left idea like file folders and files is a comfortable way interact with things. I always include "expand all" and "collapse all" buttons/links above my tree, but that is not strictly necessary. Just be aware that few users will probably be able to understand and efficiently use this sort of interface.

Answer 3

Creating and using data are usually different parts of a process, acknowledging this can simplify the system.

• Creating data is a simple operation on a low level, basically creating the underlying objects for the Owner, Author and Place roles. Perhaps the Owner and Author is played by a Person object, Place could be an Address.

• Using data is what the users does in any useful system, making connections between pieces of information. The Information Carrier seems to be such a connector. This is what the discussed part of the system should do.

By having an interface like the one you describe, basically a database GUI, it will become too low-level for most users, since they aren't familiar with the underlying data. As stated in your screenshot, when the user thinks about a Document he thinks about an Owner and an Author, not a Person, which may be the underlying object for both of them, containing pieces of information unknown to the user, but could be required by the data model.

Therefore, forcing/allowing a user to create a Person in the process of "Connecting information to a Document" is a mental model mismatch and could also be error-prone.

So my suggestion is to split the creation and usage:

1. Create the basic data objects, Person, Address, Picture etc. in another part of the system.

2. The document creation page can now be simplified to only making connections, hopefully everything on the same page to avoid the stack of modal dialogs looming in the screenshot. It should be possible now when it's only about selecting already existing data.

3. If new data needs to be created, do that in the other part of the system, return to the document creation and update the selection fields, manually or automatically.

If new data needs to be created for most new documents, there could be some information problem that needs to be solved, like importing pre-existing data, or even simplifying the data model so much that most relations will be reduced to a text field. The Address could be such a case. It's hard to know without a detailed data analysis.