Earlier this year I was approached about writing a book on cloud computing topics by an editor for one of the big computer book publishers. Given that between my day job and having an infant I barely have time to keep this blog updated, I had to turn down the offer. However I did spend some time taking a second look at various cloud computing platforms like Amazon Web Services and Google App Engine then trying to put myself into the mindset of a potential customer as a way to figure out the target audience for the book. Below are the two categories of people I surmised would be interested in spending their hard earned cash on a book about cloud computing platforms

1. Enterprise developers looking to cut costs of running their own IT infrastructure by porting existing apps or writing new apps. 
2. Web developers looking to build new applications who are interested in leveraging a high performance infrastructure without having to build their own.

As I pondered this list it occurred to me that neither of these groups is well served by Google App Engine.

Given the current economy, an attractive thing to enterprises will be reducing the operating costs of their current internal applications as well as eliminating significant capital expenditure on new applications. The promise of cloud computing is that they can get both. The cloud computing vendor manages the cloud so you no longer need the ongoing expense of your own IT staff to maintain servers. You also don't need to make significant up-front payments to buy servers and software if you can pay as you go on someone else's cloud instead. Google App Engine fails the test as a way to port existing applications because it is a proprietary application platform that is incompatible with pre-existing application platforms. This same incompatibility rears its head when you look at App Engine simply as a way for enterprises to do new development. App Engine is based on Python, which if you look at the State of the Computer Book Market 2008, part 4 -- The Languages is not a terribly popular programming language. In today's world, enterprise development still means Java or .NET development which means enterprises will favor a platform where they can reuse their existing skills and technology expertise. Google App Engine isn't it.

So how about Web developers? In my classification, I broke up Web developers who'd be interested in cloud computing into hobbyists (like myself when writing a Twitter search engine on Windows Azure) and professionals (like myself when working on the platform that powers Hotmail's recently launched social features). Hobbyists either don't spend money or spend relatively little so I discounted them as a target audience of interest. The professional Web developers interested in cloud computing would be those who are considering Server or Web hosting but have concerns about scaling up if their service gets successful. After all, it seems like every week you are either reading about scaling hurdles that startup developers have faced as their applications become successful whether it is Bret Taylor's recent post How FriendFeed uses MySQL to store schema-less data or Jeff Atwood's Deadlocked! which talks about how he had to learn more about SQL Server's locking strategy as StackOverflow.com became more popular. The fact that Google App Engine is limited to only Python meaning that it is unavailable to developers using WISC platforms and only a subset of developers using LAMP can participate on the platform. Furthermore, there are key limitations in the platform that make it infeasible to build a full scale application. For example, Bret Taylor mentions that a consequence of having a denormalized database they need to run a background "Cleaner" process which fixes up data references and makes their database consistence. The App Engine DataStore API requires applications to store data in a denormalized way but there is no facility to run background processes to clean up the data as FriendFeed and most other large scale services which use database sharding often do. According to a recent blog post the Google App Engine roadmap has been updated so at least this limitation will be addressed. Other limitations for Python developers are that they can't use all of their existing knowledge of Python libraries since it only supports a subset of Python libraries. Database developers may be relieved that a lot of database management tasks no longer exist but may be chagrined once they see the restrictions on queries they can perform and hear some of the horror stories about query performance. At the end of the day, it just didn't seem to me that there were many professional Web developers who would put up with all of this pain over just going with AWS or dedicated hosting.

That said, Google App Engine does address the long tail of developers which I guess is nothing to sneeze at. Maybe it will see some success from targeting the low end in the same way that AdSense targeted the long tail of advertisers and is now the powerhouse of search advertising. Maybe. I doubt it though.

Now Playing: Aerosmith - Livin' On the Edge

 

Earlier this morning I was reading a number of comments in response to a submission on reddit.com where I found out that despite being a regular visitor to the site there were multiple useful features I was completely unaware of. Here's a list of features I discovered the site has that I hadn't noticed even though I visit it multiple times a day

• Private user-to-user messaging feature including an inbox containing all responses to your comments.
• A social networking component which enables you to customize the site so you only see content from your friends.
• An option for bookmarking my favorite stories so I could come back to them later

These are all clearly useful features. In fact, some of them are features I'd have lobbied for if ever asked what features I'd like to see added to reddit even though they already existed. Considering that I'm a fairly savvy Web user and visit the site multiple times a day, it is problematic that I'm unaware of valuable features of the site which were the result of valuable effort from the developers at reddit.

