Personal Blogs

Over the last few years, I’ve been tutoring M250 Object-oriented Java programming. During some of the tutorials that I facilitate, I share set of tips with students. What follows is a brief summary of the tips, and some accompanying notes. I hope these might be helpful to anyone studying M250, or any other OU module that involves a bit of programming.

1. You can't learn programming by reading the course books. You need to do it. You need to spend serious time playing.

It’s important to spend some quality time with the language that you’re using and the integrated development environment that you’re using to manipulate that language. You can only properly learn to get a feel for both object-oriented programming, and programming constructs by using them. Get a feel for the words and the punctuation that you’re using. Also, instrument your code with print statements, and consider using a debugger to really see what is happening. Play and mess about. Getting yourself in a tangle is all a part of the process. There is another related tip is: do one thing at a time.

2. Use the examples as a starting point; then go further.

Start to play, and then to play a bit more, and see where this will take you. Invariably, you’ll end up writing more and more code. This means that you’ll get to a point where you need to think about how to make things a bit easier again. If you’ve found a problem in a textbook, think about how might alter that problem to solve a slightly different problem, or a more general problem.

3. Accept that things are going to be uncomfortable sometimes: it’s impossible to understand everything at once, things will only make sense after you've spent the hours playing and learning.

There’s a lot going on with object-oriented programming. 

There’s the key ideas of types (or classes), objects, attributes and member functions. Not to mention, of course, how objects might work with each other to solve problems. Plus, there’s constructors, libraries and iterators.

It’s all a lot of take in, and it isn’t a surprise if you start to feel a bit overwhelmed. If you see difficult things and struggle to understand what is going on, accept certain things at face value for the time being; full understanding will come a bit later.

4. Always make a backup copy.

This relates to the first tip: playing.

When you play with code, you can also mess things up and get yourself in a tangle, especially if you follow tip 2 where you build on earlier things you have earlier done. As you figure everything out, make sure you take a backup copy of your code. If you’re making lots of changes, you might want to create different versions of your code. You might create a copy, save all your files in a new directory and call it ‘version 1’, ‘version 2’ etc. 

Also, do make sure you save your files in a location that is different your computer, just in case your computer goes wrong. A bit later on, you might start to use something called GitHub.

5. Try to explain your code to someone else. (Or, get a plant, and call it Dijkstra)

Sometimes coding presents some real puzzles; sometimes there’s something that isn’t quite understood, or something doesn’t quite work as expected. As a developer, I’ve sometimes had bugs which have been both weird and persistent. When this happens, I would “have a chat with Dijkstra”.

Let me explain. I once heard that in a computer lab in Cambridge, there was a houseplant, which was named called Dijkstra, named after a famous Dutch computer scientist called Edsger Dijkstra. If a student was struggling with some code, and asked themselves the question “why doesn’t this work?” they were told to explain their code to Dijkstra. The very act of explaining your code, a step at a time, has the potential to help you to understand what is happening, and what the problem is. 

If you have a partner, sibling, or pet, they can all become Dijkstra.

6. If you keep going over the same things time and time again, don’t be afraid to step away from it. Sleep on it, and come back to it with fresh eyes.

In computing, there’s a term called thrashing, which is sometimes used to describe a phenomenon that occurs with computer operating systems. This needs a bit of explanation, so please do bear with me.

Your computer has two types of memory: random access memory, and backing store memory. Random access memory is fast and expensive, but your computer doesn’t have very much of it. In contrast, there is typically a lot backing store memory in your computer (which used to be held on a magnetic disk), which is pretty inexpensive in compared to random access memory. Your computer operating system provides programmers with a lot more memory than is actually available through random access memory. It does this by moving data between different types of memory.

Thrashing is what happens when your computer operating system causes your computer to spend all its time trying to get things done by moving data between different types of memory, rather than doing the work that needs to be done.

If you find yourself ‘thrashing’, you need to reboot. You need to step away from your code and come back to it after a break.

I remember once having an idea about how to solve a coding problem when I was having a shower. A break can do you the world of good. This point leads me to my final point.

7. Have fun, and be gentle with yourself.

Everyone learns at different speeds; learning isn’t a race, so do be gentle with yourself. It’s important to have fun too. I remember that one of my first object-oriented programs was a simulated card game that was based on a television gameshow. It was fun to write, and it was fun to play. This point about playing takes us back to the first point: you can't learn programming by reading the course books; you need to find the time to play.

In February 2018 I went to a 'Teaching programming across STEM' workshop that was organised by my colleague Michel Wermelinger. The aim of the workshop was to get different colleagues from different parts of the STEM faculty together to share experiences about how they teach programming, raise awareness of each other’s plans, discuss different types of provision, and to share experience and examples.

What follows is a rough summary of the notes that I took during the day, which were augmented by having a quick look at some of the slides that were prepared for the workshop (OU staff link). The aim of these notes are to help me remember what happened, and to provide a future reference for anyone who might be interested in the teaching and learning of programming at the OU. Since there was a 6 month gap between the event and the writing of the blog, I’m sure I’ve forgot some important elements and aspects, but I hope they are both pretty accurate and useful.

Introduction

The event was introduced by Michel, who said that the day was split into two parts, a morning ‘supply side’ section (which included a series of talks), and an afternoon ‘the demand side’ section, which included networking and workshop discussions. Michel kicked off the event by talking about OpenLearn materials that contain programming.

OpenLearn materials

OpenLearning is an Open University website that offers free online short courses for anyone who might be interested. It is sometimes used to share excerpts of real OU modules but it also contains self-contained short courses. If you have an interest in an academic subject, the chances are that there will be an OpenLearn course that might tell you a little bit about it. It is, perhaps, not much of a surprise that there are OpenLearn resources about programming. 

Simple Coding

Michel introduce us to something called an ‘hour of code’ introduction to programming using Python 2, also known as Simple Coding (OpenLearn). Simple coding introduces students to the fundamental concepts of variables, expressions, loops, if, lists, and function calls. It contains one problem throughout: keeping and maintaining a restaurant bill.

I made a note that this was a part of the BBC Make It Digital season. To complement this, Michel has written a short blog post about Trinkets. Finally, students are also encouraged to share their code on social media.

Learn to Code for Data Analysis

Another OpenLearn resource is called Learn to Code for Data Analysis (OpenLearn). This course started life as a 4-week 20 to 30 hour Futurelearn MOOC. It makes use of Python 3, function definitions and loops. It also makes use of the R-like Pandas library which is used for data analysis. It also uses (I’m copying from my notes here) Jupyter notebooks with Anaconda or cocalc.com.

The courses applies something called First Principles of Instruction and adopts a problem-driven approach, where students are given a weekly project to clean data, merge data and manipulate data. Students are asked to manipulate authentic real open data from organisations such as the World Health Organisation and the UN. 

TM112 Introduction to Computing and IT 2

TM112 Introduction to Computing and IT 2 was introduced by Paul Piwek, module chair. Paul explained that TM112 builds on TM111 and prepares students for level 2 study where students go onto study M250 (which uses Java) and M269 (which makes use of Python), before making their way to TM351 (which is mentioned later).

The module has three themes: essential information technologies, problem solving with Python, and information technologies in the wild.  There are 3 spiral bound books, so students can put them down next to their computer, and practice typing in code.

Students will be using turtle graphics with Python 3, Baby Pandas (a library that is used for data processing and analysis), Jupyter notebooks and an editor like IDLE. The module places particular emphasis on the teaching of problem solving skills and the construction of algorithms. Students are given programming practice and assessment by using data from the Office of National Statistics.

There are also formative quizzes with CodeRunner, which are marked for engagement to help students build mental models of what happens at an abstract level when programs are run.

SM123 Physics and Space

Jimena Gorfinkiel introduced SM123 Physics and Space which is studied after students have completed S111 Questions in Science.

Students are given 4 weeks of Python 2 programming that is based on the science they are learning. Currently, there are no other programming at level 2 and level 3 physics or astronomy pathways. The aim is to help students get a feel for programming and data analysis is all about. There is no expectation of developing specific competencies, but the aim is to help students understand principles of algorithm design.

The module design is built on ideas from other introductory materials, i.e.it makes use of Trinket (trinket.io) and the teaching approach is to scaffold the student’s learning by providing activities and examples.

TM129 RobotLab

Jon Rosewell introduced TM129 Technologies in practice, a module that has three different 10 point bits: a section on programming, a section on networking, and a section about the Linux operating system.

The programming bit has a simulator for a small Lego robot which is called RobotLab and robotics is a used as a way to introduce students to programming and to provide a useful context. It introduces basic control structures but doesn’t introduce students to data structures. Students are asked to run and watch the running of code, adapt code, and complete an open challenge.

Like Scratch, RobotLab is a drag and drop environment, but the environment can also create text programs which students see when they are expose to Python code. A comment I noted was that practical labs are important: ‘If you have simulation, and you do it well, there are opportunities for learning’.

An issue with the approach is that RobotLab is not a recognised language and is now showing its age. Support for RobotLab will finally end with the February 2019 presentation of TM129.

M250 Object-Oriented Java Programming

Anton Dil introduced M250 Object-Oriented Java Programming. In some cases, students study M250 in parallel to M269, which will be described in the next section.

M250 uses Java and adopts an ‘objects first’ approach. Students are introduced to key object-oriented (and Java) concepts, such as protocols and attributes, classes, inheritance, composition, interfaces, access levels and the catching and throwing of errors. Other topics include collections, file input and output. There are also optional sections on design by contract and assertions.

Students use a range of different tools, such as the Java Development Kit (JDK) 7 and a graphical object-interaction environment, called BlueJ which enables students to manipulate objects and visualise relationships between classes. Some of the teaching makes good use of examples, such as illustrating methods using bank accounts, demonstrating classes by creating unexpected types of frogs, and demonstrating a marionette that is made from simple shapes.

Like other OU modules, Coderunner is used for interactive computer marked assessments. An important part of the assessment is, of course, through a series of TMAs that have increasing weighting. Looking towards the future, a future assessment principle may be to have less reading and more writing code and to encourage the social dimension in programming. On this point I made a note to myself about whether the concept of pair programming might be something that could be introduced; doing it virtually and at a distance may provide some interesting but unique challenges.

M269 Algorithms, data structures, computability

Michel Wermelinger introduced M269 Algorithms, data structures, computability, a module that gets to the heart of computer science. It introduces students to data structures, queues, how searches work, sets, binary trees, hash tables, graphs, generic techniques, approximation, complexity, big O notation, heuristics, and genetic algorithms. Needless to say, it’s also all about programming. 

The tools used in M269 includes Python 3, Komodo edit, and Coderunner is used for all the TMA questions. For students who haven’t come up through TM112, it contains a Python crash course in week 2.

Given its challenging subject matter, M269 is a marmite course; some students respond well to the challenges it presents, whereas others offer more robust opinions. From a personal perspective, I remember studying a similar module when I was an undergraduate in the 1990s. I found it a challenging subject, but I later appreciated its importance and value when I became a professional software developer.

Open University Summer of Code

Neil Smith introduced an initiative called the Advent of code. Advent of Code is described as: “a series of small programming puzzles for a variety of skill levels. They are self-contained and are just as appropriate for an expert who wants to stay sharp as they are for a beginner who is just learning to code. Each puzzle calls upon different skills and has two parts that build on a theme.” Neil also told us about that there is something called the Google Summer of Code, which students can apply to.

Computing and Communications students are invited to take place in a voluntary programming challenge called the Summer of Code that is designed to give students programming practice. Students are sent a two part problem, every Monday to Friday for two weeks. All in all, there will be ten problems. An interesting observation is that if students do 2, they will invariably do all 10. Another observation was that some students were passing programming assessments but not being able to solve these problems; perhaps practice is the key and problem solving can and should be taught explicitly.

TM351 Data management and analysis

