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


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!

  • Does the nesting go any deeper than the 3 levels shown in the wireframe?
    – Matt Obee
    Sep 6, 2012 at 19:58
  • Yes. Definitely. Sep 6, 2012 at 20:07
  • Does the user need to be able to edit and delete objects after creating them?
    – Matt Obee
    Sep 6, 2012 at 20:11
  • Yes. Each object should be fully create / editable on it's own. Sep 6, 2012 at 20:37
  • As I can understand, your use case is to give user ability to create a new person and then fill person properties, right? Why you have to do it in a single window? Sep 7, 2012 at 10:03

7 Answers 7


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:

enter image description here

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:

improved mockup

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?

  • Good point. I'll address those questions in an edit. Interesting design! Sep 24, 2012 at 21:10
  • K. I've added details to the question -- let me know if I'm unclear at any point. I like where you're going with the list. Did you have a specific design in mind? How would this work with form elements? Sep 24, 2012 at 21:25
  • So, do I see it well, that you're essentially building a list-detail view with a tree as the "list" and an edit form as detail? While I agree that it's a pretty good general solution (esp. for infinitely deep lists), in my experience, it immediately brings an "I need a pilot license to understand this" attitude. I wonder how experienced @LorenRogers ' users are. Some banks grab some fresh graduates and they leave in a year. This interface is not for them...:( But perhaps the problem itself is complex
    – Aadaam
    Sep 25, 2012 at 11:57
  • Yes, it's a complex point to start from. On the other hand, as your example shows, it's a view everybody knows. Windows users know it from the explorer, mac users from the finder. It is a well-established pattern. Also, many web-applications are using hierarchical menues on the left (e.g. wordpress), so the basic principle I think is relatively easy to comprehend. Granted, these are all assumptions and the true practicability can only be determined by testing with the actual users.
    – Christian
    Sep 25, 2012 at 12:26
  • Wow. This answer is awesome. I'm not sure if it'll apply to my specific case, but I really like the preview-detail concept. Also, to delete items, you could do a gmail-like thing where you select items with checkboxes and do bulk actions on them. You could also delete from the detail view, just like email. The more I think this through, the more I like it. Sep 25, 2012 at 14:08

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

  • 1
    Interesting! I like the slide over aspect here. Seems like it may be very intuitive / clear what's going on. I've been considering doing something like this, but vertically. I think there may be a way to allow infinite recursion using a vertical layout and the general concept you pointed out. Sep 7, 2012 at 18:23
  • Love the answer but just worried about the "infinite forms" aspect as @LorenRogers pointed out Sep 25, 2012 at 10:59

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.

  • Perhaps I'm misunderstanding your idea, but I don't think this would work recursively. What if I wanted to create a Jewel for Bob that didn't exist? I'd need to specify the magical powers, weight, color, etc, of the Jewel before it could be added. I don't see any way to fill in those properties for the new Jewel in your design... (Perhaps I've missed something?) Sep 25, 2012 at 13:55
  • Also, this seems a lot like @GotDibbs 's idea. Is it similar? Sep 25, 2012 at 19:05
  • @Loren: You would be able to create an additional jewel by entering its name into the autocomplete box after "Onyx". As I said, this design really only works nicely when the only attribute you're adjusting is name. It's possible to extend this to more layers of depth (where clicking the "Ruby" button could spawn a sub-sheet) but it could get quite unwieldy. You can conceivably add additional attributes in the subsheet form if you like (weight, colour, etc.) simply as additional form fields.
    – Kit Grose
    Sep 25, 2012 at 23:45
  • @Loren: and yes; it's quite similar to GotDibb's suggestion, except that his requires a "new equipment"/"new jewel" form and this design only requires forms for modifying attributes.
    – Kit Grose
    Sep 25, 2012 at 23:49
  • 1
    @KitGrose I really like this answer, and it could have application for another situation that I'm designing. Do you happen to have any examples of it functioning in the wild?
    – Alex
    Mar 11, 2013 at 1:00

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.

