Comments on What is a Web Application?

Tom — Fri, 26 Jan 2007 14:50:59 GMT

I would like to start off with saying I agree with some of the what is being said in the article and in the discussions. I also think this discussion would be better served if it had the benefit of references to existing concepts, methodologies and practices as it relates to software as a web application.

In its simplest form, a web application is simply GET and POST HTTP requests, but this is an oversimplification of reality. What defines a web application? It is more than allowing a user can create, delete or edit data; it is also be that allows them to view data. Personally, my preference in defining a web application is modeled after a Model-View-Controller pattern. I feel this model comprises a discreet and logical segmentation of what components a web application is comprised of. In an MVC view*, the web application is composed of three parts; models, controllers and views;
• The model is your business logic and data (databases or other data repository)
• The controller brokers and transaction interactions from a view back to the model. So depending upon input from the view the controller will transact with the model then it will then respond with an appropriate view.
• The view will display the data contained in the model. The view determines how the data supplied via the controller should be displayed.

An example would be as follows;
A flight status check contains a model (ie Sabre or Worldspan), the controller (ie servlet, bean, tag…) and a view (jsp, asp…). The model contains all the current flight data; carriers, routes, destinations, and times. The controller is concerned about taking input from the view, performing validation and supplying the model correct flight number. It would then be concerned about the model response for the flight number, then determine which view to use. The view had an input state to supply flight number and a result state which I displays the results.

In my mind definition of a web application becomes this; Do you have an underlying data source? Do you have controller which interacts with your data and your interface? Do you have a set of interfaces by which users interact with your controller? If you have these elements, it’s a safe bet your have yourself a web application.

Thanks!

*While I have outlined a fairly well known and well practiced OO pattern, there poor souls in the industry who simply prefer to design monolithic web applications which combine all three into one unit. Even though they have made a serious design error :) in doing so, it is still a web application.

Bob Baxley — Fri, 26 Jan 2007 14:50:59 GMT

Whether or not users or engineers would describe a given Web property as an application or a content site is not the point. The point is that the design considerations effecting an application that allows for the editing and manipulation of stored data, are different from those effecting a content-based site that allows for the consumption, navigation, and retrieval of fixed content. For example, the designer of a Web application that allows for the storage of user-generated data, has to be concerned with issues of task flow, state, and error handling—issues that are absent or extremely simply in content-based Web sites.

While I certainly agree that things get fuzzy in the case of applications that combine large quantities of both content and functionality, Amazon for example, the distinction seems quite clear and useful as you move away from the middle. Although they may use many of the same methods, the designers sitting at Documentum are working with a very different set of problems and concerns than the designers working at the NY Times.

Mike Jaixen — Fri, 26 Jan 2007 14:50:59 GMT

The distinction of a web application from web content is something that really only concerns those of us on this side of the web server. If you floated the distinction by 100 web users, the majority would probably look at you as if you were from another planet. A search engine, for example, is an application by most any definition. It has executable code, generates it’s output on the request, and allows for the user to interact with it by entering information. I could also build an application that provides personalization of content like Amazon.com; it remembers things I’ve looked at, and recommends like items. (Even though all I’ve done is click on links – ie very little interaction.) I also can go to an online brokerage site and buy & sell stocks – another obvious application.

Instead there is a continuum of complexity that I see. A simple “content-only” site would be at one extreme, and complex transaction applications at the other end. Everything else goes somewhere in the middle. Is it an application? My answer would be: why do you ask?

If you are in systems engineering or operations support, and you want to make sure the web site is running, you care whether or not there is executable code or not running on the servers. If you are in security, you want to make sure that any data transfers that occur as part of the request are handled securely. If you are in user-experience areas, you want to make sure it’s as easy to use as it can be. And if you are the owner of the site, you just want to make sure it does what it’s supposed to.

The answer is the classic IA answer: “It depends.” :-) I would ask the question “Why would I care?”, and then ask if the content meets that criteria or not. Whether or not it’s a web application is irrelevant IMHO.