Alistair Willis introduced TM351 Data Management and Analysis. M250 and M269 are prerequisites for TM351. TM351 isn’t a programming module as such, but it does expect programming competence that is commensurate with level 3 student. The module explores the data lifecycle: the acquisition, preparation, analysis and presentation of data. Python is used for acquiring and cleaning data, and databases are used for storage. The module also demonstrates simple machine learning, statistical analysis and graph plotting.

TM351 uses Python 3, PostgreSQL, MongoDB, Pandas, Mathplotlib and Jupyter notebooks. A point that I clearly noted was that students needed to learn how to use a library and not just a language.

Like M269, it is also a ‘marmite module’ and offers students with some particular challenges. It requires students to combine different techniques together to form solutions. In some cases students don’t have adequate coding skills and may also lack critical skills so they can apply the right techniques.

An interesting point I noted was that the Python requirements for TM351 are less than what is required for A-level. Another comment I note down was: perhaps more needs to be done to help students to prepare for this module, or the preparation needs to be done differently. In some respects, this is where TM112 Introduction to computing and information technology 2 will play an important role.

Python programming in S818

Andrew Norton and Mark Jones introduced S818 Space science which is a 60 point module that forms Stage 1 of the MSc in Space Science and Technology (F77). The module presents an introduction to Space Science and Technology, Apollo 11, Gaia  and Rosetta probes, and the Curiosity Mars rover.

S818 is linked to the OpenSTEM lab. The programming that is carried out as a part of the module is linked to the physics that is applied; Python is used as a tool to work through data. Students are directed to “Learn to Code for Data analysis” on OpenLearn, that was previously mentioned by Michel.

During Weeks 1 to 6, students are exposed to Jupyter notebooks and Pandas. Examples include a section on space weather and looking at data from space weather satellites. In addition to these activities, students are asked to carry out straight line fitting to data (SciPy, matplotlib), plot data of increasing complexity (using matplotlib) and a numerical solution of Kepler’s equation in orbital dynamics (I’m not sure what this means).  Students are also expected to use Python to handle and present results, even when they aren’t explicitly asked to do so. 

Python and accompanying tools

Tony Hirst from the School of Computing and Communications gave a talk about the different tools and technologies that could be used with Python. One thing Tony did was to explain that Jupyter is an ecosystem of related bits, based on Python. One of those bits is known as iPython. 

Echoing earlier presentations, Tony emphasised the importance of libraries and packages. There were packages that could be used to define and simulate circuits. There were packages that related to chemistry, where users could type in the name of a compound and software would ask the web for the structure. There were packages about astronomy and also packages about music, which could work with musical representations and create playable midi files.

We were told about V-REP a Virtual robot experimentation platform, and Binder, a way to connect Jupyter notebooks to GitHub version control software.

I made a note that Tony had also been looking at running software on OpenStack, which is an important part of TM352 Web Mobile and Cloud technologies.

The demand side

After a break for lunch, it was onto a series of short 2 minute presentations by ‘various artists’ that were broadly entitled ‘the demand side’ for the simple reason: these may be modules or module that need to apply programming in some way. 

SXPA288 Practical science: physics and astronomy

Sheona Urquhart spoke about second level physics and astonomy module, SXPA288 Practical science: physics and astronomy. I made a note of some interesting words: “the thing that freaks them out is the terminal window” and “this is not a programming course … Excel is just grim”. I’m assuming that this comment is linked to the need to perform data analysis.

T312 Electronics

T312 Electronics, which was introduced by Jane Bromley, is a new module that has just started production. I noted down that there might be an opportunity to draw on the Python electronics libraries that Tony had mentioned, and Python might also be used for hands on experience of signal processing.

M346 Linear statistical modelling

This module was introduced by Karen Vines, and is currently going through a rewrite. The earlier version used to use some software called Genstat (if I’ve made a note of this correctly), but there is a plan to move to the R programming language (wikipedia) which was said to be ‘command line’. The emphasis on this module is said to be the statistical techniques rather than the software

M373 Optimization

Optimisation was introduced by Tim Lowe. The module is all about numerical computing techniques, where ‘students use commands written by module team which implement methods’. I’ve made a note that this is a module that is needed to support a new data sciences degree. 

Physical Sciences Level 3

Ulrich Kolb introduced the BSc in Physics and mentioned that students needed programming skills. Students are required to carry out some simple Python coding and carry out simple tasks for data analysis. Modules are split into 10-15 credit chunks, and these could be linked to programming.

Delivering programming tutorials

This bit of the workshop was delivered by yours truly, where I spoke from the perspective of a staff tutor. I introduced a popular model called TPAC, which categories different types of knowledge in a simple way: there is pedagogical knowledge, technical knowledge about how to use tool, and knowledge about the content or the subject that is taught. I also mentioned that tools such as screen sharing could be really useful in the teaching of programming. I can’t quite remember, but I must have also spoken about the university group tuition policy.

PG Bioinformatics and cheminformatics

The final presentation of the day was by Mark Hirst who briefly spoke about the requirements bioinformatics and cheminformatics modules. There was a need to develop data handling, data analysis and data mining skills. Perhaps where was also an opportunity to use data from genome databases and a subject that could be called ‘advanced coding for the biosciences’.

Discussion notes

The event ended with a wide ranging discussion. One theme was about whether there was the need to explicitly teach different programming paradigms and the subject of comparative programming languages (I have to confess that I might have raised this as a subject, since it was one of my favourite subjects as an undergraduate, and one that I have found really helpful as a professional programmer). Another point being it is important to acknowledge important tensions between the needs of education and the needs of training.

There were differences: one colleague insisted that we could all use C++, another said that we should use FORTRAN, and a further colleague suggested that Pascal should be used for the simple reason that strongly typed language encourages good programmer behaviours. This wide range of opinions suggested that there isn’t one language that can suit our needs. 

One interesting point was that our students are, of course, changing. There is now a new computing curriculum for schools, which is something that everyone needs to be aware of.

I also noted down the words: ‘the pedagogy of teaching computing across students is something that is common across school, and this is something that can be learnt from each other’. I made another note was about the broad subject of the teaching of programming and how students move from a novice to an expert, namely that expertise is something that you acquire by doing, and this is a point that links back to my own practical presentation about the importance of delivering programming teaching.

Some concluding questions were: ‘how do we teach programming in a cost effective way?’ and ‘should we set up a working group to co-ordinate the teaching of programming?’ A further point is that associate lecturer development is important, and as is collaboration between different development communities. 

Reflections

I learnt a lot from this event and I got thinking about different ways of doing things. Not only did I learn about virtual robots that might be used in modules like TM129, I started to wonder about the possibility of teaching through robotic kits (The Pi Hut). I also learnt about the importance of R, and emphasised the flexibility and richness of libraries.

When I worked in industry, I did some serious coding in C, C++, Visual Basic and have even enjoyed confusing myself with the very many ways to write the same expressions in Perl, but I have yet to seriously get my hands dirty with Python. Thanks to all the presentations that were made during the day, I came away feeling inspired; I felt that I now need to do more to update my programming and development skills.

Acknowledgements

The words shared in this blog ultimately come from each of the presenters. A big shout out to Michel Wermelinger who did a brilliant job putting this event together.

Teaching programming at a distance

The first presentation of the second day was by yours truly.  I gave a short talk about a university funded project that aims to understand more about the teaching experience of Open University associate lecturers who are tutoring on the TT284 Web Technologies  module.

One of the purposes of the project was to understand issues particular to the learning (and teaching) of programming.  An area of particular interest is the transition between the first level modules (which use some visual programming language) to the second level modules which require students to pay more attention to other issues, such as language syntax.

I wasn’t able to present any firm findings at this stage (since I keep getting sucked into the idiosyncrasies of my day job), except that three themes that were emerging were that some students can struggle with understanding what PHP is and how it works, confusion about Javascript, and the perpetual battle to understand regular expressions (which is, I believe, an issue that pretty all developers, expert or novice, seem to have)

The question and answer session was interesting.  There was some chat about a coding DoJos (group coding sessions), the use of MOOCs (FutureLearn and the Kahn Academy), and how get students talking to each other.

Holistic programming teaching at Middlesex

Franco Raimondi’s talk was rather different to all the others: he showed us some robots (real hardware!) that he used in his teaching.  They had an interesting design, using both Raspberry Pi devices that were connected to Arduino microcontrollers.

One question was: why use both?  The Arduinos are used to control analogue input, but the heart of the control is managed (as far as can understand it) by the Raspberry Pi devices.  Students then have the challenge of how to design and implement a communication protocol between the Pi and the sub-component.  I personally think this is a great approach: students are exposed to different devices and learn more about their purpose.  When I had a job in industry, one thing that I had to do is figure out how to get one embedded controller talking to another: Franco’s robots would have helped me a lot to figure out how to do this.  More information about the robots can be found by taking a look at the MIddlesex Robotic plaTfOrm: MIRTO website. 

Okay, so there is an interesting robot, but how are they used in practice?  Franco described a series of lectures, design workshops, programming workshops and physical computing workshops.  In the workshops (if my notes are correct!) students are asked to solve different problems, such as to write a line following algorithm where the robot has to cater for 90 degree turns, and to complete different line circuits as fast as possible.  Students could also implement control algorithms, such as PID controllers (Wikipedia) (which again takes me back to the days when I worked in industry for a while), remote control and managing the taking of cameras by controlling the Raspberry Pi.

What I found really interesting was that the platform (and the workshops) made use of a programming language called Racket (Wikipedia).  Racket is a language that I had not heard of before, but apparently it has roots in the Lisp language.  In some respects, I commend the choice (because it’s great to expose students to different programming paradigms), but on the other hand, there is something to be said for getting to grips with tools that are used in industry.  I guess this just goes to show that whenever you come along to workshop like these, you always learn new stuff.

Towards the end of Franco’s session, he spoke about a system to record Student Observable Behaviours, which then led onto a discussion about learning objectives.  Apparently, the use of ‘observable student behaviours’ is something that Middlesex use, perhaps as a part of their assessment strategy.  We were shown a web-based tool that lecturers can use to gather evidence of student engagement and activity.

I don’t know what this relates to, but I also made a note of a place called The Crystal  (Crystal website), which was also described as the Siemens technology centre.  As soon as I looked into it, I realise that I had once seen it before: on a cable car ride across the Thames.  I now know how to get to The Crystal if ever I need to visit it!

I enjoyed Franco’s session: he covered a lot of ‘tech stuff’ in a very short time.  Students at Middlesex are clearly challenged and are clearly kept busy! 

One thought is that different computing courses and degrees cover different topics and perspectives.  When I was heading home from the workshop I remembered that The Open University covered a bit about robots too on a first year undergraduate module that has the code: TM129 Technologies in Practice (OU website).  Students are also presented with the challenge of creating a line following robot.  Rather than using real robots, a simulated one is used (but, students can get to see real ones if you come along to an engineering day school).

Measuring programming achievement after a first course

The next presentation was by Ed Currie who presented what were described as ‘thoughts and preliminary research’.  One of the key thoughts (and one that I found most interesting) was why some students find programming so difficult.  One note that I have made is that we can’t teach it, students can only learn programming.  It’s not up to us; it’s up to them, and our job (as lecturers and teachers) it to facilitate the learning.

Ed mentioned the idea of Threshold concepts (Wikipedia) by Meyer and Land.  I’ve made a note of the point that ‘sequence is a threshold concept’ (when it comes to programming).  I remembered hearing the phrase before from a colleague who was doing what I think was some research to see what happened when students grappled with key ‘threshold concepts’.

Two great phrases that I’ve noted down are ‘neo-piagetian stages’ and ‘flip classroom’ (Wikipedia).  In some respects the OU has always been doing ‘flipped classrooms’, i.e. students study some material and the go to a face to face tutorial to apply what has learnt, either in terms of solving a problem, or through facilitated discussions.

I don’t know what the context was or where this came from, but I also made the note ‘sharing of learning stories’.  This might have just been an idle idea during Ed’s talk, or something that Ed had said.  When it comes to learning how to do computer programming, I’ve got my own story (which might well be insufferably dull!), and I’m sure that other people have their stories.  Perhaps something could be gained (in terms of learning strategies and approaches) if we find the space to discuss and share how we know what we know.

