failsafe: cultivating dysfunctional tech-literacy.

I came into the office this morning dragging a long mental to-do list, only to find internet access down in most buildings on campus. This being a large (albeit temporary) productivity barrier for the average e-learning librarian, I searched myself and realized that the only thing I’ve been meaning to do that doesn’t require connectivity is, fittingly, write this blog post on technology failure.

I’ve apparently lingered on snafus many times in the past, including in the July 2010 issue of Library Technology Reports, which examined predictions and experiments with VoIP and web video from the oft-maligned library 2.0 era (predictably few of which turned out quite as expected). Less-than-success has also been occupying my mind in a preparatory capacity: Internet Librarian is later this month and has an entire track devoted to risk, innovation, and failure, spearheaded by the incomparable Sarah Houghton-Jan. I’ll be joining the Failcamp panel from 1:30-2:30 on Tuesday the 26th with three of my other favorites: Amy Buckland, Jan Dawson, and Krista Godfrey, to talk in an entirely lo-fi and highly interactive way about the inevitable trial and error of innovation.

I find that in general there is no better way to understand oneself and one’s capacity to deal (or one’s organization and its capacity to thrive) than by looking hard at how you/it create and/or mitigate projects, tools, etc. that, for one reason or another, end up whimpering instead of banging. S.o.l.-seeking can go far beyond this practical tendency toward slightly masochistic self-examination, however. True failsafing requires, in part, a nuanced understanding of the many shades of technology crap-out that exist. To name a few:

a) Actual, honest to god system failures, crashes, etc., such as the web blackout I am experiencing as I write this.

b) “Failures” that are in actuality evidence of critical de-bugging in pilots, experiments, and trial runs, which any project manager knows like the (shards of glass embedded in the) back of their hand.

c) The ubiquitous, inevitable user fails that accompany our interactions with every gadget, service, and app under the sun.

Let me linger a while on c). In social media and externals of any kind, five times out of ten this type of fail is likely to be caused the inevitable misunderstanding that comes from a proliferation of unfamiliar settings/functionality. Such as the time when, intending to scold me privately for not calling, my (wonderful) father inadvertently did so on my public wall:

dad scold

Or, when my (amazing) mother described her own bit of Facebook trouble after my bike wreck a few years ago:

Fair enough, understandable, and totally democratic: we are all confused by our tools to varying degrees, even if only momentarily.

The other five out of ten c-class fails come from another (and in my opinion, far more frustrating) source: the marketplace, itself wholly dependent on the innovation up-and-down. These fails are caused by obsolescence, grandiose expectations, outdated versioning, service cancellation, merges, or plain old bankruptcy. The Industry has become so good at creating buzz and usership before tools are stably deployed that unrealistic expectations of longevity are created. On the flip side, we blithe consumers are so stoked to eat it up that there is no compelling reason not to. A perfect example of the consequences of media/technology instability was when my nephew’s dedicated baby website, where my family had been journaling and uploading pictures for several years, unexpectedly disappeared with little trace or warning – no archiving option that I know of was offered, which was basically like his childhood scrapbook up and vanishing. Three larger-scale recent examples: Blio debuts missing key accessibility features, Second Life yanks its educational discount, and Google pulls Wave in its entirety due to lower than expected adoption.

