Thursday, January 27, 2011
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.
Posted by Derek Mueller at January 27, 2011 9:51 AM
to Writing Center
Derek, I'm interested in this on a variety of levels. I too count my PHP successes with one hand! But more importantly, our writing center is thinking offering more online services, and I'm working with a graduate student whose research revolves around online writing center work. So I'd love to hear more about every part of this project, if you have a moment.
Posted by: cbd at January 27, 2011 11:53 AMSure, Bradley, let's figure out a time to talk about this. We can visit about it by phone, if you'd prefer to (not sure whether you still have it programmed, but my number is 315-708-3940).
I recently had a conversation with one of our grad students who asked whether I had ever set anything like this up for high schools. I haven't. And so we started talking (very speculatively) about why it might be a good idea to bundle this system together and post it somewhere as a customizable UWC system. Sure, it does require hosting and customization, but the general workflow is pretty stable and would be durable for other WCs.
Posted by: Derek at January 27, 2011 12:04 PMGreat, Derek. I have been bad about generalizing and packaging software I've created. That you are considering it is super. There certainly is a need. Heck, you might be able to get a grant from IWCA or something...
We'll talk more soon.
Posted by: cbd at January 27, 2011 12:29 PMHey Derek,
This is very interesting to me in reference our cyber high school! In our school, the students turn everything in electronically to be evaluated. We have approximately 700 students as of right now, and the English department gets completely overloaded with work turned in by the students. We can't crank out the evaluations fast enough!
The students receive credit when they have met a specific number of the state’s proficiencies for the Core Content Expectations in each subject area.
Each project in our school’s database community is directly aligned with specific state mandated proficiencies that the students have the possibility of earning, based on the quality of their submitted work. Depending on the adherence to guidelines and the work’s quality, the students may earn one to a few different proficiencies per project submission.
All our data is entered into separate FileMaker accounts for the students, but they turn the artifacts into our school's server, which is not linked to FileMaker whatsoever.
These distinctions make our evaluation process somewhat complex. In the past couple years, we have tried several different processes for evaluation, turn-in, expert accountability, and many other logistical problems. I think we've made some progress in our system; although, it could still use some improvement. It sounds like you could possibly run into some similar issues/problems. We should chat about this further. I'm not very familiar with some of the processes you're using, so I'd love to learn more!
Yes, let's talk about this. The email form/queue system we've set up at EMU is similar to what we built and what is currently used at Syracuse. Its greatest challenge has to do with capping: we cannot easily predict when drafts will be uploaded. Students tend to use the service close to their deadlines, and academic deadlines tend to fall during the second half of a semester. That this is necessarily uneven causes problems for staffing, since our consultants' hours are x number per week. Were I a more skillful PHP programmer, I would be able to come up with a way to throttle the service based on the number of uploads. Say we reach twenty uploads in a week, the form would *automatically* adjust (e.g., "We are no longer accepting uploads this week.").
Anyway, there is much here to think through, and I am interested in talking about how something like this might work for a high school like the one you work for.
Posted by: Derek at January 28, 2011 10:06 AM