Tag: Tools

Sample Project, Notes from the Collaborative Classroom pt 4

Sample Project: Recipes

While the early posts on this topic were discussing the mechanics and workflow of group work, one of the main reasons I wanted to write about this experience, was also to highlight some of the outstanding projects produced by my students.

And so finally…!

The Recipe Project is one of my favorites because it requires really understanding the medium and genre of the documents involved. That understanding comes in the form of two different requirements of this particular project:  1) breaking down all the elements and concepts of recipe documents, and 2) choosing  a different genre and blending them together. Also, groups needed to produce two versions of this document where one focused on an older audience and the other on a younger one. As with all of the projects in the course, my goal is to get my students to see and work beyond conventional concepts of what constitutes a particular type of documents (in this case, a recipe).

Here is a copy of the Recipe Project Prompt.

Before they began the actual project planning files, they were to first decide as a group who their audience was and which recipe they were going to use as well as which type of document they were going to use as the source for the blended document. They prepared a relaxed “presentation” for the class so that we could ask questions and make sure they were all on the same page. In all, there were two areas with which they had difficulty. The first was with the idea of blending documents itself.  For example, the Penguins group decided they wanted to use a recipe for Lenga (beef tongue) since it was the favorite of a group member. However, during that initial class discussion, it was clear that they hadn’t decided on a source type of document; rather, they focused on their audience, but in a general way: for the adults, they would write it more “seriously” and for the younger people, it would be more “fun”. But they were confused when questioned about in what type of format (document) the recipes would show up. To be fair, this was typical during that first discussion. To help, I would ask them about their audience and why they might be wanting to show these people this recipe. That is, I was trying to get them to think about context.

One very clever group, the Hedgehogs, decided that they wanted to use a cake ball recipe in the form of the wedding invitation genre.  While maintaining the parameters of the writing prompt, they went one step further for the younger audience version by also converting the invitation/recipe into a puzzle.

An interesting thing that began to occur later in the semester, was that the groups began to consider their planning forms as part of their finished documents, and began tailoring them to echo the content and style of their finished projects, creating a sort of brand. Here are their Recipe Project Planning Forms they used.

And here are the electronic versions of both the adult and children invitations that they uploaded to Moodle:

Wedding Cake Balls – Adult Invitation

Wedding Cake Balls – Children Invitation

If you read through them, you will notice the group’s extreme attention to the details of their different genres. For example, the numbers were spelled out in the adult version because that is part of the invitation’s formality. Although it was a simple thing, they switch to numeric representation for the children’s version because the numbers would be easier to read, yet the tone, while fun, still helped maintain a sense of formality (as did the font usage–which also changed from adult to children audiences).

While the PDFs make the text easier to read, they do not do the documents justice; please browse through the gallery and enjoy the group’s creative use of form and details:

This slideshow requires JavaScript.

The Recipe Project Report shows how their fellow classmates also responded to such details.

Groups and Group Work, Notes from the Collaborative Classroom pt 2

Groups and Group Work

Group work is difficult no matter the technology or students. On the first day of class, I spend the bulk of the time explaining how and why the class will operate collaboratively for the entire semester. Each semester, there is usually one or two students who decide to drop the class because of this. I freely admit to my classes that in high school, or as an undergraduate in college, I did not enjoy working in groups–mainly, because there was always at least one person who would not participate for one reason or another, thereby making the rest of the group do all the work. Or worse still, I sometimes ended up doing the entire assignment myself with everyone else receiving equal credit. There always seems to be students who, no matter what, won’t participate. And that is a problem with group work.


In an effort to minimize this tendency (lack of participation), I try to push the issue back onto the groups, giving them the authority to “vote a member off the island;” that is, deny a particular group member points on a project for which they did not actually do anything (or only minor things). And the groups’ decision is final; I cannot overrule them. However, before they enact such measures, I do have a few rules in place, such as notifying me about the problem well ahead of time, so that I can give them feedback on how they might resolve such issues. Groups have used this option only a couple of times—the students in question mostly did not object or appeal because they knew they had contributed little or nothing at all. In that case, the “big stick” of grading had very little effect. However, I have noticed that from their evaluations of each others’ group participation, like professors, students have a difficult time, even when upset about the lack of effort from some members, of penalizing a classmate. The typical reason was that they didn’t want to be the “bad guy.”


It may not be obvious, but assigning groups is not as simple as it sounds.

The first few times that I assigned group projects, I let the students decide among themselves in which groups they wanted to be, believing that by being democratic, the students would feel empowered and therefore would be more engaged. I was wrong. Although there were some people who did gain a measure of inspiration by being self-directed, most students’ selection was based on friendships, race, popularity, attractiveness, or just whoever hadn’t yet found a place within a group. This would result in some bonding but more often created a sense of exclusion among members–before projects even started.

To avoid this, I started assigning people to groups myself. At first, I tried the counting off or drawing names methods, but to do this strictly by hand was time-consuming, and really not as random as I would like (for example, seat placement and attendance issues would bias the randomness). So instead, I used Moodle’s Random function within group creation (you can create groups based on on the total number of groups desired or on the number of members desired per group). Since I was often still grading projects after assigning new projects, this meant that within Moodle, people were assigned to multiple groups which also meant I had to use different naming conventions to keep from confusing myself as well as my students. But Moodle’s automated group creation only allows for numeric or alphabetic naming conventions (“Group 01” or “Group A”)–which made it difficult to keep track of when we got beyond the first two projects. I could have recycled those groups by deleting them and then recreating them but I like having the history.

