InPlenary: Co-located Interactive Lectures




Figure 1: Pictures from InPlenary lecture. (a) Me lecturing, (b) Screen with delegated navigation and interaction, (c) Screen with discussion slide and comment field.

In my PhD I explored various ways to design for places and co-located interaction. One of the systems we developed was a co-located lecturing system that distributed the lecture slides and interaction widgets to client devices using the local network access point as a signer for location-based content. The core idea was to make the traditional university lecture an interactive object that could facilitate richer interactions between the participants in the lecture. We worked from the following scenario:

“A lecturer enters the classroom and open their computer. They sign into the InPlenary application and navigate to today’s lecture slides. When activated, the projector in the room automatically1 shows the lecture. The lecturer can see a small view of their slides on their screen, their notes and a preview of the next slide. […] The students open their computers and login to InPlenary. They can see a preview of the current lecture in the room (which is also on the projector) and open it. When opened they can see a small view with the current slide and a note-taking widget where they can make notes. As the lecturer navigates through the slides, they also change on the student’s computers.”

To support the above scenario (and the idea of interactive widgets), we developed a slide authoring module that would ingest a pdf slideshow and transform it to an interactive lecture. In the authoring tool, the lecturer could add notes and interactive widgets to each slide. We also developed a system for coupling the lecturer and student computers to a specific room, and a module for running and distributing the slides to the client machines.

Interactive widgets

We developed a series of interactive widgets that could be added as an overlay to the relevant slides. We selected a couple from the research literature on Audience Response Systems: Voting, commenting and essay feedback. We added two additional widgets: Navigation delegation and learning progression feedback. See the scenarios below.

Quiz voting

“The lecturer change to a slide with a quiz question: Who was the proposer of the concept of Ubiqiotus computing? On the student views a voting widget is introduced with options. As they enter their vote they get a confirmation. Their vote is persisted with their notes for later review, together with the correct answer. When the lecturer ends the vote, the results are overlayed on top of the current slide. They initiate a discussion of the result.”

Comments and voting

“The lecturer change to a slide with an open question. They invite the students to discuss the question with the student next to them. When they have discussed the question, they enter a reply into the comment widget. Once they have added a comment, they can vote on the replies from the other students. The lecturer shows the 3 top voted replies and they discuss these.”

Supporting lectures and later review

We examined statistics on slide access in our existing learning management system. We observed two things: Students download slides at the lecture and we saw a huge spike in downloads when they used the slides as supplementary material when studying for the exam. To support this use-scenario we implemented a way to persist the student notes and lecture response data with the slides and a review module where the students could review and reflect on the material when studying for the exam.

“Four months after the exam a student is studying for their exam. They login to the InPlenary system and navigate to the lecture above. They can navigate through the slides, review and edit their notes, and replay the exercises. They can also review the comments, replies and input produced collectively in the class to aid their understanding of the concepts.”

Background: Designing for place and common interactive objects

The system explored several of the questions in my PhD thesis, in particular how to design interactive systems and applications for places? The short idea was to explore how we can design systems for particular places2 that serve multiple functions and multiple user demographies (e.g. libraries, community centres, educational institutions, urban spaces). InPlenary combines ideals from ubiquitous computing and ideas about common information spaces from CSCW.

When designing for a place, we need to consider two requirements. First, the inhabitants (the students) bring their own devices into the space. We need to support multiple different devices and cross-device interaction. To address this we decided to implement the system as a web-application. Second, we need a way to establish location. In this case we utalized the existing network infrastructure to establish a connection between the devices and the room.

In the system, each classroom access point (AP) is assigned an unique key that is exposed through a small webserver running on the AP. When participants use the network, background services can query the AP for the key and send that along to the lecture system backend. This would match the user with a classroom, and when the lecture starts, a collection of slides (see figure Figure 2).

Clients would listen to slide changes and update the slides on each client device. With a personalized loging, students can write notes for each slide, answer interactive quizzes and provide feedback for classroom assignments etc. These would be persisted with the slides, so that the information is available when students review the lecture material later.


The system is implemented across multiple modules. Each was developed as a rather thick client3, with the location service and persistance happening on a web-server.

  actor Student
  participant AP
  participant Server
  actor Lecturer

  Student->>Server: Student login
  activate Server
  Server-->>Student: Student page with lectures
  deactivate Server
  Student->>AP: get roomID
  activate AP
  AP-->>Student: return roomID
  deactivate AP
  Student->>Server: enter lecture room 
  activate Server
  Server-->>Student: Lecture Room
  deactivate Server
  activate Server
  Lecturer ->> Server: Start lecture
  loop every n seconds
  Lecturer ->> Server: Change slide
  Student->>Server: Query current slide
  Server-->Student: return new slide
  Lecturer ->> Server: Stop lecture
  deactivate Server

Figure 2: Sequence diagram coupling clients to a room via an access point

cluster_3 InPlenary [Software System] 1 Lecturer user [Person] 4 InPlenary Author module [Container: HTML/CSS/JavaScript] Web-application 1->4 Lecturer uploads slides and add interactive widgets 5 InPlenary Lecture module [Container: HTML/CSS/JavaScript] Web-application 1->5 Lecturer starts lecture 2 Student user [Person] 2->5 Login to system 6 InPlenary Review module [Container: HTML/CSS/JavaScript] Web-application 2->6 Login to system 2->6 Select past lecture 7 Backend service for persiting lectures [Container] PhP 4->7 Transforms PDF to PNG and adds interactive widgets 5->7 Loads lecture 5->7 assigns room id to lecture 5->7 process login 5->7 Fetch room lecture 8 Access Point webserver [Container] PhP 5->8 Query AP for room id 6->7 process login 6->7 fetch lecture 7->5 Show home screen 7->6 Show lecture list 7->6 Replay lecture with interation data 10 WAYF login [Software System] Existing Login provider 7->10 query login 9 Lecture database [Container: MySql] Lecture database 7->9 Persist lecture 8->5 returns room id 10->7 Approves login

Figure 3: C4 Container view of InPlenary (A bit chaotic – needs cleaning).

Pilot and Evaluation

We piloted the system in two lectures to test the rebustness of the system. Following this we invited two lectureres from a different department to test the system in their lecture:

We collected use data and surveyed and interviewed the participating students about their experience with the system. For multiple reasons the system and research was only reported in my PhD thesis. It is used as a case in Beaudouin-Lafon et al. (2021) paper on “Generative Theories of Interaction”

I have wanted to return to this project and the system multiple times to do a more elaborate writeup, but I have not have the time.


Beaudouin-Lafon, M., Bødker, S., & Mackay, W. E. (2021). Generative theories of interaction. ACM Transactions on Computer-Human Interaction (TOCHI), 28(6), 1–54.


  1. yes, UbiComp!↩︎

  2. Places, not location-based stuff. Places are meaningful to the people who inhabit these and use them for multiple activities. “Location” does not capture that. Think place as a user experience construct and location as a minor usability construct. There is a longer version of this argument in my thesis.↩︎

  3. For production, I would make a thin client instead and delegate more to the backend. However, when prototyping one often end up with a thick client.↩︎