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

Written by: Bob Baxley
“Creating web applications that support the full and valid completion of specific tasks, operations, and database transactions, require some understanding of how to manipulate the medium to that purpose. ”One of the first challenges facing the designer of any application is answering the ubiquitous question, “How do I __________?” In the case of a web application examples might include, “How do I register for a class?”, “How do I pay my bills?”, or perhaps “How do I make sure that gets to my mom on the Friday before Mother’s Day?”

The hypertext environment of the Web presumes a style of unfettered browsing and exploration that is not particularly conducive to the full and valid completion of specific tasks, operations, or database transactions. Creating web applications that support the full and valid completion of specific tasks, operations, and database transactions, therefore requires some understanding of how to manipulate the medium to that purpose. To wit, the following few thousand words serve to describe both the fundamental building blocks of HTML-based web applications as well as the three ways in which those blocks can be arranged to provide various types of task flows.

As previously discussed, one of the defining elements of web applications is their support for the editing and manipulation of stored data. Unlike the typical conversation that goes on between a user and a content-centric Web site however, this additional capability requires a more robust dialog between user and application. For example, a visitor to CNN might see something of interest and click on a link, sending a request to the server to send over the indicated story. In such cases, the vocabulary of the user is reduced to something less than that of a nine-month-old baby. The experience provides the user with specificity in their selection of nouns—get me this versus get me that—but their choice of verbs is conspicuously limited to “fetch.”

By comparison the designer of a bill pay application has to support a broader array of both nouns and verbs so that users can more readily converse with the application, saying things such as, “Create a new vendor with this address and account number” or “Pay these four bills the day before they’re due.” Where the user of a content-centric site is mostly confined to the mode of listening, the user of a web application splits their time between listening and talking. And because the client-server architecture of a web application dictates a serial conversation, these types of operations not only require a broader vocabulary; they also require a separate mode.

Although rich-media applications technologies strive to reduce the division between these modes, when it comes to HTML-based applications, the best strategy is to embrace the nature of the medium. This is accomplished by clearly isolating operations into two types of pages: “views” for viewing and navigating, and “forms” for editing and manipulating stored data.

An example of a relatively sophisticated view is shown in Figure 1. This page not only provides for the simple presentation of content and data, it also includes controls for navigating the data or the application—changing the sort order, specifying the type of information to be displayed, or paging through long lists of items. What distinguishes these operations, however, is that they do not result in permanent changes to stored information.

Conversely, the purpose of a form should be the completion of a specific task such as updating an address, recording a stock transaction, or submitting an application. In desktop applications, specific tasks such as these are typically handled through modal dialog boxes. Only by requiring the user to supply complete and valid information, can the application complete the requested operation. Inherently HTML does not provide any ready mechanism for enforcing modality. Although this might initially seem like more of a blessing than a curse, the lack of modality in a web application makes it very difficult to structure tasks in a way that ensures the system is able to do what the user asked.

To help mitigate this problem, it is important to respect the division between views and forms by eliminating virtually all of the navigation options from forms. Global and local navigation links not only serve to distract the user from what they’re doing, they also function as cancel buttons since such navigation links do not typically submit or validate the user’s edits.

It’s worth noting at this juncture that just because something is a ‹FORM› doesn’t necessarily mean it’s a form in this context. As described here, forms result in permanent changes to stored data, necessitating a variety of validation criteria as well as the attendant collection of status, confirmation, and progress alerts. By comparison the forms associated with content-centric sites or web directories, the new Yahoo! Search for example, do not result in changes to stored data and therefore don’t have to validate input or report input errors.

The division of an application into explicit views and forms is what I call the “view/form” construct—the benefits of which include:

  1. A tidy separation of interactions into the two modes of viewing and editing
  2. Providing explicit control over when data is submitted and saved
  3. Reducing the chances of a user inadvertently abandoning edits by minimizing the navigation options out of forms
  4. Reducing the visual complexity of views by moving input controls to dedicated form pages
  5. Providing an explicit and predictable moment to validate user input

