As irony would have it, the piece appeared the same day that Kairos’s technorhetoric.net URL somehow wound up in the hands of one of the many domain brokers that have bots waiting around for domains to expire. Meaning that the URL in the article is bad, as are the many other pages and articles that provide links to the technorhetoric.net domain.

This is unfortunate, and I hope that the Kairos people can somehow secure their domain from the broker who now controls it. But Kairos’s trouble is instructive about the care and feeding of domain names.

As everyone who’s ever bought a domain knows, you don’t really buy a domain–you effectively lease it for a period of time, usually ranging from a year to three years. Fail to renew the domain, and one of those automated brokers will snatch it up.

Now most domain registrars will email you before your domain expires. They want your business. Some will email multiple times. But of course–and I suspect this might have happened with Kairos–you can’t depend on those emails to be sent. A server glitch on the registrar’s end or a spam filter on yours is all it takes to prevent that important reminder from reaching you. (It also goes without saying that you shouldn’t register domains with a school or work email address, which may expire when you graduate or change jobs.)

Besides, the identity you establish on a domain is far too precious a thing to be left to your registrar to remind you to renew.

So do the smart thing, and put your domain expirations on your calendar. And then mark the calendar a month out, too, so that a failed credit card payment or other glitch does not wind up costing you your domain name.

Now I know that out there somewhere Karl Stolley is smiling to himself thinking “If you only used notepad to begin with, she would have known the answer,” and in my head, I am responding equally as snippily saying “If I had used notepad, she would have dropped the class long before she could ask the question.”

So of course I had to respond to Jim. And here is my response:

I very much enjoyed your story, and thanks for thinking of me, Jim. I’d like to be a bit more hospitable and generous in my response than I was in your head, so let me give that a try:

