Personal Blogs

The first Open University module that I was a tutor for was called M364 Fundamentals of Interaction Design. I have some faint recollections of going to a module briefing which took place in Milton Keynes. When the module finished (and I found myself on the module team) I decided to run an unofficial module debriefing. This blog post has been derived from a set of notes that I made during the debriefing that was held in Camden Town on 16 July 2016. It is a part of a larger piece of work that I hope will be useful to inform university teaching practice across Computing and IT modules. Eleven people attended, most of them were associate lecturers. There was one staff tutor (a line manager for associate lecturers), and the original M364 module chair. 

Initial comments

A really interesting point was that the module doesn’t teach what is meant by ‘justification’. This is important because the TMAs for the module don’t necessarily have right or wrong answers (instead, students might present answers that are not appropriately justified).

A comment from tutors: students who are taking M364 as a first module may struggle, especially when it comes to the writing; they can also be shocked by the amount of reading that they have to do. The four blocks ‘dart around’ the set text, which can be disorientating. 

Marking

Marking is considered to be very time consuming because tutors need to understand the material very well. Anything between 1 hour and 3 hours per assignment is reported, which is at odds with the university guidelines of 45 minutes. In my own experience over ten years, I rarely got the marking down to an hour per assignment. 

Tutorials

The more students that attend the day schools, the more exciting they become. It’s important to offer real world examples (I regularly used door handles).

Exam marking

One tutor reported that they loved doing exam marking since it can inform other types of marking. An interesting observation is that the marking for M364 seemed to take longer than with other modules. It was also a challenge to try ‘to read their minds’ (in terms of looking for evidence of understanding).

Terminology

One observation was that there were occasional differences in the way that terminology was used within the module. There were also differences in terminology between modules, i.e. the terms ‘use cases’ and ‘scenarios’ are different in modules such as M256 (which is a Java module). Some English as a Second Language (ESL) students can find things especially difficult, since there are so many terms (especially in terms of the usability and the user experience goals).

Culture

Block 2 contains a section on culture and cultural dimensions, which hasn’t made it into the replacement module, TM356. Students sometimes took the section about culture very literally, but this aspect of the module did lead to some really lively discussions during tutorials. Even though the research about culture that is featured in block 2 can be criticised very easily, it offered a useful vocabulary.

Module team

The overwhelming view was that the module team responded to any problems and issues very quickly and efficiently. (This view wasn’t just expressed because a member of the module team was at the debrief meeting). 

Monitoring

During the module, monitoring was, by and large, allocated to a single monitor. Once that monitor had decided to move on, or wasn’t available, monitoring responsibility was handed over to another volunteer. There was the view that monitoring could have been distributed more widely across all the tutors. Key points were: ‘you learn more from monitoring than being monitored’ and ‘you see how others are marking’.

Tutor resources

One thing that I’ve noted down was that a roadmap of the course would be considered to be useful. Perhaps there could be more materials about the ‘mindset of correct, not correct’ answers. A challenge for new tutors is to understand the philosophy of the module, and it might be useful to convey the point that feedback to students has to be relevant to context of the tuition (or, put another way, tutor comments have to be aligned with and relate to what the students have submitted).

Something else that would be useful would be to have specimen TMA solutions: one that is very good, another that might be mediocre, to allow tutors to ‘align’ their marking.  In a similar vein, it would be useful to share different examples of marking practice.

Guidance to tutors is considered to be important: encourage new tutors to be flexible, and tell them not to be afraid of moving away from the module materials (if they find it appropriate to do so). Also, don’t expect to be perfect; this is a subject that doesn’t have perfect answers. 

Further work

During the debriefing event (which was, in essence, a focus group), I made a recording of all the discussions. My next step is to transcribe the recording so I can try to compose a distilled summary of what amounts to over 10 years of collective distance learning teaching practice of a subject that I feel is pretty difficult to teach. At the same time, I hope to present a short seminar so I can more directly share stories and experiences with some of my colleagues who teach different Computing and IT modules. I have no idea when I’m going to be able to do this, though; I’ll just try to fit it in when I can!

I’ve written this blog post to complement a presentation that I have given (or are just about to give!) at a faculty student support team meeting on 17 June. The aim of the presentation was to share something about what staff tutors do on a day to day basis. Since I thought that other people within the university might find the presentation (and this summary) of interest, I’ve decided to share it more widely.

I’ve written this summary from my own perspective; other staff tutors within the Open University (and in other faculties) are likely to have very different days simply because of how their role might be split between central academic work and regional academic work.  There will be, of course, common themes: working with module teams, working with student support teams and working with tutors (and doing research, when time permits!)  We also, of course, can and do speak with students.

If you’ve accidentally discovered this post, you might not know what a ‘staff tutor’ is.  It’s a job that is half academic, and half management.  The management bit means we manage tutors.  This management bit can and does directly feeds into the academic bit: we represent the interests of the tutors during module team discussions.  A staff tutor is what is known as a ‘regional academic’. We are currently spread across the whole of the UK, and we might do a whole bunch of different things, ranging from outreach, working with local industries (if time and opportunity permits), and playing a role in marketing events.  I’m based in the London region, and work for the MCT faculty (which is the faculty of Mathematics Computing and Technology).

Before I go on and describe ‘a day’, I should perhaps make a quite note on how I wrote this somewhat eclectic summary.  I began by writing what I got up to during an entire day.  I then thought about other important tasks that hadn't cropped up during the day that I sampled.  In fact, the below narrative is a collage of aspects from different days.  I’ve written it this way so give a sense of the diversity of things that we do.  It’s not representative, since every day is different, but it does give a taste of what kind of things a staff tutor gets involved with.

Blitz the inbox

I usually get up between 7 and 8 in the morning, depending on what I’ve got on.  If I’ve got to travel to Milton Keynes (the head office) I usually set my alarm clock for 6.30pm so I can comfortably catch a couple of trains.  Most of the time, however, I tend to work either at home, or in the Camden regional centre. On this day, I was up at around half seven, had some breakfast, and was in my study around three quarters of an hour later after quite a bit of early morning faffing about. 

When I boot up my laptop in the morning I usually have a single objective: to get though as many inbox messages as I can, as quickly as I can; this way I can figure out what is important and what is not.  I delete unnecessary calls for papers and scan through a ‘geek newsletter’ looking at new tech headlines.  I then delete a load of messages from Milton Keynes.  This might be: fire alarm notifications, messages about cakes and something about a pathway diversion. There is some stuff that I just don’t need to know about.

It’s important to keep everyone in the loop about what you’re doing, so one of the first things I did was to email our London faculty assistant to tell him what I’m doing.

I have a load of folders to manage my email load.  I see one email that corresponds to an on-going issue (a complaint).  I open up a folder that corresponds to the presentation of a module that I’m looking after, and I drag it in, to create a ‘virtual paper trail’ of an issue.

I see a university conference announcement that relates to an eSTEeM project.  This is a university scholarship initiative; I’m becoming increasingly interested in the scholarship of teaching and learning and I received a bit of funding to run my own project.  I read the conference call and wondered: could this conference be useful for dissemination?  Perhaps it might, but I then decided the timing didn’t work: I needed to concentrate on finishing the project which is about understanding the tutor experience of TT284.  I’ve got loads of other ideas; the challenge, of course, is trying to find the time.

One message reminds me that I need to send a message to all TU100 14J students.  One of my roles is to support the level 1 computing undergraduate tutors.  One thing that I’ve been doing is trying to encourage as many students to come along to the face to face tutorial sessions.  To do this I send them neat, concise messages about their day schools – this means they have all the information they need: information about the venue, information about travel information, and information about the room that they need to go to.  I compose a message to our faculty assistant, asking him to send it out later that day.

One email is interesting: can I help out with postgraduate events (because apparently I was some kind of IT curriculum programme lead?)  This was news to me!  I used to be a postgraduate computing student, but I’m certainly not a curriculum lead.  I sent an email to the regional marketing contact (who is always lovely) agreeing to run a ‘demo tutorial’ for any prospective students who might be interested, suggesting that we had a face to face chat when I’m next in the London office.

A colleague sent me a message that demands a response: Could I contribute to an associate lecturer’s CDSA (or, appraisal)?  Yes, I can!  He’s great!  But there isn’t much to say at the moment since he’s currently on a year out, but I’ll happily write a couple of paragraphs that might be useful.

One thing that I do in the region is help out with the associate lecturer development conferences which offer all tutors on-going professional development and training.  These events are very important: they give tutors an opportunity to meet each other, help tutors become familiar with new educational tools and approaches, and help the regional academics to more readily appreciate any of their worries and concerns. I’ve been helping to organise a session where the tutors would work with two actors who are running a session on dealing with difficult telephone calls.  After sending and receiving a couple of messages, it has been decided: the actors are going to invoice the region.

Releasing monitoring reports

It doesn’t seem like there are any really urgent crises to deal with this morning, so I decide to set another objective: to sign off all off on ALL the associate lecturer monitoring reports that have arrived into a faculty inbox over the last week or two. 

I’ve always held the view that signing off on monitoring reports is an important job.  I hold this view for two reasons: firstly, it’s a really useful way to get an understanding of the correspondence tuition that is delivered to students and secondly, as a tutor, I really welcomed the personal comments that used to come from my line manager.  Here’s what I do: I look at the comments of the monitor, and then the PT3, and then the script, and then add some ‘mediation’ comments.  Some monitoring for other staff tutors who are located in another part of the country has ended up in the London inbox, so I emailed it them a colleague who looks after those.

After a couple of hours of work, I decide it’s time for a well-earned cup of tea.

Academic stuff

During my break I idly browsed the BBC technology pages and discovered an article about a new computing initiative that uses something called the ‘Microbit’.  This takes me down the path of looking at (briefly) some of the history about the BBC’s computer literacy project that ran in the 1980s.  I start to read about someone (who is now a fellow of the royal society) who had helped design the ARM chip instruction set.  Since I often help at the London degree ceremonies in the Barbican I started to idly wonder whether this could be someone to put forward for an honorary degree. From my perspective, their contribution to computing is pretty clear.

I decide to park this, since I’ve already said I would recommend someone else to the honorary degree committee, but haven’t (yet) managed to find the time to write a biography of the candidate that I was thinking about.

A few weeks earlier I had attended an event that was run by the Higher Education Academy (HEA website).  The event was all about teaching introductory computing (personal blog), which is an interest of mine.  I also have an awareness that the faculty will soon start to consider how to replace TU100 My Digital Life (which will take a couple of years).  I’ve got this habit of writing ‘blog summaries’ so I can keep notes of interesting events and share these notes with colleagues.  I finally find the time to finish writing my summary, and I upload it to my personal OU blog after a bit of editing.

Dealing with a module issue

I receive a call from a fellow staff tutor about a student who is persistently unhappy with aspects of a module. We swap student ID numbers, and I look up the student record.  We have a chat about the student, and by looking at the student record, we figure out a way forward.  We both manage the tutors who are delivering the module in question, and between each of us we figure out what needs to be done: my colleague agrees to speak with the student to try to offer some further guidance and explanations.

I send my colleague copies of some emails that I had safely filed away.  I remember that after starting as a staff tutor, I soon realised that effective record keeping is really important.

Working with the student support team

The computing and IT student support team is located in Birmingham.  The members of the Birmingham team respond to student’s learner support queries and help students choose their next module on a programme of study.  When it comes to helping students with certain issues, we sometimes ask students to ring the SST, or we create what is known as a ‘service request’, asking the SST to give students a call: there are things that they can do that us staff tutors can’t do.

