Learning Technology Developer Opinon

Digital filtering

No, not the infinite impulse response filter, but what digital tools do for us, and against us – the wrong tools are as bad or worse than no tools. Free speech is in the tooling, not the content.

It’s a bit of a cliche to quote Marshall MacLuan when discussing digital technologies, but his insight that a new medium “roughs up” a society by its mere existence is apt

McLuhan tells us that a “message” is, “the change of scale or pace or pattern” that a new invention or innovation “introduces into human affairs.”

The scale, pace and pattern of digital technologies means they are now, and will become moreso, the primary means of our expressing ourselves in many spheres of life. And if not the primary means, certainly an enabling/disabling means. Even a traditional analogue sculptor is likely to order some tools or supplies online.

Why does this matter in Academia? A key role of research in academia is to identify and solve societal, technical and medical problems before they crop up in the future, or at least put in place the means to rapidly respond to surprises we might receive. For example

“Early efforts by scientists at Oxford University to create an adenovirus-based vaccine against MERS provided the necessary experimental experience and groundwork to develop an adenovirus vaccine for COVID-19.” – Dr. Eric J. Yager, Albany College of Pharmacy and Health Sciences in Albany, NY

We usually don’t have the time to start working on a problem when it manifests – imagine if we had to wait 10-15 years for covid vaccinations, rather than just one year due to the headstart from MERS.

Quite often these subject-specific results can be adequately expressed via the traditional route of disseminating papers, videos, and datasets, so the existing digital tools for dissemination are at least broadly adequate. And research communities around the world have a long-standing capability in developing the new experimental apparatus they require, using a combination of off-the-shelf and custom equipment and software. In the humanities, some research areas require the creation of new digital tools, and researchers undertaking this task are appropriately skilled.

Yet when we consider the other role of Academia – to produce graduates with attributes that maximise their potential for solving the future problems of the world, we start to see a bit of an issue emerging. Unlike the research world, the teaching sector is heavily reliant on external software and has less of a culture of build-it-yourself-when-needed (these tasks often go in the too-hard basket, or the can’t-be-resourced basket). This is a supposedly pragmatic response to the issue of the scale, and risk of delivering a teaching experience to many students. But it does not let us avoid the core problem. It is a short-term response that creates a longer-term problem. Why? Let’s start by considering an outrageous example.

Imagine if Microsoft and Adobe overnight decided that we should not use the colour green in any document created with their systems. We would have to give up using green, or learn to use the excellent open-source tools for photo-editing and drawing such as GIMP, Inkscape and OpenOffice. Imagine the fuss! Clearly, no commercial supplier would take such odd action. Yet, what if as thought leaders in the world, there becomes a new value, or principle that is so important to academia, or more likely, a particular institution, that cannot be implemented/expressed/actioned with the existing software they use. What if their inability to express that is as distressing as not being able to use the colour green?

This could occur if we want to start living our academic values in a more consistent way. For example, should we wish to develop a new approach in education that is not catered to by the existing externally-supplied software, or even just tweak something that is not culturally appropriate, then we face a brick-wall of uneditable black box code.

Since it costs money and time to create, implement and test a software architecture with flexibility – knowing what to keep constant is a key skill and those choices are influenced by the culture, values and philosophies of the architect. So what happens when that choice doesn’t work out for other users? For example, if we have a grade reporting system that shows traffic lights to represent pass-fail, then a single threshold is insufficient because the pass/fail mark varies by country, institution and study level, so you can find institutions for whom a pass is 40% in the UK, 50% in the USA, and 60% in China. A system hardwired for US courses is inappropriate in many UK and Chinese institutions. It might even be quite difficult to retrofit that change when reported to the creators. So, do you give up on traffic lights, or create your own software, or wish for a world in which things were open-source and you could edit/tweak and adjust what you need, when you need it?

Did you start to sweat at the risk of making changes to the codebase, testing them, rolling it out, and running a custom service? How is that different to running a University printing press back when pen and paper was the norm. We managed the transition to publishing, now we need to manage the transition to the academic sector being able to create, modify and operate its own digital tooling where it needs to.

This is important in higher education where the development of graduate attributes not currently assessable with examinations (probably marked in Gradescope) will more than likely require new digital tools with culturally-specific features that vary by subject, level, institution and country. The external supply of what we need will at best severely lag our demand, and incompletely support our needs, if we leave it to market forces to create. The alternative is to be able to create the novel digital tooling we need within the sector, using open source licenses, so that others can modify to suit themselves, without having to start over. What do we need to do? I have some thoughts on the digital literacies helpful to STEM education developments here.

Curator Embedded Systems Developer Learning Technology Developer Provider User Interface Developer

There’s plenty of room in the digital.

The famous physicist Richard Feynman once said “There’s plenty of room at the bottom” – in fact, he gave an entire talk about it. Perhaps a similar sentiment applies to digital education. This post arises from remarks I made during a presentation to the University of Edinburgh Learning Technologists on 26 April 2021, at an internal event.

If you are a learning technologist, or learning technology developer, or otherwise active in the space of helping academics do digital things with their teaching, then remote laboratories are an area you should start considering now. There’s time to develop and enhance your digital skillsets before they become mainstream.

We need remote laboratories regardless of any physical distancing constraints, as we pointed out before the pandemic:

They open up pedagogical opportunities that are either new, or we think used to exist, but are likely to have been squeezed out by resource constraints, such as:

  • reflective learning
  • student-led explorative learning
  • learning difficult or counter-intuitive concepts
  • authentic assessment
  • student co-creation
  • answering questions via interactive live demonstrations

