Lessons learned from Web-based e-mail

Have you ever wondered why so many people use free, Web-based e-mail accounts? I know that I have. I cannot stand them; nonetheless, most people I know use them. I think that, despite the fact that Web-based e-mail is not nearly as good overall as a quality desktop e-mail client, there are some major lessons to be learned from the penetration of Web-based e-mails that can be applied to many other applications, particularly in the decision to make it a Web-based application or a client/server application.

There is a world of difference between a Web-based application and a Web site. An application allows a user to actually perform a task. For example, the WinZip application allows users to decompress compressed files; the Microsoft Word application allows users to perform word processing; and the Adobe Photoshop application allows users to edit and create images. Therefore, a Web-based application is an application that pipes input and output over HTTP and uses HTML and maybe some helper technologies like JavaScript or Flash to allow a Web browser to act as a local container for input and output. A Web site, on the other hand, is primarily a read-only system that may or may not allow basic user input to perform, at most, short tasks. In other words, a Web site is almost entirely composed of tasks that could be performed with only non-form HTML and graphics with no server-side processing (as unpleasant as that might be). Another way to phrase it is that a Web site is aimed at the consumption of information, which is precisely what the HTML standard is designed for.

Here are some more examples: MySpace is a Web site. Yes, it allows the user to perform some input, such as writing comments or sending messages, but its facilities for doing so are rather primitive, and it is not focused around any one task. It may have applications within the Web site, but as a cohesive whole, it is primarily a read-only domain, and it fits the static HTML rule fairly well (i.e., other than comments and messages, most content rarely changes). YouTube is also another Web site; 99.99999% of its users do not do anything on it other than view videos. Hotmail and Google are Web-based applications. MapQuest and its cousins straddle the Web site/application divide.

Interestingly enough, while some applications were simply not feasible before the Web (shopping sites are a very good example), e-mail is the only category of application where Web-based clients have significantly overtaken market share from traditional applications. Sure, there are a few markets where there is enough demand for Web-based versions to replace the more traditional version, but e-mail is the only category of application that I can think of where the Web significantly replaced existing applications. We can learn some lessons from Web-based e-mail to find out how to decide if an application should be Web based.


One factor in people using Web-based e-mail is that it is a zero configuration tool once an account is created. E-mail clients require black magic to make them work, in the eyes of most users. No amount of configuration wizards or fancy installers or anything else can overcome the fact that it is too hard for most users to do. I have helped countless people configure various e-mail clients, and it just is not fun. Terminology is a big problem; for example, one e-mail client might ask for the incoming mail server and another might ask for the POP3 server. Many people cannot understand why the POP3 server is "mail.domain.com," but they are using "smtp.isp.com" as their outgoing e-mail server. At the end of the day, asking someone who is not knowledgeable to configure e-mail, despite it only needing three or four "technical" pieces of information for much of the time, is just too much.

To mitigate this kind of issue, make your application require zero configuration if possible. This also depends a lot on the context. Software designed for a corporate environment should cooperate nicely with Microsoft SMS and other automated deployment tools, and allow the configuration to be dynamically detected on startup or generated during the push. Allowing IT to push the software and then allowing the Help Desk to get swamped with calls is not going to win you any friends. For consumer use, you may need to get creative. One viable option (which is really almost mandatory) is to allow the distributor to package a configuration file that can be easily imported.


Portability is related to the setup hassles. I do not merely mean the fact that you do not need to reconfigure your Web based e-mail when you check it from another PC. Traditional e-mail clients often fall apart when you move your already setup PC to a different ISP (usually on the SMTP end of things) due to anti-spam initiatives on the ISP's part. As a result, no one with a laptop actually likes using their e-mail client, unless it is set up to VPN into a home office so that configuring a new SMTP server is not needed.

While this problem is particularly brutal for e-mail, many other applications suffer from it as well. Luckily, client/server applications are nearly 100% relegated to the corporate world where on-the-go users have VPN access. Those that are designed for consumer usage have the server located at the vendor's location, and the user's location is unimportant.

There are some applications that people will want to use from any computer without installation or configuration. These applications are prime candidates to be written as Web-based applications. Surprisingly, though, these applications are rare. Most developers, product managers, and so on completely overestimate how much their users will use their software. E-mail, social networking sites, and such have the appeal of immediacy ("I need to check my e-mail -- it has been two hours since I last checked it!") combined with a low need for time to complete most tasks ("Can I send an e-mail really quickly from your computer?"). Let's get real: No one is going to be visiting their aunt and suddenly decide they need to use a word processor, a spreadsheet, or video-editing software. People who need to be able to work from anywhere have laptops. So if your application is one that combines urgency with low time requirements, Web-based software is the way to go; otherwise, you will probably not need to worry about it.

