Is Google Doing Something Evil?
Jun 23, 2008 – 21:24 by Ryan
We have to preface this post by stating that we love Google Apps. We’ve been using Google Apps at Deft Labs for almost two years and have had a fantastic experience. It’s an excellent product for the price. Everyone pays $50 per user per year for a slew of business tools (a fantastic browser-based e-mail tool, group calendar, e-mail lists, browser-based office suite, etc.). This breaks down to ~$0.14 per day per user. Microsoft Office will run you ~$0.18 per day per user if you buy one new $260 license every four years. Additionally, if you stop using Google Apps after two years, you would have only spent ~$0.14 per user per day versus the ~$0.36 you would’ve paid for Microsoft Office. If you factor in the e-mail server hosting expense, you’re looking at a cost per user per day that is an order of magnitude higher when using Microsoft Office.
Productivity Gains
What’s difficult for most people is the switch to a purely web-based solution. For years, people have been using the same interface for their office tools. When you introduce a new tool you can expect to suffer an initial productivity setback. After your users have adjusted to the new tool, you should see a significant productivity gain. Google runs their highly successful business on the same tools.
Inbox Zero
One of the most important productivity gains we discovered with Google Apps is the concept of Inbox Zero. The basic premise of Inbox Zero is that you only have action items in your e-mail inbox. Everything else is archived or organized by a limited set of labels. One of the major setbacks of Outlook is search. There really is no comparison to the e-mail search capabilities of Google Apps. Even amongst thousands and thousands of e-mails, it’s easy to find the one you’re looking for. In Outlook, people tend to compensate for poor search capabilities by archiving their e-mail in (often) scores and scores of nested folders. The overhead associated with organizing and accessing data in this manner can often be overwhelming. SAI recently released a similar post describing the cost of compulsive e-mail monitoring.
What Evil?
Alright, now we have to justify our title :-) Recently, we went to renew our Google Apps account and when we were presented with the checkout screen we weren’t able to adjust the number of user accounts. This was on the confirmation page before the checkout (i.e., billing) page. Next, we thought about what e-commerce sites on the Internet don’t allow customers to modify the quantity of their order before checkout, and we couldn’t think of one. After clicking around for a minute or so we weren’t able to figure out how to change the quantity. Eventually, we sent a message to customer support and a day or so later they cheerfully responded with a link to a help page. After reading ten or so FAQs entries we found the section we needed to solve the problem.
photo credit: dreamerofm
Help Pages?
A not-so-radical theory in user interface design is that help pages are a list of failures. Sometimes they’re intentional but most of the time they document strange scenarios/functionality that isn’t intuitive to the majority of users. Looking at this issue, it’s obvious to us that modifying the quantity of your order should be apparent to everyone. The real question we had to think about is does Google not understand that modifying your order before checkout needs to be obvious or did they intentionally make it difficult in hopes that they would experience a rebate effect (i.e., if you require the customer to go out of their way then they probably won’t make the effort to do so, even if money is involved).
If you consider that Google has 92% of the web-based productivity market then you realize the amount of money that could be collected by making a quantity change difficult. One pleasant surprise is that they pushed our renewal date back a few days to allow us to compensate for the customer support interaction :-)
Sphere: Related Content
As cloud platforms and services start to make their way to the market, we think it’s becoming obvious how the industry will play out. To understand the future, it’s important to look at the past.
Serious Clouds
For the last few decades, there have been two primary methods for developing software. The first is the remote model where engineers write software on a networked server. Typically, an engineer will open a remote terminal session and use either 
