Don’t mean to go toooo far off topic but I’d also be interested to hear your thoughts on web apps that revolve around CRUD’ing (creating updating & deleting) stored data through the use of forms. I feel that this is a very neglected topic and one that could benefit from some serious discussion about best practices and usability.

The whole edit/view paradigm that currently exists in so many web apps I’ve seen could be streamlined with some clever (and quite simple) DHTML, although few people go to the effort of doing something as adventurous.

Of course I have my own opinions and theories on the subject having gone through the design of such applications multiple times, but it’d be wonderful to get outside ideas from time to time.

That said, I have to say that I disagree somewhat with some of your points . . .

1) “What is an application?” Agreed, this the first step. But no one (other than a handful of IA & UI people) seems to even be aware of this!!! I’ve had to really exercise all of my rhetorical and persuasive skills to my clients to even recognize that this was an issue [sigh].

The conventional (client and even Web developer) wisdom seems to be: ‘hey we’re delivering it using a Web browser so it should look and work like a Web site’. Yeah, it has the transactional nature of an _application_, it has the rich interaction of an _app_, it has the narrow task focus of an _app_, but those are just ‘minor technicalities’ [ouch], so let’s make it look like, say, Disney.com (insert your VP’s favorite entertainment site here). [Just to be clear, that last sentence is heavy on the sarcasm.]

So, I think this is more than just “academic rhetoric”. I really need “a consistent method for classifying web properties”, if only as a tool to help me convince clients that Web applications look much more like traditional (desktop) applications than they look like Web sites (and Why/How they do so and, just maybe, what the implcations area).

2) “One-to-one relationship”

I’m not sure that I agree that this is different for Web applications vs. traditional applications. For one thing, the ‘unique session’ that web applications establish is really a crutch to get around that fact that the underlying (HTTP) protocol is ‘stateless’ and, therefore, the application has to keep state itself by linking state information (on the back-end Web application server) with the unique browser session. For another thing, any desktop application that is running on an OS that requires the user to Log In to the OS (i.e., Windows 2000, XP, Unix, etc.) can find out from the OS ‘who’ the current user is. So, the desktop application (i.e., Photoshop) definitely “knows who you are” (or, at least, can know directly, if it needs to). And, it could be said that it knows who you are much more directly (and simply) than Web application ‘sessions’. Certainly, non-Web client-server applications typically require users to Log In, and thus know who their users are.
Finally, there is a whole class of Web applications where the “unique session” criteria wouldn’t apply. These would be applications that run completely on the client side (e.g., on the Browser). A very simple example of something like this would be an online mortgage payment calculator. Now if the application runs completely on the Browser *and doesn’t permanently change data*, then it would not meet your second criteria. But, we could also have Browser-based applications that save data locally OR, use the server only to archive data when the applications ends (no session required, but still need to uniquely identify the user somehow).

I guess the point that I’m really trying to make here is that while it *is* useful to try to come up with a rule like ‘creates data or edits it in non-trivial ways and saves new/edited data persistently” (and I’ve done this myself when discussing this with client teams) it is also possible to come up with counter examples and, especially, with borderline cases. I guess a really DO want a taxonomy of: sites, weblications, desktop applications, etc.

3) Adaptation/Personalization

Desktop and Client-Server applications have provided personalization and customization mechanisms for years now (a couple of decades, at least). On the complex and tweaky side, one example would be all the customizations and defaults one can set for the X-Windows GUI. On a simpler level, each user on a (current) Windows machine can have their own: desktop color/image, browser Favorites, My Documents folder, etc. The only difference that I see with Web applications is that it was _never_ true that a Web application could assume that they were always going to be used by the same user every time. Contrast this assumption with the early days of the Windows and Macintosh GUIs, which were really designed assuming a single user, I believe. Moreover, it is not clear that non-trivial levels of adaptation/personalization have a favorable cost-benefit trade-off. Remember when Personalization was a big buzzword in e-commerce circles a few years ago? But it turned out that supporting non-trivial levels of personalization was very costly. And they ran into the same problem that the (A.I.) people ran into on the research side: to do personalization well, you need a dynamic and very robust user model. It is hard to build that kind of model based on occasional usages of a Web site or application!

4) “A new form of interactive media”

I’m not yet convinced of this. To me they still ‘smell’ like an application (desktop, client-server, Web-based, they’re all applications). Where I _do_ see Web applications as being different (and, possibly, unique) is that they really should be (? have to be) designed in a more abstract way. By that, I mean that I can make almost no assumptions about how my design is going to be rendered and what the ‘platform’ the application it is going to run on will support. For example, up until recently, I couldn’t even assume that I could use more than 216 colors in a design. Another example: if I have deliver high-quality interaction and need to have my Web application work cross-browser (or worse, down-level browser) then I really have to design very carefully. Worst case, is that I have to degrade the quality of the interaction to the lowest common demoninator. What actually ends up happening, most cases, is that the Product Manager or the Technical Lead says, in effect, ‘bleep this; we’re designing for IE v.X and up on Windows only. (Yes, I try to push for designing to W3C standards instead, but it is usually an uphill struggle at best.)

