Thinking-Man-RodinEarlier in the week, I wrote about an activity I did in class using a web application I was working on. For a first attempt, it went pretty well. There were, however, some issues that prompted me to make some revisions to the activity.

I thought I’d do a little thinking out loud to explain what I changed and why. Ultimately, documenting these revisions and their justifications will help improve the design of the final activity. You can see the current demo version of the app here. To review, the basic idea is that students need to reconstruct an essay from a bunch of jumbled sentences, sorting them from the pile on the right into paragraphs on the left.

Problem: What Goes in the Introduction? One of the first problems that became immediately apparent was that it’s tough to distinguish what goes in the introduction and what goes in the body. Some statements could easily fit into the introduction, a body paragraph, or the conclusion. I hadn’t really considered this, and the first iteration of the activity dumped the entire essay into one pool of sentences to shuffle.

This was a simple fix. I separated out the introduction and the conclusion. I shuffled those paragraphs, but I didn’t mix them with the body paragraphs. This had the desired effect in subsequent uses of the activity. Students sorted out the introduction fairly quickly, and then they spent the bulk of their time trying to sort through the body paragraphs.

Problem: It’s Overwhelming. Some students complained that it was a lot and that it was overwhelming. Partially, this problem was addressed by separating out the introduction and conclusion. However, this could be further remedied with some form of scaffolding. For example, one or two sentences could be pre-sorted into each body paragraph.

This would give students a head start, help them establish topics for the body paragraphs, and cut down on the number of statements in the right-hand column. I’m unsure if I’d want to do this for everyone, but it might be useful as a modification for weaker readers or students who have a less firm grasp on the content.

Problem: Everyone’s Paper Looks the Same. I asked the students to print out what their essays looked like at the end of the period. This would let me check it off for a classwork grade, and they could then keep it in their notebooks as a model.

Unfortunately, I didn’t foresee that everyone’s paper would look pretty similar. By the end, they’d all have the introduction done (looking identical), and most of them would have gotten similar results for the body. This made it a bit confusing when students started printing things out, and they couldn’t tell who’s paper was whose in the printer.

To fix this, I made another revision and added an input box for students to write their names. Once the students type in their names, they’ll appear at the top of the print out and make it much easier to identify who each paper belongs to.

Problem: Can We Save It? What if students don’t have enough time to finish it in class? Can they save it and keep going at home? It would be nice, but this presents a lot more technical barriers. It’s certainly possible, but it would require a database. Another design decision would be whether the activity would auto-save each time a student moved something, or if you would need to press a “Save” button.

I opted to skip this problem for now, since it would make developing similar activities much more time consuming. The temporary solution I came up with was to have students print their progress out and take it home. This would give them a blueprint to reconstruct what they’d done and then continue it. It’s not perfect, but it works…

Next Up – The Technology Driving the Activity

Tomorrow, I’ll briefly discuss the technology that drives this activity. While there are a few drawbacks, there are a lot of things I love about it. And there are some valuable lessons for developers of ed tech resources, and everyone’s lives would be better if more developers adhered to these principles.