The purpose of this article is to improve your ability to find that balance by adding to your understanding of web applications as an interactive medium. What distinguishes a web application from a traditional, content-based website and what are some of the unique design challenges associated with web applications? A reasonable launching point is the more fundamental question, “What is an application?”
What is an application?
The first step toward differentiating web applications from traditional content-centric websites is to focus on the “application” part of the equation. According to the American Heritage Dictionary, an application is (among other things), “…a computer program designed for a specific task or use.” That last phrase, “specific task,” is perhaps the most important.
The fundamental purpose of all web applications is to facilitate the completion of one or more tasks. Unlike visitors to traditional, content-centric websites, users of web applications invariably arrive with specific goals, tasks, and expectations in mind. Of course, that’s not to say that visitors to content-based websites don’t also arrive with certain goals and expectations, but rather that the motivations for using a web application are almost always explicit and precise.
One of the most important implications of this task-based orientation is the degree to which the application should call attention to itself. Compared to content-centric websites, video games, and various forms of entertainment media, application design succeeds not when it draws attention to itself but when it recedes into the background. This requires the designer to find solutions fundamentally natural to both the user and the medium, allowing the application itself to become transparent. The paradox of application design is that the perfect solution is invariably the one that goes unnoticed.
While this does not mean that an application’s design shouldn’t be enjoyable and aesthetically pleasing, it does mean that the design should play a subservient role to the user’s work.
A second implication of their task-based orientation is that web applications have to provide users with various milestones informing them when tasks are complete. In other words, web applications have to support an end-state in a way that content-based sites typically don’t.
In addition to the challenges resulting from their focus on task completion, the manner in which web applications function and connect with users highlights other issues affecting web application design.
When is a website a web application?
Without being overly concerned about semantics or classification (if that’s actually possible on a site like Boxes and Arrows ), it is important to establish an objective means of differentiating between a web application and a traditional website. To wit, in contrast to content-based websites, a web application possesses both of the following observable properties:
- One-to-one relationship – Web applications establish a unique session and relationship with each and every visitor. Although this behavior is fundamental to Web applications it is not present in either content-based websites or desktop applications. A web application such as Hotmail knows who you are in a way that Cnet or even Photoshop doesn’t.
- Ability to permanently change data – Web applications allow users to create, manipulate, and permanently store data. Such data can take the form of completed sales transactions, human resources records, or email messages to name but a few. This contrasts with web services like Google that allow users to submit information but do not allow them to permanently store or alter information.
Although these two characteristics alone result in a fairly broad definition of web applications, websites that possess both of them necessarily contain a degree of application behavior, logic, and state lacking in traditional content-based sites. In addition, they require a significantly more sophisticated level of user interactivity and interaction design than what is associated with content sites.
This distinction between websites and web applications is most obvious in situations where a given site is almost exclusively composed of either content OR functionality. Newsweek.com (a website) and Ofoto (a web application) are two such cases. However, even popular web destinations such as Amazon, and myYahoo!, sites that combine both content AND functionality, should be considered web applications because they meet these two criteria and therefore exhibit the interactive complexities and behaviors associated with applications.
In the case of Amazon, this takes the obvious form of personalized content and complex transactions, as well as a variety of other functions including the creation and storage of , the uploading and ordering of digital photographs, the editing and tracking of orders, and many others. That’s not to say that all online stores qualify as web applications; in fact most don’t. But Amazon and other stores of similar sophistication have the same characteristics and design considerations as more traditional applications such as email and contact management.
Granted, consumer sites like Amazon and myYahoo! typically lack the level of complexity found in licensed enterprise applications such as Siebel, PeopleSoft, or Documentum, but as a tool for classification, complexity is both inadequate and subjective.
Whether any particular application has sufficient complexity to require a highly skilled interaction designer is a question that can only be answered on a case-by-case basis. The point remains, however, that if a web property establishes a one-to-one relationship with its users and allows those users to edit, manipulate, and permanently store data, then it possess certain capabilities and complexities that distinguish it from traditional content-centric websites.
So what?
One of the most significant challenges and benefits results from the one-to-one relationship web applications form with their users.
Because a web application requires each user to uniquely identify themselves to the system, typically through a username and password pair, the application can be dynamically altered from one user to the next. This can take both the obvious form of personalized content and the more subtle and complex form form of personalized functionality based on roles and privileges. This type of dynamic behavior allows a complex corporate accounting application, for example, to provide different functionality to account managers, regional directors, corporate executives, etc.
Although this type of capability has been a mainstay of enterprise applications for some time, many less sophisticated or expensive applications now employ this behavior. For example, consumer-based online services can add and remove features or advertising based on whether or not a particular user has paid a subscription fee.
More so than any other interactive medium, a web application has the ability to adapt itself to each user, providing them with a personalized and unique experience. Accommodating the full range of permutations afforded by this capability is a unique and significant design challenge. Because various functions, interface controls, and data can dynamically come and go from the interface, designers are forced to think in terms of modular components that are simultaneously harmonious and autonomous.
In the same way that it is practically impossible for a visual designer to fully anticipate how a given web page will look in every situation, the designers of large-scale applications also struggle to fully document and consider every possible permutation of functionality and data.
Another unique design challenge associated with web applications results from their ability to allow users to make permanent changes to stored data. Because web applications are fundamentally database applications–that is, they store and present information contained in a defined database structure—the user’s information almost always has to fit within a predetermined format. Certain fields are present; some fields are required, others are not; some require a specific type of value; and still others require a value within a precise range. The result of all this is a level of data validation and error recovery unseen in either content-based websites or most desktop applications.
Accommodating this behavior requires the designer to carefully consider the task flow from one operation to the next, the full scope of potential errors, the most expedient way to recover from errors, and of course the holy grail of it all, the ideal solution for avoiding errors altogether.
All this points to one critical conclusion: web applications are a new form of interactive media, distinct from both content-based websites and traditional desktop applications. Therefore, the creation of truly useful and usable web applications requires the designer to understand, appreciate, and exploit the unique capabilities, limitations, and conventions of this new medium rather than simply approaching the design problem from the perspective of more established interactive mediums.
Next Up
Next time around we’ll continue to explore web applications as an interactive medium by comparing their advantages, disadvantages, and uses to traditional desktop applications.
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.
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?
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. 😉
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.
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.
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….
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.
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.
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.
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!
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!
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.
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.
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.
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.
Is it too simplistic to look at the “is it an app?” question from a point of processing information?
To take the Honda example:
The website provides a list of choices and the user has to process which choice best suits his/her needs.
The app takes the users need, processes the information and presents the solution.
This can be extended to bookshops as well.
As standard bookshop website requires you to do the processing – what do I like? where might I find it?
Amazon on the otherhand attempts to take over the processing of that information for you based on your previous choices and the choices of people who have made similar previous choices to you.
Not sure I fully understand your question but here’s a shot at it.
The term “Web application” refers to the online artifact with which a user interacts and “Web Programming” refers to the activity of writing the programming code that is executed by a server and Web browser to convey that artifact. The Web application is the thing itself.
Web programming concerns itself with
scripting on the server. Web application
concerns itself with user integration of
that programing.
Example a php script which handles a form
mail. The script itself does not have to be visible
to the user. An application can be built via
html, flash or another technology which
is the visual presentation to the user.
It does not have to be a browser experience.
One can actually create a client side exe that
deals directly with the script. and can check
for errors before the sending of instructions.
The error/correction response time is minimal
and sense only a small bit of data needs to be
returned to the exe there is less bandwidth.
The web application can or can not be part of the
browser experience.
Prasanna,
Apologies for the blatant self-promotion but to my knowledge, the only thorough treatment of UI design for Web applications is my book, “Making the Web Work: Designing Effective Web Applications”. You can learn more about the book here:
The book’s site
http://www.baxleydesign.com/pubs/mww_desc.html
Amazon
http://tinyurl.com/yvkt3
Applications are all about enclosed functionality, and the web is all about unenclosed functionality.
If I’m on the web using the Opera browser, using Active X to edit a Powerpoint slide that is embedded in a word document, which application am I using?
Check out “The Content Management Bible” — the author sees functionality as simply another type of content, which is a very powerful paradigm.
What foundations should someone lay before designing a web based application?
Ramesh, you should post your question on a site that deals more with the engineering and technical aspects of building Web applications.
Traditionally applications been compiled code. But now we’ve moved into the web where web apps are several script files that work together to perform tasks. Which are not compiled.
Since that bashes our previous technical notion of an application we move more into a conceptual notion of an application.
The article threw in recording of information. I believe stored data is a definite requirement of a useful app.
Web based calculators are more like “tools.” Tools are like a sort feature (albeit it is technically a function of something) conceptually is produces a quick temporary function. A loan calculator does not live in the mind beyond the need to find how much interest of principle is needed for the current problem.
Desktop applications are really a spectrum of usefulness. Windows calc application is like the tool, but Quicken is a much more useful application, and has the calculator built in as a tool.
So can we not use the concept of usefulness be applied to web apps. There are those that provide straight tool like objective, like the CRUD apps. CRUD apps provide use with cruding data, but provide very little information (I distinguish “data” as rock solid facts, like the temperature outside is 84 degrees, and “information” is what we can find good use out of the data, like it’s warm outside, you should probably wear shorts).
Now hotmail, mail.yahoo, gmail, etc., are web apps, are cruders, and give us the use of communication. It even becomes more useful when it begins to help manage our mailbox space, when it gives us charts and graphs about how much space is being used.
Stratifying the web apps into usefulness may help to distinguish them. They all work with data, but they all don’t make good use of that data.
As an after thought, Macromedia always promotes Flash as a rich media web app tool. Where you basically get rid of the statelessness of the http protocol, and deal with everything in a .swf file on one html page, never bouncing about through script files. And this brings us closer to the traditional compiled code, but instead of the stored data residing on the local box, it resides on a server somewhere in phoenix, Arizona, or India, wherever. I’d say the statelessness is just again as it was mentioned before a challenge of technology.