Personal Blogs

On 8 October 2018 I helped to deliver an online briefing to introduce new tutors to TM356 Interaction Design and the user experience, with a number of module team and staff tutor colleagues. What follows is a really brief summary of what was covered during this session.

I’m posting this blog for a couple of reasons: (1) so I can effectively share notes with everyone who attended, (2) so I can look back to see what I did when I helped to run a briefing, and (3) so I can easily remember what I’ve done when I get to that part of the year when I have my annual appraisal!

Agenda

The structure of the briefing was as follows: begin with some introductions and an ice breaker (so the new tutors can meet each other), present an overview and background of the module, and then present a summary of the module materials. The next part was to say more about the role of the tutor and the way that the module applies something called the Group Tuition Policy, including a description of all the key learning events. At the end there was a Q&A session.

The main ‘presentation’ part of the session was recorded, but the icebreaker session and the Q&A wrap-up session was not.

Tools

One of the slides mentioned the key tools and technologies that could be used for learning. These were: Open Studio (for the sharing of designs), discussion forums (module, cluster, tutor group), Adobe Connect for online tutorials (with the tutor, cluster forums, and module wide events), and prototyping tools (such as Balsalmiq).

Module materials and philosophy

A significant part of TM356 is based around a project; students are asked to think about an interactive product, which can be the focus of their investigations. There is also an emphasis on ubiquitous computing, iteration and prototyping.

The module consists of four blocks: an introductory block, a requirements block, a design block and an evaluation block.

Block 1, the introductory block has 4 units. These have the titles: Unit 1 - What is interaction design? Unit 2 - Goals and principles of user-centred design, Unit 3 - The ‘who, what and where’ of the design context, and Unit 4: Interaction design activities and methods. 

Block 2, requirements for interaction, also has 4 units: Unit 1 - Knowing the Users, Unit 2 - Exploring activities and contexts, Unit 3 – Data gathering for Requirements, and Unit 4 - Establishing Requirements.

Block 3, design and prototyping: Unit 1 - Understanding and Conceptualising Interaction. Unit 2 - Interface Types. Unit 3 - Design becoming concrete through prototyping, and Unit 4 - Conceptual design: Moving from requirements to first design.

Finally, Block 4, evaluation, has the following units: Unit 1 – Introduction to evaluation, Unit 2 - From data to information, Unit 3 - Planning and conducting an evaluation, and Unit 4 - Module reflection.

Tutorials

The module has three clusters (groups of tutors) which are broadly split across the UK. This module does have face to face tutorials; there is one towards the start of the module, and one towards the end. Here is a summary of the current group tuition plan:

• Interaction Design - getting you started
  
• Project choice workshop (module team)
  
• Preparing for TMA 2: practising skills - data gathering for requirements
  
• Prototyping and the development of concepts
  
• Design Hackathon (module team and some tutors)
  
• Prepare for TMA 3
  
• Preparing for TMA 4: practising skills for evaluating your design
  
• Preparing for exam: revision sessions (one block per cluster, and shared)
  

The design Hackathon is an event that is organised by the module team that is intended to expose students to collaborative design work. Suitable materials and electronics will be provided, and a topic for design activity will be agreed by the team beforehand.

At the event, tutors will help facilitate the students' work and reflections, in preparation for TMA03. For the 2018 presentation, the Hackathon will take place in Milton Keynes and Edinburgh at the same time, and students who were not able to attend physically will be able to connect to an online room and view presentations from both face-to-face groups to get some idea about what happened during the event.

Q&A and wrap up discussion

I didn’t make notes during the Q&A session, but I do remember a few things. I remember using the screen sharing tool in Adobe Connect to show tutors different parts of the TutorHome page and the module website. I also remember mentioning the importance of the tutor’s forum, highlighting a resources area, and a discussion about the introductory letter.

I’m also pretty sure that I emphasised that every tutor should make good use of their staff tutor (their line manager): their job is to answer questions about anything, and address any worries that they may have.

Every computing and IT department in a university has its own unique focus; some might pay lots of attention to the design and development of hardware. Others may place emphasis on programming languages and the foibles of operating system design. 