Reflections on teaching design patterns

The final presentation of the day and final presentation of the workshop was by Carl Evans, who is a lecturer at Middlesex.  Carl talked about his work on an MSc module and his experience of creating and presenting a module about software design patterns.

In computer science and software engineering, Design Patterns is one of my favourite topics.  A couple of points that Carl made really resonated with me.  One was that ‘industry needs architects, not just programmers’.  Another great point (and one that I totally subscribe to) is that there is an increasing expectation (from industry) that graduates can work with frameworks as well as know how to use programming languages. In some ways, this point connected up with Thomas’s keynote.

Carl mentioned Sun/Oracle certifications, the use of layered architectures, and frameworks called Spring (Wikipedia) and Hibernate (Wikipedia) that I have heard of, but have never used in anger.  A quick look into these frameworks quickly shows that design patterns feature pretty prominently.

A really questions are: how do we best teach patterns, and where do we start?  Is there a pattern about how to teach patterns?  I noted down that a refresher about the object-oriented approach is useful, before taking students through different categories of patterns, such as object creation patterns, enterprise patterns, data access patterns, and compound patterns (I was writing everything down pretty quickly at this point, so I might not have managed to the nuances of everything that was said).

Carl also told us about a site called Design Patterns Library which I don’t think I’ve seen before.  One book that was referenced was Head First Design Patterns by O’Reilly.  There seems to be a claim going around that says that these ‘head first’ books are based on ‘neuroscience’ (but I’ve yet to find out exactly what exactly this means: claims like that immediately make me sceptical!)  Either way, anything that helps to make important technical concepts understandable is a good thing.

Final thoughts

I don’t know how many Psychology of Programming Work In Progress events I’ve been to, but it’s been quite a few.  This might have been my fourth or fifth.   I have enjoyed every single one, and I enjoyed this one at Middlesex University too.  It was well organised, friendly and thought provoking.  The talks were really interesting, covering distance learning, errors, notation, robots, challenge of teaching object-oriented programming and a whole load of other subjects too.  The great thing about these events is that you never know what you’re going to get, which means that you never really know what you’re going to learn (and this can be, invariably, a very good thing too).

From my perspective, the event helped to strengthen an opinion I have, which is that we need to figure out how to help students (and practicing programmers) how to best understand and work with software frameworks.  This issue is not only a computing education issue, but also, significantly, a psychology of programming issue.  The first subject that I studied when I discovered this subfield of computing (or of psychology, depending on your ‘home’ discipline) was the topic of program (or software) comprehension.  It’s clear from this short workshop that this continues to be (for me) an important topic. 

On April 23, I visited the Open University campus to attend an event to share lessons about how the university can support students who have disabilities. The event, which took place within a group called the ‘e-learning community’ had two parts to it: one part was about sharing of research findings, and the other part was about the sharing of practice.

This blog aims to summarise (albeit briefly) the four presentations that were made during the day.  It’s intended for a couple of audiences: colleagues within the university, students who might be taking the H810 accessible online learning (OU website) module that I tutor, and anyone else who is remotely interested.

Like many of these blogs, these event summaries are written (pretty roughly) from notes that I made during the sessions.  (This is a disclaimer to say that there might be mistakes and I’m likely to have missed some bits).

Academic attainment among students with disabilities in distance education

Professor John Richardson, from the OU’s Institute of Educational Technology gave the first presentation of the day.  John does quantitative research (amongst a whole load of other things), and he began by staying that there is an increase in knowledge about our understanding of the attainment of students who have disabilities, but the knowledge is fragmented.  John made a really important point, which was that it is patent nonsense to consider all disabled students as a single group; everyone is different, and academic performance (or attainment) is influenced by a rich combination of variables.  These include age, gender, socio-economic status, prior qualifications (and a whole bunch of others too).

When we look at qualitative data, it’s important to define what we’re talking about.  One of the terms that John clearly defined was the phrase ‘a good degree’.  This, I understand, was considered to be a first or an upper second class honours degree.  John also mentioned something that is unique about the OU; that it awards degree classifications by applying an algorithm that uses scores from all the modules that contribute towards a particular degree (whereas in other institutions, the classification comes from decisions made by an examination board).

We were given some interesting stats.  In 2009 there were 196,405 registered students, of which 6.8% of students declared a disability.  The most commonly disclosed disability was pain and fatigue, followed by dyslexia.  Out of all disabled students, 55% of students declared a multiple disability.

In 2012 the situation was a little different. In 2012 there were 175,000 registered students, of which 12% (21,000) students declared (or disclosed) a disability.  John said that perhaps this increase might be an artifact of statistics, but it remains a fact.  He also made the point (raised by Martyn Cooper, a later speaker on the day) that this number of students represents the size of an average European university.  From these statements I personally concluded that supporting students with disabilities was an activity that the university needs to (quite obviously) take very seriously.

If I’ve got this right John’s research drew upon a 2009 data set from the OU.  There were some interesting findings.  When controlling for other effects (such as socio-economic class, prior qualification and so on), students who had declared pain and fatigue and autistic spectrum disorders exhibited greater levels of gaining good degrees that non-disabled students.  Conversely, students who had disclosed dyslexia, specific learning disabilities or multiple disabilities gained a lower percentage of good degrees when compared with non-disabled students.

I’ve made a note of a couple of interesting conclusions.  To improve completion rates, it is a good idea to somehow think about how we can more readily support students who have disclosed mental health difficulties and mobility impairments.  To improve degree levels, we need to put our focus on students who have disclosed dyslexia and specific learning disabilities.  One take away thought relates to the university’s reliance on text (which is a subject that crops up in a later presentation).

Quantitative research can only tell us so much; it can tell us that an artifact exists, but we need to use other approaches to figure out the finer detail.  Qualitative research, however, can provide detail, but the challenge with qualitative approaches lies with the extent to which findings and observations can be generalised.  My understanding was that we need both to clearly create a rich picture of how the university supports students with disabilities. 

Specific learning differences, module development and success

The second presentation was a double act by Sarah Heiser (a colleague from the London region), and Jane Swindells, who works in the disability advisor service.  Jane introduced the session by saying that it was less about research and more about sharing a practitioner perspective.  I always like these kind of sessions since I find it easy to connect with the materials and I can often pick up some useful tips that you can use within your own teaching.

An important point is that dyslexia has a number of aspects and is an umbrella term for a broader set of conditions.  It can impact on different cognitive processes, such as the use of working memory, speed of information processing, time management, co-ordination and automaticity of operations.  It can also affect how information is received and decoded. 

On-line or electronic materials offer dyslexic learners a wealth of advantages; materials can be accessed through assistive technologies, and users can personalise how content is received or consumed.  An important point that I would add is that the effectiveness of digital resources depends on the user being aware of the possibilities that it gives.  Developing a comprehensive awareness of the strategies of use (to help with teaching and learning) is something that takes time and effort.

Sarah spoke about a project where she has been drawing out practice experience from associate lecturers through what I understand to be a series of on-line sessions (I hope I’ve understood this correctly).  Important themes to include challenges that accompany accuracy, text completion, following instructions, time, and the importance of offering reassurance.

I’ve made a note of the term ‘overlearning’.  When I had to take exams I would repeat and repeat the things I had to learn, until I was sick of them.  (This is a strategy that I continue to use to this day!)

One point that I found especially interesting relates to the use of OU live recordings.   If a tutor records a session, a student who may have dyslexia can go over them time and time again, choosing to pick up sections of learning at a time and a pace that suits them.  This depends on two points: the first is the availability of the resource (tutors making recordings), and students being aware that they exist and know how they can access them.

Towards the end of the session, Sarah mentioned a tool called Language Open Resources on-line, or LORO for short.  LORO allows tutors to share (and discover) different teaching resources.  I was impressed with LORO, in the sense that you can enter a module code and find resources that tutors might (potentially) be able to use within their tutorial sessions.

SeGA guidance: document accessibility/accessible methods and other symbolic languages

The third presentation of the day was from Martyn Cooper, from the Institute of Educational Technology.  Martyn works as a Senior Research fellow, and he has been involved with a university project called SeGA, known as Securing Greater Accessibility.  A part of the project has been to write guidance documents that can help module teams and module accessibility specialists.  An important point is that each module should have a designed person who is responsible for helping to address accessibility issues within its production.  (But, it should also be argued that all members of a module team should be involved too).

The documents are intended to provide up to date guidance (or, distilled expertise) to promote consistency across learning resources. The challenge with writing such guidance is that when we look at some accessibility issues, the detail can get pretty complicated pretty quickly.

The guidance covers a number of important subjects, such as how to make Word documents, PDFs, and pages that are delivered through the virtual learning environment as accessible as possible.  Echoing the previous talk, Martyn made the point that electronic documents have inherent advantages for people who have disabilities – the digital content can be manipulated and rendered in different ways.

Important points to bear in mind include the effective use of ALT texts (texts that describe images), the use of scalable images (for people who have visual impairments), effective design of tables, use of web links, headings and fonts.  An important point was made that it’s important to do ‘semantic tagging’, i.e. design a document using tags that describe its structure (so it becomes navigable), and deal with its graphical presentation separately.

I noted down an interesting point about Microsoft Word.  Martyn said that it is (generally speaking) a very accessible format, partly due to its ubiquity and the way that it can be used with assistive technologies, such as screen readers.

Martyn also addressed the issue about how to deal with accessibility of mathematics and other symbolic notations.  A notation system or language can help ideas to be comprehended and manipulated.  An important point was that in some disciplines, mastery of a notation system can represent an important learning objective.  During Martyn’s talk, I remembered a lecture that I attended a few months back (blog) about a notation scheme to describe juggling.  I also remember that a good notation can facilitate the discovery of new ideas (and the efficient representation of existing ones).

One of the challenges is how to take a notation scheme, which might have inherently visual and spatial properties and convert it into a linear format that conveys similar concepts to users of assistive technologies, such as screen readers.  Martyn mentioned a number of mark-up languages that can be used to represent familiar notations: MathML and ChemML (Wikipedia) are two good examples.  The current challenge is these notations are not supported in a consistent way across different internet browsers.  Music can be represented using something called music braille (but it is also a fact that only a relatively small percentage of visually impaired people use braille languages), or MIDI code.

A personal reflection is that there is no silver bullet when it comes to accessibility.  Notation is a difficult issue to grapple with, and it relies on users making effective use of assistive technologies.  It’s also important to be mindful that AT, in itself, can be a barrier all of its own.  Before one can master a notation, one may well have to master a set of tools.

The question and answer session at the end of Martyn’s talk was also interesting.  An important point was raised that it’s important to embed accessibility into the module production process.  We shouldn’t ‘retrofit’ accessibility – we should be thinking about it from the outset.

Supporting visually impaired students in studying mathematics

The final presentation of the day was by my colleague Hilary Holmes, who is a maths staff tutor.  A comment that I’ve made (in my notebook) at the start of Hilary’s presentation is that the accessibility of maths is a challenging problem.  Students who are considering studying mathematics are told (or should be told) from the outset that maths is an inherently visual subject (which is advice that, I understand, is available in the accessibility guide for some modules).

Key issues include how to describe the notation (which can be inherently two dimensional), how to describe graphs and diagrams, how to present maths on web pages, and how to offer effective and useful guidance to staff and tutors.

First level modules make good use of printed books.  Printed books, of course, present fundamental accessibility challenges, so one solution to the notation (and book accessibility) issue is to use something called a DAISY book, which is a navigable audio book.  DAISY books can be created with either synthesised voices, or recorded human voices.  The university has the ability to record (in some cases) DAISY books through a special recording facility, which used to be a part of disabled student services.  One of the problems of ‘speaking’ mathematical notation is that ambiguities can quickly become apparent, but human readers are more able to interpret expressions and add pauses and use different tones to help convey different meanings.

