Google Apps grows more commercial, adding scripting to 'Premier'

By far the strongest feature of any operating system or applications suite -- when its architects bother to include it -- is the ability for its own users to program new and unique features into it. It's also the least appreciated feature on the marketing list; but businesses that have invested heavily in Microsoft Office over the years typically have an extensive library of Excel macros, a war chest of VBA functions built into their Word templates, and a spaghetti tangle of Outlook rules.

Today, Google premiered its approach to user-designed extensibility for its online Apps suite, and so far it's exactly what you might expect from Google: Its Apps Script language doesn't reinvent the wheel, leveraging its grammar completely from JavaScript, which many developers already know. It uses a basic set of terms for representing the graphical objects in the system, and a simple array of methods for making things happen and applying functions to menus. And as for how it can actually improve your work, Google pretty much leaves that up to you.

But folks curious enough to peruse the company's tutorials, which ask users to test their skills on prepared document templates, very quickly find themselves in either of two situations: directed toward a sign-up sheet for "Premier Edition" where they prepare to subscribe for $50 per user per year, or with an open template whose Tools menu -- the place from which the script editor is launched -- is completely disabled.

Although there's no up-front notice of this fact whatsoever, our tests reveal that the new scripting feature is clearly limited to Premier Edition subscribers, whose licenses cost $50 per user per year, and whose DNS registries often include MX records that point to Google's Gmail servers.

Slowly but most certainly, Google is shifting the bar between free and commercial functionality, certainly with good reason -- its intent is to build the market in software, and there is no market in "free." But the company hasn't been straightforward in how it goes about introducing commercial services, specifically toward customers who have had the "free" aspect of Google software drummed into their heads for so long.

This morning's blog post from the company does mention that scripting is available for Premier and Education class customers, although folks are only now learning what the distinctions there are. For awhile, TechCrunch's Michael Arrington couldn't find the free Google Apps and thus proclaimed it "history;" it does still exist, but is harder to find without a link like this one to take you there. Prospective Google Apps users are now directed to the Premier sign-up sheet, and away from Standard.

Premier users who make it through to the scripting examples will find that Google has created something similar to what Microsoft would call a type library, representing the features of each application with a little vernacular. The model here is surprisingly similar to what you'd see in Office. For the Google Docs spreadsheet, for example, the application is represented by the centralized object SpreadsheetApp (the counterpart to Excel.Application). The active workbook, or collection of spreadsheets, is a property of this object that you collect using a method .getActiveSpreadsheet(), and assign to a variable as you instantiate it using var; for individual sheets, you collect each one using the .getSheets() method, referring to its place in the workbook using the subscript. (VBA here would use member objects instead of methods, but assigning the properties of member objects to a variable would work pretty much the same way.)

Google makes the point that Apps scripts are run on Google's servers, not on your client system -- and that's important because it seriously affects the offline functionality of your applications. Certainly it helps that all of the security functions are managed at the server level, so the possibility of accidentally accessing a malicious script that gains access to your local computer or file system, is reduced to near-zero if not zero. But it also limits the interoperability of your applications to Google's walled garden, so you can only play with the toys that Google gives you without accessing, say, the system clipboard or the contents of an open calculator app.

And from what we've seen, a "custom function" in Google's spreadsheet is limited by the same problem that afflicts VBA scripts in Excel: The formula language is, in many respects, more powerful than the scripting language. The one nugget of functionality that a scripting language could really add to an app is the procedural ability to perform a series of functions on set conditions, maybe even at discrete times; but by separating spreadsheet functions from procedural functions, you can't use the procedure to influence the calculation to any appreciable degree, at least not without hacking the contents of the sheet itself and recalculating -- which is painful in practice, and sends you right back to 1986 with regard to the programming model.

So Google's typical pitch to consumers, which boils down to, "Here it is, now do whatever you want with it," may be incompatible to some degree with the simultaneous pitch which says, "Please pay for it." It's fine for a free product to be unbounded and indeterminate in its use, that's what experimentation is all about. But if Microsoft has had a hard time pitching VBA to customers who have already purchased Office, imagine how difficult it will be for Google to sell Apps Scripting to folks who haven't yet shelled out their fifty bucks.