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.

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:

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?

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?
–
Loren RogersSep 24 '12 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
–
AadaamSep 25 '12 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.
–
ChristianSep 25 '12 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.
–
Loren RogersSep 25 '12 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.

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.
–
Loren RogersSep 7 '12 at 18:23

Love the answer but just worried about the "infinite forms" aspect as @LorenRogers pointed out
–
irrational_paiSep 25 '12 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).

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?)
–
Loren RogersSep 25 '12 at 13:55

Also, this seems a lot like @GotDibbs 's idea. Is it similar?
–
Loren RogersSep 25 '12 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 GroseSep 25 '12 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 GroseSep 25 '12 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?
–
AlexMar 11 '13 at 1: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.

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.
–
Loren RogersSep 25 '12 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.
–
Vitaly MijiritskySep 25 '12 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?
–
Loren RogersSep 25 '12 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 mvitaly@gmail.com and I'll be glad to share what I can.
–
Vitaly MijiritskySep 25 '12 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.
–
Vitaly MijiritskySep 25 '12 at 14:23

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.

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.
–
Loren RogersSep 25 '12 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!
–
irrational_paiSep 25 '12 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.
–
Loren RogersSep 25 '12 at 14:00

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.

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?
–
Loren RogersSep 25 '12 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.
–
AadaamSep 25 '12 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?
–
Loren RogersSep 25 '12 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?
–
Loren RogersSep 25 '12 at 19:42

This seems like a duplicate of @Christian's answer. Could you elaborate on how this is different?
–
Loren RogersSep 25 '12 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.
–
FrankComputerAtYmailDotComSep 25 '12 at 19:06

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.
–
Loren RogersSep 27 '12 at 14:36

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.
–
FrankComputerAtYmailDotComSep 28 '12 at 5:14