Another approach is to use some software called AMIS (AMIS project home), which is an abbreviation for Adaptive Multimedia Information System. AMIS appears to be DAISY reader software, but it also displays text.

Diagrams present their own unique challenges.  Solutions might be to describe a diagram, or to create tactile diagrams, but tactile diagrams are limited in terms of what they can express.  Hilary subjected us all to a phenomenally complicated audio description which was utterly baffling, and then showed us a complex 3D plot of a series of equations and challenged us with the question, ‘how do you go about describing this?’  I’ve made a note of the following question in my note book: ‘what do you have to do to get at the learning?’

Another approach to tackle the challenge of diagrams is to use something called sonic diagrams.  A tool called MathTrax (MathTrax website) allows users to enter in mathematical expressions and have them converted into a sound.  The pitch and character of a note change in accordance with values that are plotted on a graph.  Two important points are: firstly, in some instances, users might need to draw upon the skills of non-medical helpers, and secondly (as mentioned earlier), these tools can take time to master and use.

A final point that I’ve noted down is the importance of offering tutors support.  In some situations, tutors might be unsure what is meant by the phrase ‘reasonable adjustment’, and what they might be able to do in terms of helping to prepare resources for students (perhaps with help from the wider university).  Different students, of course, will always have very different needs, and it is these differences that we need to be mindful of.

It was really interesting to hear that Hilary has been involved with something called a ‘programme accessibility guide’.  This is a guide about the accessibility of a series of modules, not just a single module.  This addresses the problem of students starting one module and then discovering that there are some fundamental accessibility challenges on later modules.  This is certainly something that would be useful in ICT and computing modules, but an immediate challenge lies with how best to keep such a guide up to date.

Reflections

It was a useful event, especially in terms of being exposed to a range of rather different perspectives and issues (not to mention research approaches).  The presentations went into sufficient detail that really started to highlight the fundamental difficulties that learners can come up against.  I think, for me, the overriding theme was about how best to accommodate differences.  A related thought is that if we offer different types of resources (for all students), there might well be a necessity to share and explain how different types of electronic resources and documents can be used in different ways (and in different situations).

The Languages Open Resources Online website was recently mentioned in a regional development conference I attended a month or two back.  Sarah’s session got me thinking: I wondered whether it could be possible to create something similar for the Maths Computing and Technology faculty, or perhaps, specifically for computing and ICT modules (which is my discipline).  Sharing happens within modules, but it’s all pretty informal – but there might be something said for raising the visibility of the work that individual tutors do.   One random through is that it could be called: TOMORO, with the first three letters being an abbreviation for: Technology Or Mathematics. There are certainly many discussions to be had. 

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.

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. 

I had never visited the University of Buckingham before.  It was on the morning of Tuesday 15 May 2012 that I found myself travelling to Milton Keynes railway station to meet with a pre-booked taxi that would whisk me into the unknowns of the Buckinghamshire countryside towards an event that was intended to share practice about the teaching of mobile technology.  Although I had never visited Buckingham, I have heard it being spoken of many times before; a radical institution which was founded at approximately the same time as another radical institution, the Open University. 

As well as sharing practice about the teaching of mobile application development another really important theme was the subject of employability and the open question of whether universities are 'teaching the right stuff' to enable graduates to immediately make a contribution in the workplace.

This blog post is a summary of a visit to a HEA event entitled 'Mobile Application Development: from curriculum design to graduate employability'.  If I've missed any key points, I encourage the fellow participants and delegates to add comments below.

Industry keynote

Lee Stott, an academic evangelist from Microsoft kicked off the day with a really interesting keynote.  Lee is from a part of Microsoft that works with university departments (Microsoft Faculty pages).

Lee emphasised the point that users expect connectivity.  I made a note of an interesting quote that went 'mobility plus cloud equals opportunity'.  It's easy to imagine (or even remember) situations where one gained access to information whilst travelling, solving problem, such as finding an address of a location or accessing some urgently needed information.

Lee also made the point that mobile devices are our predominant work tool (or tools).  A tool, of course, might be a phone or a laptop.  This is certainly true in my case; I often haul my laptop between the OU's headquarters in Milton Keynes and my home, sometimes using the dead time on a train to do some marking.  Another thought that comes to mind is whether mobility is causing work time to encroach on our personal time, but this is a whole other debate (and one that I hope to connect with by writing another blog post about a recent seminar).

The usefulness of an app depends on a combination on its functionality, the functionality of a device and the availability of a network.  To be useful, apps need to be useful but also graphically appealing.  Lee emphasised the importance of designers, not just software designers, but graphic designers.  This connects to an important point which is that creating good apps is an interdisciplinary activity - a combination of technology, business and art. Writing commercial apps isn't just about writing software that works - they need to be 'hardened'; tested thoroughly and be checked for vulnerabilities.

Microsoft, along with other mobile platform vendors (such as Google and Apple) have their own ecosystem of tools, technologies and platforms.  Microsoft is but one of many platforms that educators can choose from.

I have to confess (for my sins) that I used to be a software developer who mostly specialised in Microsoft technologies.  I used to use .NET, MS SQL and a bunch of other stuff.  It has been, however, a few years since I've done this.  Lee introduced new technologies that were entirely new to me, such as Microsoft Azure (wikipedia) and Microsoft XNA (wikipedia) for Xbox.  Lee also mentioned other software that was on the near horizon, such as Windows 8 (wikipedia) which can be used on 'slate' (or tablet) devices.

Lee also touched upon the important subject of recruitment.  Lee emphasised that it is important to encourage students to build apps and sell them through apps market places to create a portfolio which can be shown to potential employers.

The question and answer session was interesting.  There was some discussion about cross platform approaches to development and the fact that when you go cross platform, developers lose some functionality from the original host operating system of a mobile device (or phone).  The subject of native code versus multi-platform code was a debate that arose on a number of occasions throughout the day.  HTML 5 (wikipedia) was regularly mentioned, along with a platform such as PhoneGap (PhoneGap website).

Another tension that exists particularly when industry representatives and university representatives debate curriculum, is the difference between education and training.  Industry wants people who are fully trained (and ideally want universities to do this), but the real role of universities when it comes to technology (in my opinion) is to enable students to effectively know how best to learn and adapt to new tools and situations.  Lee made the point that the teaching of fundamentals is essential.  I agree.  Conveying principles through the use of vendor specific tools whilst presenting concepts in a general way to enable other technologies to be understood is a difficult thing to achieve.

Mobile application development: a journey thus far

Harin Sellakewa from the University of Buckingham gave a presentation that described how mobile technology came to be taught, in its current form, at Buckingham.  Harin described how some of the curriculum had changed and outlined the introduction of new modules.  The use of mobile technology had been explored by a number of various projects, including those that were funded by the EU.

Some of the key learning objectives of a module on mobile software was mentioned: how to design applications (or apps), understanding different components and learning about various guidelines and specifications.  All these learning objectives could then contribute to making an application that could be sold on the free market.

Harin also gave us a number of useful tips.  Any module must (of course) satisfactorily complement any existing modules, also aim to get people involved, speak to different vendors, start with student projects, attend training events that are run through industry and take the time to network.

A number of different topics were exposed through the question and answer session.  As well as a discussion about different technologies, an industry representative mentioned the importance of candidates having a portfolio of work to demonstrate to prospective employers.  One point that stuck in my mind was that an unfinished application has the potential to work against an applicant; showing something polished and complete is necessary.

Developing Apps in Schools

Aaron Peck teaches computing and ICT at the Royal Latin School, Buckingham, a school just around the corner from the university.  Aaron began by speaking about wider discussions about the GCSE computing curriculum, mentioning the OCR GCSE which was said to contain three key components: programming, a research project and an examination.

Aaron emphases fun and mentions the use of the MIT Scratch (Scratch website) environment.  He also went onto speak about mobile devices, a technology that the pupils are invariably likely to be familiar with.   Here lies an obvious collision of ideas: why not teach programming through the use of mobile devices?

Scratch has, of course, some distinct advantages - it is immediate and gets around the tyranny of fiddly syntax by providing students a graphical environment in which they can play.  Another programming environment that has a graphical world is the MIT App Inventor (App Inventor website) which allows users to create apps for Android phones.

Students are encouraged to create small projects, which may include a simple calculator, a recipe book or a hangman game.  The creation of apps has the potential to open up further discussion of wider issues, such as how such developments might be commercialised.  I remember an anecdote from Aaron, where he was asked by a student about how much an app programmer might earn; a testament to his ability to instil enthusiasm and engaging choices of technology.

There were some advantages to using App Inventor; it can be used on multiple development platforms, it is relatively simple to install and given that students may have used Scratch during earlier studies, making the graphical nature of the programming environment to be (potentially) more easily grasped by students.

Aaron isn't stopping at creating apps with App Inventor.  He mentioned his intention to try to work with Lego Mindstorms Robots through the Android SDK, where it might be possible to create a 'remote control' app using Bluetooth radio.  Aaron also mentioned that there was also opportunity to share the workings of HTML and Javascript with his students.  If my memory isn't playing tricks on me, I also seemed to recall that he mentioned that one of his students was inspired enough to use C++.

The question and answer session led us to subjects and technology such as Microsoft Kodu and Micrcosoft Gadgeteer.  Other important issues include addressing the gender imbalance, and how to motivate all student groups, including those who may not have a strong technical bias.

I really enjoyed this talk.  Two big parts of tech were familiar to me: Scratch (or as I know it, Sense), and App Inventor.  Both products are used as a part of different Open University computing modules, TU100 My Digital Life and TT284 Web Technologies.  It was an eye opener, for me, to see how these products could be used a way to inspire students at GCSE level. 

Mobile Assessment

The use of mobile technology to help teaching and learning seems to be a hot topic at the moment.  Joan Lu gave a presentation about the use of mobile technology for assessment and also mentions the use of student response systems making reference to an EU funded project entitled Do-IT.  Joan is from the XDIR research group at the University of Huddersfield which has carried out research  projects related to mobile technology.

Designing the mobile syllabus to enhance student employability

Yanguo Jing from London Metropolitan University gave a presentation about his first hand experiences of teaching about mobile technology to his postgraduate students.  It was a really interesting presentation that was packed with useful tips, not just about teaching but also about industrial engagement too.

Returning to the subject of multiple platforms and environments, Yanguo said that initially he tried to teach a little bit about all the major toolsets.  He came to the conclusion that this was less than ideal.  Although students might be given breadth, getting to the 'depth' is always a challenge.  It was decided, therefore, to focus on one particular platform and use the experience with the platform to make points that are important in other platforms too.  This is a very sensible practical decision; there is only so much detail that a lecturer can hold in his or her head at any one time.

Understanding mobile isn't just about understanding technology and the fundamentals of creating some executable code that runs on a device, it is also about understanding the surrounding business and economic area.  Connecting back to the ideal of creating marketable Apps that Harin touched upon in his earlier presentation, Yanguo said something about how he encourages his students to enter application competitions, or Appathons.  He also mentioned that students were also encouraged to attend an industry conference, DroidCon, to gain first hand experience about what is happening within industry.  It was interesting to hear that Yanguo is a part of an industry liaison group.  Not only does this facilitate a connection between academics and industry, it can also act as a connection between industry and students too.

Finally, it is also perhaps worth mentioning that Yanguo is helping to organise a related HEA event on mobile technology on 15 June 2012, entitled Workshop on Teaching and Learning Programming for Mobile and Tablet Devices.  It sounds like it's going to be a great event!

Programming with iOS

Gordon Eccleston from Robert Gordon University, Aberdeen shared some of his experiences of teaching using Apple's iOS.  This platform enabled students to learn something about HCI principles and also about object-oriented programming (through the use of Objective-C).

Gordon offered a key tip which echoed earlier discussions in the event.  He said, 'keep your modules as generic as possible'.  Inspiration and information that informed the creation of his module included looking at different text books and short courses that were designed for industry.  Studying the documentation provided by the vendor can be a very useful source of materials that can help to guide or inform the creation of aspects of a module.

