Earlier this week, I published <a href="http://www.informationweek.com/blog/main/archives/2008/11/google_apps_inv.html">Part I</a> of my recent interview with Rajen Sheth, who is known in the halls of Google as the inventor of Google Apps. Just the name <em>Google Apps</em> causes a bit of confusion. Many users of Google's browser-based word processor, spreadsheet, and presentations solutions think they are using <em>Google Apps</em>. Indeed, they are using Google's browser-based applications. B

David Berlind, Chief Content Officer, UBM TechWeb

November 7, 2008

10 Min Read

Earlier this week, I published Part I of my recent interview with Rajen Sheth, who is known in the halls of Google as the inventor of Google Apps. Just the name Google Apps causes a bit of confusion. Many users of Google's browser-based word processor, spreadsheet, and presentations solutions think they are using Google Apps. Indeed, they are using Google's browser-based applications. But Google Apps is more than just a colloquial reference to Google's portfolio of browser-based applications.Google Apps is a branded collection of those applications and more (for example, e-mail, group calendaring, and Web site hosting) that organizations who subscribe to the free (standard) or $50 per user per year premium versions get to call their own, literally. For example, if InformationWeek's parent company TechWeb susbscribed to Google Apps and you send e-mail to me at my e-mail address [email protected], the e-mail server that takes receipt of that e-mail may look like it lives in the domain techweb.com. But in reality, that e-mail server would be a part of Google's Gmail infrastructure.

There's also a degree of integration between the applications and services that make up the full cloud-based suite; much of which is rooted in the identity management services and collaborative connective tissue that's baked right into the fabric of Google Apps.

But, while Google continues to enhance the underpinnings of Google Apps in ways that help evolve the final user experience, there are some parts of that user experience that the server-side is powerless to do anything about unless the browser-side evolves as well.

Enter Chrome -- the Web browser that Google prereleased in an unfinished "beta" form at the beginning of September 2008. Hey, between Microsoft's Internet Explorer, Mozilla's Firefox, Apple's Safari, and Opera, didn't we already have enough browsers that aren't exactly compatible with one another. Did we really need another? Well, if you asked Google founders Larry Page and Sergey Brin, the answer is an unequivocal "yes." According to them, increasingly sophisticated Web applications are a core business of Google's and if building a new browser is what it takes in their mind for Google's Web applications to make their next quantum leap, then so be it.

I wanted to know from Sheth how, if at all, Chrome could a change-agent for his invention, Google Apps.

DB: I know that you're not a spokesperson for the Chrome team, but, in your opinion, was the release of Chrome a statement by Google that there was room for improvement in the fabric of the Internet, improvement that could be taken on by the browsers?

RS: There is always room for improvement [in the user experience of Web applications]. One of the big things with Chrome is to continue to increase the amount of innovation that's happening in the browser space. I think Chrome brought in a variety of really innovative ideas that continue to make it more and more palatable for people to use applications within the browser as the primary interface.

DB: Put that in context of one or more Google Apps. Tell us about something that happens in Chrome but not in other browsers.

RS: Let's say you're writing an article and you have your article open in Google Docs, you have your mail open [in Gmail] and you have a variety of things going on. You can get to the point where, in the browser, you can have many windows open. You can have many many tabs open at the same time. Let's say you're researching some stuff for the article and you go to the Web and you find a site. You click on that site and something happens. You end up with a video on that site that crashes your browser. Typically, if you're using other browsers, you're done. The whole thing crashes. All the work that you had is saved [DB's note: Due to Ajax-based interactivity not found in all Web applications, most of Google's Web apps have an auto-save feature] but then you're going to have to come back and go back to those Web sites and recreate [that environment where you had all your tabs open].

With Chrome [that video] crashes one thread and each tab is its own thread. Just like each application would be its own process in the operating system. As a result of that, you can treat things a little more independently.

Another thing about Chrome, which is kind of a simple UI thing but it's pretty powerful, is that you can have an interface to the application that doesn't have the browser bar, that doesn't have a lot of the other stuff at the top, so it feels more like an application. That's one of the things that I think is a hurdle for Web apps is that people kind of have a mentality about why they're using the browser: to find information. Now, we're moving them to the mentality that the browser can be the place that you go for applications and that helps kind of reinforce and make it easier to shift to that paradigm.