These opportunities are created because:

  • it’s cost-effective enough to provide spare capacity for students to spend time doing self-directed exploratory learning
  • it’s digitally mediated so you can develop assessment methods that draw on the flow of data between the lab and the students, rather than relying on the students writing up yet another report.
  • students can create their own experiments, and therefore learn by teaching others.
  • the experiments are always online, always accessible.

What is a remote lab?

There are a number of different possibilities on a spectrum from real-time interaction with real equipment, all the way through to virtual and simulated labs ….

  • real-time interactive experiments with a lab sheet
  • real-time interactive experiments without a labsheet
  • real-time interactive experiments either
    • solo
    • in a group (working together on same kit, or different)
    • with a tutor/demonstrator/staff in digital attendance
  • batch jobs (for using one piece of kit to do lots of fast experiments for lots of students all around about at the same time)
  • pre-recorded real data replayed as if collected live – this takes some effort to set up, but can be done by all students simultaneously
  • simulated data (mathematically generated data, either in advance, or live, depending on the particular mechanisms you are working with)

Our remote labs don’t require any special hardware interface boxes, just as long as there is some form of computing device which can run our software that manages the data and video streaming – and that is more than adequately handled by a Raspberry Pi 4 B (we use 4GB RAM but 2GB would be fine).

Our experimental setup uses widely known hardware such as Arduinos and Raspberry Pis, and our cross-compilable streaming software.

Use cases:

A number of use cases come to mind immediately – you will think of others too. Making the campus a playful science museum, accessible remotely and by those physically present is one of the great things I look forward to. Here’s a list of some uses:


  • demonstrate important principles in contact sessions by screen-sharing an experiment
  • develop experiments for use by students on your course to collect and analyse data, preparing a report for assessment (I know I just said you didn’t need to, but this is a good starting point!)
  • set students group-work that requires jointly planning and carrying our experiments on the same piece of kit
  • set students group work that requires them each to individually plan and execute experiments on equipment with different parameters (size, weight, etc), and compare notes to develop an overall model of a phenomena
  • set students group work that requires diverse range of experiments to be carried out, in order to approach a problem from multiple angles
  • students explore operation of equipment out of curiosity, prompting questions in class
  • students ask staff questions, even unanticipated ones, which can then be answered with a live interactive demonstration using experiments found in the catalogue
  • students send in samples to analyse e.g. via remote microscope
  • students develop new experiments (e.g. senior year design it, a mid-year builds it and a junior year uses it)
  • share experiments with colleagues around the world
  • modify other colleagues’ experiments to better suit your own teaching needs
  • develop your own user interfaces and teaching materials to depend your own understanding
  • allow others to access your equipment using their own user interfaces and materials (with suitable safety measures in place so the hardware can protect itself no matter what user interface is in use)


  • Research groups make their prototypes and demonstrators available online for sharing with other academics, industrialists, commercialisation partners, and for demonstrations in advanced classes
  • Outreach activities allow students from schools to work with university-level equipment (perhaps with a different user interface to match the activities they will do)
  • recruitment – a single ambassador can connect every student in the classroom to an experiment in a subject of interest to them – no need to take equipment in a car or van anymore
  • public engagement – run events where the audience work together on individual experiments and share results to form overall trends (e.g.
    • characterise chaotic double pendulums, or
    • control multiple ground penetrating radar robots to piece together an archeological dig, or
    • control individual vehicles in an arena to explore swarm dynamics and artificial intelligence.
  • contribute to teaching at your local schools, further education and higher education establishments, and vice versa
  • entertain and inform visitors on campus

What about this room in the digital?

There are at least three distinct ways to to contribute ….


  • unpack course intended learning outcomes (ILO)
  • identify pain points in current delivery (e.g. lab restrictions, etc)
  • identify “longed for” opportunities
  • come up with creative experiment designs to target specific ILO that can be addressed by remote labs, bearing in mind pain points and desired changes
  • create supporting materials for academics and students where needed (designing the sessions etc)


  • provision and arrange access to experiments and user interfaces for each class as required
  • handle support requirements that sit somewhere between purely academic issues, and purely equipment issues
  • check, collate, track and report on usage analytics both for pedagogic and accounting purposes
  • arrange extensions, access to alternative equipment and provide advice on experiments that could be used


There’s plenty of room here – if you know / develop Javascript and HTML5 skills then there is a huge amount you can do to create and enhance new experimental activities with existing hardware. Going further, if you do embedded systems, you can make new hardware, and if you do web server development or operations, you can enhance and evolve the infrastructure of the system itself. Some specific points:-

  • Design and commission new user interfaces from web developers with the necessary Javascript & HTML5 skills
  • Modify and remix existing user interfaces to suit academic and student needs (we’re using vue.js, which is relatively straightforward but also capable)
  • Perform tech testing of new interfaces on different combinations of VLE, browser, computing equipment etc where that differs from testing by anyone who developed the experiments originally
  • Commission or indeed directly implement additional experimental instances from existing open-source hardware designs (e.g. order printed circuit boards, populate with components, download and install the firmware, build and connect the hardware)
  • Install and configure streaming software on Raspberry Pis
  • Manage a fleet of experiments using the management interfaces
  • contribute to server and booking system testing, development and documentation (currently in Golang).


Remote labs are going to become mainstream in the near future. There is a great deal of scope to add value in the adoption of existing experiments into courses, as well as developing and evolving the activities, and even the experiments. To get involved on the digital side is relatively straightforward, because well-known ecosystems are being used, such as Vue.js interfaces in Javascript, Arduinos for hardware, Raspberry Pis for the streaming, and golang for the servers. The management tools are currently pretty sparse to non-existent, but will develop in a similar direction to VLE management tools (but also with APIs if you like scripting). There is time to develop additional skills in this area and jump on the wave – there’s plenty of room in the digital.