OU blog

Personal Blogs

Christopher Douce

Module debriefing: M364 Fundamentals of Interaction Design

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 22 Nov 2016, 15:16

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!

Permalink
Share post
Christopher Douce

Using the cloud to understand the user experience

Visible to anyone in the world

In mid-July I went to an event at University College London that was all about interaction design and the user experience.This blog post is a quick summary of some of the key points that I took away from the event.

The theme for the evening was all about how to do remote user testing.User testing is a subject that is covered in the Open University M364 Fundamentals of Interaction design module. Interestingly, the evening also had connection with another module that I have a connection with: TM352 Web Mobile and Cloud.There were three talks during the evening.For the purposes of this blog, I'm just going to say something about two of them.

Remote user testing

The first talk of the evening was by a representative from a company called WhatUsersDo (company website).Here's a quick summary of the business: if you've got an interactive product and you need to test it with real users, you can contact this company who have a bank of on-line testers.These testers can then be videos and recorded using your products or interfaces.When the testing has been completed, analysts can review the data and send it back to you in a neat report.

In essence, you can get lots of qualitative data relatively easily.You also don't have go through the challenge and drama of recruiting participants and organising lab sessions.Lab sessions, it is argued, are expensive. Instead, remote testers can their laptops (and smart devices) which have embedded video cameras and microphones.

The thing is: how does a recording find its way from a research participant to a user experience analyst?The answer is simple: the cloud helps them do it.Apparently the WhatUsersDo infrastructure is undergoing continual change (which isn't too surprising, given the pace of change in computing).Apparently, the business uses Amazon EC2, or Elastic Compute Cloud (I think that's what it's an abbreviation for!)Other bits of interesting technology include the use of Angular.JS (Wikipedia) and MongoDB (Wikipedia).

SessionCam

SessionCam (company website) also helps users to do user testing, but adopts a somewhat different approach to WhatUsersDo.Rather than to ask users to talk through their use of a website (for instance), SessionCam actually records where the users look when the move throughout a website.

I was very curious about how this worked.The answers seemed to be pretty simple: through the use of 'magic tags' that were embedded in a web page.It also works through the magic of cookies.I also had another question, which was: if the system is tracking user 'movements', then where does all this data go to?The answer was also pretty simple: to the cloud.Like WhatUsersDo, SessionCam also makes use of Amazon cloud storage.

A really interesting aspect to all this, is that the company was able to gather and store information about thousands of user interactions.The company could then create what was known as 'heat maps'.These were rough pictures of where users go to on a website.

Reflections

This event has taught me two things: the first is the interesting ways that cloud technology can be used to create a niche business or service.Secondly: the unassailable fact that I need to always keep up with changes in software technology.

I've seen Angular mentioned on an increasing number of job adverts.A quick skim read about it mentions some bits of tech that I have used at various times: HTML, the DOM, Javascript and JSON - but I haven't used Angular in anger.In fact, I know hardly anything about it.The same applies to MongoDB: I know what it is, and I know what it does, but I have never found the time to mess about with it.This is something that I really ought to do!(And the same applies with the use of Python, and this might well become a subject of another blog post).

In some respects, these companies represent two mini case studies about the use of cloud technologies.A couple of months back, I went to a talk about a company that shared financial data 'through the cloud'.There are loads of other examples out there.

Permalink Add your comment
Share post
Christopher Douce

Day in the life of a MCT staff tutor

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 17 Mar 2020, 08:26

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. 

Permalink 4 comments (latest comment by Emma lawrence, Saturday, 13 Mar 2021, 08:57)
Share post
Christopher Douce

Gresham College: Designing IT to make healthcare safer

Visible to anyone in the world

On 11 February, I was back at the Museum of London.  This time, I wasn’t there to see juggling mathematicians (Gresham College) talking about theoretical anti-balls.  Instead, I was there for a lecture about the usability and design of medical devices by Harold Thimbleby, who I understand was from Swansea University. 

Before the lecture started, we were subjected to a looped video of a car crash test; a modern car from 2009 was crashed into a car built in the 1960s.  The result (and later point) was obvious: modern cars are safer than older cars.  Continual testing and development makes a difference.  We now have substantially safer cars.  Even though there have been substantial improvements, Harold made a really interesting point.  He said, ‘if bad design was a disease, it would be our 3rd biggest killer’.

Computers are everywhere in healthcare.  Perhaps introducing computers (or mobile devices) might be able to help?  This might well be the case, but there is also the risk that hospital staff might end up spending more time trying to get technology to do the right things rather than spending other time dealing with more important patient issues.  There is an underlying question of whether a technology is appropriate or not.

This blog post has been pulled directly from my notes that I’ve made during the lecture.  If you’re interested, I’ve provided a link to the transcript of the talk, which can be found at the end.

Infusion pumps

Harold showed us pictures of a series of infusion pumps.  I didn’t know what an infusion pump was.  Apparently it’s a device that is a bit like an intravenous drip, but you program it to dispense a fluid (or drug) into the blood stream at a certain rate.  I was very surprised by the pictures: every infusion pump looked very different to each other and these differences were quite shocking.  They each had different screens and different displays.  They were different sizes and had different keypad layouts.  It was clear that there was little in the way of internal and external consistency. Harold made an important point, that they were ‘not designed to be readable, they were designed to be cheap’ (please forgive my paraphrasing here).

We were regaled with further examples of interaction design terror.  A decimal point button was placed on an arrow key.  It was clear that there was not appropriate mapping between a button and its intended task.  Pushing a help button gave little in the way of help to the user.

We were told of a human factors analysis study where six nurses were required to use an infusion pump over a period of two hours (I think I’ve noted this down correctly).  The conclusion was that all of the nurses were confused.  Sixty percent of the nurses needed hints on how to use the device, and a further sixty percent were confused by how the decimal point worked (in this particular example).  Strikingly, sixty percent of those nurses entered the wrong settings.  

We’re not talking about trivial mistakes here; we’re talking about mistakes where users may be fundamentally confused by the appearance and location of a decimal point.   Since we’re also talking about devices that dispense drugs, small errors can become life threateningly catastrophic.

Calculators

Another example of devices where errors can become significant is the common hand-held calculator.  Now, I was of the opinion that modern calculators were pretty idiot proof, but it seems that I might well be the idiot for assuming this.  Harold gave us an example where we had to try to simply calculate percentages of the world population.  Our hand held calculator simply threw away zeros without telling us, without giving us any feedback.  If we’re not thinking, and since we implicitly know that calculators carry out calculations correctly, we can easily assume that the answer is correct too.  The point is clear:  ‘calculators should not be used in hospitals, they allow you to make mistakes, and they don’t care’.

Harold made another interesting point: when we use a calculator we often look at the keypad rather than the screen.  We might have a mental model of how a calculator works that is different to how it actually responds.   Calculators that have additional functions (such as a backspace, or delete last keypress buttons) might well break our understanding and expectations of how these devices operate.  Consistency is therefore very important (along with the visibility of results and feedback from errors).

There’s was an interesting link between this Gresham lecture and the lecture by Tony Mann (blog summary), which took place in January 2014.  Tony made the exact same point that Harold did.  When we make mistakes, we can very easily blame ourselves rather than the devices that we’re using.  Since we hold this bias, we’re also reluctant to raise concerns about the usability of devices and the equipment that we’re using.

Speeds of Thinking

Another interesting link was that Harold drew upon research by Daniel Kahneman (Wikipedia), explicitly connecting the subject of interface design with the subject of cognitive psychology.  Harold mentioned one of Kahneman’s recent books entitled: ‘Thinking Fast and Slow’, which posits that there are two cognitive systems in the brain: a perceptual system which makes quick decisions, and a slower system which makes more reasoned decisions (I’m relying on my notes again; I’ve got Daniel’s book on my bookshelves, amidst loads of others I have chalked down to read!)

Good design should take account of both the fast and the slow system.  One really nice example was with the use of a cashpoint to withdraw money from your bank account.  Towards the end of the transaction, the cashpoint begins to beep continually (offering perceptual feedback).  The presence of the feedback causes the slower system to focus attention on the task that has got to be completed (which is to collect the bank card).   Harold’s point is simple: ‘if you design technology properly we can make the world better’.

Visibility of information

How do you choose one device or product over another?  One approach is to make usually hidden information more visible to those who are tasked with making decisions.  A really good example of this is the energy efficiency ratings on household items, such as refrigerators and washing machines.  A similar rating scheme is available on car tyres too, exposing attributes such as noise, stopping distance and fuel consumption.  Harold’s point was: why not create a rating system for the usability of devices?

Summary

The Open University M364 Fundamentals of Interaction Design module highlights two benefits of good interaction design.  These are: an economic arguments (that good usability can save time and money), and safety.

This talk clearly emphasised the importance of the safety argument and emphasised good design principles (such as those created by Donald Norman), such as visibility of information, feedback of action, consistency between and within devices, and appropriate mapping (which means that buttons that are pressed should do the operation that they are expected to do).

Harold’s lecture concluded with a number of points that relate to the design of medical devices.  (Of which there were four, but I’ve only made a note of three!)  The first is that it’s important to rigorously assess technology, since this way we can ‘smoke out’ any design errors and problems (evaluation is incidentally a big part of M364).  The second is that it is important to automate resilience, or to offer clear feedback to the users.  The third is to make safety visible through clear labelling.

It was all pretty thought provoking stuff which was very clearly presented.  One thing that struck me (mostly after the talk) is that interactive devices don’t exist in isolation – they’re always used within an environment.  Understanding the environment and the way in which communications occur between different people who work within that environment are also considered to be important too (and there are different techniques that can be used to learn more about this).

Towards the end of the talk, I had a question that someone else asked.  It was, ‘is it possible to draw inspiration from the aviation industry and apply it to medicine?’  It was a very good question.  I’ve read (in another OU module) that an aircraft cockpit can be used as a way to communicate system state to both pilots.  Clearly, this is subject of on-going research, and Harold directed us to a site called CHI Med (computer-human interaction).

Much food for thought!  I came away from the lecture feeling mildly terrified, but one consolation was that I had at least learnt what an infusion pump was.  As promised, here’s a link to the transcript of the talk, entitled Designing IT to make healthcare safer (Gresham College). 

Permalink Add your comment
Share post
Christopher Douce

Gresham College Lecture: User error – why it’s not your fault

Visible to anyone in the world

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.

Permalink Add your comment
Share post
Christopher Douce

Interaction design and user experience for motorcyclists

Visible to anyone in the world
Edited by Christopher Douce, Sunday, 9 Feb 2014, 16:04

Has anyone ever uttered the following phrases:  ‘it must be me!’ or ‘I must be stupid, I can’t work this system!’  When you say those words the odds are that it is likely that the problems have little to do with you and have everything to do with the system that you’re trying to use.

Making usable systems and devices is all about understanding different perspectives and thinking about compromises.  Firstly, there’s the user (and understanding what he or she wants to do using a system).  Secondly, there’s the task that has to be completed (and how a task might be connected to other tasks and systems).  Finally, there’s the question of the environment, i.e. the situations in which a product is going to be used.  If you fully understand all these aspects in a lot of depth and balance one aspect against another, then you’ll be able to design a system that is usable (of course, this is a huge simplification of the process of interaction design, but I’m sure that you get my point).

Parking a motorbike

A couple of months ago took a course at my second favourite academic institution, CityLit.  Since it was pretty good weather (despite being January), I decided to ride my scooter into the middle on London and park in one of the parking bays that were not too far from the college.  The only problem was that the City of Westminster has introduced a charging scheme, and this was a system that I hadn’t used before.

This blog post is a polite rant (and reflection) of the banal challenge of trying to pay Westminster council a grand total of one pound and twenty pence.  It turns out that the whole exercise is an interesting example of interaction design since it helps us to think about issues surrounding who the user is, the environment in which a system is used and the task that has to be completed.  Paying for parking sounds like a pretty simple task, doesn’t it?  Well, let me explain…

Expecting trouble

Having heard about the motorcycle parking rules in Westminster, I decided to do some research.  I expecting a simple system where you texted your bike registration number and location code to a designated ‘parking’ telephone number, and through the magic of mobile telephony, one English pound was added to your monthly mobile phone bill and the same English pound was appropriated to Westminster Council.  Well, it turned out to be a bit more complicated than that.  Payments don’t come from your phone account but instead come from your credit card.  This means that you needed to connect your phone number to your credit card number.

When you’ve found the motorbike registration site (which isn’t through a recognisable ‘Westminster Council’ URL), you get to create something called a ‘parking account’.  When logged in, you’re asked to enter the registration number of your vehicle.  In my case, since I’m pretty weird, I have two motorbikes: one that makes the inside of the garage look pretty, and another one (a scooter) that I sometimes use to zip around town on.   There are enough spaces to enter the registration codes for four different bikes. 

The thing is, I can’t remember the registration numbers for any of my bikes!  It turns out that I can hardly remember anything!  I can’t remember my phone number, I can’t remember my credit card number and I can’t remember two registration numbers.  I must be an idiot!  (Thankfully, I remembered my email address, which is something else you need – just make sure you know the password to access your account).

There was another oddity of the whole system.  After you’ve got an account, you login using a PIN code, which is the last four numbers of your credit card.  I never use these four numbers!  Again, I don’t know what they are! (Unless I had to look).  I was starting to get a bit impatient.

Arriving at the parking bay

The ride to the middle of town was great.  It was too early in the day for most people, which meant that the streets were quiet.  After parking my bike, I started to figure out how to pay.  I looked at an information sign, which I immediately saw was covered in city grime.  I also immediately saw that it didn’t have all the information I needed. 

I visited the parking website and discovered that you needed FOUR different numbers!  You needed a phone number, a location number (where your bike is parked), a day code (to indicate how long you’re parking your bike for), and the final four numbers of your registered credit card.  Thankfully, I had the foresight to save the parking telephone number in my phone, so I only had to send three numbers (but I would have rather liked to avoid messing around with my wallet to fish out my credit card; it meant unzipping and then zipping up layers of protective clothing).

Coffee break

At last, I had done it.  I had sent a payment text.  To celebrate my success, I visited a nearby café for a coffee and a sit down.  About ten minutes later, I received a text message that confirmed that I had paid for parking ‘FOR THE WRONG BIKE!’ 

The text message confirmed that I had just paid for parking for my ridiculous bike rather than the sensible city scooter that I had just used.  Also, when I registered both bikes on the system, I entered the scooter registration first, since it would be the bike that I would be using most.  At this point, I had no idea whether the system was clever enough to stupidly assume that I had written either (or both) of my bikes to Westminster at the same time.  There was no clear way to choose one bike as opposed to the other.  Again, I felt like an idiot.

Then, I had a crazy thought – perhaps I ought to try to look at my ‘parking record’, since this way there might be a way to change the vehicle I was using.  I logged in to the magic system (through my smartphone), entering in my last four digits of my credit card, again, and found a screen that seemed to do what I wanted.  It encouraged me to enter start and end dates (what?), and then had a button entitled, ‘generate report’.  A report on what?  The number of toys found in Kinder Eggs that are considered to be dangerous?  I pushed the button.  Nothing happened.  I had no parking history despite having just sent a parking text.  Effective feedback is one of the most obvious and fundamental principles of good usability.

Chat

It took be around five minutes to walk to the college.  When I got there I discovered two other motorcycle parking bays that were just around the corner.  I then made a discovery: it seemed that different bays seemed to have the same location ID.  It then struck me: perhaps the second number I had been entering in the phone was totally redundant!  Perhaps it’s the same code that is used all over London!

 During my class I got chatting to a fellow biker.  After I had emoted about the minor trauma of trying the pay for the parking, my new biker friend said, ‘there’s an app for this…’  Again, I thought ‘why didn’t anyone tell me!’  So, during a break I found the right app and started a download.  After a couple of minutes of nothing happening, I was presented with the delightful message:  ‘Error downloading: 504’.

Final thoughts

A really good interaction design principle is that you should always try to design systems which minimise what users need to remember (there’s this heuristic that has the title ‘visibility of system status’).   On this system, you needed to remember loads of different numbers and codes.  The task is pretty simple.  There is a fixed fee.  The only variable that you might want to enter is either the length of the stay (in days) and the choice of the vehicle.  But what happens if your phone runs out of charge and you want to use a friends phone to pay?  You’ll then have to make a telephone call with an operator, all for the sake of one pound twenty.

There’s also the environment to contend with.  I had to take gloves off, fumble around in my pockets for my mobile phone and then enter numbers.  The information sign was pretty small (and I can’t remember it mentioning anything about using an app).  I dread to think how difficult the process is if English isn’t your first language, and you don’t know that Westminster has bike parking fees.

One final thought is that one approach to learning more about the user experience is to observe users in the things that they do.  This is an approach that has drawn heavily from the social sciences, and on Open University modules such as M364 Interaction Design, subjects and techniques such as Ethnography are introduced.  Another approach to learning about user successes and failures is to search on-line, to learn about the problems other people have experienced.  Although this isn’t explicitly covered in M364, it is an interesting technique.

All this said, the second time that I needed to pay, I used the ‘pay by phone’ parking app.  The ‘504’ error message that I wrote about earlier had miraculously disappeared (why not a message that says, ‘please try again later?) and I was able to download the app and then press a couple of on-screen (virtual) buttons and enter in the last four numbers of my credit card (again, a number that I haven’t yet memorise, since no other system asks me for it…).  I even managed to pay for the right bike, this time!

Permalink Add your comment
Share post
Christopher Douce

Accessibility workshop: modules and module team representatives

Visible to anyone in the world
Edited by Christopher Douce, Sunday, 2 May 2021, 12:46

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.

Permalink 1 comment (latest comment by Jonathan Vernon, Tuesday, 6 Nov 2012, 17:58)
Share post

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 1976654