While the SL news doesn’t surprise or concern me, the Wave fail did both in spades. If working with technology is replete with all classes of snafus, teaching with and/or about technology is just as perilous – often more so due to the crashing-and-burning in front of an audience element. That said, writing about working and/or teaching with technology is the most perilous of all. Why? Because as much as you might develop a robust knowledge of multifunctional tools and the ability to learn and adjust to them quickly, you still inevitably end up a) relying on specific platforms to do your own work, 2) advocating, endorsing, or demoing things in analog or digital venues that may not exist or function tomorrow, and 3) being crushed under the wheels of the traditional publishing juggernaut, which remains dismally equipped turn as fast as the pace of innovation. I recently had a perfect confluence of all three, a long story best recounted in bullets:

  • As I might have mentioned once or twice, for the past three years or so I spent a ton of time writing a book on instructional technology and design.
  • In chapter 6 of said book, I proposed a method for expanding one’s teaching technology repertoire by experientially evaluating the practical “affordances” of emerging tools.
  • In a massively irritating move, I chose way back in the dim days of 2009 to use Google Wave, one of the emerging instructional tools of that day, as a long-form case study of how to examine these affordances.
  • I triumphantly turned the page-proofed manuscript in in late July 2010…
  • …less than a week later, Google made its announcement about scrapping Wave.
  • I flipped out a tiny bit, then faced a decision: do I re-write Wave out of the manuscript, or leave it in with a contextualizing note that this is a perfect caution against relying on emerging tools?
  • After more s.o.l.-searching and informal polling of peers and editors, I decided to leave Wave in and use it as a cautionary tale…
  • …all of which set back the publication of my book by several months.
  • However, it also created the added bonus of a semi-hilarious personal fail to recount,
  • which is sortof the best part.

What is amazing is that I was relatively lucky: I got my proof back and a chance to fix the situation. Many technology writers/teachers/enthusiats don’t have the same luxury. There are any number of books on Google Wave already published (including this unfortunately named gem): how many in-progress works, not to mention teaching initiatives and ongoing collaborations in Wave, just bit the dust?

In a world without guarantee that the services, startups, and gadgets we use today will be around tomorrow, cultivating positive-yet-cagey flexibility is key. My personal favorite failsafes? Studied detachment and informed unflappability. Toward these ends, I propose the adoption of a new skillset into the panoply of digital age competencies: dysfunctional literacy. I have come to believe that if you do not accustom yourself to the idea of losing your best technological friend at some point or another, you are likely to become techno-developmentally maladjusted. Sociopathic, even. Preparing for the inevitable outmoding, disappearance, and/or cache-waning of today’s tech in the face of the next, ahem, wave should simply become a way of life for anyone that touches a computing or mobile device, ever.

Shoutout to Brian Mathews for his video solidarity on the Wave fail.

3 thoughts on “failsafe: cultivating dysfunctional tech-literacy.

Add yours

  1. that is a delightfully zen (and perfectly practical) perspective on how to interact with the cloud! “dysfunctional literacy,” i love it.

    librarians absolutely must retain (or develop) a sense of humor about technofailure if we’re going to continue participating in the digital age in any constructive kind of way. i think the high likelihood of your favorite new tool/toy disappearing into the ether without a trace is a blessing in disguise: it forces us to focus on the content, and not rely so heavily on format.

    here’s to keeping on our toes!

  2. What if we let tech teach us that everything changes and, therefore, is always subject to change? I like this take you give us here as a potentially politically vital one–students also need to learn habits of adaptability and willingness to look at systems for methods of use without being too concerned about learning something once and for all. Like that the ’email this article’ link in a db interface will usually look like an envelope and be somewhere around the perimeter of the screen. Since it doesn’t have to always be one way, we can begin to imagine that even we might have some capacity to change it. What if we could cultivate this same feeling about, say, income distribution in this country. Wouldn’t that be awesome! What’s nice about tech is that, as you say, the opportunities to experience how resistant to permanence and subject to change and failure are constant. Might be interesting to mobilize that failure as a useful analogy to the rest of the structures that fail us all the time.

    Though I may be straying too far afield.

  3. Nice post! I was reminded of how reliant I was on EtherPad in the classroom, which was great for giving students a document that allowed everyone to edit at the same time. EtherPad then got bought up by Google Wave and disappeared, and then Google Wave…etc.

    Another lesson I take away from the disappearance of favorite technologies is that while the tool may evaporate, the functionality may be available elsewhere. Being able to identify that functionality as an abstraction is a valuable skill, one that seems connected to talk lately about the need for students to be capable of “computational thinking” (a concept I know mostly from Jon Udell’s blog posts and podcasts about it).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Website Powered by

Up ↑

%d bloggers like this: