New website
Five Tips for recording pupils’ progress in ICT
By Terry Freedman
Thu, 3 Jan 2008, 09:54

As well as assessing students' understanding at any given time, you will also need to record their progress over time. Here are five suggested ways of doing this.

Encourage pupils to store their work electronically rather than in paper format

This very much ties in with the following point. Paper versions of students' work are handy, because it is generally easier to read from paper than off a screen, and you can very easily annotate it pretty much anywhere.

However, as far as archiving is concerned, digital space is now no longer the big issue it once was, so it makes sense to store as much as possible in an electronic format. That will make it very easy to look back over previous versions of the work, in order to "get inside" the student's thought processes. (A simple comparison of marks or grades given at different points in time will not help you do that.)

Having said all that, I should strongly recommend keeping a paper version of the most up-to-date version of the work, especially if it counts towards a qualification, just in case the electronic repository gets damaged.

Encourage pupils to store different versions of their work from draft to finished product

This links in with the previous point, of course. In information and communications technology (ICT), much like mathematics, the process of getting from A to B is just as important as the destination itself. In other words, process is as important as product. Being able to look at the changes made to a piece of work over time is very useful when it comes to assessing a student's capability at any given point in time. Also, in the UK at least, students must have an eportfolio.

Make notes in your markbook as you walk around the classroom

Your markbook may be either paper or electronic, so I am using the term in a general sense. The critical point is that it is important to record your impressions as you walk around the room, looking at students' work, listening to their questions, and "eavesdropping" on their discussions. If a student appears to have a misconception about a particular concept, and then overcomes it (whether through your intervention or discussion with peers), those facts should be noted because they provide information about the student's progress which cannot be reflected in grades alone.

In other words, what you are trying to do, through your markbook, is tell a story.

Discuss the work with pupils, and ask them challenging questions –- and make a note of their responses in your markbook

This is, in effect, an extension of the previous point. You can pump-prime your students, and throw them a "curved ball" just as they think they've "cracked it". After all, how can you truly test their understanding -- and changes in their level of understanding -- without forcing them away from a nice, predictable, set of circumstances?

Note the context

If pupils provide you with evidence of ICT work they have done in other subjects, ask them, or their teacher, to also provide you with information about the context in which the work was done. A complicated-looking spreadsheet print-out may look impressive, but would become less so if you knew that the teacher had set it up and the students merely copied it.

This links in with the previous point, of course: by asking probing questions, you can start to figure out if the student really understands something or not.

Conclusion

To a large extent, much of what has been advocated here is to do with the gathering of what you might call "anecdotal" evidence. I don't think it is anecdotal, as such, but it is less objective-looking than a mark or grade. Please note the use of the word "looking": most of the time marks and grades give a spurious appearance of objectivity in  my opinion.

Even if that is not the case, using information like students' responses to questions and changes in their ideas over successive drafts of their work should, if the "objective" data is correct, corroborate what their marks tell you. If not, there is a mismatch that requires investigation -- and what could be wrong in that?

© Terry Freedman Thu, 3 Jan 2008