Archive for January, 2012

Table Based Collaboration

Monday, January 23rd, 2012

I’ve been supporting our department wiki for many years now.  The most used feature is basic rich text, as you would expect, but the next most popular feature is tables.

Over time, I’ve identified a particular kind of collaborative function that people engage in when they are coordinating activities.  I don’t have a good name for activity, but I’ll call it “table based collaboration”.

In some corporate cultures this is till done by sending giant Excel spreadsheets around as email attachments.  This is the main option available when collab services (like wikis) are not available or practical for all the participants.  In this model, the owner of the process owns the spreadsheet makes the updates based on email received from the participants.

A more collaborative approach uses any form of wiki to create tables on wiki pages.  Depending on the data, it’s also possible to use a bulleted list format instead of a table, but the data itself and collaboration process is the same.  There’s a big jump in ease of use if the wiki supports rich text table editing.

I’ve tried about a half-dozen different wiki implementations of tables, and none of the rich text table editors are worth using in a produciton environment.  As soon as you do any kind of formatting, the entire table converts from wiki-syntax to raw html.  And after that point, the first formatting bug (that can’t be fixed by the rich text editor) becomes impossible to correct by direct-editing.

The lack of decent rich text table editing means that you need to stick with the wiki-syntax for tables, and edit them by hand.  This is workable, but forces the participants to have passable fluency in the wiki syntax and whatever foibles it has.

Another way of enacting table based collaboration is to use an actual database with a simple web interface.  We have several examples of this in my organization.  It’s generally implemented using an off-the-shelf database of some kind.  By definition, the table never needs to be joined with anything, and there’s only a single table.  If your “table based collaboration” sprouts any extra tables, then it turns into a “department web application” and it falls outside the realm of this discussion.

There are an endless supply of web application frameworks which have an simple process for creating a simple web app.  But the process of creating it still requires the owner of the process to learn the framework and generate the web app.  It also requires someone to set up and maintain the web application itself.  These solutions are not suitable for having a non-web-technical person set up a new table.

If you look at each of these mechanisms, each one has pros and cons.  Factors to look at are: 1) Does it require centralized infrastructure? 2) What are the platform/tool requirements placed on the participants?  The leader?

In the final analysis, I think something like a Google Docs spreadsheet provides a sweet spot of accessibility, formating and overhead.  Unfortunately, it’s not appropriate for a department-level solution.  Using Google Apps for proprietary company data needs to be approved as a company-wide policy, you can’t just download it and start using it.  Approving it for use for company business is appropriate for some companies, and not for others.

What I’ve been looking for is a web-application that allows end users to define a set of columns using basic types (string, date, enumeration, etc) and provides a simple spreadsheet-like interface for adding/removing/modifying data.

I’ve been so frustrated recently that I’ve been thinking about recommending that people go back to mailing around OpenOffice spreadsheets.  Some general purpose wikis get by with less-than-ideal behavior when two people make updates at the same time. So, in some cases the collaborative aspect of the solution (like wiki tables) costs more in synchronization headaches than what it would cost to have one person do all the updates.