Occasionally (well, OK, more than occassionally) I’m asked why we can’t just get a single educational tech application that would have everything our students could need — blogging, wikis, messaging, link-curation, etc.

The simple answer to that is that such a tool does exist, it’s called Sharepoint, and it’s where content goes to die.

The more complex answer is that we are always balancing the compatibility of tools with one another against the compatibility of tools with the task at hand.

The compatibility of tools with each other tends to be the most visible aspect of compatibility. You have to remember if you typed up something in Word or Google Docs, remember what your username was on x account. There’s also a lot of cognitive load associated with deciding what tool to use and to learning new processes, and that stresses you out and wastes time better spent on doing stuff that matters.

But the hidden compatibility issue is whether the tools are appropriate to the task we have at hand. Case in point — I am a Markdown fan. I find that using Markdown to write documents keeps me focused on the document’s verbal flow instead of its look. I write better when I write in Markdown than I do when I write in Google Docs, and better in Google Docs than when I write in Word. For me, clarity of prose is inversely proportional to the number of icons on the editing ribbon.

Today, Alan Levine introduced me to the tool I am typing in right now — a lightweight piece of software called draftin. Draftin is a tool that is designed around the ways writers work and collaborate, rather than the way that coders think about office software. It uses Markdown, integrates with file sharing services, and sports a revise/merge feature that pulls the Microsoft Word “Merge Revisions” process into the age of cloud storage.

As I think about it, though, it’s also a great example of why the all-in-one dream is an empty one. If I was teaching a composition class, this tool would be a godsend, both in terms of the collaboration model (where students make suggested edits that are either accepted or rejected) and in the way Markdown refocuses student attention on the text. Part of the art of teaching (and part of the art of working) is in the calculus of how the benefits of the new tool stack up against the cognitive load the new tool imposes on the user.

We want more integration, absolutely. Better APIs, better protocols, more fluid sharing. Reduced lock-in, unbundled services, common authentication. These things will help. But ultimately cutting a liveable path between yet-another-tool syndrome and I-have-a-hammer-this-is-a-nail disease has been part of the human experience since the first human thought that chipped flint might outperform pointy stick. The search for the all-in-one is, at its heart, a longing for the end of history. And for most of us, that isn’t what we want at all.

Photo credit: flickr/clang boom steam