It’s easy to trash the tool when it fails to fix the issue at hand; and perhaps as easy to criticize the intended user for resistance or ludditism in their failure to adopt use of the provided tool. However in my experiences where the tool “fails to fix the problem”, the issue most often seems to lie elsewhere; the “critical step” in the communications problem is about something other than the tool itself or with individuals’ willingness/openness to adopt its use. & the problem is that we threw a tool at a system that was broken elsewhere than in the need for a tool.

Many of the tools mentioned in the comments above are great tools, and perform well in their intended tasks. e.g. I had to bite my tongue in order not to jump in defending Learning Management platforms in blended classroom settings (I use Moodle in my institution, and am thrilled at what it has permitted us to do within our learning community). Similarly, a hammer is a great tool; but it does not build a house. And given any particular situation, dropping a hammer into the picture will not necessarily be what the system needs in order for a house to materialize. In such a situation - drop in hammer, no house results, or some ramshackle structure ultimates which subsequently leaks & falls apart - it is easy to frame the hammer as defective, or to characterize the user as resistant in its use. It’s perhaps a bit more difficult to perceive that perhaps the wood was of poor quality, or that in fact no house was desired to begin with.

I like to build tools. And to Bush-ism the old hack, “when all your tools are tools, all your problems look like things that tools can fix.” Ain’t always the case, is it?

In the example I gave above re the Calendar, I think there are 2 “obvious” but inaccurate conclusions: (1)the webcalendar application is not a good tool; and (2)the potential users are luddites and are unable/unwilling to adopt the technology. I really don’t think either of these conclusions are realistic. This tool is used quite effectively in other institutions/systems; and our users have enthusiastically adopted other technological tools which speak to their needs. I think the real issue here, is that the communications issue is broken elsewhere. No one was clambering for a tool to “fix” this - had they been, we would likely have seen several proposed “tool” solutions - a big paper calendar in the main hallway across from the faculty support office with copies faxed to other locations, &c. We’d have been working on refining the tool for communicating the calendar, and the web-based calendar would likely have been embraced as a successful solution.

Perhaps however we have a community of “cats” rather than “dogs” who really don’t want to feel constrained by a central calendar. Perhaps there are offices vying for centrality who struggle to release their sense of control to a central calendar-handler. Perhaps the “big picture” of institutional events is more than most folks wish to juggle, and folks are content to keep abreast of issues/events close to their individual daily experience, not really feeling any immediate need for a central institutional calendar. Perhaps folks prefer to kvetch when things collide or resign themselves to the perceived inevitability of this. Perhaps Mercury really is in permanent retrograde in our institution’s birthchart. These then are the aspects of the system that require attention, and the mere introduction of a good calendar system will not address the disease. It will likely bring the existing disharmonies to the fore, as they have fewer places to hide - and intensify the issue rather than bring it to resolution.

I suspect that tools work well - and often evolve organically - when the lack of an effective tool is the critical step missing in a systems issue. When the missing step is somewhere else, throwing in a tool is doomed to failure. “Build it and they will come” works when the need exists, and the built-thing is the critical missing step. More commonly, the applicable axiom is “necessity is the mother of invention”.

wt.similibus.org