Reflection with Interactive Tabletops: an Evaluation


Last Tuesday Jose and I had the opportunity to experiment on a couple of students during a thesis poster presentation taking place just before the last #chikul13 class. While Jose was focussing on making students more aware through ambient displays, I did my first test-run of the Navi Tabletop Application. As you may remember, we’ve been awarding students with activity and progress badges. This app visualises these achievements and gives students a collaborative tool to reflect upon their work.


The rapid prototyping with my custom HTML5/CSS3/Javascript framework works! I managed to get a fully functional tabletop prototype with actual badge-student relationship visualisations working in a weekend. Here’s a quick before-after screenshot comparison.


(please ignore the English in the screenshots, I have no control over the badge descriptions sent back to me by the data repository ;))

The bezier curves are courtesy of Paper.js. While I moved away from using a canvas element to draw my interface, it’s great as an extra layer to draw more demanding objects, like the relationship lines.

As I explained before, I want to create a tool to support collaborative reflection between students and teacher. The teacher would then guide this process. However during my testing on Tuesday I decided to let them freely explore the app by themselves and see what happens.

Navi Tabletop App

Let’s start with a quick explanation of how the app works.

navi_v2_step1 navi_v2_step2

Badges can be dragged onto the playfield (the top 70% of the screen). Students who have been awarded this specific badge will light up (in blue) in the student container. The opposite is also true: dragging a student onto the playfield will light up the badges in the badge container that this specific student has earned.

navi_v2_step3 navi_v2_step4

The highlighted items together show the union of the relationships with the items in the playfield. Touching an item in the playfield will show its relationship to other items in the playfield through connected lines. This will also limit the highlighted items (students or badges) to the ones related to the touched object.

Badges are awarded every 2 weeks. The user can cycle through these time periods in the badge container.

Test Chamber 1

I decided to use the think-aloud protocol, give no scenario and see whether the students could make sense of the tool and data by themselves. I filmed the whole process using a camera on a tripod and asked them to fill in a survey afterwards. For students who weren’t part of the #chikul13 course I gave a bit of background information on the badge system.

During the one hour poster presentation session, 14 students tested the application. 2 groups of 3 people and 2 groups of 2 people used the table simultaneously. The remaining 4 people used the application by themselves.

Almost everyone figured out how to use the app without guidance. Users started dragging items onto the playfield and started seeing and understanding the relationships between names and badges.

The most interesting events occurred when students of the #chikul13 course grouped up with their actual #chikul13 group members (they work in groups of 3 during the course): At one point they became interested in seeing their group badges per period. They dragged out their names and started cycling through the time periods. When noticing a low amount of awarded badges, they started reflecting about that period and found reasons for the lack of badges. They also saw which periods what person was more active and had an awkward but funny moment when 2 of them had a negative badge for not commenting at all during a 2 week period.


That group I just mentioned was a perfect example of our ideal target audience. It was interesting to see them behave the way they did: discussing and reflecting over their progress in the #chikul13 course even though the amount of data they were given was limited.

As for people using the tabletop app by themselves, results were less interesting. They were struggling to continue exploring and needed a little push now and then to have ideas on what to do. But as I am aiming for a collaborative tool, this isn’t a big issue.

The survey showed similar results. Students would like to use the tool with others, however there was more interest in using the tabletop with other students than with a teacher. The word “fun” was used a few times when asked if the collaboration added anything to the experience. They also admitted that using the tool together invites for more communication and quicker understanding of the data. Almost everyone agreed that more information would certainly improve the application as the actual comments, posts and tweets (on which the awards are based) aren’t yet available through the tabletop.

It was clear that the UI wasn’t flawless. People tried double tapping and wished the lines would remain visible when letting go of objects. Due to some issues with the time period selection and a lack of a time period spanning the entire course timeframe, people weren’t convinced the tabletop app helped them get a good total overview of the class’s progression

The survey also contained a SUS questionnaire. This resulted in a SUS score of 71 counting all students, 76 counting only the #chikul13 students. An above average score which is not too bad for a feature-limited prototype with a very specific purpose.

What’s Next

I am pretty happy with these results and it was exciting to see the students play around with the Navi Tabletop App. But there is a lot of room for improvement.

Period selection

First up is the time period issue. While I could fix the button’s responsiveness and provide the user with better visual feedback, I believe cycling through the periods is not necessary at this level of the interface. I will remove it and bring it back at badge level (including a default full course timeframe selection).