Of course the best way to understand the value and implementation of these concepts is to look at some real-life examples.

Problem: How Can I Ensure Users Explicitly Save or Cancel Their Changes?
MovableType’s Weblog Configuration Forms

One such example is found in the blogging application, MovableType. Used to specify a variety of parameters about an individual blog, MovableType’s Weblog Configuration area is grouped into four different forms, Core Setup, Preferences, Archiving, and IP Banning.

In Figure 2, it’s obvious that this is a well-crafted, intelligent design. There is however, one confusing and ambiguous aspect of the interaction design that highlights the importance of clearly distinguishing between the modes of viewing and editing.

The issue is this: the only interface element on this page that actually saves the user’s data is the Save button located at the bottom of the form. If the user clicks any of the other links, buttons, or menus, their changes will be abandoned. This is a particular problem with regards to the links to the other configuration forms since a user could reasonably infer that the Save button would save their edits to all four forms at once.

In other words, if the user made changes to the Archives form and then immediately navigated to the Preferences form, any changes they made to the Archives form would be abandoned. In effect, the links to the other configuration options, as well as the navigation controls along the left and top of the page, all function as Cancel buttons and serve to distract the user from completing their task.

Problem: What Happens After a Successful Submit?
Example: TiVo’s Account Management forms

Figure 3 illustrates a second point of confusion that can arise when views and forms are merged into a single page. In this example from the TiVo account management application, the user has successfully submitted changes to their account and those changes have been saved. However, because the application doesn’t follow the view/form construct there is not a logical place to confirm the result of the user’s action. As a result, the confirmation message is reported at the top of the form that has just been saved.

To illustrate the issue we’ll walk through the entire task flow. First the user navigates to this page. Next they change the values for one or both of the available fields and then click either of the Save Preferences buttons. Their browser talks to the server and after some sort of delay, the page redraws with exactly the same page and form elements but with the somewhat subtle addition of the green text reading, “Success!” Unfortunately, it’s quite likely that most users won’t see this message and will be left wondering if anything happened or not.

In addition, the TiVo design itself acknowledges a problem with the approach by including instructional text next to each of the Save buttons. By contrast, if the design followed the view/form construct, the only way out of the form would be an explicit Save or Cancel button. This would eliminate the need for such text and reduce the number of messages and information vying for the user’s attention.

Fortunately, there is a simple solution all of the problems described in these two examples: redesigning the task flow using the view/form construct and a hub.

Solution: The Hub Structure
Example: Mailblocks Preferences Forms

The structure of a hub is one of the most common task flows used in HTML-based Web applications. As its name implies, a hub is constructed from a single view page and a collection of forms. The view serves as a launching pad to each of the forms with a successful submit from any of the forms returning back to the view (Figure 4).

This example, from the Options area of the web-based mail service Mailblocks, features a view page as a launching pad to the various forms containing user-defined options for mail accounts and other preferences. Unlike the designs shown in the two preceding examples, Figure 5 solves the same problem using a hub.

The view page includes links to the various forms as well as information explaining the contents and purpose of those forms. In addition, the page contains a collection of vital information about the user’s different accounts as well as different commands for acting on those accounts.

One spoke of this hub, the Add/Edit External Account form, is shown in Figure 6. The important thing to notice about this form is the elimination of all extraneous navigation. As a result, the only way the user can readily exit the form is by explicitly clicking the Submit or Cancel buttons located at the bottom of the form. Although the utility navigation links still appear in the upper-right corner, only the Sign Out button would abandon the user’s changes since the Help links opens a secondary browser window.

Compared to the earlier examples, this approach has the following advantages:

  1. Provides an intuitive task flow by providing clear mechanisms for navigating to the appropriate form, explicitly submitting changes, and returning to the initial starting point.
  2. Minimizes the chances of a user inadvertently abandoning changed data by removing extraneous navigation elements.
  3. Minimizes the cognitive load and visual clutter of all pages by dividing the task into specific, focused operations.
  4. Removes the need for a confirmation alert.

Hubs are one of the most useful structures available in HTML-based applications. They can be found in a variety of applications including online calendars, Web-based email, bill pay applications, server configuration applications, and others.

