Posts tagged management
One of my responsibilities at Jewish Day School is to write a weekly “tech tips” column for the online faculty news. This is one such tip. This one is, perhaps, particularly our-setup-specific (My Classes, Handins, Returns, etc.), but I think that the core ideas are worth sharing to the world.
One of the real challenges that we confront when teaching in a digital classroom is that there are a tremendous number of documents, spread across a tremendous number of computers, often in tremendously varying states of completion. A team of faculty is coalescing around digital portfolios this spring, and file management is the single greatest challenge that we’re looking at initially.
With that in mind, it seems timely to suggest some best practices for working with files in the My Classes folder on FirstClass:
- Email attachments hurt. If students are turning in their work an email attachments, it counts against their disk quota (which is pretty slim by this point in the year). And you have to open each and every single message to download the attachment so that you can read it. That’s a recipe for frustration. Instead, have your students upload their files directly to the Handins folder — they can just drag them from their computer desktop into the FirstClass folder (or choose Upload… from the File menu in FirstClass). Files in the My Classes folder do not count against anyone’s disk quota. The best part: you can now select a group of files in your Handins folder and drag them to your computer desktop to download all of them all at once (no more opening every individual email).
- File names matter. Ask your students to include both the name of the assignment and their name in the name of the file that they’re uploading. If the students don’t put their name on their files, it’s a hassle to figure out who turned in what. And likewise, if they don’t put the assignment on the file, you’ve got to open the file to find out. The file names don’t need to be Homeric epics: “Feb. 18 Essay – Seth B.doc” works great as a file name.
- Students can’t cheat from the Handins folder. They aren’t able to open other people’s work (or even their own), nor can they remove their work once it’s turned in (so no coming back with an “improved” version after the fact). In fact, the only person who can open the files in the Handins folder is… the teacher.
- Students need to be told about the Returns folder. Every class has a Returns folder that has an individual folder for each student in the class. You can drag files you are returning to those students directly into those folders (from, say, your computer desktop). Only the student whose folder it is can open the folder and read the files (and they can’t change them). Plus, now you don’t have student files cluttering up your inbox and counting against your disk quota as email attachments!
- Be clear, but firm. You’re teaching technical skills, and your students won’t get it right at first. Help them to turn in their files correctly (i.e. in a way that is easy for you to work with), rather than fixing their mistakes. Every mistake you fix will end up being a mistake you have to fix every time.
Obviously, the list goes on, but these five best practices should help cut through some of the chaos and confusion accompanied by the proliferation of documents produced by a digital classroom!
This post is part of a series that are components of my “Expert Plan” at my school, looking to create a shared resource for my colleagues as the school moves towards greater adoption of laptops and technology in our pedagogy.
This is actually a classic use of wikis — the one for which they were developed, in fact — and one that I have found very useful in the past. By documenting my work on a project in a public, shared space, I am both sharing information that needs to be known and inviting other participants to contribute their knowledge as well. I use wikis both for shared projects with my colleagues (as a way to guarantee that only the most current documentation is available, rather than distributing instantly out-dated paper handouts) and as a way of pushing my students to document their own work so that I can grade them on process. Additionally, wikis are a way for me to document my own thought process for both professional development and future planning purposes.
Shared Projects with Colleagues
I have found that many of my colleagues (both at [my current school] and [at previous schools]) are hesitant to edit existing documents. The most reliable contribution that I have found my colleagues make is on meeting minutes, when I invite those who did not attend a meeting to insert their contributions to the meeting as comments on the page.
When working on a project with a similarly technically-inclined colleague (say, in the Education Technology department), the process is more likely to be more collaborative, as we edit each other’s work more liberally (although even this is not a guarantee).
Student Documentation of Process
Students don’t document their working voluntarily. I have only had success in asking students to document their work when I have both assigned the documentation for a grade (usually a grade separate from the end product of their work, so that I can distinguish between process and outcome not just in narratives but also in my gradebook).
The closest that I have come to developing a true classroom culture of collaborative documentation was last spring at [my previous school] in my Application Design classroom. In this case, I worked with the students to help them select and design an open-ended project for which they had to do immense amounts of research (they were creating a computer-controlled CNC lathe). I found that there was an inverse relationship between the amount of expertise that I demonstrated and the amount of work and thought that my students contributed: when they could rely on me for answers, they were lazy about documenting their work and finding their own solutions. When I professed no knowledge (often truthfully), students were far more likely to both do much more exhaustive research and to present their findings more clearly.
One challenge of creating a truly collaborative wiki environment (whether with colleagues or with students) is to get all of the participants to read, respond, revise and/or react to each other’s contributions. For example, I am doing a miserable job, on this page, of linking to the work of others in the Laptop Leaders program. I suspect that a major part of this is simply the “drinking from the fire hose” feeling incurred by the stream of data as everyone contributes simultaneously. In a classroom, I have had some success dividing students into groups around a shared research interest. To that end, I need to sift through the other Laptop Leader documentation that refers to, say wikis.
At the basic level, my sense is that wikis represent such a shocking change in paradigm for how the web is used that the average user is either befuddled or intimidated by them. I found that I was explaining how wikis work to my classes and the students were fascinated and mildly horrified at both the ease with which they could make changes and the ease with which I could track their use of the wiki. I don’t know for certain, but I wonder if my colleague’s reluctance to update wikis is a combination of fear of the unfamiliar (editing the wiki) and fear of speaking out (publishing their words/ideas to a broader arena in a way that feels more permanent than, say, an email — more on par with a faculty meeting).
As we steam towards the end of the year here, I’m watching my next few weeks and, in fact, my summer start to disappear under encroaching project creep. Not that I object too much: most of the projects are pretty cool — in fact, some of them are projects that I’ve been dying to find time to work on during the school year.
I’m painfully aware of my propensity to put off inordinate amounts of work for my next medium-sized chunk of free time. My canonical example is the year in college that I put off about a dozen errands until my Thanksgiving break. Boy howdy, was it ever a rude awakening to realize that Thanksgiving break is only about three or four extra days on the weekend, and probably at least two to four of those days are chock full of commitments to family and friends. Not so much time.
With that in mind, I was fascinated by Steve Pavlina’s article on calculating your fudge factor: that ineffable amount that your horseback estimate of the time necessary for a project is off from reality. My fudge factor is approaching 1.0 for things like driving time — and has been for years. But for coding projects and curriculum development, it might be closer to 3-10 (as in, it takes me 3 to 10 times as long as I plan for).
I’m not convinced that I have Steve’s discipline, but I rather suspect that I can use old data to get some sense of how off I usually am in my time estimates. I have surely made lots of promises archived in my email and then documented my progress (and extensions) in that same medium. Sounds like an interesting project to work on this summer…
Although building an intelligent project monitor that used heuristics to identify project commitments and updates in my incoming and outgoing email and automatically calculated the fudge factor… Now, that could keep me off the street for days at a time. Or weeks. Depends on what my fudge factor is.