Little known fact: over on the baseball blog that you people forced me to create, I do a bit of math. Where a bit can be read as more than I did my senior year of high school and in four years of college combined. True, it’s simple stuff. Addition, subtraction, multiplication and division to go along with the occasional formulaic calculation – the complex derivatives work has already been done for me, in most cases – but I’m doing a fair amount of work with numbers.
Presenting those to the my massive tiny audience has always been a bit of a pain in the ass. Some of you may recall that I do all of my markup by hand in emacs (yes, still); every bold, italics, hyperlink and so on that you see has been added by me. By hand. In those cases, however, I’ve managed to convince myself that I’m faster manually inserting them then I would be with a GUI, as I can generally type much faster than I can move a mouse around and click buttons. Not so with tables, however. They’re perhaps the most straightforward of HTML constructs, as well as the most tedious. Thus, when I’m doing entries that are heavy on tabular data – say, like my ALDS preview – I’m generally not a happy camper.
Recently, however, I’ve taken the lazy man’s approach and begun simply embedding spreadsheets (thanks to Joe for the tip); see the entries here and here for examples.
Or, for the link averse, here’s one quick embed for you:
I’m using Google Docs over on wicked clevah, but Zoho (as pictured) will do the same thing, and their user interface for the process is superior, as are their human friendly permalinks (compare this to this). Note that neither Google nor Zoho makes it easy for me to go to the third decimal place I need for baseball work.
Anyway, the embeddable spreadsheet concept is appealing for obvious reasons: I’m not hand coding the damned tables for data I already have online. But it’s also true the spreadsheets are more visually appealing than the basic tables I reluctantly crafted.
So it’s a win on multiple fronts. But beggars apparently can be choosers, because I have some complaints.
- iframes: Both Google and Zoho deliver their embedded assets via an iframe; likely because that’s the only practical solution. Which I have no real issue with, except for the fact that iframes can’t make the transition to feeds. Thus any of the folks picking up wicked clevah via their aggregators will be missing part of the content. Hell, if you’re reading this very entry via a feed, you missed the object embedded above. While this isn’t an issue, typically, when we’re talking about content like video, it’s kind of a concern for me. Seeing as the arguments I’m making often depend on the spreadsheets, after all.
- No Updating: As nearly as I can determine, embedded spreadsheet content does not live update. Thus if I make changes to the source material – corrections, additions, whatever – it is not reflected in my original entry. Which may be a desired behavior in many use cases, as the data behind the argument should remain relatively static, but it’s not in mine.
- Reliability: Obviously when you’re outsourcing content to a third party, you have to expect that there will be times when it’s unavailable. Particularly for unpaid services like Google Docs or Zoho. But I have to say that I didn’t expect my embedded assets to be down within three days of it being published (see above). Just as with the content being unavailable within feeds, it’s a problem when the statistical basis of my assertions is down due to a “server error.”
The bigger issue, however, for me is that these mechanisms do little or nothing to encourage and foster collaboration. Each of the mentioned services has the ability to host collaboratively worked on documents, of course, as do others such as IBM’s Bluehouse.
It’s probably too much to ask that visitors would be able to work on the content in place on the blog; we’re still struggling to understand what a document is in an age of web pages, remember. But it can’t be debated that the embedded mechanisms do little to link readers back to the source material for the purposes of further analysis and contributions. I’ve used the CHONE projections for 2009 performance in my post, for example: it would be wonderful if anyone so inclined could hit the source spreadsheet, easily get commit rights, and add, say, the Bill James or Marcel projections I was too lazy to include.
Extrapolating outward and assuming that that process worked effectively, we could see a central repository in which folks like Randy and his crew over at Over the Monster, Evan, Tim and the gang over at Fire Brand of the AL, myself and other interested parties could effectively work on – centrally – things that we probably all reinvent ourselves locally. And that’s just the Red Sox bloggers use case.
We’re not there yet, sadly. But I look forward to a day when I can do all of the above – not least because it’ll mean less work for me.
Until then, I’ll have to appreciate what the technology does well, while trying to mitigate its shortcomings. As usual in this business.
Disclosure: IBM is a RedMonk customer, while Google and Zoho are not.
