Coding the UWC

I’m not the nimblest programmer, and because I can count my successes with PHP on one hand, I feel compelled to document them, to extend and preserve them through self-congratulatory accounts like this one.

I am working this semester as a faculty consultant to the University Writing Center. I probably mentioned that before. Basically, my charge is to get online consulting systems up and running at EMU, provide a few months of support and training, and spread the word. The main piece here is asynchronous consulting via email. Much like what we built at Syracuse, this process relies on a form. The student fills it out, uploads an attachment, submits it. The submission calls a PHP script, which in turn displays a You did it! message, a readout of the form data fed to the screen (for saving, for verification), and an email message that routes the form data and the attachment to a listserv. The listserv consists of a handful of subscribers who will comment and send back the uploadeds in turn, in time.

The system works reasonably well, but managing the queue can become a headache. Whose turn is it? At Syracuse, the queue was filled in with four or five rotations, and then as form-fed drafts arrived, consultants would access a shared Google Spreadsheet and manually enter a few vital details: name, email address, time received, time returned, and turnaround (time returned minus time received). These few crumbs of data were helpful, but many of the trackable-sortable pieces of the form were not otherwise captured systematically.

Until Zend Gdata. With this installed, it’s now possible to run a second PHP process that will push all of the form data into a shared Google Spreadsheet automatically. I puzzled over this on Friday, figured it out on Saturday. My initial stumble was that I was trying to integrate the new PHP code into the script that turned out the email and screen readout. Didn’t work. But then I figured out that I could instead route the form to a relay file (I doubt this is what programmers would call it, but I don’t have the vocabulary to name it anything else). The relay file was something like simple.php.

Simple.php is a script with a couple of lines: include formemail.php and include formtospreadsheet.php. Now, when the form gets submitted, both scripts run. The email routes the document like it should, and the Google Spreadsheet (queue) grabs a new line of data. The only element requiring manual entry is the time the consultant returned the commented draft. The shared spreadsheet does everything else: calls the list of consultant names from another page, calculates the turnaround, and records a comprehensive record of who is using the service, the classes they come from, etc. Over time, the comprehensive record will allow us to sort by different classes, different faculty, different colleges, which will help us identify patterns that might prove insightful for how writing is assigned and taught across the curriculum.

I should add that our recent launch of the service limits it to four targeted programs. This is necessary because we are not currently staffed to handle a deluge of submissions, and while we do want the service to get solidly off the ground this semester, we want foremost to extend it to a segment of the 17,000 students who are enrolled in some sort of online class.

PHPinally

We’re experimenting in the WC this semester with consultation by
discontinuous email
. Students can upload up to five pages of whatever they
are working on, the draft then zigs and zags (taking two lefts and then a
right?) through the internet to a listserv account where five always-on
consultants take turns commenting and returning drafts, usually within 24 hours
after the draft is sent. The system seemed to be working fine until recently
when we realized a flaw in the design of the upload form. Basically, the
form allows students to 1.) upload a file or 2.) copy and paste a chunk of text
into the form. ‘Submit’ The form then calls up a PHP script, which, when
there is an uploaded file, puts the file in a temporary directory, builds the
email message to the listserv, attaches the file, sends the email to the
listserv, and finally clears the file from the temporary directory. That much
seemed to be working fine for, oh, ten weeks, and we have 45 such consultations
to show for it. But:

Continue reading →

Manovich – The Language of New Media (2001)

Notes on Lev Manovich’s The
Language of New Media
(2001). In the prologue, Manovich gives us what he
calls a Vertov Dataset–full-passage selections from elsewhere in the book
matched up with frames from Vertov.   It’s a distinctive and memorable
way to open onto the project–self-sampling and re-associating, which emphasizes
(paradoxically?) the relational and modular qualities of new media objects, the
intertwined historical-theoretical trajectories of cinema and computing that now
constitute new media, the logics of selection, association and assemblage
driving new media, and the evolving lexicon of new media, from database, loops
and micronarratives to transcoding, [var]-montage and the tele-
It’s all in the Vertov Dataset, then explained more fully elsewhere. 

Continue reading →

Genre Sirc-umvention

We have evolved a very limited notion of academic writing (or any genre,
really).  Our texts are conventional in every sense of the word; they write
themselves. They are almost wholly determined by the texts that have gone
before; a radical break from the conventions of a form or genre (and I’m not
speaking here about the academic convention of the smug, sanctioned
transgression, e.g. Jane Tompkins) would perplex–how is that history writing? 
what community group would need that for its newsletter?  how is that going
to help you get a job? A Happenings spirit would begin at the point of Elbow’s
"life is long and college is short" queasiness with academic writing
("Reflections on Academic Discourse" 136). (10)

A-la Geoff Sirc’s English Composition as a Happening.