Mike Jaixen — Fri, 26 Jan 2007 14:50:59 GMT

David Heller — Fri, 26 Jan 2007 14:50:59 GMT

So someone offline asked me to add my 2 cents here.

First I want to thank Bob (when are we going to do sushi again) for his article and just taking on this task of “interaction design” as he has.

I do think that Bob made a mistake in his approach in this article. He attempts to create a dichotomy where what it really is is a continuum. I think the separation of a “content” site from a web-app is actually not accurrate, or useful.

While JJ Garret showed it as a dichotomy in his Elements User Experience Design chart, I don’t think it is ever really that simple (and I don’t think JJG meant it that way). Content is an application in that search is an application, personalization is an application … I think that instead of concentrating on defining what isn’t and what is an app, and more speaking about specific interaction models:
*searching + result models
*selection
*meta data visualization
*navigation types
*repeating attribute controls
*form widget design
*form layout
*calendar controls
etc. etc.

The methods we choose just fit the tool(s) we are trying to create to make the best experience as possible.

Anyway, I assume that is what Bob is going to into next. ... Yea Bob!

Paula Thornton — Fri, 26 Jan 2007 14:50:59 GMT

Some of the responses have ‘danced around’ this thought. I take issue with your comment “A web application such as Hotmail knows who you are in a way that Cnet or even Photoshop doesn’t.” The use of Photoshop as an example of an ‘application’ is a sound, but not comprehensive one. In fact, the majority of applications used by the most people in corporations before the proliferation of desktop applications were somewhat ‘personal’ in that they had high levels of security involved to know just exactly who you were and what you did when you used the application. The fact that none of the focus was on how they could use any of that data to improve your experience, is a given.

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!

Emily — Fri, 26 Jan 2007 14:50:59 GMT

Hi,

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.

Emily — Fri, 26 Jan 2007 14:50:58 GMT

Hi,

Bob Baxley — Fri, 26 Jan 2007 14:50:58 GMT

Thanks to all for your enthusiasm as well as your insightful and provocative comments. It’s quite encouraging to see so many more boxes than arrows. :^)

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.

Steve Mulder — Fri, 26 Jan 2007 14:50:58 GMT

Great article and discussion, though I have to disagree with the notion that an application is an application because it deals with more specific user tasks than a content site. From my experience over the years watching users, that’s simply not true. Tasks can be just as specific on content sites.

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

Jim Abbott — Fri, 26 Jan 2007 14:50:58 GMT

Bob: this is a _much_ overlooked topic and I am *very glad* to see you writing about it. Many thanks!

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.

Madonnalisa — Fri, 26 Jan 2007 14:50:58 GMT

I have to second subimage’s request on your thoughts around CRUD’ing as well. It’s something I’m trying to tackle right now at a conceptual stage and finding “usable” tools to help support the folks I’m building this for.

subimage — Fri, 26 Jan 2007 14:50:58 GMT

Great introduction article, although a bit slim for my tastes. I’m eagerly awaiting part 2 of this one. You touched on enterprise applications in this one, which is a subject dear to my heart. Are you going to be elaborating on this in part 2?

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

Bob Baxley — Fri, 26 Jan 2007 14:50:58 GMT

Savy, thanks for the comment although I’m not exactly sure what you mean. What others are you saying are client-server or networked applications? And what do you mean by “what the medium does to an application”? Are you referring to the differences in how a similar application, email for example, behaves as a Web application versus a desktop application? Are you talking about the way a browser-based presentation effects the interaction model? Are you talking about the way a Web application takes advantage of the internet as a data communication infrastructure? Or are you talking about something else altogether?

savy — Fri, 26 Jan 2007 14:50:58 GMT

It would have been worthwhile to emphasise the word WEB in web application also, the others being a CLIENT-SERVER application, or a networked application etc, because then we could discuss what the medium does to an application.