The OU Computing and IT degree programme places a special emphasis on the connections between computing and people. In some ways TM356 Interaction Design and the User Experience is a module that totally reflects this focus: it is all about the process of designing interactive devices and systems that allow us to address real problems that people have to face.

The TM356 Hackathon is all about design. Although a lot of OU teaching is at a distance, the Hackathon is unique in the sense that it is a face-to-face teaching event that allow students to meet with module teams and computing researchers.

But what is a Hackathon? ‘Hackathon’ comes from an obvious combination of two words: hacking and marathon. The hacking bit comes from the idea of creatively meddling with technology. The marathon bit means that the participants will expend quite a bit of (positive) energy doing this over an extended period of time.

In essence, the Hackathon is an opportunity to create some physical designs to some real world problems by working with other people over a period of a day. An important question is: why physical prototyping? Why not do some sketching (which was the focus of the module, M364, which it replaces)? The answer to this question is simple: computing is more than just a website; it has moved from the desktop computer and into the physical environment. Physical prototyping helps us to envisage new types of products and devices; it encourages participants to develop what is called ‘design thinking skills’.

What follows is a short summary of the first ever TM356 hackathon event that took place at the London School of Economics on Saturday 4 February. In this post I’ll try to give everyone a flavour of what happened. I’m writing this so I remember what happened, and also to give other TM356 students a feeling as to what might be involved.

Introduction

The day was introduced by module presentation chair and Senior Lecturer Clara Mancini. Clara said that an important aspect of interaction design is collaboration. The Hackathon event enables different students to work together to gain some practical hands on experience of prototyping. This experience, it is argued, can help students with their own TM356 projects and help them to prepare for their tutor marked assignments.

There were three key parts to the day: a tutor led discussion about projects, a series of short presentations by researchers, and the actual hackathon workshop where everyone works together on a specific theme. The event concludes with a tutor led discussion about how students might begin to tackle their assignment.

Project discussions

Since there were nearly thirty students, we were all split up into different tables to begin with our ‘project discussions’. During the module students are asked to create a prototype design for an interactive product. An important thing to note is that an interactive product doesn’t have to be a website: it could be anything, since interaction design and computing is gradually moving away from the desktop and into the environment.

The table that I sat at had some really interesting project ideas: a system for an improvised comedy group, a mobile friendly design for a government website, a remote control for people who have physical impairments, a tool to log and scan documents, and a navigation and route planning system. 

Looking at research projects

A number of OU research assistants and research students were also invited to the Hackathon. Their role was to share something about their own interaction design research projects with a view to inspiring the Hackathon project work. Researchers were sat at different places in the Hackathon room. Students were invited to meet the researchers, who were either working on their doctoral work, or on post-doctoral research contracts, to find out more about what they were doing.

There are two projects that I remember: one was about the creation of digital prototypes using electronics and cases made using 3D printers. The second project was about electronic fabrics or electronic textiles (e-textiles, Wikipedia), which could form the basis of wearable computing platforms. We were shown a camera that could be worn as a necklace, and a device that hospital patients could use to make subjective measurements of pain.  The electronic textiles were used in a research project about how to motivate groups of people who have special educational needs.

The Hackathon

The theme of the Hackathon was: ‘wearable technologies for health and well-being’. We were encouraged to think about the different ways that the term ‘well-being’ could be considered. We were also encouraged to think about issues that might affect wearable technologies, such as: demands on comfort, how we might pay attention to a product or a device that is worn, how it relates to the environment or the activity that we are engaged with. There are also practical issues to consider, such as how to organise input and output, cleaning and charging.

All the students were given access to a range of prototyping materials: this included card, paper, coloured pens, pipe cleaners, string, as well as some basic electronic devices, such as Arduinos. Marian Petre, a professor in the department made the important point that it wasn’t about the end result, it was about the thinking and the decision making that led to the creation of a prototype.

As a short aside, any student who has taken an OU module called U101 Design Thinking: creativity for the 21st century (Open University) would be familiar with some of the design thinking (Wikipedia) ideas and skills that the Hackathon and the module team were trying to expose and develop.

All the students sat in tables with either a tutor, researcher, or module team member. To get everyone going I suggested that the group should try some ‘divergent thinking’ before going onto doing some ‘convergent thinking’. To put it another way: we brainstormed what was meant by the terms ‘wellness and wellbeing’ before choosing a topic and exploring it more depth. When we had settled on an idea, we then went onto building a simple physical prototype.

Of course, our prototype didn’t doing anything: it was all about understanding the broad concept of use, and understanding the design goals and trade-offs. During the process, we would also uncover requirements and learn more about the potential user, the activity, and the environment in which the product would be used.

Presentations

At the end of the design activity all project groups were asked to make a short presentation about their prototype.

I’m not going to say anything about what each project was about since I wouldn’t want any of the design to unduly influence any thinking that might go on within any future events. Instead, let’s just say that the projects had very different objectives and they were all brilliantly creative.

Final points

Towards the end of the Hackathon and just before everyone got stuck into going through the third TMA (which was all about design), I noted down a few points that were made by the module team: the point of making makes you become aware of issues and limitations; you begin to think about electronics, materials, size of products and the environment. Design thinking is relating to uncovering the needs of the users and starting to think about practical issues. The design process is, of course, iterative. In the process of design, the prototypes become objects of communication.

The face-to-face Hackathon is complemented by a series of three online events that aim to address similar issues. The first online session presents the idea of a conceptual model and allows students to discuss prototyping approaches. The second online session enables students to speak with one another about their projects, and the final session explores different interface types. Rather than being equivalent to the face-to-face Hackathon, these sessions can be considered to be complementary; similar issues are discussed and explored in different ways.

If you are a student studying TM356, I hope this short blog post gives you some idea about what it is all about. I also hope that it will inspire you to attend the session. There is a lot to be gained by coming along!

Acknowledgements: the Hackathon was designed by the TM356 module team and run with help from research assistants and doctoral students from the School of Computing and Communications. Special thanks are given to and associate lecturers who play such an invaluable role and all the students who came along at the first TM356 Hackathon.

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!

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 3^rd 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). 

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!

A HEA sponsored workshop that is to focus on the teaching of interaction design, usability and user experience is to take place at the Open University in Milton Keynes on 27 June 2012.

The workshop aimed to bring together academics and teachers with the view to sharing experience and best practice.  More information is available from the HEA website but the key themes and principles behind the workshop is described below.

Interaction design, usability and user experience

Human-computer interaction (or interaction design, as it is now known) is a subject that touches upon so many different areas of computing; it impacts on areas such as web design, the design of mobile applications, the creation of video games, educational technology and so many others. There are also very obvious connections to industry and commerce, not to mention engineering, where system designers need to create usable interactive systems and interfaces for a range of different users.

Two of the key terms which are often spoken about when discussing interaction design are that of usability and user experience. Usability refers to the attributes or features of a product that enables the users to achieve an intended outcome. User experience, on the other hand, relates to the feelings or sense of accomplishment that might accompany an interaction with a device.

This interdisciplinary workshop aims to bring together technologists and educators from institutions throughout the UK who teach interaction design and related subject areas. Its overall intention is to share experiences and expose challenges, such as how to address complex issues such as the design of products for diverse users.

Topics can include, but are not limited to:

• Approaches and techniques used to teach interaction design
• Approaches and techniques used to teach the development of web technologies and any other interactive systems
• Development of mobile applications and tools
• Understanding usability and user experience
• Teaching of accessibility and interaction design
• New and novel pedagogic approaches for the teaching of usability and user experience
• Practitioner reports (education and industry)

Format

Those who are interested in sharing something about their teaching practice or their research are invited to submit short abstracts.  The abstracts will then be reviewed and those that are successful will be invited to submit papers that are 4-5 pages long which are to be connected to a presentation of 20 minutes.  It is envisaged that there will be a panel session at the end of the day to allow common themes to be identified and to expose some of the challenges that educators face regarding the teaching of interaction design and related subject.

If you are interested in attending, please submit a 300-500 word abstract to c.douce (at) open.ac.uk, using the subject heading 'HEA workshop'.

Key dates

Below is the list of the key dates to bear in mind:

13 May 2012 - Deadline for the submission of abstracts

18 May 2012 - Notification of acceptance

17 June 2012 - Deadline for final papers

Registration information for the event will be made available at least two weeks before the date of the workshop.