I'm designing a complex form interface for building custom reports. The user can specify a lot of different kinds of information -- far more than will comfortably fit on screen. We will have approximately five separate screens of controls.
We're going with a tab-based layout, where each of the ~five screens is a separate tab. We find that the fields divide naturally into simple categories that our users will understand. The tab navigation and form controls (submit, cancel, revert, etc) will be fixed.
When creating a new report, the user will probably fill out the screens in a certain known order, although they don't necessarily have to. When editing an existing report, they may make changes in any order. A user may need to edit an existing report that they haven't seen or used in months, or at all.
The state of the form may be very complex, and it is subject to interdependent validation rules -- selecting one option may change validation rules for another option on a different screen. This is a consequence of the back-end system, which in turn is designed to follow complex business rules. It is even possible that rarely, changes in business rules or the underlying data could cause a report that was once valid to become invalid (requiring editing by a human).
Because of these factors I feel that it is very important to have some sort of summary view so that the user can see the complete state of the form.
Early prototypes of the form put the tab navigation on the side of the tab content. Each tab label had the name of the tab and a one-line summary of that tab's state. The downsides of this approach quickly became apparent. Most tabs required more summary information, so the tab labels became large, variable-sized, and full of information other than the name of the tab. Some information needed to compute the summary loaded late, so the tab labels moved around. It's also possible that the tab labels could overflow the available space, resulting in a vertical scrollbar for the primary tab navigation.
My preferred approach would be to have the tab navigation above the tab content (with no summary information), and have a separate summary panel on the side. The panel could include as much information as needed without trying to double as navigation, including verbose validation messages (“Because you chose option X, you must make a selection for Y.”). The error messages could even by “hyperlinked” to reveal and highlight specific fields.
However, some managers saw the first one and liked it, so it looks like we may be stuck with it. I'm trying to figure out how to salvage the summary information within those constraints. I definitely feel that I shouldn't put any interactive elements inside the tab labels, because that would conflict confusingly with the navigation function. I'm also leery of putting in colorful text or icons, because I don't want to drown out the tab name. The same goes for stuffing the summary text itself in the labels; full summary information might distract from the navigation and could even push the last labels off the visible area. On the other hand, partial summary information could be confusing, because a user might not understand that some important fields on another tab are excluded.
How can I salvage this? Is it okay to just stuff a bunch of summary text in between the navigation labels? If not, is there some reasonable limit? Am I overreacting by keeping other interactive content out of the navigation labels? And is there some other solution I'm missing?
