Tools, Purposes and Other Fairy Tales

The gift of instructional technology is tools:

• little tools that do one or two things brilliantly,
• big tools that do many powerful things quickly,
• the constant innovation which makes what is hard one day just a click away the next.

And the bane of instructional technology is: tools.

• Little tools that do a few things poorly,
• big tools so big they are slow and cumbersome and suck up your time,
• the constant innovation which takes away your sanity and causes us all to chase the delusion of endless "improvement" which is often only: the need to keep up and to seem to be improving.

Tools are wonderful. Tools are dreadful. When they are new and work, they are magic. When they age and break, they are worse than inert: they aggravate and infuriate; they are deader than the proverbial doornail. And it all happens very, very fast.

Tools are the how, not the way, mere means to ends, and therein lies the problem.

In higher education we are concerned primarily not with means but ends. The human being is the ultimate (earthly) end: her life and purpose and her ability to use her freedom to choose that purpose and to build that life however she sees fit in an understanding that emerges quickly or slowly, early or late, and sometimes even: just in the nick of time.

We subvert the entire meaning of our enterprise when we fixate upon means––tools, that is––and measure those tools only against other tools and not against the purposes towards which our mission points us.

But think about tools we must, for we are IT, and it's what we do. And so we struggle endlessly against the tendency to focus on the how and to forget the why. It is a mental struggle. It is a moral struggle. Sometimes it almost seems like a physical struggle: a gripping in the pits of our stomachs and an itching and tingling in our legs. As long as we live and breathe tools, we will always be uneasy.

What is the prescription for this unease? How in higher ed can we focus away from the tool and towards the ends?

One way is to focus not on the tool but rather on the use case.

A use case is a term of art. It sounds fancy but it's simple. A use case is a story. It's a picture of some things a user does. It's journalistic: like the "lede," that first part of the news story that gives you the whole picture but also whets your appetite to know more.

Write a journalistic "lede" without the "how," and you have a use case: the problem to be solved, the thing our users need to do, the reason that they come to us, their purpose, their 'end.'

• Who?
• Does what?
• When and where?
• And why?
• To achieve what?

Subject. Verb. Circumstances. Purpose. A use case is a sentence writ large, exploded into steps. It could almost be the panes of a comic.

And we are the ones who help to figure out the 'how.'

For many use cases, I would like to argue that the 'how' should always be in three sizes.

Just as in the fairybook bears' house, in IT-land solutions come in three sizes. Like the bear story, it's a fairy tale: there aren't really just three sizes. And they aren't just sizes, they're bundles of traits––ownership, complexity, flexibility, and more.

But three is a good number, because looking at and choosing amongst five or seven or ten things is harder. So we in higher ed IT do well to recommend tools in three sizes and kinds.

1. A free and easy consumer service with just a few functions. It's not meant for professional use but it's adaptable for many purposes. It's not hard to use, though finding all the tricks can take time. And we don't own it.
   • Think flickr for photos, Youtube for video, Dropbox for file sharing, Slideshare for publishing presentations, etc.
   • We don't care that we don't own it. We just need to make the proper warnings about where the data lives, who can access to it, whether the data can be sucked out, our lack of control, etc.
2. A free service and which has robust-, numerous- and flexible-enough functions that it can be used for many purposes. It takes time to learn, but the learning curve is not steep. And we own and offer and support it, and that means it's geared more towards the kinds of purpoes our users have.
   • At some campuses, it's WordPress. It's run locally. Anyone can request a site. There are already-built resources. It can be used for courses, working groups, projects, etc. It can be public, private or community-only.
3. A specialized service which we have licensed or built, which has a high degree of complexity. It can be used for many different purposes. You can use it a little or a lot. The learning curve is steep. Whether it's someone else's or not, we bought it and we provide it and so even if we don't own it 100%, we get the blame when things go wrong.
   • Think a sophisticated digital asset management service, or even Adobe's Creative Cloud suite, which many (wealthy) campuses license and which (in aggregate) is off-the-charts in complexity.

As with many choices, it's really a table. This one has one binary distinction and four scales.

type	who owns it?	how many functions?	how complex?	number of purposes	learning curve?
simple, free & easy	someone else	few	simple	one or two	none or trivial
our un-fussy service	us	not too many	relatively simple	more than a few, less than a dozen	non-flat
"our" high-end service	us	a lot	complex	many, many	steep

But tables are for nerds like me, and a list is more human-readable, and this is one of those distinctions we in IT-land often forget, because "I can understand it," but then I am not the user.

And unlike in the three bears' house, in IT-land each of the three sizes is "just right" for somebody. Every user is a Goldilocks who deserves her chair and bed and porridge just the way she likes it.

• People who come to us for simple functions can be directed to simple tools––even if we don't own them.
  • And we need to have worked out the use cases well enough so that we can give a short 'getting started' document or demonstration.
  • We don't need to know all the answers––as long as the client knows they are using someone else's pipes.

Unlike many things in IT-land, the process doesn't have 86 steps.

• Write the use case, and identify the three choices.
• Give your users a clear picture of the use case: who does what.
• Help the users choose wisely, and help them get the right amount of support for each choice.
• Advise your users appropriately of the advantages and pitfalls––learning curve, data ownership, privacy, security, longevity, etc.

If you can get the users to share their successes, then others will see what success looks like, and they too may come to recognize that one size seldom fits all, but there is often one size for each user that is "just right."

––Edward R. O'Neill