enter image description here

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.

  • 1
    I like the idea of a carousel, and I think it could work really well in specific situations, but it's essentially the same as having pop-up windows right? The difference is that the windows are just shown one at a time. It's really interesting, and I hadn't thought of it, but I'm probably going to go with another option. But this is an awesome idea for kiosks, embedded systems, etc... +1 for a general answer. Sep 25, 2012 at 13:45
  • Yea, agree, it's as good as opening up another window but the slide just distracts the user from thinking so. But you're right, mine might not be the optimal solution. And I assumed the fact that all the forms are going to have the same number of fields. +1 for the question, got me thinking! Sep 25, 2012 at 13:47
  • Cool stuff. Yeah, I've updated the question to mention that there can be multiple fields on each level. Thanks again for the idea though -- someone else may find it really useful. Sep 25, 2012 at 14:00

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

  • Interesting concept, but I'm not sure how well it would work for showing multiple items on the same level. For example, if bob has both a Dagger and a Magic Power, how would this be represented? Would the Dagger form close and the Magic Power form take it's place? Does it open in addition? Perhaps I'm just confused about how this design works? Sounds promising though. Sep 25, 2012 at 13:49
  • Everything opens in addition, you only close tabs explicitly. It's a solution I've used for B2B systems very similar to what you describe and it works like a charm. Sep 25, 2012 at 13:59
  • Do you happen to have a screencap of a final system? I'm just not sure how tabs would show relationships. (Do they just not show them?) The fact that you have successfully used this pattern gives your answer a lot more weight. I'd love to hear more about how this worked in implementation. What were your users like? Sep 25, 2012 at 14:09
  • I don't have any screencaps I'm allowed to share, but I can describe how it worked in broad terms if you like. But this isn't the place for it, you can email me at [email protected] and I'll be glad to share what I can. Sep 25, 2012 at 14:19
  • Oh, and no, the tab "heads" don't show relationships. The relationships are visible within the forms. E.g. Bob The Barbarian's form will have a list of all his items, and one of them will be the sword. The sword's form will have a list of all its jewels etc. Sep 25, 2012 at 14:23

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)...

  • Good point about mobile. I'd forgotten about that. Also, regarding your question about object ownership, are you asking if it's a one-to-many or a many-to-many relationship? Ideally, it would work for both. But I didn't specify. I'll add that to the question. However, I'm not sure that breadcrumbs would work well if it's not a one-to-many relation. (Since there could be other references to the new object.) In this case, it seems like it's the same concept as Vitaly's answer. Am I misunderstanding your idea? Sep 25, 2012 at 19:13
  • Vitaly's solution is similar, but at him, the tabs are merely open windows, while here, it's a breadcrumb. A tab system is randomly navigatable, while a breadcrumb is only navigatable sequentially: you either go back one (or more) steps, either abandoning or saving your changes in the meanwhile, or you can open another level of detail. Depends on the situation which one is actually better. In case it's a many-to-few relationships (eg. account to package types), then you can expect the fews to rarely change. Try not to make too universal solutions: solve the real, existing ones well first.
    – Aadaam
    Sep 25, 2012 at 19:18
  • I see -- you're right. I suppose for my specific case, I would have to require that the child item is created before the parent item can reference it. This may actually work better than the tab solution, because you'd need to select the item after you've created it. With this design, it can be automatically added. Is this what you were thinking? Sep 25, 2012 at 19:40
  • Also, what problems do you have with the app? I know that I'm not giving direct details, but I'd prefer to keep this general instead of digging into the details of financial tools. I don't think the specifics of my situation would add much to the conversation -- do you disagree? Sep 25, 2012 at 19:42
  • @LorenRogers: yes, with all my respect, I do disagree. That's because I don't understand the actual flows which happen. I'm pretty sure, when a customer stands in front of an office clerk, the office clerk isn't needed to create 5 levels of nested, detailed information. There's no such task. We're trying to help you to build a generic framework for something which is much-much more specific in practice, and I feel that we can easily miss the point by not knowing what are the specifics which we could actually exploit in order to simplify an inherently complex problem.
    – Aadaam
    Sep 25, 2012 at 21:28

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


enter image description here

  • This seems like a duplicate of @Christian's answer. Could you elaborate on how this is different? Sep 25, 2012 at 15:46
  • Same difference, its the best design for what you need since you can have an infinite number of levels. However, it would if you could define what rules exist for your application. I'm sure there must be certain conditions which prohibit the addition of more levels, only allow certain values to be selected from a lookup table, etc. etc.
    – Joe R.
    Sep 25, 2012 at 19:06
  • 1
    I still don't see how this is a different answer, or how it would work. Please edit your answer to show a more detailed workflow for your idea. Sep 27, 2012 at 14:36
  • 1
    Do you understand what "Same difference" means?.. It's the same concept as Christians answer. Try running regedit.exe on your computer so you can see how it works.
    – Joe R.
    Sep 28, 2012 at 5:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.