Project Management

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.

Setup

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

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.

Conclusion

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.

J.Ja

About

Justin James is the Lead Architect for Conigent.

40 comments
gordon
gordon

Lesson: Compelling, Simple to Use, with Accessible Web Tone and High Bandwidth: I think your view is too narrow in classing Email as the only Web-Application success. Several other successful SaaS applications exist, they are just not consumer applications in the way that email is. SalesForce.com Salesforce Automation has a large following, as does Vocus.com Public Relations. These are highly functional applications, with Zero footprint, no IT infrastructure required, On-Demand - just login and use! The true lesson to be learned from web-email is that there are not many killer applications for the consumer other than email, chat, social networking, music, video. Bandwidth is the main problem for music / video... it's OK with broadband at home, but we don't have affordable broadband on the move (perhaps WiMAX is the answer?). When I first tried web-email on dial-up, it was painfully slow and horrible to use. Broadband made it less frustrating by eliminating the lags, but only recently did Yahoo! make it acceptable to use with their web-client - it's not perfect, but it is great! The more pervasive and "urgent" the application is to the user, the more critical the bandwidth and everywhere-accessibility becomes. If I could subscribe to *MyTunes* and play my music anywhere and on any device (without messy syncing) then I would be happy - MyTunes would manage all the IT issues.

Justin James
Justin James

Gordon - Yes, salesforce.com and a few other SaaS vendors have a bit of a following. Some olf them are even moderately profitable. But when measured in terms of market share (profit & market share are the two major factors which go into measuring "success", in my book), the vast majority of them do not cut it, and it is nearly impossible to say that any of them are close to a "dethroning the existing king" status. Salesforce.com, for example, keeps growing gross revenue but their net revenue keeps shrinking; marketing and sales costs are growing faster than income. In other words, they are struggle to grow sales, and it is costing them more than the sales are worth. So yes, while I agree that some SaaS vendors (but disagree that salesforce.com is one of them, I cannot soeak of your other examples as I am not too familiar with them) are doing well, few of them are capturing market share even close to double digits; indeed, adding all of the SaaS vendors in a space together (where they compete against more traditional vendors, of course) rarely yields double digit market share. So I really do not think that SaaS has proven itself as a profitable way of doing business (for vendors; I also agree that many customer can benefit from SaaS) yet. To re phrase my measure of success: the giant company turning a $100,000 profit is not so hot, it has market share but not profit. The corner laundromat may run a $100,000 profit, but its market share of even the local market is around 5%, not something particularly impressive. Right now, I see the vast majority of SaaS vendors like my local laundromat. They are turning a slight profit and have captured a small amount of the market. Great for the owner and employees, but not exactly Forbes or Fortune material either. J.Ja

-
-

I think you need to get just a little more abstract and look at what it is that you're describing. Browser = human interface for conveying data in a format humans can interpret Data = messages, information, transactions Internet = data transport ISP = access arrangement to connect human interface to data source via data transport Web server = one method of connecting data to data transport Instead of "Who would want to access email at their aunt's?" maybe you should ask "Why can't I leverage the power of computing no matter where I am? Could that possibly enrich the interaction I have with my aunt, or maybe allow me to visit my aunt and still accomplish all the other roles I play in life? Why should I be stuck in this cubicle like a cow being force fed grain instead of out living my life and being an independent provider of my capabilities to those who might consume my output? What's wrong with this picture of how I, the square block, am being forced into this round hole instead of being the individual I was meant to be?". Just a thought :)

apotheon
apotheon

I just use SSH to solve that problem. I maintain local mail client functionality on a computer at home with the mutt Mail User Agent, and use SSH to access it from any computer I like. It's a lot more secure than with webmail that way.

Justin James
Justin James

But instead of SSH + Mutt, I use VPN + Remote Desktop. But that's the price I pay for having Windows as my desktop OS, as opposed to *Nix, more bandwidth needs. :( J.Ja

mattohare
mattohare