Gordon spoke about lab based teaching (in a lab containing lots of Apple kit) and student course work.  Gordon then went onto present a brief overview of a number of different student projects.  The use of projects cannot be understated.  A good project connects the technology with broader issues of business and also helps to give the student some good materials that can be immediately demonstrated to a potential employer (I have this image of an interviewee handing their phone to an interviewer whilst saying, 'this is what I've done).  One project that stuck in my mind was an app that illustrated a fashion portfolio which demonstrates a connection between apps and marketing.

Gordon's session inspired a really interesting question and answer session.  One point was that PC (or Mac) based simulators are all very well, but it's also important (as well as rewarding) to allow students to run their software on actual devices (such as an iPod touch).  For one thing, it allows the developers to gain access to device only peripherals, such as accelerometers and other sensors that they wouldn't otherwise have access to.

Reflection of curriculum design and delivery in mobile computing

Khawar Hamed from the University of Staffordshire spoke about his experiences of curriculum design.  Khawar's presentation reminded me an app is at the top of a technology pyramid.  Along with the operating system of a device, apps are perhaps the most visible software artefact that users interact with.  Underneath the app and beyond the phone there is a sophisticated digital infrastructure that enables devices to work.  Some of the modules that Khawar mentioned allow students to begin to study these underlying technologies.  Another point is that mobility isn't just about technology, it's also about enabling organisations to achieve their objectives.

Khawar touched upon other issues such as the importance of getting the right name for a course or programme.  Since the names and phrases used to describe technology can change relatively quickly, perhaps the names of modules and programmes should be prepared change too?   An important point was to always seek industrial involvement wherever possible.  Connecting to this point, Khawar mentioned an organisation called The Wireless University Forum.

One really interesting debate that emerged from this presentation centred upon whether an institution should provide devices that students can transfer code to.  The answer was a resounding 'yes'.  Not everyone will have an Android phone, or an iPhone (or even a smartphone, although this is something that is changing).  Plus, providing a device delineates between what is a 'learning' device and what is a 'personal' device.

Mobile app development - creativity, skills and evidence

The final talk of the day was a second keynote.  Andrew Lapham, from Yell Labs gave an enthusiastic presentation about the work that his team carries out and what characteristics in potential employers he is looking for.  Key points include the ability to be creative and generate new and interesting ideas, strong communication skills (the ability to communicate those ideas and to persuade others of their merit), and an underlying enthusiasm for technology and what it might be able to achieve.

The notion of having a portfolio of evidence was also touched upon.  Whilst demonstration of apps or talking through a pet project is impressive, what is more impressive is having evidence that your own product or code has been marketed.  This might include having a blog about a product, and also gathering some evidence about how your customers view your product.

Reflections

There was one thing that surprised me about this day which was an exceptionally strong focus on apps.  In retrospect, it shouldn't have been a surprise at all.  Apps are the way to consume software on mobile devices.

I certainly sense that teaching programming for mobile devices isn't easy.  Each platform comes attached to ecology of tools (and a whole set of accompanying vocabulary) and techniques.  Teaching everything just isn't an option, but teaching in depth is surely the right way to go.  Educators will therefore have to choose a platform and figure out how to connect a technology choice to wider principles to enable graduates to more readily get to grips with the new environments they will inevitably face.

One really interesting question is whether mobility and the technology that goes with it is changing software engineering?  It's not a question seems to have an easy answer, but perhaps user based apps require different design methods than the lower level software that support the networking infrastructure and perhaps those who have stronger connections with the industry would be able to comment.

A final reflection relates to the creation of a portfolio that can help during the recruitment process.  The importance of a personal portfolio was emphasised in a recent HEA event at the University of Greenwich about gaming and animation.  Employers like to see what applicants have done.    Furthermore, it offers opportunities to allow employers to find out about the difficulties that applicants face and how they were overcome.

When it comes to being an app developer, the message was clear: a portfolio of well-crafted working apps was clearly something that employers would like to see.

Congratulations to Buckingham for running a fun and thought provoking event!

 I recently had the pleasure of attending the PPIG 2011 workshop between 6 and 8 September.  As I might have mentioned in an earlier blog, PPIG is an abbreviation for the Psychology of Programming Interest Group.  There used to be an American equivalent which was called ESP (Empirical Studies of Programmers), but this community seem to have disappeared.  PPIG, on the other hand, is going strong.

This year it was held in the University of York computer science department.  The department had moved since I was last there, forcing me to circumnavigate the campus and arrive at a time when almost all the tea and sandwiches had disappeared.  Thomas Green gave an opening address, and then it was swiftly on to the first presentation.

Mathematics and Visual Impairments

Alistair Edwards gave a talk entitled 'new approaches for mathematics in blind students'.  Mathematics, of course, relies on visual notations.  These notations, it was argued, are an integral part of working with maths.

Alistair holds that view (or, should I say that I understand that he holds the view) that there is more to it than just using an appropriate notation, or having that notation converted into another form.  We externalise parts of our working memory by using pen and paper.  Also, the idea of cancelling (or balancing) an equation by crossing of similar teams from both sides can be viewed as a visual manipulation.

Alistair mentioned a couple of projects, one of which was called Lambda, an abbreviation for Linear Access to Mathematics for Braille Device and Audio-synthesis.  Here, the challenges began to be clear: I didn't know this but different countries have different braille notation for mathematics.  There is, of course, the issue that using an interface to a notation immediately places cognitive barriers in the way that has the potential to make things more difficult to understand.  Users, it was argued, need more direct forms of interaction when working with mathematics.

All in all, a very thought provoking introduction, and it made me wonder how Green's cognitive dimensions of notations framework might be used to analyse interactions to notational systems (such as mathematics or programming languages) by users who may have different modality preferences (i.e. auditory over visual).

New Tech

The first main session of the workshop was called New Tech.  I'll do a very quick run through of the papers from each session.  Jon Rimmer presented the shyness project, and introduced the beguiling ambient computing device called the 'subtle stone', whereby class participants can communicate their emotional state to the lecturer by a click of a juggling ball.  Jon deftly directed us to a series of interesting papers about shyness.

The following paper was closely connected.  It was entitled 'self-reporting emotional experiences in a computing lab', by Judith Good (et al).  Us programmers go through a whole spectrum of different emotions during a programming session, from delight, through to wishing to jump on our laptop (although I don't recommend this).  This is an interesting direction: emotion connects to motivation, and traditionally the PPIG community have more focussed upon the cognitive.

Chris Roast, from Sheffield Hallam University, took us on a tour of a tool that helped to create different internationalised film posters; software localisation through abstraction.

One of the papers that I most enjoyed was by Chris Martin from the University of Dundee, who took dancing robots on a road trip to a number of different schools to further explore whether a robot dance workshop can inspire interest in a technical subject such as computer programming.  Or, does using robots 'sugar coat' a difficult subject, or is there more to it than this?  By robots, imagine small buggies.

In fact, Chris's robots use the same Arduino microcontroller that is central to the TU100 Senseboard. By dance, this is an activity that has a low threshold to success, is created, transcends culture, and where performance can be valued over competition (I made notes during this bit of Chris's talk).

The two other papers in this section described how to make music with a dry marker pen, a whiteboard and a mobile phone by defining your own musical notation (which was pretty cool), and considered the challenges that users of mobile spreadsheets face.

Human and algorithmic complexity

The next presentation was a 'work in progress' paper by yours truly.  I talked about a project (that has been making very slow progress, due to a myriad of different reasons) to explore whether it is possible to link measurements of program complexity to physiological measurements that are known to indicate human cognitive load. 

The workshop participants gave me a whole number of things to think about, including the names of a number of researchers, as well as a clear message of: 'stop procrastinating, just get on with it'.  I'm certainly going to take that last piece of advice.

The following presentation was about the challenge of working with test data.  A subject that can easily cause terror to many a software developer.

Language Formalities

Wednesday yielded a change of plan.  Thomas Green ran a session entitled, 'how to design a notation'.  A programming language is, of course, a form of notation.  Thomas posed interesting questions, like, 'how might we invent a different type of musical notation?', which led onto other questions such as its level of abstraction (what each element of a notation can represent), what you might wish to do with a notation, it's overall purpose, and how you might off load to external representations.

A theme underpinning all this debate was one that is familiar to many human-computer interaction and interaction design researchers: the idea of trading one thing off against another.

Giora Alexandron then presented his paper entitled 'programming with the user in mind' which led us towards considering something called live sequence charts, which is an extension of UML sequence diagrams.  We were introduced to the Play Engine and the PlayGo IDE.

This was followed by a presentation by Ahmad Taherkhani who spoke about 'automatic algorithm recognition based on programming schemas'.  I really liked this paper, since it was a new angle on some very early psychology of programming themes.  I particularly like how Ahmad was attempting to use existing theories to engineer a solution that may not only have practical use (in terms of providing tools to help educators to understand the programming code that students write), but also the act of programming a solution has the potential to allow us to learn more about the theories that are being applied.

The final paper in this session was a work in progress paper by Khuong A Nguyen who used a human-computer interaction technique called cognitive walkthough to learn more about the NXT-G visual programming language that can be used with the Lego Mindstorms hardware.

HCI for the future

Following a tour of a HCI and accessibility lab (which resembles a small apartment), a short panel discussion took place, with Nicholas Merriam and Luke Church taking centre stage.  Nicholas's perspective was especially welcome, since he spoke about the challenge of working with low level embedded software and the role that timing visualisation tools may play when attempting to solve programming problems that seem particularly intractable.  This linked back well to the earlier discussions of notation.

Learners and language design

This session contained two papers.  The first was a paper by Ahmed Alardawi, from Sheffield Hallam, aimed to explore the effect that object-oriented programming language class structure has on the comprehension of computer programs.  What was great about this research was that it clearly made use of existing work, and partially replicated earlier studies, thus adding to evidence.  Babak Khazaei, also from Sheffield Hallam, presented an empirical study on the influence of OCL, an abbreviation for Object Constraint Language (wikipedia). 

Motivation and affect

This part of the workshop contained a single presentation, by Rein Sach, from the Department of Computing at the Open University. 

Rein's paper was entitled, 'what makes software engineers go that extra mile?'  Rein asked software engineers what it was about their work that they enjoyed.  This gave way to an interesting discussion about the perception of the nature of programming work.  Even though developers might have to battle with misbehaving operating systems and maintain servers from time to time, perhaps these activities need to be considered as work rather than nuisances that get in the way of the real task, which is doing the intrinsically rewarding and creative work of creating code.

Invited paper

Thursday kicked off with a presentation by Gerrit van der Veer, from the Open University in the Netherlands and the Free University, Amsterdam.  Gerrit's presentation was about different aspects of design, how technology might be used to gather debate surrounding the artefacts that are created during the design process through a system called CAM, meaning Co-operative Artefact Memory.  A barcode sticker could be attached to different artefacts, such as a sketch or a physical prototype.  Design groups could then use these stickers, with mobile phones, to access a shared Twitter stream that relates to each object, allowing views and ideas to be shared.

Two thoughts came to mind during Gerrit's presentation.  Firstly, I wondered the extent of similarities between design practice (in different disciplines) and what occurs within software development practices that use agile methods, such as eXtreme Programming.  Secondly, CAM reminded me of a tool called OpenDesignStudio used for an Open University design course called U101, Design Thinking.

Another part of Gerrit's presentation was all about service design (i.e. design which yields a product that is not a tangible item).  Gerrit pointed us to a number of resources, such as the Service Design Tools site, and mentioned the importance of culture, by referring to the work of Hofstede (which is studied in the M364 Interaction Design Open University course). 

Cognitive considerations

The final session of the workshop contained two presentations that related to the cognitive dimensions of notations framework, papers by Anna Bobkowska, Maria Kutar and John Muirhead.  Anna introduced a language for the processing of multimedia streams through the use of a visual language.  Maria and John's presentation explored how a cognitive dimensions questionnaire might be used by non-experts.