DB: Persistence? I've seen it in Docs. What about Spreadsheets and Presentations?

RS: Spreadsheets and Presentations [offer persistence via Google's Gears] in a read-only mode right now, so you can get [limited] access to those off-line.

DB: How does having a persistence mechanism built into the browser [the way Chrome builds it in] versus having it as plug-in [the way it's done in other browsers] change the equation for Google Apps or anybody who is in the Web apps business?

RS: It reduces the friction. It makes it such that people don't have to think about bringing that [plug-in] in. Just like people nowadays rarely have to think about having Flash built-in. Or having a PDF reader. Because, a lot of times, that just comes with the system.

So, I think it's the same thing here in that Gears will now just come built-in. They don't have to think about going and downloading [Gears] and installing it and updating it and everything. It will just become part of the platform. And it helps us to develop against Gears and not have to worry as much that people have to go and download it. But it helps other Web app developers as well, too. It makes it easier for them to go ahead and develop on top of gears and know that their users will have it and be ready to use it.

DB: Mozilla's direction does not include building Gears in. Let's say you're running on Chrome and inherit certain functionality with certain Web apps while other browsers involve more friction with those same Web apps. Doesn't that amount to the notion of vertical stacks, one from Chrome, one from Internet Explorer (which has been there as well), another one Mozilla, Safari, and so on?

RS: I don't think it leads us to that world. The reality for us, like [Google founders] Larry [Page] and Sergey [Brin] said, we're a Web application company. It would never serve us well if we only operate well in one browser setting. There would be a lot of users that we simply wouldn't be able to hit if we were doing that. So, we always strive to make these applications work in all of the major browsers and it's in our best interest to do that.

I think what Chrome serves to do is it continues to increase the amount of innovation in browsers. But I do think that standards and the ability to have a functionality that's available across all browsers is critical to that. If we're building on top of something that's only within Chrome, then it will reduce what we can do in our Web applications.

DB: How do we get to that point where we get a standard, because not everyone is going to agree on that? Adobe may argue that you should use their persistence mechanism. And Oracle has their own. Mozilla, from my perspective, they have to remain agnostic. They can't say let's take this Gears thing and make it part of Firefox because then everyone else who has a plug-in will say "What about us?, What are we, chopped liver?" So how do you get to that point? And I'm not just talking about Gears. You can see this happening with other things that are not yet part of the browser. This (Gears and off-line persistence) may be the first big one, but there will be others down the road.

RS: It's a great question. Some things can become standard across various things. Other things may never become standard. But there are three areas where we need to focus on to make sure these Web applications still work. The first thing is to make sure that the Web apps that rely upon things like Gears can work across many different browsers. Yes, Gears works within Chrome. But it also works within Firefox, Internet Explorer, and on the Mac and the PC. So, getting that kind of widespread footprint will ensure that it works in a variety of browser combinations.

The second thing is that in order for more and more people to adopt something like Gears (and I think Gears is a good example of something like this), they have to know that this isn't just something that Google is controlling. That was one of the reasons behind why we made Gears open source and that has helped us a lot because others have taken that and extended it and added functionality to it and then trusted that they could build their Web applications on top of it. Chrome is the same thing. We released it as open source so that others can take it and make it what they want it to be.

DB: But, so long as Microsoft and Apple and Mozilla resist the temptation to incorporate that code into the source-trees of their own browsers, it's still not a standard, though. Open source has the influence of creating a de facto standard, but it still has yet to get to that point of being a standard. Is there a way to break that impasse?

RS: I think part of it is usage, which gets to my third point, which is that if the Web apps are using these technologies, then the browsers are going to need to support these technologies. Even if it's not baked-in to each of the browsers, those technologies are going to need to be available across the various browsers. I mean, it's just like, for example, people started using Ajax very heavily a couple of years ago. And now, there isn't a browser out there that doesn't support very heavy JavaScript. Browsers will have to evolve to get to that point... better engines, ... better processing of that. So, I think the Web apps are going to push the innovation in the browser and the browsers will change as a result of that.

Next, in Part III: Google Apps inventor Rajen Sheth may say more innovation is on the way. But when asked to peer into his crystal ball, he starts by saying that three years ago, he couldn't possibly have anticipated the innovations happening today.

About the Author(s)

David Berlind

Chief Content Officer, UBM TechWeb

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights