Personal Blogs

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!

It took me a good few minutes to find my way out of Westminster underground station.  When I did finally emerge to the surface, I found the houses of parliament towering above me.  After a minute or so gathering my bearings, I was on my way.  I roughly knew where I was going: past Westminster Abbey, then take a turning down one of the adjacent roads.  As per usual, I got to the site of the venue ridiculously early.   So early, in fact, that they organisers were still putting the chairs out (!)

The launch event for the 2013 disability history month was held on 19 November. I attended a similar event in 2011 (blog post), which I found thought provoking, but my diary conspired against me from attending last year.  There were a number of reasons to go along to this event: one is personal, and another is professional (a third reason could be considered to be political).

The day kicked off with Richard Raiser playing a clip from a recent BBC two part documentary which described how the lives of people with disabilities had changed.  I did manage to see the first episode, which was about the care system, but I didn’t get to see the second episode (and I had missed downloading it on iPlayer).  The point was simple: we’re on the telly, and we’ve a right to be there.

Speakers

Just like the last launch event, there were a number of speakers.  The first speaker of the day was Kevin Courney from the National Union of Teachers.  Representatives from unions featured heavily in the 2011 event, and this year was no exception.  Teachers are, of course, likely to encounter people with disabilities and they, of course, may have disabilities themselves.  Kevin drew our attention to some teaching resources that the unions had prepared for schools.

The second speaker of the day was Mike Oliver, who was introduced as a social model theorist.  By way of detail, the social model is a way of looking at disability where people disabled not by their so called impairments, but instead by the society in which they inhabit.  Mike touched upon history before speaking about themes such as choice, control and independent living.  Mike’s underlined the significance of the current economic challenges.