Here’s a snapshot of the number of groups listed towards the end of the semester:

Groupings Overview


The problem with Groups within Moodle is that it creates them at the class level rather than at the assignment level. It would be handy, if on the assignment creation page, there were an option to create groups on that level. This would alleviate the need to use different naming conventions; that is, I could just stick with “Group 01”, etc. But the different conventions proved an adequate workaround.

So instead of recycling (deleting and recreating) the group names, I began using Moodle’s random group creation as a starting point only, so as to get a rough draft assignment for everyone. I would then copy and paste those groups and members into a spreadsheet and then manually adjust the assignments. I then went back to Moodle to manually create the groups using such group naming conventions as animal names or comic book titles (Alpacas, The Defenders, etc.), making the assignments based on my spreadsheet. It took time to ensure that group members hadn’t previously worked together (though this was almost impossible by the last couple of projects). This mixed solution had the added benefit of helping me sometimes find “better” fits for some group members whom I thought would benefit more by working with other students in particular.

Overall, I thought working with new people mimicked how real world jobs work. We typically don’t get to choose who our team members are and so learning how to navigate such group politics and issues while working towards a common goal is invaluable. Also, it continually helped teach the valuing of assessing people’s skills and knowledge at the outset and applying that information to the project at hand. And perhaps more importantly in terms of college, it helped connect people who otherwise may have never had the opportunity of meeting one another. One of the most rewarding things about such a class is receiving an email from a former student who happens to mention still being in contact with former group-mates.


So what makes a good group size? I’ve tried from 2 to 6 members early on. 2 member groups are too small–if one person was sick or decided to drop the course or just plain wasn’t working, that meant that the other person had to bear the responsibility for the entire project alone. 5 and 6 member groups are too large–mainly from a logistic perspective; that is, although I made some class time available for the groups to work on their projects, the majority of the work was done outside the classroom; accomodating that many different class and work schedules can be very difficult. I found that 3-4 people sized groups is the sweet spot (though depending on the project, even 4 can be a little too much to divide the  responsibilities). This allowed groups to recover from for the absence of a member, added the brainstorming power of divergent perspectives, and perhaps more importantly, an provided the opportunity for an equitable division of labor.


As I mentioned, most group work was done outside of the classroom. To get groups to thinking about potential challenges, we discussed the pros and cons of face-to-face meetings as well as synchronous and asynchronous technological tools (email, texting, video conferencing, phone calls, etc). Some groups always met face-to-face (like at the library), and some groups tried using only email. The most seemingly productive groups tended to use a combination of face-to-face meetings and distance communication tools. These groups typically began with a face-t0-face meeting, brainstorming on a project goal and developing a temporary plan and schedule. They would use this plan to set up dates/times and methods of communication. I also I created Moodle forums for each group that were only visible to their members. However, almost no groups ever used them (and even then, only initially), though this did vary from semester to semester.


For assignments, I required that in addition to one hard-copy being turned in, each group member uploaded digital files to Moodle.  They had to turn in the same copy; I had each member turn in a separate copy for accounting reasons. Although Moodle lets you filter the class by groups on its grading page, I want to be sure I was working with the correct people–and, it also was another way to encourage member participation by making their accountability very visible (if they were not doing the work, it would be highly unlikely that the other members would share their files).

About those “Digital files”:  since Microsoft Office was freely available on campus computers in the library and various labs, and since I also have my own copy of that produce, I stipulated that the file formats had to be in one of the Office file formats (such as .docx) or .rtf (rich text format). But I did not want to limit students to a particular software package, so I also allowed for any program that could save or print to a .pdf file. And in the case where some projects were more of a physical nature (the Packaging project, for example), they could take digital pictures and upload those to Moodle. Typically, most projects were created digitally, but I also felt it was helpful to see hard copy manifestations of it (again, such as the Packaging Project).  This also meant that I did not teach any particular program, although I would demonstrate useful tips and tricks within Word or other tools. I posted links to different applications as I came across them on the web (such as Prezi.com). I also encouraged students to share their discoveries with the class as well. One such application that a group used one semester was pixlr.com–a Photoshop-like web application. Although I did not teach any particular application, students were free to ask me for help and we would learn together. I enjoyed those moments because it demonstrated that you don’t have to be a “guru” to learn a new tool–just a willingness to play.

One issue where technology was a problem for the groups was with operating system/software compatibility. Usually, this was in the form of some members using Apple laptops while others used Windows. Most of the time, they could save to one another’s format (i.e. Office for Mac) but even then, there were minor changes in formatting that would occur. This was a problem usually for the presentation part of the project (I had a projector but no Mac adapter)–and those formatting issues could really hurt evaluations (so we had to be sure to acknowledge those issues during the presentations).

In the next post, I’ll discuss the evaluation (grading) and mechanics of the projects:  Pt 3.