Review of the Visualization Course at KTH: A Matter of Trust

Usually, I prefer to keep feedback regarding courses internal. This time however, I think it is worth speaking out because there are many things that were handled the right way in this course.

First, I describe some of the student projects and explain why I consider them to be successful. Then, I explain how the course was setup. I list the issues that need to be addressed by the students and by the teacher in such a setup, and describe how they were handled in the project. Altogether, I try to find out in the retrospective why the projects were successful.

The student projects

Time-scaled maps of public transport in Stockholm

Maps are often helpful in measuring distance as the crow flies. A group of students decided to generate time-scaled maps of the public transport in Stockholm, such that users can select a subway station and see the isometric map change into a isochronic map. The excellent part about this project was that the students decided to go way further than creating a prototype with dummy data. The changes of travel times during the day could be visualized by smoothly warping isochronic map. The students extracted real travel data from the local transport provider instead of feeding in fake data. Great.

Wave simulation

Another team created a wave simulator that visualized simulated waves for different parameter settings, such as the wind speed at a certain height above the sea level. The graphical user interface was very organized and given the expertise in numerical programming required to use mathematical models for simulation on computers, also doing a job that goes beyond the topic of visualization.

Exploration of functional MRI data

Visualizing 3D data is challenging. Two students accepted the challenge and created a whole toolbox for exploring functional MRI data of a brain. The toolbox was so extensive that they could not find the time to show every feature at the final project presentation – I have often seen projects that were struggling with exactly the opposite problem.

3D Magnetosphere Game

This game took advantage of a wall-sized screen in the visualization lab. The magnetosphere around two planets was visualized in 3D, and users wearing the necessary goggles could explore somewhat exaggerated effects of the magnetosphere. Nice textures, smooth rendering, and the possibility to play asteroids in 3D as well made the project results convincing.

Volume-rendered virtual objects with gesture control

The idea in this group was to render a virtual three-dimensional object from sliced data (e.g. from a computer tomography scan) on the GPU and having a RGB-D camera that lets the user control the pose of the virtual object with a single hand. This was the project I was participating in, and while I am always very critical with my own products, the audience seemed to like what we came up with.

The course setup

The visualization course was project-based and there were no real lectures in the classic sense where a teacher was presenting topic by topic. Instead, the first two lectures were used for joining groups and finding good problems to work on. Some milestones gave the project some structure and helped both the teacher and the students to monitor process. Our teacher took the time to help the groups individually, and his task seemed to give feedback and put some of the projects back on track which were not fitting in scope or having troubles with certain blocking issues.

There was no exam. Instead, the milestones, the final presentation, and the final product was graded. Why did these teams come up with such nice projects? I am convinced that it was both due to the fact that the teacher trusted in the students, and the students being motivated to create some product for the sake of the experience and for the sake of the product itself. In the following, I look what challenges are involved for both teacher and the students.

Working with the right people on the right problem

It is crucial for the success that you work with the right people on the right problem. What I want to stress is that it is hard to recruit the right people without knowing which problem you are going to work on. Similarly, it is hard to choose the right problem without knowing which people you are going to work with.

I have taken courses where the students were assigned to groups by teachers. This calls for trouble because there is no mutual agreement to work together – an absolute prerequisite for the somewhat distributed work arising in a course project during a term with other courses. The positive aspect is that the group has at least a chance to decide on a project that suits them.

Yet another course took the approach of listing projects first and then allowing students to form groups by themselves and then asking them for priorities to which problems they would like to work on (some problems were solved by several groups in parallel). This approach is not possible if you want to give the students a chance to do something new, something the teacher has not thought of.

The approach in the visualization course let the students solve both tasks at the same time. The process of finding the right problem and finding the right people is clearly quite unstructured: the students just need to mingle. I am convinced that this is a very good idea and addresses the first-mentioned criteria for success to a certain extent: work on the right problem with the right people.

A problem that is not solved yet is the factor of time. Usually, I tend to let some time pass, iteratively improving on my options on what problem to work on, and who might be interested in which problem. In the course, these decisions needed to be made quite on the spot. Ideally, I would like to have known a couple of weeks earlier that the visualization course was project based. Then I could have done some brainstorming about which of my project ideas fit that course and the scope before the course starts.

Working together in a distributed environment

One of the toughest problems with group projects during a term at university is the distributed nature of the university studies. Every student usually has his or her own schedule. Every student has many courses in parallel and his or her own priorities. This makes the exchange of information during project work difficult. Meetings are difficult to schedule and often not too productive. Even scheduling a meeting takes time and efforts. This course did not give an answer to this problem but at least gave the projects some structure by specifying milestones that then do no longer need to negotiated by the team members.

The length of the leash

It is not clear how much pressure is helpful. This is an issue that the teacher has to deal with. Shall the teacher apply more pressure in order to make the students perform better? Is increasing the pressure leading to nicer products? Would it work if the course were not graded at all? That are questions that are difficult to answer.

The requirements by the grades define a common denominator among the team members. The grades obviously define a minimum requirement to pass the course and no student usually signs up for a course without aiming at passing that course. In a simplistic way of thinking, this implies that by increasing the requirements for passing and by checking progress more often, the students projects should reach higher and higher standards.

However, if grading issues and the related pressure gain weight, then the students put increasing efforts in finding out how to satisfy these requirements with minimal effort. This is a smart thing to do but often results in projects where the effects of this strategy are clearly visible.

In the visualization course given by Mario Romero, the grades were obviously necessary to guarantee a certain standard in the projects. However, the grading never really became such an issue that other rewards lost their appeal. And engineering students usually have a rewarding system where satisfaction is inherently tied to the product: a nice product rewards for all the work put into it, so working on the product is what matters, not the grades behind it. In order to make this mechanism work, the leash needs to be long enough. In order to avoid that some students try to chase for cheap credits, the leash needs to be short enough. A short leash however is often just a hassle for those who are goal-oriented and motivated on their own. In the visualization course I attended, the leash was long enough.