Comments on Views and Forms: Principles of Task Flow for Web Applications Part 1

Bob Baxley — Fri, 26 Jan 2007 14:51:21 GMT

Thanks to all of you for the kind and encouraging comments. Always nice to know that people are reading and enjoying.

To respond to Jennifer’s question, my point is exactly that there should be one page for looking at the information and another for editing. In addition, the editing page should NOT (generally speaking) include navigation elements other than help and explicit submit and cancel buttons.

If you think there are details in the information that the user may need to explore before editing, you may be able to identify a rather limited set of such details and surface them on the view page itself.

As for an edit button, in most cases you can simply link from the data rather than having to include an explicit button. For example, if you had a calendar and each event was a link, you can use the link to navigate to the edit page. Hope that helps.

To Uday’s comment: totally agree that things can get a LOT more complicated than what I’ve described. If somebody can help me install PeopleSoft on my iBook perhaps I can use some more complex examples :^)

I’m not sure how to respond to all of your bullet items short of seeing some examples but I can tell you that the next article deals with two other task flows, wizards and guides, so hopefully that will address some of these issues.

To your final point about managing data manipulation across several pages, I think you always have to remember that HTML is a relatively limited environment and may not be appropriate for such complexity. That’s not a punt, just a recognition of the fact that a simple technology may not be the right environment for a complex task. Put another way, you can’t buy a house at an ATM.

Jennifer — Fri, 26 Jan 2007 14:51:21 GMT

This is a great article. It’s well-thought out and clearly written. It will be very helpful to me.

I’m curious about how you would apply this model to viewing and editing record details, when the view and form provide the same fields.

Imagine an application where customers are listed in a table. The customer ID is a link to a details page for that customer. The user clicks it, views the details, and sees something he needs to change. Does he need to click an Edit button to make the fields editable? Would the page change to remove the navigation elements?

I like the views/forms model, but it seems to require view vs. edit modes. Is that how you would apply it to this situation?

BTW – Thanks for sharing your experiences and ideas. I always look forward to seeing your articles on this site.

Bob Baxley — Fri, 26 Jan 2007 14:51:21 GMT

Unfortunately Convea requires IE 5.5 running on Windows. Without getting into the whole religious debate about open standards, I’m not sure you can call yourself “the best DHTML application ever built” when you only run on one browser on one operating system, even if that particular combination is the most dominant.

Erik — Fri, 26 Jan 2007 14:51:21 GMT

Try Convea http://www.convea.com as a good example of a web application.

Erik — Fri, 26 Jan 2007 14:51:20 GMT

Try Convea http://www.convea.com as a good example of a web application.

Erik — Fri, 26 Jan 2007 14:51:20 GMT

Try Convea http://www.convea.com as a good example of a web application.

subimage — Fri, 26 Jan 2007 14:51:20 GMT

Hey Bob,

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.

David Dunkle — Fri, 26 Jan 2007 14:51:20 GMT

Here’s a different perspective on when a combined view/edit page would be useful; when the data being viewed is complex!

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.

Sanjiv Sirpal — Fri, 26 Jan 2007 14:51:20 GMT

I’ve only given this article a brief review, and I find that the Author has hit the nail dead center.

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!!

VegasLaunch — Fri, 26 Jan 2007 14:51:20 GMT

Something that makes this article so helpful and something that should be seriously reviewed and accepted is that multi-language will be required for all sites in the future.

ji kim — Fri, 26 Jan 2007 14:51:20 GMT

To comment on Niall Cook, there are cases where it might be lot more productive for the end user to view data and change data in one screen.
Good example might be a call center or customer support applications where end user has to make changes to the view data quickly – going to another screen to make changes might add more 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…..

Bob Baxley — Fri, 26 Jan 2007 14:51:20 GMT

Thanks for the comments. Good points all.

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.

Erik — Fri, 26 Jan 2007 14:51:20 GMT

For a few pennies more…

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 ;)

Neil Moodley — Fri, 26 Jan 2007 14:51:20 GMT

I think one needs to differentiate between a discussion of the logical and physical aspects of Information Design.

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…

Niall Cook — Fri, 26 Jan 2007 14:51:20 GMT

I like this way of looking at web applications – a clear set of principles that could be implemented by anyone.

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…