Bachelor Thesis Log 6
You are reading an older blog post. Please be aware that the information contained in it may be technologically outdated. This text may not necessarily reflect my current opinions or capabilities.
This is an English translation of a blog post that was originally published in German.
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.
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.