Best approach to handling complicated forms with related items?

Question

Developer here to pick the brains of the UX pros out there (so please excuse the general lack of UX knowledge on my part).

I am developing a code generation engine that will, out of the box, create forms for complicated data entities that a user might have. Let me explain what I mean by that via example. Say I sell shoes and here is an entity model (in developer parlance) of a shoe:

-Shoe
  --Color
  --Type
  --Store
    ---Address
       ----Street1
       ----Street2
       ----City
       ----State
           -----Name
           -----Abbreviation
       ----Zip

Ok, so my software creates a form for adding a new Shoe to the database. Since a shoe must belong in the inventory of a given store, I must have a store before I have a shoe. Since a store must have an address that includes a State, then I must have a State before I have an Address, and an Address before I can have a Store, before I can have a Shoe.

Make sense so far? Great! So here is the question: is it better to nest these forms so that when I create a Shoe I have nested forms available that allow me to create a new Store (with a nested form that allows creation of a new Address and so on)

-OR-

When the user attempts to create a new Shoe--but there aren't yet any Stores in the database to associate with that shoe (in which case they could just select a store from a drop down when creating the shoe)--should I not show the form at all and just display a message that says something like, "You need a Store before you can have a Shoe. Please go create a Store first and then come back to create your Shoe."

Thanks in advance!

Answer 1

No pig in sight

The Engineering brain likes to approach design problems logically. A solution gets coded logically. The developer's understanding of that code is (roughly speaking) the implementation model.

However, the user interface does not have to be a representation of the implementation model. In fact, I'd say it's usually a burden for end users, since they often don't need to understand how the code works.

Alan Cooper, in About Face, asks why data purity is so important. it's a good question: Why should data accuracy be holier than any other aspect of software use?

Blasphemy

If you're willing to explore the possibility that interdependencies between pieces of data are limiting, at times, and embrace the possibility that one piece of data doesn't necessarily have to be preceded by some other piece of data, then it frees the user to enter things in the order that is convenient to them.

And allowing incorrect data to exist is no big deal—until the point where it becomes a big deal. At that point, you can either:

• Make an assumption—and allow the user to Undo the assumption if it's incorrect, or
• Ask the user to help resolve the error.

All this has implications for the architecture, and your approach to coding. Undo doesn't just happen. Postponing data validation until it matters doesn't just happen.

What shade of lipstick?

Often, a UX practitioner is asked to help after the key decisions have been made. That's what we call a lipstick-on-the-pig project.

So the question you're cleverly asking potentially has a large answer. I'm curious to see what others say in response to your question. :)

Answer 2

One potential solution is to have some "unknown/unspecified" state objects in the system.

E.g. You could start with the software including an "Unspecified" option in your store dropdown. This would be a valid option of the user to choose and your backend could maintain the relationship hierarchy to a store entity.

You can thus maintain al your business rules... However you now have to add one. The new rule is that shoes/inventory associated with the "Unspecified" store is in a 'draft' or unknown state and can not be ordered or put up for sale.

In your view/edit screen for the shoe, you could add a link/button beside the store field to "Add a Store" too. This would allow the user to build out a shoe first, then when ready add a store.

Answer 3

Since a shoe must belong in the inventory of a given store, I must have a store before I have a shoe [...] Make sense so far?

No, sorry but it doesn't make sense. It's an implementation problem/restriction, users may have a different workflow.

Let's be honest, readers who are also programmers know what I'm talking about. To have a logical tree is easier, we insert one record as child of another. No tricky cases to handle, no multiple paths to code.

It's not a technical problem, we're lazy to write code to do it in the right way. However it's not how we expect to work when we use someone's else application.

...is it better to nest these forms so that when I create a Shoe I have nested forms available that allow me to create a new Store...

Our forms aren't Google homepage. We have tons of stuff there, I'd avoid to add even more noise to our UI. Moreover you'd put unrelated things on the same page, making your interface even more confusing.

...should I not show the form at all and just display a message that says something like, "You need a Store before you can have a Shoe. Please go create a Store first and then come back to create your Shoe."

Invalid records (a shoe not associated with any store) should not be visible to customers but users must be able to create invalid records.

It may be because they want to finish later, because they have lunch break or because it's the way they prefer to work (first all shoes and then associated shops). It doesn't matter the reason, the truth is that this is a perfectly valid workflow.

What I would do is to implement two options:

• Postpone. They may insert a shoe without selecting any shop leaving (let's say) dropdown list control empty. Someday in future they may come back to edit this shoe to fill missing fields. More fields you have and more it's important.

• Defer. They may want to create a new shop but don't break their workflow. Now they're inserting a shoe, when they confirm this operation then immediately redirect them to your page to insert a new shop. Of course don't forget to also associate the shoe with the shop.

I think they should be implemented both because they're both reasonable workflows. Of course there is more you have to do (for example a tool to quickly search for not completed records) and useful features you may add (create a copy of an existing record, if it's reasonable for your scenario) but this is the very basic level you must provide to your users.

---

This reasoning applies to every field. You have to insert a new State/Country/Region/Area in your database? Let them write new value and ask to fill required information when they're done with this. There isn't any required information? Don't bother them, add a notification and let them free to fill optional field if and when they want.

Answer 4

If I'm getting it right, my solution proposal would depend on how much importance you give to each created form and how reusable you know or suspect they will be.

About nested forms: I don't think it's a good idea since it adds too much complexity. I would opt for the message option, something like "You need a Store before you can have a Shoe. Create store now"

Then they can create the store in the new page and when finished you should offer a link to go back to the Shoe form and continue the process.

If you want to avoid this depency problem, you could just let them create a shoe form just from inside the "store panel/page".

"Should I let them complete/use the form if there isn't any store?": If you think the users will reuse forms, you could let them create and save them as templates, so they can you reuse them whenever they want, completing tasking easily if the forms have usually common patters.

---

So summing up, I would choose any of these option based on what's most likely to be the most useful/natural/etc for your users (...or the available time to code)

• Let users create Shoe forms (independently from the store form) and save them as templates.

• Offer the link to create a store at the start of the shoe form, with the option of going back in the process before or after finishing the store form completion.

OR

• Let them create a shoe form just from inside a Store panel/page.