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.”
Navigation delegation
“The lecturer change to a slide that ask the students to review the last 5 slides with software engineering models. They are tasked discussiing the models on how each model deal with iteration. To support the students in group discussions, the lecturer delegates control of the five slides to the students, so they can navigate back and forth between the models and the guiding questions. When the exercise is over, the lecturer retake control and navigates to a slide where the students can reorganize a list with the models from least to most agile. The students complete the exercise and the class review the final list.”
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.
Implementation
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.
sequenceDiagram
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
end
Lecturer ->> Server: Stop lecture
deactivate Server
Figure 2: Sequence diagram coupling clients to a room via an access point
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.
References
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.
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.↩︎
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.↩︎
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.”