Shouldn’t be spreadsheets, redux
A lot of people have been asking us (both privately and publicly) about Google’s new spreadsheet and how it compares to Dabble. Given that we’ve been saying from day one that we’re trying to help users move beyond spreadsheets for the (many) tasks where they’re inappropriate, this is a little bit amusing - but it’s also a good opportunity to spell out some differences.
Here’s the key point: when it comes to managing data, Google Spreadsheet (like other web-based spreadsheets) is only solving half of the collaboration problem. Yes, it lets everybody access and edit the same data over the web, and that’s an important improvement over the email-the-Excel-file-around strategy many groups are stuck with. But it also forces everybody to look at that data in exactly the same way. That’s fine when everyone who’s working with the data has substantially the same interests and roles - like letting the board members of a company or non-profit all take a poke at its budget - but not for more diverse collaborations between team members who are each coming at the data from a different angle. This is how the most painful spreadsheet-emailing processes come about, and it’s where something like Dabble gives you the biggest benefit: getting many different views, and performing many different tasks, using the same data.
It helps to have an example. I’ve spent a lot of time working with people who help to run arts festivals - dance, music, film, and theatre. One core kind of data that everyone there needs to access and contribute to is the list of shows happening at the festival. There’s a lot of information associated with each show, and it’s typically collected by different people: the programming director might put together a simple schedule for each venue, the technical director will assemble a list of technical requirements for each show, the box office manager will keep tabs on the prices and numbers of each ticket that’s been sold. It would be absurd to prepare one monster spreadsheet with all of this information: the box office manager really doesn’t want to know how many microphones a given act needs, any more than the technical director cares how many tickets it sold. But it’s also painful to keep them separate: if the programming director moves a show from one venue to another, that change needs to ripple out to everyone. And synthesizing the data is important too: the house manager for a given venue might well want to know both what gear is needed for each show and how many tickets were sold for it - but only for shows running at his or her venue.
If you’re managing all of this with spreadsheets, whether web-based or not, it’s easy for someone to end up with a full time job of updating, combining, and extracting data from these various lists, and getting new synthesized and filtered versions out to everyone that needs them. That’s not a good use of the limited resources of a small team.
It would be fair to say that most of Dabble’s features are really in service of this one goal: putting the core data in once and only once (the shows and venues), while letting related data be both separate (looking at box office receipts is a totally different task from looking at technical requirements), and combinable (see all the data for a venue…) as well as filterable (…but only that venue). Not to mention viewing that data as, say, a calendar or an RSS feed rather than just a table. If (and only if) you genuinely don’t need any of that, a web-based spreadsheet is probably just fine.
It’s worth remembering, however, that different roles and contexts don’t always have to come from different people. They can, and often do, come from the same person at different times. The next time you find yourself with a 3-year old spreadsheet spiralling out of control as you try to adapt it to one more use, you might consider importing your data into a tool that was built with evolution in mind.