UI pattern to allow user to add item with unlimited sub-items

Question

Hi all

I'm writing an ASP.NET app. I need to include a page where the user can add an item which has several sets of subitems, each of which sets is unlimited in number. The subitems themselves contain between 10 and 15 fields, so need a fair bit of UI space.

As an example of what I mean, the user needs to be able to add a Business record to the system, including any number of Employee records and any number of Asset records.

The way I normally do this is by using a MultiView control with a set of tabs at the top. The tabs switch between the Views of the MultiView. The first tab will be for the Business record, the second will be for Employee records, and the third for Asset records. The Views for Employees and Assets are initially empty bar a button to add a new Employee (or Asset). When this button is clicked, the page is posted back and a user control is added dynamically to capture the details of the Employee (or Asset).

There is one save button that saves the whole object graph to the database.

This is quite complicated to program and maintain and I usually encounter headaches to do with managing ViewState for the dynamic user controls. Obviously, the ViewState on the page can also become quite large, making the page quite slow.

The advantage is that it is quite an intuitive UI for the user to understand, and the user can add everything and check it all before saving anything to the database.

Can you please suggest any other UI patterns that you might use for this and any advantages or disadvantages?

Thanks

David

Answer 1

Hi,

Have a look at Quince, a UX pattern repository that can help you lift some inspiration : http://quince.infragistics.com/

Regarding the viewstate, if you're not doing MVC without state, have you considered the following tricks:

• Disable ViewState on non-context elements (ie: labels)
• Compress the ViewState by defining a custom handler that bzips>base64 encodes. You'll be surprised at the amount of space you end-up saving on the client
• Store the viewstate on the server, create a request id, and tie this id to the app cache with an expiry window = to the session lifespan (non-sliding), then substitute the viewstate with your guid back and forth.

Cheers, Florian

Answer 2

I like your design of the multiview control using the tabs to navigate between the views. For me, I've had times with large views and a time when I needed to bypass some of the steps. You are almost on the edge of a wizard control, but I see each of your steps way too complicated to use the official wizard control.

In my case, I separated each view into a specific web page. Using your example, consider creating three pages: Business.aspx, Employee.aspx and Asset.aspx. If you have code that validates the web forms, then can reference it in each of the web pages. I did this because in my situation, I was adding many records on each "step". I didn't want to worry about the overhead and room for error of having to properly recreate the viewstate with each post back. Your Business.aspx page knows how to take care of itself and be valid without having to worry about valid Employee records or data. When I hit this problem, my multiview pattern made it easy to break the views into separate pages. Oh, say someone browses directly to Asset.aspx, I would either display a message explaining the user jumped the gun OR make a simple view form to allow them to select the respective Resource and/or Employee before the Asset can be added.