We set up a webmail interface to our office outlook server. It's generally pretty fluid, doesn't have a lot of the overhead of Remote Desktop (RD). A few of our RD users were using outlook on it, and I suggested OMA. They seem to be doing well with it. Though, some of the users have issues if when the browser tries to use some local office installation and it's out of sync.

apotheon
apotheon

I loathe them both -- and use neither. I'm running AHWM on my FreeBSD laptop. When I had Debian GNU/Linux on a laptop, I used either WindowMaker or Sawfish (depending on when you asked) -- since AHWM isn't available (and I didn't know it existed until switching to FreeBSD). If you like the MacOS X Aqua interface, you might want to look into XFCE. There are some definite similarities. If your reason for liking that interface is the framework rather than the superficial interactive aspects of it, you might want to consider using WindowMaker with the GNUStep framework, which is an open source implementation of the same codebase MacOS X imported from the NeXTSTEP OS. KDE and GNOME are far from the only options.

Justin James
Justin James

I know why I still Windows as my primary desktop OS. Not all of the reasons are still valid. Some of them are. I think at this point, It is mostly due to the fact that I cannot stand KDE or GNOME. I could very easily see myself on OS X at some point in the future. I just wish there was a risk free way to try it out for a week or two at no risk if I do not like it. J.Ja

apotheon
apotheon

You made your bed. I guess you can lie in it.

Louis Pace
Louis Pace

I've found a solution that enjoys some of the benefits of both the web application and a local client. For $100, I purchased a 4GB flash drive. Smaller drives will work for this solution as well. I installed PortableApps on the flash drive, including Firefox Portable and Thunderbird Portable. (http://portableapps.com/). I then subscribe to Yahoo!'s Mail Plus, which gives me POP access and better spam filtering, along with some other nice features. Using Yahoo! Mail means my email address never changes. Using Thunderbird Portable means that I have the benefits and flexibility of a local client, but the portability of the web-based application. Using Firefox Portable grants me similar benefits - my email and my bookmarks are with me wherever I go!

C_Tharp
C_Tharp

Don't lose that stick!

Louis Pace
Louis Pace

Good point. One thing I forgot to mention - a free tool, GoodSync, keeps my data backed up on a hard drive at home. (http://www.goodsync.com/) Also, if anyone is interested, Yahoo!'s Mail Plus service is pretty inexpensive. $20 per year amounts to less than $2 per month.

Deadly Ernest
Deadly Ernest

Another factor is the separation factor, it's hard to link a web based mail client to someone, while an ISP based one is easily linked. I write under a pen name and have two web based mail accounts that have absolutely no links to my real identity and can't be traced to me, except if they trace my access over the web, not an easy task.

apotheon
apotheon

The people I'd most like to avoid tracking me down are the people most able to do so quickly and effectively. Trying to maintain real anonymity is a sucker's bet.

Justin James
Justin James

I don't think most people care if they can be "tracked" through their ISP's email system. However, I *do* think that most people like the fact that with Web based email, it is very simple to create a new account if your existing one is spam flooded or if you wish to dodge someone's messages. I know a lot of people with a "backup" email account that they use to avoid ex-girlfriends and such. It is a real hassle to do that with an ISP, and nearly impossible with a corporate IT department. It also allows them to easily handle indentity. Much "easier" to logout and log in with a different username for the "personal email" and the "professional sound email address" (think "sweetcheeks@mail.com" vs. "john_jones@mail.com") than it is for most users to understand a unified inbox from all accounts, and selecting a sending account when writing mail. J.Ja

mattohare
mattohare

How many of us have an address we check infrequently, but give out to places where we expect spam? My walla mail address became that when spammers started targeting foreign addresses. I especially love using it for domain registrations. I go through it once a week (usually while watching a cheesy sitcom or the 'lifestyle' segment of the news) so I can get anything official.

Locrian_Lyric
Locrian_Lyric

I have one for professional use, one for personal use and one for spam.

gjholt
gjholt

Yes, and security. The nasties are on the hotmail, gmail, mail.com conputer for me to consider, not on my hard disk before I can even look at them.

Justin James
Justin James

You raise a good point here, which is that for consumer level applications, the consumer rarely has things like gateway virus scanners in place. The corporate IT department knows how to handle these items, and the Web app folks do, but for the consumer, going with a Web based app frees them from the overhead of data storage, like antivirus duties. J.Ja

Justin James
Justin James

Web base e-mail is pretty successful. What can we learn from it? J.Ja

mattohare
mattohare

I disagree with you on the distinction of site and web application. (Of course, that means there's a bit of overlap. That way we're both right! *chuckle*) To me it's the same as when I class a computer as a tool belt, not just a tool. A computer has several pieces of hardware (and a bit more importantly) software that allow people to do things. So, this week, did I: * Make spreadsheets, browse web pages, do word processing, write code, tick check boxes and option buttons? OR * Analyse the organisation's budget, write to my aunt, research the administration divisions of Denmark, book a flight, chat with friends, brag about that cool prize I got in mountain biking at yesterday's works outing? Remember, Myspace has a blogs facility. I use it, and I have to say it's fairly sophisticated. (It could be better, but how does that separate it from any other software?) I would say that I added to my public diary, not just entered and retrieved data. (For a few of my mates, it?s a delayed version of IM.) Myspace also has a message board facility. I use that a bit to connect on work and sport-related issues. Google Maps and Google Earth are another example. You could class Google Maps as a ?website? in your scheme, and in the early days I?d agree. Now I can get directions from anywhere, to anywhere. (I don?t fancy the swim that Google suggests when I get directions between Belfast and Portland (Oregon). Google Earth is still a web application. We do not install the whole dataset locally! Another web application that?s catching on is transport planning. Most systems now have an online schedule system. Some let you book online. While you could say this is a website, it?s an application with the level of interaction. I think we've learned some of what worked with webmail, and applied it in the spatial applications pretty well.

Wayne M.
Wayne M.

The issue is typically one of maintenance, both at initial install time and over the life of the product. Having supported a geographically distributed client-server application for many years, I can attest to the appeal of only having to install and make changes to a web server. The differences between client machines is immense - no two are alike. The difficulties in having work done by both technical support staff and non-technical users are challenging. The cost of a deployment is restrictive and a rollback is almost out of the question. I still do not believe the current HTTP / Web Browser desktop is sufficient to support truly remote applications. Although I appreciate the flexibility of web-based e-mail when at a client site, as soon as I return to the home office, I switch back to my desktop e-mail client. Software needs to become simply a tool for people to just use bypassing installation, configuration, and maintenance steps. That is the lesson I draw from web-based e-mail.

mattohare
mattohare

I am having a bit of an issue with Yahoo on that. My other mail service, Walla, only made one significant change. That change made an English-language interface (now my hebrew is going from bad to rusty-bad), and they added a silly level of spam protection. At the same time, they also increased capacity. Yahoo has added anti-spam, anti-virus, and a bunch of other stuff. But, now I'm I tried using their new 'award-winning' client and had to switch back. They kept messing up my surname in the signature block.

rclark
rclark

Without your permission, only permission of the host company is needed. As seen by the recent AT&T and Cisco fiascos, most companies are relatively agreeable to allow the PTB access to other peoples email. The one thing that Corporate Exchange gives you is the ability to keep stuff off the net behind a firewall. The PTB can still get it, but in order to do so, they have to have a warrant. While much easier to come by than in any previous decade, they are still a hassle that the PTB don't want to have a record of unless it is justifiable. On the other hand, if the companies (ISP and Hosted Email) will give it up for free with no record, then hey, lets grab the data and set us up a mining mission. Like free hookers, most guys wouldn't pay for a hooker, but if you're giving it away for free and my wife (JohnQ Public) will never know, then what the heck, it's party time.

Locrian_Lyric
Locrian_Lyric

Ease of use. Permenance Portability reliability. 1)There is no setup for webmail 2)You can keep your webmail addy even if you change ISPs 3)If your PC crashes, or is unavailable, your web mail is still accessable 4)The latest version of internet Exploder won't crash your webmail when if forces itself on your system.