Items light up when related items are dragged onto the playfield, but this wasn’t obvious enough to some users. A more visually striking highlighting (e.g. animation) that catches users’ attention might solve this problem.

Double Tap

Quite some users attempted double tapping, something not very common on touch screens. I believe the lack of actions available on items might be the cause of this double tapping reaction. Some users expected the lines connecting related items to remain visible while the “correct” action was holding a finger down on the item. Adding action buttons to items in the playfield to support these kind of features could indirectly solve this behaviour.

Badge Information

People had to drag the badge all the way onto the playfield to see its description.  A simple touch should already show that information.

Lack of Information

The big next step is showing the actual blog/comment/tweet data. Most people agreed this would make the application more useful. Once Jose’s StepUp! backend can provide me that information, I’ll be adding that functionality to the tabletop. This will hopefully bring the reflection process to a whole other level.

Another Time Perhaps

Great, you got this far! I bet you were hoping on a video and… there isn’t one. But fear not, one will be posted soon! Screenshots and text can only say so much right?

Feedback, comments and ideas more than welcome as always, so feel free to fill that comment box below!

Reflection in Learning: Tabletops & Beyond

Last Wednesday our HCI group had the opportunity to meet with the folks of CUO, the Centre for User Experience Research, at the Social Science department of our university for a little brainstorm session. I was asked to present a bit of my work with which I threw a few ideas into the group and which provided me with some nice feedback. The slides of my presentation are available here, but they are pretty visual so won’t make much sense without me yapping along to them. The first half is much in line with what I’ve posted here and here though. As for the second half, let me give you an update.


We want to promote reflection and think our badge data is a good starting point. The badge data is an abstract, high level representation of the activity and achievements and can be a central access point from which we can further drill down into the raw data. While a student can figure things out by himself, input and guidance from a teacher through this reflection process can greatly improve the result. Putting students and teacher around a table for discussion seems like a good idea, so why not use a digital tabletop?

Tabletop Reflection

Let me explain how the first few steps of this process would work:

We put the teacher and a couple of students around the tabletop. The teacher drags out the names of the present students onto the tabletop. These expand and become the students’ personal consoles.

The teacher then pulls up the badges. As the tabletop app now knows which students are standing around the tabletop, it can adjust its badge visualisation and limit it to data relevant to these students. Dragging a badge onto the tabletop will expand the badge, provide more options such as showing its relation to the students and the class and provide a drilldown point to more information, in our case: tweets, blogs, comments, etc.

This provides the teacher and students with the basic elements required to facilitate discussion and reflection. The teacher has an immediate overview of the progress and the data of the students. He/she can give feedback, discuss the artefacts and guide the students in their learning process with the data available on the tabletop. The students can study and discuss the artefacts and compare their own work to that of their peers.

A couple of screenshots of the rough tabletop prototype:

Fullscreen_07_05_13_11_52 Fullscreen_07_05_13_11_51-4


Let’s do a quick tech intermezzo, before we lose half of the audience ;) While the goal is to create a tabletop reflection tool, we also want the technology to support multiple platforms. I walked away from the pure Paper.js idea I mentioned previously though and have now created a custom Javascript framework to suit my specific needs. The framework logic is built on a mix of Object-Oriented with Component-based design, the visual design is all HTML5 and CSS3. This allows me to quickly create classes that support multi-touch, animations (CSS3 and custom) and event triggers and can easily be hooked up to the DOM elements. No rocket science, just very helpful for rapid prototyping ;) As an example, the above prototype was developed in a couple of days.


The features required in our process aren’t all available yet in our prototype but will be developed soon. The next step (after some evaluations) will probably be about how we can expand this to collaboration. We want the students to collaborate around the tabletop but also collaborate with people out in the field. Imagine students outside or even out of the country being guided by the tabletop users and in turn providing the class with realtime data from these locations. Google Glass as a direct stream to what’s happening there? Why not!

We think there is potential in not just taking learning outside and the outside into the classroom, but also bringing these learning artefacts and analytics into the real world. We have more interesting ideas on this and how to involve the parents into the process, but more on that later. If I tell you everything now there’s no reason to come back right? ;)

Unified UX/UI across tabletops & mobiles

Let’s get a bit more technical today. I’ve been talking a lot about the pedagogical side of things but have been neglecting the technical aspects. Since I’ve spent the last 10 years as a software engineer, not a teacher, a “tech” blogpost seems in order..

