Bricklin's WikiCalc: Much much more than just a mashup of wikis and spreadsheets

Drawing from one of the names -- VisiCalc -- that gave birth to the PC industry, electronic spreadsheet co-inventor Dan Bricklin has gone public with an alpha version and his plans to release WikiCalc -- an open source browser-based solution that takes some of the most powerful features of spreadsheets (eg: the ability to format anything including text and calculated data into a tabular layout), some of the most endearing features of Wikis (ie: their simple markup language and instant ability to collaborate on Web-based documents), and marries them not only to each other, but also in very behind-the-scenes-fashion to advanced Web page formatting techniques that involve tables, HTML templates, and cascading style sheets.  You can visit the aforelinked Web site to download a copy and try it for yourself.

To the extent that Wikis make collaboration on Web-based documents simple but are sorely lacking in their ability to easily control the overall presentation and format of those documents (colors, fonts, and positioning of text or tabular data that may or may not require tabulation), the alpha 0.1 version of WikiCalc is not just the marriage of Wikis to spreadsheets, but also lays the foundation for a very simple yet powerful browser-based Web page publishing tool the likes of which we haven't seen yet. 

Many people, for example, use spreadsheet software for nothing more than their ability to easily layout and print their documents in what-you-see-(on the screen)-is-what-you-get (WYSIWYG, pronounced "wizzie-wig") fashion.  Instead of sending WYSIWYG output to a printer, WikiCalc publishes WYSIWYG output to a Web page.  But, whereas you can do rougly the same thing in Excel using that spreadsheet's "Save as HTML" command, WikiCalc is like many Web authoring tools in that it can publish the page directly to any Web site that you have the authority to publish Web pages to.  For example, I used it to publish a simple test Web page that includes both calculated and tabularly organized text (a delivery schedule) directly to my personal Web space on Comcast's service (Comcast is my ISP). 

