Dr Karl Stolley

A number of people have expressed interest in having a collection of everything that was Tweeted at Computers and Writing 2009 with the #cw09 hashtag. However, because there were more than 1500 Tweets from the conference (!), it is not possible for any one person to archive all of the Tweets.

If we are going to have such an archive, it will take a community effort. And fast–we have less than a day or two to do this.

First, here’s what you should do (I’ll explain why next): go to your favorite, feed-enabled Web browser and enter this URL, replacing USERNAME with your Twitter username and PAGE with a number starting with 1 and increasing it by one until you no longer have any results left:

http://search.twitter.com/search.atom?q=%23cw09&rpp=100&from=USERNAME&page=PAGE

Each time you run this query, right-click and choose View Page Source; in a good browser, you will see the raw XML (and not the styled HTML page that browsers like Safari and Firefox generate for RSS). Your ATOM/RSS will look something like this (my most recent 100 #cw09 tweets).

Copy that entire chunk of source by right-clicking and choosing Select All, and paste it into a good text editor: either WordPad on Windows (*not* Notepad) or TextEdit on Mac. (In TextEdit, choose Format > Make Plain Text if it’s trying to save as RTF.)

Save the file as like username-cw09-page-1.rss.txt for the first page, username-cw09-page-2.rss.txt for the second page, and so on. Because of the way XML works, do not paste all of your results into a single file; keep a separate file for each time you up the page number in the URL.

We’ll have to figure out as a community where to share and post these files, and how to (eventually) get them into a searchable, sharable database as an SQL file. But for now, just be sure to grab your Tweets, save them, and keep them safe.

The reason this is necessary is that Twitter will only return 1500 results for a given search (like #cw09), and it will only return results that are less than roughly a week old. So that’s why we have to do this individually, and do it fast. After sometime on Thursday of this week, the Tweets from during the conference will rapidly begin to disappear from the searchable Tweet stream.

4 comments.

Like any good or even mediocre academic, I have a mile-long list of plans and projects for the summer. But here are some of the non-negotiable items.

Topping the list is my book on web writing and design, the manuscript for which is due to my editor at Greenwood Press in 155 days (thanks, iPhone countdown app). I got a lot of writing done on it during spring semester and that, combined with my notes and lessons from my spring web design course, has me pretty far along in the writing. Not as far as I’d like to be, though.

Then there’s a book chapter due on the 15th of June for an edited collection; my contribution is a bibliographic review on free and open-source software research in the areas of education and e-learning. I’m surveying only the last 5 years or so, but casting a wide net in terms of the journals and fields of endeavor that I’m hoping to include. This article should also go towards a course offered at IIT on instructional design, which I’m hoping to teach in the near future.

My Computers and Writing 2009 presentation on activity theory and source-level literacy is drafted, as is a very rough article based on it (but which needs a lot of work). I presented both at the IIT Humanities Colloquium back in April, and that feedback from my colleagues has helped me to see how to improve the presentation, and also how the article itself is struggling to hold together because it’s really at least two different articles trying to be one.

There are also courses that need planning, including some revisions to my Knowledge Management seminar based on past evaluations and my own notes and revamping a course called Key Concepts in Technical Communication, which is an overview of the research and methods of tech comm for our PhD students.

I’ve also set out a few new technology development goals for myself this summer; the first I’ve already about completed: learning to use the git version control system. I still need to teach myself to setup a custom git server using gitosis and Gitweb. (Yes, I could use a hosted solution like Github, but I have a mix of public and protected projects plus a brand-new server just waiting to host this kind of thing.) I’m also planning to learn Ruby and Ruby on Rails to a level where I can teach them, for a course on Web application development that I’ll be pitching for spring semester 2010.

And finally, I am consolidating all of my digital files and archives, and my vita and portfolio, from across far too many computers…but that’s the subject of a whole post all its own.

Write the first comment.

As of the seventh edition of the MLA Handbook, “the MLA no longer recommends the inclusion of URLs in the works-cited-list entries for Web publications.”

The logic behind this is that URLs are often long and unwieldy (ironically, the worst offenders in this department are often major bibliographic indexes and article repositories, not to mention the mile-longers offered up by Amazon.com), and that retyping URLs is not nearly as efficient as simply Googling for the author and title of a work. (On this second point, I agree; but as I suggest below, omitting URLs is not the solution.)

There are two significant flaws with this logic.

The first is that the MLA seems to be imagining a web governed by restrictive copyright, one that is free from Creative Commons and other forms of permissive content licensing. Only in a locked-down copyright scenario does the assumption hold that a given document on the web would have one single, solitary location–not to mention one single, solitary version. In reality, neither is true: not only because of Creative Commons licensing (which leading web-available scholarly journals such as Kairos and First Monday openly encourage their authors to use), but also because of RSS feeds, JSON, and other modes of content syndication that make one piece of content easily published in multiple locations. Add to this sites like the World Wide Consortium that explicitly and meticulously version all of their pages, and the “Just Google it!” idea behind omitting URLs quickly reveals its limits.

The second flaw in the MLA’s logic is that it misses the entire point of URLs (or more generally URI: Uniform Resource Identifier) on the web. URLs are the only means for reliably referring to a particular item on the web and other parts of the internet. URLs are also the only means for accessing pages stored in the Internet Archive’s Wayback Machine, which is an essential scholarly tool. I cannot say how many times I have read articles, particularly in the fields of computers and writing and digital humanities, that cited now-defunct websites and web pages, only to find them via Wayback. Without a URL/URI in those articles’ lists of references, this type of crucial digital archive reading would be impossible. And while one could argue that Wayback needs a text search, it would reveal the same problems of uniqueness in referring to live pages. Read the rest of this entry.

10 comments.

Clay Spinuzzi has probably the best description of the value of Twitter that I’ve read, something that he calls the “ambient status” that emerges from ones collected followers:

I get a sense of the trends in the fields in which I work, but also the well-being of my contacts. I see when they’re engaging in activities similar to mine. I can tell when they’re struggling with particular issues. I can get a sense of what they’re reading, writing, and studying.

The problem is that Twitter does not make it terribly easy to find other people, at least in its basic, twitter.com-based form. If someone’s not using their full name or an email address that you know, finding that person is next to impossible. And finding people generally is either pure luck or the haphazard function of sites like twollow.com, which sets your account to automatically follow someone if they tweet a word from a list of keywords that you specify.

But other means of self-organizing around Twitter are emerging, such as TwittGroups.com, which helps establish membership lists and, more importantly, a shared hashtag for the group. (Hashtags are nothing more than a hash, #, followed by a word or acronym; hashtags.org is a key site that aggregates hashtags.)

The people I follow on Twitter who are also a part of rhetoric, composition, writing, technical communication, and so on, tend to use conference-based hashtags. But it occurred to me that what we really needed was a shared hashtag that could be used all of the time, apart from conferences. In the rhetoric and writing community, #cccc09 is in wide use because of the conference is going on now.

But what happens next week? Read the rest of this entry.

Write the first comment.

Sometimes, the most difficult thing about teaching digital writing and communication is the problem of choosing (or not) software, particularly those software packages believed by students and/or faculty to be industry standards.

Even without unpacking the loaded label of “industry-standard,” a no-win situation develops for instructors planning courses that necessarily involve software: On the one hand, students typically expect to learn about brand-name, industry-standard software. In tech comm, some students believe brand-name software proficiency to be the hallmark of a marketable technical communicator. Employers seem to think this, too, as suggested by the now long-standing practice of specifying software in job ads, and job applicants listing software skills on their resumes; or rather, listing software titles on resumes.

On the other hand, students also expect to be able to work from home, and to work cheaply. Tuition is costly enough without tossing a thousand-dollar piece of software onto a syllabus’s “Required Materials” list–particularly for software that has little or no use value outside the enterprise. That, of course, is precisely the problem with expensive, proprietary enterprise-level software.

My position is that using a particular software package ought to be about as big of a concern to technical communicators (and their employers) as learning to drive a particular make and model of a car is to driver education. Learning to drive in a Buick doesn’t mean one cannot safely drive a Toyota or a Bentley. The controls may be in slightly different locations; the vehicle may even handle very differently. But the driver’s ability to drive, after a period of relatively painless adjustment, remains constant.
Read the rest of this entry.

2 comments.