I have this new requirement for an application UI design. There is one instance of the app wherein the user needs to input a lot of info, the recommended wireframe was to put a 3 level tab design (image reference added below), I wanted to know whether there is another UI pattern which I can use to achieve this functionality.

Thanks @Chris, This is something which can be very useful when entering data in large volumes, using this format lets the user to switch to any state and do the data entry. thanks for that valuable suggestion
–
SullanSep 23 '11 at 4:30

Almost anything else. Filling in that quantity of data manually is very time consuming, very error prone, and very depressing to have to do. If your users have a choice, then they will go elsewhere. If they do not, they will hate you.

I would suggest that firstly, you need to be very harsh about whether you actually need every one - remove any from this form that are optional, and allow the user to add them at another time.

Then, do not split it into so many pieces - give the user a clear view of how many pieces of information they need to enter. Divide sections up visually, with graphical breaks, so that it is not all in one. And fit as much as you can into a page - put scroll bars, rather than new pages or tabs. The reason is that it gives a very straightforward view on how much is to be done, and it feels like one stage, not 3 stages, which makes it easier to complete.
–
Schroedingers CatSep 20 '11 at 11:01

depends on the context. In the one page approach you don't get the advantages of things like progressive disclosure. In the one page approach if the system is used frequently, splitting the form into different tabs or 'easily identifiable sections' allows the user to zone into relevant parts of the system faster.
–
colmcqSep 20 '11 at 14:17

I am all for visually partitioning the page, but as everything has to be filled in, it is often easier to see the whole task. So help to focus by using graphics, but show the scale of the form-filling task being undertaken. IMO - it may not be right in this case, but I think it should be considered.
–
Schroedingers CatSep 20 '11 at 15:05

1

I use both approaches, but hugely context dependent.
–
colmcqSep 20 '11 at 15:10

As a lot of UX decisions are. And yes, they are both valid, depending on the context, which includes the application AND the user-base.
–
Schroedingers CatSep 20 '11 at 15:19

If the data entry is a process, the idea of providing navigation for a linier form process is a little odd. Better make a stepped process users can next/prev through or jump to a specific point along the line. Allowing user to navigate to any part of a form at any time through levels of heirachy removes the linier nature and in tern how far through the process they are. Better keep it linier and allow a 'jump to' contents tool. With a form of this scale some kind of percentage complete indicator, or a decreasing 'todo list' indicator fo some kind.

Better still, as others have suggested, (if possible) make the data capture much simpler - reduce the required fields to a point where completion wouldn't take someone an entire day and require such a complex complex UI.

If you have 3 levels of tabs each with say 4 tabs, and each page having say 4 fields, you will be asking someone to fill in 4^4 = 256 fields. Do you seriously need that much information from someone using your product?

If you need to collect so much information you really should ask for different pieces of relative information over a workflow of different screens. To require so much information upfront will only upset your users.

Also to validate your users input on both server side and client side would be a nightmare to develop.