This is a very commonplace occurrence in software development. As applications add features without wanting to clutter the interface, they begin to "hide" these features until it gets to the point where their users end up clamoring or pining for features that actually already exist in the application. A famous example of this comes from Jensen Harris' series of posts on the UI changes in Office 2007. There is rather informative post entitled New Rectangles to the Rescue? (Why the UI, Part 4) which contains the following excerpt

Contrary to the conventional wisdom of the naysayers, we weren't (and aren't) "out of ideas" for Office.  Customers weren't telling us that they didn't need new features--to the contrary, the list of requests is a mile long.  Every version we were putting our heart and soul into developing these new features, undergoing a rigorous process to determine which of the many areas we would invest in during a release, and then working hard to design, test, and ship those features.  The only problem was that people weren't finding the very features they asked us to add.

To address the issue above, the Office team effectively dedicated a release to making their existing features discoverable¹. This isn't the only example of a popular application dedicating a release to making features more discoverable instead of adding new features. The Facebook redesign of last year is another famous example of this which has lead to increased usage of the site.

A recent TechCrunch article, Facebook Photos Pulls Away From The Pack shows the effect of the redesign on the usage of the site

...
What accounts for Facebook’s advantage in the photo department? The biggest factor is simply that it is the default photo feature of the largest social network in the world. And of all the viral loops that Facebook benefits from, its Photos app might have the largest viral loop of all built into it. Whenever one of your friends tags a photo with your name, you get an email. This single feature turns a solitary chore—tagging and organizing photos—into a powerful form of communication that connects people through activities they’ve done in the past in an immediate, visual way. I would not be surprised if people click back through to Facebook from those photo notifications at a higher rate than from any other notification, including private messages.

But the tagging feature has been part of Facebook Photos for a long time. What happened in September to accelerate growth? That is when a Facebook redesign went into effect which added a Photos tab on everyone’s personal homepage.

The lesson here is that having a feature isn't enough, making sure your users can easily find and use the feature is just as important. In addition, sometimes the best thing to do for your product isn't to add new features but to make sure the existing features are giving users the best experience.

When you do find out that usage of a feature is low given it's usefulness and relevance to your user base, this is a good time to invest in an experimentation platform where you can perform A/B testing (aka split testing) and multivariate testing. There are a number of off-the-shelf tools for performing such experiments which enable you to test and validate potential redesigns today without unleashing potentially negatively impacting changes to your entire user base.

---

¹I believe the Office team shipped lots of new features as well in Office 2007, however the biggest change from an end user's perspective was the redesign not new features.

Now Playing: Metallica - Harvester of Sorrow

 

I often wonder whether the founders of Twitter think of the site as a social utility that helps keep people connected with the people they know and care about like Facebook or whether it is primarily another personal publishing platform like Blogger. How they view the service influences the features that are the added to the site and its evolution.

For example, take a simple feature like "friend suggestion". A site that views itself as a social utility would implement such a feature in a way that attempts to bring you together with people it thinks you know or who've implied they know you. A site that views itself as a personal publishing platform for would-be pundits and people interested in them will end up recommending the most popular users in a move that mirrors the Bloglines Top 100 or recommending people based on editorial choice instead of how they relate to you.

Now compare the results of Twitter's Suggested Users feature shown below 

with one of Mr. Tweet's various recommendation options

Twitter's suggestions for me include a grocery store, the microblog of an online shoe store CEO and a mommy blogger. On the other hand, Mr. Tweet has actually recommended people I have met or at least know professionally. As I go down the list of recommendations from Mr. Tweet and finally encounter people I don't know they are at least people who move in the same circles as me online. On the other hand Twitter's list contains a grab brag of celebrities and brands that have no direct connection to me.

Twitter is squandering an opportunity to grow their social graph in a way that deepens their users connections on the site and with the site. If I were in their shoes, I'd pick up Mr. Tweet in the same way they picked up Summize because the technology and feature set nicely complements the site and fills a hole in their user experience.

Now Playing: Metallica - Leper Messiah

 

There's some storm in a teacup around Facebook's terms of service which is in reality just another iteration of the freak-out-because-web-company-changed-their-terms-of-service that we see in the blogosphere every couple of months. For the most part this is a boring dance but there is an interesting issue around end user expectation around sharing content and ownership of their personal data underneath all the melodrama.

The point of interest is called out in Mark Zuckerburg's post On Facebook, People Own and Control Their Information where he writes