(First off, I’d have dropped, too, if Notepad were the tech–Dreamweaver’s code view, or FOSS tools like Notepad++ (http://notepad-plus.sourceforge.net/) for Windows or Text Wrangler (http://www.barebones.com/products/TextWrangler/) for Mac are better options, simply because they highlight the syntax of XHTML, CSS, and
so on–but also because Notepad chokes on utf-8. But that’s sort of beside the point.)

What I do think is that Bill Hart-Davidson’s work on objects & views vis-a-vis the Web is instructive here. As both writers and readers, we’ve been conditioned to work with a singular view of digital writing–Word has basically one view of a document (OK, and a print view, but it’s basically the same diff as “Normal”); the same can be said of Flash, Premiere, and a whole host of programs.

In other words, in most cases, the author’s composing environment and the reader’s viewing environment are essentially the same. In most cases.

What makes the Web unique, though, is that there are so many different views: different browsers on different operating systems, mobile devices, adaptive technologies–not the mention the ability of some sites, like Facebook and Delicious, to read and re-render particular views of sites through their various share/bookmark functions. Add in available system fonts, internet connection speeds, screen size, resolution, and the number of variations on a view of a Web page quickly spirals beyond any one program’s ability to represent even a fraction of the possible views.

Dreamweaver, particularly in its WYSIWYG mode, encourages authoring in a particular view, one that is basically (but not completely) like a full-on graphical desktop browser. One that is basically like Word or most other digital writing environments. Thus Dreamweaver’s popularity.

And of course, for a lot of people, Dreamweaver’s graphical view is more than adequate to put together a basic web page….just as the dizzying variety of brownie and cake mixes in your local supermarket is more than enough for most people to make baked goods to feed their families and friends.

But the cake mix, like Dreaweaver’s WYSIWYG, is just one view–a limited view–of the cake object. Add oil and an egg, mix, and bake in the oven, basically. Throw some frosting on, if you’d like.

It’s a cake, yes, but aside from knowing how/that one has to measure and add oil and egg, one’s cake literacy is limited by that view. Frosting adds a layer of customization to the cake, but frosting decorates as much as it obscures.

I’m going somewhere with this. I’ve recently been fascinated by a cookbook called Ratio: The Simple Codes Behind the Craft of Everyday Cooking (Michael Ruhlman, Simon & Schuster, 2009). And his cookbook is unlike others that share shelf space at your local bookstore, in that it Ratio is not recipe-oriented, but ingredient- and process-oriented.

For example, rather than just tossing out a cake recipe, Ruhlman shows the ratios of different cakes’ ingredients, e.g.,

Pound Cake:
1 part butter : 1 part sugar : 1 part egg : 1 flour
Sponge Cake:
1 part egg : 1 part sugar : 1 part flour : 1 part butter
Angel Food:
3 parts egg white : 3 parts sugar : 1 part flour

Change up the types of eggs, the kinds of sugar, the type of fat or flour all you’d like. Add additional things to make chocolate, lemon, cinnamon cakes: the underlying ratios hold up. They guide.

What’s also interesting to note is how these ratios relate to one another: sponge and pound cake have the same ratios, but it is a matter of the order of mixing that results in pound rather than sponge; angel food eliminates egg yolks and fat, but has a much higher egg-sugar to flour ratio.

As an exercise, ask students sometime to describe the difference between a Word document, a PDF, and a web page. They often mention software, but are basically unable to express–rhetorically–why one might choose one format over another. (Which is why, I think, we see websites that are a pastiche of Word, PDF, and HTML files.) They are usually as incapable of describing these differences, in other words,
as most recipe-following bakers are at describing the difference between biscuit dough and pie-crust dough.

But what is more interesting and, I promise, to the point of this whole email is that, working from these ratios, a whole universe opens up in terms of baking and cooking, one that is not bound by the recipe (let alone the cake mix), but rather by the underlying *view* of cooking and baking as described by the ratios.

It’s a rhetorical form of cooking: contextualized to diet, personal preference, not to mention the ingredients one might have on hand in ways that recipes or boxed mixes are not.

But–and this is a significant ‘but’–we all have to start from somewhere. I cut my web-design teeth on WYSIWYGs, and it was only after their limitations in representing views of an object (particularly PHP- and MySQL- driven pages, e.g., what you’d confront working with WordPress templates) became too much to try and work around that I gradually, and with more mistakes than you can imagine,
moved into straight-up code-level development.

And that’s perhaps a way in to talk about your experience with your student last night: you *can* use Dreamweaver to make Web pages. Obviously. (Just as you can rely on a Pillsbury brownie mix to make brownies. Obviously.)

The question is not, a la the Code Wars we have on this list from time to time, whether Dreamweaver is better or worse than code, or capable or incapable of supporting the creation of web pages.

Instead, for me the question becomes, what are the literacies that are or aren’t being exposed, interrogated, and developed when one view is favored, or even exclusively used, over another? (Students in my classes write their source by hand, it’s true–but also with a browser or two handy to constantly verify the browser view as they work.)

Put another way, what are the rhetorical, versus the merely technical, benefits of these moments when it’s not a simple matter of Dreamweaver v. Code, but Realizing a Rhetorical Aim v. NOT Realizing a Rhetorical Aim?

So I was crowing last week, on Twitter of course, that rather than have a course-specific hashtag for my grad seminars, we would use hashtags already in use on Twitter already: #techcomm for the Key Concepts in Technical Communication course and #km for the Knowledge Management one.

And I’m still moving forward with that plan, largely to take advantage of the broader discussions of both areas on Twitter. But then I realized that a course-specific hashtag would be useful for course-related or course-specific posts, while the other hashtag would be important for things related to the broader tech comm and knowledge management Tweetstream on Twitter.

Not to mention that neither my students nor I want to pollute the Tweetstreams for #km and #techcomm with things that only have relevance to our mundane business in the course.

So there it is, care of the OR boolean operator on the Twitter search feed: Key Concepts will aggregate #techcomm and (…actually OR…) #com521, and Knowledge Management will aggregate #km and #com542.

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.

Well, the Tweetstream is not really plagued by what I would call jargon. Rather, Twitter users have developed their own shorthand for communicating within Twitter’s hallmark 140-character post limit. (And it is important to note that the conventions I’m listing here have emerged from the community’s broader rhetorical practice, and not as features designed by Twitter the website/service itself.)

Here’s a tweet, or actually a retweet, of mine roughly as it would have appeared in the #CNNfail Tweetstream:

karlstolley RT @timleberecht: How #CNN fail(ed) – screenshots from news sites worldwide http://bit.ly/bqgHN #iranelection #cnnfail #fb

• So, the first item that appears is the username of the person who’s doing the tweeting; no big mystery there.
• Next up is RT, or “retweet,” which is a sort of citation mechanism in Twitter that, among other things, cause tweets to be passed on beyond one’s own immediate group of followers.
• @username, which is the syntax for both referring to and directing messages publicly to another Twitter user, based on her username. In the Tweet above, I’m retweeting a tweet written by @timlebrecht, whose Tweet was just one that I spotted in the Tweetstream.
• Tim also uses a hashtag, #CNN, in the body of his post; hashtags are another Twitter convention and can be used on words in the message (as #CNN is) or at the end (or even the beginning) of a post, as #iranelection and #cnnfail are. I also added the #fb hashtag so that this particular Tweet would update my Facebook status, as is the convention with the Selective Twitter Updates app.
• http://bit.ly/bqgHN, which is the URL that Tim was pointing to; bit.ly is a URL shortening service, like is.gd and tinyurl.com, which keep the URLs short (but which also have problems of their own in terms of long-term viability/accuracy).

Which is all just to say that RT, @username, and #hashtags are nothing more than metadata about the actual content of the post. True, they are visually noisy to newcomers, but such is the nature of new forms of digital expression.

But obviously, even with this explanatory list in mind, there is no shortage of noise on the Tweetstream. My own experience reading it, especially on a stream that was moving as fast as #CNNfail was Sunday night, is that the colorization brought on by hyperlinked hashtags and usernames helps me visually sort through to what I want to read: too many usernames, as in a string of retweets, or too many hashtags lumped at the beginning or end of a tweet, and I’m not likely to read carefully. I’ll look for the black text of tweets that will likely be more informational and, with luck, something that hasn’t been tweeted already.

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.

One technique I have employed in the past for interface comments involved the Pearl Crescent Page Saver extension for Firefox, which generates a PNG image of an entire web page (not just the portion visible in the browser’s viewport). I would then run that PNG image through Acrobat, generating a PDF that I could then use Acrobat’s various commenting features, particularly the sticky notes, to offer comments targeted to different areas of the page.

The problem, of course, was that this method only worked in Firefox. Where I really need this kind of commenting ability is Internet Explorer, which traditionally is the place where CSS layouts and other things fall apart for weird reasons (often easily fixed, though, by passing corrective IE styles through conditional comments).

Enter Protonotes, a web-based service that allows anyone to add sticky notes to a live web page, regardless (as far as I can tell) of the browser they use. Here’s an example with Twitrhet.

All that Protonotes requires is that users register for a free account, and add a couple of JavaScript calls in the head area of their documents (xxxyyyzzz) would be their actual group number assigned by Protonotes:

<!--XHTML-->
<script src="http://www.protonotes.com/js/protonotes.js" type="text/javascript"></script>
<script type="text/javascript">
<!--
var groupnumber="xxxyyyzzz";
-->
</script>

I have gone the extra step on Twitrhet and pushed the body area down in the CSS, so that the whole page is visible even with the Protonotes toolbar expanded:

/*CSS*/
body.protonotes {
  margin-top: 50px; /*Move whole page below Protonotes toolbar*/
}

But the real fun part is throwing in a little PHP and using a variable on the query string (in Twitrhet’s case, ?notes) and only activating the Protonotes code in the presence of that variable:

<?php
/*PHP*/
/*Check to see if notes is set in the $_GET array:*/
if(isset($_GET['notes'])) {?>
<script src="http://www.protonotes.com/js/protonotes.js" type="text/javascript"></script>
<script type="text/javascript">
<!--
var groupnumber="xxxyyyzzz";
-->
</script>
<? } ?>

Then, as an added measure to make that .prototypes class appear on the <body> to make the page drop 50px when Protonotes is active, I add:

/*PHP*/
<body<?php if(isset($_GET['notes'])) { print 'class="protonotes"'; } ?>>

If someone were to use a more secretive or less guessable variable, the Protonotes code could peacefully live on the page, and only be activated when necessary–a significant advantage for students and collaborative teams who’d rather not maintain two copies of their pages, while also enjoying the benefits of commenting through Protonotes.

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.

What I find peculiar and frustrating with citation style guides generally, not just MLA’s, is the extraordinary care that is expected of writers who cite books. The intricacies of citing books within series, or that are publisher imprints, have always left me puzzled and uncertain. Needlessly so (at least for books less than 40 years old), I believe, when there is an internationally recognized standard numbering system for books, ISBN (and its counterpart ISSN for periodicals).

The URL/URI is to the web what the ISBN and ISSN are to books and periodicals. They are absolutely, unambiguously unique both in form and to the resource they identify; only one web page or other web-available artifact can have the address http://www.mla.org/style (for example). That is what makes URLs useful: they are inherently unique and unambiguous (that is why the also find their place as in XML Namespaces). If URLs were not unique, the web would cease to function reliably.

Which brings me back to ISBNs: these have been around since the mid-1960s and are a true international standard. And I have often wondered why they are not used in citation, but instead primarily for commerce. ISBNs, and to a lesser extent ISSNs, could eliminate much of the ambiguity and needless information in book (and periodical) citations. For older or non-mainstream-published books, the additional publication information could be used instead.

Ultimately, though, the MLA’s decision to make URLs optional is a blow to digital information literacy. Not just for researchers writing works cited pages (and their eventual readers), but for those who make and maintain websites of scholarly value. There is no good reason for URLs to be anything less than memorable and shareable in email, on Twitter, and yes, in lists of references.

Sites like tinyurl demonstrate that simple, short, unique URLs are possible (thought: we should have a scholar’s tinyurl with guaranteed link permanence). And projects like WordPress and even the favorite target of some scholars’ ire Wikipedia show that so are simple, unique and human-readable URLs.

Modifications to citation styles should, as the MLA has attempted, make it easier to list sources of information and, more importantly, to help readers to find them. But ease cannot come at the expense of accuracy and removing ambiguity from a citation, which is exactly what happens when the URL is omitted from citations.

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?

With the idea that a more permanent hashtag would help to organize people in our field, #twitrhet was born. I didn’t put a whole lot of thought into the name. I was inspired somewhat by the TechRhet listserv, which had started a “Who are you on Twitter thread?” And I’m also amused by the self-deprecating title of “Twit” for those who use twitter in particular ways. So #twitrhet it was.

Within just a few days of creating the group on TwittGroups.com, the group had more than 100 members. That was great–but I knew it wouldn’t be any more interesting or sustainable than a Facebook group in the long run.

So, over the weekend, I registered the domain for and built twitrhet.org. At the moment, it does nothing more than list the 50 most recent #twitrhet-tagged tweets, the top 10 active Twitrhetors over that 50, and build a word cloud (which needs more improvement) based on the content of those posts.

But that’s still not enough. To make twitrhet.org more sustainable and useful, I have the following plans in the works:

• RSS Feeds. While someone could grab the twitrhet feed from elsewhere, like hashtags.org, mashing it up for convenience (and stability) seems like a good idea. There will also be feeds with the active Twitrhetors, and possibly the word cloud.
• Recursive Hashtag Aggregation. Lots of people are using #twitrhet. Many more are using #cccc09 and will use other conference tags in the future. And some people use both #twitrhet and a conference tag. Building a simple tab-like navigation that pulls in popular hashtags used in addition to #twitrhet will pull in broader streams of tweets, while keeping them visually separate (though perhaps that will have to be rethought). When the hashtag diminishes in popularity, the nav item will disappear, too.
• On-page Responses. Right now, the site lets you read the Tweetstream and respond by clicking on someone’s icon, which opens Twitter with an @ reply. But more than a few people have expressed the desire to be able to respond from Twitrhet itself. AJAX and the Twitter API will make that possible.

I’m continuing to use the WikkaWiki to power my course websites. MediaWiki was a big hit with students in a seminar on Knowledge Management a year ago, but I’ve used the lighter-weight (and easily customizable and standards-compliant) WikkaWiki software since then.

There are a few big things I’ve done in terms of the structure of the courses that are different from past courses of taught. Specifically:

• Putting the major project in the middle of the semester, rather than the end. My students tend to get a weird sense of panic when I’ve had the major project as the final one. They tend to have learned and become capable of much more than they realize around the second- or third-from-last weeks of class, so I’m curious as to how and whether shifting the major project to the middle changes things.
• Adding milestones to the projects, to give students a better sense, week-to-week, of where they should be. I’m a firm believer in large projects that are impressive enough in scope to be significant parts of student portfolios. Large projects also, however, tend to unfold differently for different students. But, in response to evaluations and comments from students, I’ve added some suggestions to help students gauge their week-to-week progress.
• Having in-progress project presentations every week. I don’t know why this hadn’t occurred to me earlier. Most students appear to enjoy the final project presentations. And yet the real benefit of presentations comes earlier than the projecct due date: students are inspired by one another’s work. So this semester, every week a few students will present their in-progress projects.
• Recording my lectures and demonstrations and posting the audio on the course wiki. I did a test run of this in the Information Structure and Retrieval course last semester, although I never posted the audio: running the recorder for three straight hours was a silly choice, and required too much time to listen and edit. I learned my lesson, and stop and start my little R-09 digital recorder more frequently, which breaks the audio up into individual files that are easier to review. And the recordings are meant to work hand in hand with the wiki. Wikis are great for in-class demonstrations of code, as students can go back through the page’s revision history (see, e.g., the list from my demo on XML namepaces from the info structure course). Coupled with audio, which can be played right in the wiki using the Yahoo! Media Player, students can walk back through these pages and pick up points that they might have missed.

I’m always grateful for feedback on my courses. And if anything looks appealing, please feel free to use or link to my materials: As with last semester’s Information Structure and Retrieval and Open Source classes, I’ve licensed all of the material on the course websites under Creative Commons licenses.