March 31, 2006, 2:29 PM — Close your eyes and picture a standard set of Office productivity applications for PCs that have turned into Web applications.
Word processors turn naturally into Web-based word processors in which the browser can edit words as well as display them. Fine.
Presentation packages turn naturally into Web-based presentation packages in which web pages become slides. Fine.
Databases turn naturally into Web-based CRUD[1] applications in which Web-based forms are used to create/update data and web pages are used for reports and database browsing. Fine.
Spreadsheets turn into...what? The obvious thing to do would be to take a spreadsheet from an office suite and transplant its functionality into a browser. This can certainly work and various initiatives are under way doing exactly this. However, I cannot help feeling that there might be an opportunity to do something a little more interesting than just "functionality transplantation" in this case.
What is a spreadsheet really? At heart it is a collection of cells of information. Some of these cells are static, containing words, numbers, pictures and so on. Some of these cells are dynamic containing calculations. The calculations use information from other cells to compute interesting things. The cells that calculations use can themselves be calculations...and there you have it. Everything else about a spreadsheet is secondary.
Cells in a spreadsheet are not like paragraphs in a word-processor or slides in a presentation in one very critical aspect. Cells have addresses. Cells can be uniquely referenced by means of their row and column numbers. Cells can also be referenced by friendly names allocated to cells such as "gross profit" or "unit cost" and so on.
In a classical PC-based spreadsheet, all the cells referenced in a spreadsheet are local - mostly all contained within the same spreadsheet. Once Web-enabled, the "reach" of the spreadsheet in terms of the cells it could reference in calculations, explodes.
Time to close your eyes again. Picture a web-enabled spreadsheet in which cells can be referenced as URLs. Something like http://www.example.com/sheets/costings?R10C12
This says (roughly) "give me the cell at row 10, column 12 of the costings spreadsheet on example.com".
What does this look like underneath? It looks like an HTTP GET - the quark of the Web universe. Trivially implemented both by producer and consumer.
What would this mean if the world worked this way? Well, take the classic example of a simple Web Service: a service to retrieve stock quotes. What do the majority of non-geek users want to do with a stock quote? They want to plug it straight into their spreadsheet. They do not know or care about Web Services. Why not shield the end-user from the Web Services stuff and allow them to drag-and-drop spreadsheet cells from anywhere on the Web?
Of course, you could do this much with a standard PC-based spreadsheet as long as some standard mechanism for representing cells of spreadsheets on the Web exists. To my knowledge, this does not exist yet.
Now close your eyes again and pretend that this much has happened. We now have a worldwide standardized way of publishing spreadsheet cells on the web. Let us give it a name: Web Cell Markup Language (WCML). The world is now swimming with web sites publishing not just web pages but also cells and cell ranges using WCML.
What happens if we take the next step and put our spreadsheets on the Web rather than keeping them local? Now our spreadsheets can be both a consumer of cells and a publisher of cells. Now we have created the necessary environment for network effects[2] to kick in. We consume cells in a way that also publishes new cells which are themselves consumed leading to more published cells in a virtuous cycle.
Perhaps the future of web services for consumers lies in being a bit innovative in how we put spreadsheets online? Come to think of it, perhaps spreadsheets will be the vehicle that makes structured data on the Web really take off?
Could it really be that simple? For a large class of interesting applications, I do not see why not.
[1] http://en.wikipedia.org/wiki/CRUD_%28acronym%29
[2] http://en.wikipedia.org/wiki/Network_effect
