Groupware challenges for developers: Reading Reflection #3

Imagine being someone who had developed a meeting scheduler when this bomb dropped⁠—ouch! Half the paper is spent on how futile it is to make a meeting scheduler (“the most widely available and the least useful groupware application”).

At the time this article was written by Jonathan Grudin, you had single-user applications and you had organization-wide mainframe systems, and people knew how to develop and sell and maintain those, but network groupware was hot on the scene and no one knew had figured out how to do it (with a select few exceptions, like email). Either the person who stood to benefit from the system wasn’t the person who would need to put in the work, or the system was too rigid and the would-be users found ways to sabotage or work around it, or there wouldn’t be enough support from management⁠, or all of the above (and more).

Right now I’m experimenting by writing this blog post directly in the WordPress editor, rather than writing in Google docs and copying it over here. It’s not bad, but already I’m missing things like my handy word counter that I like to have displayed while I’m typing, and I don’t like the way the block under my mouse is highlighted, nor the way the formatting tools appear when I move my mouse and disappear when I resume typing… Like Grudin said, everyone has their favorite text editor and people work on their own more than they work together, so your groupware will be better off the easier it is to hook into existing single-user apps. Luckily, WordPress makes it easy to copy/paste from Google Docs to their “block” format.

I’ve worked on projects that would have benefited mightily from the advice in this article. In one, a “wisdom of the crowd” system was developed over several years where the crowd were volunteers from all over, hobbyists. The wisdom was great, so finally, the system was transitioned to the client, and here’s the problem—the system was trained on geeks, but the end-crowd, so to speak, were professionals who were expected to take time out of their work-day to use the system. There were plenty of would-be wisdom consumers, those Grudin called free-loaders, but virtually no one to constitute the necessary crowd, and ultimately, the management lost patience and interest. So, like so many groupware systems before it, it died.

Could we have foreseen the withering of the system in its intended habitat? Maybe… But like Grudin observed, it’s really hard to evaluate groupware systems and predict how they will be adopted (or not) by any given community.