I receive a call from a colleague in Birmingham about a particular module, TT284 Web Technologies. My colleague has a very precise question about the module, and it’s a question that I can easily answer (since I work with the tutors who deliver that module, and have worked with the module team).  From my own perspective, it’s great to have that contact with someone who is offering advice to the students.  Also, I feel that due to changes in the way that tutors are managed (staff tutors are now managing smaller number of numbers), we’re able to specialise a bit more, and this will help us to more easily respond to detailed academic queries.

Towards the end of the day

As well as being a staff tutor, I’m also a tutor.  In MCT I tutor on M364 Fundamentals of Interaction Design.  In the previous presentation of M364, I ran a module wide revision tutorial.  I didn’t have to do this (this isn’t something that the M364 module team explicitly ask tutors to do), but I thought it would be a good thing to do; plus, it would help me to get more OU Live experience.  I decided to do the same for the current presentation. 

When I announced that I was running a session, another tutor said that she would come along and help out, which was great news. After quite a few email messages, we chose a date and time. There will be two sessions, and we agreed that we would work together on both of them. Our two sessions will tackle the subject of revision in different ways.

After a bit of a delay, the first stage of the Locations Analysis is out. I discover there are a huge number of documents to read through.  I skim through the main document, which seems to be over eighty pages in length. I quickly become tired.

When I get back I check my email again. There an extension request from a fabulous T320 tutor. I’m very happy to accept their judgement, and I appreciated that they asked me about it.  I offered a couple of suggestions about what to say to our student.

It’s the end of the day.  It has been a busy one. I make something to eat, and then caught a train to the middle of London to meet up with some friends.

On the way back, at Charing Cross train station, I noticed that I had missed a call.  There was a voicemail.  It was from a student of mine. I called the student back and we had a chat.  The student was asking for an extension. I agreed to the extension, and highlighted some sections of the assignment so our student could just focus on completing what he needed to do. I also emphasised a really important point: that there are no extensions to the final TMA. 

On 20 January 2014 I found the time to attend a public lecture in London that was all about usability and user error. The lecture was presented by Tony Mann, from the University of Greenwich.  The event was in a group of buildings just down the street from Chancery Lane underground station.  Since I was keen on this topic, I arrived twenty minutes early only to find that the Gresham College lecture theatre was already full to capacity.  User error (and interaction design), it seems, was apparently a very popular subject!

One phrase that I’ve made a note of is that ‘we blame ourselves if we cannot work something’, that we can quickly acquire feelings of embarrassment and incompetence if we do things wrong or make mistakes.  Tony gave us the example that we can become very confused by the simplest of devices, such as doors. 

Doors that are well designed should tell us how they should be used: we rely on visual cues to tell us whether they should be pushed or pulled (which is called affordance), and if we see a handle, then we regularly assume that the door should be pulled (with is our application of the design rule of ‘consistency’).  During this part of Tony’s talk, I could see him drawing heavily on Donald Norman’s book ‘The psychology of everyday things’ (Norman’s work is also featured within the Open University module, M364 Fundamentals of Interaction design).

I’ve made a note of Tony saying that when we interact with systems we take information from many different sources, not just the most obvious.  An interesting example that was given was the Kegworth air disaster (Wikipedia), which occurred since the pilot had turned off the wrong engine, after drawing from experience gained from different but similar aircraft.

Another really interesting example was the case where a pharmacy system was designed to in such a way that drug names could only be 24 characters in length and no more.  This created a situation where different drugs (which had very similar names, but had different effects) could be prescribed by a doctor in combinations which could potentially cause fatal harm to patients.  Both of these examples connect perfectly to the safety argument for good interaction design.  Another argument (that is used in M364) is an economic one, i.e. poor interaction design costs users and businesses both time and money.