One of the questions about our new terms of use is whether Facebook can use this information forever. When a person shares something like a message with a friend, two copies of that information are created—one in the person's sent messages box and the other in their friend's inbox. Even if the person deactivates their account, their friend still has a copy of that message. We think this is the right way for Facebook to work, and it is consistent with how other services like email work. One of the reasons we updated our terms was to make this more clear.

The issue of what to do with content a user has shared when they decide to delete the content or attempt to revoke it is in an interesting policy issue for sites geared around people sharing content. When I've discussed this with peers in the industry I've heard two schools of thought. The first is that when you share something on the Web, it is out there forever and you have to deal with it. Once you post a blog post, it is indexed by search engines and polled by RSS readers and is then available in their caches even if you delete it. If you send an inappropriate email to your friends, you can't un-send it. This mirrors the real world where if I tell you a secret but it turns out you are a jerk I can't un-tell you the secret.

The other school of thought is that technology does actually give you the power to un-tell your secrets especially if various parties cooperate. There are ways to remove your content from search engine indexes. There are specifications that dictate how to mark an item as deleted from an RSS/Atom feed. If your workplace uses Outlook+Exchange you can actually recall an email message. And so on. In the case of Facebook, since the entire system is closed it is actually possible for them to respect a user's wishes and delete all of the content they've shared on the site including removing sent messages from people's inboxes.

I used to be a member of the second school of thought but I've finally switched over to agreeing that once you've shared something it's out there. The problem with the second school of thought is that it is disrespectful of the person(s) you've shared the content with. Looking back at the Outlook email recall feature, it actually doesn't delete a mail if the person has already read it. This is probably for technical reasons but it also has the side effect of not deleting a message from someone's inbox that they have read and filed away. After all, the person already knows what you don't want them to find out and Outlook has respected an important boundary by not allowing a sender to arbitrarily delete content from a recipient's inbox with no recourse on the part of the recipient. This is especially true when you consider that allowing the sender to have such power over recipients still does not address resharing (e.g. the person forwarding along your inappropriate mail, printing it or saving it to disk).

At the end of the day, many people would like to use technology to solve what is essentially a social problem instead of adjusting their behavior. The bottom line is that even though it is technically possible for Facebook to delete my private messages from your inbox when I decide to delete my account, it would be harmful to your user experience AND it doesn't buy me anything since you've already seen the content. The real solution is for me not to have sent any messages to you that I'll later regret in the first place.

Now Playing: Bush - Everything Zen

 

The New York Times has an article titled How Google Decides to Pull the Plug which talks about the rationale behind the rash of abandoned and cancelled projects that have come out of the Big G in recent months. The article contains the following interesting excerpts

GOOGLE recently set the blogosphere abuzz by announcing that it was pulling the plug on several products.

The victims included Lively, a virtual world that was Google’s answer to Second Life; Dodgeball, a cellphone service aimed at young bar-hoppers who wanted to let their friends know where they were hanging out; Catalog Search, which scanned paper product catalogs so they could be searched online; and Notebook, a simple tool that allowed people to take notes on Web sites they had visited.

Google also said it would stop actively developing Jaiku, a microblogging service similar to Twitter, and instead turn it over to its users as an open-source project they could tinker with as they wished.
…
All of the shuttered projects failed several of Google’s key tests for continued incubation: They were not especially popular with customers; they had difficulty attracting Google employees to develop them; they didn’t solve a big enough problem; or they failed to achieve internal performance targets known as “objectives and key results.”

You’d think that Google, a highly profitable engineer’s playground, would keep supporting quirky side projects as long as someone wanted to work on them. The company, which is best known to consumers for its search engine, is famous in business for promoting innovation by letting engineers devote 20 percent of their time to projects outside their main responsibilities.

But in this difficult economy, even Google is paying more attention to costs.
…
Lively, Google’s entry into three-dimensional virtual worlds, was publicly unveiled last July. Four months later, when the company decided to close it, only 10,000 people had logged into the service over the previous seven days. That was well below the targets set by Google’s quarterly project review process, and far behind Second Life from Linden Lab, which had about half a million users in a similar period.

“We didn’t see that passionate hockey-stick growth in the user base,” said Bradley Horowitz, Google’s vice president for product management. Management decided that the half-dozen people working on Lively could be more productive elsewhere.

It will be interesting to see what the long term effects of these changes in perspective will be on Google's culture around launching new products out of 20% time projects and the veneration of side projects at the Googleplex. One expected change is that employees will be more conservative around what 20% projects they choose to work on so that they don't end up wasting their time on the next Google Page Creator or Google Web Accelerator which is received with initial hype but quickly discontinued because it doesn't see "hockey stick growth in user base".

