A nice side-effect is that the nav menu is displayed on every single page which adds some visual statility.

However, one area that isn’t so black and white to be treated in this way is interfaces where you need users to immediately see the effect of their changes, or where the view itself is so minor that it doesn’t warrant taking people off to a separate place.

For instance, take a user scenario for an application I am currently designing. As part of a bigger process (creating a website from standard building blocks) users must decide who they want to have access to their site.

In this particular scenario they have a view (the list of people who have access) and a form (the task of selecting other people and giving them access). In my mind, all this can be done on one screen, but with a clear visual separation between the view and form elements. As users add new people to their list, the view updates to reflect their changes.

What this article appears to be saying is that the view and form should be completely separate, but in my particular example I think that the user experience would suffer from this approach.

Be interested in other views on this…

I think the logical discussion of View/Forms is very relevant and welcome, however I am not sure that it always needs to be implemented in a strictly separated manner. There are many devices that can be used to segregate a page into distinct yet related areas; consider section colouring and font weights.

Overall, I think so long as one carefully considers the application of principles like View/Forms carefully then implementation can largely be tailored to the situation, flow, look and feel or what-have-you.

just my 2 pennies…

I think there is merit in the Views/Forms approach, particularly in complex, multi-form applications.

Although I don’t believe there needs to be a clear cut separation in simple apps like a user access form, I do believe the user can benefit from, for example, navigation buttons/links being removed from complex form screens while they are completing a particular task. I agree that this adds a step of navigation where it isn’t always needed.

Overall, I like the idea, and agree with many of the points. However, I do wish the figures were labeled, as they were referenced

As with all UI guidelines, my point should obviously be prefaced with the phrase, “depending on the situation.” Unfortunately that ends up making everything sound like more of an off-the-cuff suggestion than a well-considered guideline.

I agree that there are definitely cases where a simple form can be successfully blended with a view. An excellent example is right in front of our faces — the Add Comment area on this page. In this case, the form seemlessly fits into the flow of the page, minimizing the chances of the user leaving the page without submitting their changes. This is not typically the case with more complex forms however, and almost never the case with forms that allow the user to manipulate one instance out of a collection of objects. See the Buy/Sell page of the Motley Fool’s portfolio trackers for an example of what not to do .

As for the figure numbers, it’s my fault for forgetting to submit captions with the article. Hopefully the friendly volunteer editors will have a chance to add them in their copious spare time.

There are limitations to what “web applications” can currently do, mainly due to technology limitiations.

However, if you are designing “web appliations” where you can require end users to have certain brower type, versions, and OS support, there are alternatives. For example, using remote http calls using javascript, applets, or flash…..

I work as a ui/info arch for a financial web application, and three years ago I went down the path of distinctly seperating the ‘View’ and the ‘Add/Edit’ interfaces.

Thanks for validation!!

Before you scoff, read me out. Using the e-mail address example from the article, we see that a simple and separate edit page can support an easy task. But what happens when data comparisons are needed to correctly edit your data? What if there was a list of fifty e-mail addresses, to which you wanted to add five new ones? Wouldn’t it be easier if the current list of email addresses were readily available, on the same page from which you were submitting your new entries?

The need for a current data view while simultaneously editing the data would grow as the data complexity grows. On a portfolio allocation screen, for example, it is much easier to contemplate changes while viewing your current allocations. One need only recall how many times a printed-out screen dump of one’s “Current Allocations” as been held in-hand as one attempts to reallocate a 401k fund, to understand this. Those saying, “Never!” have obviously been editing their funds by using multiple open browser windows, which is really the same thing.

I’m guessing that the number of confounding variables that would necessitate a “current state” read-out to support editing is low, somewhere around four or five. It’s just too difficult to juggle more than that in your head.

…and I offer the usual weasely disclaimer; this all depends on the actual complexity of the task and variables.

Good article yet again. You lay out a nice baseline way of solving this problem which most web app designers will bump into at one point or another.