Tony touched upon further issues that are also covered in M364.  He said, ‘we interact best [with a system] when we have a helpful mental model of a system’, and our mental models determine our behaviour, and humans (generally) have good intuition when interacting with physical objects (and it is hard to discard the mental models that we form).

Tony argued that it is the job of an interaction designer to help us to create a useful mental model of how a system works, and if there’s a conflict (between what a design tells us and how we think something may work), we can very easily get into trouble very quickly.  One way to help with is to make use of metaphor.  Tony Mann: ‘a strategy is to show something that we understand’, such as a desktop metaphor or a file metaphor on a computer.  I’ve also paraphrased the following interesting idea, that a ‘designer needs to both think like a computer and think like a user’.

One point was clearly emphasised: we can easily choose not to report mistakes.  This means that designers might not always receive important feedback from their users.  Users may to easily think, ‘that’s just a stupid error that I’ve made…’  Good designs, it was argued, prevents errors (which is another important point that is addressed in M364).  Tony also introduced the notion of resilience strategies; things that we do to help us to avoid making mistakes, such as hanging our scarf in a visible place so we remember to take it home after we’ve been somewhere.

The three concluding points were: we’re always too ready to blame ourselves when we make a blunder, that we don’t help designers as often as we ought to, and that good interaction design is difficult (because we need to consider different perspectives).

Tony’s talk touched upon wider (and related) subjects, such as the characteristics of human error and the ways that systems could be designed to minimise the risk of mistakes arising.  If I were to be very mean and offer a criticism, it would be that there was perhaps more of an opportunity to talk about the ‘human’ side of error – but here we begin to step into the domain of cognitive psychology (as well as engineering and mathematics).  This said, his talk was a useful and concise introduction to the importance of good interaction design.

For reasons that currently escape me, I seem to have found myself on three different module teams where I have some responsibility for accessibility.  The first two are design modules (design and innovation qualification) that are currently being developed by the university.  The third is M364 Fundamentals of Interaction Design, a module that I have tutored since its launch in 2006. 

I've been asked to write what is called an accessibility guide for the design modules.  For M364, I was asked to attend an accessibility workshop that was held on 17 October 2012 at the university in Milton Keynes.  This blog post is a rough set of notes that relate to this event (which was intended to inform and help those who are charged with writing an accessibility guide).  As well as being an aide memoir for on-going work, I hope that it might be useful for my H810 Accessible online learning: supporting disabled students groups who may be confronted with similar challenges.  Furthermore, I hope that the summary may be of use to come of my colleagues.

Setting the scene

The workshop began with a bit of scene setting.  Accessibility and support for students with disabilities is provided by a number of different parts of the university.  These include Disabled Student Services, the Institute of Educational Technology (IET) who offer internal consultancy and advice, and the Library.  Responsibility also lies with faculties, such as the Faculty of Mathematics Computing and Technology in which I am primarily based.  Accessibility, it is said, is closely connected with one of the key objectives of the university: to be open to people.

We were all reminded for the fundamental need to anticipate the needs of students during the module production process.  This is especially important at the moment since there are a significant number of modules that are currently in production.  We were also reminded that a tension between content and accessibility can sometimes arise.  Academics may wish to present materials and suggest activities that may be difficult for some learners to engage with, for example.  There is the need to consider the implications of module design choices.

The types of anticipatory adjustments that could be made include figure descriptions, transcripts for videos, subtitling, alternative learning activities and the provision of alternative formats.  It should always be remembered that alternative formats, such as documents supplied in Word, PDFs and ePub formats have the potential to help all students.  Alternative formats (as well as standard provision of materials, such as those offered through the university virtual learning environment) can be consumed and manipulated by assistive technologies, such as screen readers, screen magnifiers, for example.  Other relevant assistive technologies that can be applied include voice recognition software and mobile devices.

