Yesterday, in a fairly crowded Weldon, I found myself in the nice and ironic position of being stymied by the self-checkout system to the point where I gave up and resigned myself to being stuck in front of a line of people, each of whom was checking out an entire floor of the place. The fact that the books I was trying to check out were a Marshall McLuhan book and another book on using technology to facilitate learning, of course, helped the inherent awesomeness of the whole situation.
After I got bored of looking silly and checked the things out in the manner of the previous century, I got to thinking about the learning processes for various different things in general, and technology in particular. It’s been bouncing through my head a lot this semester, which is probably a good thing when one of my textbooks is on interaction design. Quite a bit lately, between my making heavy use of Blender for various personal and school projects, figuring out the foibles of the SMART Board software for another project, and considering seeing if I can pick up Python as well. Only one of the three really strikes me as especially esoteric at this point, though the two I’ve got some experience messing with these days have each routinely set me off on some proper rants.
I’ve been reading Raymond Siemens’ and David Moorman’s Mind Technologies: Humanities Computing and the Canadian Academic Community for the last few days. It’s more or less what the title implies – a survey and discussion of the state of technology use in academia in the country, in the form of a series of essays or chapters by various scholars in different fields, discussing how they’re applying technologies to their various projects. One of the chapters was by John Bonnett, whose work I’ve written about here before. The chapter mainly discussed his Virtual Buildings Project, although the secondary focus of it was on, as he puts it, “how hieroglyphs get in the way.” Bonnett defines “hieroglyphs” in his chapter not as the pictographs used by Egyptians, Mayans, Mi’kmaq and so on used, but rather expanded the concept towards any sort of system which is unnecessarily complex or abstruse. When we encounter something we just can’t figure out ,either due to a lack of knowledge on our part or a lack of effective design on the part of what we’re trying to use, it might as well be in another language.
Part of learning these other “languages” is, to be fair, our own burden to deal with. There are very few things out there which one can’t figure out, but quite a few that they won’t figure out, due to frustration, a lack of time or energy, and so on. And the more “languages” one knows, the more they can pick up as time goes by. With too little background, just about anything can come across as Linear A, frustratingly indecipherable despite our wishes or efforts.
But that doesn’t excuse opaque interfaces or user-hostile design in the process of developing whatever you’re working on, be it a scanner, a piece of graphics software, a book, or a simple tool. Back in December, Carrie asked, “why can there not be more formulated programs for the not-so-computer-savvy historian?” (emphasis added.) It’s a good question, one which should be asked more often and more forcefully than is done these days. There’s a lot of incredibly powerful tools for any number of tasks just sitting out there – including the tools to, if need be, make additional ones – that are seeing very little use either because they’re hard to find or they’re difficult for the uninitiated to get their heads around. As I said above, part of the responsibility to deal with that falls on those of us who want to use these things: a certain minimum of effort is necessary to learn how to do anything, of course. At the same time, not everyone is going to have a background in computer science or the like, especially if they’re in the humanities.
Rather than use this lack of background as an excuse to avoid the entire field, we ought to be putting some effort into finding what’s out there that can be readily used and making it known to others. We could be finding tools that are out there and suffer from these learning curve programs and try to figure out how they can be improved through better interfaces, documentation, and so on. And probably most ambitiously – but most rewardingly – we could see what we can do about making, or at least planning or calling out for, some of those tools ourselves, as we (usually) know what we want in such things. Each of these is necessary for those of us wanting to incorporate new tools into our work as historians (whether public or academic), and aspects of each are at least feasible for any of us.
No comments:
Post a Comment