Publish globally, script locally

My InfoWorld article on Groove Web Services[1] was entitled “Script Locally, Publish Globally.” This week, John Burkhardt — one of the lead developers of GWS — made an announcement[2] on his Weblog that prompted me to invert that title for this column. John writes:

“Between the beta and v1 we were able to move closer toward the feature that Jon Udell mentioned[3] … Basically all we did was to move the user information out of the service URL and into a header. … This enables [users] to share URLs obtained from GWS with other users. As long as the other user has authority to access the same resource in Groove they will be able to resolve the URL.”

Excellent! To see why this matters, let’s switch contexts and talk for a moment about another application that, like GWS, relies on a local Web server: Radio UserLand, the software that powers my Weblog. There are two obvious benefits to this approach. First, the HTML/JavaScript user interface taps into a broad base of developer skills, so it’s easy to develop and extend. Second, it’s remotable. I can drive the software directly from the Windows box in my office, remotely from a Wi-Fi-connected Mac TiBook in the living room, or even more remotely from any browser on the Internet.

There’s also a subtler benefit that falls into the realm of unintended consequences. Software behavior that would otherwise have to be described in words and pictures can be shared directly among users, by exchanging URLs. For example, here are the conventional instructions that explain how to edit the Radio template:

1. Choose Prefs from the Radio menu at the top of any page on the desktop Web site.

2. Click on “Home page template” in the Templates section.

3. Make the change. (It’s HTML.)

4. Click on Submit.

In software documentation, we often abbreviate these instructions like so:

Prefs -> Home page template

That looks like a pathname or a URL, right? It is one, and because the engine is a local Web server, you can alternatively write:

https://localhost:5335/system/pages/prefs?page=3.2

Within a community of uses who are all running Radio on localhost at port 5335, this URL has an interesting property. It can be published globally — on a Web site or a discussion forum — but it scripts local behavior.

Radio’s user interface is not all that complex, so let’s take another example: Outlook. Many of its useful features are effectively inaccessible, because they’re so deeply buried. Quick! Where’s the feature that moves Replies to the folder of origin? When I first found it, I not only wanted to use it, I wanted to share it with friends and colleagues. But just now, in order to be able to show it to you, I have had to once again wade into the Sargasso Sea of menus and dialog boxes in order to fish out the formula:

Tools -> Options -> Preferences -> Email options -> Advanced email options -> In folders other than the Inbox, save replies with original message

Because this path mixes menus and dialog boxes, and because buttons on dialog boxes can be notoriously hard to find, these formulas are often documented using a mixture of text and screenshots. For Microsoft products alone, a Hiawatha National Forest’s worth of pulp trees has been felled in order to churn out 600-page tomes full of this stuff.

A picture can be worth a thousand words. But a URL can be worth half a dozen pictures. When application behavior is expressed that way, you empower your community of users to share it directly. And Google, which can zero in on URLs and URL fragments in Web pages posted by those users, becomes your tireless and efficient helpdesk assistant.

Software as a service? A powerful idea, I’m all for it. The service doesn’t always have to live in the cloud, though. When it’s local you get different, and also powerful, effects.

1. /articles/op/xml/02/12/06/021206opwebserv.xml

2. https://radio.weblogs.com/0107057/2003/01/18.html

3. https://www.oreillynet.com/pub/a/webservices/2002/12/09/udell.html