The third speaker was Jan Walmsley, formerly from The Open University (an institution that has now over ten thousand students with disabilities).  Jan is a part of the Social History of Learning Disability research group (a research group that I hadn't heard of before).  The group was established in 1994 and one of its objectives is to share memories and experiences by people and for people by publishing life stories. 

The two final speakers of the day were Jackie Downer and Kirsten Hearn.  Jackie described the importance of support workers and that technology can be a lifeline.  Kirsten gave an impassioned speech, emphasising the importance of rights, and echoing points earlier points by saying that it was liberating that it, ‘wasn’t me that was the problem, but the world’.

Plenary

One of the first points to be made was by Baroness Dame Campbell who emphasised the importance of political lobbying.  An audience member asked about the credibility of the social model, and whether we ought to be thinking in terms of a ‘post-social model’.  (The questioner mentioned the name of an academic called Tom Shakespeare).  This struck me as a difficult question to answer, and a quick internet search led me to a research paper (University of Leeds) that takes quite a bit of reading.  This question points us towards the growing discipline of disability studies.

Towards the end of the panel session, the issue of teaching (and teachers) was again returned to.  I seem to remember a reference to the learning resources that were mentioned during the start of the speeches.  The point for these were simple: there is a potential to ‘educate out’ discrimination, (or to normalise difference) at an early age.

An alternative perspective

The final speech of the day a speech wasn’t really a speech at all.  It was a stand-up comedy performance by comedienne Liz Carr.  I hadn’t seen Liz before, but I had heard of her work through a comedy group called Abnormally Funny People.  Unfortunately, I haven’t made too many notes during this part of the event, since I was laughing too much, but Liz did reference a recent challenge to the government’s bid to abolish the Independent Living Fund (BBC Website).  I also remember a startling gag about the right to work assessments.  This, to me, was the kind of comedy that cuts quickly to an issue and makes us think.

Reflection

There was a palpable difference between the 2011 event that I attended and this event.  The biggest difference, of course, reflects the change in the UK political landscape; there were many references to government cuts and the ways that the affect people with disabilities.  We were encouraged to reflect on history and the lessons that it offers us.  We also needed to be mindful of ‘what used to be’; stories of change, difference and individuality are important to remember and to keep.  One thing I felt was a steely will to retain rights and fight for new ones.

The Open University is divided into a number of regions and twice a year the London region runs a staff development event for its associate lecturers who live in and close to our capital.  This blog post is a brief summary of an event that took place on Saturday 16 November 2013.  My own role during the day was quite a modest one (I was only required to do a couple of introductions).  This meant that I was able to wear my ‘tutor hat’ for much of the day.

Challenges for ESL students

ESL is, of course, a common abbreviation for ‘English as a second language’.  From time to time I’m asked what the university is able to do to help students who struggle with English.  There are a couple of schools of thought about this.  One school of thought is that English and writing skills should be embedded within modules (this is certainly the case within computing and engineering modules).  Another school of thought is that there should be a particular course or module that is dedicated to writing (which is the approach that the science faculty takes).  There are, of course, pros and cons with either approach.  The aim of this session was to offer tutors useful guidance about different resources and materials that could be shared with students.  It also aimed to help tutors chat about different challenges they have faced.

One skill that was considered to be important was the reading of papers, and a point was made that this is something that could be practiced.  Reading is, of course, a prelude to writing.  Although some people might argue that university level academic writing is something that is done only within the university (or academic) context, it can also be argued that learning how to write in an academic way can benefit learners in other ways, i.e. when it comes to writing for business and commerce, or the ability to distil evidence and construct cohesive arguments.

One question that was raised was, ‘how do you offer feedback in instances where students may struggle to read suggestions?’  This was a very good question, and sometimes interventions, or special sessions to help students are necessary.

Our discussions about writing led onto other discussions about plagiarism and academic conduct.  Plagiarism is, of course, a word that has very negative connotations.  In some cultures, using the words of an authority may be considered to be a mark of respect.  On the other hand, developing the ability to write in one’s own words is a really important part of distance learning; it’s both important and necessary for students to demonstrate how they are able to evaluate materials. 

The university has very clear policies about plagiarism and academic practice, and this is something that I’ve blogged about previously.  (Academic practice conference: day 1 summary, day 2 summary). From the tutor’s perspective, it isn’t an easy task to address these issues thoroughly and sensitively.  One thing that tutors could do is to run an activity (which exposes issues that relate to academic conduct).  Tutors (or module teams) could show how things should be done, and then tutors could facilitate a discussion using on-line forums, for example.

Another discussion that I’ve noted was the use of the ‘voice’.  Different modules may have a preference as to whether students can or should write in the first person.   One of the arguments about writing in the third person is that it allows other voices to be more clearly exposed.

During the session, we were all encouraged to do a bit of group work.  We were given a sample of writing and we were asked, ‘what resource would you choose to share with your students to try to help them with their writing skills?’  This was a fun activity and it emphasised that there is a lot of resources that both students and tutors can draw on.

To underline this point of resources, there were sets of study skills booklets that were available in the presentation room.  These had the titles:  Studying with the OU – UK learning approach, Reading and Taking Notes, Preparing Assignments and Thinking Critically.  If you’re interested, these can be downloaded from the Skills for Study website.

Developing resources and pedagogy for OU Live

I arrived at this afternoon session slightly late, since I was having too much fun chatting to colleagues.  OU Live is an asynchronous teaching and learning tool (which is a posh term to say that people can do things at the same time).  In essence, think ‘skype with a whiteboard’.  It allows tutors to run on-line sessions with groups of students, offering both audio and text-chat channels.  From my own experience, running OU Live can be pretty hard going, so I try to take every opportunity that I can (time permitting) to attend whatever training sessions the university offers.

This afternoon session was presented in two parts.  The first part was from the perspective of a science tutor (Catherine Halliwell), whereas the second part was from the perspective of a languages tutor.

Science perspective

I arrived in the session right at the moment when an important point was being made.  This was: ‘find a style of delivery that suits you’. It can be quite easy to use OU Live just to give ‘lectures’, but it is possible to use it to deliver dynamic interactive sessions.

One thing that tutors can do is to record their on-line sessions.  More students might use a recording of a session than there are students who are able to attend a live session.  One of the benefits of recordings is that they have the potential to become a very useful resource.  Tutor might, for example, refer students to sections of a recording when they start to revise for their exams.  Another thought is that you could explicitly refer to them when a tutor gives assignment feedback (guiding students to parts of a presentation where you have explained potentially difficulty concepts).

Catherine mentioned that her faculty had trialled the use of pairing tutors together to run single OU Live session.  Her module, a third level chemistry module, has 10 hours of tuition time.  Each session was shared; one tutor would take the lead, and the other would be a ‘wing man’.

Another aspect to OU Live pedagogy which can be easily overlooked is the importance of preparation.  Students can be asked to carry out certain activities before a session, such as completing one or more worksheets, for instance, to help to prepare students – or even performing observations, with the view to sharing data.

Catherine also spoke about some features that I had never used, but had been (slightly) aware of.  One of these features was the ‘file transfer’ facility, which could be used by the tutor to send students sets of ‘unseen questions’, perhaps in the form of a word document.  In some ways, this could be considered to be the electronic equivalent of giving everyone some handouts.  (I can also see that this would be especially useful during programming sessions, where tutors might hand out working copies of computer code to all participants).

We were given a number of very useful tips: make the first session as interactive as possible, and feel free to use a silly example.  Also, use things like voting, or drawing on a map.  Another thought is to turn the webcam on at the start so that the participants know who you are (you can turn it off after a few minutes, of course!)  Tutors should try their best to make their sessions friendly and fun.

There are a number of other points to bear in mind: some students can be reluctant to use the microphone, and this is okay.  Another approach (and one that I’ve heard of before) is to use OU Live as an informal drop-in session, where students are able to log in to have a chat with a tutor at a pre-arranged time.  It’s also important to take the time to look at a student’s profile to make sure whether there are any additional requirements that need to be taken into account.   Finally, because it’s possible to record a session, a tutor can always say, ‘I’m going to go through this bit quite quickly; because I’m recording this, you can always go back and play it back later if there’s anything that you miss’.

Languages perspective

The presentation from our language tutor was rather different.  We were given, quite literally, an A to Z tour of topics that relate to the use of OU Live, leaving us (and our facilitator), pretty breathless!

A couple of points that I’ve noted include the importance of developing routines and forcing habits (in terms of running sessions at the same time).  It’s also a good idea to send group emails, both before and after sessions (so students are aware of what is going to happen).  In terms of preparation, it’s a good idea to get on-line around half an hour before just to make sure that you don’t run across any technical problems or issues; having been confronted with the situation of Java software updates in the past this is very sound advice.

During the question and answer session at the end of the afternoon, the issue of the recording of day schools also cropped up again.  Our tutors were very pragmatic about this: recording of OU Live sessions should happen, since it allows the creation of resources that all students can use (especially those who could not attend any of the sessions).  It is therefore important to let all students know that recording is going to take place either before events, or at the start of an event.

Reflections

There’s always something to pick up from these events.   There were two main things that I gained from this session.  The first was the early discussions about language support consolidated what I already knew about the importance of academic conduct (and how the university procedures work).  Secondly, I picked up some tips about how to connect things together, i.e. connecting together assignment feedback with the use of OU Live recordings. 

The next event is to be held at the London School of Economics in March.   This event is likely to include a Mathematics Computing and Technology faculty specific session which will be held in the afternoon.  The fine detail hasn’t yet been decided on, but this too is also likely to be a good day.

After a day of meetings and problem solving, I wandered down to the basement where my scooter was parked.  I had a rough idea of the route I had to follow; I needed to head south from Camden town, navigate around Kings Cross and onto the Pentonville Road and then pick up the A1 at Angel, and then try to find my way south.  Thanks to Google Streetview I had geekily rehersed some of the trickier intersections – but I still ended up going the wrong way.

The reason for my Tuesday evening visit to the City University was to attend an event that was a part of a wider programme of events called the Ada Lovelace day (Finding Ada).  A website describes it as: ‘an international celebration of the achievements of women in science, technology, engineering and maths (STEM)’.  Okay, so I’m not a woman, but I’m fundamentally interested in two related subjects: the availability and accessibility of education to everyone, and the history of computing – so, it seemed a pretty cool event to go down and support.

Panel discussion

The event kicked off with a panel discussion.  The panel was introduced by Connie St Louis from City University.  The panel was a great mix of discussants from different sectors: the university sector, commercial sector and public sector.  Each discussant had a different story as to why they found science, technology or computing a fascinating subject.  

Whilst the subject of ‘coding’ (or the creating of computer programs) took central stage, quite a lot of the discussion it was great to hear about photonic research (from Arti Agrawal) and Prim Smith’s journey from programmer through to senior manager.  I particularly liked her description about how software can play a very important role in the provision of services to the public sector.   Vikki Read, from Unruly media, said that ‘it was important to give everyone the opportunity [to code]’.

Coding demo

After the introductions and initial questions came to an end we were given a taste of what ‘coding’ actually was.  In reality, this meant that we were shown what a ‘for loop’ looked like in a language called M-script which is used in something called Matlab.  For those who don’t know anything about Matlab, it’s a very complicated piece of software (I’m not going to say much more than this!)  It’s something that is used by engineering professionals to tackle some really tough engineering problems. 

For me, there were two things that didn’t work quite so well in this section: if you’re going to introduce what coding was all about Matlab wouldn’t have been my personal choice, and secondly, the coding demo was carried out by a man (which didn’t really seem to be in keeping with the day).  This said, we did get to see what M-script code looked like.

Doing a livecoding demo that is compelling and engaging is always going to be tough.  You’ve got to provide effective and efficient instructions that, in effect, are very understandable that do something that is interesting.   It’s not an easy task, and coders (in my humble opinion) only get into ‘the zone’ of coding (to appreciate the beauty and elegance of software) after a lot of hard work.

The Matlab demo was followed by a video presentation (YouTube) from code.org (website) which opened with the quote, ‘everybody in this country should learn how to program a computer... because it teaches you how to think’ (which, I think, is a good point).  I remember a quote from the video which goes something like, ‘software is about humanity’.  By writing code and considering abstractions (and how best to describe problems and situations to a computer), we need to reflect about our problems.  We also perpetually interact and work with software, whether we choose to or not.  It could even be argued that although software and programming has its foundations in mathematics and sciences, it is a subject that requires a huge amount of creativity.

One of the panel members later made the point that to be a scientist requires you to apply and use a huge amount of imagination.  The same, of course, can be said about software.

Question and answer session

The question and answer session was quite short and I haven’t taken too many notes during this part of the evening.  One of the questions asked was, ‘how difficult is coding?’  This one is difficult to answer easily since it depends on a number of different factors: the language, the problem that you’re trying to solve, and the level of motivation that you might have to solve it.  One other point that I do remember is a story about how one of the members of the panel gained her first job as an energy manager.  The short version of her answer was: it doesn’t hurt to be direct.

Reflections

This event was all about outreach and its objective was to inform and inspire, and this is something that is very tough to do in an hour.

Lovelace is a beguiling figure.  Her story is one that is fascinating.  It is also fascinating because of not necessarily what is known about her, but also what is disputed.  You don’t have to dig too far into her story to read about rumours of horse racing, gambling, debts and family jewels.  This said, she was certainly way ahead of her time (as were Babbage’s attempts to build a computing machine), when she wrote about the way that machines could weave patterns with numbers.   Babbage is certainly indebted to her when she translated (and added to) Menabrea’s description of his idea of the analytical engine.

During this event I was expecting there to be stronger voices that more directly call for more women in science, technology and engineering subjects.  I can remember a distinct gender disparity from my own undergraduate days when I studied computer science and I can clearly see that this is continuing today when I drop into computing and engineering tutorials (but less so in design tutorials) to give our tutors a bit of moral support.  I’ll be the first to put my hand up and say that I don’t really understand the reasons why this should be the case.

To me, computing is not just cool, it is very cool.  In what other subject can you invent infinitely complex, interactive and unique universes out of nothing but numbers?  Not only is software the stuff of pure thought, but it is also a way to solve real-world problems (some of which were hinted at by one of the panel members).

Not only did I get lost getting to the City University, I also got lost trying to leave the building. After a couple of false starts, I finally made it to the exit and out into the cool autumn air.  Minutes later, I had fired up the scooters engine and practically oblivious to the fact that deep inside the machine was some software (in my scooter’s engine management system) that was helping to propel me on my journey home.

The second TU100 development day for associate lecturers in London and the surrounding regions was held on Saturday 7 September in the London regional centre.  The overall purpose of the day was to give associate lecturers who tutor on TU100 an opportunity to share experiences and to gather some useful feedback about the module that I could pass onto the module team.  These days are often great fun since everyone is very much up for sharing and talking (and this day was no exception).  This blog post represents a quick summary of what happened (from my own perspective, of course).

I’m writing this post for a number of reasons.  The first reason is to remember what happened on 7 September (since my memory is somewhat fallible), and the second reason is to give those tutors who couldn’t attend a bit of a feel for some of the subjects were discussed.  The third reason is to try to encourage other tutors to come along to other events that we run in the region.

There were essentially three different parts to the day.  The first part was all about teaching programming and Sense.  The second was about issues relating to student retention (where we heard about a university initiative called Project Retain), and the third was a general ‘feedback (or feedforward) to the module team’ session.

Session 1 : Teaching programming and Sense

During the first session we were put into small groups and Leslie, one of our very experienced TU100 tutors, distributed a questionnaire to inspire discussion.  These had the headings: ‘how does TU100 teach programming?’, ‘how does TU100 teach Sense?’, ‘student contact hours’ and ‘marking’.  Since I’m not a TU100 tutor I didn’t contribute too much to the group discussions, but I did make some notes of some of the themes that had emerged.

It wasn’t too long before the subject of programming cropped up.  One of the comments I’ve made is that the module doesn’t contain too much about testing.  One other thought is that early on in the module it is a good idea to emphasise the importance of Sense, particularly the Sense programming guide.  Another thing that tutors could do is to emphasise the wealth of Scratch resources that are available from MIT, and that perhaps we should more explicitly brief students that Sense is an extension of Scratch.

We soon began to talk about the on-line sessions which are presented through Blackboard Collaborate (or OU Live, as the university calls it).  One of the challenges with using the OU Live software is that it takes time to hand over screen sharing control when tutors ask students to complete certain tasks. 

An interesting point is that OU Live might not only be useful for running tutorials.  Since it contains a facility to record sessions it can also be used to record how any application is used.  Tutors (or faculty staff) could use OU Live to make ‘video’ recordings to demonstrate some programming concepts.

One of the biggest challenges that tutor’s face is the marking of assignments.  Sometimes tutors come across some puzzling situations, i.e. if students submit work where a screenshot represents a correct functioning program, but the program that is submitted isn’t actually correct.  When it comes to correspondence tuition, one of the fundamental challenges is to get into the head of the student.  This led to the question of whether we might be able to record video clips to show how students could have created correct solutions.

Plenary

After around fifteen or twenty minutes of chatting, all groups were asked to report back.  This section is a quick summary of some of the key points that some of the groups mentioned. 

TU100 doesn't contain a section that is dedicated only to programming.  Instead, programming can found in different sections throughout the module.  One point mentioned by tutors was that whilst TU100 teaches coding it doesn’t say much about how to do the 'problem solving' part of programming.  Instead, students are required to spend time discovering how to program by exploring and playing with the Sense environment.

Aware of this issue, some TU100 London tutors have started to present the fundamentals of how to break apart problems into pieces that could then be used to create code (either in the face to face sessions, or on the on-line sessions).  The precursor to TU100, M150 contained some materials to introduce students to something called structured English.  This gave way to a debate about whether some additional material might be added to TU100, but the problem is that there are already lots of materials that students and tutors need to cover. 

The point is that the foundations (in terms of learning to program) are really important, especially for students who might potentially struggle with the fundamentals of programming.  One tutor said that some students never make it to the starting line on Sense and this kind of resources could be a bridge between high level thinking and programming.  Some of the fundamentals that could be covered (by tutors) include the basic constructs of programming, which includes sequences of instructions, selection, iteration, the use of variables and debugging.

One tutor said that ‘we need to emphasise that it is important that students have a go’ (so students gain an understanding of what the building blocks of software is all about).  Also, there is need for a Sense forum, something or some area that allows sharing of materials and ideas between students and tutors. 

One piece of advice to students should be, ‘go look at what people do with Scratch’.  Another comment was, ‘add a couple of YouTube type videos about program analysis’.  The interactive nature of programming does lend itself to the use of OU Live, via application sharing, but on-line asynchronous tutorials are always going to be difficult and it takes a skilled facilitator to use more sophisticated functions such as on-line break out rooms.

Another perspective was that it might help the students if there was slightly more signposting to different resources.  (I understand that this is something that the module team have been working on for the new presentation).

Contact hours, tutorials and day schools

Different regions do different things when it comes to on-line tutorials and day schools.  When it comes to on-line time, the London region has given tutors the opportunity to schedule and run individual sessions.  The south region runs join sessions, as does the south east region.

When it comes to the face to face sessions, all the London groups come together to form a series of big day schools with the intention of creating a critical mass of both students and tutors.  In other regions tutors run sessions with pair of tutors.  The differences can be down to geography, both in terms of the location of the students and the location of the tutors.  One other thought from my side is that it is also important to emphasise to all students that they are encouraged to go to any of the tutorials that they might find in the tutorial finder (so they can discover evening as well as weekend events).

Some tutors use materials that are created by the module team, whereas others create their own materials.  One example is the London region tutors creating materials in structured English, with a view to trying to ‘plug a gap’ in the module materials (regarding how students new to programming might set about splitting a program into different components).

Another approach that some tutors adopt to use their allocated on-line time is to run on-line drop in sessions via OU live.  The idea for this is that students could just pop into an on-line room to have a chat with a tutor if they had any questions.  I personally find this a really compelling way of making use of the on-line rooms, particularly when students might be wishing to chat about programming.  The breaks with the formality of a one-to-one conversation of the technology, but also allows participants to see what is being displayed on a shared whiteboard.

Working with OU Live

The first tip (for tutors) was, ‘remember to switch on your microphone’.  Another thought was, ‘can we make headsets compulsory please?’  The reason for this is simple: when students use the microphone and headset that is built into a laptop, a whole group of participants can be easily distracted by feedback, making communications a whole lot more difficult.

In some respects, participating in an OU Live session can be quite intimidating and one observation was that there are lots of students who don’t want to speak at all.  Sometimes some students prefer to use the text chat window rather than using the microphone, which can then make if quite difficult for the tutor to keep on top of everything (which is why some regions share OU Live sessions between tutors).

One point was that it is useful to ‘do something’ every 20 or so seconds.  This might be asking students questions, requiring them to respond with yes/no answers.  Another thought is to use a series of polls to assess understanding of certain concepts.  (One thing that I have personally learnt from my experience with the South East of England training is to poll students using the, ‘happy face’ button, i.e. by asking the students, ‘is everyone happy?, can you click on your happy face?’  When you regularly ask this, it helps to keep the student’s attention).

Marking of code

This section of the plenary discussion echoed an earlier point, that when it comes to communicating what needed to be done with complicated TMA questions (which involve programming), could the module team produce a video about how things should run, or have been constructed (using Sense)?

I’ve learnt that there are two different ways to add comments into Sense code.  One way is to use something called a comment window.  Another is to add some in-line comments.  I made a note of a debate about the use of different types of comments and that in previous assignments a TMA question asked students to add comments.  The consensus was that comments help; they help students to reflect on the code that is being written and help tutors to understand what has been submitted.

Project retain

An interlude between the first and the second session was presented by Maggie King, our associate dean for teaching and learning.  One of Maggie’s responsibilities has been to be a part of a university wide project called ‘project retain’.  

Project Retain is intended to increase the university’s retention (and progression) of students across different levels of study.  The project has given the university a number of recommendations, which include: offer a guide to key learning points and module materials, schedule and communicate real-time contact sessions during the first two weeks of a module (ideally through a letter), open module materials and web sites before the module starts, and make it clear when assignments are coming up (so our students are not surprised when they have to submit their assignments).  The first year of study, it was argued, is absolutely crucial.

Session 2 : Retention

Terry, one of our experienced TU100 tutors facilitated the second main session of the day, which was also about retention (which is an issue that affects student satisfaction scores, recruitment and funding). 

Terry introduced us to HEFCE performance indicators.  These include dimensions such as the national student survey and other aspects such as the measurement of research performance.   Terry also introduced the difference between retention and progression.  Progression is all about moving from one level of study to another.  In some circumstances students can defer, allow them to take a bit of time out from study and enabling them to pick up a module again at a later date.

One of the biggest changes in the university in the forthcoming couple of years will be the introduction of something called student support teams.  Since more and more students will be registering with the intention of studying for a particular qualification, student support teams will play an important role in helping students with their choices along a student pathway – it is hoped will positively impact on student retention.

Terry covered a wealth of materials, including sharing with us points from a national audit office report, drop out rates, how retention in UK HEIs compare with the retention in other countries, and how the university compares with others in the national student survey.  During his session Terry asked us to consider the causes of student drop out during different stages of study, such as pre-entry, induction, on-programme and movement to the next level.  In the university both tutors, student advisors and module teams all have an important role to play.  The final question of the day was, ‘how can the university support you in the task of improving retention in your tutor groups?’  This was an exceptionally very good question to ask and is something that I’m keen to pick up on and delve into when I have a bit more time.

Session 3 : Open Session

I have to confess that I haven’t taken too many notes about this final session mainly because we ran out of time!  Everyone was very willing to share experiences and opinions throughout the day, which was one of its fundamental objectives.

Reflections

One tutor made the comment: ‘you can make a full time job of teaching TU100’.   TU100 is, without a doubt, a very big module: there is a lot of material and there are a lot of demands on the tutor’s time.  What struck me about this day was the willingness of tutors to do their utmost to help their students along their TU100 journey and their willingness to share experiences with each other.  The event had lots of energy and there was a lot of positive talking going on, yielding some very good ideas.  From my own perspective, I certainly hope to be running a similar event next year.  I’ve already had a couple of thoughts about what we might do.

I have learnt quite a few things from this session.  I’ve learnt about the opinions that tutors have about certain aspects of the module and I’ll be happy to forward these directly to the module team.  It is also clearly apparent that some students struggle with programming and the idea of producing some video material to help to explain certain concepts might be something could be useful.

Acknowledgements

Many thanks to all our TU100 associate lecturers who kindly gave up their valuable time to attend this event on a Saturday. If any of the tutors who have attended would like to add further comments, please don’t hesitate to comment below.

On 1 July I attended an event at one of Google's offices in London to celebrate the UK's computing heritage.   The event was in five parts.  The first was a panel discussion about the very early days of the internet. This was followed by the screening of a short film, a presentation by Tilly Blyth about the Science Museum, some information about the national computing museum and the reconstruction of a computer called EDSAC, followed by a closing Q&A session.

I was immediately struck by the names of some of the speakers; people who were and continue to be fundamental pioneers of the internet.  During the event I made quite a few notes, only to later discover that the parts of the evening had been recorded and made available on YouTube.  So, if you're interested, do go and visit the links that are featured in this quick blog.  They're certainly worth a look.

The history of the internet

The first session, a panel discussion, comprised of Roger Scantlebury and Peter Wilkinson, from the National Physical Laboratory (NPL), Peter Kirstein (Wikipedia) from UCL, University of London, and Vint Cerf (Wikipedia) from Google.    You can view this really interesting discussion by going to the video recording on YouTube.

For sake of completeness, however, I'm also going to leave you with some of my edited notes which more or less reflect the bits that piqued my interest.  There were occasions where that I became so engrossed in the discussions that I forgot to take notes!  So they are, by necessity, very course and incomplete.  I recommend the video over than my notes.

 As soon as the discussion started, I started to remember stuff that I had read in various histories of the internet.  Donald Davies, who worked at NPL initiated a project that had intended to be national in scope - in some ways, similar to the Arpanet.    NPL has played an important role in the history of computing (and the internet).  Alan Turing moved to NPL to work on the ACE computer (Wikipedia), after spending time at Bletchley Park and working on voice scrambling systems.  This led to the development of the English Electric DEUCE computer (Wikipedia).

As an aside, I was really interested to learn that the NPL chose to make use of a Honeywell DPP-516  (Wikipedia) as the basis for some of their networking designs.  This happens to be the same machine that was used as an Internet Message Processor (Wikipedia) in the Arpanet project.  (It also turns out that the contractor that developed the IMP, BBN, visited NPL - interesting stuff!)

Peter Kirstein spoke about how he and how UCL became involved.  Politics, of course, proved to be a fundamental issue.  ARPANet was connected to a seismic array based in Norway called NORSAR which could be used to detect soviet nuclear tests.  Vint Cerf made some really interesting points - that the challenges were mostly bureaucratic ones rather than about technology.  Getting people to communicate is harder.  Like I said: the video is better than my notes!

LEO: Lyons Electronic Office

I've known of the LEO computer for a very long time, but it isn't a machine that I know too much about.  Google has sponsored the making of a film to celebrate the the LEO computer (YouTube), which is certainly.  I was very surprised to see a number of the participants in the film in the audience.  The underlined how recent this history is, and how phenomenally quickly technology continues to move.

Science Museum: Information age gallery

Tilly Blyth, from the Science Museum, London, spoke about the development of a new 'information age' gallery.  The aim of the gallery is to celebrate last two hundred years of communication and information technologies (I hope I've got this right!)  Tilly described its narrative approach; the museum has chosen twenty one different stories.  (I've made a note of a four)

The first is an exhibit of the last manual telephone exchange that was used in the country.  This physical artefact has the power to not only convey changes in technology but also the changes in work practices.  Another exhibit relates to the LEO computer, which I'm sure will be both interesting and enchanting in equal measure.

Some current technologies have their own interesting histories.  There's also going to be an exhibit about the global positioning system.  Commerce and information can now be more readily connected to physical locations.  I was reminded of these new apps where you can hail a taxi by pressing a button on your phone.

The final teaser was a mention of an exhibit that related to how technology was consumed and used in developing countries, such as Cameroon.  We can so easily get wrapped up in our own worldview that we can easily forget that information and communications technology has a global impact.  We were told that the museum was working with an anthropologist with a view to trying to understand how devices are used in different cultures.

I've taken a note of the phrase, 'stories of contrast'.  I'm looking forward to its opening.

EDSAC Reconstruction

David Hartley, the director of the National Museum of Computing at Bletchley Park spoke about the history of the museum.  David spoke about significant machines, such as the Harwell Dekatron computer and the Colossus reconstruction. He also touched upon the role of the British Computer Conservation Society emphasising its importance by saying that 'there is nothing so boring as a dead computer'.  David also mentioned that there were parallel cultures to the museum; one that related to the more traditional role of a museum and one that related to machine reconstruction (and preservation).

The second film of the day was entitled EDSAC - A cultural shift in computing (YouTube).  This video described a project to rebuild a historic computer.  It's certainly worth a look if you're interested.

Closing session

The opening question, to Vint, was 'did you have the notion that the internet would change the world?  What were you trying to achieve in those days?'  Vint spoke about a range of different things, and mentioned Douglas Englebart's mother of all demos  (YouTube) and other influences.   Vint also speaks about IPv6, space travel, the history of TCP/IP and ubiquitous computing.  The question and answer session has also been recorded (YouTube).   Some really great questions!

Reflections

One thing that struck me was how many people attended the event.  I was amazed!  Another thought is that it really did feel like a celebration.  I was also amazed to see some of the people who featured in the films that were screened sitting in the audience.  This reminded me of how close we are to our own history, and also how we are all wrapped up in it too. 

When we're in the middle of change we can't easily see the rate that it is happening.  Events such as this one helps us to step back and realise how far we've come in such a phenomenally short time.  A really good point was that whilst the technology is, in its own right, pretty interesting - it's the human structures and the politics that have to be negotiated to really allow things to be work.  Arguably, these represent the tougher challenges.

We have a reflexive relationship with technology.  We make technology by working with people.  When we've made something, technology has a potential to change us too.  An implicit challenge that each of us face is to understand and acknowledging the extent of these changes.

Session: Putting the history of computing into different contexts

The voice of the meachine: Tom Lean

Tom Lean from the British Library kicked off the second day with a presentation about a project that he is currently working on: An oral history of British Science (blog).  An important part of this project is about the history of computing.  A part of Tom’s role is to travel around the country to interview different people.  Each interview takes between 10-15 hours in length.  They are biographical; people are encouraged to talk about themselves, their environment, tools and procedures.

This lifestory approach to interviewing allows us to get a sense of the person themselves, their mannerisms and how they sound.  It allows us to have a more direct connection with the subject and those people who played a part in its development.  The longer interviews are edited down to highlights, which will then be made available through the British Library History of Science project website. I understand that researchers will be able to gain access to the entire interviews.

Tom gave us a taste of the interviews by showing us a clip of Ray Bird taking about the HEC1 computer (YouTube).  (For the interested, there’s also an Oral History of British Science YouTube channel).  The second clip was an interview of Mary Lee Berners-Lee (Wikipedia) who spoke about ‘what’s fun about programming’.

All in all, a great talk and a great initiative.  As an aside, I remember discovering another archive of oral histories of computing (University of Minnesota), which have been collected by the Babbage Institute.  Different interviews by different people (and institutions) are likely to explore and expose different issues.  Both archives are invaluable to present and future researchers.

Telling the long and beautiful (hi)story of automation: Marie d’Udekem-Gevers

Marie took us on a tour of devices that relate to the history of computing, offering us a slightly different perspective.   Computing can also be understood in terms of mechanisms, mechanisation and automation, which eventually takes us towards data processing.  We can also think of the history of computing in terms of generations, but there is also an important pre-history that we need to be aware of too. 

When we think of the pre-history of computing we might also consider mechanical and water clocks, the development of the Jacquard Loom (Wikipedia).   There is also the work of Pascal (who was mentioned earlier) and Babbage (whose trial machines are exhibited within the Science Museum).  Marie introduced a simple distinction: internal versus external representations (and memory).

The difference between the two is that we can easily (and obviously) see external representations (of information), captured within cards, or as notches on a rotating wheel.  Modern computers, of course, make use of hidden internal representations.  The difference between internal and external connects to the notion of the immediately understandable and tangible versus the hidden and abstract nature of software.  This connects to a wider (and later) debate about what we can gain by exhibiting the more recent generation of computing devices.

Competing histories of the internet: Christopher Leslie

Christopher Leslie (PPY homepage) teaches the history of the internet technology at the Polytechnic Institute of New York.  During his talk, Christopher mentioned a couple of books – one that I have read, and another one that I had never heard of before.  The first is called, ‘where wizards stay up late’ by Hafner and Lyon.  The second was called ‘NERDS: a brief history of the internet’.  (There are, of course, a number of other books about the history of the internet, such as one called ‘A brief history of the future’ by a former Open University colleague). 

A couple of comments that Chris made echoed some that had been made during the previous day; that it is very easy to take a determinist view of the history of technology; that developments occur gradually and in a number of determined steps.  When it comes to the history of the internet, there have been a number of different systems and innovations, emerging from different countries and locations. One interesting note that I made was the development occurs through a series of transitions, that technology is moved from one context to another.

Chris mentioned the work of Donald Davies at the National Physical Laboratory, Teddington, and an important Association of Computing Machinery conference in 1967 where two people who had never met each other presented very similar ideas.  In fact, I’m read that the word ‘packet’ (as in the phrase ‘internet packet’) comes from Davies’s work, whereas the protocols that make the internet work come from the work in the US (of course, I’m impossibly simplifying a whole swathe of really important history and technical stuff here!)  Chris also mentioned the French network Cyclades (Wikipedia) which has also influenced the development of ‘the internet’.

I’ve also made a note of his point that the connections between people and communities are really important.  Although defence funding was necessarily important, it is the connections between people and a culture of openness that exists within an academic community that helps developments to occur.  Another really important point that I’ve made a note of is that we ‘need to fight determinism in the classroom!’  I totally agree. 

My ‘take away point’ from Christopher’s presentation was that things are a whole lot more complex than they really are; there isn’t one history – there are many.

Session: Games

I was initially surprised to see a session on games in this conference, but the reasons why (and the importance of its inclusion) soon became apparent.  This session resonated a lot with me, since I was once an avid player of games during the ‘cassette era’!  There is also an increasing awareness that is a whole history that relates to the use of computers in entertainment.

Games and gaming can also represent compelling museum exhibits; they can be potentially used to draw people in to other exhibits.  This is why this session also has the subtitle ‘games – and it’s potential as a Trojan horse’. 

The popular memory archive: Helen Stuckey

Helen Stuckey, who travelled all the way from Australia, talked about a project that was all about collecting and exhibiting player culture from the 1980s.  I never knew this, but apparently there was quite a unique gaming culture in Australia and many games were developed locally due to import restrictions. 

The popular memory archive is a web portal.  Gaming isn’t just restricted to the games as artefacts; there is a wider and richer picture of use and consumption that is important too.  The portal allows visitors to save or record player memories.  In the 1980s games were often the first way that people came into contact with computers (this was certainly my own experience).  I have my own memories of walking to a newsagent and agonising over which game to buy with my own pocket money.  This walk, and the action of loading the game into my Atari computer in my cramped bedroom could be considered as a part of my biography.

Other aspects of computing history include the history of production and the role of hobbies.  Helen showed us a logo of the ‘Melbourne House’ software company, which certainly remember from my teenage years.  At the time, it had never occurred to me that this was an Australian company.

One of the challenges lies with choosing what artefacts and issues to focus on.  Out of a potential 900 titles, 50 game titles were chosen.  Some of the themes that I’ve noted include businesses, rise of the bedroom coder, legal issues, and the role of the collector.

Fan sites, such as Hall of Light (a database of Commodore Amiga games) and Word of Spectrum also have an important role to play in terms of documenting history.  (I started to look into both of these sites, and quickly found hours of my life had disappeared!)

I found the idea of a web-based resource really interesting.  Just as we have citizen science projects, such as Galaxy Zoo, I can see that there is scope for participative, or citizen history sites.  When there are so many memories and products and experiences out there, crowdsourcing is undoubtedly a powerful approach.  I’m enthusiastic about old games, and after a quick search around on the web following Helen’s presentation, I can clearly see that I’m not alone.

Introduction of computer and video games in museums: Tiia Naskali

Tiia’s presentation was about a physical exhibition rather than a virtual one.  Tiia spoke about gaming from the Finnish perspective and the hobbyist era between 1980 and 1990.  (On reflection, this is an incredibly short period of time in which a whole lot happened). 

Connecting to some of the points that Helen mentioned, Tiia made the point that games are a part of life histories. They are important within popular culture and the work of that period can be shared and appreciated by a newer generations.

What struck me as really interesting was Tiia’s summary of different game exhibitions that had taken place across the world.  One of the most prominent was Game On which apparently began at the Barbican, London. 

Gaming exhibitions still will continue to have resonance today.  On the month of this conference, the latest generation of games consoles are receiving a lot of attention: the Xbox One (Wikipedia) and the Playstation 4 (Wikipedia).

This session led to questions relating to the challenges regarding digital preservation, i.e. whether we should be considering how to preserve digital worlds.  For those who are interested in this project, more information can be found by visiting a project website that also contains a link to a final report. Other points raised during the question and answer session related to the authenticity of gaming experience and the potential societal impact of the use of games, which is, of course, the subject of on-going research.

Session: The importance and challenges of working installations

Computer Conservation Society – Its story and experience: Roger Johnson

Roger Johnson introduced the Computer Conservation Society (society website).  It wasn’t an organisation that I had heard of before, but I’m so glad that I heard about it.  The society was the brain child of Doron Swade (Wikipedia), former curator of the science museum (who has written a cracking book about the trials and tribulations of building Babbage’s Difference Engine no 2).

The society is a joint venture with the Science Museum and the British Computer Society and currently has approximately 800 members.  It has a number of guiding principles.  Firstly, membership is open to all, and it is free.  It doesn’t own computers but has, instead, close links to museums.  It also has a small rescue fund.  This can be used to help preserve historically significant machines that might be at risk of being disposed. 

During Roger’s talk, I made a note of the phrase, ‘today is tomorrow’s history’.  Given that there is so much that is going on at the moment a challenge lies with understanding what should be captured. 

For those who are interested, the CCS also has its own newsletter, called Resurrection (CCS website).

Museums – what they can and should be doing : Charles Lindsey

Peter Onion, who works on the Elliott 803 (Wikipedia) at the National Museum of Computing (and probably does a whole range of other things too!) temporarily stepped in for Charles Lindsey (who was able to attend the question and answer session).

Peter, using Charles’s words spoke about the objectives of a museum.  Two objectives are to inform the public and to help serious researchers.  Peter argued that perhaps there is a third, which is to preserve (and to develop) the skills necessary for the maintenance and operation of the objects and to preserve the perspective of those who created them.

One really interesting (and important) point is that museums are about history, not fashion.  One question was whether computing history ended in 1980?  This echoed an earlier point that some modern computers can appear to be visually uninteresting; their mystery and complexity is hidden within integrated circuits.  Working (historic) machines have the potential to add and expose depth and may be able to more directly expose the details that make things work.   There is also the question of what stories we may tell, questions about what issues earlier engineers (and maintainers) may have faced, methods they used and tools they applied.

History, nostalgia and software: David Holdsworth

We all know that hardware without software is useless.  A laptop without an operating system or application software becomes a pointless and immutable mix of plastic, glass and electronics.   Software is the stuff of computing (you might almost call software its ‘oxygen’), but so much of it is lost.  One of the most obvious reasons is that software is inherently invisible, and increasingly so.  This raises the important question of how to go about preserving (and also potentially exhibiting) software.

David showed us an interesting couple of web pages; an implementation of the Algol-60 programming language (Wikipedia) for a KDF9 computer (Wikipedia) demonstration through a web page.  Those who know something about the history of programming languages, Algol is a really important language.  Think of it as a latin of programming languages; it’s not used much these days but you can see strong echoes of its design in programming languages of today, such as Java.  (Being more of a software guy than a hardware guy, I felt that more might have been said about the history of languages).

The fact that we can write programs using an old language through a web page is really cool.  Such an approach allows us to sample the past and get a feeling for how things used to work.  David argued (or I have noted down) that we should ideally be able to browse and analyse source text, see software working and sample user experience.  I agree with him.

When it comes to digital preservation, David made the point that we need to read the original media and save it to new media, to keep a byte stream and create software to manipulate and work with these byte stream.  Not only is the software important, but so is the documentation too.  One way to deal with the documentation challenge is to scan existing manuals.  Documentation, however, can be flawed and incomplete.  The best representation of how a machine worked is an emulator.  A well written emulator becomes a description of how hardware operates.

On the subject of emulators and software, I asked myself a thought experiment of ‘what kind of exhibit would I create if I wanted to present something about the history of software?’  Some random thoughts include: the presentation of a command-line interface (echoing the use of a teletype), followed by the use of DEC terminals.  This would then be followed with a hands-on emulation of a Xerox Alto, followed by another emulation of an Apple Lisa (perhaps even an actual machine).  This could then be followed with a really early version of Windows, and then concluding with a touch screen tablet interface (running either iOS or Android).  All these presentations got me thinking!

The Teenage Baby: Chris Burton

I visited the Museum of Science and Industry (MOSI website) when I was looking around Manchester before choosing to study Computer Science there as an undergraduate.  Chris’s presentation has underlined that a repeat visit there is now long overdue.

Manchester Small Scale Experimental Machine (SSEM), also known as the Manchester Baby (Wiki pedia)was designed by Williams, Kilburn and Tootill and is considered to be the first stored program computer in the world.  Chris gave a description of a programme to reconstruct a replica of this very first machine.

The reconstruction was completed in 1998.  Chris told a fascinating story of the role the machine had played within the museum.  It was a story of movement and construction, of relocation and restarting.  The SSEM has now been in operation for fifteen years and it is important to remember that the original machine only ran for only three.

Chris emphasised the very important role of volunteers.  A volunteer can act as a guide, introducing the different aspects of the machine to visitors.  Chris told us of a story of a volunteer who held aloft a Williams tube and said, ‘this is what a flash drive looks like in 1948... and it only holds a millionth of a gigabyte’, raising curiosity and grounding the past in the technology of the present.

Physical reconstructions not only embody history, but also they represent and echo some of the processes that occurred as a part of the development of a machine.  By creating the past, we can not only develop skills, but we can uncover challenges that the early designers and users faced.

Session: Reconstruction stories

Reconstruction of Konrad Zuse’s Z3 : Horst Zuse

One of the truths in the history of computing is that there were a number of parallel developments happening around the world at the same time.  In Britain there was the work at Bletchley Park, in the United States there was the work at University of Pennsylvania, and in Germany, there was the work of Konrad Zuse.

Horst Zuse, who made a presentation at this conference, is Konrad’s eldest son.  I have known about Zuse’s work for a long time, and heard that his very early machines were destroyed in World War II.  What I didn’t know was the extent of Zuse’s creativity and innovation.  His early machines, the Z1, 2 and 3 used binary floating point numbers.  Z3 can be considered to be one of the first functional programmable computers in the world. One of the differences between the Z3 and other early machines it made use of electromechanical relays.  Z3 apparently used two and a half thousand  of the them, with six hundred being used for the calculating unit.

In 2008 Horst proposed building a new version, or a reconstruction of the Z3.  The new machine could be used to teach the principles of computing (addressing the same issue that the computing devices of today are more difficult to understand).  This reconstruction, however, was to make use of modern telecommunication relays, but this doesn’t discount the challenge of creating such a machine.

Horst talked about the delivery of the relays, the racks in which they were housed, the construction of memory and some of the challenges regarding the input devices (if I remember correctly).  It was initially located in the Technical museum, Berlin, to accompany the Z1 reconstruction that took place between 1987 and 1989.  It’s final destination is likely to be the Konrad-zuse-museum in Hunfield (museum website).  The museum looks like a cool place to visit!

There were two surprises in store for me.  The first was that Zuse created a binary calculating engine whilst independently rediscovering some of the principles that had been previously discovered by George Boole.  Secondly, during the question and answer session, a delegate asked about something called Plankalkül (Wikipedia).  I had never heard of this before.  In essence, Zuse proposed the design of a programming language decades before it became practically possible.

EDSAC Replica Project : David Hartley

Every ‘first’ is qualified.  Zuse’s machine is considered to be the first programmable computer, the Manchester Baby could considered to be the first solid state computer, whereas EDSAC (Wikipedia) is considered to be the first computer that went into regular service with a specific intention of solving problems for its users.  I didn’t know this, but EDSAC is also attributed to have helped three Nobel Prize winners.

The EDSAC reconstruction (project  website) started in 2010, following a conversation with a co-founder of ARM (which designs the processors that are used in smartphones and a whole host of other devices).  The project aims to have a working machine by 2015.  As well as creating a machine, corollary objectives include the desire to create a new archive of related materials and resources and, importantly, to create expertise.  These objects connect nicely to points that Peter Onion made when he was talking about the role of museums; that the very act of rebuilding (or preservation) actively enables past skills, tools and techniques to be rediscovered (and new approaches to be reapplied).

The machine is to be housed at the National Museum of Computing at Bletchley Park.  It’s interesting that there will be two early machines with very different memory technologies: the use of a cathode ray tube, and mercury delay lines.  I understand that there is a connection with the Dollis Hill research centre somewhere along the way, but I don’t (yet) fully understand the details just yet.  This just underlines the point that there’s always lots more reading to do.

For those who are interested, there’s a YouTube clip about the EDSAC replica project.

The Harwell Dekatron Computer :  Kevin Murrell

The Dekatron computer, or WITCH (as it is affectionately known), strikes me as a bit of an odd ball – but a very interesting one!  It was designed for (or as a part of) the UK Atomic Energy Research Establishment, Harwell, Oxfordshire.  Kevin told us that it was relay controlled, but it has an electronic arithmetic and logic unit (the bit that does all the calculations).  It also makes use of something called Dekatron valves which serves as its memory.

After spending life at Harwell, it was then moved to Wolverhampton and Staffordshire Technical College (which then later became a university).  Because of its move and role in education, it remains, perhaps the oldest original working computer in the world.

More information about this interesting machine can be found though the following YouTube video: The reboot of the Harwell Dekatron/WITCH computer.  The Computer Conservation Society also have a page about the WITCH (CCS website)

Capturing, restoring and presenting IRIS : Ben Trethowan

IRIS is an abbreviation for Independent Radar Investigation System.  Its role was to collect radar signals to record movements of aircraft.  Should there have ever been a mid-air collision the data collected by IRIS could have been used to provide key evidence for any investigation.  IRIS was said to have been built in the 1970s and ran until 2008 where it was decommissioned, which is an astonishing length of time for a single system.

Ben gave us some information about the technology.  IRIS was based on a DEC PDP11 that had been heavily customised.  Apparently the operating system had been customised too.  When it comes to computer conservation, the march of time can have an impact.  One of the challenges that Ben faced was regarding magnetic tapes.  Over time, oxidisation can occur, which means that the metal layer that is used to store all the data was starting to separate from the plastic layer.  An important part of IRIS was the use of high capacity data cartridges.  These too had started to degrade.  Rubber parts used as a part of the tape drives (or the cartridges) were beginning to perish.

As far as I can remember it, the previous owners of IRIS contacted the computer history museum and asked if they would like it.  Ben then got involved with the project to move the machine to Bletchley Park, working very closely with the donor organisation.  In doing so, he gained a thorough understanding of the role of the machine and the context in which it was used.

What struck me about Ben’s presentation was that he presented what amounted to a ‘good practice’ guide for computer conservation.  Ben’s talk was very clear; it was very interesting to hear all about the ‘other stuff’ that technical curators or ‘machine keepers’ need to consider or take account of.  Whilst a machine is interesting in its own right, understanding the context of use and the sharing of hard won expertise is invaluable in terms understanding how a machine works, its design and its broader organisational and cultural significance.

I’ve made a note (during Ben’s talk) that a good relationship with a donor organisation is important.   It also struck me that good computer conservation isn’t just about dealing with the computer and its software.  A computer forms a part of relationships between groups of people.  As soon as a computer moves from its original context to a new one it can easily become disembodied.  Understanding the human structures as well as the technical structures strikes me as a dimension that museums always need to be mindful of.

Reflections

The conference ended with a short panel session.    I have to confess to being pretty mentally tired at the end of the two days and I didn't take in as much at this point as I would have liked!  This said, the conference was just the right length; a third day would have been too much for me!

This part of the blog is a set of random reflections - nothing too controversial; just a set of thoughts on what struck me the themes were.  I’m sure that different people would have come away with a different set of themes based on their own personal interests.

One of the key themes of the conference was (perhaps unsurprisingly) the role of museums in the history of computing.  There are some fundamental challenges regarding preservation when many aspects of computing (and computer use) are intangible.  There is also a question of which stories to present and how we might present them, and how to we make what is sometimes abstract become visible to try to make it understandable.  One approach, of course, is to use guides or interpreters to try to inspire visitors and help them to understand abstract ideas and principles.  Grounding the role of machines in terms of their application or their wider social context also strikes me as being very important too.

Reconstruction of old computers featured heavily and this was a surprise (but in retrospect, this was more due to my own unfamiliarity of what was happening in this sector than anything else).  Reconstruction is a process where the actions both generates and reaffirms knowledge.  It also strikes me that it is a fabulous way to go about conducting research into some of the early designs and sharing expertise.

Another theme relates to the role of history and its relevance.  A number of speakers say that the history of technology or computing isn’t taught a great deal.  Computer history certainly wasn’t taught on my undergraduate degree and this is a shame.   I was also struck by the assertion that subjects such as computing are viewed as ‘ahistorical’.  This said, you scratch the surface and there’s a whole host of rich, deep and fascinating stories. 

It also was a real delight to inadvertently discover that those that had a connection with the actual history of computing were able to come along to the conference.  What also struck me was a sense of community, especially amongst those who have an involvement with the Computer Conservation Society.

A final work on what I got (personally) got out of the conference.  One of my research interests relates to how ‘place’ played a role in the development of computing, i.e. what happened and where.  I also hope to travel to different places where these innovations have taken place.  This, for me, will be a catalyst for adventure and learning.  In fact, I’ve already taken a couple of journeys and hope to do many more in the coming years.

One thing that I’ve realised is that there is so much history on my doorstep.  During the conference I was chatting to a former colleague who I was amazed to discover had a direct and immediate connection with a computer called LEO (Wikipedia), which was arguably the world’s first commercial computer.  (There was the UNIVAC in America, but I would have to travel quite a way to visit the places where it was created).  I know hardly anything about the LEO.  I feel that a whole new journey of discovery is just about to begin.

Twice a year Open University associate lecturers have an opportunity to attend regional development events.  These conferences offer tutors a number of different training sessions about a range of different topics, ranging from change in university policies, through to the best way to use technology.

Each event is different and has a slightly different character.  This blog is a really simple overview of an event that I recently attended at Kent College.  In fact, I think I remember visiting Kent College to attend my first ever tutorial, which was run by my then mentor, not long after starting as an associate lecturer.  I remember getting quite lost amongst a number of different buildings and being in quite a gloomy room.  Things have changed: Kent College was unrecognisable.  Old buildings had been demolished to make way for new modern ones.  This, however, wasn't the only surprise.

Teaching through drama

Not long after arriving, we were all gently ushered into a large theatre.  We could see a number of tables set out at the front and I immediately expected to endure a series of formal presentations about changes to the structure of the university, or an update about student registrations, for example.   Thankfully, I was disappointed. 

From stage left and right, actors suddenly appeared and started to scream and shout.  It immediately became apparent that we were all in the middle of a theatre production which was all about teaching and learning.  We all watched a short twenty minute play of a tutorial, in which we were presented with some fundamentally challenging situations.  The tutorial, needless to say, was a disaster.  Things didn't go at all well, and everyone seemed to be very unhappy.  Our hapless tutor was left in tears!

When the play had finished and we were collectively shocked by the trauma of it all, we were told that it would be restarted.  We were then told that we should 'jump in' and intervene to help correct the pedagogic disaster that we were all confronted with.  Every five or so minutes, colleagues put up their hands to indicate that they would like to take control of the wayward situation.  It was astonishing to watch for two different reasons.  Firstly, the willingness that people took on the situation, and secondly the extensive discussions that emerged from each of the interventions.

Towards the end of the modified (and much more measured) play, I could resist no longer.  I too put up my hand to take on the role of the hapless tutor 'Rosie'.  My role, in that instant, was about communicating the details surrounding an important part of university policy and ensuring that the student (played by an actor) had sufficient information to make a decision about what to do.   It was an experience that felt strangely empowering, and the debates that emerged from the intervention were very useful; you could backtrack and run through a tricky situation time and time again.  The extensive audience, sitting just a few meters away, were there to offer friendly situations.

If an outsider peered around the door and saw what was going on, it might be tempting to view all this activity as some form of strange self-reflective light entertainment.  My own view is very different: there is a big distance between talking about educational practice in the third person, i.e. discussing between ourselves what we might do, and actually going ahead and actually doing the things that could immediately make a difference.   A really nice aspect of the play was that all the students (as played by actors) were all very different.  I'm personally very happy that I'm not tutoring on the fictional module 'comparative studies'!  This first session of the AL development conference was entertaining, enjoyable, difficult and insightful all at the same time.

Sessions

After the theatre production, we (meaning: conference delegates) went to various parallel sessions.  I had opted for a session that was part about the students and part about gaining more familiarity with the various information systems that tutors have access to (through a page called TutorHome).  I've heard it said time again that the only constant in technology is change.  Since the OU makes extensive use of technology, the on-line portal that tutors use on a day to day basis is occasionally updated.  A face to face training session is an opportunity to get to know parts of our on-line world that we might not have otherwise discovered, and to chat with other tutors to understand more about the challenges that each of us face.

The second session that I attended was also very different.  Three research students from the University of Surrey presented some of their research on the subject of motivation in higher education.  There is, of course, quite a difference between the face to face study context and the Open University study context.  A presentation on methods and conclusions gave way to an extended (and quite useful) discussion on the notion of motivation.

One memory of this session is the question of how it might potentially move from being strategic learners (completing assignments just to gain credit for a module or degree), to motivation that is connected with a deep fascination and enthusiasm for a subject.  There are a number of factors at play: the importance of materials, the way in which support is given and the role that a tutor can play in terms of inspiring learners.

I made a note about the importance of feedback (in response to assessments that had been completed and returned).  A really important point was that negative feedback can be difficult to apply, especially if there is no guidance about what could be done to improve.  (This whole subject of feedback represents a tip of a much larger discussion, which I'm not going to write about in this blog).

In terms of inspiration, one useful tip that I took away from this final session was that the relevance and importance of a module if a module can be connected to debates, stories and discussions that can be found in the media.  Although this is something that is really simple (and obvious), it sometimes takes conferences such as these to remind us of the really important and useful things that we can do.

Final points

All in all, a fun day!  From my own personal perspective, I enjoyed all the sessions but I found the theatre session particularly thought provoking - not just in terms of the points that were covered, but also in terms of the approach that was used.

Since I have no idea who is going to be reading this particular blog post (not to mention all the others I've written!), I guess I'm primarily writing for other OU tutors who might accidentally discover these words.  If you are a tutor, my overriding message would be: 'do go along to your regional conferences if you can make it - they are really good fun!'

If you're a student with the university I guess my message is that there are many of us working behind the scenes.  We're always trying to do the best that we can to make sure that you're given the best possible learning experience.  Another point that I must emphasise is that the instances of interaction with tutors are really important and precious (for student and tutor alike).  So, if you're a student, my message is: 'do go along to any face to face tutorials or days schools that might be available as a part of your module - there is always going to be something that you'll be able to take away'.

When I was a graduate student at the University of Manchester (or the bit of it that was once known as UMIST) I was once asked to show some potential computer science students around the campus.  At the end of the tour I ushered them to lecture which was intended to give the students a feel for what things would be like if they came to the university.

The lecture, given by one of the faculty, was all about the notion of abstraction.  We were told that this was a fundamental concept in computing.  In some respects, it felt less of a lecture about computing, but more of a lecture about philosophy.  I had never been to a lecture quite like it and it was one that really stuck in my mind.  When I left the lecture, I thought, 'why didn't I have this kind of lecture when I was an undergraduate?'  As an undergrad I had spent many a hour creating various kinds of computer programs without really being told that there was an essential and fundamental idea that underpinned what I was doing.

When I saw the British Computer Society (BCS) advertising a lecture that was about the 'power of abstraction', I knew that I had to try to make time to come along. The lecture, by Professor Barbara Liskov, was an annual BCS lecture (the Karen Spärck Jones lecture) that honours women in computing research.

All this sounds great, right?  But what, fundamentally, is abstraction?  An 'abstract' at the top of a formal research paper says, in essence, what it contains.  Abstraction, therefore, can be thought of as a process of creating a representation of something, and that something might well be a problem of some kind.  Admittedly, this sounds both confusing and vague...

Barbara began her lecture by stating that abstraction is the basis of how we implement computer software.  The real world is, fundamentally, a messy place.   Since computers are ultimately mathematical machines, we need a way to represent problems (using, ultimately, numbers) so that a computer can work with them.  As a part of her lecture, Barbara said that she was going to talk through some developments in the way that people (or computer programmers) could create and work with abstractions.  I was intrigued; this talk wasn't just about a history of programming languages, it was also a history of thought.

So, what history was covered?  We were immediately taken back to the 1970s.  This was a period in computing history where the term 'software crisis' gained currency. One of the reasons was that it was becoming increasingly apparent that creating complex software systems was a fundamentally difficult thing to do.  It was also apparent that projects were started, became excruciatingly late and then abandoned, costing astronomical amounts of money. (It might be argued that this still happens today, but that's a whole other debate which goes beyond this pretty short blog post).

One of the reasons why software is so fundamentally hard to create is that it is 'mind stuff'.  Software isn't like a physical artefact or product that we can see. The relationships between components can easily become incredibly complicated which can, in turn, make things unfeasibly difficult.  Humans, after all, have limited brain capacity to deal with complexity (so, it's important that we create tools and techniques that help us to manage this).

We were introduced to a number of important papers. The first paper was by Dijkstra, who wrote a letter to the Communications of the ACM entitled, 'Goto considered harmful'.  'Goto' is an instruction that can help to create very complicated (and unfathomable) software very quickly.  Barbara described the difficulty very clearly. One of the reasons why software is so hard is that there is a fundamental disconnect between how the program text might be read by programmers and how it might be processed or executed by a machine.  If we can create a program representation that tries to bridge the difference between the static (what is described should happen) and the dynamic (what actually happens when software does its stuff), then things would be a whole lot easier.

Another paper that was mentioned was Wirth's 'program development by stepwise refinement'. Wirth is famous for the design of two closely related languages: Pascal and Modula-2. It certainly is the case that it's possible to write software without the 'goto' instruction, but Barbara made the interesting point that it's also possible to write good, well-structured software in bad languages (providing that you're disciplined enough). The challenge is that we're always thinking about trade-offs (in terms of program performance and code economy), so we can easily be lured into doing clever things in incomprehensible ways.

Barbara spoke about the importance of modules whilst mentioning a paper by Parnas entitled, 'information distribution aspects of design methodology'. One of the great things about modules, other than that they can be used to group bits of code together, is that they enable the separation of the implementation and the interface.   This has reminded me of some stuff from my undergrad days and time spent in industry: modules are connected to the term 'cohesion'.  Cohesion is, simply, the idea that something should do only one thing.  A function that has one name and does two or more things (that are not suggested in its name) is a recipe for confusion and disaster.  But I fear I'm beginning to digress from the lecture and onto one of my 'coding hobbyhorses'.

Through a short mention of a language called Simula-67 (Wikipedia) we were then introduced to a paper by Liskov and Zilles entitled, 'programming with abstract data types'.  We were told that this paper represented a sketch of a programming language which eventually led to the creation of a language called CLU (Wikipedia), CLU being short for Clusters.

There is one question Barbara clearly answered, which is: why go to all the trouble of writing a programming language?  It's to understand whether an idea works in practice and to understand some of the barriers to performance.  Also, whenever a language designer describes a language in natural language there are always going to be some assumptions that the compiler writer must make. Only by going through the process of creating a working language are language designers able to 'smoke out' any potential problems.

Just diverting into programming language speak for a moment, CLU implemented static type checking, used a heap, and doesn't support concurrency, the goto statement or inheritance.  What it does implement is polymorphism (or the use of generics), iterators and exception handling.

Barbara also mentioned a very famous language called Smalltalk, developed by Alan Kay.  Different developments at different times and at different places have all influenced the current generation of programming languages.  Our current object-oriented languages enable programmers to define abstractions, or a representation of a problem in a way that wasn't possible during the earlier days of software.

Research directions

Barbara mentioned two research topics that continue to be of interest.  The first was the question of what might be the most appropriate design of a programming language for novices?  In various years, these have been BASIC (which introduced the dreaded Goto statement), Pascal, and more recently Java.  Challenges of creating a language that helps learners develop computational thinking skills (Wikipedia) include taking account of programming language design trade-offs, such as ease of use vs. expressive power, and readability vs. writeability, and how to best deal with modularity and encapsulation.

Another research subject is languages for massively parallel computers.  These days, PCs and tablets, more often than not, contain multiple processor cores (which means that they can, quite literally, be doing more than one calculation at once).  You might have up to four cores, but how might you best design a programming language that more efficiently allows you to define and solve problems when you might have hundreds of processors working at the same time?  This immediately took me back to my undergrad days when I had an opportunity to play with a language called Occam (Wikipedia).

There was one quote from Barbara's lecture that stood out (for me), and this was when she said, 'you don't get ideas by not working on things'. 

Reflections

I should say at the point that I haven't done Barbara's speech justice.  There were a whole lot of other issues and points that were mentioned but I haven't touched on.  I really enjoyed being taken on a journey that described how programming languages have changed.  I liked the way that the challenges of coding (and the challenge of using particular instructions) led to discussions about modules, abstract data types and then to, finally, object-oriented programming languages.

It's also possible to take a broader perspective to the notion of abstraction, one that has been facilitated by language design.  During Barbara's lecture, I was mindful of two related subjects that can be strongly connected to the notion of abstraction.  The first of these is the idea of design patterns.

Design patterns (Wikipedia) take their inspiration from architecture. Rather than design a new building from scratch every time you need to make one, why not buy a pre-existing design that has already solved some of the problems that you might potentially come up against?  There is a strong parallel with software: developers often have to solve very similar problems time and time again.  If we have a template to work from, we might arguably get things done more quickly and cheaply.

Developers can use patterns to gain inspiration about how to go about solving common problems.  By using well understood and defined patterns, the communication between programmers and developers can be enhanced since abstract concepts can be readily named; they permit short-cuts to understanding.

In some cases, patterns can be embedded into pre-existing code that can be used by developers to kick-start a development.  This can take the form of a framework, software code that solves well known problems that ultimately enables developers to get on and solve the problems that they really need to solve (as opposed to dealing with stuff such as reading and writing to databases).

Abstraction has come a long way in my own very short career as a developer. One of the biggest challenges that developers face is how to best break down a problem into structures that can be represented in a language that a machine can understand.  Another challenge lies with understanding the various tools that developers now have at their disposal to achieve this.

Note: The logo at the top of the blog is used to indicate that this blog relates to a BCS event and this post is not connected with the BCS in any other way. All mistakes and opinions are my own, rather than that of the OU or the BCS.

On 22 April 2013 I managed to find a bit of time to attend a seminar that touched upon some of the themes that I recently blogged about, namely, the way in which technology can be made available (and can be used to help) different groups of users. 

During the day there were a total of five presentations, each of which touched upon many of the different themes that continue to be a strong interest: accessibility, usability, and the way in which technology can potentially help people.  Like so many of these blogs, I'm going to do a bit of a write-up of each presentation, and then conclude with a set of thoughts and points which emerged from the closing discussion.

Older people and on-line social interactions

The first talk of the day was by Shailey Minocha who talked about a project called OCQL (project website) that has been exploring how technology may be able to be used to help and support older people.  If you're interested, I've written a brief blog summary of an earlier workshop that Shailey and her colleagues ran.

Some of the issues that the project aims to explore are the different motivations for being on-line, understanding various advantages and disadvantages and corresponding potential risks and obstacles. Another aspect of the project was to explore whether we might be able to offer advice to designers to allow them to create more usable systems.

Shailey touched upon challenges and dilemmas that users may face.  One challenge is how we might help to create formal and informal support networks to enable users to not only get online in the first place, but also help users to develop their technology skills.  One comment that I noted was that 'buying a [internet] connected computer is easy, it's continuing to use it that is difficult'.

Shailey gave us a flavour of some preliminary findings.  A simple motivation for getting connected is a desire to keep in touch with people, which is connected with the advantage that certain aspects of technology has a potential to reduce social isolation.  Some of the obstacles included the need to gain technical support and the challenges that lie with understanding certain concepts and metaphors that are a necessary part of being on-line.  The perceived risks include fears about a loss of privacy, concerns about knowing who or which organisations or products to trust.  The perceived disadvantages include the fear that technology might take over the lives of the user and this might take the user away from other events and activities that were important.

I remember a really interesting anecdote of a user who started to use an iPad.  The device was used so much (to keep in contact with distant friends and family), that this took away from time socialising with other people who lived nearby.

Shailey also left us some recommendations.  Training, it was suggested, should be personalised to the needs of individuals.  One-off training sessions are not sufficient.  Instead, training should take place over a longer period of time. 

For those who are interested, here are two links to some related resources.  The first is a link to a paper entitled, Conducting empirical research with older people (ORO repository), to be presented at a human-computer interaction (HCI) conference.  The second is a set of web resources (Delicious) that have been acquired during the project.

Towards the end of the presentation I noted two really interesting questions.  The first was, 'to what extent is the familiarity of technology a temporary problem?', and the second question (which is related to the first) is: 'putting age as an issue to one side, how can we all prepare ourselves to become familiar with and work with the next big technological innovation that may be on the horizon?'

The haptic bracelets

Simon Holland, from the department of Computing and Communication introduced us to devices known as the Haptic Bracelet (Music Computer Laboratory).  In essence, a haptic bracelet is a wearable device that you can put on your wrist or ankle.  The word haptic, of course, relates to your sense of touch.  The devices can be controlled so that they can vibrate at different frequencies or produce rhythms.  They also contain accelerometers which can be used to detect movement and gestures. 

My first question was, 'okay, so all this stuff is pretty cool but what on earth can it be used for?'  Simon clearly had anticipated this thought and provided some very compelling answers.  Fundamentally, it can be used with the teaching of music, specifically with the teaching of rhythm, or drumming.  Drum kits have pedals; drummers use both their hands and their feet.  Simon told us that he imagined a device that was akin to an iPod: a form of music player that could help musicians to more directly (and immediately) learn and feel rhythms.  When I started to think about this, I really wanted one - I could imagine that a haptic iPod could add a whole new dimension to the music which I listen to as a travel across London on the tube.

Its one thing listening to a piece of music through headphones, it's something totally different if you're feeling beats and vibrations through the same limbs that could be creating exactly the same rhythm if you were sitting at a drum kit.  I've noted the following quote that pretty much sums it up:  'at best, it goes through your two ears... [but] how do you know what limb is doing what?!'  All this can be linked to a music education approach called Dalcroze Eurhythmics (wikipedia), which was something totally new to me.  Something else that I hadn't heard of before is sensorimotor contingency theory (which I don't know anything about, but whatever it is, it sounds very cool!)

Early on in his talk, Simon suggested that these devices have the potential to be an assistive technology.  One area in which these devices might be useful is with gait rehabilitation, i.e. by providing additional feedback to people who are trying to re-learn how to walk following a brain injury or stroke.  Apparently a metronome is used to help people to move in time with a rhythm, which is a useful technique to regain (and guide) rhythmic motor control.  One of the advantages of using haptic bracelets is that the responses or feedback they could provide could be more dynamic.  Plus, due to the presence of an accelerometer, different feedback might be presented in real-time - but this is mostly conjecture on my part; this is something that is a part of on-going research.

During the final part of Simon's slot, we were given an opportunity to play with some of the bracelets.  Pairs were configured in such a way that we were able to 'send' real-time rhythms wirelessly to another user.  When we 'tapped' on a table, the same 'tap' was picked up by someone else who was wearing another bracelet.

We were introduced to other (potential) uses.  These included sport, gaming, and helping with group synchronisation (or learning) in dance.  Fascinating stuff!

Digital inclusion in the era of the smartphone

Becky Faith is a doctoral student at the Open University who spoke about some of her research interests, and it was all pretty interesting stuff.  One of her areas of interest is how technology (particularly the smartphone) can be used as a means of support for vulnerable people (and how it might be used to gain support from others). 

During Becky's talk I was introduced to a range of new terms, phrases and frameworks that I hadn't heard of before, such as capability theory (which might relate to what rights people may have but are not aware of) and technofeminist theory.   I also noted questions that related to the roles of the private sector versus the state in facilitating access to technology.  This reminded me of one of the drivers for good interaction design and usability: that it can lead to higher levels of productivity, more effective sales and lower costs.  Since goods and services are now on-line, facilitating digital inclusion also, fundamentally, means good business sense.

Becky's session was also very interactive.  We were given a challenge: we had to find out a very specific piece of information using our smartphone (if we had one).  This was to find the name of our MEP.  We were also asked how we might feel if this was our only device.  I, for one, wouldn't be very happy.  I (personally) feel more comfortable with a keyboard that moves than one that is only visible on a screen.

The activity gave way to a debate.  Some users will be faced with fundamental access challenges.  These could be thought of in in terms of the availability of devices or availability of signal coverage.  Ultimately, there is the necessity of understanding the needs of the users, their situations and the kinds of devices and equipment they may have access to.  A thought provoking session.

Careware

Andrew Stuart from Careware (company website) started his presentation by describing a question that he had asked himself, or he had been asked by someone else (I didn't note down the exact wording!).  The question was, 'why can't I find my dog using my iPhone?'.  Dogs go missing all the time.  The company that Andrew established created a GPS dog collar, which allowed dogs to be found using iPhones.  A great idea!

Andrew's company later expanded to create devices, such as a tracking belt, which could be used with vulnerable people.  Tracking dogs is one thing, but tracking people is a whole other issue.  The idea of people wearing tracking devices obviously raises serious ethical issues, but the necessity for privacy needs to be balanced against the desire to ensure that vulnerable people (who are sometimes family members) are cared for and looked after.  It is argued that personal tracking devices can help some people to maintain their independence whilst allowing family members not only peace of mind but also open up new ways to offer personal support.  Users of a personal tracker can, for instance, press a button to alert other people of difficulties or problems.  A GPS belt (instead of a collar) is a device that is very different from a mobile phone (which, arguably, with its in built GPS facilities, can almost do a very similar task).

Andrew's presentation touched on a number of different issues, i.e. centralised telemedicine through call centres versus the use of individual devices for families, and the roles that local authorities may be able to play.  There were also hints of future developments, such as the use of accelerometers to potentially detect falls.

Open University modules such as Fundamentals of Interaction Design touch upon subjects such as wearable computing or wearable interfaces.  It was interesting to see that two presentations demonstrated two very different types of wearable devices - and both presentations were about how they can be used to help people, but in very different ways.

Exploring new technologies through playful peer-to-peer engagement in informal learning

The final presentation of the day was by Josie Tetley, from the Health and Social Care faculty.  Josie spoke of an EU funded project called Opt-In which 'aims to explore if and how new technologies can improve the quality of life of older people' and investigates 'whether existing pedagogic approaches are the best way of enabling older people to learn new technologies'.

Getting people to play with technology was one of the topics that were mentioned, both in a research lab, but also as a part of informal social settings.  Josie also spoke about the different research methods that were used, such as questionnaires, diaries and semi-structured interviews.  One point that I've noted include that some technologies can lead to obvious instances of deskilling, such as overreliance and use of satellite navigation systems.   

Some preliminary findings include that some users are interested in certain applications, notably video telephony applications such as Skype or FaceTime (wikipedia).  Technology, it was also said, can be readily accepted.  I also noted a really good phrase, which is that good technology transcends all age groups.

Summary

All in all, a very interesting event.  I have to say that I wasn't quite sure what I was letting myself in for.  I didn't really know too much about what was on the agenda before the morning of the seminar.  I was more guided by the words of the title that sparked an interest.

The most significant point that I took away from the day was that my conception of what an assistive technology was had been fundamentally broadened.  Another take away point related to the importance of considering the types of learning that are appropriate to different user groups. 

It was also great fun to hear about different research projects and gain an awareness of new ideas and frameworks.  Learning about subjects that are slightly outside our own discipline has the potential to be both rewarding and refreshing.

This is the second post in a series of two about an academic conduct symposium that I attended at the Open University between 20 March and 21 March 2013.

The difference between the first day of the conference and the second was that the first day was more focussed towards the student and the essential role of the associate lecturer.  The second day (in my opinion!) seemed to be more focussed towards those who have the role of dealing with and working with academic conduct issues. Below is a brief summary of the three workshop sessions, followed by some final reflections on the whole symposium.

Student perspectives on good academic practice

Pete Smith from the Faculty of Education and Languages, was the facilitator for my first workshop of the day.  This session addressed a different perspective to all the previous workshops.  It aimed to ask the question:  'what is the published literature on the student perspective?  [or 'views' about academic conduct].  Pete presented what was, in essence, a short literature review of the subject.  I was really struck by the wealth of information that Pete presented (which means that I'm only going to pick out a number of points that jumped out at me).  If you're interested in the detail of the research that Pete has uncovered (which is almost akin to a masters thesis), it might be a good idea to contact him directly.

Some key notes that I've made from the session include the point that learners can perceive themselves in terms of different roles in terms of how they relate to issue of academic conduct.  There are also differences of perceived seriousness and attitudinal differences.  Factors such as topic knowledge, cultural influences, demographic variables, new technology and conflicting advice are all considered to play a part.

Multiple reasons for academic misconduct range from genuine lack of understanding, attempts to gain greater levels of efficiency, temptation, cultural differences and beliefs. 

When looking more deeply at the research it was commented that there was a lack of robust evidence about the success of interventions.  We don't know what works, and also we don't have consistent guidance about how to begin to tackle this issue.  One important perspective is that everyone is different and knowledge and understanding of a learner is needed to make the best judgement about the most approach to take.

What resources are available?

This session was facilitated by Jenny Alderman from the Open University Business School and another colleague who works in the Academic Conduct Office.

One of the reasons why academic conduct is considered to be so important is that there is an important principle of ensuring that all students are given fair and equitable treatment.  Jenny reminded us that there are considerable costs in staffing the academic conduct office, running the central disciplinary and appeal committees and supporting the academic conduct officers.

An interesting debate that emerged from this session related to the efficacy of tools.  Whilst tools such as TurnItIn can be useful, it is necessary to take time to scrutinise the output.  There will be some clear differences between submissions for different faculties.  Some more technical subject (such as mathematics) may lead to the production of assignments that are necessarily similar to one another.  This has the potential to generate false positives within plagiarism detection systems.

Key resources: code of practice for student assessment, university policy on plagiarism, developing good academic practice website (which was linked to earlier), and the skills for study website which contains a section entitled developing academic English (Skills for Study).

Other resources that could be useful include Time Management Skills (Skills for Study), Writing in your own Words (Skills for Study), Use of source Materials (Skills for Study) and Gathering Materials for preparing for your assignments (Skills for Study).

The library have also produced some resources that can be useful.  These include a video about avoiding plagiarism (which features 'Bob').  The library have some resources about digital literacy entitled 'being digital'.  There is also a plagiarism pathway (Being Digital, Open University Library), which contains a number of activities.  (At the time of writing, I hadn't seen these before - many of these resources were pretty new).

As an aside, I had some discussions with colleagues about the need to more fully embed academic English into either individual modules or programmes of study, and I was directed to a module entitled L185 English for Academic Purposes.  Two fundamental challenges that need to be overcome include that of will and resource.  This said, there are three sections of the L185 module that are available freely on-line through OpenLearn.  These are: Paraphrasing Text, Summarising Text and How to be a Critical Reader.

Since the workshop, I've also been directed towards a resource entitled, Is my English good enough?  This page contains a link to the English for OU study pages.

What works?

The final session, facilitated by Jonathan Hughes, was all about what interventions might successfully nurture good academic practice (and what we might be able to learn from student casework).

Connecting back to earlier debates surrounding the use of technology to detect plagiarism, the issue of spurious reports discussed.  In instances where we are unsure what the situation was, we were reminded that the right thing to do is refer cases to the faculty academic conduct officer. 

I've noted that academic conduct is an issue of education and an important part of this is sharing the university view of what plagiarism is.  It is also connected with the judicious application of technology in combination with human judgement and adoption of necessary of process to ensure appropriate checks and balances.  (Again, all this is from the notes that I made during the event).

During this session I remember a debate about whether it was possible to create something called a 'plagiarism proof assignment'.  One contributor said, 'if you write a question, if you can do a quick internet search for an answer, then it is a poor question'.  The point being that there is an intrinsic connection between academic conduct and good instructional design.

One question that arose was whether the university should be telling our students more about tools such as TurnItIn and Copycatch.  Another approach is, of course, to have students submit their own work through these detection tools and also permit them to see their reports (which is an approach that other institutions adopt). 

Final thoughts

This conference or symposium was very different to other conferences I've been to before.  It seemed to have two (if not more) main objectives.  The first was to inform other people within the university about the current thinking on the subject and to share more information about the various policies and procedures that the university employs.  The second was to find a space to debate the different conceptions, approaches and challenges which come with the difficult balancing act of supporting students and policing academic conduct.

In terms of offering a space that informs and facilitates debate, I felt the conference did a good job, and I certainly feel a bit more equipped to cope with some of the challenges that I occasionally face.  Moving forward, my own objective is to try my best to share information about the debates, policies and resources with my immediate colleagues. 

I came away with three take away points.  The first relates to the definition of what 'plagiarism' is.  It now strikes me that there are almost two different definitions.  One definition is the internal definition which acknowledges that students can both deliberately and inadvertently fail to acknowledge the work of others.  The other more common definition is where plagiarism can be interpreted (almost immediately) as maliciously and deliberately copying someone else with the clear intention of passing someone's work off as your own.  Although the difference is one that is very subtle, the second definition is, of course, much more loaded.

The second take away point lies with the policies and procedures.  I now have a greater understanding of what they are and the role of the academic conduct office.  I can clearly see that there are robust processes that ensure fairness in academic conduct cases.  These processes, in turn, help to maintain the integrity and validity of the qualifications.

The final take away point is that I am now a lot clearer in understanding what I need to do, from my perspective, to help both students and tutors deal with different types of academic conduct.

Copies of slides and videos are now available on the Academic Conduct Site (Open University staff only)

On 12 February 2013 I volunteered at a joint Open University and UCL event on 12 February 2013 which aimed to introduce aspects of computing and engineering to school students.  This was the first time I had been involved with this type of event.  I have started to view outreach (in the broadest sense) as something that is something that is increasingly important to do (and this is something that I have written about in an earlier blog).  So, if you're interested in hearing some about the outreach stuff that I've recently heard about, the previous blog I've posted might (or might not!) be of interest.

Structure

I learnt about this event by a colleague who was canvassing for volunteers.  Upon accepting his challenge I quickly discovered that I was to play a tiny part of what was a much bigger event and soon heard rumours that students were coming to UCL to hear about other subjects such as chemistry and engineering.  My own role was to offer some support and guidance to students who wished to learn a little bit about computing and information technology.

Not only was this, for me, my first ever time being involved in an outreach or engagement event, it was also my first ever time on the UCL campus: it was massive!  I found myself being ushered into a large computer suite in the basement of one of UCL's impressive buildings.  Within moments, our lead facilitator and lecturer, Arosha Bandara, started to outline the plan for the day.

The focus on the day was the programming language Sense, a language that is used with the Open University module TU100 My Digital Life which is a first level undergraduate module in computing.  One of the key aspects of Sense is that it works with a bit of electronics that allows different types of measurements to be made.  Arosha talked us through a program that simulated a simple etch-a-sketch game.  Students would be asked to make a change to the program so that it would work properly - they were required to do some software maintenance!  During the second part of the day, students were then required to get together in groups to think of how to the language and the sensors to do something fun.

The talking bit...

The morning began with Arosha outlining the broad concept of Ubiquitous computing (Wikipedia), namely, that computers can be everywhere, can contain sensors and can be embedded within the environment.  Arosha then introduced a programming problem (in the form of an etch-a-sketch game).  Everyone was taken through different parts of the Sense programming environment.  Key elements such as buttons, instruction palettes and sprites (graphics) were introduced.

Students were then directed to some key parts of the game that accepted inputs from Sense hardware.  Students were then shown, step-by-step, how to make a change to the game to modify the behaviour of an on-screen pen.  They could immediately see the effect of changes to their programs.  Further modifications included adding some conditions that enabled their game programs to respond to noises (such as clapping!)

The projects bit...

There were loads of things to take in during the first part of the morning.  There was a whole new programming environment, there was the concept that a computer can receive and work with signals from the outside world, and the idea that a program can be formed out of groups of instructions.

The second part of the day was all about being imaginative, thinking about the different kinds of inputs and outputs that the electronics allow, and trying to think of some kind of application or demonstration.  Students were assigned to small groups and were encouraged to come up with different ideas.

The group that I was assigned to came up with the idea of trying to build some kind of 'human sensor', perhaps creating an infra-red trip wire (the Sense board came with a number of different sensors and outputs - one of them being an infrared transmitter or detector).  We collectively thought about the different cables and sensors that we had at our disposal before beginning to play with what kinds of signals (or numbers) we could detect from the outside world.  We got a fair way with this task before our time was up.

Reflections

It was a fun day!  Although there was limited time to do real stuff, the tiny team that I was allied to wrote some simple program code that allowed a heat sensor to work.  The Sense board represented a connection between the magical world of code and software to the physical world, where measurements could be made.

One of the biggest challenges of the day was to convey such a lot of (often quite difficult) theory in such a short amount of time.  Arosha was charged with telling our students something about the different types of programming constructs, variables and graphics.  Although this was necessary to get to the point where we could all do some fun stuff (modify our program), the way that hardware was used with software certainly facilitated engagement and helped to focus our attention.

I liked the way the idea of ubiquitous computing was used as an introduction, but one additional might have been to emphasise the extent that we are surrounded by computers.  The moment you receive a telephone call, there is an unknown number of computers all working together to deliver your telephone call.  There's the computer in your mobile phone, there's a computer in the base station which speaks to other computers... at the other end, there is a similar situation.  Also, turning on the TV means starting up a pretty powerful computer that is performing millions of instructions a second which coverts signals from one format to another.  Their ubiquity and invisibility is astonishing.

What is also astonishing is that the fundamental principles of computer programming that are exposed by the Sense programming language is also shared amongst all these devices and systems.  In the same way we have ubiquitous computing, we also have ubiquitous code; computer software that run anywhere.

Being involved in this day took me back in time to the days when I first got my hands on a computer.   Although the form of a computer has changed immeasurably, some things have not changed.  Computers remain very particular and pedantic - they require patience.  It's also important to remember that to learning how to work with code can and should be fun.  But when you've created a world out of code and you understand how things work, working with them can be immeasurably rewarding too.

The 24th Psychology of Programming Interest Group workshop was held at London Metropolitan University between 21st and 23rd November 2012.  I wasn't able to attend the first day of the workshop due to another commitment, but was able to attend the second and third days (this is a shame since I've heard from the other delegates that the first day was pretty good and yielded a number of very thought provoking presentations and discussions).  This blog post is a summary of the days I managed to attend.  I'm sharing this post with the hope that this summary might be useful to someone.

Day 2: Expertise, learning to program, tools and doctorial consortium

Expertise

The first presentation of the day was entitled, 'Thrashing, tolerating and compromising in software development' by Tamara Lopez from the Open University.  I understand thrashing to be the application of problem solving strategies in an ineffective and unsystematic way, and tolerating to be working with temporary solutions with the intention of moving a solution along to another state, and compromising: solving a problem but not being entirely happy with its solution.  An interesting note that I've made during Tamara's presentation relates to the use of feelings.  I have also experienced 'thrashing' in the moments before I recover sufficient metacognitive awareness to understand that a cup of tea and a walk is necessary to regain perspective.

The second presentation of the day was by Rebecca Yates, from LERO based at the University of Limerick.  Rebecca's talk was entitled, 'conducting field studies in software engineering: an experience report' and her focus was all about program comprehension, i.e. what happens when programmers start a new job and start to learn an unfamiliar code base.  I made a special note of her points about the importance of going out into industry and the importance of addressing ethical issues. 

One of the 'take away' points that I got from Rebecca's talk was that getting access to people in industry can be pretty tough - the practical issues of carrying out programming research, such as time, restrictions about access to intellectual property and the importance of persuasion (or making the aim of research clear to those who are going to play a part in it) can all be particularly challenging.

Learning to program

Louis Major, from the University of Keele, started the second session with a paper entitled, 'teaching novices programming using a robot simulator: case study protocol'.  Louis told us about his systematic literature review before introducing us to his robot simulator which could be used to create programs to do simple tasks such as line following and line counting.  Louis also spoke about his research method, a case study approach which applied multiple methods such as tests and interviews.

Louis also spoke about the value of robots, that they were considered to be appealing, enjoyable, exciting and robotics (as a whole subject) had a strong connection with STEM disciplines (science, technology, engineering and mathematics).  The advantage of using simulations is that there are fewer limitations in terms of space, cost and technical barriers.

A couple of months after the workshop I was reminded about the relevance of Louis's research after having been tangentially involved in an introductory Open University module, TM129 Technologies in Practice, which also makes use of a robot simulator.  Students are also given the challenge of solving simple problems, including the challenge of creating line following robots. 

The second talk in this part of the workshop was by PPIG regular, Richard Bornat.  Richard's talk, entitled 'observing mental models in novice programmers' built on earlier work that was presented at PPIG where Richard and his colleague Saeed had designed a test that was claimed could (potentially) predict whether students were able to grasp some of the principles of programming. 

An interesting observation was that when it comes to computer programming the results sometimes have a bi-modal distribution.  What this means that if student pass, they are likely to pass very well.  On the other hand, there is also a peak in numbers when it comes to students who struggle.  During (and after) his talk, he presented that some students found some of the concepts that were connected to programming (such as the assignment operator) fundamentally difficult.

Paul Orlov, who joined us all the way from St. Petersburg, spoke about 'investigating the role of programmers peripheral vision: a gaze-contingent tool and experimental proposal'.  Paul's talk connected with earlier research where experimental tools, such as a 'restricted focus viewers', were used in conjunction with program comprehension experiments. Paul's talk inspired a lot of debate and questions.  I remember one discussion which was about the distinction between attention and seeing (and that we can easily learn not to attend to information should we choose not to).

Ben Du Boulay, formerly from the University of Sussex, was our discussant.  Ben mentioned that when it came to interdisciplinary research conducting systematic literature reviews can be particularly difficult due to the number of different publication databases that researcher have to consider.  Connecting with Richard's paper, Ben asked the question about what might be the fundamental misunderstandings that could emerge when it comes to computer programming.  Regarding Paul's paper which connects to the theme of perception and attention, Ben made the point that we can learn how to ignore things and that attention can be focussed depending on the task that we have to complete.  Ben also commented on earlier discussions, such as the drive to change the current computing curriculum in schools.

One thing that learning programming can do for us is help to teach us problem solving skills.  There is a school of thought that learning programming can be viewed as how Latin was once viewed; that learning to program is inherently good for you. Related points include the importance of task and the relationship to motivation.

Tools

Fraser McKay from the University of Kent presented, 'evaluation of subject-specific heuristics for initial learning environments: a pilot study'.  In human-computer interaction (or interaction design), heuristics are a set of rules of thumb that help you to think about the usability of a system.  General heuristics, such as those by Nielsen are very popular (as well as being powerful), but there is the argument that they may not be best suited to uncovering problems in all situations. 

Fraser focused on two environments that were considered helpful in the teaching of programming: Scratch (MIT) and Greenfoot.  Although this was very much a 'work in progress' paper, it is interesting to learn about the extent to which different sets of heuristics might be used together, and the way in which a new set of heuristics might be evaluated.

Mark Vinkovitis presented the work of his co-authors, Christian Prause and Jan Nonnen, which was entitled, 'a field experiment on gamification of code quality in Agile development'.  Initially I found the term 'gamification' quite puzzling, but I quickly understood it in terms of, 'how to make software development into a game, where the output can be appreciated and recognised by others'.

The idea was to connect code development with the use of quality metrics to obtain a score to indicate how well developers are doing.  This final presentation gave way to a lot of debate about whether developers might be inclined to develop software code in such a way to create high rankings.  (There is also the question of whether different domains of application will yield different quality scores).  I really like the concept.  Gamification exposes of different dimensions of software development which has the potential to be connected to motivation.  It strikes me that the challenge lies with understanding how one might affect the other whilst at the same time facilitating effective software development practice.

Doctorial consortium presentations

Before the start of the workshop on Wednesday, a doctorial consortium session was held where students could share ideas with each other and discuss their work with more experienced (or seasoned) researchers.  This session was all about allowing students to share their key research questions with a wider audience.

Presentation slots were taken by Louis Major, Frazer McKay, Michael Berry, Alistair Stead, Cosmas Fonche and Rebecca Yates (my apologies if I've missed anyone!)  Other research students who were a part of the doctorial consortium included Teresa Busjahn, Melanie Coles, Gail Ollis, Mark Vinkovits, Kshitij Sharma, Tamara Lopez, Khurram Majeed and Edgar Cambranes.

Day 3: Tools and their evaluation and keynotes

Tools and their evaluation

The first presentation of the final day was by Thibault Raffaillac who presented his research, 'exploring the design of compiler feedback'.  I enjoyed this presentation since the feedback that software tools offer developers is fundamental to enabling them to do the job that they need to do.  A couple of questions that I've noted from Thibault's presentation included the question of 'who is the user?' (of the feedback), and what is their expertise.  Another note is that compilers (and other languages) always tend to give negative points and information.  It strikes me that languages offer an opportunity for programmers to interrogate a code-base.  Much food for thought!

Luis Marques Afonso gave the next talk, entitled 'evaluation application programming interfaces as communication artefacts'.  Understanding API usability has a relatively long history within the PPIG community.  The interesting aspect of Luis's work is that three different evaluation techniques were proposed:  semiotic inspection method (which I had never heard of before), cognitive dimensions of notations (Wikipedia) and discourse analysis (Wikipedia).  It was interesting to hear of these different methods - the advantage of using multiple approaches is that each method can expose different issues.

The final paper presentation, entitled 'sketching by programming in the choreographic language agent' was given by Luke Church, University of Cambridge.  Luke described working amongst a group of choreographers.  It was interesting to hear that the tool (or language) that had been created wasn't all about representing choreography, but instead potentially enabling choreographers to become inspired by the representations that were generated by the tool.  Luke's presentation created a lot of interest and debate.   

Keynote: extreme notation design

A computer programming language is a form of notation.  A notation is a system that can be used to represent ideas or actions and can be understood by people (such as music) or machines (as in computer programming), or both.  Thomas Green proposed a set of 'dimensions' or characteristics of notation systems which relate to how people can work with them.  These dimensions can be traded-off against each other depending upon the nature of the particular problem that is to be solved.

One challenge is: how can we understand the characteristic of trade-offs?  Alan Blackwell gave a keynote talk about a programming language that was controversially described as being a hybrid of Photoshop and Excel.

Palimpsest used the idea of different layers which could then contain different elements which could interact with each other (if I understand things correctly).  Methodologically speaking, the idea of creating a tool or a language that aims to explore the extremes of language design is an interesting and potentially very powerful one.  My understanding is that it allows the language designer to gain a wealth of experience, but also provides researchers with an example.  Perhaps there is an opportunity for someone to write a paper that compares and collates the different 'extremities' of language design.

Panel: coding and music

The final session of the workshop was all about programming, music and performance.  We were introduced to a phenomena called 'live coding', which is where programmers 'perform' music by writing software in front of a live audience. The three presentations which were contained within this final part of the day were all slightly different but all very connected.

Alex Mclean

Alex Mclean from the University of Leeds presented two demonstrations and talked about the challenges of live coding.  These included that manipulating and working with music through code is an indirect manipulation.  Syntactic glitches can interrupt the flow of performance and there is the possibility that being wrapped up within the code has the potential to detract from the music.

Live coders can also improvise with musicians who play 'non-programming language' (or 'real') instruments.  Since the notion of 'live' can have different meaning (and can depend on the abstractions that are contained within a language), challenges include the negotiation of time and harmony.  Delays can exist between the having a musical idea and realising it.

Alex mentioned Scheme Bricks, which has been inspired by Scratch (and Sense) which allows you to drag and drop portions of code together.  This also made me realise that if there are two live coders performing at the same time they might use entirely different 'instruments' (or notation systems) to each other. 

Thor Magnusson

Thor Magnusson from the University of Brighton introduced us to a language called ixi that has been derived from SuperCollider (Wikipedia).  Thor set out to make a language that could be understood by an audience.  To demonstrate this, Thor quickly coded a changing of drum and sound loops using a text editor using a notation that has come clear and direct connections to music notation.  Thor spoke of polyrhythms and code to change amplitude, to create harmonics and sound that is musically interesting. 

What I really liked was the metaphor of creating agents which 'play' fragments of code (or music).  Distortions can be applied to patterns and patterns can be nested within other patterns.  Thor also presented some compelling description of the situations in which the language is used; 'programming in a nightclub, late at night, maybe you've had a few beers; you're performing - you've got to make sure the comma is in the right place'.  For those who are interested, you can also see a video recording of Thor giving a live coding performance (YouTube).  In my notebook I have written something that Thor must have said: 'I see code as performance; live coding is a link between performance and improvisation'.

Sam Aaron

When Sam began his short talk, I couldn't believe my eyes - he was using a text editor called Emacs! (Wikipedia).  The last time I used Emacs was when I was a postgraduate student where it persistently confused me.  Emacs, however, uses a language called Lisp which is particularly useful for live coding, since it is a declarative language. 

During his talk Sam gives a brief introduction to Overtone.  You can see a video of a similar introduction to overtone through Vimeo.  One thing that did strike me was way in which aspects of music theory could be elegantly represented within code.

Discussion

This final part of the workshop gave way to quite a lot of energetic debate.  There appeared to be a difference between those who were thinking, 'why on earth would you want to do this stuff?' and, 'I think this stuff is really cool!'  When it comes to live coding there is the question of who is the user of the language - is it the performer, or is it the listener, or viewer (especially if a live coding notation is intended to be understandable by a non-musician-coder)?

But what of the motivations of the people who do all this cool stuff?  When it comes to performance there is the attraction of 'being in the moment', of using technology in an interesting and exciting way to creating something transitory that listeners might like to dance to.  It certainly strikes me that to do it well requires skill, time, persistence and musicality; all the qualities that 'traditional' musicians need.  Live coders can also face the fundamental challenge of keeping things going when things begin to sound a bit odd, to create new and creative code structure on-the fly, and an ability to move from one semi-improvised (by means of programming and musical abstraction) to another.

Other than the performance dimension, there is the intellectual attraction of changing and challenging people's perceptions of how software and programming languages are thought of.   Another dimension is the way that technology can give rise to a community of people who enjoy using different tools to create different styles of music.  All of the tools that were mentioned within the final part of the day are free and open source.  Free code, it can be said, can lead to free musical expression.

Reflections

Like other PPIG workshops this workshop had a great mix of formal presentations, more informal doctorial sessions mixed with many opportunities for discussion.  I think this was the first time that the workshop was held at London Metropolitan University.  Yanguo Jing, our local conference chair, did a fabulous job at ensuring that everything ran as smoothly as possible.  Yanguo also did a great job at editing the proceedings.  All in all, a very successful event and one that was expertly and skilfully organised.

There are two 'take home' points that have stuck in my mind.  The first is that programming languages need not only about programming machines; through their structures code can also be used as a way to gain inspiration for other endeavours, particularly artistic ones.  

The second point is that programming can be a performance, and one that can be fun too.  The music session with certainly stick in my mind for quite some time to come.  Programming performances are not just about music - they can be about education and creation; code can be used to present and share stories.