When I heard news that Google was to release a spreadsheet companion to their freshly bought Writely web-based word processing app, I got excited about all the things they could do to make it more than just a copy of Numsum. Let’s face it, Google’s the Gorilla in the room here and they’re gonna squash Numsum, but wouldn’t it be cool if…
Well, Dmitry Nekrasovski get’s credit for planting the notion of URL-addressable rows, columns, and cells in my mind with this commentary from months ago:
I just came across this ITWorld article that suggests a simple yet intriguing idea for making online spreadsheet applications like Numsum more than Excel wannabes: make cells and cell ranges addressable with URL’s, and use a standard XML variant to encode them. To the author’s credit, he does not use a buzzword for this idea, but, for ease of meme-peddling, I will refer to it as Spreadsheet 2.0. You heard it here first.
The implications of Spreadsheet 2.0 at the user experience level for a public site could be pretty neat: feeding into a live stream of, say, stock market data could be as easy as copying and pasting a spreadsheet cell. But it could be most valuable in an enterprise environment. Anyone who has worked in a large organization will testify to the pervasiveness of the “spreadsheet mentality” and the difficulty of managing and reusing data once it is buried in a spreadsheet. Could this be a legitimate way for Web 2.0 apps to find their way to large-scale enterprise deployment?
Now, go one step beyond read-only URL-addressability and think about writing to cells with an HTTP post URL. Imagine the way cool apps we could build based on that.
Thanks go to Jessamyn for inviting me.
7 Comments
You can already do this.
I have started working on an API for Google Spreadsheets. It has an EditCells(row, col, value) function that you can use to remotely modify a cell. You can see more on my blog at http://geekswithblogs.net/lance/archive/2006/06/08/GoogleSpreadsheetsAPI.aspx.
[tags]google, google spreadsheets, api[/tags]
Speaking strickly from an internal MIS organization perspective, addressable cells in an online spreadsheet would be significant opportunity for application development - a variation, if you will, on the wisdom of masses theme pervasive in Web 2.0. However, I would be concerned about the lack of a structured application development environment. Precision and accuracy are requirements in business processes. Efforts would have to be made to ensure that applications that are literally spread accross several websites were accurate, otherwise this would take the meaning of “spreadware” to a whole new level. Additionally, long term support of such an environment may be more expensive than the traditional. Presently, I am looking for ways in which my organiation could become less dependent on the isolated spreadsheet. Linking them together would not necessarily provide the kind of assurance for accuracy necessary for a sound data-driven decision making environment for which we strive. Those cautions aside, it would nonetheless be an interesting concept that should be explored and maybe even deployed, with some restraint.
[tags]addressable url, spreadware, spreadsheets, google, google spreadsheets[/tags]
EditGrid has an official API at http://labs.editgrid.com
It uses SOAP + WSDL, which should make writing clients easy in languages that support these technologies. (We may release a REST version if requested.)
Currently we have most simple features implemented, and you can get/set cell values, or even a range of cell values. Create new sheets/workbooks etc.
Try it out!
I’ve thought about this concept at some length. I think it could have some profound implications.
I envision a globally interconnected “number-web” of spreadsheets which are continually communicating with each other and updating their status.
In this world, every spreadsheet computation is based on the results of some other SS computation. So, if the profitability of my company is related to the inflation rate in China and the Euro-Dollar exchange rate, I’ll hook up my spreadsheet to a stream which provides those numbers. Those numbers in turn can be generated by other SpreadSheets employing the same principles. Furthermore, I’ll *publish* the data from my SpreadSheet to the world, and so my stockholders (for example) will also have continually updated data about their financial positions. In theory, this chain of publishing calculations based on other calculations could go on ad infinitum.
In practice, this could cause problems, as Ken pointed out. In particular, what happens if there are cyclical spreadsheet dependencies? It might make sense to try to prohibit this somehow. But situations like this exist in the real world - there’s no reason why Company A and Company B can’t both own shares of each other’s stock. So I think a more reasonable approach would be to allow cyclical dependencies. In this case there would need to be a delay mechanism. Eg, an SS does not automatically recalculate itself every time it gets a request, but rather only every hour or so.
Another issue is: what if there’s a bug? If some guy in the Czech republic makes a divide by zero error and publishes a profit (or loss) of $10 trillion, you wouldn’t want this error to disrupt calculations through the entire world.
Despite these issues I think it’s a powerful idea.
[tags] addressable url, google, google spreadsheets, spreadsheets, spreadware[/tags]
I think cells, rows, columns, and even sheets qualify as resources as defined by REST. Using the HTTP POST/GET/PUT/DELETE methods for CRUD operations makes the network exchanges simple enough to do with telnet. I’ve built a small app which implements this. This blog post demonstrates the input & output:
http://www.nearinfinity.com/blogs/page/seths?entry=rest_network_api_for_an1
I think &range=A1 will work for you….
Hello!
I think this try.
One Trackback/Pingback
[...] In response to Casey’s post regarding URL addressable cells in spreadsheets, I came across numbler today which appears to have a rest api (and xml) that supports PUT, Get and Delete for cells and ranges. Will be interesting to see what kind of things can be made with this. [...]
Post a Comment