Miguel Monteiro went on to speak about the cognitive foundations of modularity.  Miguel referred to a programming paradigm called Aspect-oriented programming (wikipedia), a subject that I have heard of many times, but one that I have not explored in a great deal of depth.  Learning more about AOP is certainly something to do at some point.

Qualitative and Quantitative

The final presentation of the workshop was by Gordon Fletcher from the University of Salford.  Gordon's presentation was entitled 'methods and practicalities of qualitative research', but it was so much more than this.  Gordon spoke about data collection in different communities, and mentioned the concept of biographical research (which made me wonder if anyone has thought about applying this technique, perhaps with regards to exploring motivation or software related careers.

I came away with a number of messages, namely, it can be relatively easy to gather qualitative data, but figuring out what to do with it is a whole other issue.  Also, both quantitative and qualitative research can be both systematic and rigorous; these different approaches to research have a lot in common.  An interesting quote was, 'the method has to fit the researcher even more than it has to fit the research'.

Gordon's presentation gave way to a memorable debate on the use of terms.  Undoubtedly the use of language will remain a perpetual challenge when carrying out multidisciplinary research.

Themes

A number of diverse themes were evident within the PPIG '11 workshop, representing its broad membership.  There was a strong theme of computing education and pedagogy.  Programming and educational motivation was also apparent, mixed in with the use and design of visual programming languages.  This connected to the important theme of cognitive dimensions, notational systems and notational design. 

Two interesting inclusions were links to the broader subject of design, and accessibility.  Human-computer interaction and interaction design remains important theme too.  A final theme is (perhaps that isn’t as strong as in previous years) is the application of ethnographic methods to further understand the activity of programming.  It was great to hear from a broad spread of presenters who are exploring many different research areas.

I recently attended a public dissemination event that was held by the AEGIS project, hosted by the European headquarters of the company that developed the Blackberry, Research in Motion.

The Aegis project has the strapline that has three interesting keywords: groundwork, infrastructure and standards.  When I heard about the project from a colleague, I was keen to learn what lay hidden underneath these words and how they connect to the subject of accessibility.

The Aegis project website states that it 'seeks to determine whether 3rd generation access techniques will provide a more accessible, more exploitable and deeply embeddable approach in mainstream ICT (desktop, rich Internet and mobile applications)' and goes on the say that the project will explore these issues through the development of an Open Accessibility Framework (or OAF).  This framework, it is stated, 'provides embedded and built-in accessibility solutions, as well as toolkits for developers, for "engraving" accessibility in existing and emerging mass-market ICT-based products'.  It goes on to state that the users of assistive technologies will be placed at the centre of the project.

The notion of the 'generations' of access techniques is an interesting concept that immediately jumped out at me when reading this description (i.e. what is the third generation and what happened to the other two generations?), but more of this a little later on.

Introductory presentations

The dissemination day began with a couple of contextualising presentations that outlined the importance of accessibility.  A broad outline of the project was given by the project co-ordinator who emphasised that the point that the development of accessibility required the co-operation of a large number of different stakeholders, ranging from expert users of assistive technology (AT), tutors, and developers.

There was a general call for those who are interested in the project to 'become involved' in some of the activities, particularly with regards to understanding different use cases and requirements.  I'm sure the project co-ordinator will not be offended if I provided a link to the project contacts page.

AT Generations

The next presentation was made by Peter Korn of Sun Microsystems who began by emphasising the point that every hour (or was it every second?) hundreds of new web pages are created (I forget the exact figure he presented, but the number is a big one).  He then went on to outline the three generations of assistive technologies.

The first generation of AT could be represented by the development of equipment such as the Optacon (wikipedia), an abbreviation for Optical to Tactile Converter.  This is the first time I had heard of this device before, and this represented the first 'take away' lesson of the day.  The Wikipedia page looks to be a great summary of its development and its history.

One thing that is missing is the lack of an explicit link to a personal computer.  The development of a PC gave way to a new second generation of AT that served a wider group of potential users.  This generation saw the emergence of specialist AT software vendors, such as companies who develop products such as screen readers and screen magnifiers.  Since computer operating systems are continuing to develop and hardware is continually changing (in terms of increases in processing power), this places unique pressures on the users of assistive technology.

For some AT systems to operate successfully, developers had have to apply a number of clever tricks.  Imagine a brand new application package, such as a word processing program, that had been developed for the first generation of PCs, for example.

The developers of such an application would not be able to write code in such a way that allows elements of the display to be presented to users of assistive technology.  One solution for AT vendors is to rely on tricks such as the reading of 'video memory' to convert on-screen video displays that could be presented to users with visual impairments using synthetic speech.

The big problem of this second generation of AT is that when there is a change to the underlying operating system of a computer it is possible that the 'back door' routes that assistive technologies may use to gain access to information may become closed, making AT systems (and the underlying software) rather brittle.  This, of course, leads to a potential increase in development cost and no end of end user frustration.

The second generation of AT is said to have existed between the late 1980s to the early 2000s.  The third generation of AT aims to overcome these challenges since operating systems and other applications begin to providing a series of standardised Accessibility Application Programming Interfaces (AAPIs).

This means that different suppliers of assistive technology can write software that uses a consistent interface to find out what information could be presented to an end user.  An assistive technology, such a screen reader, can ask a word processor (or any other application) questions about what could be presented.  An AAPI could be considered as a way that one system could ask questions about another.

Other presentations

Whilst an API, in some respects can represent one type of standard, there are a whole series of other standards, particularly those from the International Organization for Standardization (ISO) (and other standards bodies) that can provide useful guidance and assistance.  A further presentation outlined the complex connections between standards bodies and underlined the connection to the development of systems and products for people with disabilities.

A number of presentations focussed on technology.  One demonstration used a recent release of the OpenSolaris operating system (which makes use of the GNOME desktop system) to demonstrate how the Orca screen reader can be used in conjunction with application software such as OpenOffice.

With all software systems, there is often loads of magic stuff happening behind the scenes.  To illustrate some of this magic (like the AAPI being used to answer questions), a Gnome application called Accerciser was used.  This could be viewed as a software developer utility.  It is intended to help developers to 'check if an application is providing correct information to assistive technologies'.

OpenOffice can be extended (as far as I understand) using the Java programming language.  Java can be considered as a whole software development framework and environment.  It is, in essence, a virtual machine (or computer) running on a physical machine (the one that your operating system runs on).

One of the challenges that developers of Java had to face was to how to make its user interface components accessible to assistive technology.  This is achieved using something called the Java Access Bridge.  This software component is, in essence, 'makes it possible for a Windows based Assistive Technology to get at and interact with the Java Accessibility API'.

On the subject of Java, one technology that I had not heard of before is JavaFX.  I understand this to be a Java based language that has echoes of Adobe Flash and Microsoft Silverlight about it, but I haven't had much of a time to study it.  The 'take home' message is that rich internet applications (RIA) need to be accessible too, and having a consistent way to interface with them is in keeping with the third generation approach to assistive technologies.

Another presentation made use of a Blackberry to demonstrate real time texting and show the operation of an embedded screen reader.  A point was made that the Blackberry makes extensive use of Java, which was not something that I was aware of.  There was also a comment about the importance of long battery life, an issue that I have touched upon in an earlier post.  I agree, there is nothing worse than having to search for power sockets, especially when you rely on technology.  This is even more important if your technology is an assistive technology.

Towards the fourth generation

Gregg Vanderheiden gave a very interesting talk where he mentioned different strategies that could be applied to make systems accessible, such as making adaptations to an existing interface, providing a parallel interface (for example, you can carry out the same activities using a keyboard or a mouse), or providing an interface that allows people to 'plug in' or make use of their own assistive technology.  One example of this might be to use a software interface through an API, or to use a hardware interface, such as a keyboard, through the use of a standard interface such as USB.

Greg's talk made me think about an earlier question that I had asked during the day, namely 'what might constitute the fourth generation of assistive technologies?'  In many respects this is an impossible question to answer since we can only identify generations when they have passed.  The present and especially the future will always remain perpetually (and often uncomfortably) fuzzy.

One thought that I had regarding this area firmly connects to the area of information pervasiveness and network ubiquity.  Common household equipment such as central heating systems and washing machines often continue to remain resolutely unfathomable to many of us.   I have heard researchers talking about the notion of 'networked homes', where it is possible to control your heating system (or any other device) through your computer.

I remember hearing a comment from a delegate who attended the Open University ALPE project workshop who said, 'the best assistive technologies are those that benefit everyone, regardless of disability, such as optical character recognition'.  But what of a home of networked household goods which can potentially offer their own set of wireless accessible interfaces?  What benefit can such products provide for users who do not have the immediate need for an accessible interface?

The answer could lie with increasing awareness of the subject of energy consumption and management.  Washing machines, cookers and heating systems all consume energy.  Exposing information about energy consumption of different products could allow households to manage energy expenditure more effectively.  In my view, the need for 'green' systems and devices may facilitate the development and introduction of products could potentially contain lightweight device level accessibility APIs.

Further development directions

One of the most interesting themes of the day was the idea of the accessibility API that has made the third generation of assistive technologies what they are today.  A minor comment that featured during the day was the question of whether we might be able to make our software development tools and environments accessible.  Since accessibility and usability are intrinsically connected, the question of, 'are the current generation of accessibility API's as usable as they can be?'

Put another way, if the accessibility APIs themselves are not as usable as they could be, this might reduce the number of software developers who may make use of them, potentially reducing the accessibility of end user applications (and frustrating the users who wish to make use of assistive technologies).

Taking this point, we might ask, 'how could we test (or study) the accessibility of an API?'  Thankfully, some work has already been carried out in this area and it seems to be a field of research that is becoming increasingly active.  A quick search yields a blog post which contains a whole host of useful resources (I recommend the Google TechTalk that is mentioned).  There is, of course, a presentation on this subject that I gave at an Open University conference about two years ago, entitled Connecting Accessibility APIs.

It strikes me that a useful piece of research to carry out is to explore how to conduct studies to evaluate the usability of the various accessibility APIs and whether they might be able to be improved in some way.  We should do whatever we can to try to smooth the development path for developers.  Useful tools, in the form of APIs, have the potential to facilitate the development of useful and accessible products.

And finally...

Towards the end of the day delegates were told about a site called RaisingTheFloor.net (RTF).  RTF is described as a consortium of organizations, projects and individuals from around the world 'that is focused on ensuring that people experiencing disabilities, literacy problems, or the effects of aging are able to access and use all of the information, resources, services and communities available on or through the Web'.  The RTF site provides a wealth of resources relating to different types of assistive technologies, projects and stakeholders.

We were also told about an initiative that is a part of Aegis, called the Open Accessibility Everywhere Group (OAEG).  I anticipate that more information about OAEG will be available in due course.

I also heard about the BBC MyWebMyWay site.  One of the challenges for all computer users is learning and knowing about the range of different ways in which your system can be configured and used.  Sites like this are always a pleasure to discover.

Summary

It's great to go to project dissemination events.  Not only do you learn about what a project aims to achieve, but sometimes the presentations can often inspire new thoughts and point you toward new (and interesting) directions.  As well as learning about the Optacon (which I had never heard of before), I also enjoyed the description of the different generations of assistive technologies.  It was also interesting witness the various demonstrations and be presented with a teasing display of the complexities that lie very often hidden amidst the operating system of your computer.

The presentations helped me to connect the notions of the accessibility API and pervasive computing.  It also reminded me of some research themes that I still consider to be important, namely, the usability of accessibility APIs.  In my opinion, all these themes represent interesting research directions which have the fundamental potential of enhancing the accessibility and usability of different types of technologies.

I wish the AEGIS project the best of luck and look forward to learning more about their research findings.

Acknowlegements

Thanks are extended to Wendy Porch who took the time to review an earlier draft of this post.

Following on from the previous post, this post describes my adventures into the Moodle forums source code.

Forums, I understand, can be activities (a Moodle term) that can be presented within individual weeks or topics. I also know that forums can be presented through blocks (which can be presented on the left or right hand side of course areas).

