Dabble DB

The Dabble Blog

Archives: April 2005

« March 2005 · May 2005 »

You Can’t Import Usability

In a great comment on Andrew’s last post, Patrick Logan writes:

There is a spectrum of choices between a traditional spreadsheet and a traditional database. Perhaps a more usable system in this space would allow someone to begin working more like a spreadsheet and allow shapes to emerge and be supported more like a database, but not expose that support in traditional database terms.

One crude way in which this happens already is for database systems to support spreadsheet imports, creating and populating a database table based on the structure and data of an Excel file. The idea here is that you can get started on your application in the familiar, free-form environment of a spreadsheet, where it’s easy to add new columns and enter data. Then, when you’re ready to “move up” to a database, just do a simple import and away you go.

Clearly, this is a useful and essential feature for legacy data stored in old spreadsheets: any database product that didn’t provide some way to bring in that information would be sunk. What’s deceptively appealing, however, is the idea that this is also a good way to build new applications. QuickBase, for example, recently added a feature called Spreadsheet-Style Create. It’s a good start, but the focus on creation bothers me. If everyone knew from the start exactly what their app would look like, then this would work great, but real life doesn’t work that way: there are always going to be fields to add, remove, split, merge, and migrate; new batches of data to enter; new relationships to other pieces of data that you never knew you cared about. The problem with imports and special create modes is that they’re a one-time offer: once you take it, you’ve shut the door on the spreadsheet’s ease of use, and are stuck with the database’s standard modelling tools. Almost by definition, they will be harder to use than the spreadsheet was - or what would have been the point of starting things that way in the first place?

Personally, I would rather that the database system made it easy enough to build my application from scratch that I didn’t feel a need to use the spreadsheet as a crutch. That’s the only way I’ll know that if I need to make significant changes later, they will be just as easy as the initial setup was. Maybe that means taking a cue from QuickBase, and providing two kinds of tool: one aimed at rough field creation and bulk data entry, and another aimed at smaller, more detailed refinements. But make both sets of tools available at all times, operating on the same data model, rather than locking one of them to the beginning of the application’s lifecycle.

Incrementality and Barriers To Entry: 100 Million Spreadsheet Users Can’t Be Wrong

In Avi’s previous post, he asked the question, “if not spreadsheets, then what?”. The conventional wisdom on this (being suggested to users but largely ignored) is that, if things get too complicated in terms of number of users or in terms of the data itself, it’s time to move to a “database”. Now, there are a wide variety of database offerings out there, and we’ll likely take some time exploring a few of them in future posts, but the general arguments for databases are pretty compelling: Typically, they offer a central repository, avoiding the usual collaboration problems associated with emailing spreadsheets back and forth. As well, they are often designed to handle more complex data models, another frequent complaint of spreadsheets not scaling up. Sure, it takes a little more thought to set up a database and come up with a reasonable data model, but the benefits are hard to deny.

So, why aren’t databases used more frequently in the small application space? One answer would be to blame the users: they’re just being short-sighted or lazy. Why can’t people just plan better? Similarly, one might look to the environments in which the users are making their decisions, with pressure from managers, bosses, and customers to satisfy short-term needs first and foremost. Why can’t organizations just do the right thing up front? There may be a small amount of truth to these answers–both people and organizations have been known to make mistakes, but I really don’t buy that this is the whole story. In recent years, some in the software development community have questioned the assumption that up-front planning is an efficient or reliable way to build complex systems. Might it not be that the users are right not to want to plan better, because they don’t yet know what they’re planning for? Instead, they simply use the tool that lets them capture the information they need now, without forcing them to think about what they might need later - and, invariably, to be wrong about that. Sometimes, worse is better. In this case (at the very least), I suspect that users understand their requirements better than the other kind of experts.

If you’re willing to grant that users may be right to choose spreadsheets from their currently available options, it becomes very important to understand why; to understand what is right about spreadsheets. Sean’s recent comment points to the answer: absolutely zero barrier to entry. Excel or some equivalent is sitting on most every computer. If I want a structured presentation of some data in front of me, I can open it up and enter my data the way I’d like to see it. At this point, I’ve put in very little effort and have probably built what I want. If I want to share this information with a colleague, great: no barrier to sending an email with an attachment. Of course, as more and more people use the spreadsheet and new requirements for the data come up, things start to break down: errors, duplications and inconsistencies appear. It’s not that this is a surprise, that they don’t know it’s coming–rather it’s that the barriers to using other tools are simply more important to users than avoiding these problems. By and large, users simply stop at the first barrier they encounter.

What this tells me is that, if we want spreadsheet users to enjoy the benefits of collaboration and integration, we need to drastically change our idea of what acceptable barriers to entry are. We can’t start by taking away what’s good about spreadsheets–instead, we need to expand upon it: low barrier to entry, repeated, otherwise known as incrementality.

Incrementality is something we’re very interested in: we are convinced you can get very far one small thought at a time.

« March 2005 · May 2005 »