Can you really make a business use case for Google Gears?

Google Gears has been gaining some headway in the Web development community after a beta version of the API was released in May. It is likely that already popular Web applications will enhance service offerings by incorporating Google Gears into their bag of tricks. Even though Google is vocal regarding the implications of using a beta release in a production environment, support from major players like Adobe is likely to push the product to full release soon enough.

If you are still questioning the affect that a product like Google Gears will have on your day-to-day work, or whether or not integrating with the API will boost demand for your software, then you are not alone. Up until this point, much of the information available is technically-oriented, and does little to document a detailed business use case. Although, you can begin to evaluate the usefulness of Gears by highlighting the primary concern addressed — diminished productivity without an Internet connection.

Before I get into specifics, and for the benefit of those still in a fog, let me explain briefly what Google Gears is not. First and foremost, it is not Google Gadgets, and therefore does not perform a task or function as a standalone product. It is an API, which simply means it is the gateway between two or more existing (visual) interfaces. For our purposes, it is a gateway between your offline operating system, and your online Web application. Also, unlike some plug-and-play APIs, using Google Gears will require integration, the level of which will depend on the complexity of your software.

Although the term may be a misnomer, offline Web application productivity is not a new concept. In March 2007, Adobe released Apollo (now known as AIR), which is a software development kit (SDK) for creating rich media Internet applications. One of the primary features, is that you can work offline, and then synchronize data that you modified locally with live data after reconnecting to the Internet. The demonstration of the beta release included an almost fully featured eBay desktop application, with which you could sign in and manage existing auctions.

Google Gears is not a competitor to AIR, and Adobe will likely incorporate the new API into their SDK. However, while examining both of these tools, one has to wonder, how much productivity is actually lost while offline? So much that a tool like Google Gears is a necessary evil? According to Wikipedia, “An engineer created a Gears version of Google Reader as part of the company’s program in which employees can work on their own projects for 20 percent of their work week… the engineer wanted to be able to access Google Reader while commuting on the company shuttle, which often has “flaky” Internet access.” Do so many of us need to be as connected as this scenario illustrates?

Because Google has been successful with their previous suite of services, the development community is quick to embrace what the company has to offer. With good reason, it pays to be an early adopter, and to reap the benefits of expertise in a technology that could become wildly popular. However, before jumping on the bandwagon for this latest release, we should take a step back and gather our thoughts. Instead of selling Google Gears to the product development team, or your boss, take a minute and consider the following.

Working offline is a manual process

At the present time, choosing to work offline is a manual process, and must be initiated by the user. As the API is improved, I am sure this will change. However, for the time being, users are required to synchronize before disconnecting from the Internet. Then, from the browser’s file menu, they must choose to work offline. The entire process is rather cumbersome according to the tutorials, and it also requires clearing cache frequently to ensure cached versions of the page are not being served. For the average user this is an inordinate amount of work for a process that should be seamless. If my connection falters, I should instead be prompted to work offline, and my current work should instantly be saved to my desktop.

Providing a feature that is relatively untested

A common issue associated with the early adoption of a new API, is that you are also first to adopt the bugs or glitches. Ignoring warnings by Google, some software is already incorporating Gears in the production environment. Users with little or no insight into the service offering, will take it at face value. Indicating the risk does not give a company the right to relinquish responsibility, especially since the average user will not understand the implications. If you decide to move forward with the API long before the beta is over, then you are gambling with your product’s reputation by providing a feature that is relatively untested.

Missing metrics in the offline experience

A key factor that contributes to the success of any Web application or software as services offering, is metrics. Being able to track how users are navigating the system is an essential component, that when analyzed, can provide valuable insights. When the user begins working offline, you lose this advantage. If you currently provide these metrics through an in-house solution, then you can certainly build a component to manage the user input offline. However, if you use third-party tracking tools, the user’s interactions will no longer be transparent to you. If Gears gains steam, then Google should capitalize by providing offline analytics to compliment the solution.

Increasing bandwidth costs in order to support synchronization

One factor that may deter companies from supporting an increase in offline productivity on an enterprise scale, is the bandwidth required to constantly synchronize. While a few employees might not significantly affect network performance, bandwidth is sure to be compromised when simultaneous users log on Monday morning. You can argue that the efficiencies you gain, or that the customers you attract, outweigh the costs to run Google Gears. Nevertheless, this should be an issue that is addressed when considering whether offline productivity is of utmost importance to the success of the software or the company.

Providing a secure gateway to a user’s sensitive information

I want to believe Google will close up all inherent security holes during beta testing, but I also realize that hackers are more progressive than most would care to admit. Although email phishing scams probably pose more of a threat, the reality is that if you provide an API built around JavaScript, then you are open to cross-site scripting attacks. For some time the browser has been a gateway to the desktop, but now the gateway would lead directly to the API itself, which could include sensitive information. I would disagree with the notion that JavaScript is the wrong tool for the job, but any software that implements the API should take great care to understand the risks.

Concluding thoughts

These points are in no way a detriment to the hard working Gear’s engineers, and the primary purpose here is to supply a bit more introspection. Interest in offline Web applications is obviously growing, and I am sure that interest will spawn a slew of innovative offline desktop widgets built with the API. As is common with most open-source initiatives, it will ultimately be the community of developers that helps evolve the code. However, more frequently we are also being called upon to offer a business use case because we understand the particular nuances of the software. In a situation such as this we should not take that responsibility lightly.

• Posted by Brian
• July 22nd, 2007