To begin, and remembering the success that I had when trying to understand how blocks work, I start by looking at what the database can tell me and quickly discover quite a substantial number of tables.  These are named: forum (obviously), forum_discussions, forum_posts, forum_queue, forum_ratings (ratings is not something that I have used within the version of Moodle that I am familiar with), forum_read, forum_descriptions, forum_subscriptions and forum_track_prefs.

First steps

Knowing that some of the data tables are called, I put aside my desire to excitedly eyeball source code and sensibly try to find some documentation.

I begin by having a look at the database schema introduction page (Moodledocs), but find nothing that immediately helps.  I then discover an end user doc page that describes the forum module (and the different types of forum that are on offer in Moodle).  I then uncover a whole forum documentation category (Moodledocs) and I'm immediately assaulted by my own lack of understanding of the capabilities system (which I'll hopefully blog about at some point in the future – one page that I'll take note of here is the forum permissions page).

From the forums category page I click on the various 'forum view pages', which hints that there are some strong connections with user settings.

Up to this point, what have I learnt?

I have learnt that Moodle permits only certain users to carry out certain actions to Moodle forums.  I have also learnt that Moodle forums have different types.  These, I am lead to believe (according to this documentation page) are: standard, single discussion, each person posts one discussion, and question and answer.  I'm impressed:  I wasn't expecting so much functionality!

So, can we discover any parallels with the database structures?

The forum table contains fields which are named: course, type, name, description followed by a whole other bunch of fields I don't really understand.  The course field associates a forum with a course (I'm assuming that somewhere in the database there will be some data that connects the forum to a particular part or section of a course) and the type (which is interestingly, an enumerated type) which can hold data values that roughly represents the forum types that were mentioned earlier.

A brief look at the code

I remember that the documentation that I uncovered told me that the 'forums' was a module. In the 'mod' directory I see notice a file called view.php.  Other interesting files are named: post.php, lib.php, search.php and discuss.php.  View.php seems to be one big script which contains a big case statement in the middle.  Post.php looks similar, but has a beguiling sister called post_form which happens to be a class.  Lib, I discover, is a file of mystery that contains functions and fragments of SQL and HTML.  Half of the search file seems to retrieve input parameters, and discuss is commented as, 'displays a post, and all the posts below it'.

Creating test data

To learn more about the data structures I decide to create some test data by creating a forum and making a couple of posts.  I open up an imaginatively titled course called 'test' and add an equally imaginatively titled forum called 'test forum'.  When creating the forum I'm asked to specify a forum type (the options are: single simple discussion, Q and A forum, standard forum for general use).  I choose the standard forum and choose the default values for aggregate type and time period for blocking.  The aggregate type appears to be related to functionality that allows students to grade or rate posts.

When the forum is live, I then make a forum post to my test forum that has the title 'test post'.

Reviewing the database

The action of creating a new forum appears to have created a record in the forum table which is associated to a particular course, using the course id.  The act of adding a post to the test forum has added data to forum_discussions, where the name field corresponds to the title of my thread: 'test post'.  A link is made with the forum table through a foreign key, and a primary key keeps track of all the discussions held by Moodle.

The forum_posts table also contains data.  This table stores the text that is associated with a particular post.  There is a link to the discussion table through a discussion id number.  Other tables that I looked at included forum_queue (not quite sure what this is all about yet), forum_ratings (which probably stores stuff depending on your forum settings), and forum read, which simply stores an association between user id, forum id, discussion id and post id.

One interesting thing about forums is that they can have a recursive structure (you can send a reply to a reply to a reply and so on).  To gain more insight into how this works, I send a reply to myself which has the imaginative content, 'this is a test post 2'.

Unexpectedly, no changes are made to the forum_discussions table, but a new entry is added to the forum_posts table.  To indicate hierarchy a 'parent' field is populated (where the parent relates to an earlier entry within the forum_posts table).  I'm assuming that the sequence of posts is represented by the 'created' field which stores a numerical representation of the time.

Tracing the execution flow

These experiments have given me with three questions to explore:

1. What happens within the world of Moodle code the user creates a new forum?
2. What happens when a user adds a new discussion to a forum?
3. What happens when a user posts a reply?

Creating a new forum

Creating a new forum means adding an activity.  To learn about what code is called when a forum is added, I click on 'add forum' and capture the URL.  I then give my debugger the same parameters that are called (id, section, sesskey and add) and then begin to step through the course/mod.php script.  The id number seems to relate to the id of the course, and the add parameter seems to specify the type of the activity or resource that is to be added.

I quickly discover a redirect to a script called modedit.php, where the parameters add=forum, type= (empty), course=4, section=1, return=0.  To further understand what is going on, I stop my debugger and start modedit.php with these parameters.

There is a call to the database to check the validity of the course parameter, fetching of a course instance, something about the capability, fetching of an object that corresponds to a course section (call to get_course_section in course/lib code).   Data items are added to a $form variable (which my debugger tells me is a global).  There is then the instantiation of a class called mod_forum_mod_form (which is defined within mod/forum/mod_form.php).  The definition class within mod_forum_mod_form defines how the forum add or modification form will be set out.  There is then a connection between the data held within $form and the form class that stores information about what information will be presented to the user.

After the forum editing interface is displayed, the action of clicking the 'save and return to course' (for example) there is a postback to the same script, modedit.php.  Further probing around reveals a call to forum_add_instance within forum/lib.php (different activities will have different versions of this function) and forum_update_instance.  At the end of the button clicking operation there is then a redirect to a script that shows any changes that have been made.

The code to add a forum to course will be similar (in operation) to the code used to add other activities.  What is interesting is that I have uncovered the classes and script files that relate to the user interface forms that are presented to the user.

Adding a new discussion

A new discussion can be added by clicking on the 'Add a new discussion topic' button once you are within a forum.  The action of clicking on this button is connected to the forum/post.php script.  The most parameter associated to this action is the forum number (forum=7, for example).

It's important to note the use of the class mod_frum_post_form contained within post_form.php which represents the structure of the form that the user enters discussion information to.

The code checks the forum id and then finds out which course it relates to.  It then creates the form class (followed by some further magic code that I quickly stepped through).

The action of clicking on the 'post to forum' button appears to send a post back (along with all of the contents of the form) to post.php (the same script used to create the form).  When this occurs, a message is displayed and then a redirect occurs to the forum view summary.  But where in the code is the database updated?  One way to do this is to begin with a search to the redirect.  Whilst browsing through the code I stumble across a comment that says 'adding a new discussion'.  The database appears to be updated through a call to forum_add_discussion.

Posting a reply to a discussion

The post.php script is also used to save replies to discussions (as well as adding new discussions) to the database.  When a user clicks on a discussion (from a list of discussions created by discuss.php), the link to send replies are represented by calls to post.php with a reply parameter (along with a post number, i.e. post.php?reply=4).  The action of clicking on this link presents the previous message, along with the form where the user can enter a response.

To learn more about how this code works, I browse through the forums lib file and uncover a function called forum_add_new_post.  I then search for this in post.php and discover a portion of code that handles the postback from the HTML form.  I don't explore any further having learnt (quite roughly) where various pieces of code magic seems to lie.

Summary

The post.php script does loads of stuff.  It weighs in at around seven hundred lines in length and contains some huge conditional statements.

Not only does post appear to manage the adding of new discussions to a forum but it also appears to manage the adding, editing and deletion of forum messages.  To learn about how this script is structured I haven't been able to look at function definitions (because it doesn't contain any) but instead I have had to read comments.  Comments, it has been said, can lie, whereas code always tells the truth.  More functions would have helped me to more quickly learn the structure of the post.php script.

The creation of the user interfaces is partially delegated to the mod and post form classes.  Database updates are performed through the forum/lib.php file.  I like some of the function abstractions that are beginning to emerge but any programming file that contains both HTML and SQL indicates there is more work to be done.  The reason for this aesthetic (and person) opinion is simple: keeping these two types of code separate has the potential to help developers to become quickly familiar where certain types of software actions are performed.  This, in turn, has the potential to save developer time.

One of the central areas of functionality that forum developers need to understand is how Moodle works and uses forms.  This remains an area of mystery to me, and one that I hope to continue to learn about.  Another area that I might explore is how PHP has been used to implement different forum systems so I can begin to get a sense of how PHP is written by different groups of developers.

Acknowledgements: Photograph licenced under creative commons by ciaron, liberated from Flickr.

One of the great things about Moodle (other than the number of databases it can use!) is the way that courses can be easily created and edited.  One of its best features is the edit button that can be found at the top of many pages.  Administrators and course managers can push this button and quickly add and remove functionality to redesign a course or a site within seconds.

This blog post is the first in a series of two (but might even extend to three) that aims to answer the question of: how does the Moodle block editing magic work?  To answer this question I found that it was useful to split this big question into a number of smaller questions.  These are: how are blocks presented to the user?, how are block layouts stored in the Moodle database?, and what happens when the user clicks on the edit button and makes changes to the layout of a site or a course?

There are two reasons for wanting to answer to these questions.  The first is that knowing something about this key part of Moodle might help me to understand more about its architecture which might help me in the future if I have to make any changes as a part of the EU4ALL project.  The second is pure curiosity, particularly regarding the database tables and structures - I would like to know how they work.

There are two broad approaches that I could take to answer these questions: look at things from the top down, or from the bottom up.  I could either look at how the user interfaces are created, or I could have a look at the database to see if I can find data tables that might be used to store data that is used when the Moodle user interface is created.  In the end I used a combination of top down and bottom up approaches to understand a bit of what is going on.

This post will present what I have learnt about how Moodle presents blocks.  The second post will be about what I have found out about the database and how it works (in relation to Moodle blocks) and what happens when you click on the various block editing icons.

There will be load of detail which will remain unsaid and I’ll be skipping over loads of code subtleties that I haven’t yet fully understood!  I’ll also be opinionated, so advance apologies to and Moodle developers who I might inadvertently offend.  I hope my opinions are received with positive spirit, which is the way that they are intended.

Introducing blocks

Blocks are bits of functionality which sit on either side of a Moodle site or course.  They can do loads of stuff: provide information to students about their assignment dates, and provide access to discussion forums.  When first looking at Moodleworld, I had to pause a moment to distinguish between blocks, resources and activities.  Blocks, it might be argued, are pieces of functionality that can support your learning, whilst activities and resources may be a central part of your learning (but don’t quote me on that!)



Not long after starting looking at the blocks code, I discovered a developer page on the subject.  This was useful.  I soon found out that apparently there are plans to improve the block system for the next version of Moodle.  The developers have created an interestingly phrased bug to help guide the development of the next release.  This said, all the investigations reported here relate to version 1.9+, so things may very well have moved on.

Looking at Index

Blocks can be used in at least two different ways: on the main Moodle site area (which is seen when you enter a URL which corresponds to a Moodle installation) and within individual courses.  I immediately suspect that there is some code that is common between both of them.  To make things easy for myself, I’ve decided (after a number of experiments) to look at how blocks are created for a Moodle site.

To start to figure out how things work the first place that I look at is the index.php file.  (I must confess that I actually started to try to figure out what happened when you click on the editing button, but this proved to be too tough, so I backtracked…)

So, what does the index.php file do?  I soon discover a variable called $PAGE and asked the innocuous question of ‘why are some Moodle variables in UPPERCASE and others in lowercase?’ I discover an answer in the Moodle coding guidelines.  Anything that is in uppercase appears to be global variables.  I try to find a page that describes the purpose of the different global variables, but I fail, instead uncovering a reference to session variables, leaving me wondering what the $PAGE class is all about.

Pressing on I see that there are some functions that seem to calculate the width of the left and the right hand areas where the blocks are displayed.  There is also some code that seems to generate some standard HTML for a header (showing the Moodle instance title and login info).

The index page then changes from PHP to HTML and I’m presented with a table.  This surprises me a little.  Tables shouldn’t really be used for formatting and instead should only be used to present data.  It seems that the table is used to format the different portions of the screen, dividing it unto the left hand bunch of columns, a centre part where stuff is displayed, and a right hand column. 

