Software delivery mechanisms: Comparing desktop applications, web apps, and static websites

Let’s compare some of the different “delivery mechanisms” for software products, and what impact the different options can have on the User Experience. In this post, we’ll look at the following classifications:

  • Desktop applications vs. web applications
  • Static websites vs. web applications
  • Shrinkwrap products vs. enterprise applications vs. Software-as-a-Service

Desktop applications vs. web applications

Desktop applications are software programs that, in general…

  • are targeted to a particular platform or operating system;
  • usually use the native user interface controls and look-and-feel of the target operating system;
  • are either downloaded, or distributed on CD-ROMs or other media;
  • run on the user’s local machine;
  • usually need to be installed before they can be run; and
  • usually do not require the user to have a user account and to login.

Web applications…

  • should be usable with any web browser running on any operating system or platform;
  • can use user interface controls and have a look-and-feel that is different from those of the native operating system;
  • are hosted from a server, so generally no software needs to be downloaded, installed, and run locally;
  • the user interface is presented in the user’s web browser;
  • the data storage, processing, and business logic are usually handled completely by the server;
  • typically require a user to have a user account and to login.

How do desktop and web applications differ from a User Experience standpoint?

  • Early web applications supported few interactions beyond simple form-filling, as user interface controls for richer, direct manipulation interactions like dragging-and-dropping or drawing objects on a canvas weren’t available. “Content creation” applications like paint programs and spreadsheets were thus better-suited for desktop apps. However, modern web technologies and frameworks have pretty much eliminated the gap between web and desktop applications. Google Docs, for example, is a web-based office suite whose word processor, spreadsheet, and presentation tools work in all the ways that users are accustomed to with desktop office suites.
  • Web applications sometimes feel slower and less responsive than desktop apps, due to the need to send requests to the server over the network and waiting for a response. However, desktop apps have the same latency issues if they communicate with a remote server, and web apps can often be made more responsive through clever architecture and the use of client-side technologies like Javascript, Flash, or Java applets. Pixlr is an impressive web-based photo editing tool with very little noticeable latency.
  • Desktop apps save data to the user’s local storage, whereas web apps save data “in the cloud”, on the remote server.
  • Security is more of a concern for web apps, as users can lose control of their data and on-line identities if they forget their passwords or if their accounts are hacked.
  • Some users prefer the security of “owning” a copy of the software program on their local machine, which remains accessible even when Internet or network connectivity is unavailable, or in case the vendor ceases to exist. Others prefer the convenience of not needing to install the program, back up data, and install updates and patches.

Static websites vs. web applications

A “static” or “content” website…

  • primarily features content (e.g., text or videos) that remains fairly static;
  • offers navigation as the main (but not necessarily only) means of interacting with the site;
  • may offer some interactive features, but the majority of the user’s time is typically spent viewing content;
  • is usually accessible to the general public, although access to some features may require a user account and logging in.

Web applications are highly interactive, and are typically based around a central database or other form of storage, are based on some proprietary algorithm, or both. They allow users to create content or communicate with other users, or they serve some specific business function, like managing an organization’s bookkeeping and accounting, or allowing customers to book airline reservations.

The dividing line between “websites” and “web apps” is not always clear. People don’t usually think of content-oriented websites like Wikipedia as “software”, even though Wikipedia is interactive and is obviously powered by software. Consumer-focused e-commerce sites, like or an airline reservation website, have more obvious software functionality but are still usually considered “websites” rather than “software”. Google Docs, however, would be considered by most people to be “software” and is clearly a “web app”.

Shrinkwrap products vs. enterprise applications vs. Software-as-a-Service

Enterprise applications are typically large, multi-user applications that manage specific critical business processes for an organization. They are usually “bespoke” applications: they are custom-developed, either in-house or by a contracting organization. Some vendors offer standardized software products that they then heavily customize for each client organization. The customized product is then an enterprise application for that organization.

Enterprise applications involve a central server managed by the organization. The end users access the application either via a web-based user interface, or via a desktop client program that connects to the server.

“Shrinkwrap” or “mass-market”” software products, such as Microsoft Office, are usually desktop applications intended for individual users. In organizations, each user needs a separate copy. There is typically no vendor customization.

Software-as-a-Service (SaaS) is a bit of a hybrid of these models. SaaS vendors offer a standardized product, on a subscription or usage-based billing model to organizations or individual consumers. The product is usually a web-based application, and the SaaS vendor hosts the server. There is typically little customization (changing of the program code) permitted, but the product may offer many configuration options.


This entry was posted in Product Management, User Experience Design. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>