What is the Parachut<e>?
This semester, the Director and Assistant Director of the Writing and Communication Program here at Georgia Tech approved a pilot program for a learning technology that I have been helping to design and build for the last several years. <emma> is a learning management system that was developed, designed, and built by writing instructors for the writing-intensive classroom. It is used program-wide in the First-Year Composition Program at the University of Georgia, where I completed my PhD and first became involved in the project, and <emma> has gradually been making inroads into English and humanities classrooms at UGA and into other FYC programs around the country. Motivated in part by the work I’ve been doing in my FYC classes at Tech, <emma> development has started to turn toward making the environment more suitable for multimodal composition pedagogy that also emphasizes some of the core principals that have motivated the <emma> project from the outset: process- and project-oriented assignment design, portfolio-based assessment, and a writing classroom centered around student-generated content. The pilot will hopefully give the development team some insight regarding whether <emma> is ready for multimodal writing and communication, and what further development might help to optimize it for that purpose.
Nine brave piloteers volunteered to take the leap with me this semester. In an effort to make the introduction of new technology as productive as possible for everyone, especially the students, I have been writing-up tips of the day that offer advice about how to deal with issues that piloteers may be confronting at a given point in the semester. The idea here is that because I am using the technology myself, I can hopefully offer support when it is relevant and before a “crisis” prompts a request for help. Since I am already doing the work, I figured that I might as well turn what I consider to be the most valuable tip of the week into a weekly TECHStyle column, a Parachut<e>, if you will, for the piloteers.
This week’s tip summarizes some of the advice I’ve offered recently about managing one’s grading or marking workflow in <emma>.
How do I control access so that students can’t see marked work until I’m done marking?
One of the newest tools that <emma> offers is an in-browser WYSIWYG editor. Students can use the in-browser editor to create eDocs, which can be traditional essays or multimodal documents that contain links to external sites, or embedded images or video. Instructors grade or mark eDocs by saving the student-generated document as a new version and offering comments, inserting a grading rubric, and marking-up text with specialized tag sets. One piloting instructor recently asked how to control access to marked eDocs until she was done with grading the entire batch.
Step One: Use SaveAs to make the copies that will be graded or marked.
First, in Manage Course, use the Set Default Project tool to set the project you’ll be marking as the default. This will save you quite a few mouse-clicks in the long run.
Once you’ve set the default, in Projects in the relevant class on <emma> pull up a list of the student eDocs with which you will be working by selecting the appropriate Stage and Project.
Open the first eDoc by clicking on its title, then click SaveAs. Make sure to give the new eDoc a title that clearly identifies the original author, e.g., “Lastname with comments.” Make sure to select NA for the original author and set the access to Private; this will ensure that the eDoc won’t be available to the student until you are ready to release it:
When <emma> pulls the new document up in the editor window, you can take this opportunity to insert a rubric or other relevant content that you’ll be using to provide feedback on all the documents (Next week’s post will offer some advice about how to use templates to save you some time in this regard). Once you’re done, click Submit.
Repeat this process for each eDoc until you have a list of artifacts ready for grading or marking. Once you get going, the process goes pretty quickly and doesn’t take any longer than downloading, opening, and saving copies of artifacts submitted via T-Square.
Step Two: Grade or mark away!
That’s it. I have a lot of theories about how to do this most effectively, but that’s the subject of another post.
Step Three: Release the graded or marked artifacts.
Once you’re done, your default My Documents view in Projects will be a list of graded/marked eDocs. Starting with the first eDoc, click the “+” sign next to the title to open the Doc Tools menu. Select Update Details, and then select the original author, named in the title you gave the eDoc in Step One, as the original author of a commented document:
Go down the list, repeating this process for each eDoc in the list, and you’re done. Again, the process goes quickly once you get going, and in this regard, I’ve found <emma> is much zippier than T-Square.
Do you have any tips, tricks, or suggestions?
This is how I manage things when I’m working with eDocs. If it seems a little counter-intuitive and kludgy, it’s probably because eDocs is a stable tool, but one that is still a work in progress. I’d appreciate hearing your thoughts on how to improve the functionality of eDocs, ways to work more efficiently with the tool we have now, problems that you may have encountered while grading or marking in <emma> eDocs, or anything else you can think of.