http://qs1969.pair.com?node_id=210914


in reply to (OT) Work flow in Web based applications

I can see some problems with using a mode stack in the context of a web application. I've seen this approach used to good effect for desktop applications, but I think it's a little trickier for a CGI script.

The first thing that comes to mind is, what do you do with incompletely entered data? Let's say your "add a product" screen has 10 fields, plus the "assign contacts" area. I fill in all the fields, then realize my contact doesn't exist yet. So I jump to the "add a contact" screen.

In a desktop application, this is fine; the contact entry screen appears "on top" and once I'm done adding the contact, I return to the product entry screen, with the state of everything (including whatever I typed in those 10 fields) fully preserved.

But in a CGI context, what happens? Do you create a new product record in the database, with my (perhaps partially entered) product information? If so, there are obvious potential problems. (What if I realize I don't know all the contact information yet, and it's time to go home, and I'll deal with it tomorrow?) But if not, then when you return me to the product entry screen, I have to re-enter those 10 fields.

I'm just thinking out loud here... haven't really thought it through. But I wonder if you could use popup windows and/or frames, combined with JavaScript/DHTML for updating, to get the same effect you have in a desktop app where a new mode can be pushed onto the stack without touching the state of anything beneath it.

Sorry if this was less than lucid. I'll try to elaborate and/or clarify when I have a chance.

Cheers,
--Kevin

  • Comment on Re: (OT) Work flow in Web based applications

Replies are listed 'Best First'.
Re: Re: (OT) Work flow in Web based applications
by FamousLongAgo (Friar) on Nov 06, 2002 at 22:03 UTC
    But I wonder if you could use popup windows and/or frames, combined with JavaScript/DHTML for updating, to get the same effect you have in a desktop app where a new mode can be pushed onto the stack without touching the state of anything beneath

    I would be leery of that. A great temptation with web apps is overdesign and non-standard behavior, and using frames with DHTML is just asking for trouble. You'll end up having to support ten versions of your code for different browser/OS configuratons.

    One good idea is to spend some time on sites like Expedia, JetBlue, Amazon, Southwest Airlines and other web apps that have to maintain a lot of state and allow for users to do lateral navigation. Steal ideas from them, notice how they do error handling, UI design, and so on.

    When that is done, mock up your HTML pages. Then write code using fictitious subroutines / objects / whatever you like, at as high a level of abstraction as you can. Once you are satisfied with the overall architecture, move down a level of abstraction, using stub objects / subroutines, and then move down another level, until finally you have coded the whole thing out.

    Of course the process is never so pat and linear, but I've found it's a good model to work from. The most important part is looking at lots of other web applications, preferably ones run by companies that have poured money into usability testing.
[reply]
      I would be leery of that. A great temptation with web apps is overdesign and non-standard behavior, and using frames with DHTML is just asking for trouble.

      You're absolutely right. I wrote that node in haste and now I can repent at leisure. But let me clarify. I certainly didn't mean that Ovid should blithely use every DHTML trick in the book. What I did mean was that if you have a page on which the user is entering data, and you want to update some subsidiary data on a different page, it might pay to put up the entry form for that subsidiary data in a popup window. And once the user has entered that data, how do you communicate that fact to the parent window, and how does the parent window display the newly entered info to the user? JavaScript and DHTML. That's really all I was trying to say.

      You'll end up having to support ten versions of your code for different browser/OS configuratons.

      That's certainly an issue when you're writing a web app for the general public, but when you're working on an intranet-based app that a strictly limited group of users will access, you probably have a certain amount of control over which OS and browser the users will be using. I don't think it's unreasonable to write platform-dependent code in such a case.

      One good idea is to spend some time on sites like Expedia, JetBlue, Amazon, Southwest Airlines and other web apps that have to maintain a lot of state and allow for users to do lateral navigation. Steal ideas from them, notice how they do error handling, UI design, and so on.

      Absolutely. But also pay attention to where they still screw up. Some of the most annoying experiences of my online life have come when trying to price airfares. If Expedia and Travelocity and their kin work smoothly now, it's only after YEARS of sucking, and falling prey to some of the worst pitfalls of CGI-context state maintenance.

[reply]
Re^2: (OT) Work flow in Web based applications
by Aristotle (Chancellor) on Nov 06, 2002 at 23:41 UTC

    That's what I addressed. You have to define what a complete set of data is and keep track of it on the server. Then, by looking at the blanks left in that set of data, you send the user to the pages he needs to fill out. Finally, you have accumulated what appears to be a complete set of data; then and only then do you actually commit any changes to the actual database.

    It really is quite simple - sort of a reduced model/view/controller design.

    Makeshifts last the longest.

[reply]

In Section Seekers of Perl Wisdom