You can already see this happening somewhat by looking at how many side projects are being shipped as part of Gmail labs. Checking out the list of Gmail labs offerings I see over 30 big and small features that have been added to Gmail as side projects from various individuals and teams at Google. It seems on the surface that a lot of Google employees are betting on tying their side projects to a huge, successful product like Gmail which isn't in danger of being cancelled instead of working on new projects or helping out smaller projects like Dodgeball and Jaiku which eventually got cancelled due to lack of interest.

This expectation that a new Google product will need massive adoption to justify its investment or be cancelled within four months, as was the case with Google Lively, will be a significant dampener new product launches. Reading Paul Buchheit's post on the early days of Gmail I wonder how much time he'd have invested in the project if he was told that Google would cancel the project if it's user base growth wasn't competitive with market leaders like Yahoo! Mail and Hotmail's within four months.

I suspect that the part of Google's DNA which spurs innovation from within is being killed. Then again when you look at Google's long list of acquisitions you realize that a lot of their most successful projects outside of search including Google Maps, Blogger and YouTube were the results of acquisitions. So maybe this culture of internal innovation was already on the way out and the current economic downturn has merely sealed its fate.

Now Playing: Metallica - Fade To Black

 

The MIX '09 conference site has announced the panel I'll be moderating at this year's conference in the post titled Opening the “Walled Garden” of Social Networks which is excerpted below

As social networking sites become more and more numerous, and consumers are looking to simplify their online lives,  providers are scrambling to define the path forward for social network aggregation.  Join us at MIX for a special guest panel on “Standards for Aggregation Activity Feeds and Social Aggregation Services”. 

Check out this killer line-up of panelists - big names and leading companies in the online and social networking space:

Dare Obasanjo (Moderator) – Microsoft

Kevin Marks – Software Engineer at Google; formerly principal engineer for Technorati; one of the founders of Microformats

Marc Canter – CEO at Broadband Mechanics; founder of Macromedia

Monica Keller – Dev Manager at MySpace; formerly Architect at SumTotal

Joseph Smarr – Chief Platform Architect at Plaxo

If you haven’t registered for MIX09 by now, what exactly are you waiting for, an invitation?  Consider it delivered.

This should be a fun panel and if you'll be at MIX and are interested in where activity streams and social network interoperability is going then you should attend.

PS: I believe John McCrea may be replacing Joseph Smarr on the panel due to scheduling issues.

Now Playing: Wu-Tang Clan - Reunited

 

This past weekend, I bought an Apple iPhone as a replacement for my AT&T Tilt which was slowly succumbing to hardware glitches. As a big fan of Windows Mobile devices and their integration with Microsoft Exchange I was wary of adopting an iPhone. I was concerned about it not having all of the features I'd gotten used to but on the other hand I was looking forward to replacing my iPod+AT&T Tilt combination with a single device.

Here are my positive and negative impressions of the device after five days

The Good

There are lots of things I like about the iPhone experience. Below are my favorite aspects of the experience thus far

• Visual Polish: The visual polish of the 1st and 3rd party applications on the iPhone is amazing. There are so many nice touches in the phone from the coverflow browsing experience when playing music to the transparent pop over windows when you receive an SMS text. The few 3rd party applications I've used have also seemed similarly polished although I've only downloaded less than ten apps. It's like using a futuristic device that you see in movies not an actual phone from real life. 

• Browsing and Purchasing Applications: As someone whose used Handango and ActiveSync to install applications on my Windows Mobile device, I have to say that experience pales in comparison to being able to browse, search, purchase and install apps directly from my phone. Having the app store integrated into iTunes actually seems superfluous.

• It's also an iPod: I used to think my iPod classic was a fantastic music playing device until I got my iPhone. Now it seems rather primitive and ugly. I shocked at how much better the music playing experience is on my iPhone and have tossed my iPod classic into our junk drawer.  Now my pockets are lighter and I got an iPod upgrade. Nice. 

• The Web browser: The browser supports multi-touch for zoom and it does AJAX. Hell, yeah.

• Autocomplete when sending emails: When sending a mail, it uses autocomplete to fill out the TO/CC/BCC line by looking in your contact list and the email addresses of people in your inbox. This is a very nice touch.

The Bad

There are also a number of features I miss from owning a Windows Mobile device which I hope are addressed in the future or I might eventually find myself switching back