If you’ve read my previous post you know I’ve developed Navi, a badge dashboard, which is a small (on-going) Java project running on Google App Engine. This dashboard allows students and teacher to access class progression data through their mobile phone and desktop browsers.

We want to take this a step further and go beyond desktops and mobile devices by exploring the possibilities of tabletops and ambient screens in class rooms and create collaboration and reflection tools using the learning analytics data we possess (Step Up!). Our goal is to create a unified, always-present digital environment that spans across all these devices and delivers a homogeneous UX and UI through its unique look and feel.

The requirements

Visual Uniformity
While a uniform look might help brand identity, our main reason to create a visual uniformity is to create a similar UX across all platforms. Moving from one device to another should be a seamless experience and require little extra effort from the user.

The learning analytics data we have needs to be visualised. To engage students we will require something more than tables and forms, certainly when we consider deploying on tabletops and creating interesting ambient displays.

Cross Platform
Creating a unified experience across this big range of platforms is tricky. Using each native environment would be very time consuming. While multi-platform tools do exist, they would not allow for the flexibility we require. (we have a couple of students comparing such tools for their master thesis here and here)

Multi-touch Interactivity
Multi-touch devices such as tablets, tabletops and (specific) ambient displays allow for rich multi- and single-user experiences. Therefore we need a solution that will not limit us to simple single touch interaction.

The technology

While web applications have always been a good solution to go cross platform, it’s only since the arrival of HTML5 that web development has become really viable to create proper applications. With the new Canvas element and CSS3 we can create much more interesting visualisations and UIs and aren’t limited anymore to the basic objects provided by the HTML framework. Throw some Javascript into the mix and you have yourself a very potent, interactive, animated, vector-based canvas to work on that runs across any device (with a proper web browser anyway).

There are quite a few libraries for visualisations on the web. Examples are D3.js, Processing.js and Paper.js. As the UI will be an important part of my development, my preference went to Paper.js, a vector graphics framework supporting scene graphs, bezier curves, interactive animations and more. As it is more focused on pure vector drawing (instead of data visualisations focus of D3.js), it seemed more suited for the job. With my game development background, it also felt a bit more familiar ;)

To create the unified touch experience, Javascript and HTML5’s touch events are a great starting point. We immediately have support for mobile devices and can easily support tabletops using the npTuioClient browser plugin and MagicTouch.js script which allows TUIO connectivity.

For my backend I continue using Java, building on the current Navi project by exposing its data through a RESTful webservice.

The framework

Getting this technology to work is quite straightforward, but I need an abstraction layer so I can focus on the UX and visualisations without having to worry about the underlying libraries. Therefore I’m first developing a simple UI framework (currently “cleverly” named Navi Framework) around this technology that will let me easily create the UI elements and interactions.

The explanation of the actual design of this UI framework deserves its own blogpost and since we’re busy hosting the #lak13 conference in Leuven it will have to wait another week. But if you have any thoughts on the technology I am using or have any interesting suggestions, feel free to throw your comments my way!

Learning from games

First a short recap, in case you haven’t read my previous posts: we are awarding the students in our #chikul13 course with badges in the same way achievements are awarded on Xbox360, Playstation3 and Steam. Our first results do indicate certain facets of this gamification are appreciated by our students and have a positive impact on their work. Badges in learning are quite new but maybe we can learn something from the years of experience all of you have with achievements, be it in games.

I remember not everyone was excited when Microsoft decided to introduce achievements 8 years ago. The overal Gamerscore, a total sum of all achievement points, would become the main focus for some. While it did boost sales, it didn’t always reward good game design, just easy achievements. Soon Sony would follow, as would PC games and even Apple with its Game Center. Achievements aren’t going anywhere soon it seems…

So I look at you, game developers, journalists and gamers. What do you think of achievements today. Please do post your comments and while you’re at it, could you answer a couple of the following questions?

  1. Do you check your own achievements?
  2. Do you compare your achievements with friends?
  3. Does knowing your friends’ achievements change the way you play your game?
  4. Do achievements cause you to play more/explore more than you would without them?
  5. Would you still play all the games you play today without the achievements?
  6. Do you check achievements on other devices? (mobile, websites,…)
  7. [for the designers] When designing achievements, what is it you want to achieve? (Replay, exploration, sales,…)

Happy Easter!