Work and pleasure

Web-based e-mail also offers the advantage of allowing people to perform personal business while at their job. Many IT departments block Web-based e-mail. But for users who prefer to check their e-mail while on a computer that they cannot (or know they should not) install or reconfigure software on, Web-based e-mail is how they do it. This is actually a very specialized, but important angle to the portability problem. E-mail is important enough to many users to want to be able to check their personal accounts while at work, and a Web application is the only way many of them can do it.

Luckily, like the portability scenario, there is little reason for most applications to have a Web front end merely to allow users to use them from work. Users do not typically use personal applications from their desks at work -- they read personal Web sites while at work. Other than quick tasks like checking the home e-mail, instant messaging, or maybe following up on some feeds in Google Reader (which is arguably a very customizable Web site and not a Web-based application), users are simply not going to do very many nonwork-related tasks that require an application. In fact, we can break out the pattern for the vast majority of home users into the following categories:

  • Information consumption ("surfing the Web" to use an outdated phrase)
  • Communications (e-mail, instant messaging, social networking, etc.)
  • Multimedia consumption (listening to MP3s, looking at pictures from a camera and printing one or two of them, and so on).
If your application does not fall into one of these three categories (and multimedia consumption, if it is content that a user would stick locally can be safely ignored save locally is a category which can be safely ignored [Edited 6/18/07 for clarity]), the need to access the application while at work is not a need at all. Vendor tie-in and account permanency

You are probably asking yourself, "Well, that is all true, so why do most users opt for a free Web based e-mail account and not their ISP's Web front end to their account?" That is the $64,000 question with a very simple answer: Changing an ISP occurs much more often than people are willing to change their e-mail address, particularly for dial-up users. ISPs are constantly coming onto the market or going out of business. Even with a more stable provider like a local telco or cable provider, you may move out of their service area. While my alma mater is most likely never going out of business (it's the seventh oldest university in the United States), they canceled my e-mail account six months after graduation. One thing all of my former employers have in common, is that I cannot use that e-mail address anymore. And so on. I only know one person who has held onto the same non Web-based e-mail account longer than me, and he is a super long-term AOL user. I have had two e-mail accounts for nearly forever. One is a Hotmail account that I set up around 1997 or so (so old it does not need numbers in it). The other is an account that I pay a national ISP $6/month for an e-mail only account just so I have a professionally titled account for personal usage that I know will never need to change (even with all the M&A activity in the ISP business, pick a big ISP, and that domain will always exist even after the company does not). Most people, if they have the same non-Web based account for more than a year or two, it is a work account.

My point is that the one thing Hotmail, Gmail, etc. offer that the ISP's Web-based e-mail does not is permanency. People do not associate the task of e-mail with the vendor providing their Internet connectivity. Why should they? ISPs are commoditized to the point where they all offer the same packages for the same price points, give or take a few dollars a month. As a result, people expect to frequently change ISPs. Cell phone number portability was huge for consumers, because once consumers had the ability to keep their number, the only thing that could keep them with a miserable vendor was the early termination fee. With ISPs, unless a customer has a static IP address, the only thing really tying them to an ISP is their e-mail account and the early termination fee. Customers with Web based e-mail (or even paid e-mail through a vendor who is not their ISP) are only retained by early termination fees or lack of choice in the local area.

How does this affect your application? It does not. Luckily for the vast majority of application developers, the only application that gets hit with this issue is e-mail itself. The only other application category that is affected by this is applications designed to run on cell phones, as far as I can think of.


The lessons learned from Web-based e-mail abound. While there are many categories of applications that could not exist before the Web, it is a rare application that could be a desktop application but needs to be a Web-based application. Even for a large system with a public facing front end and an internal usage system, it is a coin toss between the standardization of making the backend Web based as well, and the easier development, horsepower, and added flexibility of a client/server backend. For example, a company may have a Web-based shopping cart that ties into their inventory system, and even have a Web-based inventory front end, but part of it will most likely be a native application because of the need to hook into barcode scanners. This is not to say that Web-based applications are inherently bad (that is another discussion), but that there is little reason to make most applications Web based. The success of e-mail as a Web-based application shows it to be a particularly special case and, while it is something that everyone uses, that does not mean that it is better. Web-based e-mail is more convenient to the point where it overcomes its relative lack of strength (until recently, Web-based e-mail was poor compared to a desktop e-mail client). It is a rare to find any other applications that fit into the same boat as e-mail.