Justin James
Justin James

I think you and another poster both picked up on something that I managed to entirely miss, which is that Web based apps free the consumer from the overhead of dealing with data. Virus scanning, backups, redundancy, stuff like that. Most consumers have a single hard drive (no redundancy), do not do backups, and their virus scanner is the throwaway one that Dell or HP pre-installed, and they never subscribed to the updates. Web based apps free them from needing to count on their insecure and unreliable systems. It just happens that email is probably the only data type that consumers regularly use that is bandwidth friendly (most consumers won't put their MP3 or MPEG collections online, particularly since most consumer grade broadband has such a low upload speed). J.Ja

jnavon
jnavon

- Web apps do not requiere neither to be installed nor to be upgraded by the user. This is a BIG advantage for many people. - Web apps allows collaborative work a lot easier (instead of sending a word doc attached just share your google doc) -Web apps can be used from Windows, Mac OS X or Linux in the same way Finally, I agree with you in that desktop apps usuallu provide a nicer user experience than the web version but the gap is narrowing quickly (RIA, AJax, etc)

Justin James
Justin James

I agree with your points here. But what is interesting is that these advantages are not reflected in market share, and certainly not for lack of trying on the vendor's parts. A point that I missed in another reply, is that email is also one of the few data types that anyone actually wants to host and can host cheaply enough to be ad supported and provide for free. No one is going to let consumers upload 150 GB of MP3s and MPEGs to act as a portable file share, at least not for free. And no consumer wants to spend 2 days doing all of that uploading. Email has a distinct lesson, in that low bandwidth data lends itself much better for Web apps than high bandwidth data. J.Ja

fachtopia
fachtopia

It seems like if you work for Microsoft defending Microsoft Outlook or any other email client. Have you forgot to mention issues like: - if you are corporate, you have a consolidated point for all your email - if you use a email client how much support you have to give to each employee or money to be considered (Microsoft Outlook) - Antispamm, Antispyware devices, softwares - Portability ( it've been already mentioned ) Now you can have too many solutions web based and all of them related that there's no need to have nothing installed Example: Salesforce + Gmail or Corporate Email ( on your server )+ Quickbooks Online + Company web sites + eCommerce portal + UPS delivery I've read your article and I don't find a solid point why should I use MS Outlook or any other email client over any of the actual top 5 web based email services on the market ( free or paid, whatever ) JM Fach VoIP Business - Virtual PBX www.fachtopia.com

Justin James
Justin James

I thin, you might want to re-read the article, if you thought that my point was to convince users to switch back to Outlook or other email clients (although that is my personal preference for my own use). The point of the post was that Web mail is the only Web based application that has replaced desktop applications for any significant number of people. I have found it interesting that for all of the buzz around Web apps, they do not acheive market share, with the exception of email. So I took a look at what Web based email gives users that desktop clients do not, and used it to derive a set of guidelines that can indicate when to *develop* a Web based app versus when to *develop* a desktop app. The post has nothing to do with when to *use* a Web based app vs. a desktop app. J.Ja

mattohare
mattohare

It's funny how an example or side point distracts from the main point. I'm still navigating through the other posts before I actually get to replying to the real point, which is a very good one. I think this (email) is a great example for it too.

apotheon
apotheon

I'm another one that prefers POP/IMAP accessed from a local client over web-based email. There are a number of reasons for it, including faster operation, a wider range of choices for the functionality I'd like to have in the interface, greater ability to customize how I manage email, more choice in things like domain names without having to pay extra for the privilege, local archives of my email, no scanning my email to determine what ads to show me, and so on. It's also much easier to achieve relatively secure communications, as various encryption schemes are much easier to use with local clients than web applications, generally (to say nothing of the fact that even if you have something like GPG or PGP in webmail, you're still reading it in a browser from someone else's server after decrypting it). Of course, Outlook is a pig, and suffers a lot of failings -- but it's not what I use, anyway. It doesn't run on any OS I'd want to use for email, so it's a non-starter for me regardless of whether I like it -- but since I don't like it anyway, that's really a moot point. I quite like mutt, and use it for email. Among other benefits, it's entirely incapable of executing any of those email viruses that I keep seeing in the news. You don't get the same protection with webmail.

apotheon
apotheon

The two most important and obvious lessons are portability and ease of set-up, at least in terms of application design. The one most important and unobvious lesson is something else entirely: People will, for portability and ease of set-up, put up with a whole lot of crap. Think about the spam filtering that not only lets a bunch through but actually blocks a lot of legitimate email on Hotmail, for instance, and the millions of people who keep using it anyway. edit: I'm guessing on that "millions" number.

Justin James
Justin James

Yeah, it really is true. Hotmail and many of its competitors are pretty bad at a lot of things, but people are willing to trade that for the convenience. That is a big "lesson learned", convience is a trump card. Another item, is that as bad as many Web email providers are, the ISP and IT department email systems are often worse. Not for technical reasons, but for policy reasons. ISPs and IT departments love to skip spam filtering because it costs money and uses hardware. They love to restrict the size of your email store, and worse, start deleting or rejecting mail if you do not clean it out. And so on and so on. Compared to the hassles of dealing with an ISP's email or a corporate IT department, Web based email feels like freedom. Again, it is a matter of "convenience" versus "quality". It's like going to McDonalds instead of making a homemade burger. J.Ja

mattohare
mattohare

This reminds me of an old BBC comedy where a couple of suburbanites set up their own farm and all in their huge (by british standards, large by american standards) suburban lot. Their neighbors, at a cheeky moment called them self-sufficiency bores. That said, I often have trouble on that balance between having control over my realm and being able to go places. That family pretty much had to stay home. Even getting out of their London suburb was a massive issue. I'll travel around town, across the province, even to another continent. I may have my notebook computer with me, but sometimes I can't even find a place to use that. I've had to use friends' computers and the like. My webmail (yahoo) supported that. Also, I don't think I can come close to being as close to he quality of their spam protection. I complain about it sometimes. Especially how spam takes the express route to the bit bucket, bypassing the trash bin. (Oops, lost a message from a mate when I caught his name just after pressing 'OK' on delete.)

apotheon
apotheon

I'd probably start looking into hosting out of my home if FIOS came to my area, too. A business account in my area would double the cost of my Internet connection, by the way. That's pretty steep, especially considering I'd only have 768Kbps (max) upstream at that rate. With the variability of cable speed, that'd get throttled back considerably during peak hours, which is exactly when I'd need the bandwidth most. I'd actually need something like a dedicated T1 line at least to get the kind of reliable bandwidth I'd need to host everything at home. I'm probably better off just getting a colocation account -- but I'm not quite to that point yet in my hosting needs.

Justin James
Justin James

It is actually a surpisingly low bandwidth operation. I am on a low end business class account from TWC, I have better than T1 speeds at a fairly reasonable price, compare to just getting plain vanilla cable modem service. And Verizon FIOS is now in my area, I am waiting for the network to finally reach my place, and I can jump to there. :) J.Ja

apotheon
apotheon

I don't think I can fit a great plains buffalo in my closet, so I'll just keep getting my ground buffalo at the local Whole Foods. I don't have the bandwidth I'd need to host out of my closet.

Justin James
Justin James

... that I am someone who got so fed up with email hassles and such, I now self host from my closet. Not only do I make my own burgers, I raise the cows. ;) J.Ja

apotheon
apotheon

I use email addresses with my own domain names, thanks. I'm not managing my own mail servers, but I have no need to -- I choose webhosts pretty wisely these days, I think, and get exactly the service I need.