[AoyW] Pocket Wikis in Sync

The wiki is the app at the heart of the Always-On-You Web. Personal and shared webs obviously have to allow edit-in-place; what's the point of publishing read-only content to yourself? :-)

But the wiki as represented by Wikipedia isn't nearly flexible enough for the always-on-you web. For one, it shouldn't limit the content to rich text plus bitmaps (i.e. HTML). And it cannot corral the content in a single wiki instance. Always-on-you wikis that run directly from a flash drive, or live on your laptop, (see TiddlyWiki & PmWiki) won't be directly accessible to your collaborators; they need their own copy of the data in their own instance of the wiki. And that calls for a synchronization mechanism. A wiki-sync.

There are two ubiquitous sync systems, which everyone uses constantly... and I bet you can't name them. They are email and instant messaging. Huh? Yes, the number one way that documents are sync'ed by co-authors is via email attachments. This method imparts no implicit context for the object in question; discerning its meaning is left to the humans. But it works well enough, apparently. IM is simpler still, relaying a text block to some number of online participants, in near-real-time.

These simple, common mechanisms are the right stuff for sync'ing shared, locally-sited wikis. When a change recipient is online, they get the update instantly; otherwise the change is stored and forwarded when they're next online. The only thing to add is a tag that uniquely identifies the object that changed, so incoming updates can be processed behind the scenes.

My firm is designing an open sync service that will allow members to keep multiple instances of a data object in sync across the net. It's not just for wikis, any app could use it; it's not just for portable apps, hosted apps could use it. We'd love to get feedback from wiki warlocks and mashup masters about it, so drop me a line or leave a comment if interested.

AoyW Joins the BlogBurst Network

I'm blushing while blowing my own horn, but this blog has been accepted into the BlogBurst network, a wire service which promotes choice blog content to major publishers. (Bloggers in the mainstream media bed? horrors! :)

Well, it figures. The always-on-you web is subtly emerging, and today we're the only blog on the beat. I'll enjoy it while it lasts.

[AoyW] Privacy Promotes Productivity

Why is it that the web wave has left the desktop dry? Technical factors have been a barrier, but they're a berm made of sand; they dissolve in time. Social factors are more subtle, and a lot sturdier. The common architecture of web software raises some real social concerns, which have hardly been examined, let alone remedied.

The founder of an enterprise IM startup recounted this anecdote: "While deploying our IM software at a hedge fund, I noticed the admins using AIM, and suggested to an admin that the new intra-office IM system for the traders would be helpful to the admins as well." Her response: "Will my boss be able to see what I've written?"

The answer was yes, of course. The firm bought the app to improve knowledge retention, among other reasons. The lesson here is that employees are averse to the vision of a manager peering over their shoulder when they're alone at the keyboard. If they know that it's merely possible, they will curtail their efforts, per the philosophy The Less Said the Better.

The PC, for all its deserved reputation as unmanageable, is a personal sandbox in which an employee doesn't feel constrained and watched. She is free to play with ideas and drafts, and chooses what to circulate to colleagues. That freedom is a boon to productivity.

That freedom doesn't exist in contemporary web software. Today, web applications are based on servers, so everything done with them is knowable by operators and managers. This has caused many web workgroup installations to meet resistance and even fail; employees are used to the virtual vanity erected by their PCs, and they prefer it to the open stage of a centralized environment.

Drawing the benefits of the web—easy navigation via hyperlinks, and a metaphor reminicent of the spiral-bound notebook with section tabs on the edge—out of the internet cloud requires a different architecture. Something more akin to the independent-peers arrangement realized by PCs and email.

That's the architecture of the Always-On-You Web: lightweight, personal web servers which run from mobile devices, and are accessed on any local screen device via a browser. Mobile web servers are peers, sync'ing any content designated as shared, and keeping private all else. The Always-On-You Web has no centralized servers.

---
PS: in an effort to energize the bland blogspot layout, I've added an evocative banner image. It's a little artsy and a little risque. I'd love to hear reader reactions...

[AoyW] Introducing 'indi', a Web 2.0 Site in Your Pocket

Last week at the ETech conference, the indi "personal web site" from InfoEther made a tentative debut for the digerati. Judging by the blog coverage it didn't receive, they didn't grok it. Maybe the only concepts the ETech audience can wrap their cortical folds around these days are those bits of fluff about to be sucked off the floor by Google or Yahoo. ;-)

The indi is a web application platform that runs directly from a flash drive on any PC. The application environment is written in a mix of Ruby and the Flash ActionScript language, with the UI rendered by the Flash player in the PC's browser. For perspective, the bandwidth of a USB 2.0 drive is comparable to a hard drive. Broadband, schmoadband. This environment isn't going to feel like any web site known to man. If the PC of the moment happens to be online, indi apps can hit the net to pick up mail or updates to a team calendar, or do multi-player gaming, or anything. If you can't get online, you've still got everything you need: data & apps, ready to rock.

The indi is a statement that personal web services like Writely and GMail don't have to run in the cloud. Rather, the data and apps of such services ought to live in your pocket, where they belong to you (not a third party) and are always immediately accessible.

Now, I know something about this space, since my company is working on an app with a similar architecture for a completely different market. You should consider me both biased, and well-informed.

The indi's designers chose Flash for the front end. In a word, "aghh". About the only compelling Flash app I've ever encountered is the Orbitz Pool Table game. And that crashes IE with disappointing frequency. When I first got Firefox, which doesn't bundle Flash, I was delighted by the Flash-free web experience. It's now my standard mode. Flash is to the web what game shows are to television.