It appears that the code that co-ordinates the printing of the left and right blocks is very similar, with the only difference being different parameters to indicate whether things appear on the left, and things appear on the right.

The index file itself doesn’t seem to display very much, so obviously the code that creates the HTML for the different blocks is to be found in other parts of the Moodle programming.

Seeding program behaviour

To begin to explore how different blocks are created I decide to create some test data.  I add a single block to the front page of Moodle and position it at the top on the right hand side:



Knowing that I have one block that will be displayed, I can the trace through the code when the ‘create right hand side’ code is executed using my NuSphere debugger to see what is called and when.

One thing that I’m rather surprised about is how much I use the different views that my debugger offers.  It really helps me to begin learn about the structure of the codebase and the interdependencies between the different files and functions.

Trying to understand the classes

It soon becomes apparent that the developers are making use of some object-oriented programming features.  In my opinion I think this is exactly the right thing to do.  I hold the view that if you define the problem in the right way then its solution (in terms of writing the code that connects the different definitions together) can be easy, providing that you write things well (this said, I do come from a culture of Java and C# and brought up, initially, on a diet of Pascal).

After some probing around there seem to be two libraries that seem to be immediately important to know about: weblib and blocklib.  The comments at the top of weblib describes it as ‘library of all general-purpose Moodle PHP functions and constants that produce HTML output’.  Blocklib is described as, ‘all the necessary stuff to use blocks in course pages’.

In index, there is a call to a function called blocks_setup (blocks, I discover, can be pinned true, pinned both, or pinned false – block pinning is associated to lessons, something that I haven’t studied).  This function appears to call another function named   blocks_get_by_page (passing it the $PAGE global).  This function returns a data structure that contains two arrays.  One array is called l and the other is called r.  I’m assuming here that array data has been pulled from the database.

The next function that follows is called blocks_have_content. This function does quite a bit.  It takes the earlier data structure, and translates the block number (which corresponds to which block is to be displayed on the page) and converts it into a block name through a database call.  The code then uses this name to instantiate an object whose class is similar to the block name (it does this by prepending ‘block_’ to the start).

There is something to be cautious about here: there is a dependency between the contents of the database (which are added to when the Moodle database is installed) and the name of the class.  If either one of these were to change the blocks would not display properly.

The class that corresponds to the news block is named ‘block_news_items’.  This class is derived from (or inherits) another class called block_base that is defined within the file moodleblock.class.php.  A similar pattern is followed with other blocks.

Is_empty()

Following the program flow, there is a call to a function called is_empty() within blocklib.php.   This code strikes me as confusing since is_empty should only be doing one thing.  Is_empty appears to have a ‘side effect’ of storing the HTML for a block that comes from a call to get_content to a variable called ‘content’.  Functions should only do what they say they do.  Anything else risks increasing the burden of program comprehension and maintenance.

The Moodle codebase contains several versions of get_content, one for each of the different blocks that can be displayed.  The version that is called depends on which object Moodle is currently working through.  Since there is only one block, the get_content function within block_news_items is called.  It then returns some HTML that describes how the block will be presented. 

This HTML will be stored to the structure which originally described which block goes where.  If you look through the pageblocks variable, the HTML can be found by going to either the left or right array, looking in the ‘obj’ field, then going to ‘content’.  In ‘content’ you will find a further field called ‘text’ that contains the HTML that is to be displayed.

When all the HTML has been safely stored away in memory it is almost ready to be printed (or presented to a web client). 

Calls to print_container_start() and print_container_end() delineate a call to blocks_print_group.  In this function there will then be a database call to check to see if the block is visible and then a call to _print_block() is made.  This is a member function of a class, as indicated by the proceeding underscore.  The _print_block() can be found within the moodleblock.class file.  This function (if you are still following either me or the code!) makes a call to print_side_block function (which is one of those general purpose PHP functions) contained within weblib.php.

Summary and towards part 2

I guess my main summary is that to create something that is simple and easy to use can require quite a lot of complicated code.

My original objective was to try to understand the mechanisms underpinning the editing and customising of course (particularly blocks) but I have not really looked at the differences between how blocks presented within the course areas and how blocks are presented on the main site.  Learning about how things work has been an interesting exercise.  One point that I should add is that from an accessibility perspective, the use of tables for layout purposes should ideally be avoided.

What is great is that there is some object-oriented code beginning to appear within the Moodle codebase.  What is confusing (to me, at least) is the way that some data structures can be so readily changed (or added to) by PHP.  I hold the opinion that stronger data types can really help developers to understand the code that they are faced with since they constrain the actions that can be carried out to those types.  I also hold the view that data stronger typing can really help your development since you give your development tools more of an opportunity to help you (through presenting you with autocomplete or intellisense options), but these opinions probably reflect my earlier programming background and experience.

On the subject of data types, the next post in this series will be about how the Moodle database stores information about the blocks that are seen on the screen.  Hopefully this might fill the gaps of this post where the word ‘database’ is mentioned.

Acknowlegement: Picture by zoologist, from Flickr.  Licenced under creative commons.

This post describes my second bash at understanding PHP and SOAP webservices, work carried out off and on over the last couple of weeks. The first time I connected PHP to an externally hosted web-service was using a script that I wrote that was external to Moodle. Now my challenge is slightly different: to try to get Moodle calling external web services.

Just to make sure I understand everything, I'm going to present some background acronyms, try and remember what pages I looked at before, then step towards uncovering parts of Moodle that are in some way connected to the magic of web services.

Background information

I'm required to interface to web services that use the SOAP protocol (wikipedia). SOAP is, I am led to believe, an abbreviation for Simple Object Access Protocol. In a nutshell, SOAP allows you to send a message from one computer to another, telling it to do stuff, or asking it a question. In return, you're likely to get a response back that either tells you what you wanted or indicates why your request had failed. SOAP is one of many different techniques that you can use to pass messages to one computer to another over the internet.

Another technique, which is simpler (and faster) but has some limitations that SOAP gets round, is REST (wikipedia). More information on this 'architectural style' can be found quite easily by doing a quick internet search. My focus is, however, SOAP.

So, assuming that one computer exposes (or makes available) a web service to another computer, how do other computers know how to call a service? In other words, what parameters or data does a particular service expect? The answer is that the designers of SOAP service use a language that describes the format of the messages that the SOAP server (or service) will accept. This language is called WSDL, or Web Services Description Language (wikipedia).

Each SOAP server (or service) has a web address. If you need to find out what data a SOAP service requires, you can usually ask it by adding ?wsdl after the service name. This description, which is presented in a computer readable structure, can sometimes help you to build a SOAP call – a request from your computer to another.

Very often (in my limited experience of this area), the production and use of this intermediate language is carried out using layers of software tools and libraries. At one end, you will describe the parameters that you will process, and some magic programming will take your description (which you give in the language of your choice) and convert it into a difficult to read (for humans!) WSDL equivalent. But all this is a huge simplification, of course! And much can (and will) go wrong on the journey to get SOAP web services working.

A web service can be a building block of a Service Oriented Architecture (again, wikipedia), or SOA. In the middle, between different web services you can use the mysterious idea of middleware to connect different pieces of software together to manage the operation of a larger system, but this is a whole level of complexity which I'm very happy to avoid at this point!

Stuff I looked at earlier

The first place that I looked was in a book! Specifically, the PHP Cookbook.

Chapters 14, consuming web services, and 15, building web services looked to be of interest, specifically the sections entitled 'calling a SOAP method with/out WSDL'. Turning to this section I was presented immediately with a number of possibilities of how to make SOAP calls since there are a number of different implementations depending upon the version of PHP that you're using.

Moodle, as far as I understand, can work with version 4.3 of PHP, but moves are afoot to move entirely towards version 5. My reference suggested its perhaps best to use the bundled SOAP extension as opposed to the other (PEAR::SOAP or NuSoap) libraries since they are faster, more compatible with the standards, automatically bundled and exceptions (special case errors) that occur within SOAP are fed into corresponding PHP exception constructs to make programs (theoretically!) easier to read.

Consuming services

On my first attempt to call a web service, I ran into trouble straight after starting! All my code was failing for a mysterious reason and my debugger wasn't deciding to give me anything that was useful. After doing some searching and finding some on-line documentation I gave the PEAR library a try, but ended up just as confused. I ended up asking one of my illustrious colleagues for help who suggested that I should add an additional parameter to original attempts using the PHP extensions to take account of local network setup.

Calling seemed to be quite easy. I could create something called a SOAP client, tell it which address I want to call, give it some options and make a call my sending my client a message which has the same name of the web service which I want to call, optionally loaded up with all my parameters. To see more of what came back, I put some of the client variables in some temporary variables so I could more easily watch what was coming back in my debugger.

Producing services

Now that I (more or less) knew how to call web services using PHP, it struck me that it might be useful to see how it might be possible to present web services using PHP. This was found in the next chapter of the book.

To maintain consistency, I asked the question how might I create some WSDL that describes a service? Unfortunately, there is not an easy answer to this one. Although the integral SOAP libraries don't directly offer support to do this, there are some known techniques and utilities that can help.

One of the big differences between PHP and the WSDL language is that PHP is happy to just go ahead and do things with data without having to know exactly what form (or type) the data takes. You only get into trouble when you ask PHP to carry out operations on a data item that doesn't make sense.

WSDL, on the other hand, describes everything, giving both the name of a data item and its type. Because of this, you can't directly take a PHP data structure and use it to create WSDL. To get round this difference one approach is to provide this additional information in the form of a comment. Although comments are intended to help programmers, they can also be read by other computer programs. By presenting data type information in the form of a comment, an intermediate program can create WSDL structures without too much trouble, saving developer time and heartache. This approach is used by both the NuSoap library and code that works with PHP 5. But I digress...

Moodle web services code

There appear to be some plans to expose some of the Moodle functionality via a series of web services, enabling Moodle to be connected to and used with a range of external applications. There is also a history connecting Moodle with external assessment systems using web services.

A grep through the Moodle codebase (for 1.9) reveals a library called (perhaps unsurprisingly) soaplib. There appears to be some programming logic which makes a decision about which SOAP interface library to use, depending upon the version of PHP: use the native version if PHP 5 is used, otherwise NuSoap.

I'm guessing that the need to use the NuSoap library will gradually disappear at some point, but a guess is totally different from finding out whether this is really going to happen.

One way to find out what is going on and what lies in store for the future is to explore the on-line discussion forums and quickly find a forum that is dedicated to discussing Moodle web services. It appears there are two interesting developments, something called the Moodle NetWork (which allows you to share resources between different instances of Moodle, at a first glance), and non-core Moodle code contribution called the OKTech Web Services. After a little poking around it's possible to find some documentation that describes this development in a little more detail.

I also discovered a documentation page entitled Web services API , but is related to XML-RPC (wikipedia) rather than SOAP. My head is beginning to hurt!

Returning to the Moodle core SOAP library, I ask the question: what uses the soaplib? One way to do this is to search for calls to functions that are contained within this library. I have to confess, I didn't find anything. But, what I did find is a discussion.

It turns out it was added as a result of work carried out at the University of York in the UK for a project called Serving Maths that created something called the Remote Question Protocol (RQP). The initial post mentions concerns about not being able to make use of some of the additional parameters that the PHP 5 library provides. This is a concern that I share.

Next steps

I've more or less finished my whistlestop tour of Moodle components and code that relate to web services type stuff. I'm sure there is more lurking out there that I haven't discovered yet. But what of a conclusion?

Since I'm not planning on using Moodle to expose any web services I can thankfully sidestep some of the more difficult discussions I've uncovered.

Also, since there isn't much in the way of existing SOAP utility code that I can build upon and I roughly know more or less how to call web services using the magic functions that are provided in PHP 5, I'm going to try to more or less directly add some lines of code to Moodle. But before I do this, like every good developer, I'll test things out using a test harness to explore how my target services behave.

Image: modified from wikipedia