Up Next
In addition to hubs, there are two other task flows commonly used in HTML-based web applications. Next time around we’ll focus on the other two: wizards and guides. In the meantime, I hope you’ll take the time to join the conversation on our newly created discussion list dedicated to interaction design.

(Editor’s note): I’m happy to announce the beginning of Boxes and Arrow’s first discussion list. Dedicated to the topic of interaction design, <“Interaction”> awaits your participation. Please come join the conversation.Bob Baxley is a practicing designer who specializes in interaction design for Web applications and desktop products. He currently runs the Design and Usability teams at The Harris-myCFO and recently published his first book, “Making the Web Work: Designing Effective Web Applications.” He looks forward to hearing from you at .

Bob Baxley

is a writer, designer, and father (not necessarily in that order) who lives and works in Silicon Valley. Specializing in interaction design for both Web applications and desktop products, Bob has worked in a variety of corporate and start-up environments including Adobe Systems, Apple Computer, Epiphany, NetObjects, Ameritrade, Claris, and most recently, myCFO. In 2002, Bob authored “Making the Web Work” (ISBN: 0735711968), the first book to detail the unique challenges involved in the design of Web-based applications and services. He writes about design and technology at Baxley Design as well as a host of other things at Drowning in the Current. Bob welcomes all comments, criticisms, queries, and kudos at info (at)
View all posts by