Again, really good topic; well written article; and I look forward to the next installments.

Consider this task: Find the Honda with the most leg room in the back seat. A user could either 1) Browse the hierarchy of Honda models, finding that info and comparing each model, or 2) Use a fancy product recommender tool (application) to narrow down to the answer. Same task, simply different ways of accomplishing it.

What makes an application, really? You’re on to something when you talk about one-to-one relationships. I also think there’s something interactive (entering data vs. selecting from a list?) about applications that isn’t the same for content sites. Still lots of questions about this fuzzy distinction, though….

Not sure I can respond to all the individual points but I’ll try to pick out some of the general themes. First off, I agree with Udanium when he talks about Web applications being transactional in nature. That’s a distinction I want to take on more completely in the next article when I will be comparing Web applications to traditional desktop applications. It’s a very important point however and is fundamental to what makes Web applications unique.

In response to Jim Abbott’s comment about the personalization/one-to-one characteristics of Web applications not being unique: the examples Jim mentioned had to do with highly controlled and “pre-designed” forms of user-specific customization available in desktop applications. What I’m trying to underscore is the ability of Web applications to adapt to a given user based on that user’s role in the overall system as well as their historical behavior with the application. Granted some desktop applications are approaching this type of functionality — recently opened file lists, browser history, or saved transactions in Quicken are all good examples. However, as a user I don’t have the impression that my desktop applications are watching, logging, and reacting to my behavior in the same way that Amazon appears to. Of course that’s not to say that desktop applications couldn’t do that. In fact, it might make for some pretty interesting features.

To Jim’s final comment about Web application’s not necessarily being a new interactive medium,: my point there is that the combination of a primitive interaction vocabulary, the page-based model, and the transactional nature of Web applications, requires the designer and the user to think differently about how they accomplish tasks and I believe that makes for a new medium.

To Steve Mulder’s comment about content sites also being task based: I was waiting/hoping for someone to drive a truck through that hole. There’s no doubt that a given user might approach a given site with a very specific task in mind. The difference however, is that content sites also have to support users who are motivated by curiosity (and boredom). As a result, content sites have to be sensitive to issues of marketing and entertainment value in a way that applications don’t. As a loose analogy you might think of it as the difference between fiction and non-fiction.

Various people also brought up the idea of things such as mortgage calculators, flight status lookup, or package trackers also being applications. I wouldn’t consider these applications because they don’t allow users to create or edit data and therefore don’t have the issues of data validation and data integrity that account for so much of the complexity of Web applications. Instead, I think of these functions as sophisticated search operations.

Finally I want to reiterate the point that what’s interesting about this exercise is what the definition tells us about the unique design challenges associated with Web applications. Certainly this conversation is helping us ferret out and highlight some of those challenges.

As someone who has worked on a web application before, I’d also like to say that while search engines aren’t applications in and of themselves, they’re often used as part of the software, so people sometimes get confused and think they’re separate applications when they’re not.

My experience was in doing Cold Fusion development on a health benefits enrollment application, which also used search operations to find different things and bring them up, like the forms for health care providers that needed to be printed out. Although the search function wasn’t the whole application, it played a large role in it.

The software I worked on is a web application because it allows end-users to enter their data and update it. We didn’t allow data to be permanently deleted in case someone accidentally deleted info and called us wanted it restored, but the data was removed from the user’s active file and stored in another data table, so it simply appeared to be deleted.

As someone who has worked on a web application before, I’d also like to say that while search engines aren’t applications in and of themselves, they’re often used as part of the software, so people sometimes get confused and think they’re separate applications when they’re not.

My experience was in doing Cold Fusion development on a health benefits enrollment application, which also used search operations to find different things and bring them up, like the forms for health care providers that needed to be printed out. Although the search function wasn’t the whole application, it played a large role in it.

The software I worked on is a web application because it allows end-users to enter their data and update it. We didn’t allow data to be permanently deleted in case someone accidentally deleted info and called us wanted it restored, but the data was removed from the user’s active file and stored in another data table, so it simply appeared to be deleted.

I contend that the ‘principles’ of online applications are not any different than ‘other’ applications. In fact, as response times and ways to get around ‘statelessness’ continues, most of these ‘legacy’ applications are being front-ended with web-based interfaces. The ‘whole’ is converging…though not very successfully.

The fundamental methods and organizational designs (read: roles and responsibilities) are not changing across IT floors as quickly as they should be to support the convergence occurring. It’s as if they are all in denial (the major analyst firms being the worst offenders, since IT groups look to them to notify them of trends).

Most recruiters (to my shock, even in a fundamentally ‘desktop’ rather than ‘legacy’ environment like Intuit) are clueless as to who we are and what we really do…and the breadth of skills backgrounds we can and do come from (including those of us who have been swimming upstream since the days of legacy system design).

Your ‘otherwise’ well-written article is yet another injection of energy to keep us moving in the right direction. Thanks!