Nested Creation Forms

Question

This question is about how to create objects in a relational database without a ton of popups.

I'm working on a web app that has forms within forms. That is, you can create linked objects within the object creation dialog. Here's an example to illustrate the concept:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Etc...

Jewels could have multiple magic powers. Or whatever. (I'm actually working on a financial product.)

Any good ideas about how to do this in a non-ugly, non-confusing, preferably one-window way?

-- Edit 1 --

Here's more information for my specific situation. I'd prefer to keep this more general, but if a good design only shows up for my situation, that would be fine. Let me know if there's anything else you'd like to know!

• Users are both noobz and power users. Some use this application all day, and know their way around, others log in once or twice just to change an important setting / make a new item.
• This form is being used to create items for clients. They want it done quickly, and with low chance of error.
• This application is used in a corporate banking setting. The primary user is an account manager for major companies. (These users spend a lot of time in the application, creating things for clients.)
• This pattern comes up a lot. Sometimes it only goes 2 levels deep, but in some cases it goes many, many levels deep. (15~20) There may even be cases of recursive loops. I'm not sure. For the sake of this question, I'd prefer to assume that it's infinite. (I'd accept an awesome answer for a finite amount though, if it's super awesome.)
• Individual items can be pretty complex. Up to ~100 form elements. Some item forms have odd fields too like long lists / document uploads / etc...
• There can be different kinds of items on each level. Ex: A Person could also have Enchantments, Powers, Friends, etc... I should be able to create these from the Person form and have them added to my Person.
• Each level can have multiple properties for the item. For example, a Jewel may have weight, color, combination logic (rule references that keep it from being combined with certain other Jewels,) or Magical Powers (references to other objects.)

-- Edit 2 --

It would be ideal if answers accommodated all relationship types. (Ex: one-to-one, one-to-many and many-to-many relationships. That is, the Dagger object could be owned by Bob alone or shared by many People.

I know it's a lot to ask, but I really appreciate the ideas!

Answer 1

This smells a lot like a folder structure, where you can add as many levels and as many items per level as you please, with deep nesting.

I would imagine that a similar view would occur more natural to the user:

This mockup builds upon the idea of the user working "top down", thus the "add new item" element is at the bottom. The user could collapse individual items and there's a multitude of options (and already-learned metaphors) to indicate nesting and all its implications.

Still, it's difficult to make an informed suggestion with the limited amount of information we have:

• Are we dealing with power users or not?
• What environment will this be used in?
• What's the primary task a user is going to want to achieve?
• How deep will the nesting usually go?
• Will the nesting have a minimum/maximum level?
• How complex are the individual items going to be?
• Can there be different kinds of items on one nesting level? (e.g. "Gems", "Ammunition", "Enchants" for Equipment)

etc. pp.

-- UPDATE -- With the added information I'm thinking of something like this:

For the power users, adding a new item should just have a shortcut (CMD/CTRL+N) that adds a new child or sibling item, depending on what's the more common case. Advanced shortcuts (CMD/CTRL+SHIFT+N, CMD/CTRL+ALT+N) could cover adding child/parent items. Especially for power users, keyboard navigation would be key (see what I did there?). They could browse the items with the arrow keys and the form with TAB, enabling them to get around the screen really fast.

The mockup doesn't cover the casual user (save for the drag to add new item-thingy I thought was cool) – they'd probably need more guidance on how to delete items. Also the case of a the item list growing beyond screen borders has to be thought through, especially it's scrolling behaviour: Should it scroll completely or should the current hierarchy always stay visible (e.g. scroll only non-relevant items and always preserve the current selection tree at the top?

Answer 2

I think this all depends on how many levels deep you're going to go. As always, one size design does not fit all situations.

If you really must keep all sub-forms on the same page, the below is the best I could think of for the situation. The general thought is you have your main form, then when you click the New button on the toolbar of the child area, the child area collapses to a sidebar. Then next to the sidebar you have a new mini-form for editing/creating your element. If you have further depth to your data structure, then you would just stack on more sidebars.

Obviously this solution gets more and more weak the deeper your data. If your data is more than a couple levels deep, or one of your levels requires a lengthy form, I would strongly urge just having modal dialogs or new windows to enter the new data. This way your users will be able to focus more on each "tier" of the data and won't just be quickly and sloppily entering in layer upon layer of data. Sometimes it is good to pace the user.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 3

If all your items only have one user-visible field (name) you could get away with using a combo-box (i.e. autocomplete); as they're typing, dynamically look up the matching items in the database, and if there are no matches (or the user doesn't select any match) and they press comma/return/some other key, that item is keyed as a new item.

This allows you to then implement an accordion metaphor (similar to what Christian mocked up in his answer) to manipulate child models (e.g. jewels).

The final outcome ends up something like this, then:

^{download bmml source – Wireframes created with Balsamiq Mockups}

As you can see, you can theoretically continue nesting at each level, and you could extend the equipment attributes box to include more than just jewels if you prefer.

Answer 4

Imagine your nested forms as a carousel of forms so, this is what you could do,

As shown in the mockup, when a user click on new equipment, the new person form could slide left and go out of view and the new equipment form could slide in from the right, mimicking a carousel.

The most important bit about nested forms or redirecting a user to another form(from a current form) is to assure him/her that the previous form data isn't lost.

So, in this case, when an old form slides out and a new form slides in, you could have a button/notification which tells the user that they could save this current form and go back to the previous form and that their changes aren't lost. I've used a button to solve this problem, you're free to choose a better option if you have one in mind.

Answer 5

You can use within-app tabs. One you create an object, a new tab opens up and you either go there or go on working on your object. This lets you go as many levels deep as needed, you don't have a bunch of nested dialogues, you can always switch from one entity to the other and you have a lot of real estate for each entity. Also, this being a web-app, you can count on users already being familiar with the tab navigation model.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 6

I have several problems with this app.

For a general solution, Christian's is pretty fine, except I feel it's cluttered. It's not Christian's fault per se: it's a cluttered approach.

Also, managing a tree widget on mobile is pretty hard itself. I love OmniOutliner for iPad, and I think they have the best tree-management approach so far, but it is hard still.

We have an additional constrained compared to a normal TreeView: each level contains exactly one type of object.

A big question for me wether the objects are shared or they do belong to the root. An example could be from an RPG: all humanoids can, let's say, wear the Magic Ring of Healers, and there's an unspecified (probably infinite) amount of such rings in the world, and no ring has special properties or there's no connection between their current owner.

In this case, addition of new type of rings rarely happens, usually "shared type" kind of ownerships don't need additions often.

Therefore, it's pretty fine then to put away the previous context for a bit (let's say, simply open a modal window, and this has nothing to do with iOS constraints), and ask for the necessary details to create a new kind of ring.

You can "avoid" modal windows by providing a breadcrumb.

^{download bmml source – Wireframes created with Balsamiq Mockups}

(Back also saves)

When the thing to edit is part of the object, it's better if it's inlay I guess:

^{download bmml source}

Also, it can be that actually there are multiple flows which have to run in parallel and it'd be better if the screen would be divided. Unfortunately for us, we don't know the real application with its real domain, and we don't see how frequent is addition to each of the domains and when does it occur (eg. when the customer is right in front of them or in the back office)...

Answer 7

You could display the levels as a threaded tree, where users can expand any desired level.

Example: