Transcript
Transcript of the talk. The audio file can be found here (MP3), and the slides can be found here; advance through them with the spacebar. If you contribute any fixes to the transcript, please add your name to the Contributors section at the bottom of this page. Thank you so much! --Karl
JILL MORRIS: I am here today to introduce our final keynote, Karl Stolley, who is an associate professor of digital writing and rhetoric, and co-director of graduate studies for the Lewis Department of Humanities at the Illinois Institute of Technology. He teaches graduate courses on web design, information architecture, and the rhetoric of technology. He also recently wrote a book that I'm sure many of us are using in our classes, or at least as support material with our students, How to Design and Write Web Pages Today, which makes the argument for writers designing and developing websites at the source-code level according to web standards. His talk today is called "In Search of Troublesome Digital Writing: A [Meditation] on Difficulty." Please give a warm welcome to Karl Stolley.
KARL STOLLEY: Thank you Jill for that introduction and for putting together a conference that has taken some risks, although giving me a hot mic in a room full of people might be the biggest risk that you've taken yet. So, if you haven't pulled up the slides on your devices of choice, you can do that. In theory...in theory, as I advance the slides up here they should advance throughout the room. Trying this for the first time, it might explode. As long as this one up here stays together then I'll at least be able to get through the talk.
So, I promised, at least in the title, a meditation on difficulty. That might be false advertising. I think I put "meditation" in the title so that I would calm down.
CINDY SELFE: Karl, would you switch back to the slide with the website?
KARL STOLLEY: Oh sure. ks4--like "Karl Stolley for us". How cute. It's my own URL shortener. ks4.us/cwcon. And I think it's been tweeted, if people wouldn't mind tweeting it again.
So I'm going to talk about troublesome digital writing. And in order to start moving in this direction to talk about difficulty, I want to raise some overarching, provocative questions. And particularly I'm curious about what is the intellectual status of the digital writer? And the teacher of digital writing? And the professional digital writer? And here I'm thinking about the web designer, or the content strategist, or even the game designer. I think that we need to more publicly talk about who are the professionals at the other end of what it is that we're teaching in our classes.
So, to start talking about intellectuals, I'm going to torture Michel Foucault a little bit, who in this interview from the 70s called "Truth and Power," he talks about the universal intellectual--people like Voltaire and JS Mill. And he notes that these people derive from their status as jurists or notables. And that they find their fullest manifestation as writers. However, Foucault also notes that "the threshold of writing, as the sacralizing mark of the universal intellectual, has disappeared."
Here's the most controversial slide. He wants to blame theory for this. And say that the fact that we needed to theorize writing was exactly the reason why writing was no longer the focus of intellectual activity. In place of that he raises the spectre of the specific intellectual, which he notes derives from another type of person, particularly "the savant or expert." And the specific example he raises for this is Robert Oppenheimer, of course the father of the atomic bomb. And he notes that "it's because he [as a specific intellectual] had a direct and localized relation to scientific knowledge and institutions" that Oppenheimer "could make his intervention." But because "the nuclear threat affected the [entire] human race and the fate of the world, his discourse" becomes elevated to that of the status of the universal.
I believe that we can do this with digital writing. We're not building atomic bombs, thank you very much. But certainly with what's happened the last few days with the NSA and the PRISM program, if we are going to be involved with digital medium, in some ways we are participating in the fate of the world, or at least the fate of this country, of our constitutional rights to privacy, our ability to communicate with one another and not be fearful about that.
So, here's my thesis statement: Given the opportunity for extended encounters with difficulty, rather than tools that route around difficulty, digital writers can become specific intellectuals--people whose deep technological expertise rivals that of their command of rhetoric--who are therefore able to learn, teach, and build things that scare the crap out of others. [Laughs.] I thought that would get a bigger laugh. It's the whole NSA thing, right? Ugh. I'll just edit this later--I can put a standing ovation on that line.
But to get there writing takes a difficult digital turn to restore its status as the locus of things in ways that I don't think Foucault could possibly have imagined 30 years ago, 40. So to proceed, I'm going to first talk about identifying productive points of difficulty. And then refine those points of difficulty through something called "threshold concepts." We can't yet call those a theory, but they're a group of really interesting ideas, at any rate. Then I'm going to describe some specific threshold concepts through two sources that are really kind of awesome, but weird. The first is the UNIX philosophy, particularly articulated by Eric S. Raymond in his book on UNIX programming. You might know Eric Raymond for his book The Cathedral and the Bazaar. Those of you who are into open source are probably familiar with that. And then another book called The Pragmatic Programmer. And I'm going to sort of situate those in three different classes that I teach, including a brand new one that I'm offering this fall. And then finally I'm going to just offer a quick plan for professional development.
So first: I am not setting up difficulty as a binary against ease. Dreamweaver is difficult. WordPress is difficult. The command line is difficult. Everything that you're doing is difficult. And, if it wasn't, this conference would be as big as the Four Cs. Everybody would be doing it. We live in and dwell amongst difficulty. We do crazy things in classes. We ask and challenge students in very, very insane ways. But the question I have is, what kind of difficulty are we putting ourselves through as professionals and then introducing to our students. So here's my wild graphic. And this is, hopefully you've got this on your device. But I believe that in any digital rhetorical situation we have some kind of primary difficulty. Like, putting up a course website, or, designing some sort of electronic survey to conduct research. Something like that. And, here comes a binary: we can go one of two ways in this. We can break that primary difficulty down into constituent difficulties, or we can go the other route, which is, what I call "excessive mediation." Where we use a tool that kind of just skirts past those constituent difficulties. And what we find at the other end are what I call secondary difficulties. These are difficulties that emerge from the tool that's being used. And the problem here is that that leads to sand traps. You started off with the best of intentions in making a course site in WordPress, let's say. But now you're stuck in a feedback loop and you're posting on Twitter and TechRhet and you're asking questions like, "How do I do X in WordPress?" And so rather than focusing on that primary difficulty, you're stuck in a feedback loop of the secondary difficulties of the tool you're using. [8:15]
[Begin 8:15] On the other side, we break up the primary difficulty into its constituent ones. So if we're going to build a course website, we have constituent difficulties like: how do we make this maximally accessible for all students, how do we make it so that you as an instructor can update the design and the content of the site in easy ways, and we can continue to kind of break those down. And then we get a smaller subset of secondary difficulties there because we're still working in a mediated environment, but rather than leading to the sand traps of the excessively mediated way, we're dealing with these thresholds or threshold concepts that move us to a different place of understanding.
There may be some sand traps, too, if you start using something that I love like the version control system Git. Git has its own problems; Git does have its issues where, "How do I do X in Git?" But I think they are muted with regard to the thresholds, and I tend to think of sand traps and thresholds as being a ratio. So if there are, if we take thresholds divided by sand traps, if that number is less than one, then I don't use that technology in my professional practice, and I don't bring it into my classroom.
You totally can't see this, but I've tried to map this onto four points here. In the upper left-hand corner by the constituent difficulties, we have the quality of being overwhelming. It's overwhelming. On the other side with excessive mediation, we have ensnaring, right? You've discovered the hammer of one particular technology, and the whole entire world is a big, shiny nail. At the bottom as we move through these levels of secondary difficulties, we develop expertise on the far side, and on the other side, we develop dependency.
So to summarize and get that ugly chart of the screen, and hopefully yours, too--are the slides advancing? Sweet! You gotta go with the little victories, man, I'm tellin' ya. So I am, sort of, summarizing this as our productive difficulties are those that sidestep the issue of keeping up. Everybody is always like, "I don't know how to keep up with the technology." Here's the secret: you don't. ...I'll just let that fester, and we'll go into threshold concepts.
So threshold concepts, these are ideas that were developed in the United Kingdom and in Europe. A couple of researchers, Meyer and Land, were talking to economists and physicicsts and trying to figure out what are the essential ideas that you as an economist or a physicist or a mathematician have to comprehend in order for you to advance within your own discipline. And they offer this definition where they say that "a threshold concept can be considered akin to a portal, opening up a new and previously inaccessible way of thinking about something," and it therefore "represents a transformed way of understanding or interpreting or viewing something without which the learner cannot progress." And that is the key point. When I'm designing courses or when I'm choosing technologies for my own development, I really don't care what widget is going to roll off the digital assembly line. I'm worried about next week, next month, next semester, next year, next ten years. What are students going to be able to do, even if they can't do it right now, based on the kinds of things that we're covering?
And in this way threshold concepts differ from core concepts or core learning outcomes because they represent this "seeing things in a new way." For example, in mathematics, addition is sort of a fundamental concept. Some quantity plus some other quantity is some larger, bigger quantity. But you can do addition all day long, as long as you want, and you're never going to get to infinitesimal calculus. Right? We all know infini--I'm not even going to try to say it again. [Laughs.] So threshold concepts are these things that take us from one place to another, like in algebra, the transitive property. We need things like that. We need these other kinds of concepts to help us move beyond where we are. So the qualities of these things are that they are transformative, irreversible, integrative, bounded, and troublesome, and as a bonus, they are also discursive.
So let's take these things one by one and I'm going to use web standards as a sort of example for how we cross thresholds with these things. In 30 seconds, if you don't know web standards, core languages of the web - HTML, CSS, JavaScript - all have a standard specification that in the last 10 years has been more faithfully implemented in browsers. That's how I'm able to do these slides today with all this cool whiz-bang stuff. They ask that we separate things into different layers. Ooh, interesting. I think my slides just got broken up here. Okay, that's web standards - they're transformative. Don't know what happened there. So they alter the ways that we see, think, or do things. And in the case of web standards, that is, we separate concerns when we write digitally. We put structured content into the HTML, and that's it. No design, no behavior. At the presentation level in CSS, we put all of our visual stuff there, and do all the behavioral stuff at the [?]. So that's a way of seeing things that the students in my class get frustrated with, once they've had a little taste of that. That second that they need to copy some text out of a PDF, which is this big, just ball of design and garbage and line breaks and columns and things like that. When they get to the point where they see the separation of concerns, they have a different experience elsewhere.
Threshold concepts are irreversible. Once they're learned, they really can't be unlearned, at least without a great deal of difficulty. They can be ignored, and a lot of times I'll get emails from students like, "Check out this cool thing I'm doing at work! Don't look at the source code, though, because it's not standard compliant yet. I'm really ashamed, and we're working on trying to get there." Okay, great! That's fine. Do it knowingly. Make that decision, but that threshold concept is still there in the back of your mind. I'll skip that example.
They are integrative in that they expose relationships between knowledge that previously seemed unrelated or disparate. And so here comes some slide action. So in the top of this one, I have some command line interaction where we're changing directories into a web folder and finding a directory there called "fu," and inside of "fu" is a file called "bar.html" - if you ever start reading programming, get used to fu/bar [?]; it's all over the place. Just a little nod to that discursive community. And we can do something like change the read/write permissions on that fu/bar.html so that it's world-readable, which seems totally alien. Our students are used to clicking through folders and things like that. The idea of going in that linear, textual fashion through a file system is really weird, but it just so happens that that fu/bar.html is exactly what we would write in an anchor tag to make a hyperlink in an HTML page. Boom! So these two different alien-abduction kinds of technologies become integrated with each other. Sounds pretty good.
But threshold concepts do not necessarily open to mastery, but to additional thresholds that in turn have to be crossed, and this is a source of frustration for students. So for example, in HTML we might have a hyperlink to some external website, and we'll drop in the target_blank attribute to open that thing in a new window. Sounds good, but it's wrong. Right? We gotta go back over another threshold and say that behavior like that belongs not in that structural content layer, but in the behavioral JavaScript layer and so here's four lines of jQuery, you can take this one to the bank and drop it in your website this afternoon, that's how you open up another window. We can have another talk about whether that's something you actually want to do, but if you do, that's how you do it.
And, back to integrative, that little selector there, that a_href and the http? That's actually a valid selector in CSS. So again, this is integrative. If students understand how to make selections in CSS, they can then kind of do this JavaScript stuff. Unsurprisingly, this is all very troublesome - for students, for their instructors - we're offering up knowledge that is alien, counter-intuitive, and potentially, no, probably most definitely aggravating. And for this reason, crossing a threshold is not like running through the tape at the end of a marathon; you have to go back and forth and relearn a lot of hard lessons, over and over and over again. And of course, that's hard because we have this conception, still, of what digital writing has become, at least, in the world since Windows 3.1 and Microsoft Word: we have some box, and we compose in it. And what I try to offer up in my classes is something that looks like this: writing, writing, writing, writing, writing. Yes, it's source code, but it's also writing to the very core.
Threshold concepts are discursive in that they change the manner and level of sophistication in which learners talk and write. This is so crucial for me as an instructor to be able to help students, for to be able to teach. We need the language to talk about things, and as a heroic example, here's an actual memo from one of my undergraduates this past fall, who writes on his memo that he turns in with his project: "Towards the end of the project, I found both my HTML and CSS were getting messy. I started seeing a lot of classes and ID's in my HTML, and my CSS had a lot of redundant properties and values. To simplify it, I put together selectors that shared the same properties and values. This made my CSS shorter and easier to read." Cool.
But it gets set up in that particular way. The first assignment in the web design class that I teach, I don't open what they've written in a web browser. I only look at the source code; I only respond to that, because they can't do anything yet! It's going to be a red and green page that looks like Kermit the Frog... and the writing isn't going to be so great. But what I'm interested in is are they learning to write at the source level and to treat that in the same kind of dignified manner that we would want to treat all writing. Hang on while I have a Marco Rubio moment.
Okay, so I want to transition into some of these grounding threshold concepts for my courses, but here's sort of the big one that I employ everywhere, and that is that costly tools don't produce better designs - this is one from The Pragmatic Programmer. And they advise us to beware of vendor hype, industry dogma, and the aura of the price tag, and to judge tools on their own merits. And of course to costly, we could also add well-known, popular, or "the thing we used last time." Bob Gill is a graphic designer who has a book called Graphic Design Made Difficult and his basic thesis of how one makes graphic design difficult is always to do something new every time, to not rely on that thing that worked before. So, okay, judge tools on their merits. That sounds good, maybe, but what thresholds must be crossed for us to be able to effectively judge tools on their merits? We can look at spec sheets, right? And yeah, okay, it's got all these features in it, but does that give us what we need to really make a judgment call on those?
So, I commit this sin, which is to consider the web as THE platform for digital writing. Maybe five, six years ago, this was a risky thing to believe, but the mobile devices that you're all using to look at these proves that that was not the craziest thing in the world, to treat the web as our platform. Not just something to run Google docs through, but rather those deeper constituent difficulties of web writing: the HTTP specification and all of that low-level stuff that kind of swims down there. So I focus on the technology, and I'm unapologetic about it. But I do so in a very particular way, which is to say, Unix-like operating systems, so, the Berkeley standard distribution, or Linux, or OSX - Congratulations! If you have a Macintosh computer, you have OSX, you have a Unix distribution - and then a browser to look at the web, an editor to write everything, and a command line shell with a package manager. That is it. If I have those three things, that is the place for me to stand and pull a lever and move the world and all that stuff.
The rest is writing. Languages, including English - English is allowed in my class; I'm not prejudiced against prose - the commands that we write, and the scripts. And so my technology philosophy is in a nutshell is "Text, or it didn't happen." When students write me with a problem, they say, "Oh, my web page, there's this block and it's stuck over there and I can't move it." I say - I used to say, just, "Well, let me see the source code," and now I say, "Well, let me see your GitCommit(?). Let me see the point at which that got broken." And so then I'm not only seeing their product, but I'm also engaging with their process and figuring out what moment did they go wrong, at what point were they poised to cross a threshold and then went and smashed their face into a wall someplace. That's where the teaching happens.
And it's funny that we are prejudiced against text. Andy Feinberg, who - alright, everybody who's tinfoil-hatting up for the MOOC revolution, go back and read Andy Feinberg's Transforming Technology, particularly I think it's Chapter 4, maybe 5, I dunno, somebody correct me and tweet it, oh and heckle, too, but he - writes that the basic fact about computer networks is scarcity of bandwidth, and that writing is the oldest technology that we have to have in our tool set for dealing with the narrow bandwidth. Now this is crazy; we all stream Netflix so we can watch Arrested Development through the same thing where we check our email.
However, our bandwidth person-to-person is still so narrow. That email that comes in with the student who's like, "Oh my god! Look at my digital project! I don't know what happened!" When I ask for GitCommits, when I ask for source code, I am acknowledging that, as your instructor on the other end of an email connection, I need something that's going to work low-bandwidth. You can send me a video of your problem; I still need to see the source code. We work in a low-bandwidth way when we work with writing. Or to quote somebody from a little closer to our field, Jay Bolter, who observed in writing space in the early '90s, "even a graphics program does not draw; it writes."
So, hokey religions and ancient weapons. This'll be the last third of the talk. So the Unix philosophy in a nutshell by Doug McElroy(sp?), "write programs that do one thing and do it well." And here, instead of just programs, we could say write web texts, we could say write course websites, we could do all kinds of things, say write things that do one thing and do it well. Write them in such a way to work together, and then write in such a way to handle text streams because those are universal interfaces. Alright? I love Unix because it's such an old operating system that it predates not just the mouse, but the video display terminal. The earliest Unixes worked on a line printer, so they actually, all your output would be printed, or, earlier than that, punched into cards. And for that reason, Unix was a very tight and quiet operating system. You didn't want it spewing out reams of text when everything was fine. You wanted it to just silently be, like, "Cool, bro," and then go on to the next thing. And then it was only when you hit the error that some output followed.
So I have three courses that I want to quickly hit and talk about how some select threshold concepts work through those. The first is my course in standards-based web design. The languages in there, I've already mentioned. The principles are to look at web standards and version control - those are the things I care most about. And in terms of techniques in that class, we do all mobile-first responsive design, and if you don't know what those things are, don't worry. I'm writing a web text for Kairos - which is really late... I think I was supposed, Sorry, Cheryl. No surprise, though. I've never met a deadline I didn't fail to meet. But mobile first design - we start designing for the mobile space, which is awesome because when students look at their little phones, they don't ask me questions like, "How do I have a menu on my site where you hover over it and then another submenu pops up?" You can't really get away with that. And so we have this really tight, lean way of designing websites that they scale really well even up into larger screens. And there's the URL to the latest syllabus, there.
The course that I teach as a follow-up to that is web application development. This is where it gets hard. We do Ruby in there, and the Rails{?} framework, and then Ruby-based, domain-specific languages, including SCSS and Hamill{?} - I have a Hamill slide later. Don't worry, I know you're waiting for it. It's coming - The principles in there is that we deal exclusively with model view controller architecture, and we apply techniques of agile iterative development, so we work with these frameworks and write this code, and it's all web standards still coming out the other end so they build on themselves.
And then, quickly, the last introduction - each of these will get a little deeper treatment in the rest of the talk, but - I'm teaching a course this fall for the first time called application programming interfaces. And my hand was forced, so I'm teaching the whole thing in JavaScript. And for those of you who don't know, JavaScript used to be a language that ran only in the web browser. Well, Google built their Chrome browser and wrote their own JavaScript engine called V8, and some enterprising, open source gurus figured out that they could actually port that V8 JavaScript engine to run on servers, and some other enterprising individuals wrote a framework called NodeJS, which is actually powering these slides. Like the stuff to make it go back and forth is using NodeJS. So there's server-side and client-side JavaScript running on these slides.
So I'm going to try to teach this, and this is like, pushing it as, really, as far as I can. So our principles are going to doing lightweight data serialization in JSun instead of heavy XML stuff, and we're going to look more at restful{?} interfaces, which are representational state trasfer, so that we have this interesting relationship that we build between the browsers that are asking for data and the servers that are serving it up and using a technique of event-driven, non-blocking IO. Here's an English sentence for all that: We're going to take open data sets from government sources and access those things and mash them up, and then the last part of the class is not just consuming APIs, but students will actually be writing APIs for other people to consume. So there's a programming element, but also a documentation element.
So you get the idea of the kind of courses I teach. So, two, and I call them post-hoc because I've been doing a lot of the stuff that these things name, but I didn't have the language for them until I actually read them. So there's The Unix Philosophy, which has 17 principles in it, and The Pragmatic Programmer, which has another 70. So, here we go, 87 principles... get comfortable! No, I'm going to do 5 or 6.
So the first is this idea of modularity. I'm really hung up on this thing. I want stuff that is hot-swappable. In the old days, six years ago, I used to preach the gospel of the LAMP stack, which was Linux, Apache, MySQL, and PHP. That's the thing behind Mediawiki, behind Drupal, behind Wordpress. The problem is is that that all gets very tightly coupled. You really can't throw in, at least easily, an EngineX web server on some of those frameworks. So I want every piece of that. I want my operating system, my web server, my database, and, certainly, my language that I'm writing in, all of those things to be modular so that I can swap things in and out as different computing demands show up. So the Rails class, this blows students' minds, like, we have development environments that get set up for everybody in the lab, and they have access to Linux in there, but they use an embedded database called SQLite3, and then we deploy to a service called Horoku, where we're using another database called Post{?}, which you've probably heard of before.
And what comes of that is that students start to just get comfortable, not with a particular technology, not with a sand trap that says, "Oh, in MySQL, here's how you write a query string." Instead, we abstract up a layer to what's called object-relational mapping, where we can write interfaces to pull and put data, and not worry about the database on the other end, and to swap it out and test things, and see which one we like back/best{?}. Right? That's how we get to the point of being able to judge a tool on its own merits.
Parsimony. This is a big one. Only do big things when it's clear that nothing else will do. I hate giant data. I get freaked out when I'm working on a project that's bigger than I can reasonably put in an email attachment. So whether that's optimizing media or keeping the code base small, I like small, tiny, parsimonious things. You could put this entire slide show, minus the background image because it works for a retina display, but you could put the entire code base for this slide show on one of those old school, 3.5" diskettes, even though there's three different servers that are working to make this powered back and forth. So, low and lightweight stuff, and that's what we do in the JavaScript-based node class this fall, the APIs, is to say, we can write really lean JavaScript. You can write a web server in Node in 7 lines. I'm not saying, like, configure; I'm saying, write a web server that listens for incoming requests, like, "Give me an about page." You can do that in 7 lines of code. This is not massive amounts of stuff.
Ooh. This is a big one. Don't program by coincidence, right? We all love Bob Ross and the happy accident [laughs], but we don't want happy accidents when we're writing. We want students to be at a place where they understand what happened. Even if they come across some happy accident, like in the Rails class when you start some work with models and, say, we're building some kind of social network ourselves, and we have user profiles, and we have a user name, a first name, a last name. You get all these methods so you can say, "User, find all by last name" and then pass(?) to the last name. That "find all by last name" method, you just get. It's there; it's built into the framework based on whatever your model is, and that's fine that it's there, but when students discover it, it needs to be more than just a happy accident. They need to understand that the framework is giving them those tools and enabling them to do that so that when they need to do something different, they're able to.
Alright, this is counter-intuitive based on everything I've said so far: avoid hand hacking, and write programs to write programs when you can. Now, every three weeks, I think, on TechRhet, somebody will come on and say, "I'm just teaching Drupal. I'm not gonna worry about teaching HTML and CSS because everybody's just doing Drupal." Okay. Guess what Drupal puts out? It puts out HTML and CSS, and so again, back to that idea of routing around.
I'm interested in languages that generate other languages that require a deeper literacy, so here's my HAML (?) slide. Hopefully you've got it in front of you 'cause it's impossible to read there. But what HAML lets us do is write a really short-hand HTML, and it plays incredibly well when we're drawing in dynamic data from a database or some other data store, and you don't have to put in closing tags. You just indent, and HAML takes care of the rest, and this makes it so super-easy to do templating, right? I'm working on a book right now that's about a framework called Jekyll, and this is going to be like a meteor hitting the earth. It will destroy WordPress 'cause 95% of the time people choose WordPress for one reason: they want to make it really easy to template out their websites, and if they want to change some global HTML or something, they want to do it one place. That's cool, but we don't need this whole other WordPress ecology that we're buying into. We just need something that we can template really well. And, do it in a domain-specific language like HAML instead of something like PHP which gets all smooshed in there with HTML and it's just this messy thing.
Separate the concerns, right? Modular things. One tool that does one thing well. I don't want to see the same kind of source code building my HTML as is talking to my database. Those are different concerns, and they should be articulated and written in different ways.
Alright. Two more, and then I'm gonna wrap this up. So extensibility – design for the future because it will be here sooner than you think. That's been one of the great things - I've gotten to teach that webstandards class now for almost – I don't know - ten years, i think. I started at Purdue, and - here's a funny story – I started teaching webstandards because I was teaching Flash, and once I got past the moving a circle across the stage to a timeline, I was like, ooh, I want to do some of these whiz-bang Flash sites, and then I found out they were writing all of that stuff in action script, and I was like “I'm not gonna code! I'm gonna go just teach regular web pages. That's easy!” Right? And then that became the slow spiral down the staircase into webstandards.
So I'm a product of not wanting to code, and now that's all I do.
But we want to design for the future, and this was the place. Like, I was teaching Dreamweaver in my classes, and then I was irritated because every fall the office of technology would update Dreamweaver on all the computers, and all of my course materials were obsolete, and that was a pain in the neck. But what kept me up at night was not that. It was all of the students that were in the class that last semester-“Sorry guys, what I taught you doesn't matter anymore because Adobe went and changed the interface.” It's like, is there something more permanent that we can glom on to? Something that's still going to have some truth value to it? And that's my kind of circling down the staircase into webstandards.
But those are extensible skills. Once you get over that initial threshhold of writing to a computer for another human being, it becomes easier to accept that as the mode of discourse everywhere.
Alright. Last threshhold concept- which is to refactor early and refactor often. I don't know how many of you know the verb “refactor,” but it's a good one. It's kind of like revision, but it's different from that. When we refactor a code base, what we want to have happen is the surface of the interface that a user would see, stays pretty constant. We rework the internals so that it's better, faster, easier to read, easier to extend-all of these things- but we don't disrupt the surface. And that's what I have in mind for raising these threshold concepts. How can we take all of the best things that we do in this field but refactor below the surface to come up with pedagogies that are more sustainable, that are thinking about what our students are going to do tomorrow, next week, next semester, next year. And the thing I love the best about refactoring is that we are talking about fixing the root of the problem. It goes back to those sandtraps. It's not like, “How do I get WordPress to stop doing x?” It's “How do I get a smaller constituent difficulty that avoids x or that treats x in a way that's going to work for what I'm trying to accomplish?”
Alright, so what does this look like in terms of professional development? Maybe nothing. All of those threshhold concepts that I listed, if you don't want to program, you don't want to teach it, you think what I do is an abomination against god and nature. We're cool. I used to think my role in the field was to drag the sinners down to the river and stick their heads in the code until they saw the light. But I've gotten beyond that. I've grown up a little bit. Just a little bit. I'm still wearing flip-flops. That's fine. You can still use those heuristics. If you're going to just GUI your way to digital bliss, go for it. But use those things.
Find a tool that's small, find a tool that's parsimonious. Find things that students are going to be able to use and to upgrade on their schedule - not Adobe's, not Microsoft's. Let them make those threshholds themselves. So the first - again - embrace the web as the core platform of writing. We have to do this ourselves. Like, if you want to really get good at web stuff, and you want to teach it to students, you have to stop writing in Microsoft Word for everything. And again, Word violates that "one thing and do it well." Everytime on twitter somebody's like 'Word just crashed, and I lost all my work!' - that should happen one time to one person, and we should all evolve and say, 'Maybe we don't put our best intellectual labors in Word anymore.' Right? I write everything - source code, articles, my next book is all in plain text and goes in different places. And I don't even have to knock on wood. I will not lose a stitch of work. 'Cause not only am I working in that very simple plain-text format, I'm putting everything in version control, and I'm putting it up on Github for the world so other people can archive it - there's an archive someplace else - I don't lose work anymore.
It's too hard to think and to write to let Microsoft screw it up for us. Seems pretty basic.
Alright. Get a Unix. Windows is the outlier. Every iPhone, every android device, every Macintosh computer, every pretty much web server out there is running on some flavor of Unix. It's not that I don't like Windows because Microsoft is the former evil empire, it's just that they're an outlier. You can't get development tools on there. You can't get a decent command-line that uses the POSIX standard for how we have other pieces of code that talk to each other. It's just one of those operating systems - pretty much the last one standing, actually - that prevents crossing the kinds of thresholds I'm talking about.
If you've got a Mac, congratulations, you should still get a Unix. Something else: BSD, Linux, Ubuntu is a good one, Mint is really cool. Talk to me afterwards, I've got more flavors of that. And - it doesn't have to be that you go get a new computer, or you set up dual boot setup or something. I have in bag almost at all times, a Linux that runs on a usb drive. 'Cause I've got a family, an extended family, and they all run Windows, and inevitably something gets screwed up. So I just pop my Unix right into the side, boot it up, fix their problem in Windows, and then they're off and running again.
Alright. Self-enforce the constraint of plain text for everything but image, audio, and video. It's, it's, you know, it's training in the absence of a personal trainer, right? Like, you have to just say, "I'm going to, instead of reaching for Microsoft Word every time I want to write something, I'm going to reach for my text editor."
Learn web standards. I would love it - like, everybody just expects that students know Word. Do you have the day where you teach everybody Word? Maybe. Some places, I've had to do that. I taught a course, sorry, a program, in grad school for Upward Bound, and I had a lot of kids who had never touched a computer before, and we had to talk about how to write with Word.
But, we can swap that out and teach web standards instead and just know that everybody who writes just knows HTML and that if you want to collaborate together, you can do that really simply because everybody's speaking the same language. "Oh, I have Word 2009." "Well, I have Word 2012." "Well, I use Google Docs." That shouldn't matter. We should be able to collaborate - Cheryl can use whatever editor she wants, I can use whichever one I want; we should all be free to modularize our own setups but still be able to talk back and forth.
Version control. This is a big thing. Revision is still the sour spot in digital writing. Because it's really hard. You work to put that WordPress site together, and there's some little thing that's not quite right about it, and you know that if you worked at it another ten hours, you might be able to figure out what it is, but you take this risk of really goofing up the work you did already, and so it doesn't get done. We don't revise. "Good enough" becomes the rule of the day, but that becomes what's called the broken window theory, right? We know this from urban planning. If you want to see a neighborhood go to hell, have a window get broken in the room of a house. Then suddenly, garbage builds up, crime builds up, graffiti builds up, and it turns out it's just that broken window. So we gotta watch out for our broken windows. That was actually another threshold concept that I cut. Alright.
And then, finally, get awesome at an all-purpose language, and my two favorite are Ruby and Python. There are other languages, um, we can talk later about what my qualifying things are for them, but I want them to be able to do a lot of different things. I can write scripts and do write scripts in Ruby and go through all my Git repositories and update them every night just so I don't lose something. But I also use Ruby to write web services that show things to the rest of the world. I'm running Ruby a little gem called SERV to run the slides up here right now. And again, it's that kind of ubiquitous encounter with the technology. That's how you get good at it. You can't just say, "Oh, I'm gonna use Git for this, but everything else is going to have a different set of rules." No, it's - you want to have the same consistency everywhere. And then you don't have to make choices. You just say, "I'm using an editor, I'm using a command line, I'm using Git." I don't even have to think about those things. And that becomes a way to judge other tools. Like, people are really often disappointed. Like yesterday, somebody came up to me, "Hey, have you seen this?" And then they show me some software platform. I have no idea what it is 'cause that's not the kind of way that I operate. I'm really cautious about somebody's all-in-one system that I just have to install because I don't know if I'll be able to work within it.
So that's the point of not keeping up. I don't have to keep up because the stuff that I do, I can apply to any digital rhetorical situation I've encountered yet. And I think I have a foundation to encounter the new ones that are going to happen in the future, but I'm gonna do it at my own pace. You can still write in HTML 4.01 if you want; you don't have to use HTML 5. But when you're ready, it's there for you. When you need to have some backformation thing, you can do that, too.
Finally, I may have been wrong [laughs]. I've said for years that the most important thing for learning technologies and bringing new ones into the classroom requires having a problem that, that you focus on the problem and the technology will follow. And I really think that there is a component of intellectual curiosity that may be more important than having a problem solved. These technologies - all of them, Dreamweaver and everything else - they're wondrous.
The question is again, what thresholds are we crossing? I got to meet one of my nerd heroes a couple weeks ago. He came to Chicago and gave a talk. It's Travis Weistgood(sp?). He wrote the book that everybody should read about using Git. It's called Pragmatic Version Control Using Git. He's a programmer with the Texas Tribune, which is this really cool, data-driven journalist outfit in Texas. He was coming up to talk about some of the scraping they've done. Anyway, we're drinking later, and I was- we were talking about languages and how to do this, and I said, "Yeah, man, 'cause, you know, Erlang is really cool," that's a language, "but I don't think I'd ever use it." And he's like, "Oh, man, but you've gotta check it out." And so, it was, like, yeah, okay, you've gotta check it out. Like, I'll check out Erlang. I don't think I'm gonna have a purpose for it, but maybe I will, 'cause he thought I did. So, that's the happy place, and, granted, I'm post-tenure and hoping (?), to take that intellectual curiosity and go someplace with it.
Thank you. [Applause - Talk ends at 46:03]
Are there any questions? I'll try to repeat the questions if I can hear them myself.
KARL STOLLEY: Yes, (Ben?).
Q1: [mostly indecipherable] ...do well...
KARL STOLLEY: Sure. So the question is, basically, did I contradict myself at the end when I said learn a language like Ruby and Python for everything. The answer is, eh, good ear. Um [laughs], but they are very flexible languages, and so, writing Ruby isn't just writing Ruby. My approach to writing a script that automates some boring work for me is different from my approach to writing a model or a controller in Rails that, you know, just like English. Like we don't have to switch languages between poetry and an essay and fiction, right? We have the same kind of low-level, soupy interface that we can work through. The question is in those individual instances, can you separate them and make them modular? And that's the case in Ruby. So, yeah. But again, be open to languages. I teach a class called Humanizing Technology and we do a book in there that students absolutely hate. It's called Seven Languages in Seven Weeks, except we do seven languages in about four weeks [laughs]. Um, we do Erlang, we do IO, we do Prologue, Ruby, Scala, and I'm forgetting the other two. But we blast through these different languages, and the point is not to learn them, the point is to get over some of these thresholds, to get used to what it is to install an interpreter on your computer so you can run Prologue, which is a fantastic, ancient language from the '70s that is used to solve puzzles. We build stuff so they can solve their grandparents' Sudoku puzzles really fast. It's neat. But we do that to-to kind of have that over-exposure and just get over it, like, yeah, you have to install an interpreter and you have to figure out how to get the repl(sp?) running and all of these other things. Sorry to talk over, other questions?
Yes, Mike?
MIKE ___: Um, I know a lot of folks in this room think that this conference has sometimes a vexed relationship to 4C's but I want you to help me make the connection 'cause I thought your stuff about difficulty was really cool. Mira Elena Salvatore (sp?), with her work on difficulty talks about difficulty as a point of entry into a text or into an act of writing. When a student says, "I'm having difficulty," that means there's something cool going on, either in the book that they're reading or in the paper that they're writing." Um, she talks about the hermeneutic move, struggling to deeply understand something, and the deconstructive move, struggling to take something apart as the two moves of difficulty. How do you apply those to technology?
KARL STOLLEY: Well, that's the interesting thing 'cause we're in a place, if you, okay - so, the question is, like, difficulty is something that's being talked about at the 4C's, and I forget whose name you mentioned, but - and you asked what's the relationship? Well, one, the 4C's is soon gonna be a subdiscipline of us. That's the first thing. Yup. Clap it up, people. If you're not at this conference, if you're not doing this kind of stuff, I don't know what you're doing. Tweet that! [laughs] I'm gonna get fired from the field. Difficulty is really interesting. If you're teaching something like literary deconstruction - that was the example that you raised - you have to teach literary deconstruction. You have to read some Derrida, you have to work with graduate students and have them write these tortured papers. In Computers & Writing, there's an app for that! We take our points of difficulty, and we say, "Oh, we'll just do something quick and easy, like what's a quick and easy way to get a thing up? Right? We have this luxury, and it IS a luxury, to say I'm not gonna deal with the difficulty; I'm just gonna figure out a way to make it simple." But of course, there's always this problem that things are never as simple as they are because we - all of us - we have the opportunity to work with really bright and intelligent students for whom that out-of-the-box, one-size-fits-all solution is not going to match not only their technological ability and sophistication in some cases but their rhetorical savvy. Like, I want to be able to sleep at night because I want my student to have some really great idea about how to reach an audience or how to work collaboratively or whatever it is that we value in rhetoric and be able to realize that thing to the letter in technology. To not take "no" for an answer, right? To be able to route around difficulty, or stupid points of difficulty, like "Port 22 is blocked" - all of you trying to push GitHub commits this week on the wi-fi here. I just looked at that, I like that as a challenge. Like, hotel wi-fi is always blocking weird ports, so I've been working on my slides and doing some stuff with Cheryl, and I just set my computer up at home back in Chicago as a proxy server and I'm just running all my GitHub traffic through there 'cause it turns out Port 5000 and above is not blocked on their network, so boom! I've got a job to do, I want to do it, and I'm not going to take anybody's no or any technology's no for an answer. There's gotta be a different way to do it. And then nerd out and share it with your friends. [laughs]
Claire?
CLAIRE ___: ... particular author, and I wonder what role you see cooperation playing in the future of programming?
KARL STOLLEY: Well, the future's already here. I mean, all you have to do is look at the open source communities that are doing these amazing collaborative efforts. I mean that to me is the thing. Like, we should be paying attention to what's happening on GitHub. You know, why is it that you can have three PhD's in rhetoric working on a Word document together and it is absolute, utter chaos, right? "Oh, well I put my revisions in this file, and I renamed it this," or whatever. How is it that thousands and thousands of people can work on the Unix kernel, like the lizardy part of the brain of the computer - thousands of people, working independently, can do that. They never lose information; they never screw it up. What do they know that we don't about collaboration and working with each other? And so, in some ways, it's those baseline things. Every Unix hacker is running an editor; everybody who's working with a Linux kernel is working with Git because they actually wrote Git specifically for the purpose of tracking the Unix kernel, or the Linux kernel, I'm sorry. So, go around those points where people are using these interesting tools and see what they're doing. I mean, we're trying to get to the point now where we can collaborate - the rhetoric.io project that Cheryl and I are starting, like, yeah, the site's not up yet, but the GitHub repository is there. Go and clone it. Go and hack on it. Like, submit a pull request. Learn how that stuff works. Buddy up with people. It's not easy, and it's really strange, and there's a high degree of being able to - ooh, I almost dropped my first F-bomb - screw it up, but you have to work beyond that. I'm going for a perfect record today, no f-bombs.
Harley, you had a question?
HARLEY: Yeah, I'm curious if you have a means of applying these concepts... black box... multimedia... creating videos... ?
KARL: Yeah, the media thing, that's the sticker, right? Like, yes, there's Gimp; yes, there's Pixelmator (sp?), but PhotoShop is still kind of the gold standard for photo editing. The question is do we just succumb to and say, well, we just have to have PhotoShop, or do we embrace the constraints of whatever photographic and image materials it is that we have and worry about composing that? For me, you know, that's, that's going to continue to be a problem. It's really exciting to see Pixelmator - if you don't know it it's a MacOS alternative to PhotoShop; it's a smaller feature set, it's a lot cheaper, but if you can work within the constraints of your medium, then - or work within the constraints of the software, then, yeah, you can do that. But yeah, images and rich media are hard.
I will say this: Go towards the open formats and open standards, and we, really, as a field, because there's so much fantastic work that's done with video. Dan Anderson's stuff, if you haven't seen it is fantastic. But we want to make sure that when he publishes that stuff on Kairos that he's doing all the videos in a format that it's gonna work in 30 years, and that's, that's the sore point right now 'zause I don't know if you know this, but HTML5 has a video tag. Like, we can do native video in the browsers now. We don't need Flash, although you usually put it as a fall-back. But you can do native video.
The problem in paradise is that video formats are so patent-encumbered that we can't come to an agreement on how to do that, so Firefox and company is using one standard, Chrome is using another one - the H264 that Apple uses, but there's patent issues; people are freaked out on both sides. So the heartbreak right now is if you want to do native video on HTML5 is you basically have to double-up because one browser's looking for one thing, and one's looking for the other. We hear this story again and again.
In the early days of the web, if you were writing HTML in the '90s, you were writing at least two sets of pages: you were writing one for Netscape and one for Internet Explorer and then it became finer-grained from there. Like one for Netscape 3, one for Netscape 3.5, one for Netscape 4 and then all the versions and it just became this huge problem, and that's where web standards come from. It's not a bunch of engineers but rather a bunch of web designers who were like, "You know what? We can't continue to do this, to reproduce an entire website every time a new browser comes out. There needs to be some kind of standard that we can all at least closely enough agree upon that our job of writing becomes easier."
So that's one of those stories that again, you know, as humanists, we are suspicious of technology people, but it was humanists who brought us web standards, not a bunch of tech monkeys. It was people like Jeff S{?} and Molly Holtschlag (sp?) and Andy Clark (sp?) and all these other people. You know, they organized it, and they fixed it. And it's staggering to think about what we could do to influence the development of standards and things. Like, HTML5 has been kind of slurped up into the W3C, but there's this other thing called HTML the living standard, which is trying to get away from version numbers even for HTML and just keep developing the specification on a modular basis - there you go, Ben, there's some more modularity - and as the modules get integrated into browsers, then we're free to use them.
But anybody can join those mailing lists, anybody can respond to their requests for comments, and we can help drive this thing forward. Right? You people that are doing, and I am not among you, I'm just not sophisticated enough for video, but those of you who are writing and doing video stuff, get involved with some of the communities that are doing the, uh, video codecs. That stuff is, it's crucial. I mean, that's the future of your work. That's the question of, you know, is a browser in 2030, integrated into your brain, going to be able to watch that video, or not? And you can talk to Cheryl and talk about some of the problems with code rot on some of the older Kairos submissions. And it's not that those authors were dumb, it's not that they weren't long-sighted. It's that they were working with the technologies that they had at the time, and they were really limited to a particular time and scope. We owe it to those authors to learn from those mistakes and to think about what's this future thing going to be.
Yes, Cheryl?
CHERYL BALL: Uh, you've been talking for a couple years about camps. When does the Karl Stolley summer school start?
KARL STOLLEY: When does Karl Stolley summer school start? I wanna do that. Um, I didn't do it last year. I teach in a lab at IIT. It's all Linux. Um, I run everything myself, all the servers. To power it, I know all the root passwords and nobody else does, so tech people have been really supportive, actually. It's neat. If you start using Linux, you're gonna find some people in your campus IT or your departmental IT who are going to love you. Like, I just had a networking problem in my office, like, shortly after I got to IIT, and, you know, like, there was some switch I was trying to hook up and it wasn't working, and I got to talking to the, you know, IT guy that came in and I was like oh, yeah, I'm running Ubuntu and everything, and he's like, "Oh, do you know we have a connection to the Argon National Laboratory servers on Internet 2 and you can download all the packages really fast?" And I was like, "No, I didn't," and so he's hacking really fast on my computer, changing up the package management files, and now, when I want to update my Linux machines on campus, it takes seconds. It's so awesome! But without that like kind of common nerd, you know, bonding kind of thing, that wouldn't have happened.
I'm far from your question, which is just my way of avoiding it. Um. I want to do it, I'm gonna be looking for help. You know, I want it to be a small kind of thing I want to try to take some of the lessons that Cindy has no doubt learned from running DMAC year after year and figure out, like, what would a programming boot camp look like in Chicago? I've got ideas for how I want to do that. I've been building partnerships with a company called 37Signals. There's some cool people over there, including one of my former graduate students. Um, at the very least, we'll get to get into their space for an event or something like that, but they've got really talented designers and developers who could come and speak and do a better job on a lot of the topics than I could myself, but... yeah. I'll try to put something together. I think that would be fun.
Alright. Thank you all so much.
- Matthew Heston
- Merideth Garcia
- Christina Bethel