“Anguish” By August Friedrich Albrecht Schenck (1828 – 1901). Details of artist on Google Art Project [Public domain], via Wikimedia Commons.
I don’t really like polemic, most of the time. I think it often just feeds the beast, as Martha might say. I don’t like polarization or pointing fingers. I truly aspire to “generous questions … questions that invite honesty, dignity, and revelation.” But there are times when I must voice my outrage and sorrow.
I’ve spoken several times over the years about the abominations that are most online course registration systems. The example I typically use is a Nikki Giovanni seminar at Virginia Tech where the information in the course registration system is so vacantly unhelpful as to be, practically speaking, nihilistic. Such displays of casual disregard, in this context, move from irony into tragedy.
One may object that the point of the course registration system is simply to facilitate a transaction. That belief, of course, is precisely my point. A key moment of learner agency should not resemble online banking, or worse. C’mon people. Netflix does better. Amazon does better. Craigslist does better. Even the Division of Motor Vehicles does better, for crying out loud.
And I am crying, out loud.
But wait. It’s worse than that, as Jon Becker’s recent blog post demonstrates. (Go read it. I’ll be here when you get back.) Not only do we use Banner (or whatever) to strip out all the meaningful information from the moment when students actually choose to devote a substantial part of their lives and energies and financial resources to enroll in a course of study–meaningful information like a course website, a welcome from the prof, a syllabus, a full course description, heck, even a complete course title–but then we turn around and make these impoverished little information slivers nearly impossible to find.
This is probably the worst example in academia today of how decision-makers working on “business information systems,” in both universities and the vendor-land that supplies their habits, ruthlessly (and perhaps ignorantly, but that’s no excuse) pull up, by the roots, the values that could be strengthened and indeed amplified by the web-enabled affordances that could be bought or built. It reflects the destructive idea that the internet is a utility only, a set of super-fast announcement channels, a clutch of electronic four-color brochures, a warren of pneumatic content-delivery pipes, a non-network of isolated transactional sites for decisions about learning that are drained of meaning or discovery.
Unfortunately, it appears that most faculty have acquiesced to this destructive idea. It may be that most faculty actually agree with this destructive idea. This is where the anguish really starts.
If higher ed were not so stubbornly resistant to the open web, and if faculty acted more vigorously (or at all) to experience the greatness of the web for themselves, and insisted on web design for the entire university that functioned as effective learning environments fostering richly connected learning, we might yet be that fabled city on a hill. If higher ed truly believed that all of us have a stake in a digital commons, a commons we must contribute to and be nourished by, we might help build a future we’d want our children to live in. But we have insisted on our status and comforts, slandered the web we should be helping to build alongside our students, defined meaning too often as “those things we know and will tell you about in your courses,” and outsourced nearly every possible zone of online learning innovation, invention, and discovery to the vendors who peddle digital soma that will relieve us, gently and with peaceful slumbers, of the need to change our lives.
At some point accounting software became the model for data and transactions on the web. We see this in the idea of addable, comparable fields, stored is a relational db design whose prime skill is accounting joins and column aggregations.
It’s Ward Cunningham who first turned me onto to this in an inspired rant of one of his dozen definitions of “wiki” — “Wiki is the simplest possible database that could work.” What did he mean by that? I asked him.
Roughly, something like this — the databases we currently use were built for numbers, under principles that work for accounting — everything must be defined as narrowly as possible. This is a text field with 255 characters. This is a float. This is an ID that will join with that 255 character description, etc.
This makes a lot of sense when you are generating expense reports, but it is particularly lousy for capturing community knowledge, because it assumes that the database designer can anticipate what knowledge the community will want to capture.
Reducing structure makes it marginally harder to run reports, and sum totals, but it results in more information being captured and displayed, and allows for end-user experimentation when dealing with novel situations. So part of the question has to be whether we see our systems as something to inform and build community or something to run reports with.
My personal opinion is if you could ban the question “can we run a report on that” from vendor sales meetings you would end up with much better software. What we have now is reporting software that treats users as an afterthought.
My first thought was: Acquire the data, by hook (export) or crook (scraping), then reformulate in a useful way. But that’s so Web 2.0 🙂
Second thought: Annotate it in situ! Clearly I am carrying a hammer that makes many things appear to be nails, but let’s think about it. Teachers annotate the course catalog to enrich it with texts and links and rich media. Students annotate it to signal, to their peers, what they’re signing up for and why.
The annotation layer, in a private group that it’s cool to discover and join, goes viral on campus.
Crazy I know.
But…conceivable?
Look at Jon here, crazy with the upsell.
But he might be right, assuming you can point students to the appropriate URL, maybe overlays are the way to go? The big problem is discovery of those overlays — students when looking for a course are in corporate software mode, and unlikely to experiment unless directly prompted.
But if the problem is not a nail to Jon’s hammer, perhaps it is at least a screw.
What I find amazing about all of this is that I think if you asked most faculty and students why the course catalog isn’t as usable, informative, and well-designed as Netflix they would stare at you blankly. The technology has trained us to expect and accept so little.
Mike Caulfield writes: “Reducing structure makes it marginally harder to run reports, and sum totals, but it results in more information being captured and displayed, and allows for end-user experimentation when dealing with novel situations. So part of the question has to be whether we see our systems as something to inform and build community or something to run reports with.”
For me, the question you ask is rhetorical. Informing and building community must engage with complexity, innovation from the edges, folksonomies, emergence, etc. Higher ed appears to have invested enormous resources in networked affordances that do none of these things. And what is this “end-user experimentation” you speak of? Where are these “novel situations”? When it comes to many essential parts of our teaching-learning mission, that is, the core, these things are absent.
I suggest they are absent by design, meaning that a number of upstream decisions about what matters and what doesn’t, what is meaningful and thus must be controlled and specified lest other meanings are made, have established a whole set of assumptions that simply rule out other ways of thinking downstream. That’s a long-winded way of saying what Martha stated in her comment.
The only thing I’d add is that I believe we have the technologies we have because we wanted to expect and accept so little. It’s made our comforts and privileges more regular, predictable, pervasive. It’s like the Challenger accident, which happened in no small part because of design decisions based on the need to make good on NASA’s wildly erroneous prediction that they could launch 60 shuttle missions a year. Allan Macdonald is quite precise in describing this problem. When the engineers concluded early on that there was absolutely no way NASA could achieve that launch rate, the program managers overruled the engineers and–this is the important part–defined risk in ways that completely defied reason. Richard Feynman’s minority report makes this clear.
It’s a simple game. To get what you want, redefine reality to suit your purposes. You will get the results you desire, until the catastrophe happens.
Boy, I’ve had opinions about this for years, having spent done hard time in the bowels of these systems, trying to get them to play nice with the open web. In my opinion, these central student/faculty systems needs simply be comprised of:
1) An api that provides API access to faculty and student names, contact info, and course lists.
2) An authentication/security infrastructure that protects student data to satisfy FERPA and authorizes app connections with keys, just like in the grown-up world.
3) A set of business objectives and security standards for each tool that is to be developed on the API.
In-house or professional developers can design best-of-breed flexible open source tools for each of the business functions that require that data as a scaffold. If they want to monetize, monetize. If they want to share openly, share openly. But the applications have to address the person’s interaction with the information NOT the lumbering servers and Rube-Goldberg-like backend systems stitched together from the relics of the mainframe era. The cream would rise to the top, and sink when it no longer works, when someone designs something better. The innovation would be forward-facing. Every university should have an open source team that works to build business apps with an eye towards usability rather than generating ERP customizations of the “rearranging-chairs-on-the-Titanic” variety.
Then again, I don’t run the world, and the world, unfortunately, loves the solidity and associated informational constipation known as “ERP systems.” I understand that the world also likes Kraft Macaroni and Cheese.
Gardner, thanks for reminding me of why I left higher ed 🙂 Love you.
Pingback: Laying Down a Magic Carpet – Messy Thinking
Pingback: looking at college from the other side | digital digs
Fun story related to VT’s implementation of banner. A couple years ago (ish) I noticed a particularly obnoxious interface used to download a course roster file:
1) The page had separate sets of instructions for “mac” and “pc” for a process (downloading a file) which should be OS-agnostic
2) The instructions required the user to manual change the name of the downloaded file to end in ‘.csv’
3) The default name of the file was some undecipherable mix of letters/numbers that was probably related to the database ID and/or some session key.
Of course, there was no obvious feedback form to offer suggestions, so I exploited some personal connections to eventually get a hold of a URL to the banner support ticket system. I submitted a ticket which included a suggested fix (just adding a couple of HTTP headers to the response would get the browser to interpret the correct data type as text/csv and pre-fill the file “save as” dialog box with a sensible file name based on instructor name and CRN).
My suggestions were eventually implemented, but when I asked my contact about it, they said it had raised quite the kerfuffle at the IT office. One of the managers lambasted my contact: “How did a student get access to the ticket system? Students shouldn’t have access to submit support requests”
So not only are these online systems that we are forced to use so very bad. Those that maintain them seem to actively avoid getting any kind of meaningful feedback from those that use them.