Further scene setting consisted of painting a rough picture of the different types of disabilities that are declared by students.  I was interested to learn that only a relatively small number of broad categories make up the majority of declarations.  Although putting people in boxes or categories can be useful in terms of understanding the bigger picture, it's always important to remember that the challenges and conditions that people face can be very varied.  By way of additional information (and guidelines) I also remember a reference to a document by the Quality assurance agency (QAA) entitled code of practice for the assurance of academic quality and standards in higher education, Section 3: Disabled students (QAA website).  This might be worth a look if you are especially interested in these kinds of policy documents and guidance that relate to higher education.

It was also stated that it is important to consider accessibility as early as possible in the module design process.  The reason for this should be obvious: it is far easier to include accessibility during the early stages of the design of a new module than to it is to retrofit accessibility into an existing structure.  This takes us onto one of the aims of the workshop; to explore the role of a dedicated accessibility co-ordinator who sits on a module team.  One of the responsibilities of a co-ordinator is to write an accessibility guide for a module.

Responsibilities of a module team accessibility co-ordinator

Our first main activity of the day was to consider and discuss the different responsibilities of an accessibility co-ordinator.  Working in a small group, we quickly got stuck in.  We soon discovered that we had pretty different roles and responsibilities within the university.

The responsibilities that we considered were important were the necessity supporting module authors and liaise with colleagues, keeping track of what learning materials are being produced within a module and actively obtain support and guidance from different departments where necessary.  A fundamental responsibility was, of course, to produce an accessibility guide (which is now an important part of the module production process).

A co-ordinator must have an understanding of different sources of information, know how modules are produced, know something about the module material and have some facilitating and project management skills.  An ability to write clearly and succinctly is also important too!

Looking and some guides

After a period of discussion about the role of the co-ordinator, we then went onto have a look at a set of different accessibility guides with a view to trying to summarise what works well and what could be done better. 

Accessibility guides for individual modules are now being written for every new module.  The first module that had an accessibility guide was U116 Environment: journeys through a changing world. This was followed by TU100 My digital life.  A very detailed accessibility guide is also available for H810.

A fundamental question is: what is the purpose of the guide and who is it aimed for?  My understanding is that it can be used by a number of different people, ranging from learning support advisors who help students to choose modules, through to tutors and students.  It is a document for different audiences.

One thing that struck me that we don't yet have the perfect document, structure or system to provide all the information that everyone needs.  This very much reflects my own understanding that accessibility isn't producing a document or a standard or set of instructions.  Instead, it is more of a process where the artefacts can mediate and reflect interaction between people who work together to provide effective support.

One of the key difficulties that we uncovered was that there is an obvious tension between generic and specific advice.  There is a clear risk of offering too much information which has the potential to overwhelm the reader, but in some instances potential students may have very specific questions about the accessibility of certain aspects of a module.

I've made a note of some of the shared conclusions and assumptions about the purpose of a module accessibility guide.  Firstly, the guide is there to highlight accessibility challenges.  It should also say something about what alternative resources are available and also offer information and guidance about how to support students.

One really important question that was asked was: at what point in the module production should we create this?  The answer is writing the guide should happen during the module production process.  This allows the co-ordinator to be involved with the module development and allow potential accessibility problems to be addressed early.  

Moving forwards

I found the workshop useful.  One of the main conclusions was that there needed to be more clarity about the role of an accessibility co-ordinator.  I understand that the results from the discussions have been noted and there may well be follow up meetings.

Accessibility (as well as support for individual students) is something that needs to be owned by individuals.  Reflecting my understanding that it is a process, the guide is needed to be something that needs to be refreshed as a module team gains more experience over the years in which a module is delivered.

One thing is very clear for me.  Given my role as co-ordinator on a couple of modules, I clearly need to get more of an appreciation as to what is going on so I can then consider the kinds of potential challenges that students may face. 

A key challenge is to understand the (sometimes implicit) assumptions that module teams make about the extent of adjustments that can be made and present them in a way that can be understood to different audiences.  This strikes me as a pretty tough challenge, but one that is very important.