As a solution that's not even in beta yet, the alpha version of WikiCalc does more to lay a foundation than it does to serve as a completed solution.  So, it's quite rough on the edges as alpha-level software often is. For example, an open source developer that's really comfortable with Javascript-based programming techniques such as AJAX could probably make some serious improvements to the user interface -- introducing GMail-like features such as auto-save or maybe finding innovative ways to emulate the sort of cursor control that's key to cell navigation in spreadsheets but that the Web lacks (you can't use left, right, down, or up arrow to move from one cell to another like you can in spreadsheets). Compared to spreadsheets, WikiCalc alpha can only handle very simple formulas and has two functions.  One of those is the commonly used (in spreadsheets) SUM function and the implication of such a function is that ranges can be defined and used to specify the scope of a WikiCalc operation (and they can).  But Bricklin's goal for this alpha version wasn't to deliver something that was spreadsheet-feature complete.  It was to get the basic wiring and architecture in place, paving the way for the grunt work of code that must follow to really demonstrate the power of what he has built.

To the extent that WikiCalc automatically creates HTML tables to achieve the WYSIWYG effect (you can easily use your browser's "view source" command to view the source HTML of my test page to see what I'm talking about), Web authoring tools like FrontPage can do the same thing under the hood when it comes WYSIWYG publishing.  But once you take into account that (1) others can, in Wiki-like fashion, collaborate on WikiCalc-based documents (it lets you know if someone else has the document checked out for editing), (2) it uses a simple Wiki-like markup language for doing things like boldfacing and hyperlinking of text, (3) the tabular data can, in spreadsheet fashion, include calculations, and (4) the editing tool is 100 percent browser-based, WikiCalc is not just special in its own right, but, going back to the architecture I mentioned above, could very well represent a new breed of software-as-a-service (SaaS)-delivered solutions that drive the acceptance of thin client computing while also overcoming one of its most serious weaknesses (one that I wrote about yesterday): being able to work off-line.

When I wrote yesterday that:

While coverage is improving (geographically expanding while also getting more reliable), that's simply not good enough for those of us who, when we're not connected, we're not working.  This problem will be solved. 

...I said so knowing the underlying fundamentals to WikiCalc's three-tier architecture that's designed to accommodate either thin or thick client computing.   The first tier -- the one that the end user touches -- is the browser-based authoring and publishing tool. The second tier is the Web site that drives the tool.  Much the same way that Userland founder Dave Winer designed the authoring component of Userland's personal blogging solution (Radio) to be browser-based and driven by a Web server that runs locally on the PC, WikiCalc does exactly the same thing. Then, both do the same thing with the content that they can respectively author -- they store the native files in local storage (for example, on the hard drive) and then they publish the resulting Web pages to the third tier, which could be a Web server on the Internet (like I did with my Comcast-based Web space) or to one on a corporate Intranet.  Like other Web authoring tools that publish directly to Web servers, WikiCalc needs to be configured (once) with the appropriate FTP login information to transfer any newly authored or edited Web pages to the target Web server.

So, much the same way Radio has a browser-based authoring tool but is really a thick-client solution because of the way the browser-based authoring tools are driven by a local Web server that requires local processing power and storage, WikiCalc in its default configuration is the same thing.  But that architecture -- with its usage of local resources --  is also what facilitates working offline with your documents or content when you're not connected to the Internet (a key advantage of thick client computing).  But what makes WikiCalc unique is that Bricklin developed the entire second tier -- the local Web server the drives the browser-based authoring environment -- in Perl.  In his alpha release, Bricklin relies on ActiveState's Windows-based Perl runtime for interpretation of his source code.  But, because his source is based on the Perl standard and because such runtimes exist for just about every operating system imaginable, the WikiCalc source code is 100 percent portable to other operating systems. 

So, right now, a lot of people are saying "Boo-hoo.  So what? It's portable.  A lot of things are."  Indeed, there's plenty of Perl, Python, PHP, and Java-based software that's portable between many platforms. But by choosing a portable language like Perl for developing his second tier, the second tier -- the one that drives the browser-based authoring tool -- doesn't have to be local.  In other words, it can also run on a Web server (using Linux, Unix, Windows or any other OS for which a Perl runtime exists) on the Internet or local Intranet.  The second tier can live next to the third (the target Web server to which the Web pages are published) on the same physical server, or theoretically, a WikiCalc service provider might just want to run a multi-tenant version of the second tier and leave the target Web server completely up to the end-user.  Comcast, for example, could make the tool available in a way that defaults to a subscriber's Comcast-based Web space (like the one I used in my test case), but that also gives the end user the option of publishing to some other Web server that he or she has FTP access to.

By moving the second tier from the client to a server, all the end user needs to author Web pages with  WikiCalc is a browser (ergo, a thin client).  So, WikiCalc's architecture is very Dr. Jekyll and Mr. Hyde-esque in that it can be either a thick- or thin-client solution.  It just depends on where the middle tier is located.  This is also what I meant yesterday when, in reference to the shortcomings of thin-client computing,  I said that "We're closer than you think to a world where a lot of this gets worked out." 

In WikiCalc, Bricklin has developed something that is much more than the marriage of the wiki to the spreadsheet.   In WikiCalc, Bricklin has employed an architecture that demonstrably narrows the gap between the the thick and thin world's in a way that only a few more breakthroughs are required to close it altogether. There's no reason that developers of other applications can't do the same.  In terms of breakthroughs, again, referring to what I said yesterday, imagine if there was a standard for attaching USB-accessible storage to thin-clients and that standard was widely adopted.  All that's needed then is some clever FTP-based replication code to make sure that no matter what environment you're in (thick or thin) -- you can save or retrieve your documents to or from that key.  At that point, it shouldn't matter what device you use to author or collaborate on documents.  All you need is your key. 

Finally, much like Userland's Radio, the final products of the three-tiered WikiCalc are Web-pages.  While the Web pages produced by each are for very different purposes, both products share two other common attributes. First, they take an enormous amount of pain out of purpose-specific Web page publishing -- one is highly suited to blog oriented pages, the other for pages to which tabular layouts and calculated data are well suited.  The other common attribute is that the raw material that each eventually converts to a Web page is stored in a non-standard format, using application-specific markup.  Radio's is more HTML-esque than not and if you use Windows Notepad to open a native WikiCalc file, you can see by its references to spreadsheet cells how heavily WikiCalc is orchestrated around a spreadsheet framework.  What that means -- and what Bricklin has confirmed -- is that there's no reason that the OpenDocument Format (a format that includes spreadsheets) can't also be a native format that WikiCalc can work with.  Bricklin says he's just waiting for the same thing that a lot of other developers of potentially OpenDocument-compliant applications are waiting for: a  library of development tools that does the heavy lifting that must be done in order to add such compliance to an application. 

Why is this important? By making WikiCalc compliant with a standard document format -- be it OpenDocument, Microsoft's Office XML Reference Schema (should Microsoft choose to open it up to the point that it's really open), or some other document storage standard -- that too would also help bridge the thin and thick worlds because developers of software that runs in either (or both as WikiCalc does) can develop other products and suites that are capable of opening, closing, saving, publishing, and sharing the same documents that WikiCalc opens, closes, saves, publishes, and shares.  That way, if you'd rather work with spreadsheet software like Corel's Quattro, Lotus 1-2-3, whatever gOffice is coming up with, or even Microsoft's Excel when you or the people would prefer to work, you or they can.  That's what standards are for.