• Email Search: Windows Mobile devices can search emails in your Exchange inbox by sending a query to the server. Using this functionality you aren't limited to searching the emails on your device but can search at least month of emails and get the results sent down to your phone. The iPhone has no email search functionality.

• No integration with the Global Address List: On my AT&T Tilt I often needed to send emails to co-workers whose email addresses weren't in my contact list. All I needed to do was type out their names and then I could pull up their information (email address, phone number and office location) down to my phone to either add them as a contact or insert their email address into an email. I've felt rather handicapped without this functionality.  The autocomplete feature which uses all the email addresses from your local inbox has been a slight mitigation.

• No Flash in the browser: After getting used having a Flash-capable browser on my AT&T Tilt via Skyfire it is rather irritating that I've now lost that functionality by switching to an iPhone. You don't really notice how much Flash video content there is on the Web until you start missing it. My last post was of a Flash video which is a broken link when I browse my blog from my iPhone. Lame.

• Managing meetings is awful: As a program manager at Microsoft I schedule a lot of meetings. Every once in a while I may be running late for a meeting and have to either send a mail out to the attendees telling them I'll be late or cancel the meeting. Neither of these options is available on the iPhone.

• Reply flags not set in Exchange: With a Windows Mobile phone, when you respond to a mail via the phone it is properly marked as a mail you've replied to when you view it in Outlook on the desktop. The iPhone developers remembered to track which emails you've responded to on the device but failed to propagate that information back to Exchange. For a while, I thought I was going senile because I remembered responding to mails but they weren't marked as being replied to in my inbox. After I found my replies in my Sent mail folder, I realized what was wrong. 

• Tasks: Although I've never tried Getting Things Done, I am a big fan of Outlook Tasks and often add new tasks or mark them as complete from my phone. The iPhone does not synchronize your Outlook tasks from Exchange which is a glaring oversight. For now, I've gotten around this by spending $10 on KeyTasks for the iPhone which is somewhat hacky but works. 

The Ugly

So far there have been two aspects of the user experience that have been facepalm worthy

• Ringtones: On my AT&T Tilt it was pretty straightforward to make any MP3 snippet eligible to be used as a ring tone simply by dropping it in the right folder. The iPhone requires that I pay $0.99 for a song I already own to use it as a ring tone. Seriously?

• Using your iPhone on multiple computers: I typically purchase music and burn CDs on my home computer while using my iPod as a music library at work. This functionality is disabled out of the box on the iPhone. You can only sync your iPhone to one computer which includes only being able to play music off of your iPhone on a single computer. This is pretty ridiculous given multicomputer households and people who use their iPhones at home and at work. Thankfully, the Internet is full of workarounds to this foolishness on Apple's part. 

Despite what looks like a long list of complaints this is probably the best mobile phone I've ever owned. It just isn't perfect.

Now Playing: Jay-Z - Can't Knock the Hustle

 

<a href="http://video.msn.com/?playlist=videoByUuids:uuids:533e05d2-9f12-4a86-bdda-efd0455fcd36&amp;showPlaylist=true" target="_new" title="Kylie uses Windows Live Photo Gallery">Video: Kylie uses Windows Live Photo Gallery</a>

Now Playing: Cranberries - Linger

 

There used to be a time when all you needed when building a Web site was a relational database, a web server and some sort of application server or web framework (terminology depending on whether you are enterprisey or Web 2.0) that acted as a thin layer to translate requests into database queries. As we've grown as an industry we've realized there are a lot more tools needed to build a successful large scale modern web site from messages queues for performing time consuming tasks asynchronously to high availability cloud management tools that ensure your site can keep running in the face of failure.

Leonard Lin has a [must bookmark] blog post entitled Infrastructure for Modern Web Sites where he discusses the underlying platform components you'll commonly see powering a large scale web site in today. The list is included below

I’ve split this into two sections. The first I call “below the line,” which are more system level (some things straddle the line):

• API Metering
• Backups & Snapshots
• Counters
• Cloud/Cluster Management Tools
  • Instrumentation/Monitoring (Ganglia, Nagios)
  • Failover
  • Node addition/removal and hashing
  • Autoscaling for cloud resources
• CSRF/XSS Protection
• Data Retention/Archival
• Deployment Tools
  • Multiple Devs, Staging, Prod
  • Data model upgrades
  • Rolling deployments
  • Multiple versions (selective beta)
  • Bucket Testing
  • Rollbacks
  • CDN Management