Flash is a closed client and a proprietary protocol. It can't legitimately claim to be a presentation format, like SVG or PDF. (If it could, it would have euthanized PDF a decade ago, as Acrobat is one of those sad pieces of code that begs for a coup de grace, despite the worthy design goals that spawned it.) Thankfully, use of Flash seems to be declining steadily with the rise of the AJAX model.

However, if you plan to build a for-play web site, Flash is the only game in town. And games seem to be a key target for the indi. Bang...Aghh!

In applying the Ruby language for the data management side (which runs outside the browser), the indi gets full marks for geek chic. It also provides a variant of the OpenStep UI framework (originally developed for the NeXT) for ActionScript. This puts the UI logic inside the Flash player, instead of streaming to the browser, the way our SVG Terminal does. The indi approach is analogous to an AJAX UI framework running in a browser, talking to business logic on a server; except that the range of Flash is far greater than that of DHTML/CSS. From the perspective of most developers, this is a rather tall stack of unfamiliar, though critically-acclaimed, technology. Where's the Java or Javascript? Eschewing Java may be a business decision; licensing the JRE for mass-market/consumer distribution may not make sense in this case. And they've opted for an open UI library, rather than Macromedia's offerings.

Naturally, the indi isn't shipping at this point. A private beta is in progress, and in email, I've been told the debut date is July 4 of this year; how clever, since the indi is named for "digital independence". (Amusingly, the beta user guide is in PDF—come on, guys, eat your own dog food!) In good blogger form, I've had no contact yet with InfoEther. I've requested a beta invitation... if they oblige I'll be writing more.

The indi is a different take on how you can use the web... it's the Web 2.5 take, and it has a lot more to do with the future of the web than all of the ASP 1.1 outfits combined—Writely, 37Signals, et al. Not that we don't need decent online apps, it's that the useful scenarios for them pile up to a much smaller heap than those for the indi and its ilk.

[AoyW] A Killer App for the UMPC/Origami

The Origami tablet design from Microsoft seems to have been universally panned. Unlike most of the critics, I actually use an ultralight slate tablet constantly, the NEC LitePad. I'm composing this post with it. (Though I never use handwriting; I write with a shorthand method of my own design.)

Here's a radical idea for the UMPC: think of it not as a PC, but as a server. A device that could fire app UIs at any/many available screens, via wi-fi. Now you're not constrained by the tiny screen and pen input, but you fall back on them when no other PC is handy.

A scenario: You walk into the conference room with your UMPC, and all participating screens light up with your slides, plus UI to let your colleagues annotate them. The UMPC screen shows your slide notes. Later, your head back to your office, and your desktop screens and small office projector light up with whatever they showed before you left to give the presentation.

Windows doesn't offer much infrastructure to accomplish this example, but the web does, especially AJAX & SVG. Re-defining the UMPC as an always-on-you web 2.0 server unlocks a world of killer apps for it—apps which are better served from your pocket than the internet.

[AoyW] GDrive? GWrite? Gee Whiz (not).

ASP 1.1, here we come! Google seems ready to roll out the GOffice, with calendaring imminent, file service in the works, and ink drying on the Writely acquisition. Is Microsoft worried? I doubt it.

Google has it exactly backwards, especially regarding online storage. Rather than an online repository and desktop cache, what users need is a mobile repository (e.g. 32G flash drive with UWB wireless) for always-on-you apps & data, with an online subset of data for (semi-)public viewing and mash-ups.

Wireless flash drives are inherently bigger, faster, and more reliable than any WAN-based service. The net should be used to sync shared content on your drive with others, not deliver it just-in-time.

32G not enough? Take 2, take 5... they're cheap and small. Flash doesn't have this density today, but at the curerent rate of improvement, it will within three years. Got to have it now? Carry a pocket USB hard drive.

Heavy storage consumers will also need auto-archiving of older content; user-encrypted and housed at more than one service provider (who has no visibility into the data due to encryption). Google won't be among those providers, because it has to see your data to figure out what ads to show you.

The sad thing about this waste of Google's effort and brand is that it's been tried before. Theirs was the vision of Intranets.com, and numerous other players, who blew a ton of venture cap during the dot-com era. Intranets.com was the most successful of the lot, they sold to WebEx last year for $45M. Mind you, they raised $40M and spent six years to get there.

Was the lack of Ajax the reason for all those failures? Or was it user reluctance to hand over their data to a posse of three middlemen (net, ASP, billing) and rent it back from them? Google is going to find out.

[AoyW] The SVG Terminal for Firefox Gets Better

Ok, it's just a little bit better, but the new release of our SVG Terminal does text highlighting when you drag your mouse on a text field. And we've given the demo app that comes with it a shape palette, mimicking the UI of a drawing app.

To recap, the SVG Terminal is a module for Firefox 1.5, and a simple protocol, that enables apps to deliver evolving vector graphics views on network screens and fine-grained interactivity with users. It directs all user input from the browser to the app/service, which sends updates as SVG fragments to the browser. (You could think of it as X Windows for XML.)

It's designed for apps running on a mobile device which need to present a sophisticated UI on nearby screens via wi-fi, and apps which need to drive multiple network screens with graphical scenes in near-real-time.

And hey, if you like what we're doing, please blog us!