41 thoughts on “Views and Forms: Principles of Task Flow for Web Applications Part 1”

  1. 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…

  2. 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…

  3. 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 😉

  4. 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.

  5. 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…..

  6. 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.

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

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. I can tell you know what you are talking about Bob, and that Convea must be rubbish as it only works on IE- good argument!

    I guess that makes iTunes, iMovie and every single mac app a heap of shit then?

    Smart people like you make me feel so inferior.

  14. Rich, I don’t know how you’re vehemence and sarcasm add to the debate but to address your point: there is a significant difference between an application that is delivered through the public Internet and an application that is delivered through a desktop operating system. All users connected to the Web have a reasonable and legitimate expectation to be able to use any and all Web sites and applications placed in the public space.

    As a Macintosh user I don’t have an expectation of being able to use Visio anymore than you as a Windows or Linux user have the expectation of being able to use iTunes. I wasn’t making an argument about the superiority of one operating system over another. I was simply making the point that a Web application placed in the public space should be functional for all users accessing the application with a modern, standards-compliant browser.

  15. “There is a significant difference between an application that is delivered through the public Internet and an application that is delivered through a desktop operating system.”

    While I agreed with your article to a certain point (my comments about what I don’t agree with in a bit), I feel compelled to comment on this statement.

    I think you mean to say, “There is a significant difference between an application delivered via http/HTML protocols and standards and an application delivered using desktop OS protocols and standards.”

    Point being that the main difference is in the static nature of a browser using HTML to display content along with a specific server/client relationship. There’s nothing inherent in the “public internet” that creates the distinction. The “public internet” exists in the desktop world (which is how browsers work, don’t forget, and therefore the http/HTML stuff is now a subset of functionality, not seperate functionality which your statement implies), so apps like iTunes are now blending what it means to be a desktop app and a networked app.

    Everything will finally change soon, as in the next three to five years. And probably even to the point that the crippled Views/Forms workflow will go the way of the dinosaur it is.

    “All users connected to the Web have a reasonable and legitimate expectation to be able to use any and all Web sites and applications placed in the public space.”

    All users connected to the web *INSIDE* a web browser application have that expectation, sure. But that doesn’t mean anything in the overall view of the interaction model as it pertains to the web. I’ve long been able to sync my bank account inside of Quicken with my real bank info via a web connection, and can even browse some web content like views on my information, but never I have expected to be able to jump to and read a story. (Nor would I want to.) I can open up a browser and check through and MSDN while working inside of .NET Studio, but I rarely move outside of development stuff with that internal browser. I can browse the music store in iTunes with specific web content, and never do I feel I have the expectation to want to jump to while I search through stuff I want to buy.


  16. Andrei: Thanks for your comment. You’re absolutely correct about my having used the term “internet” when what I was referring to was the World Wide Web as experienced through a Web browser. I couldn’t agree more with you about the blurring of the lines between desktop applications and network applications and think that trend represents some of the most interesting and useful products being created today.

    As for your comment that the view/form construct is a “dinosaur” that will go away in three to five years, I certainly hope you’re right. I’m no apologist for HTML-based applications, however, as things stand today, it’s what we have to work with and therefore it seems important to try and use it as effectively as possible.

  17. Very interesting article and discussion. We’ve developed a complex web app (web based XML content and web site management system). In our latest version we redesigned our UI completely and moved far away from the view/edit approach. We found that when dealing with such a large array of possible logical next tasks at any point in the application, it was far more intuitive and productive for our clients to be able to do a number of different things on the same screen.

    I’d be interested in any feedback/comments: and await part 2 of this article, hoping it will touch upon some more complex scenarios.

  18. Iva, thanks for posting the screen shots for us to look at. A question which I can’t answer from the static images but which is central to this discussion is, how does the user save their changes? I see the save icon but I can’t really tell what is being saved. It’s also hard to tell which elements are for navigation and which ones are for editing. I suspect a lot of this is more clear when you’re interacting with the product but perhaps you can add a few details about the interaction.

    I’m also curious how this design was validated with users. I agree that your design is more efficient than a strict view/form structure but I’m wondering if it’s appropriate for novice users.

  19. So… here’s a few of my comments on this article. A bit of context. I’ve designed three major web enterprise applications the past three years before coming back to Adobe, and in all three of those web apps, I used the View/Form model as you describe, although I called it Display/Edit.

    One of your sections is titled ” How Can I Ensure Users Explicitly Save or Cancel Their Changes?”

    I think it must be stated that this presumes that you must force users to “explicitly” save anything. This is a choice you make as the UI designer, but there’s no inherent reason you should force users to do anything. In fact, when you do, often you can just wind up annoying them.

    When designing web apps inside browsers, if you are designing for users who must use the software frequently, every time you force them down a certain flow, it can cause more frustration than they want to tolerate. In a desktop app, there is one major behavior that helps user get out of modal situations with relative ease and speed. They can quickly hit ESC on the keyboard to close any modal dialog that they accidentally brought up or *didn’t* want to use.

    This is not so in web apps inside browsers, and the lag in server/client hits and navigational issues can easily frustrate your frequent users that must interact with the system on a daily basis.

    If you make the decision to force users to “explicitly save” information into forms, do so knowing that you may be forcing them into workflow that can be more frustrating on a day to day to basis.

    You also state in the article:

    “…the only interface element on this page that actually saves the user’s data is the Save button located at the bottom of the form. If the user clicks any of the other links, buttons, or menus, their changes will be abandoned”

    This can be addressed in most modern browsers in a reasonable fashion, with Netscape 4.x being the only problem child. At this stage of the UI Design game in web apps in the year 2003, we should no longer be designing for 4.x as the lowest common denominator. Progress must be made. This browser must die and it won’t go away if we keep allowing it to live.

    One simple solution to this problem in every other browser is using the method known as “onUnload()” and pop an alert when the user tries to navigate away and they have entered information. You can set a flag using the most basic of JavaScript when a user enters info into a form to pop this alert. In a desktop app, this flag is generally known as marking the form “dirty.”

    It is a viable option, and one that should be seriously considered if you have users that must use your web app often in their work.

    Finally, given the need to move forward in design, if you choose to make NS 7 and IE 6 your baseline for building you web application, which I think is more than reasonable these days given just how tiny NS 4.x is in terms of sheer usage on the planet, there is a new model I’d suggest for you to consider along with the View/Form model.

    It is simply this: Using a bit of DHTML savvy, and not much needed mind you, have the Edit button on the display switch the fields that are read only into edit modes *WITHOUT* forcing a server hit. In other words, load up the form and the display version at the same (which should take an extra 0.01 seconds if you optimize your code), and then switch the form into edit mode underneath he user, also switching the Edit button into Save and Cancel.

    Then when the user clicks Save, you pop an alert with “Do you want to save these changes? Yes (Return) / No ” confirming the change, and if they click Yes or hit Return to this alert, you refresh the page back into Display mode, which is more in line with most desktop apps behavior. The refresh of the screen with new display vlaues is the confirmation the changes took hold.

    Also, as a sidenote, I personally find that hiding navigational elements inside the edit version of a form to simply be presumptuous. People should not have to click the Cancel button on the form (usually require scrolling) or the browser’s Back button just to be able to navigate where they want to go in other parts of the app. Using the onUnload() method with an alert is less intrusive and most flexbile. We should strive to keep the designs as freeform as possible rather than force users into draconian, hard coded workflows to accommodate the web browsers archaic interaction model.

    My two cents.


  20. Bob, thanks for taking a look at the screenshots. Of course it’s tough to get a good idea through a few low-res jpegs, but you’ve identified two of the big dilemmas. I don’t want to bore other discussion participants with issues too specific to our example, so I’ll try to keep it general:

    – Saving: users need to save quite often as this is a multi-user app and the we need to keep the server in sync. We do all sorts of checks for that, strive for avoiding constant refreshes on the client while we update the server, and as Andrei wrote, if the app detects unsaved changes when a user is navigating away we prompt them with a confirm dialog to chose to abandon changes or save. Another ‘nicety’ we find helpful is duplicating familiar desktop app behaviors such as Ctrl+S keyboard command for save and so on. In some cases, an auto-save user preference is useful too.

    – Novices: that was a tough choice. Novices would undoubtedly benefit from simpler UI, the view/form approach. However, the learning curve is not steep even for non-technical users and after a couple of times using the app, the simplified approach seems to become more of a hassle than helpful. So, we opted for providing tutorials and extra help for the ‘absolute beginner’ and tailoring the UI to the intermediate user’s needs. This may be a unique finding to our app because someone who has signed up to use it will use it frequently and they are willing to come up to speed with a new habit or two (as we’re finding out from interviewing users of the previous versions and the new version). Feedback from our users suggests that using the view/form approach created the perception the application works slower than when the user has an option of viewing and editing an array of settings on the same screen – in other words, it took the user more time to accomplish tasks. I can see how for a web app that may not be the best approach though – especially if the level of experience of the users and their incentives for learning the app are not clearly known. We have the luxury of some fixed variables – knowing who our users are, their expectations from and incentives for using the app, their approximate system setups, etc.

  21. Andrei, GREAT comments all around. I for one really appreciate them w/ my enterprise software hat on. With my other hat, as a designer for apps for a single not-for-profit site, I have to say that your browser presumption is way off. In the my world here I have had to make huge code concessions towards AOL for Mac and Netscape 4.0. My users are so non-tech savvy it is actually scary. I tell the Mac/AOL users that they can use another browser with their AOL instead of AOL and they throw their hands up in the air like I was speaking a foreign language. Having them upgrade is also highly unlikely.

    I have personally in my enterprise apps made the decision for modality. I have made this decision based on MS’s interpretation of inductive interfaces that spoke volumes to me in not just “forcing” users to “save”, but I’m focusing their activities to limit the UI’s confusion. By eliminating the other UI components you are removing distractions and just displaying what the user needs at that moment. If they don’t like it then there are two options the cancel button, which should NOT require a scroll if done right; and the back button which should have the unload() method that Andrei mentioned. BTW, never underestimate how often users will hit the back button in a web-based app. Scares me to death actually.

  22. “With my other hat, as a designer for apps for a single not-for-profit site, I have to say that your browser presumption is way off. In the my world here I have had to make huge code concessions towards AOL for Mac and Netscape 4.0”

    Progress must be made. AOL just sealed a settlement with Microsoft over IE and will probably finally drop NS inside AOL. Things will change, but only as fast as we, the people who design this stuff, help it to change.

    “My users are so non-tech savvy it is actually scary… Having them upgrade is also highly unlikely.”

    Here’s what I tell I my users:

    You can drive a car, right? You know, that thing where if you screw up you you could actualy wind up killing youself and a handful of other people who might be in your way? That 2 ton device that requires a decent amount of training to control. That thing that nearly everyone in this country can *use* in these modern times.

    You can drive a car? Good. I consider you a pretty smart human being in the chain of intelligence in being human. Go install Netscape 7.0 or click the little “e” icon on your desktop and stop complaining.

    Progress must be made. It will only be made if you help it move along. Stop pandering to people who can’t deal with installing a free browser that is light years bettter than the piece of crud they are using today. The short term pain is nothing in the grand scheme of things.

    By the way, this comes from the person who help changed all the keyboard shortcuts from Photoshop 3.0 to Photoshop 4.0. When PS 4.0 was released, the majority of PS user on the planet thought the world was coming to an end. Four months later, no one could remember how to use the PS 3.0 shortcuts. Today, I doubt many PS users even know what I’m talking about when I speak of the PS 3.0 to PS 4.0 changes.

    You’ll live. Turst me. 8^)


  23. Hi Andrei, I didn’t say “can’t” … I said “won’t”.

    I think it is important to always remember purpose of site when evaluating this. sometimes you can loose a customer, sometimes you can’t, not one not any. Its just not worth taking that chance. Also, you have to consider teh politics of your decision. If the “right” person complains that one complaint is now equal to the 80% of your 80/20 rule.

    Otherwise, I do want to say that I get Andrei’s point about the fact that we do sometimes treat users are unintelligent in our discourse and that that is just not the truth.

    Sometimes though when you are in a usability test it is really hard to remember. 😉

    — dave

  24. Of course it’s not a simple solution but why not replace each hyperlink in the navigation menu with a submit button? That way you can catch each relevant click event and redirect the user to the desired page or reload the current page with some error message if something’s wrong with her input…

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

    BTW – great article, great site (I wasn’t aware of your journal until I saw it nominated for a Webby Award)!


  25. “I didn’t say “can’t” … I said “won’t”.”

    Actually… you didn’t say either. But I get your point. 8^)

    “If the “right” person complains that one complaint is now equal to the 80% of your 80/20 rule.”

    I find that a bit defeatist.

    Here’s something to think about… what if someone really important or smart or high on the scale of your user list, like say, Jesus Christ or Albert Einstein, came up to you and said, “I don’t understand why there’s a “save” button there on that screen… it should just save when I enter data and tab from field to field. I should never have to click a save button ever.”

    I know what I’d tell him… But what would *you* tell him.


  26. Andrei, Thanks for all the great comments and for keeping up the dialog while I was off at DUX. Really useful insights from both you, Iva, and Dave.

    One of the points I’d take from all this is that you have to design the product for a particular audience. My bias is always towards mass consumer products where browser compatibility and learnability rank towards the top. For you, Iva, and Dave, the bias appears to be towards enterprise applications where the emphasis is on operational efficiency and browser compatibility is less an issue.

    Either way however, the solution you describe seems to mostly be a method for toggling a single page between viewing and data entry. One of the advantages of the view/form construct as I’ve described it is that it allows for the increase in data density by eliminating the visual distraction of input forms. Although your solution is reasonable for pages that are dominated by a single form or task, it doesn’t work as well for a page that displays a collection of objects.

    Obviously it comes down to a question of particulars but I think both approaches have merit depending on the situation. User testing among a representative population would be critical to determining whether an explicit Save button or a JavaScript “do you want to save your changes” popup would be more or less annoying.

    To your second point, I agree that the use of a Save button is a relic of a file-based system, but even without invoking the names of dead saints and philosophers, I can assure you that old habits don’t die easily. Although you may know of one, I can’t think of any applications — Web or otherwise — that implicitly saves data behind my back. Even database application such as Quicken and FileMaker have obvious viewing and editing modes. I can appreciate that an explicit Save can seem unneccesary but implicit saves as a user moves from field to field would be a substantial divergence from user expectations.

    And finally, to one of your earlier comments, what I said was the application should “force the user to EXPLICITLY save”. The word “force” was in reference to the word “explicit” and my point was that an explicit save was preferable over an implicit one.

  27. re the Jesus/Einstein question.
    I would say, “I’ll change that right away, sir. Can I get a testimonial for my product from you?”

    What would you say?

    — dave

  28. Last comment, now for Bob & Andrei…
    “save” button is more than just a relic. It is something that invokes a sense of completeness and understanding the system. Users search for this button out of habbit but also b/c it makes them feel better. I think the popup response feels more like an “error” response like the user has done something wrong and now needs to be saved. The Save button is about empowering the user towards completion.

    Also, “save” is not always the final step in a form, but an intermediary step. I.e. save and then send, or save and sign and approve, etc. Now this could be done in the way Andrei states but sometimes Save’s are also necessary as each “save” creates a new version and that iteration creation system is important.

    — dave

  29. I would say, “I’ll change that right away, sir. Can I get a testimonial for my product from you?”

    What would you say?


    I would say, “Interesting thought. Thanks for the feedback. I’ll think about it.”



  30. Great article and discussion.

    I’ve used a variant on the hub that is good for a long workflow that may be interrupted. Each of the forms has two buttons, essentially “Save & Continue” and “Save & Go To Hub.”

    This serves both as a wizard and as the traditional hub for view/forms. In our case, we had a database hit on each screen because interruptions were frequent.

  31. “Oh, and Andrei what are your thoughts on Inductive Interfaces?”

    I did forget to respond to this… but to be honest, the project I’m working on right now would speak volumes on my opinions in this arena. And to discuss that right now would be inappropriate for me as I would need to get specific about how I’m approaching the design of the overall application, which I cannot do.

    I would need to figure out how to describe it without getting specifc. If I do so, I’ll try and comment on this at some point. But not right now.

    Sorry for being cagey here.


  32. Jarno, In the example from Tivo, I don’t think a confirmation alert is required because the user can reasonably infer that the action was completed when the page reloads. My assumption is that users fundamentally trust the application until their experience proves otherwise. Therefore, the application doesn’t need to constantly inform them that it’s behaved as expected except in the case of particularly critical or complex operations.

    By analogy, a good administrative assistant is one that completes routine tasks without supervision and without fail. They’ll keep you informed about complex tasks such as completing travel arrangements but they won’t tell you everytime the finish making a phone call. If however, they fail to complete simple tasks, you’re confidence in them will be destroyed and you’ll most likely start looking for another assistant. — I’m pushing the metaphor but hopefully you get the idea.

  33. I found the article to be informative and good, though I think the strict separation of views and forms should be a design choice based on audience. Particularly when you are building applications for internal or specialized use, the user will become familiar with the system and so a main goal of the interface design becomes how quickly the user can complete the most common tasks.

    Take for example an administration tool for a moderated message board. If there is an admin tool URL that you expect to be bookmarked (or the simplest URL let’s say) then it might want to load with a bunch of links to various tasks and list of messages that need to be approved for posting along with links to sort them. In this case the view itself can confirm the change because it is not particularly critical and the opertion of the UI quickly becomes obvious to the administrator if not immediately intuitive.

    Nevertheless, the distinction of VIEWs and FORMs is a good one from a correctness standpoint when programming complex database interactions. Working with MySQL for a long time has taught me the value of well-defined task flow in the absence of strong database constraints.

  34. You’re article is well written.

    This is something that one tends to do “by gut” after a while. After the first five years of screwing things up, I:

    1) Stopped building with technology, and started building for users, organizational logic be damned (which sounds easy, but it is not)
    2) Started learning that everything exposed to your users is your “brand” and therefore, you must pay attention to usability as a brand element as much as from the standpoint of usable applications.

  35. Of course it’s not a simple solution but why not replace each hyperlink in the navigation menu with a submit button? That way you can catch each relevant click event and redirect the user to the desired page or reload the current page with some error message if something’s wrong with her input…

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

Comments are closed.