Bachelor Thesis Log 6

August 24th, 2010

Today's post is about the promised surprise topic: In the context of the iPhone Power Day that took place today, Kai Meyer (an employee of C1 WPS) held a teachlet on the topic “MapKit integration on the iPhone” in the ESA B lecture hall in front of about 100 people. We had contacted each other beforehand due to a tip from Axel and I talked to him about what a teachlet presenter has to consider, what I think about holding a teachlet with such a large number of participants and how such a teachlet should be designed.

Today, I sat down in the lecture hall and took over the role of the tracker – meaning I took detailed notes about the progress of the teachlet. In the teachlet workshop, this log will be used by the teachlet developers to revise the choreography and adapt it to reality. In this context, I was particularly interested in how fluidly a lecture hall teachlet could function.

The goal was 60 minutes, but it only took 45. Here is the sequence:

Kai Meyer, Aug 24 2010, ESA B – iPhone Power Day

05:02pm Greetings
05:04pm Explaining the teachlet concept

05:05pm Describing the initial system
05:07pm Task
05:08pm What is MKMapView
05:09pm Class diagram target system

05:11pm Looking at initial system

05:12pm Beginning implementation
  :13pm Adding a button to the interface
  :15pm Defining an action
  :16pm Linking action and button
  :18pm Implementing a dummy method
  :19pm Debugging
  :21pm Adding MapView
  :23pm Showing user location
  :24pm Creating new UIViewController
  :25pm Linking controller and map
  :27pm Activating controller
  :28pm Test drive
  :31pm Changing MapType and title

05:32pm Task has been fulfilled
05:33pm Showing prepared target system

05:34pm Showing coordinate passing
05:35pm Showing automatic zoom
05:37pm Summary
05:39pm Questions
05:45pm End

Compared to the classic teachlet, this one had a few special features that made it particularly exciting for me. First of all, it rarely happens that a teachlet is held in front of such a large group of participants. This means that it is not possible to have a design discussion like in a seminar-like teachlet unit because, first, there are too many people present for everyone to have their say and, secondly, the acoustics make a discussion between a smaller number of participants impossible. In this case, the moderator had a microphone to be intelligible to the very back of the room. The participants (I keep catching myself wanting to write “audience”) were only able to vocally contribute short interjections.

What worked unexpectedly well in my eyes was to let the participants decide the sequence of implementation. The facilitator asked the participants completely openly what should be done, and then was able to implement each shout-out directly. The participant leadership in implementation, typical of teachlets, could be implemented without much difficulty here as well. A possible limitation, however, is that the target group was not advanced iPhone programmers and the participants probably did not know any other solution than the one targeted.

In context and for the objective, I think the unit clearly succeeded. The question that has the greater relevance for me, however, is whether it is really a teachlet in the sense of the revised definition.

Teachlet Definition 2.0.1

Here is the definition from two weeks ago, into which I have also incorporated the corrections from your comments (and more minor changes by me):

A teachlet is a highly interactive teaching unit in which an executable piece of software is modified in such a way that it fulfills a clearly defined task. This is chosen in such a way that a clearly defined learning objective can be achieved through the change. A moderator motivates the initial system as well as the change to be made in a shared view with the participants (e.g. on a projector) and is then guided by the participants to carry out the necessary changes to the software. For the solution of the task, there exists a solution space with several possible architectural variants, in order to make a draft discussion possible. The moderator has the task of directing the discussion, of recording intermediate results and of bringing about agreement on an objective for the implementation. After the joint implementation phase, the software ideally fulfills the previously set task. A teachlet also includes documentation that is relevant for the preparation, such as a detailed choreography and an implemented target system.

Did We Experience a Teachlet Today?

Kai Meyer's event was highly interactive and it involved modifying (programming) software by the participants. A clearly defined task was given (add a MapView to existing software), which led to a clearly defined learning goal (learn about the simplicity of the MapKit API). Work was done on the projector and participants guided the change steps (by shouting). For the solution space, it's a bit of a sticky point… essentially, there was one solution in the air because the participants didn't have enough experience to come up with another. In principle though, other solutions would have been possible, and there's only a “shall” in the definition, not a “must” – so I don't feel bad about letting it pass. The moderator fulfilled his tasks well, the objective was achieved (the map worked). To what extent detailed documentation exists for the teachlet, I don't know.

Conclusion: It is quite clear that the concept implemented today is still a teachlet, which was only unusual in some respects. As I said, it still worked quite well.

Future

For next week I hope to have some news regarding the interviews and maybe about organizational aspects. Tomorrow I'll talk to Axel again about the progress so far and the next steps. By Tuesday at the latest, you'll find out here how things are going.