• Distributed File Storage
• Distributed Log storage, analysis
• Graphing
• HTTP Caching
• Input/Output Filtering
• Memory Caching
• Non-relational Key Stores
• Rate Limiting
• Relational Storage
• Queues
• Rate Limiting
• Real-time messaging (XMPP)
• Search
  • Ranging
  • Geo
• Sharding
• Smart Caching
  • dirty-table management

Leonard Lin's list comes from his experience working at Yahoo! but it is consistent with what I've seen at Windows Live and from comparing notes from publications on the platforms behind other large scale web services like Facebook, eBay and Google. This isn't to say you need everything on the above list to build a successful web site but there are limits to how much a service can scale or the functionality it can provide without implementing almost every item on that list.

This brings me to Google App Engine (GAE) which is billed as a way for developers to build web applications that are easy to build, maintain and scale. The problem I had with GAE when I took an initial look at its service is that although it handles some of the tough items from the above list such as the need for high availability cloud management tools, deployment tools and database sharding, it was also missing some core functionality like message queues. These oversights made it impossible to build large classes of Web applications such as search engines or email services. It also made it impossible to build asynchronous workflows in ways that improve responsiveness of the site from an end user's perspective by reducing request latency.

So it was with some interest I read Joe Gregorio's post on the Google App Engine blog entitled A roadmap update! where he updates the product's roadmap with the following announcement

The App Engine team has been plugging away and we're excited about some pretty big announcements in the near future. In the meantime, we decided to refresh our App Engine roadmap for the next six months with some of the great new APIs in our pipeline:

• Support for running scheduled tasks
• Task queues for performing background processing
• Ability to receive and process incoming email
• Support for sending and receiving XMPP (Jabber) messages

As always, keep in mind that development schedules are notoriously difficult to predict, and release dates may change as work progresses. We'll do our best to update this roadmap as our engineers continue development and keep you abreast of any changes!

The ability to send email and the ability to perform background processing tasks are key features you'd need in any modern site. I've been wanting to try out GAE as a way to keep my Python skills fresh but have balked at the lack of background tasks and message queues which artificially limits my creativity. Once these announced features are done, I may have to take back my comments about GAE being only useful to toy applications.

Maybe next time C|Net asks Is Google App Engine successful? the answer will be "Yes".  Or at least the possibility that the answer will be "Yes" will go up a few orders of magnitude since it definitely doesn't seem to be successful today.

Now Playing: Playa Fly - Feel Me

 

Alex Payne has a great criticism of both Web and desktop email application in his post The Problem With Email Clients which accurately captures some of the frustrations I've had with both classes of email clients. The entire post is a must read if you've ever thought about how email can be improved. Some key passages from his post are 

Anyone who’s given Gmail a fair shake will quickly find conversations indispensable. Going back to any other email client is agonizing and disorienting, like being knocked around and dumped out of the back of a pickup on the outskirts of a strange town. In desktop email clients, new messages arrive completely bereft of context. The only way to orient yourself is to either remember what the conversation was about or read through the mess of quoted text that may or may not be present at the bottom of the message, depending on what kind of email client or prefences the sender has. You could try searching to re-orient yourself, but good luck with that in Outlook or Mail.app.

With conversations, Google has offered the only advancement in the information architecture of email clients in decades. Apple, on the other hand, has given us basically bupkiss, rendering Neven’s defense a bit silly.
…
This is probably heresy coming from a web application developer, but I think web applications are mostly ghastly. I hate using them. When I’m faced with a computing problem, I want to solve it with a polished, stable, native application for my operating system that looks and feels like it belongs on my computer. I don’t believe in Rich Internet Applications — they’re a boogeyman that I keep hoping will disappear.

The problem with Gmail is that it could be a “real” application. While its conversations and search-that-actually-works are (sadly) innovative, they’re not impossible to implement as part of a platform-native email client. I enjoy using Gmail, but I’d enjoy it even more if it obeyed the rules of my operating system, not the rules of the web. The web has a lot to offer certain types of problems, but I’m not convinced that email is one of them.
…
The problem with desktop email clients is that they’re not webmail. The problem with webmail is that it’s not a desktop email client.

I think Alex is on to something here. I prefer to read read my Hotmail account in Outlook via the Microsoft Outlook Connector because I'd rather read my email in a desktop app than in a Web app trying to look like a desktop app. On the other hand, I read my RSS feeds in RSS Bandit even though Outlook is an extremely popular RSS reader because I'm dissatisfied with how Outlook presents messages and feel an app I wrote myself does it more effectively.

Clearly there is room for a revolution here.

Now Playing: R.E.M. - Everybody Hurts