Old blog articles

Back in January of this year, the Internet Archive published their interactive DOS game library, allowing anyone to play old games that used to run on MS-DOS machines right in their browser, without the need for any plug-in or external software. This was very inspiring to me and reminded me of the time when I took my first steps in the world of programming using Turbo Pascal and compiling for DOS. Naturally, I made games in it.

I made a mental note to check out the underlying technology, but in January I was knee-deep in the process of finishing my master's thesis (followed by a move and a new job), so the “DOS in my browser” thing went somewhere near the bottom of my priority list.

In early June I dedicated a weekend to finally figuring that stuff out, which culminated in me adding a playable version of Revelation Mentis to my website. The way I first learned programming was by taking existing source code (typically little games) and tinkering with it, first changing values, then single instructions, then larger blocks of code. RM is notable in my personal history for being the first game (as well as the first non-trivial program) that I created on my own and completely from scratch, so it seemed like a good candidate for something to put on my website for posterity.

As I found out, many talented developers have made this process comparatively smooth – smoother than I had expected, anyway. Still, it's not a “drag and drop” kind of solution, you still need some coding chops to put all the pieces together. I'd like to walk you through what I did, just in case you're interested in doing something similar or you're curious about how it works.

Setting up the build environment

In a nutshell, emscripten compiles C/C++ code to JavaScript, while DOSBox is an application that can run most DOS applications, including my old Revelation Mentis binary. I won't pretend to be knowledgeable enough about emscripten to know how exactly the various abstractions are divided between the two, but the end result is a (from what I can tell) complete version of DOSBox including graphics, sound, file system access and more that runs without a hitch in modern browsers.

My development machine is running Ubuntu Linux 15.04, which packages emscripten 1.22 as of today. That turned out to not be enough for the version of DOSBox that I used, so I got the portable SDK and followed the instructions for installation of the most recent version of emscripten on Linux, which are straightforward. The compilation involved can take a while though, so it's best to have your beverage of choice ready at this point.

With a recent version of emscripten up and running, the next step is to grab em-dosbox, a port of DOSBox to emscripten maintained by Boris Gjenero, and follow those installation instructions as well. The first “make” command leaves you with a bare instance of DOSBox compiled to HTML and JavaScript. Due to the same-origin policy, you'll need to launch the generated webpage through a local webserver (for example “python -m SimpleHTTPServer 8000”) to get it running.

Packaging the game data

The next question is how to get the DOS application binary into our webpage. The em-dosbox documentation has instructions for that too, the tool includes a packager that can easily put your EXE file into a virtual filesystem that em-dosbox can later use. That should allow you to quickly get your DOS application up and running.

In the case of Revelation Mentis, I had some fine-tuning to do in order to get the exact experience that I wanted. Out of the box, some characters in the title screen ASCII art are rendered wrong. This is because my machine from back then used code page 850 and I (blissfully ignorant of internationalization at the time) used the 0xF7 Cedilla as part of my game's title screen. After a few minutes spent on the DOSBox wiki, I learned that I needed a dosbox.conf with the line “keyboardlayout=gr” in the “[dos]” section to rectify this problem. Unnecessarily, this should also change the keyboard layout to German for all users, but as it turns out Revelation Mentis only uses keys that are identical on US and DE keyboards, so it's not an issue. Packaging my dosbox.conf along with the game binary was accomplished by following em-dosbox instructions again.

By default, the generated instance of DOSBox automatically launches the intended binary. Unfortunately, after exiting the game the user is left at a DOS prompt. By passing it the “-exit” parameter, DOSBox can be instructed to terminate itself after the designated DOS process has ended. There are two easy ways to accomplish this with em-dosbox, you can either modify the packager script to include the option (advisable if you're rather sure you want this behavior for everything you package) or you can modify the generated HTML file afterwards (recommended if you just want to test it out or you're not sure if it's what you want).

If you decide to adjust the packager script, look into “src/packager.py” for the line where a string containing “Module['arguments']” is being written – in the current repository snapshot I'm looking at it's line 124:

f.write("Module['arguments'] = [ " + cmdline + " ];\n</script>\n")

Please note that this is Python code outputting JavaScript code (and a closing HTML tag), so don't waste too many brain cells wrapping your head around the syntax here. You can add the exit parameter as follows:

f.write("Module['arguments'] = [ '-exit', " + cmdline + " ];\n</script>\n")

If you instead decide to change the generated HTML file, it's actually that very line that the packager script is writing that you need to adjust. Look for the JavaScript line starting with “Module['arguments']” that looks about like this:

Module['arguments'] = [ './binary.exe' ];

And change it to this:

Module['arguments'] = [ '-exit', './binary.exe' ];

But keep in mind that this line gets overwritten every time you run the packager.

After all this, I had a version of DOSBox inside a webpage that ran my game as intended. The only remaining task was to change the resulting webpage into something suiting my tastes.

Polishing the front end

With all the compiling and packaging woes out of the way, you should now have one HTML file and some JS and data files. This is where your HTML and JavaScript knowledge comes in and you get to make whatever changes you want to the HTML code. There's nothing particularly challenging or unique about this part, so I'll just quickly go over what I did.

I hid a number of UI elements that I didn't want, like the DOSBox stdout text field and the graphics/mouse settings. I chose to hide them through CSS rather than outright removing them, since I wasn't sure how the DOSBox JavaScript actually interacts with them, and I didn't feel inclined to disentangle the DOSBox JS, the DOM elements and the glue code in order to remove them cleanly.

I applied a palatable dark gray background and a drop shadow – this is of course up to personal taste and you may want to go with your own design. I also added a CSS-based loading animation from Tobias Ahlin's SpinKit to be displayed while the browser fetches the data files.

I wrote a JS snippet that adjusts the size and position of the DOSBox HTML canvas depending on the window size. It's a pretty neat little algorithm that actually causes the game to “snap” to clean multiples of its native resolution of 320x200 with some tolerance, preserving pixel-accurate rendering whenever possible.

Somewhat notably, I also added a little JavaScript hack to detect when my game would finish running. Since DOSBox was configured to terminate upon the process ending, all drawing operations to the HTML canvas element would simply cease. So what I did was to check the document title for the currently running process, which DOSBox updates while it's running. As soon as the name of my game binary no longer appears, I hide the canvas element and show a “Thank you for playing” message instead.

Conclusion

And that's pretty much it! As you can see, while the whole process is certainly not geared towards the average user, it's nothing that an adventurous hobbyist coder couldn't get done in an afternoon.

Now something that I haven't really talked about is the amount of abstraction in this technology stack. My first reaction to the Internet Archive DOS game library was probably something along the lines of “Wow, JavaScript has come a long way.” It's hard not to be impressed by what amounts to a PC emulator running in JS inside a browser. However, with abstraction comes overhead, and my little 20KB DOS binary now requires 35MB of data to be downloaded by the user (the bulk of it is DOSBox I assume). It's a DOS binary running inside DOSBox, which has been compiled to JS using emscripten, running in a browser on my – and your – machine.

Any real discussion of the ramifications of this technology for archivists and the question whether everything should be running in a browser would definitely exceed the scope of this article, but when I first tweeted about this renaissance of Revelation Mentis, someone linked me this talk, which I found fun to watch.

Please let me know if this is helpful to you! If it compels you to play around with emscripten and do something cool, I would like to see the results!

Today the User Experience Roundtable Hamburg (in cooperation with the local IxDA) hosted a talk by Sebastian Deterding titled “9.5 Theses on Gamification” (Sebastian has information on earlier iterations of the same talk available online). For me it's been the first uxHH Roundtable for a good couple of months, but this topic with this speaker I couldn't pass up.

So I just got back from there and I'm pretty tired, but I have some unfinished thoughts rummaging around my head that I'd risk losing by going to sleep. They might not be excessively polished (or even necessarily cohesive), but I'm going to take the red pill and embrace the now-famous Edmund Snow Carpenter quote: “[C]lear speaking is generally obsolete thinking. Clear statement is like an art object: it is the afterlife of the process which called it into being. The process itself is the significant step and, especially at the beginning, is often incomplete and uncertain.” So please bear with me, this blog entry is not an attempt at a scientific paper.

First of all, I have to say Sebastian's overview of the history of gamification was excellent. In my presentations I've always been pretty vague and limited myself to providing a rough timescale. Sebastian apparently did some serious detective work and laid bare all the gory details. That part alone would've been worth the travel through the snow. Major props! It bears mentioning that, while important on a meta level (talking about gamification), that information is essentially trivia and, by itself, doesn't have that much intrinsic value (for pursuing gamification, whatever that may mean).

The implied question that comes with every gamification talk ever, is how to actually do that thing. I felt like Sebastian did a good job at steering people away from the checklist approach decried by Ian Bogost. He outlined some fairly established properties of games and how/why people play, and why it is very difficult to bring those in line with whatever snake oil / gamification salespeople tell you about the bottom line. (Side note: Last week, in an interview about gamification, I've wondered aloud whether the word itself is even salvageable for the long term, or whether it will inevitably go down in history as a marketing fad.)

So what do we tell someone who wants to “get started”, after all the stuff about the value of the player experience has been established? The easy approach, the one I've used so far, is to more or less point people to game design resources. “You want to make good games,” I say, “so here's what experienced designers say about how to make good games.” This also has the neat side effect of alienating checklist aficionados who don't actually want to learn anything new. I'm not even disappointed in them, their failing projects will be disappointing enough. I could link you to that Gartner press release now, but I don't really want to outwardly promote their current position just because it happens to align with my own narrative.

Something else that has jumped out at me is how many talking points (not necessarily from Sebastian's talk, but in general from the discussion surrounding gamification) would be fairly obvious if people, you know, actually played some games. I've seen and heard people talk about gamification who seemed like they hadn't touched a game since Tetris. I mean, how believably can someone talk about player engagement and emotional impact if they've never even saved a princess? (By the way I'm not saying classic games couldn't be emotionally intensive – fact is, they can be.) Sebastian, in contrast to those unnamed people, seemed to be at the very least in touch with gaming culture: we chatted for a bit about Desert Bus for Hope and I did recognize his Sword & Sworcery wallpaper. Small cues like these stabilize the assumption that he does indeed “know games” from more than a purely academic perspective.

I should probably wrap this up this right about here, so in summary I listened to a fantastic talk on gamification that ended up teaching me a good amount of new facts, evoked some new questions, challenged some beliefs and strengthened others. All in all, a valuable experience!

On a related note, I've been drafting a blog entry about an example for games achieving emotional impact through their mechanics, by toying with player expectations / mental models and seemingly “changing the rules.” It's currenty sitting at slightly under 2000 words and should be finished either this week or next.

As my studies continue towards their inevitable conclusion, I am once again faced with the situation of having to write a bachelor thesis some time soon-ish. I'm fortunate enough to have already written one of those, so it's not as much of a big unknown for me as it is for others (which doesn't mean that it's routine in any way either). I'm currently (and have been for a good couple of weeks, actually) in the process of brainstorming possible topics. By now I figure I'm not going to make any steps forward by twisting and turning stuff in my head over and over, so here I am late thursday night trying to put some of it into writing. I also thought I might as well involve y'all, since that seemed to work pretty well the first time around.

This time, though, I'll tentatively be writing in English, because in this line of academia you have to make the transition to English at some point, thus why wait?

For those of you not quite in the loop, here's the basic situation: I'm currently at the tail end of a dual curriculum involving the Bachelor of Science in Human-Computer-Interaction and the Master of Science in Computer Science (“Informatik”), so I actually have to write two final theses. They could be somehow connected or they might be completely distinct, that's up for me to decide. I'll be focusing on the bachelor thesis first and foremost.

At my department at the University of Hamburg, a bachelor thesis should be adequately completed in three months of full-time work (which might be changing to five months, or so I've heard). The clock typically does not start ticking until the topic of the thesis has been clarified, often in the form of a written exposé. The first challenge, thus, is to find a suitable topic.

Personal Interest

Obviously, my personal interests are the biggest and most important factor and dictate my specialization in the field. Viewed through the lense of project planning, this is a question of motivation first and foremost. A bachelor thesis is something that you have to persistently work on, literally for months, and from my experience it rarely leaves your mental focus. I know that if I had to write a bachelor thesis on a topic that isn't interesting to me, that I don't feel passionate about, it would just destroy me. That could just be me, I'm sure some people manage to do it. But I don't have that kind of stubborn persistence to give 110% for a single creative work over several months if I can not feel passionate about it. It's vitally important to me that I can write my bachelor thesis on a topic that I actually find interesting.

Flashback: My last thesis in 2010 was about “teachlets,” a method for facilitating software design education, to which I was exposed in a seminar and which left a lasting imprint. I was so fascinated by the concept that I asked its originator, Axel Schmolitzky, to supervise my bachelor thesis on that same topic. He was a bit apprehensive, because he didn't know whether the task we devised for me would lead to a well-rounded bachelor thesis, and he actually offered me a number of “easy ways out”: more precise and controlled lower-risk topics with a higher base chance of success. I chose to take the risk, and my final grades indeed ended up reflecting the truth that my findings did not lead to an outstanding bachelor thesis (it certainly wasn't bad, but also not as good as other things I've done). It did, however, make a lasting contribution to the teachlet community and Axel did not hesitate to attest its scientific value. I'm proud to say that I regret nothing.

Since some time in 2008 or 2009, I've had a heightened interest in Human-Computer-Interaction, usability and related areas. My first bachelor thesis had very little to do with those things, so I promised myself that the next one would definitely be grounded there. Since then, I have specialized my courses appropriately and I have been active in our HCI group, mostly as a student assistant helping with the teaching. I've had time to better familiarize myself with the field and I've begun to stake out areas that I find very interesting versus areas that tend to bore me.

The concepts of usability and user experience are, upon close inspection, still so new and ill-defined that they help very little in narrowing down the whole field of HCI. At their core, these words refer to a common-sense understanding that there have to be some reasons why certain systems are more efficient, easier and more pleasurable to use by a human than others. Research questions in this area range from the deepest depths of psychology (what kinds of tasks are our minds able to handle well, how does work satisfaction arise?) to mechanistic, data-driven evaluations that are not so very different from determining the computational complexity of any algorithm without human components. The fascination that arises from the interaction of these contrasting viewpoints is actually one of the influences that originally lured me in. I would love it if my upcoming bachelor thesis could make a contribution to existing knowledge on how to make computing more accessible and less intimidating for more people around the world.

In contrast, the topic of games and play is one that kind of snuck up on me. The UX community at large has had a bit of a focal shift in recent years, away from the traditional central question of “How can we make all this less of a hassle and annoyance?” to “How can we make this more of a pleasurable and rewarding experience?” Perspectives like Don Norman's Emotional Design caused a rising number of usability professionals to ponder concepts like fun. From that angle, games seemed like a logical thing to investigate, and before I really knew what was happening, I was reading books about game design. I maintain that I'm not interested in becoming a professional game designer or ludulogist, but I fancy myself moderately well-versed in the principles, particularly regarding engagement, motivation, and fun. I don't expect to design/develop a game, but if this knowledge happens to somehow fit into my bachelor thesis, all the better!

Lasting Relevance

Usually, a bachelor thesis does not contain groundbreaking research. There are exceptions of course. Even if it does not warrant publishing the results in a scientific journal, the thesis may still offer some scientific relevance, or it may not. If a bachelor thesis is written in close contact with a company, for example, it is often highly specialized work that is not interesting for anyone outside that company – although, again, there are exceptions to this.

In any case, I would like my bachelor thesis to have as much relevance to the scientific community as possible. I've never published a paper before, but I would very much like that to happen before the end of my studies. It's not a requirement (especially since these things can not be 100% predicted), but as far as I can influence it, I plan on doing so.

Aside from the scientific relevance, I would also love to create something that other people can build upon and make use of. Something useful, in short.

What now?

In any case, the work has to fit within the allotted timeframe. Other than that, I need a supervisor, a role for which, given my preferred topics, only one person at the department really qualifies: the current professor for HCI. In fact, I'll be talking about my ideas with him tomorrow.

I anticipate that I'll return to a weekly schedule with these reports at some point, though possibly not right from the beginning. For now, I'll write one of these whenever there are enough news to warrant it. I hope that you'll be with me again and I'll see you around!

Last week I was talking to the current professor for HCI at the University of Hamburg in his office, and among the current set of books that he was asked to assess for inclusion in our department's library, something caught my eye. I recognized the cover design of John Ferrara's Playful Design, published very recently by Rosenfeld Media. That was pretty exciting for me, since I had been looking forward to that book for a while, to the extent that I recommended it in a recent talk about gamification, just on the basis of the introductory article at UX Magazine. This occassion presented me with a chance to actually read the whole thing, so here's what came of that.

Topic and Relevance

Here's the blurb from the publisher's website linked above:

Game design is a sibling discipline to software and Web design, but they're siblings that grew up in different houses. They have much more in common than their perceived distinction typically suggests, and user experience practitioners can realize enormous benefit by exploiting the solutions that games have found to the real problems of design. This book will show you how.

Those few lines already managed to catch my attention, since they state something that I've been also thinking and talking about for a while. Usability engineering and interaction design have somewhat become my core interest concerning my studies of computer science, and I've dabbled in game design occassionally, passively (I enjoy some amounts of well-crafted gameplay in my free time) and actively (most visibly in a rather enjoyable real-time strategy game prototype that I developed with a few other students a couple of years ago, that I sadly have yet to document in a world-accessible way).

My recent drive to put games and playful experiences into the spotlight might be fueled partially by the tendency of our current faculty to dismiss games as mostly uninteresting and irrelevant to our work. (Since Timo left, games don't really have a “voice” at our CS department anymore.) I don't mean this as an insult, both mck and Claudia have highly interesting and relevant research topics for our little HCI group, it's just that games happen to not be among those.

Last semester I gave a talk about the challenges of interface complexity in our research colloquium, in which I showcased explorative learning in games by explaining the extraordinarily well-engineered level design of Super Mario Bros on the NES, stage 1-1. This seems to have been a real eye-opener for some of the visitors as to how much thought can go into a good game – they had simply never looked at them so deeply.

So John Ferrara's book, to which excellent timing (in the sense that the UX community can profit immensely from it right now) has been attributed by Hamburg's own Sebastian Deterding, is also excellently timed for me on a more individual level. It's a great opportunity to further the discussion about games in the HCI context at our department. More on that later.

Mini Summary and Review

The book contains three main parts subdivided into four to six chapters each, on 200-odd pages in total. You could say that the three parts roughly contain 1. clarification of what games are and how they're impacting UX practices, 2. how to create games that don't stink, and 3. how games can help us do other things than just relax after work.

It is rather clear about its audience: Playful Design is aimed at UX practitioners who recognize that games may hold something of value to them at least insofar as they're willing to read a book about it. It is not aimed at aspiring game designers without any UX background – although it would probably work, there are other, better-fitting books for them. The ideal reader is someone who has at least some HCI-related knowledge and wants to understand “what's the deal” with games. No experience playing video games is required, though it would probably be helpful for following along.

To give an example: There's a chapter about play-testing and how it relates to the quality of the finished game. The author draws parallels to classic usability testing and highlights the differences. If you know nothing at all about usability testing, parts of this chapter may be hard to follow. You don't need years of experience of course, just a cursory idea will do plenty to help you.

It succeeds in conveying central concepts and messages. I found the way that it delves into UX, psychology and game design very well-rounded. Please note that it is not a textbook on either of those subjects, but is concerned with their overlap and interaction. If you've studied one of these subjects in depth, you might find yourself thinking “well yes, this is nice, but there's so much more.” Indeed there is, but if you're looking for e.g. a fundamental introduction into human psychology, you should look elsewhere.

Playful Design is more of an “applied science” type of book, designed to let you know how to tranform theoretical knowledge into practical results. It reminded my of Steve Krug's famous Don't Make Me Think in its hands-on, “this is how you could do what you do better” kind of way, while also supplying adequate citations for its assertions. Language-wise, it is thankfully not comparable to typical computer science papers, but can be easily and fluently read even by non-native English speakers like me. I read it over the course of a weekend, during which I did plenty of other things as well.

Is this Book for You?

As mentioned above, if you already have some knowledge about interaction design and/or HCI (e.g. if you enrolled in our Interaction Design course last semester or some time beforehand, then you're more than covered) and want to know what all the fuss with gamification, serious games and all that is about, this book is for you. If you're a game design novice and want to know what you can do to better your craft, it almost certainly holds value to you, but I would probalby look elsewhere beforehand. If you're a project manager who has heard about gamification and wants to slap a point system and leaderboards on a tax management software to make it more successful, I will put you inside a Skinner box and repeatedly hit you over the head with this book until you show some improvement.

If you're a student of computer science at the University of Hamburg, I would expect Playful Design to be available at our department library soon-ish. If you're in the master's programme, consider enrolling in the Interactive Systems course next semester, provided you're interested in this topic and want to help further the discussion about games at our department. It looks like a detailed analysis of Playful Design could be a viable task for the seminar. (Of course a plethora of non-game-related topics will be discussed in the seminar as well, so if this book in particular doesn't faze you, don't be deterred.)

If you're a UX professional of any kind, I heartily recommend just buying the book. I will do so myself as soon as I can part with the cash. It's a fantastic addition to your physical bookshelf as well as your mental toolbox.

Im Sommersemester 2011 habe ich als studentische Hilfskraft die Veranstaltung Interaktionsdesign bei Prof. Oberquelle mitbetreut. In diesem Rahmen habe ich im (geschlossenen) CommSy-Raum der Veranstaltung einige Fragen schriftlich beantwortet, die den Veranstaltungsteilnehmern bei der Prüfungsvorbereitung aufkamen. Es wäre schade wenn diese Texte einfach verlorengehen, deshalb habe ich sie hier geringfügig aufpoliert und zusammenhängend wiedergegeben. Ob die Inhalte im nächsten Durchgang der Veranstaltung überhaupt noch relevant sind, das ist natürlich noch nicht in Stein gemeißelt. Trotzdem viel Vergnügen damit!

Tangible Media

Ich habe eben noch mal die MIA-Folien durchgeschaut und leider tatsächlich keinen Definitionsansatz dort gefunden. Auf S. 17 und 18 von MIA11-4.pdf gibt es Beispiele. Die Grundidee wird vermutlich durch Beispiele schon einigermaßen gut klar.

Aber was ist mit dem Begriff gemeint? Über die Bedeutung von „tangible“ – greifbar, anfassbar – kommt man schon ganz gut heran. Ein Tangible User Interface erlaubt es uns, den Computer zu steuern, indem wir physische Objekte manipulieren, mit denen wir eine sehr hohe Direktheit der Interaktion erreichen. Einfach gesagt kann Tangible Media alles sein, bei dem physische Objekte mit digitalen Repräsentationen „verbunden“ werden, so dass wir den Zustand der digitalen Welt verändern, wenn wir den Zustand der physischen Objekte verändern. Das ist allerdings immer noch relativ schwammig, deshalb erzähle ich einfach mal ein bisschen genauer...

Vorweg: Tangible Media ist kein besonders technischer Begriff. Aus technischer Sicht wird schließlich jedes Eingabegerät irgendwie physisch manipuliert und bewirkt etwas im Computersystem durch seine Sensordaten. Tangible Media gehört konzeptuell eher in die Schublade der Benutzbarkeitsforschung, Experience Design usw. und berührt neben der Technik auch Dinge wie die mentalen Modelle der Benutzer.

So etwas wie Maus und Tastatur sind Allzweck-Steuergeräte, mit denen wir viele verschiedenen Aufgaben erfüllen können. Diese Geräte werden auf ihre Grundfunktionen (Tastatur: einzelne, diskrete Tastendrücke, Maus: Bewegung in der 2D-Ebene) reduziert und von allen anderen Eigenschaften wird abstrahiert. Auf diesen Grundfunktionen bauen wiederum unsere hochkomplexen Desktop-Softwaresysteme auf. Aufgrund dieser „Kluft“ zwischen den physischen Objekten und der Nutzung würde ich Maus und Tastatur nicht als Tangible Media bezeichnen. Dieser Eindruck wird verstärkt dadurch, dass Computerbenutzer recht schnell lernen, die Maus und die Tastatur zu „vergessen“ und nur noch in virtuellen Konzepten zu denken.

Bei Tangible Media habe ich dagegen physische Objekte, die erstens eng mit der digitalen Repräsentation gekoppelt sind, so dass meine Interaktion mir „direkt“ erscheint. Dadurch, dass ich etwas bspw. anfasse und bewege, verändere ich die digitale Welt so, als hätte ich sie an der gleichen Stelle und auf die gleiche Weise angefasst und/oder bewegt. Zweitens stehen diese phyischen Objekte zusammen mit ihren digitalen Repräsentationen (meist als Einheit) in meinem mentalen Modell im Zentrum. Sie sind nicht nur Werkzeug, sondern auch Material.

Eine spannende Frage in diesem Themenfeld wäre, inwieweit Touchscreens „tangible“ sind. Die Dinger sind schön direkt und physisch, allerdings verändert man sie normalerweise nicht und mit der Material-Sicht haben sie auch nicht viel zu tun. Das wäre vielleicht eine spannende Frage, die man mal in einer Prüfung diskutieren könnte. (Disclaimer: Mit den Prüfungen von Herrn Oberquelle habe ich nichts zu tun und habe weder Einblick in noch Einfluss auf die dort gestellten Fragen.)

Ich hoffe das hilft schon mal. Bei Wikipedia gibt es ansonsten noch ein bisschen was zum Thema: Wikipedia – Tangible User Interface

L-Shape

Für Virtual-Reality-Systeme gibt es die sogenannten „Caves“. Das sind spezielle Räume, in denen die Wände, Fußboden und ggf. auch die Decke als Bildschirme genutzt werden können, so dass für eine Person ein ziemlich hoher Grad der Immersion in eine virtuelle Welt erreicht werden kann. (Meist ist darüber nämlich auch noch stereoskopische 3D-Grafik möglich.) Ein Nachteil von Caves ist, dass sie ziemlich aufwändig und teuer sind, weil die ganzen Projektoren irgendwie untergebracht werden und zusammenarbeiten müssen. Ein weiterer Nachteil ist, dass man sich in der virtuellen Welt zwar ohne Probleme rundherum drehen, aber nicht herumlaufen kann.

Bei einer L-Shape handelt es sich grob gesehen um die Light-Version einer Cave. Man lässt die Decke und drei der vier Wände weg, so dass man sich nur noch um eine Wand und den Boden kümmern muss. (Man stelle sich das räumlich vor, dann erkennt man die Form des Buchstaben „L“.) Das senkt die finanziellen Kosten enorm, verringert aber natürlich auch die Immersion. Das muss man bei der Planung solcher Systeme abwägen. In L-Shapes kann man sich dann anders als in Caves nicht mehr herumdrehen, ohne die Grenzen der Grafikdarstellung zu verlassen. Ansonsten sind L-Shapes und Caves sich funktional ziemlich ähnlich.

Allgemeines zu Modellen

Ich höre von Zeit zu Zeit ein leises Raunen, warum man sich im MCI-Bereich eigentlich mit diesen ganzen Modellen befassen soll, die alle irgendwie ähnlich und trotzdem unterschiedlich sind, und dennoch die Realität nicht vollständig abbilden. Warum machen wir uns die Mühe?

Aus wissenschaftstheoretischer Sicht sind sie eine Möglichkeit, die Realität zu beschreiben. Ein großer Teil auch unserer Arbeit als Wissenschaftler (das werdet ihr wahrscheinlich schon bei eurer Bachelorarbeit feststellen) besteht nicht nur darin, Dinge herauszufinden und zu erklären, sondern auch, Dinge kommunizierbar zu machen, über die vorher nicht gesprochen werden konnte. Wir beobachten komplexe Zusammenhänge in der realen Welt und wollen uns in der wissenschaftlichen Gemeinde darüber austauschen und damit auseinandersetzen. Damit das geht, müssen wir zunächst abstrahieren und strukturieren, was wir zu sehen glauben. Auch das PACT-Modell ist ein Versuch, bis dato unkommunizierte reale Zusammenhänge in eine Struktur zu gießen, in der sie für Außenstehende (also zunächst mal auch uns) erschließbar sind.

Nachdem man sich eine Weile mit solchen Modellen befasst hat, drängt sich manchmal die Frage auf, was man dabei eigentlich gelernt haben soll. Tatsächlich ist das PACT-Modell auch hierfür ein gutes Beispiel: Als mittelmäßig bis gut qualifizierte Informatikstudierende erzählt es uns im Grunde nichts, was wir nicht schon vorher im Prinzip irgendwie gewusst haben. Der Verdienst des Ganzen ist aber, dass wir eine gemeinsame Kommunikationsbasis haben, nachdem wir uns mit dem Modell auseinandergesetzt haben. Wir können untereinander die gleichen Begriffe verwenden, können halbwegs sicher sein dass wir ungefähr das Gleiche meinen, und – hier ist der Knackpunkt – können darauf aufbauen. Beim Lernen für die ID-Prüfung fällt uns evtl. noch nicht auf, wie sehr wir davon profitieren, aber wenn wir später mal in einer Abschlussarbeit das PACT-Modell referenzieren können statt die Zusammenhänge immer wieder von Grund auf neu zu erklären, dann schon.

Leavitt-Raute und PACT-Modell

Nun zu Leavitt-Raute und PACT-Modell (vgl. S. 7 von ID_11-1.pdf). Was hat es damit auf sich? Die beiden Modelle sind sich so ähnlich, dass ich wohl zu beiden gleichzeitig etwas sagen kann.

Bei der Entwicklung von benutzergerechten Systemen kann vieles schiefgehen. Als Entwickler müssen wir viele Dinge auf einmal im Blick behalten. In den beiden genannten Modellen haben wir eine Reihe von Begriffen (Leavitt-Raute: Mensch, Aufgabe, Organisation, System; beim PACT-Modell kommt noch die Technologie hinzu) und Doppelpfeile, die jeden (PACT: beinahe jeden) Begriff mit jedem anderen verbinden. Was soll uns das sagen? Vielleicht betrachten wir erst mal die Begriffe nacheinander isoliert:

Mensch (people): Unsere Systeme werden von Menschen verwendet. Menschen haben unterschiedliche Fähigkeiten, körperliche und geistige Voraussetzungen, Erfahrungen, Neigungen und Geschmäcker. Beim Entwickeln von gebrauchstauglichen Systemen soll uns klar sein, wer unsere Zielgruppe ist.

Aufgabe (activity): In aller Regel will jemand, der eine Software benutzt, dadurch etwas erreichen. Die Zeiten, in denen Computer nur im Kontext von Arbeitsplatztätigkeiten betrachtet werden müssen, sind zwar vorbei, aber dennoch werden sie nicht ohne irgendein Ziel eingesetzt (und sei es Spaß oder Bewältigung von Langeweile). Die Gestaltung eines Systems hängt in nicht geringem Maße davon ab, welche Aufgaben man damit erfüllen können soll.

Organisation (context): In welchem organisationellen Kontext wird das System eingesetzt? Ist es eine Firma (eine konkrete?), ein Verein, eine lockere Community? Das System muss sich in bestehende Regelsysteme eingliedern lassen und sollte die Zusammenarbeit unterstützen.

System (system): Das System selbst, die Komponente, über die wir die größte Kontrolle haben.

Technologie (nur im PACT-Modell): Der technologische Rahmen, Ein- und Ausgabehardware, Ressourcen.

Das alles sind Dinge, die wir im Kopf haben müssen, wenn die Entwicklung gebrauchstauglicher Systeme gelingen soll. Die zentrale Aussage der Leavitt-Raute und des PACT-Modells ist nun dies: All diese Dinge stehen sehr eng miteinander in Beziehung. Man kann quasi nichts davon verändern, ohne Einfluss auf den Rest zu nehmen. Verändern wir den Nutzerkreis (die Menschen), dann verändern sich deren Aufgaben und Ziele. Verändern wir den Organisationskontext, treffen wir auf unterschiedliche Technologien. Ich glaube, die Urheber des PACT-Modells möchten uns primär dazu aufrufen, keine kurzsichtigen Veränderungen am System oder an anderen Bereichen zu machen, ohne über die Konsequenzen im großen Maßstab nachzudenken.

Interaction Space, Visualization Space, Display Space

Die Folien dazu sind MIA11-4.pdf, Seiten 3 bis 19, also beinahe die komplette Datei. Zu Anfang wird das Modell allgemein dargestellt, danach kommen Folien, die die einzelnen Teile konkretisieren.

Beim Spaces-Modell handelt es sich, oh Wunder, um ein Modell. Es greift also auch hier alles, was ich oben über Modelle geschrieben habe. Es stellt einen Versuch dar, etwas Fließendes und Kontinuierliches zu diskretisieren und zu beschreiben.

In dem Modell kommen vier Spaces vor: Interaction Space, Display Space, Visualization Space und Internal Model.

Der Interaction Space bezeichnet den Raum, in dem der Benutzer physisch auf das System einwirkt. Die mentalen Vorgänge des Benutzers zählen nicht dazu, ebensowenig wie die internen Vorgänge im System. Zum Interaction Space gehört normalerweise der Körper des Benutzers und sämtliche Steuerungs- und Sensorik-Hardware. Je nachdem, wie die aufgebaut ist, ist es mehr oder weniger leicht, dem Interaction Space eine Dimensionalität zuzuordnen. Wenn ich nur über eine Maus verfüge, dann ist er zweidimensional, ein VR-Handschuh wäre dreidimensional.

Der Display Space ist der Raum, in dem die Ausgabe des Systems stattfindet. Das kann ein zweidimensionaler Monitor sein, aber auch eine dreidimensionale Cave, ein dreidimensionales Richt-Schall-System oder andere abenteuerliche Dinge. Wichtig ist, dass zum Display Space nicht das gehört, was dargestellt wird (das kommt gleich), sondern nur die Hardware, auf der es dargestellt wird.

Der Visualization Space ist nun der Ort, der auf/durch unsere(n) Displays grafisch dargestellt wird. Der kann ebenfalls typischerweise zweidimensional (Desktop) oder dreidimensional (3D-Spiel, VR-Umgebung) sein, andere Dimensionalitäten sind ziemlich selten. Auffallend ist hier, dass man auf einem 2D-Display-Space einen 3D-Visualization-Space (mit Abstrichen in der Immersion) darstellen kann, sowie auch einen 2D-Visualization-Space auf einem 3D-Display-Space (was allerdings allein wegen der Kosten wahrscheinlich kaum jemand macht).

Eng mit dem Visualization Space verbunden ist das Internal Model, was beschreibt, wie das System intern den Visualization Space beschreibt und speichert. Zum Beispiel könnte das System abgesehen von den Raumdimensionen noch weitere Werte als Dimensionalität abspeichern (z.B. Luftdruck in jedem Punkt), die in der Visualisierung so zunächst nicht sichtbar sind. Der Unterschied zum Visualization Space ist, dass das Internal Model alles enthält, was „unter der Haube“ des Systems in der berechneten Welt stattfindet.

Artikulatorische und semantische Distanz

Diese Schlagworte finden sich in ID_11-2.pdf auf Seite 9 (und wie mir scheint auch nur an dieser einen Stelle) im Bezug zu dem Diagramm auf der gleichen Seite.

Die eine Achse des Diagramms ist mit „Direktheit“ beschriftet. Die semantischen und artikulatorischen Distanzen sind Aspekte, die die Direktheit negativ beeinflussen. Greifen wir uns ein paar Beispiele aus dem Diagramm.

Dort stehen Assemblersprachen unter sehr niedriger Direktheit eingeordnet. (Achtung: Gemeint ist hier die Direktheit zu den mentalen Prozessen des Benutzers, nicht zur Arbeitsweise der Maschine.) Assemblersprachen besitzen eine hohe artikulatorische Distanz, da sie vom Denken und Reden des Menschen relativ weit weg sind. Die eigenen Gedanken müssen vergleichsweise mühsam in das krude Vokabular der Assemblersprache übersetzt werden, bevor sie ihre Wirkung entfalten können. Dagegen hat ein Text in einer Fachsprache, die in das Diagramm unter sehr hoher Direktheit eingeordnet ist, idealerweise eine Eins-zu-eins-Entsprechung von den dahinterstehenden Gedanken und den formulierten Worten. Dazwischen steht wenig Übersetzungsaufwand oder „Umdenken“.

Die semantische Distanz meint dagegen eine Kluft zwischen den Möglichkeiten des Agierens. So hat etwa eine virtuelle 3D-Welt mit hohem Immersionsgrad vermutlich auch eine geringe semantische Distanz, weil zwischen meinem Ziel „mich vorwärts bewegen“ und der im System möglichen Aktion „die Kamera bzw. den Avatar vorwärts bewegen“ eine starke Kongruenz besteht. In einem Textadventure muss ich dagegen mein „vorwärts bewegen“ in ein textuelles Kommando übersetzen, dies eintippen und die Rückmeldung verarbeiten. Der Anwendungskontext „Navigation durch eine Welt“ leidet unter der semantischen Distanz zur Funktionalität „Manipulation von Textkommandos“. Ich hoffe dafür steigen mir jetzt keine Textadventure-Fans aufs Dach – ich möchte nicht gesagt haben, dass es keinen Spaß machen kann.

Zu alldem möchte ich anmerken, dass ich das auch nur aus den wenigen Stichworten extrapoliert habe, die auf der Folie stehen. Es kann durchaus sein, dass ich dabei Fehler gemacht habe. Verlasst euch bitte nicht darauf, dass ich die Weisheit mit Löffeln gegessen habe – vor allem falls eure Interpretation von meiner abweicht bin ich sehr interessiert daran.

Für Alles gibt es ein erstes Mal. Ich kann mich noch daran erinnern, wie ich das erste Mal einen Programmcode kompiliert habe. Das waren damals Turbo-Pascal-Schnipsel und ich erarbeitete mir im Selbststudium genug davon, um eigene kleine Spiele unter DOS erstellen zu können.

Paradoxerweise programmiere ich trotz Informatikstudium heute eher weniger als damals. Meine Webseite ist im Prinzip mein einziges Bastelprojekt, in dem ich mich austobe wenn ich etwas Erholung vom Universitätsstoff brauche. Ganz ungestört für mich selbst zu entwickeln hat auf jeden Fall seinen Reiz, umso mehr wenn die Besucher meiner Webseite dadurch auch noch tolle neue Features gewinnen.

Erst vor ein paar Stunden hat es für mich noch ein anderes erstes Mal gegeben: Ich habe gerade das erste Mal Quellcode von mir frei lizensiert und veröffentlicht.

Wenn man meine bisherige Programmiererfahrung und meine gut dokumentierte Einstellung zu freien Inhalten im Hinterkopf hat, muss man mich in dieser Sache wohl als so etwas wie einen Spätentwickler bezeichnen. Tatsächlich hat es sich vorher einfach nie ergeben. Außer ein paar Skripten für den Eigenbedarf ist mein einziges Projekt wie schon gesagt meine Webseite, und der Code ist leider insgesamt in keiner Verfassung, dass ich ihn herausgeben und dazu stehen würde.

Die letzten Tage habe ich jedoch basierend auf jQuery eine nette kleine Sache gebastelt, die sich (nachdem ich mich etwas eingelesen hatte) auch ganz gut als jQuery-Plugin abstrahieren ließ. Es trägt jetzt den Namen ReaderBar:

ReaderBar is a jQuery plugin that aims to augment long HTML documents with a few navigational tools. It includes a button to go to the start of the document, arrows for jumping between headers/sections and bookmarking functionality. Along the left side of the document, it shows a “places bar” with quick access to headers and user bookmarks.

Man kann es in der HTML-Ansicht meiner Texte in Aktion sehen, dazu einfach auf einen der Thumbnails klicken (oder einen der HTML-Links). Über Feedback zur Benutzbarkeit würde ich mich, wie immer, sehr freuen.

Das Ganze ist auf GitHub verfügbar. Wer mag, kann sich den Code direkt von dort kopieren oder einfach nur die Entwicklung mitverfolgen. Der gesamte Quellcode steht unter der MIT-Lizenz. JavaScript ist natürlich eine extrem vielseitige und dynamische Sprache. Ich habe nicht viel Erfahrung mit den Konventionen in der jQuery-Community, deshalb ist mein nächstes Vorhaben, mir von dort Feedback zu holen und den Code strukturell so zu gestalten, dass andere Leute in dem Bereich ihn vernünftig lesen können.

Mittelfristig soll es natürlich nicht bei diesem Projekt bleiben. Ich werde mir Gedanken machen müssen, wie ich meine Inhalte auf GitHub sinnvoll mit meiner Webseite verbinde. Vielleicht ist hier mal eine neue Kategorie „Software“ möglich. Aber wie soll die wohl aussehen?

Wisst ihr noch, was eure erste freie Software war? Oder habt ihr eher an bestehenden Projekten mitgearbeitet? Wen von euch findet man denn noch so alles bei GitHub? Ich bin dort jfietkau, vielleicht sieht man sich ja mal.

Wie einige von euch vielleicht schon wissen, führe ich dieses Semester ein Tutorium zum Thema LaTeX für Studierende des Fachbereichs Informatik durch, das sich zur Hälfte als Video-Tutorial auf YouTube (oder als heruntergeladene Videodatei) abspielt. Ich möchte an dieser Stelle mal erzählen, wie es eigentlich dazu kam.

Der Bedarf für ein LaTeX-Tutorium wurde wohl vom Studienbüro festgestellt und Jan von Soosten kam auf mich zu, ob ich das nicht übernehmen könnte. Ich hatte vorher noch nie eine komplette Lehrveranstaltung eigenständig und eigenverantwortlich durchgeführt, die mir winkende Gestaltungsfreiheit lockte mich letztlich mehr als meine Semester-Arbeitsbelastung mich abschrecken konnte.

Konzept und Ursprung

Seit einiger Zeit schon wollte ich mal ein Video-Tutorium nach Vorbild der Khan Academy durchführen, doch es fehlte immer die Zeit und der Anlass dafür. Diese Gelegenheit verschaffte mir beides.

Die Grundidee der Khan Academy ist die folgende: Die gemeinsame Zeit, die Lehrenden und Lernenden zur Verfügung steht, ist endlich und wertvoll. Im klassischen Modell der universitären Lehre, bestehend aus Vorlesungen und Übungsaufgaben, findet in der Präsenzzeit eine Wissensvermittlung statt, das Einüben und Anwenden des Wissens erledigen die Studierenden allein zuhause oder in kleinen Gruppen. Die Pädagogik predigt schon lange, dass genau jenes Anwenden des Wissens für den Lernvorgang mindestens ebenso wichtig ist wie das Zuhören und Aufnehmen. Warum also nicht mal das Experiment wagen, die Lernenden die Wissensvermittlung in Form von Videos allein zuhause erledigen zu lassen, und in der Präsenzzeit das Wissen anzuwenden und gemeinsam Aufgaben zu bearbeiten?

Wir leben in einer Zeit, in der Audio- und Videodaten ohne unüberwindbare technische Schwierigkeiten weltweit zugänglich gemacht werden können. Bestehende Vorlesungen lassen sich nach Überwindung von ein paar wenigen technischen Hürden prima eintüten und audiovisuell konservieren, das passiert an der Uni Hamburg bereits und findet sehr positiven Anklang bei den Studierenden. Asynchrone Wissensvermittlung kann in dieser Form gut funktionieren und Dinge wie z.B. Lehrbücher sinnvoll ergänzen. Das bestärkt mich in dem Vorhaben, die alte Welt einfach mal um 180° zu drehen und meine Wissensvermittlung in Form von Videos stattfinden zu lassen. Klappt das notwendigerweise besser als das bewährte Modell? Keine Ahnung, aber ist ist auf jeden Fall einen Versuch wert. Ganz nebenbei fällt dabei übigens ein weltweit frei zugänglicher Video-Kurs für LaTeX-Anfänger auch außerhalb unseres Fachbereichs raus.

Let's Learn!

Die konkrete Gestaltung meiner Videos ist allerdings deutlich anders als bei typischen Lecture2Go-Aufzeichnungen. Das, was fast die gesamte Zeit zu sehen ist, ist mein LaTeX-Editor und der dazugehörige PDF-Viewer. Ich habe keine Kamera auf mich gerichtet, aber ich spreche ins Mikrofon und kommentiere, während ich arbeite. Es gibt ein Intro/Outro und einen einprägsamen Titelsong (Creative Commons sei dank: (A) in Mono – Cube-shaped). Diese Gestaltungsmuster und -elemente entstammen der „Let's Play“-Metacommunity auf YouTube. Für alle, denen das nichts sagt: Man nimmt ein PC- oder Konsolenspiel, spielt und kommentiert es und schneidet das Ganze mit. Daraus entstehen dann jede Menge Videos, die zu Serien und Staffeln zusammengefasst werden. Viele Let's-Player geben sich unglaublich viel Mühe damit, ihre Zuschauer zu fesseln und zu unterhalten.

Wahrscheinlich ist das etwas, was für einige Leute sehr unterhaltsam sein kann, während einige andere sich an den Kopf fassen und sich fragen, wie man das spaßig finden kann. Ich persönlich verfolge eine Handvoll Let's-Player auf YouTube und konnte mir für die Gestaltung meiner eigenen Videos dort einige Tricks abschauen. Die Gemeinsamkeiten beschränken sich jedoch nicht nur auf die Gestaltungsmittel, sondern erstrecken sich auch auf die Herangehensweise: Meine Videos haben bewusst nicht den Charakter eines Films oder eines minutiös durchgeplanten Tutorials, sondern ich habe vorher bestenfalls eine grobe Vorstellung davon was ich machen will, lege dann – wie ein Let's-Player – einfach los und schneide alles mit, einschließlich meiner Fehler und Probleme und Situationen, in denen ich keine Ahnung habe, was gerade schiefgeht. So wirkt das Ganze sehr authentisch und spart mir außerdem zusätzlichen Arbeitsaufwand in der Nachbearbeitung.

Eine weitere Inspirationsquelle sind übrigens die Softwareentwicklungs-Vorlesungen von Axel Schmolitzky. Wer die mal besucht hat, weiß wie Axel Live-Code-Demonstrationen einsetzt, um Dinge vorzuführen. Zwischen diesen Episoden und meinen Videos gibt es starke Parallelen.

Und nun?

Es gab auf meine Ankündigungsmail eine ansehnliche Anzahl Rückmeldungen, es wurde ein Termin ausgedudelt und wir treffen uns diese Woche das erste Mal. Übrigens am Freitag von 12:15 bis 13:45 Uhr in C-101, falls jemand noch spontan dazukommen möchte. Wenn dann bitte vorher die ersten zwei Lektionen schauen und den eigenen Laptop o.Ä. mitbringen.

Im Moment ist es noch zu früh, um die Tragfähigkeit des Konzepts zu evaluieren. Technisch kann ich schon mal sagen, dass das bisschen Videobearbeitung auf meinem Linux-Desktop nach etwas Eingewöhnung prima funktioniert, siehe dazu auch meinen Blogeintrag „recordmydesktop and OGV“. Ist jemand an Details zur Nachbearbeitung mit Kino interessiert?

Auch YouTube funktioniert als Kanal anscheinend hinreichend gut, um quasi alle Interessierten zu erreichen. Ich habe mich außerdem mit dem „Community Video“-Bereich von archive.org auseinandergesetzt und werde die Videos über kurz oder lang auch in verschiedenen Dateiformaten dort anbieten, um auch die Leute einzuschließen, die mit YouTube aus technischen, ethischen oder sonstigen Gründen nicht warm werden. Beim Lecture2Go-Team habe ich dieses Mal noch nicht nachgefragt, ob sie die Videos evtl. auch hosten wollen. Mal gucken, vielleicht geht da auch noch was.

Just a small heads up to anyone doing any kind of screencast or desktop recording on a typical desktop Linux:

Usually, people will recommend recordmydesktop, which is a very cool program that's available e.g. in the Ubuntu repositories. It works really well and all, but I keep running into walls with the OGG/Theora videos that it produces.

I'm no expert on video encoding, but apparently recordmydesktop does some very fancy optimizations involving variable FPS and stuff like that, so the video files are quite small byte-wise. Unfortunately, this has caused problems for me down the line: I can play the files just fine in Totem (thus, gstreamer) or VLC. But as soon as I try to reencode them, all hell breaks loose.

I tried importing the files into Kino, but they would cut off too early and the framerate would go bananas. I tried reencoding with ffmpeg, only to get playback speed issues. Mencoder didn't help either. Even VLC, which could play the files without problems, would not produce usable results, but would seemingly offset frame rates, so that when there was no movement on screen for any length of the video, in the resulting video it would pause a couple of frames earlier, which was very annoying.

Despite long searches, I wasn't able to find anyone else having the same problem online. So maybe I'm just incompetent and I'm making some obvious mistake. Still, I wasted hours today trying to figure this out, and I still failed.

So if by any chance you run into the same problem some time, just save yourself a lot of grief and use ffmpeg with x11grab instead of recordmydesktop. It has the added advantage that you can directly encode to any format that ffmpeg can do (which is pretty much all of them).

(It almost pains me to admit this, but in the end I used ffmpeg/x11grab to capture my OGV playing in Totem and then re-muxed the audio because I didn't want to re-record it all. In the future I'll probably use x11grab directly.)

Ab sofort sind meine Texte neben dem PDF-Format auch noch im ePub-Format öffentlich verfügbar. Ich hoffe, dass ich sie dadurch einem noch größeren Publikum zugänglich machen kann. Falls du einen E-Reader (z.B. ein Kindle), ein Tablet (z.B. ein iPad oder ein Galaxy Tab) oder ein Smartphone zum Lesen verwendest, führt dieses Format evtl. zu einem für dich angenehmeren Lese-Erlebnis.

Also warum nicht die Chance nutzen und einen Blick in paar „Klassiker“ werfen? Die folgenden Arbeiten stehen für dich im ePub-Format bereit:

• Interaktionsformen in der Blogosphäre
• Ansätze zur Vereinigung von Komplexität und Benutzbarkeit in Anwendungssoftware
• Das Teachlet-Konzept: Möglichkeiten und Grenzen einer Lehrform für Software-Entwurfsdiskussionen
• Modellierung zustandsorientierter Systeme in Java

Sag mir Bescheid, falls bei dir etwas nicht funktioniert oder dir mit den ePubs Probleme auffallen. Ich habe das vorher noch nie gemacht und es kann sein, dass sich Fehler eingeschlichen haben. Vielen Dank an dieser Stelle den Leuten im E-Reader-Forum, die für mich eifrig auf verschiedenen Geräten getestet und mir Feedback gegeben haben.

Was ist eigentlich ein ePub?

Das ePub-Format ist ein Standard für elektronische Bücher. Für E-Reader und andere Lesegeräte mit kleinen Displays sind PDF-Dateien nur eingeschränkt geeignet, da sie das Layout (meist A4) fest vorgeben, so dass entweder die Schrift winzig ist oder eine Zeile nicht auf den Bildschirm passt, so dass man nur am Hin-und-Her-Scrollen ist. Das ePub-Format erlaubt dagegen fließenden Text, der sich an die jeweilige Anzeigesituation anpassen kann. Mehr Infos gibt's wie immer bei Wikipedia.

Abgesehen von der Flexibilität gibt es noch etwas, was ich am ePub-Format mag: Es ist viel, viel leichter als bei PDFs, die Dateien zu bearbeiten. (Es gibt auch DRM für ePub, aber das lasse ich mal außen vor. Betrifft ja meine Dateien nicht.) Das bedeutet, dass es jetzt sehr viel einfacher für dich ist, die dir per Creative Commons zugestandenen Rechte zur Anpassung und Weiterverarbeitung meiner Texte auch tatsächlich wahrzunehmen.

Technisch sind ePub-Dateien kaum mehr als geziptes (X)HTML mit etwas Zucker, also falls dir vorhandene ePub-Editoren wie Sigil dafür nicht reichen, entpack einfach die ePub-Datei, schmeiß vim / emacs / einen Texteditor deiner Wahl an und mach etwas Kreatives aus meinen Texten (unter Beachtung der jeweiligen CC-Lizenz, versteht sich)!

In unregelmäßigen Abständen und gerade zum dritten Mal organisieren die Leute von Wolfire Games ein Projekt, das PC-Spiele aus dem Independent-Bereich zusammenbündelt, die dann zum selbstgewählten Preis gekauft werden können. (Ein Anteil des Betrags, dessen Höhe man auch selbst festlegen kann, geht an wohltätige Zwecke.) Alle enthaltenen Spiele sind frei von DRM-Restriktionen und laufen auf Windows, Linux und MacOS X. Das Ganze nennt sich dann „Humble Indie Bundle 3“ und verdient einen genaueren Blick. Außerdem schon mal vorweg: Heute gibt es etwas zu gewinnen!

Im aktuellen Bundle gibt es einige echte Juwelen. Allein für Crayon Physics Deluxe lohnt es sich eigentlich schon: In dem Spiel geht es darum, Rube-Goldberg-artige Rätsel zu lösen, indem man Objekte mit Wachsmalern in die Welt malt. Das Spiel ist von der Ästhetik her unglaublich gut gelungen und die Lernkurve ist einerseits kindgerecht, lässt aber andererseits auch viel Spielraum zur Optimierung. VVVVVV ist eher etwas für Hardcore-Gamer der alten Schule, ein LoFi-Arcade-Action-Adventure mit dem gewissen Etwas: Statt zu springen, kann die Spielfigur die Richtung der Schwerkraft umkehren und so zwischen Fußboden und Decke hin- und herfallen. Das erschwert sich durch Stacheln und andere typische Fallen. Ein weiteres Muss ist And Yet It Moves, ein weiteres Spiel in dem die Schwerkraft beeinflusst werden kann, was jedoch auf eine völlig andere Weise umgesetzt ist, insbesondere ästhetisch. Die anderen beiden Spiele im aktuellen Bundle, Cogs und Hammerfight, habe ich leider aus zeitlichen Gründen noch nicht spielen können.

Als wäre das noch nicht genug, haben die Macher des Bundles im Laufe der letzten Tage noch ohne Ende Bonus-Inhalt nachgelegt: Jeder Käufer des Bundles erhält außerdem Steel Storm gratis dazu. Wer beim Kauf das jeweils aktuelle Durchschnittsgebot überbietet, erhält außerdem die fünf Spiele aus dem zweiten Humble Indie Bundle, darunter Braid und Machinarium, beides Spiele, die man sich auf keinen Fall entgehen lassen sollte. Obendrauf kommt ein zeitlich bis zum 14. August befristeter Zugang zur Vollversion von Minecraft.

Die wohltätigen Organisationen, die unterstützt werden, sind die Electronic Frontier Foundation und Child's Play, bei denen das Geld sicher gut angelegt ist.

Jetzt habe ich schon viel zu viel geredet. Wer sich lieber einen visuellen Eindruck von den Spielen machen möchte, möge sich am besten das Werbevideo zum Humble Indie Bundle 3 (und/oder das zum zweiten Bundle) ansehen. Weitere Video-Empfehlungen:

• Crayon Physics Deluxe
• VVVVVV
• And Yet It Moves
• Braid
• Machinarium

Das Humble Indie Bundle 3 läuft nur noch fünf Tage. Überzeugt? Dann schlag schnell zu, oder lies vielleicht doch erst mal weiter...

Gewinnspiel

Weil ich die Idee des Bundles so großartig finde, möchte ich mit dir, lieber Leser, liebe Leserin, ein kleines Gewinnspiel veranstalten. Vielleicht hast du gerade hierfür nicht genug Finanzpolster und möchtest das Bundle nicht dreist für einen Cent kaufen, oder vielleicht hast du keine Möglichkeit für Online-Bezahlung, oder du bist von Haus aus nicht so Gamer-mäßig drauf und bist jetzt zwar neugierig, aber siehst nicht ein, dir den Aufwand zu machen, oder du hast andere Gründe dafür, das Bundle noch nicht gekauft zu haben.

Wenn du zu diesem Personenkreis gehörst, dann möchte ich dir ein Humble Indie Bundle 3 schenken! Es ist einigermaßen großzügig bezahlt und enthält alle oben genannten Extras.

Hier sind die Teilnahmebedingungen: Du bist gewinnberechtigt, wenn du mir in einem Kommentar zu diesem Blogeintrag möglichst überzeugend darlegst, warum ich das Bundle gerade dir schenken sollte. Überzeug mich mit Argumenten, überzeug mich mit Humor, oder überzeug mich irgendwie anders, es ist dir überlassen. Hinterlasse bitte außerdem eine Mailadresse, falls du mich nicht persönlich kennst oder einen anderen Kommunikationskanal zu mir hast. Wenn ich nicht weiß, wie ich dich erreichen soll, dann gewinnst du auch nicht. Am kommenden Samstag den 6. August um 20:00 Uhr ist Anmeldeschluss, danach wähle ich den/die Gewinner/in aus. Das Ergebnis wird noch am Samstag hier verkündet.

Ich hoffe auf deinen Einfallsreichtum!

Beachtliche Teile des deutschsprachigen Internetzes reden derzeit über den aktuellen Nikon-Fotowettbewerb. Bei Twitter ist deswegen einiges los, und auch einige meiner blogosphärischen Nachbarn machen kräftig Eigen-(und damit auch Nikon-)Werbung.

Während ich dies schreibe, sind bereits über 35.000 Fotos eingegangen. Dass der Wettbewerb derartig explodiert, damit hatte man wohl nicht mal bei Nikon selbst gerechnet, den zahlreichen Verbindungsabbrüchen und Fehlermeldungen nach zu urteilen...

Aber sei es wie es sei: Heute möchte ich meinem kleinen bisschen Leserschaft nicht vorenthalten, was einige meiner Freunde und Bekannten so zu dem Wettbewerb beigetragen haben.

Wer in der Liste ergänzt werden möchte, der möge sich bitte melden.

Frei (Pablo Heimplatz)

(1 Beitrag auf Wunsch des Urhebers entfernt.)

Es gibt mal wieder einen Grund, sich so richtig auf das KBS zu freuen – denn am kommenden Dienstag den 10. Mai 2011 gibt es dort prominenten Besuch. Zwei Mitglieder von farbrausch erzählen von ihrem Umfeld und ihrem Handwerk.

Wer oder was ist farbrausch?

(fr-041: debris.)

Das ist farbrausch.

(fr-025: the.popular.demo)

Das auch.

(fr-081: .frOzen)

Und das auch.

Farbrausch ist eine Demo-Gruppe, eine der bekanntesten. Das heißt, dass das weltweit so ziemlich die maßgebenden Experten für effiziente Echtzeit-3D-Programmierung sind, oftmals mit prozedural generierten Assets. Die Demos kann man sich herunterladen und auf dem eigenen PC ausführen – aus einer wenige MB oder sogar KB großen Binary entsteht ein wahres visuelles Feuerwerk auf dem Bildschirm, begleitet von atmosphärischer Musik.

Ich freu mich total auf Dienstag und bin sehr gespannt! Wer Interesse an Computergrafik, Medienkunst und verwandten Gebieten hat, den sehe ich hoffentlich am Dienstag im KBS!

1. debris, rove oder eine andere gute farbrausch-Demo gucken!
2. Dienstag zum KBS kommen (17 Uhr, C-221 am Informatikum)!
3. Weitersagen!

Having recently acquired a brand-new smartphone, I'm still fiddling around with the system, installing apps and configuring things. So far I'm really happy with it, a definite step up from my previous cell phone (and that one wasn't even that old).

Imagine my surprise when I found out that the new one has an office app installed on it by the vendor. Inspired by a semi-recent article on OSNews, I'd been wondering what a good mobile office UI might look like, so I was eager to have a look at this one that came free with my phone. It's called ThinkFree Office and supposedly it works really well. Unfortunately I never actually could look at it. How come? Because the EULA is completely friggin' ridiculous. And here's why.

License Agreements

On a newly configured Android phone, one of the first negative things I noticed was that it kind of spams you with license agreements. It seems like there's one for each Google service (like the App Market, Mail if you use it, Maps, or YouTube) and then more for a lot of other apps that use remote services. Generally these work such that you have to agree to them to use the software – if you don't, you don't get to use it.

In my humble opinion, the ones for the Google services are okay. Obviously I'd prefer it if they weren't necessary, but from what I recall they were worded comparatively clearly, not so bogged down with legalese, and fairly agreeable as far as the actual terms go. I try not to leave more data than necessary with Google, but their license agreements didn't give me that much of a bad feeling for using the Android Market, for example.

And then along comes ThinkFree Office.

Some Choice Quotes

To put my rant into the correct perspective, please keep in mind that I am not a lawyer and I have no formal education about EULAs, how they're written and why they're worded as they are. Also, the EULA presented to me is German and I'm translating it on the fly. I'll do my best, but I make mistakes. At any rate, the wording in this blog post is not the exact wording that I'm asked to agree to.

That said, here are a few quotations illustrating why I think that the ThinkFree Office EULA is completely unacceptable:

The software may be used for personal and internal commercial purposes, but not in the operation of a service bureau or to the advantage of another person or commercial entity,

Okay, so let me get my head around this. The gist seems to be that I can use it to write personal stuff, like laundry lists and diary entries. I could probably use it to write this blog entry (theoretically), even if I was making any money off this website, since it's internal use and I'm not running a service bureau, as far as I know. (What exactly constitutes a “service bureau” anyway?)

But wait... if you're reading this blog entry, and you think it's interesting or funny, did I then write it to the advantage of another person? Or is that only financial advantage? I wonder what would happen if I (hypothetically speaking) used it to write a gift coupon for a book for my mother's birthday. Would that be me using it to her financial advantage? My guess is as good as yours.

Finishing the sentence quoted above, we get this gem:

including but not limited to the development of other software.

Sure, I guess that's... wait, what?

Yes, it is explicitly forbidden to use ThinkFree Office for programming.

I started this blog entry with good intentions, but we've already reached the limits of both my goodwill and my imagination. This doesn't even try to make sense. Who wrote that, and what were they thinking? That I might hack ThinkFree Office from within itself, steal it, and sell it as my own? I'm sort of grasping at straws here. Let's leave it at a big fat “WHAT.”

You are not allowed to display, publish, modify, rent, lease, lend, sell or share the software or any part of it.

Right, so if I hand someone my phone, I have to be really careful to not let them use your software, because the license grants it to me and to me alone. Right? Or is it coupled to the phone? It doesn't say so, so I'd have to assume it's not.

Is the license agreement considered to be part of the software, anyway? I'm guessing it is. Good thing I haven't agreed to it, so I can still quote it here.

The software is intellectual property of Hancom Inc. and may not be shared with or displayed to any person besides you and other people who have agreed to this license and are registered with Hancom Inc.

Ah, here we go. I guess that clears that up, at least. If anyone here ever borrows my phone, do not open ThinkFree Office. They don't want you to see it. At all.

You have no rights of property concerning the software. You are merely granted a license to use the software under the conditions outlined in this document, and Hancom Inc. reserves all rights not explicitly granted to you.

Even though this reads like satire, it is sadly commonplace these days. I'm not saying that I think it's a good thing to agree to, but compared to some of the other stuff in there, this is almost sane.

This agreement terminates immediately and without notice, if you violate any of the conditions outlined herein.

Translation: If you don't play by our rules, go to hell.

You agree to destroy the software and all copies of it immediately after this agreement terminates.

Translation: And don't even think about coming back.

The software is provided “AS IS” and Hancom Inc. disclaims any liabilities, implicit or explicit, INCLUDING any silent guarantee concerning admissibility, fitness for any particular purpose, or compliance with the law.

Right. I'm not supposed to assume that the software does its job well. Repeat after me: If the software fails to do its job, I will not complain, because complaining is the way of the devil.

Also, if there's any code in there that (unbeknownst to me) does anything illegal, it's totally my fault, because I didn't check beforehand. Oh no wait, there's a whole paragraph further up that I didn't even bother to quote, that forbids me to even try to look at the code by any means (like decompiling or reverse engineering). So I'm not allowed to make sure that nothing can go wrong, but if something does go wrong it's my fault anyway. Gee, ThinkFree Office, I've only known you for a few minutes but it already feels like an abusive relationship.

You acknowledge and agree that Hancom Inc. may change these conditions at any time. By continuing to use the website, content, service and/or your files after such a modification of the license agreement by Hancom Inc. you agree to be bound by the changed agreement.

How do I know? You probably won't notify me, right? Let's say I check for license updates every time I use your software. What if you update them while I'm using it?

Oh well, I'm sure you'll only change the license agreement in minor ways, update the lawyer-speak or whatever. It's not like you'll say I have to pay you 10€ every time I launch your software...

Hancom Inc. reserves the right to at any time start charging a fee for access or usage of the website, content, services and/or your files.

... nevermind. ಠ_ಠ

You agree to take full responsibility for all activities or actions made by a person using your password, regardless of whether they have been authorized by you or not.

If someone bruteforces my password, or hacks your servers and steals it, it's my fault if they then do something bad with it. Riiiight.

Living in a big city, I've had my fair share of crazy people randomly walking up to me and blabbering about something or other. In situations like that, I try to smile politely and nod, while fervently searching for a way to get out of there. You know what? That is exactly what I am doing right now. Smile, and nod...

The agreement then goes on to list a whole bunch of things I'm not allowed to do while using the software. Among those things: saying stuff that's likely to be misunderstood, accessing “inofficial” parts of their website, doing penetration tests (as in network security), using automated tools or anything else that's not a normal web browser (tough luck, blind people!), sending spam mails, reading the headers of TCP/IP packets or e-mails (I swear I am not making this up), and porn.

And that's about it.

Icing on the Cake

Even after all of that, the best part is yet to come.

As I said earlier, ThinkFree Office came with my phone. It's part of the standard load of crapware you tend to get because the software vendors pay the phone vendors to install their stuff and make it non-removable. Yes, I checked, I can't uninstall ThinkFree Office without voiding my warranty.

Remember earlier, when the license agreement told me that I have to destroy the software if I ever break the license agreement? Think about that for a second. I'll be right here.

Waiting...

So did you figure it out? Yes, indeed, if I agree to be bound by those conditions and I ever break them (even accidentally or through no involvement of my own), I am contractually obligated to void my cell phone's warranty. If I were a conspiracy theorist I'd imagine some evil mastermind behind this scheme. “Isn't it glorious?”

I wonder if I could send my phone to the vendor and demand to have this application removed.

The Verdict

Dear Hancom Inc., or whoever is ultimately behind all of this: As I said, I would have loved to take a look at ThinkFree Office. I appreciate that you took the time to develop a cool mobile office application. I'm not someone who says that absolutely everything has to be free software (though I'd certainly prefer it if it was). But there is simply no way I'm ever agreeing to this. No. Effing. Way.

Dear Samsung, loading your phones with artificially unremovable crapware does not get you any brownie points. It does the opposite. I don't know how much money those people pay you to put their software there, but I'm willing to bet it's low enough that I'd gladly pay it on top of the normal price to get a phone without crapware. This is one of the (few, in my opinion) things that Apple consistently gets right. For that matter, Google gets it right too, concerning the Android hardware they sell directly, or so I've heard. So why live in the nineties?

Vor drei Tagen habe ich neue Features versprochen. Nach einem schrittweisen und heimlichen Launch der letzten paar UI-Elemente ist jetzt alles so weit, dass ich mich freuen würde, wenn die Interessierten unter euch es sich ansehen möchten. Dazu sollte ich sagen, dass nicht alle im Folgenden aufgezählten Features erst seit den letzten paar Tagen existieren, aber sie werden alle zum ersten mal hier explizit erwähnt. Hier die Neuerungen in keiner festen Reihenfolge...

Stichwörter/Kategorien

Lange war's geplant, jetzt ist es umgesetzt: Ich kann meine Blogeinträge und andere Inhalte nun mit Stichwörtern versehen. Über diesem Blogeintrag steht beispielsweise ein leicht ausgegrautes „Website“ (jedenfalls wenn ihr meine Webseite besucht und nicht den RSS-Feed direkt lest). Ein Klick darauf bringt euch zu einer Auflistung aller Einträge, die mit dem Stichwort „Website“ versehen sind.

Analog zu den Blogeinträgen beziehen sich die Stichwörter auch auf Vorträge und andere auf dieser Webseite hinterlegte Inhalte. Auf den orangefarbenen Eintragsseiten stehen sie allerdings nicht über dem Eintrag, sondern zwischen Beschreibung und Kommentarbereich.

Ein Klick auf die Überschrift in einem dieser Stichwortfelder führt euch zu meiner „tag cloud“, welche alle vergebenen Stichwörter auf einmal anzeigt, wobei sich die relative Größe auf höchst mathematische Weise aus der Anzahl vorhandener Einträge zum Stichwort, verrechnet mit ihrem jeweiligen Alter, ergibt. Die Wolke steht in einer verkleinerten Version auf der Startseite.

Übrigens gibt es für jedes Stichwort auch einen eigenen RSS-Feed, zu finden auf der Seite zum Stichwort unter dem letzten Eintrag oder wahlweise dort, wo euer Browser euch RSS-Feeds der aktuellen Seite anzeigt.

Übersetzungen der Blogeinträge

Diese Webseite war von Anfang an so konzipiert, dass sie Mehrsprachigkeit unterstützt, wenigstens Deutsch und Englisch sollten möglich sein. Meine Vision war, dass ich jeden Eintrag in beiden Sprachen schreiben würde. Für alle Nicht-Blogeinträge tue ich das auch nach wie vor, bei den Blogeinträgen mache ich mir die Arbeit allerdings nur, wenn sie mir sehr wichtig erscheinen oder nur sehr kurz sind.

Für alle anderen Fälle biete ich jetzt automatische Übersetzungen an. Die Idee dahinter ist, dass (obwohl die Übersetzungen teilweise alles andere als perfekt sind) ein englischsprachiger Leser so trotzdem eine bessere Chance hat, mich zu verstehen, als wenn der Text nur auf Deutsch vorliegt. Die Übersetzungen sind derzeit auf der englischen Übersichtsseite meines Blogs zu bewundern und haben dort einen eigenen Link unterhalb der Beiträge, die ich nur auf Deutsch geschrieben habe. Dahinter findet man dann die Übersetzung (Beispiel) mit Warnhinweis.

Normalerweise lese ich mir die nur ein mal durch, um sicherzugehen, dass keine ganz groben Sinnverfälschungen drinstehen. Ich übernehme aber keinerlei Garantie.

Sprach- und Lizenz-Infos

Ich kann jetzt zu den Links, die unterhalb von Einträgen zu Vorträgen, Artikeln oder Media-Dingen stehen, noch zusätzliche Informationen hinzufügen. Das merkt ihr als Besucher vor allem daran, dass jetzt in Form eines kleinen Icons dransteht, wenn eine PDF-Datei, ein Video o.Ä. unter einer freien Lizenz steht (und wenn ja unter welcher), und dass es angezeigt wird, wenn eine Datei oder ein Video in einer anderen Sprache vorliegt als die, in der ihr diese Webseite lest. Da mein Kram momentan so ziemlich komplett auf Deutsch vorliegt, trifft Letzteres bisher nur die englischsprachigen Besucher.

Druck-Stylesheet

Mein CSS kann jetzt deutlich besser damit umgehen, wenn ihr etwas von meiner Webseite ausdrucken möchtet. Es gibt dann Serifenschrift, keine Hintergrundfarben, keinen Navigationskram und weitere solche Anpassungen. Probiert es gerne mal aus, wenn ihr mögt.

Verschiedenes

Ansonsten hat's wieder die üblichen kleinen Verbesserungen unter der Motorhaube gegeben, die ich zum großen Teil schon wieder vergessen habe. Ich hab mich u.A. noch mal darum gekümmert, dass auch wirklich alles hier als XHTML 1.1 validiert. Ich hoffe ich hab dabei nichts übersehen.

Wie immer: Bei Fragen, Wünschen oder entdeckten Bugs gerne einfach mal melden.

Für alle Leser, denen ihre RSS-Reader heute alle Einträge von meiner Seite als neu angezeigt haben: Sorry, ich hab an den Feeds rumgebastelt, das ist dabei versehentlich passiert.

Kommt (hoffentlich) nicht wieder vor und war Konsequenz von Umbauarbeiten, die ein lange benötigtes und von mir heiß erwartetes Feature für meine Webseite möglich machen sollen. Demnächst mehr!

Auf OSNews ist heute ein von mir verfasster Artikel zum Thema Komplexität grafischer Schnittstellen online gegangen (englisch):

Over the past few decades, the software that enables us to be productive with our computers has become increasingly sophisticated and complex. Today's UI designers are faced with the challenge of devising graphical user interfaces that are easy to grasp and use, yet still provide access to a wide range of features. Here are some ideas about the nature of GUI complexity, followed by a couple of thoughts on simplicity that might just surprise you.

Es freut mich sehr, dass der Artikel bereits jetzt eine interessante Diskussion ausgelöst hat. Ich bin offen für Vorschläge, womit genau sich weitere Artikel dieser Art befassen sollen. Wer möchte, kann das drüben im OSNews-Kommentarbereich mitentscheiden.

Christoffer/ephracis hat dazu bereits eine lesenswerte Antwort veröffentlicht, die ich hiermit weiterempfehle.

Letzte Woche habe ich (nachdem wir eine ganze Weile für die Terminfindung gebraucht haben) ein wenig mit Flo (und spontanerweise Rolf) die Köpfe zusammengesteckt mit dem Ziel, ein paar gute Fotos für meine Webseite und andere Online-Aktivitäten zu machen.

Zu Flos Bericht brauche ich nicht viel hinzufügen, die Perspektive des Fotografen hat er dort bereits ausführlich und für mich als Laien trotzdem verständlich dargestellt.

Ich find's super von Flo, dass er die Idee so offen angenommen hat. Dass dabei so ein tolles Shooting herauskommt, hätte ich nicht zu hoffen gewagt, als ich ihn damals angesprochen habe: „Hey, hast du evtl. mal Zeit und Lust, ein paar Porträtfotos von mir zu machen, oder kannst du mir einen anderen Fotografen empfehlen?“ – Aus der Situation hat Flo (zusammen mit Rolf) großartige Ergebnisse gezaubert, für die ich mich hier nochmal herzlich bedanken möchte!

Für mich als jemand, der sich hauptsächlich über intellektuelle Leistungen definiert, war es eine merkwürdige Erfahrung, das eigene Äußere so in den Mittelpunkt gestellt zu bekommen. Ich bin vielleicht nicht so kamerascheu wie viele andere Leute (die sich beim Anblick einer Linse reflexartig wegdrehen), aber mehrere Stunden mit dem Posieren und Lächeln zu verbringen war dann letztlich doch ziemlich anstrengend. Zum Glück hat's mit Flo und Rolf durchgehend sehr viel Spaß gemacht, auch wenn ich hinterher echt geschafft war. Ich würde Team Letsch & Boomgarden jedenfalls weiterempfehlen.

Die Ergebnisse finden sich nun außer auf Flos Blog auch auf meiner Festplatte. Ich muss noch mal schauen was genau ich damit mache. Zunächst mal gibt's ein zufälliges kleines Bild von mir auf meiner Hauptseite. Mal sehen, was mir noch so einfällt...

Die Weihnachtstage sind eine Zeit für viele schöne Dinge: alte Freunde treffen, mit der Familie zusammen sein, gut essen, ausschlafen. Ich klinke mich in dieser Zeit gerne ein wenig aus den meisten Uni-Pflichten aus und betreibe ein wenig Programmierung für eigene Zwecke. Die letzten zwei, drei Tage habe ich mich meiner Webseite gewidment und die technische Grundlage für die Internationalisierung generalüberholt.

Wichtige Änderungen

Zuerst vielleicht mal das, was sich für Besucher der Seite ändert. Die auffälligste Änderung: Es gibt keinen „Implizite-Sprache-Modus“ mehr, sondern jeder Besucher befindet sich jederzeit entweder auf der deutschen oder der englischen Version der Seite. (Daran, dass nur auf deutsch verfügbare Inhalte auch auf der englischen Seite auf deutsch angezeigt werden, ändert sich hierdurch nichts.) Ihr merkt das daran, dass ihr beim Besuch der Seite auf eine Subdomain umgeleitet werdet, entweder de.julian-fietkau.de oder en.julian-fietkau.de, je nach Spracheinstellung des Browsers. Umschalten könnt ihr wie gehabt über die Flagge in der Fußleiste.

Die Links sehen ein wenig anders aus. Statt einer Sprachangabe am Ende des Links (früher: „http://www.julian-fietkau.de/blog/en“) wird die Sprache jetzt über die Subdomain spezifiziert (neu: „http://en.julian-fietkau.de/blog“). Analoges gilt für Direktlinks auf Dateien, soweit sie überhaupt zugelassen sind. Der präferierte Link zur Weitergabe ist nach wie vor der mit dem „www“ ohne Sprache, so dass jeder Besucher des Links die Sprache bekommt, die er lieber haben möchte. Jeder Link ist auch mit „www“ statt „de“ oder „en“ möglich und führt dann die entsprechende Weiterleitung durch.

Das ist im Grunde auch schon alles. Ich schreibe mal noch ein wenig dazu, warum ich das gemacht habe und wie das umgesetzt ist. Warnung vorweg: Hier spricht mal wieder hauptsächlich der Programmierer.

Eindeutigkeit von URLs

Ich war schon seit dem Launch dieser Version meiner Seite ein wenig unzufrieden damit, dass gängige Suchmaschinen zunächst die englischen Versionen meiner Unterseiten indiziert hatten und die deutschen dann nur über die explizite Angabe der Sprache verfügbar waren. Es scheint eine schlechte Idee zu sein, per Auswertung der Spracheinstellung mehrere sprachliche Versionen des Inhalts unter der selben URL verfügbar zu machen. Ist zwar schön, wenn Benutzer einfach die Adresse aus ihrem Browser kopieren und verteilen können, aber irgendwie ist diese dynamische Anpassung der Sprache einer URL doch etwas zu nichtdeterministisch für ein funktionierendes Web und geht entgegen der Konventionen.

In der jetzigen Lösung hat jede URL, hinter der Inhalt liegt, eine eindeutige und explizite Sprache. Alle anderen sind Weiterleitungen, die ggf. die Spracheinstellung des Benutzers bei der Auswahl des Weiterleitungsziels berücksichtigen. Das „xml:lang“-Attribut wird nun übrigens auch korrekt gesetzt.

Über HTTP-Statuscodes

Ich stand vor der Herausforderung, die Struktur so zu implementieren, dass die neuen Links alle funktionieren und die alten weiterhin funktionstüchtig bleiben. Man weiß ja nie, wer sich evtl. irgendwelche Bookmarks gesetzt hat oder wo die URLs überall stehen. Dass die alten weiterhin funktionieren, war mir also schon ziemlich wichtig. In diesem Sinne wird jeder Besucher einer alten URL mit expliziter Sprachangabe per „301 Moved Permanently“ auf die neue Adresse weitergeleitet, ohne sich daran großartig stören zu müssen.

Die andere große Frage war, was ich mit den Besuchern einer Seite ohne Sprachangabe jetzt mache. Einfach irgendwelchen Inhalt rausgeben wollte ich ja nicht mehr. Nachdem ich ermittelt habe, ob sie lieber „de“ oder „en“ haben wollen, werden sie deshalb jetzt per „303 See Other“ auf ihre Sprachversion weitergeleitet. Dadurch bringe ich laut Wikipedia im Gegensatz zu einem 301 unter Anderem zum Ausdruck: „The specified URI is not a substitute reference for the original resource.“ Soll heißen: „Hey Besucher! Das, was du angefragt hast, kannst du persönlich am besten stattdessen hier finden, aber das gilt nicht unbedingt für den Rest der Welt gleichermaßen.“

Die verflixten Kleinigkeiten

Ohne allzu sehr über langweilige Interna zu sprechen, kann ich sagen, dass die meiste Zeit mal wieder der Kleinkram verschlungen hat. Ich musste an vielen Stellen die Templates anpassen und vor allem der OpenID-Login war die letzten zwei Tage komplett kaputt. Jetzt sollte hoffentlich alles wieder gehen. Falls ihr über irgendwelche Bugs oder andere Auffälligkeiten stolpert, sagt mir gerne bescheid!

P.S. Noch eine knappe Stunde lang könnt ihr die Weihnachtsdeko bewundern, danach verschwindet sie bis nächsten Dezember.

Willkommen zum dreiundzwanzigsten und letzten (!) Bericht zu meiner Bachelorarbeit zum Thema Teachlets. Ein Lebensabschnitt geht zuende... Heute ist der große Tag: der Tag der Abgabe, der Tag der Veröffentlichung. In diesem Sinne bin ich hocherfreut, euch ohne weitere Ausschweife präsentieren zu können:

Das Teachlet-Konzept: Möglichkeiten und Grenzen einer Lehrform für Software-Entwurfsdiskussionen (INFDok)

In den letzten paar Berichten habe ich schon ziemlich viel über die letzten Schritte vor dem Veröffentlichen erzählt, deshalb kommen heute folgerichtig Infos zur Abgabe und Veröffentlichung an sich, gefolgt von einem Fazit über diese Berichte.

Wie eine Bachelorarbeit ihren Weg ins Studienbüro findet

Die eigentliche Abgabe der Arbeit war letztendlich ungeheuer unspektakulär. Ich bin heute extra früher aus einer Veranstaltung raus um zur Öffnungszeit des Studienbüros (13 Uhr) dort zu sein, wo ich dann auf Frau Wilsdorf traf, die mir meine drei gebundenen und unterschriebenen Exemplare plus CD-ROM abgenommen hat. (Weil heute Nikolaus ist, hab ich auf jede Arbeit einen kleinen Schoko-Weihnachtsmann geklebt, das fand sie ganz witzig. Danke an Janina für diese lustige Idee!) Nach knapp 15 Sekunden war's das auch schon wieder – keine Fanfaren, kein Konfetti... Naja, jetzt hab ich das ganze Unternehmen jedenfalls komplett hinter mir und kann in Ruhe auf die Gutachten meiner Betreuer warten. Ich hoffe, dass ich mein Bachelorzeugnis auf der Absolventenverabschiedung im Januar bereits bekommen kann – meines Wissens nach gibt es die zwei mal im Jahr, diese wäre dann der „großen“ im Sommer genau entgegengesetzt.

Veröffentlichung einer Abschlussarbeit

Über das pro und contra einer Veröffentlichung einer Bachelorarbeit wurde hier bereits mehrfach diskutiert. Besonders Veröffentlichungen von Vorabversionen sind nicht unstrittig, aber darüber wurde im Zusammenhang mit dem Themenblock Feedback hier schon genug geschrieben. Heute geht es mir um die Veröffentlichung der fertigen Version, wie sie bei mir jetzt erfolgt ist. Denn dagegen spricht in meinen Augen so ziemlich gar nichts.

Ich kann mir zwei Fälle vorstellen, in denen ich es verstehen kann, wenn jemand seine Abschlussarbeit nicht veröffentlichen möchte. Das eine ist eine Arbeit bei einer externen Firma, die gegen eine Veröffentlichung über den nötigen Rahmen hinaus aus Geheimhaltungsgründen Einwände hat. (Ob man sich als Student darauf einlassen möchte, ist die andere Frage, aber wenn es so kommt, dann muss man natürlich konsequent sein.) Das andere ist eine Arbeit, die lediglich mit dem Anspruch auf ein „bestanden“ geschrieben wurde und mit der der Verfasser nie wieder in Verbindung gebracht werden möchte. Ich kenne solche Situationen, in denen ich für eine Studienleistung nur das Nötigste gebe, weil mir das Lernziel am Allerwertesten vorbeigeht, das kann vorkommen. Aber bei einer Bachelorarbeit sollte es die absolute Ausnahmen sein, oder?

Dem gegenüber stehen die vielen Gründe, die eigene wissenschaftliche Arbeit von vornherein offen zu legen, von denen ich nur mal ein paar aufzählen möchte:

• Leute interessieren sich dafür. Es stimmt wirklich. Seit etwas über einem halben Jahr stelle ich meinen ganzen Kram hier auf meine Webseite und ich bekomme immer wieder Rückmeldungen und Anfragen dazu – größtenteils von Kommilitonen, klar, aber auch schon von Personen aus anderen Teilen Deutschlands und aus anderen Ländern der Welt (!). Leute kommen per Suchmaschine auf meine Webseite, weil sie irgendwas suchen, worüber ich mal einen Vortrag gehalten und die Folien hier online gestellt habe. Das macht mich schon ein wenig stolz. Vor ein paar Wochen bekam ich eine Mail von einem Menschen, der in meiner Seminararbeit „viele interessante Ansätze“ gesehen hatte und mich fragte, ob er mich für einen Job als Softwareentwickler in Hamburg begeistern könne. Viele Studenten glauben, dass sich niemand dafür interessiert, was sie machen – gerade so als ob erst nach dem Studium irgendein Schalter umgelegt wird und man dann „richtige“ Wissenschaft machen kann. Das ist falsch Leute, eure Ergebnisse sind wertvoll!
• In Zeiten des Internets liegen die Kosten dafür, einen Text zu veröffentlichen, sehr, sehr nahe bei Null. Wer keine eigene Webseite hat, kann immer noch auf externe Unterstützung zurückgreifen, in der Hamburger Informatik z.B. auf INFDok (siehe unten). In der Vergangenheit und bis heute hat die Wissenschaft viel Zeit und Ressourcen dadurch verloren, dass Dinge mehrfach entdeckt und erforscht wurden, weil Leute einfach veröffentlichungsfaul waren. Warum?
• Der Löwenanteil meines Studiums bezahlt trotz Studiengebühren nach wie vor die öffentliche Hand, also der Steuerzahler. Das geschieht in der Hoffnung, dass ich später mal mit meiner fachlichen Bildung ordentlich etwas für den Standort Deutschland tue, klar. Aber wer mich kennt, weiß, dass ich nicht gerne Schulden habe. Deshalb finde ich es sinnvoll, der Öffentlichkeit schon jetzt zurückzugeben, was ich durch mein Studium erreiche. Meine Bachelorarbeit ist ein handfestes Ergebnis von „wissenschaftlicher Relevanz“, das jeder für weitere, darauf aufbauende Wissenschaft verwenden kann. So sollte der Laden funktionieren.

Weil ich an eine frei zugängliche wissenschaftliche Welt glaube, veröffentliche ich meine Bachelorarbeit unter CC-BY-SA. Dem Thema „Was für Lizenzen gibt es und wofür sollte ich sie verwenden?“ werde ich mal einen eigenen Blogeintrag widmen. Hier nur so viel: Diese Lizenz erlaubt es jedem Leser, das Dokument weiter zu verteilen und darauf aufbauende Arbeiten zu schreiben, solange mein Name dabei genannt wird und die Ergebnisse wieder unter einer solchen freien Lizenz stehen („Copyleft“).

INFDok

Die Informatik-Bibliothek betreibt einen Volltext-Server für wissenschaftliche Arbeiten, die an unserem Fachbereich entstehen. Dort können auch Studierende ihre Arbeiten veröffentlichen (allerdings nur, wenn ein Professor oder ein wissenschaftlicher Mitarbeiter die wissenschaftliche Relevanz der Arbeit bestätigt). Das ist ziemlich unproblematisch und ich habe das direkt mal in Anspruch genommen. Die Vorteile dieses Services zitiere ich von der Bibliotheks-Webseite:

• sofortige weltweite Verfügbarkeit der Veröffentlichung ohne Verzögerung durch Herstellung, Druck und Vertrieb,
• langfristige Archivierung mit einer dauerhaft stabilen und zitierfähigen Internetadresse,
• kostenlose Publikationsmöglichkeit für den Autor,
• Volltextsuche über die gesamte Publikation,
• formale und inhaltliche Erschließung über die Informatik-Bibliothek,
• bibliographischer Nachweis im Online-Katalog der Bibliothek sowie in überregionalen Bibliotheksverzeichnissen.
• Für eine Autorin oder einen Autor bietet sich mit INFDok die Chance, ein zentrales elektronisches Volltext-Archiv seiner Publikationen aufzubauen.
• Alerting-Dienst per RSS-feed über die neuesten Publikationen
• Schnittstellen zu Open-Access-Suchmaschinen
• Zugriffsstatistik

Der Spaß ist komplett kostenlos und wird von der Informatik-Bibliothek betreut, die ja ohnehin für ihren entgegenkommenden Service bekannt ist. Die Idee eines OpenAccess-Katalogs finde ich persönlich großartig – und hey, ich bin nicht alleine, siehe OpenAccess-Award 2010. Ich kann nur mit Nachdruck für das Projekt werben und euch ermutigen, eure Arbeiten dort bereitzustellen. Das Bibliothekspersonal berät euch dazu sicher gerne! In dem Zusammenhang möchte ich mich ganz herzlich bei Frau Obernesser bedanken, die sich bereit erklärt hat, die Veröffentlichung der Arbeit heute synchron mit meiner eigenen durchzuführen und auch sonst während des Prozesses immer hilfsbereit war.

Noch ein bisschen Meta

Mit der heutigen Abgabe und Veröffentlichung der Arbeit enden auch die wöchentlichen Fortschrittsberichte. Ich muss sagen, dass ich viel Spaß dabei hatte, die Entstehung zu dokumentieren! Zu Anfang gab es ja Unkenrufe, ob sich das lohnt und ob es überhaupt jemanden interessiert. Ich kann nur sagen, dass ich vorher froh gewesen wäre, wenn schon mal jemand aufgeschrieben hätte, wie das so ablaufen kann. Dass es da Bedarf gibt, hat ja auch der letzte fb18-Thread zum Thema wieder gezeigt.

Außerdem haben die Berichte wirklich dazu beigetragen, mich vor allem in der heißen Phase von Woche zu Woche immer wieder zu motivieren. Die unangenehme Situation, längere Zeit untätig zu sein und dann in Zeitnot zu kommen, konnte ich so glücklicherweise vermeiden. Dazu kommt, dass es mir viel gebracht hat, alles immer wieder zu reflektieren. Ich habe die Berichte genutzt, um mir Dinge vorher zu überlegen und hinterher zu reflektieren und noch weiter zu verbessern. Ich bin mir recht sicher, dass sich das positiv auf die Gesamtqualität der Arbeit ausgewirkt hat. Nicht zuletzt habe ich auch einiges an Feedback von euch, meinen Lesern, bekommen, das mir ebenfalls weitergeholfen hat. Insgesamt habe ich das Schreiben nie als Last empfunden, da ich meist in Form eines einfachen Bewusstseinsstroms alles geschrieben habe, was mir so in den Sinn gekommen ist. Ich tippe noch nicht mal besonders schnell, aber mehr als eine halbe Stunde oder eine Stunde habe ich selten investiert.

Es ist immer schön, wenn wenig Arbeit viel erbringt, von daher ist die Nachahmung ausdrücklich empfohlen. Ich bin neugierig, wie eure Abschlussarbeiten so laufen. Es soll ja auch niemand denken, dass mein Weg der einzig richtige wäre. Wer macht es mir nach?

Auf in die Zukunft

Das Studium geht weiter und die nächste Abschlussarbeit kommt bestimmt. Bis dahin wird mein Blog wieder in unregelmäßigen Abständen mit Inhalten zu Themen befüllt, die mich interessieren. Behaltet diese URL im Auge (oder diese) oder abonniert meinen Feed, damit ihr nichts verpasst. Falls euch das Thema interessiert, lest meine Bachelorarbeit und verteilt sie weiter. Vielen Dank für eure Treue! Man sieht sich!

-- Julian

Willkommen zum vorletzten Bachelorarbeits-Bericht. Vorweg kann ich schon mal verkünden: Die Arbeit ist erfolgreich finalisiert und gedruckt worden und wurde heute schon mal meinen beiden Betreuern übergeben. Im Studienbüro werde ich sie dennoch wie geplant erst kommenden Montag abgeben, da sie jetzt auf den 6.12. vordatiert ist (der Endspurt ging schneller als geplant).

Drucken und Binden

Am letzten Samstag habe ich mich das erste Mal mit Textsatz für doppelseitigen, gebundenen Druck befasst. Bisher war die Arbeit für Bildschirmlesen und einseitigen Druck optimiert, was natürlich in gebundener Form nicht so viel hermacht. Deshalb habe ich mich mal ein wenig eingelesen – wieder mal ein Thema, mit dem man Wochen verbringen könnte – und einfach mal die Option „twoside“ für mein Dokument gesetzt und ein bisschen herumexperimentiert mit pagestyle und cleardoublepage. Nach einer Weile war ich dann auch zufrieden. Als PDF sieht es beim seitenweisen Durchblättern ziemlich bescheiden aus, aber in der zweiseitigen Ansicht ist es mal echt eindrucksvoll.

Leider habe ich die Bindekorrektur sträflich vernachlässigt, so dass nach dem Drucken und Binden im Innenbereich unangenehm wenig Weißraum ist. Liebe Schreiber von Abschluss- und sonstigen Arbeiten: Bitte denkt an eine geeignete Bindekorrektur, wenn ihr für zweiseitigen Druck setzt. In LaTeX könnte das z.B. so aussehen:

\documentclass[twoside,BCOR=15mm]{scrartcl}

Ich bin fürs nächste Mal jedenfalls schlauer, aber dieses Mal sind die Druckexemplare leider deshalb etwas unangenehm zu lesen. Sehr schade.

Optimieren für digitale Veröffentlichung mit LaTeX

Wenn ich das Dokument hier als PDF bereitstelle, dann nehme ich die Version für den einseitigen Druck, da die auch für den Selbstausdruck am besten geeignet ist – dabei werden die Seiten ja in der Regel bloß locker zusammengeheftet bzw. getackert. Am Bildschirm finde ich diese Variante angenehmer.

Aber die PDF-Publikation bietet noch ein paar Besonderheiten, die für euch evtl. auch ganz interessant sind. In Zeiten, in denen Publikationen zunehmend auch digital erfolgen, sollte man nicht davor zurückschrecken, auch die Vorteile des Mediums auszunutzen.

Hyperlinks mit hyperref: Das erste Paket, das in keiner mit LaTeX erstellten PDF-Publikation fehlen sollte, ist hyperref. Es kann vollautomatisch arbeiten, lässt sich aber auch sehr schön anpassen. Was tut hyperref? Es versieht das Dokument mit internen und externen Hyperlinks. Zum Beispiel ist jede Kapitelüberschrift im Inhaltsverzeichnis im PDF-Viewer anklickbar und führt direkt zum entsprechenden Kapitel. Jedes Literaturkürzel im Text führt zum entsprechenden Eintrag im Literaturverzeichnis, jede sonstige Referenz (z.B. auf Abbildungen oder Tabellen) führt zu ihrem jeweiligen Ziel und jeder Weblink kann durch einen Klick im Browser geöffnet werden. Die knallbunten Rahmen, die hyperref standardmäßig setzt, muss man nicht unbedingt schön finden – sie werden allerdings standardmäßig nicht mitgedruckt und lassen sich auch sonst anpassen oder ganz deaktivieren. Im Ernst, hyperref ist sehr praktisch für Leute, die das Dokument digital lesen, und lässt im PDF-Viewer den „Zurück“-Button vermissen.

Metadaten mit hyperxmp: Bei XMP handelt es sich um ein von Adobe spezifiziertes Format für Metadaten, das in allerlei Container-Formaten zum Einsatz kommen soll, zur Zeit allerdings meines Wissens nach für PDF-Dateien am relevantesten ist. Das hyperxmp-Paket erlaubt es dem geneigten pdfLaTeX-Benutzer, Metadaten in diesem Format zum Dokument hinzuzufügen. Dazu integriert es sich in hyperref, welches ebenfalls eingebunden werden muss. Mit diesem Paket lassen sich nebst Titel, Autor, Stichwörtern usw. auch Urheberrechts- und Lizenzinformationen hinterlegen. Wenn man irgendwann mal aus den PDF-Dateien die Lizenzinformationen automatisiert auslesen möchte, ist es Gold wert, wenn sie in einem solchen standardisierten Format hinterlegt sind und nicht nur irgendwo im Dokument stehen. Bei mir sieht das so aus:

\hypersetup{
  pdfcopyright={This work is licensed to the public under the
    Creative Commons Attribution Share-Alike 3.0 License.},
  pdflicenseurl={http://creativecommons.org/licenses/by-sa/3.0/}
}

Eine explizite Nennung der Lizenz, die im Dokument lesbar ist, kommt natürlich noch hinzu.

Dateianhänge mit embedfile: Hin und wieder würde man gerne beliebige Dateien mit dem Dokument mitliefern, seien es Quelltexte, Bilder, Messdaten oder was einem sonst noch einfällt. Weniger bekannt ist, dass das PDF-Format Dateianhänge unterstützt und dass das embedfile-Paket dieses Feature für pdfLaTeX nutzbar macht. Unter Angabe einiger Metadaten zur Datei (z.B. des MIME-Typs) kann man dann beliebige Dateien an das PDF-Dokument anhängen. Es ist dann Sache des PDF-Viewers, diese Dateianhänge dem Leser anzuzeigen. Mein PDF-Viewer, evince (jetzt auch für Windows erhältlich), tut das über die Seitenleiste, unterhalb des Punktes „Anlagen“. Ich hänge an meine Bachelorarbeit z.B. ein paar Java-Quelltexte an, damit der Leser sie nicht mühsam mit der Maus markieren und kopieren muss um sie zu testen. Ein Doppelklick auf den Anhang öffnet direkt einen „Speichern“-Dialog, das ist doch viel netter.

Dateianhänge mit attachfile2: Auch das Paket attachfile2 erlaubt Dateianhänge, nutzt dafür jedoch ein anderes PDF-Feature, nämlich Annotationen. Damit werden Dateien nicht allgemein an das Dokument angehängt, sondern an einer bestimmten Stelle eingebunden. Das bedeutet, dass man dann in der PDF-Datei so etwas wie anklickbare Icons haben kann (dieses Mal tatsächlich so richtig im Dokument statt als Anhang), hinter denen sich dann eine Datei verbirgt. Die Verwendung von attachfile2 ist nicht ganz einfach, aber nach etwas Einlesen habe ich eine Variante raus, in der meine Datei-Annotationen funktionieren und unterhalb meiner Listings ein Java-Icon angezeigt wird, das anklickbar ist. Das ist auch sehr nett.

In meiner Arbeit habe ich diese Variante mit embedfile kombiniert und meine Quelltexte sowohl als Annotation als auch als Anhang eingebunden. Jetzt liegt der Quellcode zwar doppelt (bzw. einschließlich der textuellen Version im Dokument sogar dreifach) im Dokument, aber die paar hundert Bytes betrachte ich als kleinen Preis für die Aufwertung der Benutzbarkeit.

Alle diese Features sind hilfreiche Verbesserungen der Usability für Leute, die das Dokument digital konsumieren, ohne dabei die Print-Leser zu benachteiligen. Deshalb ermutige ich jeden, der seine Arbeiten auch digital verbreiten möchte, sich mit den Möglichkeiten zu befassen.

Stand der Abgabe der Arbeit, Ausblick

Um den Bogen zurück zu schlagen: Wie oben bereits erwähnt habe ich die Arbeit inzwischen schon in gedruckter Form meinen Betreuern übergeben. Die drei Exemplare für das Studienbüro liegen mitsamt der gebrannten CD noch bei mir zuhause und werden kommenden Montag erst abgegeben. Danach liegt das Prozedere außerhalb meines Einflussbereichs und ich warte nur noch auf die Endnote.

Kommenden Montag (nicht Dienstag) ist es soweit, da gibt es dann die Arbeit hier zu lesen und herunterzuladen. Dazu kommen noch ein paar allgemeine Gedanken und ein Fazit von mir. Und dann, tja, ist es vorbei. Zumindest bis zur nächsten Abschlussarbeit... aber erst mal bis Montag!

Hier ist der drittletzte Bachelorarbeits-Bericht, ungefähr zwei Wochen vor der endgültigen Einreichung der Arbeit. Viel wird am Text nicht mehr passieren. Ich warte noch auf ein bisschen Feedback, aber ansonsten ist der Rest eher administrativ: ausdrucken, binden, abgeben und so. Heute erzähle ich noch kurz, was im zuletzt entstandenen Kapitel drinsteht, und komme danach zu den bei der Abgabe der Arbeit relevanten Dingen.

Jenseits von Teachlets

Diesen vorläufigen Titel hat das letzte Unterkapitel bekommen, das ich letzte Woche noch geschrieben habe. Das sind tatsächlich noch mal knapp zwei Seiten geworden, auf denen ich gedanklich die absoluten Kernaspekte der Teachlets aus dem Konzept entferne und gucke, was passiert. Teilweise sind dabei ganz interessante methodische Ansätze entstanden, teilweise waren die Ergebnisse aber auch nicht allzu spannend (wir nehmen Teachlets und entfernen die Interaktivität – juchu, wir haben den klassischen Vortrag erfunden...) bis hin zu eindeutigen gedanklichen Sackgassen wie etwa Methoden ohne Teilnehmer.

Von den offenen Enden lasse ich mich aber nicht weiter stören, das Kapitel war ja schon als Bonus geplant und soll lediglich als kleiner Ausblick dienen. Und ganz ehrlich: Inzwischen habe ich auch die Nase voll von der Arbeit. Es hat insgesamt viel Spaß gemacht, aber ich habe einfach keine Lust mehr, noch länger über diesem Text zu brüten, wo er sich für mich schon seit zwei Monaten fertig anfühlt. Naja, nun ist es ja auch fast soweit.

Abgabemodalitäten

Bei der Anmeldung habe ich den 6. Dezember als Deadline erhalten – der Tag drei Monate nach der Bestätigung der Anmeldung durch den Prüfungsausschussvorsitzenden. Spätestens an diesem Tag muss ich die Arbeit im Studienbüro abgeben, wobei ich auf die Öffnungszeiten achten muss. In meinem Fall, am Montag, geht das z.B. nur vormittags.

Die Abgabe soll in dreifacher schriftlicher und gebundener Form sowie auf CD erfolgen. (Die Prüfungsordnung spricht von einem „geeigneten elektronischen Speichermedium“, in dem Merkblatt des Studienbüros steht, es soll eine CD sein.) Das ist natürlich doof, wenn man seit Jahren keine CDs mehr brennt und die verstaubten Rohlinge längst verschenkt hat. Kapitalismus to the rescue: Bei einer Elektronik-Handelskette in meiner Nähe kann man tatsächlich einen CD-Rohling kaufen (für 70 Cent). Das habe ich gleich mal gemacht. Hoffen wir, dass beim Brennen nichts schief geht...

Die Erklärung, dass ich keine Texte geklaut oder Quellen verschwiegen habe, habe ich auch bereits erstellt, natürlich inklusive Erlaubnis für die Bibliothek die Arbeit in ihren Bestand aufzunehmen. Da ich keine Vorabversionen mehr verteilen werde, habe ich auch schon mal das Dokument ein wenig aufgeräumt: Ich habe den Lizenzverweis und die entsprechenden Metadaten eingefügt und das Wasserzeichen entfernt. Es sieht schon alles ziemlich sauber und final aus.

Das Binden werde ich vermutlich in der Informatik-Bibliothek durchführen, da es dort die Möglichkeit für Studenten gibt, das kostenfrei zu machen. Drei Exemplare muss ich abgeben, dann werd ich wohl noch jeweils eins für meine Betreuer und eins für mich selbst anfertigen. Bei (inzwischen) insgesamt 60 Seiten pro Exemplar sind das immerhin 360 Druckseiten, was von den Kosten her schon wieder nicht zu vernachlässigen ist. Eigentlich hätte ich sie ja auch ganz gerne auf gebleichtem Papier – ich weiß, Un-Öko, aber doch ansehnlicher. Mein kleiner Tintenstrahler wird das allerdings nicht in einem sinnvollen Qualität-Kosten-Maß mitmachen. Ich muss mal herausfinden, was das Informatik-RZ sagt, wenn ich so viel auf dem einen A4-Farbdrucker ausdrucken möchte, den die haben. Preislich ist die Methode vermutlich nicht zu schlagen. Falls die mir nen Vogel zeigen, muss ich mich dafür vielleicht mal nach einem guten aber günstigen Laden umsehen, der das für mich macht. Oder kennt jemand von euch eine bessere Möglichkeit?

Ausblick

Nächste Woche um diese Zeit ziehe ich den Feedback-Schlussstrich. Das heißt, dass Axel nur noch bis dahin Zeit hat, mir Feedback zu geben. Das hat er allerdings auf dem Schirm, ich habe gestern schon eine Mail deshalb von ihm bekommen. Außerdem bekomme ich dankenswerterweise noch Feedback von Jan, auf das ich schon sehr gespannt bin.

Nächste Woche gibt's also einen kurzen Bericht, was ich an Feedback bekommen habe und was ich schon eingearbeitet habe bzw. noch muss. Im Laufe der restlichen Woche passiert dann das Drucken und Binden. Den letzten Bericht kündige ich jetzt schon mal für einen Tag früher an: Es bietet sich an, den allerletzten (versprochen!) Bericht direkt am Montag den 6. zu schreiben. Ich freu mich drauf. Aber erst mal bis nächste Woche!

Und schon ist wieder eine Woche vergangen, hier kommt der letzte Bericht, der (jedenfalls laut meiner aktuellen Planung) in der letzten Schreibphase meiner Arbeit liegt. Das heißt noch nicht, dass es der letzte Bericht insgesamt ist – ein paar Wochen sind's ja noch, bis ich diese Unternehmung endgültig hinter mir habe. Leider ist in der letzten Woche nicht so sehr viel passiert, zu den verwandten Methoden habe ich bisher keinen guten Zugang finden können. Das Ziel ist jetzt, dass ich das bis zum Wochenende schaffe.

Der erste Eindruck zählt...

...und die erste Seite einer Bachelorarbeit ist typischerweise ein Deckblatt. Nur wie muss so ein Ding eigentlich aussehen? Ich hab noch mal die relevanten Teile der Prüfungsordnung gelesen und dazu rein gar nichts gefunden – es gibt also wohl keinerlei formale Anforderungen. Wie ich schon letzte Woche geschrieben habe, habe ich hier auch so eine PDF-Datei rumfliegen, die „Hinweise für Studien- und Diplomarbeiten“ von SWT enthält (Stand 2003...), aber das sind ja höchstens Empfehlungen.

Die meisten dieser Empfehlungen sind obendrein echte Selbstläufer. Dass auf das Deckblatt der Arbeit auch der Titel der Arbeit gehört, diese Weisheit hätte ich mir vermutlich auch ohne fremde Hilfe erschlossen. Die SWT-Empfehlungen und ich gehen lediglich in zwei Punkten auseinander:

1. Dort wird empfohlen, die Matrikelnummer auf dem Deckblatt zu platzieren. Welchen tieferen Sinn soll das haben? Dass alle Welt meine Matrikelnummer kennt, die an unserer Uni ständig als pseudoanonymer Identitäts-Schlüssel z.B. in Notenlisten verwendet wird? Wenn ich nicht der einzige Julian Fietkau an dieser Uni wäre, dann gäb's wenigstens überhaupt ein Argument dafür. Aber das bin ich. Von daher: Warum sollte ich meine Matrikelnummer auf meine Bachelorarbeit schreiben? Ernsthaft, wenn mir dafür niemand einen Grund nennt, dann mache ich das auch nicht.
2. Post- und E-Mail-Adresse. Die Vorstellung, auf meine Bachelorarbeit meine Privatadresse zu schreiben, finde ich aus ähnlichen Gründen etwas lächerlich. Das richtet sich vielleicht eher an Leute, die sowas wie ein Büro an der Uni haben. Den Sinn einer E-Mail-Adresse, den Autor kontaktieren zu können, sehe ich schon eher ein. Aber auch da geht mein Bauchgefühl mehr in die Gegenrichtung, auch wenn ich nicht genau sagen kann wieso. Obwohl ich meine Haupt-Mailadresse erst zwei mal in meinem Leben gewechselt habe, kommen mir Mailadressen so flüchtig und anonym vor, von den Schwierigkeiten mit Klartext-Mailadressdaten im Web ganz zu schweigen. Wie würdet ihr das halten? Ich neige dazu, sie nicht mit anzugeben. Zum Glück bin ich nicht (mehr) besonders schwer im Web zu finden, von daher sollte das das kleinere Problem sein.

Übrigens enthält mein Deckblatt jetzt die schöne Formulierung „Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science. (B.Sc.)“. Das stand auf fast allen Vorlagen, die ich so gefunden habe, und verleiht der Unternehmung irgendwie so einen leicht gediegenen Anstrich. Außerdem bringt es noch mal den offiziellen Sinn und Zweck der Arbeit auf den Punkt. Ich hab's also mal mit aufgenommen.

Ausblick

Jetzt heißt es noch ein paar Tage aktiv sein, voraussichtlich noch bis einschließlich des Wochenendes. Danach soll das Ding endgültig stehen. Feedback von Axel kommt dann hoffentlich noch rechtzeitig, was evtl. noch mal kleinere Veränderungen nach sich zieht, allerdings mehr im Rahmen von einzelnen Formulierungen etc. statt komplett neuen Abschnitten – irgendwann ist ja auch mal Ende der Fahnenstange. Vielleicht gibt es auch noch kurzfristig Rückmeldungen von anderen Leuten, denen ich diese Version der Arbeit dann schicke, ein paar Interessensbekundungen sind ja doch zusammengekommen. Aber da rechne ich nicht mit irgendwelchen Wundern.

Konkret für den nächsten Bericht heißt das also: Dienstag kann ich erzählen, ob ich meinen Plan einhalten und alles schaffen konnte oder nicht. Wenn ja, dann kann ich evtl. etwas Inhaltliches über diesen letzten ausstehenden Abschnitt schreiben. Bis dann!

Willkommen zurück zum aktuellen Bachelorarbeits-Bericht, heute zur Abwechslung mal ein paar Stunden früher. Dieser wird vermutlich der viertletzte sein, da ich die Arbeit am 6. Dezember spätestens abgeben muss. Das schreit doch eigentlich nach einer neuen Zeitplanung. Aber vorher gibt es eine allgemeine Statusmeldung.

Erledigtes

In den letzten paar Tagen habe ich auf vier bis fünf Seiten (inkl. einiger Abbildungen) wie vor zwei Wochen angedeutet einen ausführlichen Teachlet-Ablauf dargestellt. Das sollte beim ersten Lesen vor allem Teachlet-Neulingen dabei helfen, eine Vorstellung vom Konzept zu bekommen. Dieser Punkt der Liste ist also abgehakt.

Die typische Rolle des Klassendiagramms in Teachlets habe ich jetzt auch besser erklärt, und zwar im Abschnitt über das Durchschnitts-Teachlet. Dort ergibt das in meinen Augen am meisten Sinn, da die Erarbeitung von Klassendiagrammen an der Tafel keine Teachlet-Vorschrift ist und nichts mit der Definition zu tun hat, sondern eher eine Tradition aus der Teachlet-Werkstatt ist.

Außerdem habe ich mir ein Beispiel für ein Teachlet ausgedacht, das ohne Ausgangssystem auskommt. Ich habe beschrieben, wie ein Teachlet zum Beobachtermuster aussehen könnte, in dem ein System in BlueJ von Grund auf entwickelt wird. Das Beispiel sind Kameras, die automatisiert einen Fußball verfolgen können – die Vorstellung fand ich ganz amüsant. Um den Code in den Anhang zu packen, konnte ich nun auch doch wieder meine Erfahrung mit Listings und PDF-Dateinanhängen in LaTeX gebrauchen.

Was Stilistisches und Kleinigkeiten angeht: Axel hatte ein paar Formulierungen angemerkt, die mir nicht so gut gelungen waren, die habe ich jetzt korrigiert. Im Glossar hatte ich die „Code-Inspektion“ vergessen, dieser Begriff wird nun auch erklärt. Außerdem habe ich noch ein altes Problem gelöst, das ich, glaube ich, vor langer Zeit hier schon mal erwähnt habe: In meinem großen Diagramm unterscheiden sich die Flächen bisher lediglich nach Farben, was das Ganze in einem schwarz/weiß-Ausdruck komplett unverständlich macht. Deshalb habe ich zusätzlich zu den Farben noch eine Schraffur eingeführt, die hoffentlich auch in einer graustufigen Welt eine Unterscheidung der Kategorien ermöglicht. Für Leute mit Farbsehschwäche ist das bestimmt auch nicht ganz verkehrt. Nebenbei bemerkt war das mit Inkscape deutlich (deutlich!) mehr Arbeit, als ich sinnvoll gefunden hätte. Gibt's hier Inkscape-Hacker, die dafür einen Weg kennen, der keine zwei Stunden dauert?

Das Dokument ist insgesamt auf 56 Seiten bei stolzen 820 KB angewachsen.

Vier Wochen verbleiben, was steht noch an?

Ich muss mich immer noch informieren, ob mein Deckblatt alle wichtigen Informationen enthält und die formalen Anforderungen erfüllt. Ich glaube, da gibt es nicht so das definitive Dokument – die Prüfungsordnung nennt wohl Daten, die draufstehen müssen, und es gibt Richtlinien für Seminararbeiten von SWT, die auch noch mal etwas dazu sagen. Das muss ich in der nächsten Zeit mal konsolidieren.

An möglichen inhaltlichen Punkten habe ich jetzt nur noch einen auf meinem Zettel:

• Teachlet-verwandte Methoden beschreiben: Am Ende der Arbeit werden einige Kernpunkte als für Teachlets unverzichtbar bewertet. Vielleicht lassen sich hieraus Ideen für Teachlet-ähnliche Vorgehensweisen finden, die ich dann kurz beleuchten könnte. Das sollte wohl möglich sein, auch wenn ich dazu wohl nicht mehrere Seiten schreiben werden – ist ja eigentlich irgendwie auch nicht mehr Teil meines Themas. Aber mal sehen.

Das könnte noch mal zu ein paar Seiten Text führen. Ich hoffe, ich kann das rechtzeitig schreiben und noch Feedback dazu bekommen.

Eine neue Zeitplanung

Unmittelbar vor dem Abgabetermin habe ich glücklicherweise ansonsten nicht viele speziellen Aufgaben in irgendwelchen Lehrveranstaltungen. Das sollte mir ausreichend Möglichkeit geben, in den letzten Tagen etwas Pufferzeit freizuhalten. Auf das ausführliche Korrekturlesenlassen muss ich leider möglicherweise verzichten, aber laut Aussage von Axel ist mein Text sprachlich auch weitgehend unproblematisch. Okay, da achte ich beim Schreiben auch schon mehr auf Kleinigkeiten als bei einem Blogeintrag wie diesem.

Wagen wir mal den Versuch einer Zeitplanung für den letzten Monat:

• von jetzt bis ca. 20. November: ausstehende Schreibarbeit
• danach bis 30. November: Feedback von Axel und ggf. von anderen Interessierten
• vom 1. bis zum 5. Dezember: Pufferzeit, Drucken und Binden
• 6. Dezember: Abgabe der Arbeit

Das klingt für mich ganz machbar. Ich muss mich zwar jetzt noch mal zusammenreißen, aber der Bachelor wird einem halt nicht geschenkt.

Ausblick

Nächste Woche um diese Zeit melde ich mich wieder mit dem Stand der restlichen Arbeit, die ich bis dahin geschafft habe. Ich bin selbst gespannt, wie gut das klappt. Wer Ende des Monats eine letzte Vorabversion zwecks Feedbacken haben möchte, kann sich gerne schon jetzt melden und wird dann berücksichtigt. Ansonsten bis nächsten Dienstag!

Dieser Bericht kommt etwas später als geplant, da ich gestern Abend recht lange unterwegs war. Wie bereits letzte Woche vermutet, gibt es allerdings auch nicht so viel zu erzählen. Wegen anderweitiger Verpflichtungen ist an der Arbeit seit letztem Dienstag nämlich noch nichts passiert, daher gibt es heute nur den Bericht zum Vortrag gestern.

Vortrag im Oberseminar

Die Wiederholung meines Kolloquiumsvortrags ist gut über die Bühne gegangen. Mit ein, zwei neuen Folien im Gepäck konnte ich dank der Diskussionsfreudigkeit der SWT-Belegschaft die 90 Minuten bequem mit einem 30-Minuten-Vortrag füllen. Dabei sind für mich keine nennenswerten neuen Erkenntnisse zustande gekommen, aber ich hatte den Eindruck, dass ich einigen Leuten einen guten Eindruck von Teachlets vermitteln konnte – auch wenn der Vortrag sicher nicht perfekt war.

Übrigens war der Laden relativ voll, obwohl ich dieses Mal deutlich weniger Werbung gemacht hatte. Man merkt doch, dass der Termin zugänglicher ist, wenn er nicht in der vorlesungsfreien Zeit liegt. Übrigens: Vielleicht wird es in den nächsten Tagen bei Tien ein, zwei Sätze aus Publikumsperspektive zu lesen geben.

Insgesamt habe ich den Vortrag als gelungen empfunden und bereue trotz Freiwilligkeit nicht, mir dafür etwas Zeit genommen zu haben.

Das war's schon wieder

Nächste Woche gibt es mit einiger Sicherheit neue Ergebnisse zur eigentlichen Arbeit. Trotz weiterer anstehender Vorträge sollte ich ab jetzt nämlich etwas mehr Zeit dafür haben als bis gestern. Bis dann!

Hallo und willkommen zu einem neuen Wochenbericht. Heute erzähle ich von meinem Gespräch mit Axel über die Möglichkeiten, die Arbeit noch zu verbessern. Entgegen meiner bisherigen Planung sind noch ein paar nicht ganz unaufwändige Punkte aufgetaucht, die Aufmerksamkeit bedürfen. Außerdem gibt's noch mal den Hinweis auf die Wiederholung meines Vortrags.

Neue Ziele

Am Freitag habe ich mich mit Axel zusammensetzen können. Er hat einigen Atem darauf verwendet, mir wiederholt zu versichern, dass er die Arbeit ohne Frage bereits für sehr gelungen hält. Trotzdem gibt es noch ein paar Dinge, die nicht perfekt sind:

• Der Einstieg könnte noch einfacher und anschaulicher sein. Ich erläutere die Idee recht abstrakt und starte dann gleich in die Begriffsklärung. Dies ließe sich noch sanfter gestalten, indem ich ein ausführliches Beispiel bespreche.
• Der konstruktive Teil der Arbeit (alles ab der Definition) ist evtl. noch ein bisschen zu mager. Die Begriffsbewertung ist eine gute Sache, könnte aber noch zusammen mit dem Kapitel über die Teachlet-Variationen weiter ausgestaltet werden: Es könnten noch Konstruktionen beschrieben werden, die nach der Begriffsbewertung keine Teachlets mehr sind, sondern lediglich ähnliche Lehrformen.
• Übergeordneter Punkt: Die Gesamtlänge ist für eine Bachelorarbeit einigermaßen streitbar. Axel bestätigt mir, dass die Arbeit bereits jetzt eine runde Sache ist und an sich inhaltlich nicht länger sein müsste. Diese Meinung würde allerdings potenziell nicht jeder teilen. Für die Bewertung etc. wäre es gut, wenn die Arbeit ein paar Seiten mehr hätte. Dies kann hoffentlich durch die vorherigen zwei Punkte erreicht werden.

Der Rest waren ein paar kleinere Punkte zu einzelnen Formulierungen.

Ich habe nun also doch noch so richtig etwas zu tun – nur noch kleine Korrekturen zu haben, war von mir wohl doch zu viel gehofft. Ich könnte natürlich die Arbeit in der jetzigen Form abgeben, ohne dass mir das das Genick bricht, aber ich mache ja nicht so gerne halbgare Sachen. Deshalb werde ich wohl doch noch mal etwas Zeit da reinstecken und ein paar Seiten Text produzieren. Etwas mehr als einen Monat habe ich ja noch.

Eine detaillierte Zeitplanung mache ich mir jetzt allerdings nicht. Für das neue Semester habe ich noch nicht so richtig meinen Rhythmus gefunden und kann noch nicht sagen, wann schematisch in meiner typischen Woche gute Zeitfenster liegen. Allzu viel Zeit habe ich nicht mehr, daher ergibt sich schon aus der Dringlichkeit, dass ich mich jetzt in meiner vorhandenen Freizeit darum kümmern werde.

Vortrag zur Bachelorarbeit

Nächsten Dienstag im SWT-Oberseminar (02. November, 16 Uhr, D-220) stelle ich meine Arbeit ein zweites Mal vor. Wer den ersten Vortrag verpasst hat oder eine leicht erweiterte Version sehen möchte, ist herzlich eingeladen. Die Idee eines kurzen Demo-Teachlets stand zwar im Raum, ich habe mich aber mangels Vorbereitungszeit dagegen entschieden. Stattdessen halte ich den bewährten Vortrag und gehe auf ein paar Einzelaspekte etwas genauer ein, die letztes Mal wegen der Beschränkung auf 30 Minuten zu kurz gekommen sind. Schließlich ist dieser Vortrag freiwillig und unbenotet, und irgendwo muss ich ja Prioritäten setzen.

Also: Ich hoffe ich sehe euch nächsten Dienstag in D-220!

Ausblick

Inwieweit ich bis Dienstag vorankomme, kann ich wegen eines anstehenden Wochenendseminars noch nicht sagen. Mit großen Fortschritten bis dahin rechne ich nicht. Es hängt ein bisschen vom Verlauf des morgigen Tages ab, wie gut ich die anstehenden sonstigen Aufgaben schaffe und ob noch etwas Zeit für die Bachelorarbeit bleibt. Auf jeden Fall gibt es aber nächsten Dienstag hier einen Eintrag. Bis dann!

Willkommen zurück zum sechzehnten Bericht über meine Bachelorarbeit. Heute fasse ich mich mal wieder vergleichsweise kurz. Ich erzähle etwas über die Ergebnisse der Feedbackphase (oder vielmehr: die Abwesenheit von Ergebnissen) und über die Wiederholung meines Vortrags.

Feedback einholen

Es ist immer toll, zur eigenen Arbeit konstruktives Feedback zu bekommen. Früher war ich, wie viele andere, eher unempfänglich für Kritik an meinen Projekten. Das hat sich inzwischen geändert, ich freue mich über jeden Verbesserungsvorschlag. Dabei macht sich bemerkbar, dass es gar nicht so einfach ist, Feedback zu bekommen. Im Gegenteil, ich bitte ständig um Feedback und bekomme nur sehr selten verwertbare Infos. So leider auch zu meiner Bachelorarbeit.

Ich habe eine gute Anzahl Leute angeschrieben und um Feedback zu einer Vorabversion meiner Arbeit gebeten. Zurückgemeldet haben sich davon eine Person schriftlich und zwei mündlich. Das Ergebnis für mich war die Korrektur eines einzelnen Grammatikfehlers sowie die Kenntnisnahme des unscharfen Eindrucks eines Lesers, der Text sei insgesamt zu kurz („für eine Bachelorarbeit“, schien mir die unausgesprochene Ergänzung zu sein). Inhaltliche Anmerkungen gab es keine.

Gebracht hat mir das also weniger als erhofft. Immerhin hat es sich als die richtige Entscheidung erwiesen, mit dem Feedback von Axel nicht bis jetzt zu warten. Das bekomme ich allerdings übrigens auch „erst“ Freitag – gelesen hat er die Arbeit wohl schon, kann aber erst Freitag eine Besprechung zeitlich unterbringen. Es ist der Beginn der Vorlesungszeit, das ist für einen vielbeschäftigten Dozenten sicher nicht weniger stressig als für mich – übelnehmen will ich ihm das dementsprechend überhaupt nicht. Dennoch lässt es mich an der Ausgestaltung der Vision einer iterativen Vorgehensweise mit kurzen Feedbackzyklen doch stark zweifeln. Im Moment habe ich noch keine Ahnung, was sich am Freitag bei dem Gespräch ergeben wird und ob ich noch viel schreiben muss in den nächsten Wochen. Ehrlichgesagt hoffe ich, dass es sich in Grenzen hält, da ich dieses Semester einen ganzen Batzen Seminarvorträge vorzubereiten habe (ich zähle gerade insgesamt fünf). Mal sehen.

Ergebnisbericht: Runde 2

Zum SWT-Oberseminar kann ich dieses Semester aufgrund parallel liegender Veranstaltungen zwar nicht ständig gehen, aber dennoch werde ich dort am 2. November noch mal meinen Vortrag in etwas ausführlicherer Form halten. Wer den ersten verpasst hat und ihn gerne hören möchte: Das wird wohl die letzte Chance sein.

Das Oberseminar findet dienstags um 16 Uhr in D-220 am Informatikum statt. Ich würde mich über zahlreiche Besucher auch diesmal sehr freuen!

Ausblick

Nächsten Dienstag gibt es – endlich – das Feedback-Ergebnis von Axel hier zu lesen. Ich weiß, ich verspreche es schon seit Wochen. Aber ich wüsste nicht, wie es dieses Mal noch schiefgehen sollte. Aus Art und Umfang des Feedbacks wird sich dann die weitere Planung ergeben. Also bis dann!

Diese Woche begrüße ich euch wieder mit einiger selbstverschuldeter Verspätung, dafür bitte ich um Entschuldigung. Hoffentlich konnte der letzte Blogeintrag zu einem etwas entspannteren Thema die Zeit überbrücken. Heute gibt es zunächst mal Infos zu den aktuellen Entwicklungen, was nicht viele sind. Danach gibt's ein paar Tipps, die ich wichtig finde und die mir evtl. geholfen hätten, wenn sie mir jemand vor einem halben Jahr gegeben hätte. Vielleicht ist ja etwas Nützliches dabei.

Aktuelles

Die Phase für offenes Feedback geht noch bis einschließlich übermorgen. Leider gibt es bisher keine Rückmeldungen, jetzt warte ich noch ab, ob sich kurz vor Ende noch jemand meldet. Axel hat zugesagt, die Arbeit Anfang nächster Woche noch mal mit mir zu besprechen. Ich bin gespannt, ob es noch viel zu verbessern gibt.

Danach folgt dann noch eine redaktionelle Phase. Wenn die inhaltliche Arbeit abgeschlossen ist, kümmere ich mich um Dinge wie die Korrektur von Tippfehlern, Verbesserungen von Formulierungen und einen ordentlichen Textsatz. Gerade bei letzterem nimmt LaTeX mir natürlich schon viel Arbeit ab, aber an einigen Stellen muss ich mit Sicherheit noch von Hand korrigieren.

Eine Bachelorarbeit zum Erfolg führen

Wahrscheinlich ist die interessanteste Frage für jemanden, der selbst bald eine Bachelorarbeit schreiben möchte, wie man sich den Aufwand gut einteilt und alles innerhalb der gesetzten Zeiträume schafft. Diese Fähigkeit wird ja niemandem in die Wiege gelegt. Zu hoffen ist, dass das während des Studiums schon mal im kleineren Rahmen (Proseminar, Seminar, Berichte zu Praktikum und Projekt etc.) geübt worden ist. Trotzdem möchte ich gerne ein paar Hinweise loswerden, wie ich die Arbeit angegangen bin und was mir geholfen hat, gut genug im Zeitplan zu bleiben.

Habe zu jedem Zeitpunkt einen aktuellen Zeitplan. Ich habe mir noch bevor das Thema feststand einen Kalender geschnappt und eingetragen, wann ich Zeit für die Bachelorarbeit habe und wann andere Termine sind, die in dem geplanten Zeitraum liegen. Außerdem habe ich mir schon überlegt, wann mir vom Studium her die „offiziellen“ drei Monate am besten in die Planung passen. Dass sich die Umstände später noch ändern und Termine sich verschieben können, stimmt natürlich, sollte aber nicht dazu führen, die Planung von vornherein komplett aufzugeben. Um Axel zu paraphrasieren: Einen Plan zu ändern ist das geringste Problem, wenn man erst mal einen Plan hat.

Sei flexibel, aber setze Prioritäten. Die Crux beim Zeitmanagement ist, dass normalerweise ständig neue Aufgaben und Termine dazukommen. „Nächste Woche habe ich mehr Zeit“ ist fast immer ein Trugschluss. Eine gewisse Dynamik ist in der Terminplanung nicht zu vermeiden, besonders, wenn man sich noch auf andere Leute einstellen muss. Dennoch muss jederzeit klar sein, wie wichtig dir der Fortschritt der Bachelorarbeit im Vergleich zu anderen Dingen ist. Da es sich um eine beachtliche Arbeitsleistung handelt, müssen mit Sicherheit irgendwo Abstriche gemacht werden. Bei mir war es so, dass ich im Sommer noch andere Aktivitäten hatte, die dazu geführt haben, dass der Start meiner Bachelorarbeit eher schleppend lief. Das Thema stand schon lange fest, aber ich habe kaum daran gearbeitet, weil es zunächst mal Dringenderes gab. Danach lief die Arbeit aber auch so richtig an und ich habe dann andere Dinge vorerst auf Eis legen müssen, was sich z.B. leider für die Informatik-OE bemerkbar gemacht hat. Vor allem im August und September war es dann so, dass ich die Bachelorarbeit als meine wichtigste Aufgabe gesehen habe und andere Dinge teilweise fallengelassen habe.

Suche und halte den Kontakt zu deinem Betreuer. Seine Aufgabe ist, dir alle nötigen Hilfeleistungen zu geben, um eine gute wissenschaftliche Arbeit schreiben zu können. Außerdem, machen wir uns nichts vor: Deine Betreuer werden die Note festlegen, die am allerwichtigsten für den Bachelor-Abschluss ist. Lass dich deshalb nicht mit halbgaren Auskünften und Vertröstungen abspeisen. Mit dem Erstbetreuer solltest du von Anfang an einen engen Kontakt pflegen und dir zu deinem Fortschritt regelmäßig Feedback holen. Manche Personen haben einen Hang zu der Vorstellung, wochenlang im stillen Kämmerlein an etwas Tollem zu arbeiten, um hinterher als Superheld mit der fertigen Wunder-Arbeit aufzutauchen. Manche Betreuer fördern diese Vorstellung, indem sie sich des kontinuierlichen Kontaktes entsagen um eigene Zeit zu sparen. Allerdings sagt die Erfahrung, dass der Standard-Bachelorarbeit-Schreiber damit auf die Nase fällt, weil es eben die erste „richtige“ wissenschaftliche Arbeit ist. Ich hatte zwischendurch immer wieder die Situation, dass ich nicht wusste, ob ich etwas richtig mache oder ob etwas so geht, wie ich mir das vorstelle. Genau für solche Fragen ist der Erstbetreuer da. Triff dich regelmäßig mit ihm, mindestens alle zwei bis drei Wochen, und halte zwischendurch Kontakt, z.B. per Mail. Bei jedem Treffen mit deinem Betreuer sollten, zusätzlich zum Inhaltlichen, auch die folgenden Fragen besprochen werden:

• Ist der Fortschritt seit dem letzten Treffen zufriedenstellend? Muss die Zeitplanung angepasst werden?
• Gibt es Verbesserungsmöglichkeiten für die Arbeitsweise?
• Klappt die Zusammenarbeit auch weiterhin? Sind Schreiber und Betreuer beide miteinander zufrieden oder gibt es Klärungsbedarf?

Falls jemand in das Thema tiefer einsteigen möchte: Axel hat dazu ein Paper veröffentlicht, das ich sehr empfehlenswert finde. Es ist so gedacht, dass man es mit dem Betreuer durchspricht und schaut, welche der Patterns man umsetzen möchte. Man kann es sich bei SWT herunterladen: Patterns for Supervising Thesis Projects (PDF)

Mache dich schlau über Formalia und den bürokratischen Prozess. Frage Studenten aus höheren Semestern aus, wie sie ihre Bachelorarbeit geschrieben haben (idealerweise findest du welche, die bei dem gleichen Betreuer waren wie du). Lies die Prüfungsordnung und die Fachspezifischen Bestimmungen, da stehen u.A. die Fristen und Regelungen drin. Informiere dich, wann du welchen Antrag und welches Protokoll wo abgeben musst. (Hint: Anmeldung der Arbeit mit Unterschrift von beiden Betreuern zu Beginn der Arbeitszeit, Protokoll des Kolloquiums mit deinen Daten vorausgefüllt zum Kolloquium, Abgabe der Arbeit wenn sie fertig ist mit den nötigen schriftlichen Erklärungen von dir.) Suche nach Richtlinien für Artikel und Seminararbeiten für den Arbeitsbereich deines Betreuers.

Motiviere dich, indem du Andere mitreißt. Überlege dir, wen deine Arbeit interessieren könnte, und beziehe diese Leute mit ein. Du musst sie alleine schreiben, aber das heißt nicht, dass Ideen und Feedback von möglichst vielen Seiten verboten wären – im Gegenteil. Mache dir Gedanken, wie du nebenbei anderen Leuten etwas Gutes tun kannst. Vielleicht schreibst du ja auch solche Berichte wie ich hier. Gerade in den trockeneren Phasen kam ein guter Teil meiner Motivation daher, dass ich meine Arbeit nicht nur für mich schreibe, sondern auch für alle Teachlet-Interessierten dieser Welt und für die dutzenden Leute, die diese Berichte mitlesen, weil sie sich für die Entstehung meiner Bachelorarbeit interessieren. Informiere dich über OpenAccess. Falsche Bescheidenheit ist kein guter Grund, deine Arbeit auf deiner Festplatte vergammeln zu lassen. Freier Zugang zu Wissenschaft verbessert die Welt, also mache deine Wissenschaft frei zugänglich.

Ausblick

Ein paar Tage heißt es noch „warten“, dann gibt's mindestens das Feedback von Axel und vielleicht noch mehr. Nächsten Dienstag werde ich die Feedback-Phase resümieren und erzählen, woran ich im Einzelnen noch arbeiten möchte. Womöglich gibt es dann auch mal wieder eine aktualisierte Zeitplanung. Bis nächsten Dienstag!

Heute gibt's mal wieder etwas völlig anderes. Ich möchte euch eine Idee zeigen, mit der ich vor einiger Zeit mal herumexperimentiert habe, die mit der Wahrnehmung von teilweise verdeckten Bildern zu tun hat. Die Idee stammt aus einem Video, das ich vor langer Zeit mal gesehen habe. Dort hat jemand diesen Effekt mit schwarzen Silhouetten erzeugt. An dieser Stelle bin ich mutig und versuche es direkt mit einem Farbbild, allerdings einem einfachen. Hier ist eine Spirale:

Für dieses Experiment brauchen wir ein leicht erfassbares, nicht zu detailliertes Bild. Dafür ist diese Spirale gut geeignet. Wir brauchen allerdings auch eine Bewegung im Bild, deshalb lassen wir die Spirale außerdem um ihren Ursprung rotieren:

Diese Animation besteht aus acht Einzelbildern, auf die wir weiter unten zurückkommen.

Nun hat das menschliche Gehirn über Millionen Jahre der Evolution die Fähigkeit entwickelt, auch teilweise verdeckte Formen und Objekte erkennen zu können. Wie das genau funktioniert ist nicht abschließend geklärt. Als Grund drängt sich die Vermutung auf, dass das Gehirn mit diesen internen Hilfen nicht den kompletten Input des Auges braucht und überlebenswichtige Erkennungsvorgänge auch z.B. im Dunkeln mit nur teilweise vorhandenen Bildinformationen funktionieren können. Der Effekt lässt sich auch gezielt hervorbringen um eine Form vorzutäuschen, die so gar nicht existiert, wie bei der berühmten Dreiecksillusion. Selbst wenn wir 7/8 der (unbewegten) Spirale verdecken, glauben wir weiterhin, eine Spirale zu sehen.

Unser Gehirn „sieht“ das Motiv weiterhin und verbindet die scheinbar verdeckten Kanten. Das funktioniert, obwohl der Informationsgehalt des Bildes (d.h. die Anzahl der zum Bild beitragenden Pixel) um 87,5% reduziert wurde!

Natürlich klappt das nicht mit jedem Motiv – im Gegenteil, bei den meisten aller möglichen Bilder funktioniert es zu schlecht, um vorzeigbar zu sein. Die „Komprimierung“ kommt dadurch zustande, dass der Betrachter die Lücken im Bild mit Informationen befüllen muss, die er bereits vorher besitzt. (Jeder weiß, wie eine Spirale aussieht, und tut dies unbewusst.) Bei unbekannten Bildern oder solchen mit vielen kleinen Details schlägt das Prinzip fehl.

Allerdings können wir mit unserer Spirale Folgendes tun: Wir können die Maske auf ein leeres, weißes Bild legen und nur durch die dünnen Lücken der Maske einige Streifen unseres Spiralbilds auftragen. Dann können wir die Maske um eine Spaltbreite nach links oder rechts verschieben, so dass die gerade platzierten Streifen gerade so verdeckt sind. Dann können wir durch die Lücken in der Maske auf die (nun wieder weißen) Streifen ein weiteres Bild auftragen. In diesem Beispiel beschränken wir uns darauf, dort die jeweils passenden Streifen des nächsten Einzelbilds der Animation einzufügen. Das Prinzip können wir dann munter fortführen und weitere sechs Teilbilder einfügen, bis wir wieder (um einen „Balken“ der Maske verschoben) beim Originalbild angekommen sind.

Wenn wir fertig sind, dann sieht das Bild unter der Maske ziemlich genau so aus:

Und jetzt der Clou: Wenn wir jetzt die Maske langsam nach links oder rechts bewegen, dann sieht es so aus als würde sich die Spirale drehen, obwohl nur ein einzelnes starres Bild unter der Maske liegt.

Es gibt keine Tricks oder doppelte Böden – das einzige, was sich in der obigen Animation bewegt, ist die Maske. Das darunterliegende Bild, das aus den Einzelbildern der Spiral-Animation zusammengesetzt ist, ist dabei völlig starr.

Wer mir das anhand der vorgefertigten Animation noch nicht glaubt, der darf auch gerne selbst mal damit herumspielen. Es folgt ein bisschen HTML/CSS-Code, die die Maske über das zusammengesetzte Bild legt, so dass sie per Scrollbalken bewegbar ist.

Was kann man mit dieser Idee anfangen? Ich hatte noch keine bahnbrechende Idee für Einsatzmöglichkeiten. Es klappt allerdings immerhin auch prima in ausgedruckter Form auf Papier, anders als GIF-Animationen. Vielleicht gibt es solche Motive irgendwann als Postkarten... Wie gesagt, es ist eine nette kleine Spielerei, finde ich.

Ein neuer Dienstag, ein neuer Wochenbericht. Willkommen zurück! Heute geht es in erster Linie um meinen gestrigen Kolloquiumsvortrag, aber auch sonst gibt es ein kurzes allgemeines Update.

Dreifaches Kolloquium

Gestern, am 4. Oktober, habe ich von 17:30 Uhr an in D-220 meinen Kolloquiumsvortrag gehalten. Der Termin hat sich ergeben, weil außer mir noch zwei Bachelor ihren Vortrag erledigen wollten (bzw. fristenbedingt mussten), die von Axel Schmolitzky und Horst Oberquelle betreut werden. Diese beiden Vorträge zu den Themen Agile Methoden vs. Softwarequalität und Konsumieren/Produzieren in BlueJ fand ich ziemlich interessant und lohnenswert – eigentlich schade, dass letztlich doch nicht so viele Besucher vor Ort waren. Jedenfalls war ich an dem Nachmittag mit meinem Vortrag der Letzte. Jeder von uns sollte ca. 30 Minuten vortragen und 15 Minuten Fragen beantworten und sich der Diskussion stellen, was wir auch recht genau eingehalten haben.

Mein Vortrag ist gut gelaufen. Das Einschätzen, wie viel Inhalt ich in einer bestimmten Zeit schaffe, klappt inzwischen doch ziemlich gut. Ich hatte mir an meinen ausgedruckten Foliensatz zwar auch noch ein paar Zeitmarkierungen gemacht, im „Eifer des Gefechts“ habe ich die dann allerdings doch wieder komplett ignoriert. Man sagte mir hinterher, ich hätte etwas länger als eine halbe Stunde geredet, also wohl etwas um die 35 Minuten. Damit kann ich gut leben und eingeschlafen ist auch niemand.

Jetzt warte ich also auf die Benotung des Vortrags. Axel hat schon durchblicken lassen, dass meine Darbietung wohl auch aus Gutachtersicht recht zufriedenstellend war. Vermutlich werden er und Horst Oberquelle diese Tage den Protokollbogen ausfüllen und abgeben, so dass die Teilnote irgendwann in unserem allseits geschätzten Campus-Management-System auftaucht.

Übrigens: Wer den Vortrag verpasst hat, der bekommt noch eine zweite Chance. Ich werde ihn voraussichtlich in einer der ersten Vorlesungswochen im SWT-Oberseminar (Dienstag ab 16 Uhr) noch ein weiteres mal in etwas größerem Umfang halten. Sobald es ein Datum gibt, kündige ich das natürlich wieder hier an.

Zweck einer Definition

Während des Vortrags wurde ich durch eine Zwischenfrage aus dem Publikum auf eine interessante Diskrepanz aufmerksam gemacht, die ich gerne mit euch teilen möchte: Beim Brainstorming wurde die Choreographie als wichtig, aber nicht unverzichtbar deklariert. Trotzdem taucht sie in meiner aktualisierten Definition auf und wird dort als Teil der Dokumentation eines Teachlets genannt. Wie erklärt sich dieser Widerspruch? Auf den ersten Blick scheint es so, als müsste entweder die Begriffsbewertung oder die Definition fehlerhaft sein. Es gibt dafür jedoch eine sinnvolle und, wie ich hoffe, nachvollziehbare Erklärung.

Die Bewertung des Begriffs ergibt sich aus einer ausschließlich pragmatischen, reduktionistischen und ergebnisorientierten Sicht auf die Wichtigkeit der Aspekte. In diesem Sinne haben wir die Choreographie als nicht unverzichtbar bewertet, da es durchaus möglich ist, ein Teachlet durchzuführen, ohne eine genaue Choreographie geplant zu haben. Es ist mit Sicherheit nicht empfehlenswert und es bringt einige Schwierigkeiten mit sich, zum Beispiel wird sich die Gesamtdauer nicht abschätzen lassen und im schlimmsten Fall den angepeilten Zeitslot weit überschreiten. Aber: Es ist möglich. Man kann die durchgeplante Choreographie weglassen und man hat immer noch ein Teachlet. Das ist die eine Perspektive.

Die Definition ist zwar aus den zentralen Begriffen zusammengebaut, aber sie hat noch einen tieferen Sinn: Die Definition ist das, was einem Teachlet-Neuling das Konzept als erstes näherbringen soll. Sie soll jemandem, der über das Thema nichts weiß, einen zielführenden, umfassenden und zugleich prägnanten Eindruck davon verschaffen, was ein Teachlet ist. In diesem Sinne hat sie eine normative Funktion. Sie soll in erster Linie klar darstellen, wie ein Teachlet auszusehen hat – und erst in zweiter Linie, was es sich alles erlauben kann, um gerade eben so als Teachlet bezeichnet werden zu können. Das ist die andere Perspektive.

Stellen wir uns eine Schwarzwälder Kirschtorte vor. Lecker! Zu einer solchen Torte gehören, jedenfalls in meinen Augen, nebst Schichtungen, Sahne, Kirschen und Schokoteig auch unbedingt die Schokoraspeln obendrauf, die beim Draufbeißen so richtig Spaß machen. Was tue ich, wenn ich eine Schwarzwälder Kirschtorte machen möchte und keine Schokoraspeln habe? Die Supermärkte haben zu und es gibt keine Möglichkeit mehr, welche zu organisieren? Klar, ich mache meine Torte eben ausnahmsweise ohne Schokoraspeln. Vielleicht nehme ich stattdessen die billigen Schokostreusel. Niemand wird ernsthaft behaupten, dass das, was da entsteht, keine Schwarzwälder Kirschtorte sei – der leckere Teig, die Sahne, die Kirschen... klar ist das eine Schwarzwälder Kirschtorte. Vielleicht nicht die leckerste von allen, aber immerhin. Aber wenn mich jemand fragt, wie man Schwarzwälder Kirschtorte macht? Dann sind Schokoraspeln selbstverständlich eine der wichtigsten Zutaten! Sie gehören so zum typischen Aussehen, Gefühl und Geschmack der Schwarzwälder Kirschtorte, dass sie unbedingt als zentraler Bestandteil im Rezept stehen. (Experimente mit Schokostreuseln sind nicht zur Nachahmung empfohlen.)

Hoffentlich ist hierdurch klar geworden, wie ich diesen Unterschied zwischen der Begriffsbewertung und der Formulierung der Definition begründe. Vielen Dank an Lorna für diese wunderbare Frage!

Feedback-Status

Ende letzter Woche habe ich meine Feedback-Gesuchs-Mail verschickt. Die Zeitplanung hat sich in dem Zuge etwas verändert, weil ich beim Schreiben realisiert habe, dass eine Woche eigentlich irgendwie doch gar nicht so viel Zeit dafür ist. Ich habe den Leuten deshalb zwei Wochen (bis zum 15. Oktober) Zeit gegeben.

Leider zieht das nach sich, dass ich mit dem Feedback von Axel nicht bis hinterher warten kann, da er mit Beginn der Vorlesungszeit am 18. Oktober wieder Lehrveranstaltungen durchführen wird und keine Zusagen für Betreuungsleistungen in den ersten Semesterwochen machen möchte, was ich gut verstehen kann. Deshalb wird Axel sein Feedback jetzt doch schon auf Basis der ersten Iteration der Arbeit abgeben. Da ich nicht weiß, ob sich von den anderen Leuten überhaupt jemand meldet (bisher gibt es keine Rückmeldungen), ist das wahrscheinlich kein Problem. Aufgrund der ungewissen Wartezeit für mich ändert sich dadurch am geplanten Veröffentlichungszeitpunkt im Bereich der ersten Novemberhälfte (hoffentlich) nichts weiter.

Ausblick

Jetzt habe ich so unmittelbar im Moment für meine Bachelorarbeit gerade nichts zu tun. Es kann also sein, dass bis nächste Woche nicht viel passiert – einen Wochenbericht wird es aber mit Sicherheit trotzdem geben, zur Not plaudere ich wie angekündigt noch mal aus dem Nähkästchen und reflektiere ein wenig den Ablauf der Entstehung der Arbeit. Bis dann!

Willkommen zum letzten Wochenbericht zur Iteration 1 meiner Bachelorarbeit. Um nicht lange um den heißen Brei zu reden: Seit gestern Abend betrachte ich sie erstmalig als fertig! Das heißt: Alle Kapitel sind geschrieben, es gibt keine Lücken mehr im Manuskript. Das heißt dagegen nicht, dass es nichts mehr zu verbessern gibt.

Im Moment fühle ich mich erleichtert, dass die Arbeit jetzt auf diesem Stand ist verschafft mir etwas Entspannung. Ich bin sogar ein paar Tage vor meinem Zeitplan, der eine Fertigstellung der Arbeit eigentlich erst für übermorgen vorgesehen hat.

Momentan mache ich mir am meisten Sorgen wegen der sprichwörtlichen Betriebsblindheit. Ich habe den Text meiner Bachelorarbeit in den letzten Wochen und Monaten so oft gelesen, dass ich ihn inzwischen gar nicht mehr lesen kann – ich überspringe ständig ganze Absätze, weil ich sie noch auswendig kann. Das macht es mir sehr schwer, kritisch draufzugucken. Das würde ich eigentlich gerne, weil ich die Kapitel ja in einer völlig anderen Reihenfolge geschrieben habe, als sie jetzt in der Arbeit stehen. Das ist natürlich ein Nährboden für Abfolgefehler und implizite Vorwärtsbezüge. Leider muss ich mindestens noch ein paar Tage (wenn nicht Wochen) warten, bis ich den Text wieder „richtig“ lesen kann.

Was passiert jetzt?

Ein Blick auf die Zeitplanung im letzten Bericht verrät, dass die nächsten Punkte die Feedback-Woche vom 1. bis zum 8. Oktober sowie der Kolloquiumsvortrag am 4. Oktober sind. Auf den Vortrag werde ich mich quasi ab jetzt vorbereiten und ein paar Folien entwerfen. Nächsten Montag findet er statt. Falls du dabei sein möchtest, ist also jetzt deine letzte Chance, mir das mitzuteilen.

Die Feedback-Woche beginnt kommenden Freitag. An dem Tag werde ich die dann aktuelle Version der Arbeit (kann sein, dass ich bis dahin noch Kleinigkeiten korrigiere) an einigermaßen viele Leute verschicken. Dabei habe ich mich für den Ansatz entschieden, eine Mail an alle zu schicken, die irgendwann mal in irgendeiner Form Interesse bekundet haben, und denen freizustellen, ob sie sich das Teil anschauen und mir Rückmeldung geben möchten. Vielleicht bekomme ich ein paar Rückmeldungen, vielleicht nicht. Sofern ich welche bekomme, arbeite ich sie ab dem 8. Oktober ein. Danach geht's dann weiter mit dem Feedback von Axel, für den Rest siehe die Planung im letzten Bericht.

Natürlich kannst du immer noch Interesse an der Arbeit bekunden und mit einer Vorabversion versehen werden, wenn du möchtest. Melde dich dafür einfach bei mir.

Fortlauf dieser Berichte

Mit der Beendigung der Kernarbeitsphase ist die Zeit dieser wöchentlichen Berichte noch nicht beendet. Mein Ziel ist, sie bis zur endgültigen Abgabe der Arbeit weiter fortzuführen. In den zukünftigen Berichten werde ich dann abgesehen vom aktuellen Stand der Feedbackzyklen vor allem weitere Reflektionen des Prozesses vornehmen. Vielleicht fallen dabei noch ein paar Tipps und Hinweise für zukünftige Autoren von Abschlussarbeiten raus, mal sehen. Ich weiß es selbst noch nicht so genau.

Für dieses Mal gibt es nichts mehr mit denken (sorry, ich brauche eine kleine Pause), daher hier ein bisschen nutzloses Wissen:

Meine Arbeit ist derzeit inklusive Deckblatt, Inhaltsverzeichnis und Anhang insgesamt 47 A4-Seiten lang. Die PDF-Datei ist exakt 666886 Bytes groß. (Sollte mir das zu denken geben?) Von den 47 Seiten fallen 18 auf meinen Kerntext. Weitere 24 umfassen die Interview-Protokolle. Eine Seite wird von einem E-Mail-Bericht im Anhang eingenommen, eine weitere von der einzigen, einsamen Abbildung in der Arbeit. Hinzu kommen nur noch Deckblatt, Inhalts- und Literaturverzeichnis.

Nach der Konvertierung in Plaintext und automatischer Zählung besteht die Arbeit derzeit aus 17730 Wörtern inklusive Anhang und 6126 ohne. Gar nicht mal so viel eigentlich. Das LaTeX-Hauptdokument ist 1178 Zeilen lang, darin sind allerdings die Interviews nicht enthalten. Von diesen 1178 Zeilen sind 36 Kommentare. Von den Kommentaren sind 7 (also weniger als 20%) „richtige“ Kommentare, der Rest sind auskommentierte Codezeilen. Gut, dass mein LaTeX normalerweise keine nennenswerte Code-Komplexität hat.

Hier eine Liste der am häufigsten verwendeten Wörter und ihrer Anzahl in meinem Kerntext, abzüglich Artikeln, Präpositionen, Partikeln und anderem langweiligen Kram: Teachlets (84), Teilnehmer (60), Teachlet (49), Moderator (39), Software (31), Teilnehmern (29), Definition (26)

Ausblick

Nächsten Dienstag erzähle ich euch vom Kolloquiumsvortrag und vom Verlauf der Feedback-Woche bis dahin. Ich bin gespannt, wie das beides so klappt. Bis dann!

Nachtrag: Eben habe ich die Mail für das Feedback versendet. Beim Schreiben ist mir erst aufgefallen, dass eine Woche doch irgendwie verdammt kurz ist. Deshalb habe ich die Feedback-Woche spontan auf zwei Wochen verlängert. Mal sehen, ob ich Antworten bekomme.

Es ist Dienstag und es gibt einen ganzen Batzen Neuigkeiten bezogen auf meine Planung für die nächsten Wochen. Inhaltlich gibt es diese Woche also nicht so viel zu lesen. Kurzes Statusupdate: Das Kapitel 5 ist beinahe komplett fertig, es fehlen noch Kapitel 3 und 6 (beide nicht so schwierig) sowie der Bezug zu ähnlichen Methoden. Um euch nicht mit unnötigen Details zu langweilen kommt jetzt der Fahrplan für die Zielgerade.

Planung für die kommenden Wochen

Heute ist der 21. September.

• 1. Oktober: Die Arbeit soll bis dahin fertig geschrieben sein, d.h. ich will alle Kapitel in einer grundsätzlich vorzeigbaren Form vorliegen haben. Iteration 1.
• 1. bis 8. Oktober: Offene Feedback-Woche, in der ich die soweit fertige Arbeit an möglichst viele Leute verteilen möchte, um ggf. ein wenig Feedback zu bekommen. Wichtige Infos hierzu weiter unten! (Für mich sind hoffentlich ein paar Tage Urlaub drin.)
• 4. Oktober: Mein Kolloquiumsvortrag. Wichtige Infos hierzu weiter unten!
• 8. bis 11. Oktober: In dieser Zeit möchte ich das hoffentlich erhaltene Feedback in den Text einarbeiten.
• 12. Oktober: Die fertige und reflektierte Arbeit (Iteration 2) geht zwecks detailliertem Feedback an Axel, meinen Erstbetreuer.
• sobald Axel mir sein Feedback liefert: Auch das wird eingearbeitet.
• danach: Korrekturlesen (und korrekturlesen lassen) des gesamten Textes, drucken und binden.
• Wahrscheinlich Ende Oktober: Offizielle Einreichung der endgültig fertigen Arbeit (Iteration 3) beim Prüfungsamt. Veröffentlichung hier unter CC-BY-SA.

Feedback-Woche

In der ersten Oktoberwoche möchte ich am liebsten, dass Iteration 1 meiner Arbeit schon ein bisschen unter die Leute kommt. Meine ganz eigennützige Motivation dazu ist, dass ich hoffe, ein wenig Feedback zu bekommen. Das heißt allerdings nicht, dass ich den Text nur an Leute rausrücke, die mir Feedback versprechen. Hast du evtl. Lust einen Blick in meine Bachelorarbeit zu werfen, bevor ich sie abgebe? Ist ganz unverbindlich und ich sitze dir nicht mit Feedback-Anfragen im Nacken, versprochen. Wir einigen uns nur darauf, dass du mir bescheid gibst, falls dir irgendetwas auffällt, was ich noch verbessern kann. Wenn nicht dann nicht. Deal? Dann meld dich bei mir.

Warum mache ich das Feedback von Axel erst ganz am Ende und isoliert? Nun, weil Axel sich das so gewünscht hat. Er meint, das sei für das Betreuerfeedback so üblich, und mir ist's gleich.

Kolloquiumsvortrag am 4.10. um 17:30 Uhr

Am 4. Oktober (das ist ein Montag, der vorletzte vor Vorlesungsbeginn und somit der letzte vor der OE-Woche) um 17:30 Uhr wird mein Kolloquiumsvortrag stattfinden, der 10% der Note meiner Bachelorarbeit ausmacht. Ich werde da innerhalb von 30 Minuten versuchen, den Inhalt meiner Arbeit darzustellen. Danach folgt eine Q&A-Phase, in der ich mich dem Fragen-Bombardement des akademischen Establishments stellen möchte und beweisen möchte, dass mein Thema kein Quatsch ist. Dazu möchte ich dich ganz herzlich einladen! Das ist die Gelegenheit, mir endlich all die Fragen zu Teachlets zu stellen, die sich bei dir aufgestaut haben. Natürlich reflektiere ich mit dir auch gerne den Prozess des Schreibens oder die Methode dieser Blogeinträge. Du kannst aber auch einfach dazukommen, zuhören und Kekse essen.

Wenn du zu meinem Kolloquiumsvortrag kommen möchtest, sag mir möglichst bald bescheid! (!!!) Das ist wirklich wichtig, weil ich bisher nur mit einer Publikumsgröße von 4 Leuten rechne. Also sag mir bescheid, falls du kommst, damit ich dafür sorgen kann, dass der Raum ausreichend Sitzplätze bietet! Außerdem muss ich ja wissen, wie viele Kekse ich ungefähr mitbringen soll. Also keine Scheu. Schreib mir am besten einen Kommentar direkt hier zu diesem Eintrag. Ich hab Lust auf ein bisschen Publikum.

Übrigens sind direkt vorher noch zwei Kolloquiumsvorträge von Kommilitonen. Ich weiß aber nicht, ob die auch gerne noch mehr Leute dabei haben wollen, deswegen mache ich da mal lieber keine direkte Werbung.

Fazit

Ich glaube, die Message für diese Woche ist klar, oder? Kommt alle zu meinem Vortrag und bringt eure Freunde mit. Nächsten Dienstag gibt's einen Bericht vom letzten großen Schreib-Marathon. Bis dann!

Man könnte fast denken, mein Blog wäre nur noch für meine Bachelorarbeit da. Das soll natürlich nicht so sein, deshalb mache ich heute zwischendurch mal ein komplett anderes, informatikfremdes Fass auf, nämlich Musik. Ich weiß zwar nicht, ob es euch interessiert, aber wenn nicht, dann werd ich's ja merken... und jeder kann sich ja auch selbst entscheiden, diesen Eintrag mal zu überspringen. Aber dass ein neues Album meiner Lieblingsband ansteht, ist doch ein guter Anlass für ein bisschen Werbung, oder?

Am ersten Oktober, also in zwei Wochen, soll es nämlich soweit sein: Das neue Album „Heilig“ der Band Letzte Instanz erscheint und ich freu mich darauf wie auf Weihnachten. Wer mich persönlich kennt, hat vielleicht schon bemerkt, dass ich manchmal – recht selten – Band-Shirts trage. Und wenn es nicht gerade mal das mit dem „Nord Nord Ost“-Covermotiv von Subway to Sally ist (was mir inzwischen ohnehin viel zu groß ist), ist es eigentlich immer eins meiner vielen Letzte-Instanz-Shirts. Ich hab ja einen einigermaßen breit gefächerten Musikgschmack, rede ich mir jedenfalls ein. Aber diese Band steht seit 2006 konsequent an meiner ganz persönlichen Spitze.

Die Letzte Instanz gibt es schon ziemlich lange, sie haben aber auch viele Besetzungswechsel und damit verbunden einen starken Stilwandel hinter sich. Wem die Alben ab 2006 gefallen, dem gefallen nicht unbedingt die bis 2004 und umgekehrt. Ich finde den alten Kram auch ganz nett und hab die eine oder andere Silberscheibe aus der Zeit hier, aber musikalisch halte ich die für weniger ausgereift. Was macht die Letzte Instanz heute für Musik? Ich würde es als Gothic-beeinflussten Alternative Rock bezeichnen. Durch die übliche Rock-Besetzung mit Sänger, Gitarren, Bass und Schlagzeug hat das Ganze ordentlich wumms, durch die zusätzlichen Streicher (Geige und Cello) bekommt es eine leicht symphonische, orchestrale Note. Die Texte sind meist deutschsprachig und haben sich seit dem Sängerwechsel von Gesellschaftskritik weg und zu Philosophie und Poesie hin entwickelt, wovon jeder halten mag, was er möchte.

Nun gibt es also bald ein neues Album. Hier eine Liste der gerade verfügbaren Kostproben:

• Bei jpc (wahlweise auch Sony Music, sind die gleichen Schnipsel) gibt es Hörproben zum gesamten Album. Im Moment freue ich mich am meisten auf Unsterblich und Eismeer, aber das fluktuiert.
• Auf der Webseite der Band gibt es das Video zur Single-Entkopplung Schau in mein Gesicht.
• Bei Amazon gibt es den Track Dein Gott zum kostenlosen Download als MP3.

Ich bin übrigens kein großer Fan des Covermotivs, weshalb ich es hier auch nicht abbilde. Ingo Römling kann super zeichnen, aber das Motiv finde ich etwas zu abgedroschen und zu sehr das Klischee bedienend. Immerhin ist es etwas besser als das vorherige.

Am 2. November ist die Band hier in Hamburg, im Grünspan. Ich bin dann auf jeden Fall da. Noch jemand Interesse?

Kennt ihr evtl. noch mehr Bands, die Musik dieser Art machen? Ich kenne noch eine handvoll Rockbands, die auch mit Streichinstrumenten arbeiten, aber keine, die das so gut zusammenbringt. Gibt es (abgesehen von Chamber und Apocalyptica) weitere Bands, bei denen die Streicher gut zur Geltung kommen? Würde mich sehr über weitere Tipps freuen.

Der reguläre Dienstagsbericht fällt heute eher kurz aus. Den letzten habe ich letzten Freitag erst online gestellt. Seitdem ist aus folgendem Grund nicht sehr viel passiert: Wegen Erschöpfungserscheinungen habe ich mir mal wieder ein freies Wochenende gegönnt, hab meine Familie besucht und mich ein bisschen ausgeruht. Gestern Vormittag sind die ausstehenden Interviews mit Carola Lilienthal und Christian Späh über die Bühne gegangen. Mit dem Transkribieren der Interviews bin ich zu zwei Dritteln fertig, dazu weiter unten mehr.

Ablauf und Ergebnisse der Interviews

Carola und Christian sind (im Gegensatz zu Axel) Externe, die an meiner Arbeit nicht bzw. kaum beteiligt sind. Dadurch sind sie beide thematisch weniger voreingenommen. Das gilt für Carola noch mehr als für Christian, da dieser zumindest beim Brainstorming-Treffen im Sommer dabei war und eine ungefähre Ahnung hat, worum es mir geht.

Beide Interviews haben in den Büros der jeweiligen interviewten Person stattgefunden. Das mit Carola hat knapp 20, das mit Christian knapp 30 Minuten gedauert. Ich habe beide mit meinem Laptop aufgenommen, was ausreichend gut funktioniert hat. Den Leitfaden hatte ich nach dem Interview mit Axel noch geringfügig angepasst:

1. Welche Erfahrungen mit dem Teachlet-Konzept hast du bereits gesammelt?
2. Wie hast du Teachlets erlebt im Vergleich mit anderen Lehrformen, die du kennst?
3. Welche Vorteile siehst du an ihnen? Wo lassen sich Teachlets sehr gut einsetzen?
4. Wo siehst du Grenzen des Konzepts? Wo würdest du Teachlets auf keinen Fall einsetzen?
5. Hast du Hinweise für zukünftige Teachlet-Moderatoren? Was ist noch kein etabliertes Wissen, sollte aber auf jeden Fall bedacht werden?

Insgesamt haben beide auf die Fragen sehr gut und ausführlich reagieren können und es ist einiges an wertvollen Impulsen zusammengekommen. Einige Antworten waren grundverschieden, andere unerwartet einheitlich. Das Interview mit Axel war bereits fertig abgetippt, das mit Carola inzwischen ebenfalls. Das mit Christian habe ich noch nicht geschafft, aber das sollte morgen klappen. Danach werde ich allen dreien die Protokolle zukommen lassen, damit sie ihr OK für die Veröffentlichung geben können. Gibt's Interesse, die vorab zu sehen? Dann würde ich die schon mal hochladen, wenn es soweit ist. Ansonsten gibt es sie zusammen mit dem Rest der Arbeit nächsten Monat.

Übrigens: Das Protokoll des Interviews mit Axel hat etwas über 4300 Wörter, das von dem mit Carola ungefähr 2700.

Ausblick

Das war's auch schon wieder für diesen Bericht. Ich mag mich nicht festlegen, wann der nächste kommt, aber dann gibt's wieder Neuigkeiten zu den Kapiteln, versprochen. Also bis dann!

Heute gibt es einen Bericht zwischendurch, weil es sich schon wieder lohnt. Es gibt das Glossar, das ich für die Arbeit geschrieben habe – da können endlich auch mal die Leute mitreden, die von Teachlets bisher gar keine Ahung haben. Außerdem gibt es Neuigkeiten vom Studienbüro wegen der Master-Zulassung.

Begriffsverzeichnis

Die folgende Liste von Begriffen stammt eins zu eins aus dem aktuellen Entwurf meiner Bachelorarbeit. Ich stelle es hier komplett rein, weil es nicht zu lang ist und weil ich hoffe, dass ihr mich auf Probleme aufmerksam machen könnt. Sind die Begriffe gut genug erklärt? Wo gibt es noch Unklarheiten? Gibt es weitere Begriffe, die vielleicht irgendwann mal hier auf dem Blog aufgetaucht sind und zu denen ihr euch eine Erklärung wünschen würdet?

• Ausgangssystem:
  Eine lauffähige, aber auf eine ganz bestimmte Weise defizitäre Software. In der Regel ist diese speziell für ein Teachlet entworfen, so dass durch die erfolgreiche praktische Anwendung des Lernziels des Teachlets (z.B. ein bestimmtes objektorientiertes Entwurfsmuster) das genannte Defizit der Software im Laufe der Teachlet-Einheit von den Teilnehmern behoben werden kann.
• Autor:
  Zu einem Teachlet gehören einer oder mehrere Autoren, die das Teachlet erstmalig konzipiert und dokumentiert haben. Normalerweise ist der Autor gleichzeitig der Moderator bei der ersten Aufführung eines Teachlets. Ein Moderator kann allerdings auch Teachlets von anderen Autoren aufführen.
• Choreographie:
  Eine zeitliche Planung für Aufführungen eines bestimmten Teachlets, die den Ablauf und zeitliche Grenzen für einzelne Abschnitte festlegt.
• Ergebnissystem:
  Die Software, wie sie in einer Teachlet-Einheit von den Teilnehmern aus dem Ausgangssystem entwickelt wird. Das Ergebnissystem ist der Teachlet-Einheit zuzordnen und entsteht bei jeder Aufführung des Teachlets erneut. Anders als das Zielsystem ist das Ergebnissystem nicht in jedem Fall vollständig und fehlerfrei.
• Lernziel:
  Jedes Teachlet hat ein Lernziel. Häufig ist das ein objektorientiertes Entwurfsmuster, es kommen aber auch z.B. Programmiersprachkonzepte und Umsetzungen von Algorithmen in Frage. Innerhalb einer Teachlet-Einheit sollen die Teilnehmer das Lernziel sowohl theoretisch erfahren als auch praktisch auf das Ausgangssystem anwenden.
• Moderator:
  Eine Teachlet-Einheit wird von einem oder mehreren Moderatoren angeleitet. Diese müssen mit dem Teachlet und seinem Lernziel sehr gut vertraut sein, um die Teilnehmer erfolgreich und innerhalb des zeitlichen Rahmens durch die Choreographie zu lenken, ohne ihm mehr Freiräume zu nehmen als nötig.
• Teachlet:
  
  1. Ein auf Interaktivität ausgelegtes Lehrkonzept, das im vorigen Abschnitt sowie in Kapitel 4 genauer definiert wird.
  2. Eine weitgehend statische Sammlung aller Dokumente und Software, die es ermöglichen, zu einem bestimmten Thema eine Teachlet-Einheit zu halten, die vom Autor bzw. von den Autoren dieses Teachlets konzipiert wurde. Es wird empfohlen[Sch05], für jedes Teachlet eine Versionsnummer zu vergeben, anhand der erkennbar ist, wie oft und wie stark dieses Teachlet bereits überarbeitet wurde.
• Teachlet-Einheit:
  Eine konkrete Durchführung eines Teachlets in einer bestimmten Lehreinheit. Auch: Teachlet-Aufführung
• Teachlet-Werkstatt:
  Eine Teachlet-Werkstatt ist „eine seminarartige Semesterveranstaltung, in der die Teilnehmer neue Teachlets ausarbeiten. Jeder Teilnehmer muss sich dazu mit mindestens einem Lernziel befassen und für dieses Lernziel ein Teachlet entwerfen. Die neuen Teachlets werden an den Teilnehmern der Werkstatt selbst ausprobiert und anschließend von den Teilnehmern analysiert und bewertet.“ ([Sch05]) In Teachlet-Werkstätten wird also der Schwerpunkt auf Feedback zu den neu erstellten Teachlets gelegt. Zu diesem Zweck werden dort meist auch Tracker eingesetzt.
• Teilnehmer:
  Zu einer Teachlet-Einheit gehören mindestens einer, typischerweise mehrere Teilnehmer. Die Teilnehmer sitzen im Plenum und gestalten den vom Moderator vorgegebenen Rahmen durch Wortmeldungen und Diskussionen. In der Regel lassen sich bei einer Teachlet-Einheit sowohl aktive als auch passive Teilnehmer beobachten. Aktive Teilnehmer äußern verstärkt ihre Meinung und vertreten ihre Position, während passive Teilnehmer weitgehend ausschließlich zuhören.
• Tracker:
  Eine Rolle, der vor allem in der Teachlet-Werkstatt eine wichtige Bedeutung zukommt. Der Tracker stammt aus dem Kreis der Teilnehmer und hat die Aufgabe, ein Zeitprotokoll des Teachlets zu erstellen, anhand dessen der Moderator hinterher die Praxistauglichkeit der Choreographie überprüfen kann. Dazu schreibt der Tracker mit, zu welcher Uhrzeit die verschiedenen Phasen des Teachlets beginnen und enden.
• Zielsystem:
  Eine Version der betrachteten Software, in der das Lernziel korrekt umgesetzt wurde. Das Zielsystem wird normalerweise vom Autor des Teachlets erstellt und wird als Notlösung verwendet, falls die Implementierung den Teilnehmern nicht innerhalb der Zeit gelingt.

Zulassung zum Informatik-Masterstudium

Alle, die es betrifft, haben die Mail bestimmt schon gelesen: Wir haben dieses Jahr doch noch mal Glück und haben theoretisch Zeit bis zum 1.4., um alles abzuliefern. Nicht, dass ich davon übermäßigen Gebrauch machen möchte... aber zumindest heißt das, dass der 4. Oktober als Termin für den Vortrag zu der Arbeit unproblematisch ist und dass ich mich nicht ganz so hetzen muss wie befürchtet. Also: Den 4.10. freihalten, wenn ihr den Vortrag hören möchtet.

Am Rande: Gestern ist mir per Post die Kopie der Anmeldung der Arbeit mit Unterschrift des Prüfungsausschussvorsitzenden zugegangen. Ganz offiziell habe ich Zeit bis zum 6. Dezember. Aber keine Angst, spätestens Anfang/Mitte Oktober werde ich fertig.

Kapitel-Status

Eigentlich hatte ich vor, euch mit einer erneuten Gliederung zu verschonen, da nur ein paar neue Unterkapitel dazugekommen sind. Dann dachte ich mir aber, dass es vielleicht spannend ist, eine Übersicht über geschriebene und ausstehende Kapitel zu bekommen. Deshalb kommt jetzt noch mal eine aktuelle Gliederung, in der die noch zu schreibenden Kapitel fett dargestellt sind.

1. Einführung
   • Ziele dieser Arbeit
2. Die Teachlet-Idee
   • Begriffsklärung
   • Abgrenzung von ähnlichen Methoden
3. Bisherige Teachlet-Praxis
   • Berichte von Moderatoren
4. Definition
   • Die ursprüngliche Definition und ihre Grenzen
   • Aktualisierte Definition
5. Grenzen und Möglichkeiten
   • Das Durchschnitts-Teachlet
   • Ausschlusskriterien und Grenzen (gerade dabei)
   • Varianten und Möglichkeiten
6. Fazit
   • Ausblick

Es geht, wie ihr seht, ganz gut voran. Freut euch auf die Interview-Berichte am Dienstag!

Die meisten Entscheidungen, die ich in der Planung und Durchführung meiner Bachelorarbeit bisher getroffen habe, gingen mir nicht leicht von der Hand. Ich bin jemand, der gewisse Schwierigkeiten hat, sich zwischen mehreren tragbaren Alternativen zu unterscheiden. Manchmal neige ich dazu, wie der Esel zwischen den zwei Heuhaufen zu stehen, weil alle vorhandenen Möglichkeiten irgendwie Vor- und Nachteile haben und ich mich nicht durchringen kann, nur eine davon zu wählen. Da ist es immer eine angenehme und erfreuliche Abwechslung, wenn ich denke: Dieses hier ist echt klar und unbestritten besser als jenes; wenn eine Entscheidung mal so richtig leicht fällt.

Gestern ist mir das passiert.

Gliederung (die III.)

Bis gestern hatte ich an der Gliederung immer nur mit dem Gedanken gearbeitet, wie sie insgesamt aussehen müsste und wie so etwas üblicherweise ausgestaltet wird. Ich habe mich an vorhandenen Arbeiten und Tipps von verschiedenen Webseiten orientiert. Das war insgesamt wenig zufriedenstellend und wirkte (meinen Betreuer paraphrasierend) ein wenig unscharf und durcheinander.

Beim Schreiben der geplanten Kapitel und mit dem Feedback zu meiner Gliederung im Kopf hatte ich einen spontanten Einfall. Was wäre, wenn ich mich von Konventionen und Gesamtvorstellungen komplett lösen würde und eine Gliederung einzig nach der Frage aufbauen würde, zwischen welchen Kapiteln ich Rückbeziehungen aufbauen will. Offensichtlichstes Beispiel: Um an der Teachlet-Definition zu kritisieren und zu argumentieren, möchte ich mich auf die Teachlet-Praxis und die Berichte der Moderatoren beziehen. Deshalb ist es wahrscheinlich sinnvoll, diese bereits vor der Definition einzuordnen.

Mit diesem Ansatz haben meine Kapitel dann sehr schnell zusammengepasst wie ein Puzzle. Hier der aktuelle Stand der Gliederung:

1. Einführung
   • Ziele dieser Arbeit
2. Die Teachlet-Idee
   • Begriffsklärung
   • Abgrenzung von ähnlichen Methoden
3. Bisherige Teachlet-Praxis
   • Berichte von Moderatoren
4. Definition
   • Die ursprüngliche Definition und ihre Grenzen
   • Aktualisierte Definition
5. Grenzen und Möglichkeiten
6. Fazit

Wie ihr seht, habe ich außerdem ein paar Kapitel noch mal umbenannt. Was gestern noch „Planspiel“ hieß, heißt jetzt nach Rücksprache mit Axel Grenzen und Möglichkeiten. Das bringt den Darstellungsgegenstand des Kapitels ganz gut zum Ausdruck. Wahrscheinlich wird das Kapitel noch weiter unterteilt, wenn es soweit ist.

Insgesamt fühle ich mich mit dieser Gliederung sehr wohl. Sie fühlt sich schlüssig an und entspricht sogar der Schablone „Erst analytisch, dann konstruktiv“, die in meinem Fall das vierte Kapitel in der Mitte durchtrennt. Dieses ist zu Anfang noch analytisch, leitet dann aber in den konstruktiven Teil über.

Axel bestätigt meine Euphorie und bezeichnet diese Gliederung als sehr viel gelungener als die vorherige, was mich natürlich wiederum weiter bestärkt. Ab diesem Punkt rechne ich eigentlich nur noch mit kleinen Änderungen.

Was lernen wir daraus? Tu nicht das, was andere machen – tu das, was für dich Sinn ergibt.

Bericht vom Interviewnachmittag

Heute waren die Interviewtermine mit Axel und Carola.

Das Interview mit Axel lief sehr gut. Wir haben das direkt in seinem Büro durchgeführt und mit meinem Laptop aufgezeichnet. Ich hab hier eine OGG/Vorbis-Datei, die ca. 35 Minuten Interview enthält und jetzt transkribiert werden möchte. Wie es der Zufall will hab ich dank meines Linguistik-Wahlfachs vom Transkribieren sogar ein bisschen Ahnung. Allerdings werde ich voraussichtlich keine HIAT-Transkription wie in meinem Linguistikseminar erstellen, sondern „nur“ eine approximative Verschriftlichung ohne „ähm“s und andere Füllwörter sowie mit einer Prise künstlerischer Freiheit bei der Interpunktion. Ich werd's mal ausprobieren und dann sehen, wie gut es funktioniert. Kennt jemand eine brauchbare Speech-To-Text-Software?

Inhaltlich hat Axel viele gute und hilfreiche Aspekte genannt. Vieles wusste ich natürlich schon, aber es ist sicher auch nicht zu unterschätzen, es jetzt in einer Form zu haben, in der ich mich darauf beziehen und daraus zitieren kann. Dadurch kann ich die Arbeit hoffentlich weniger subjektiv schreiben und muss mich nicht so viel auf meine unbelegbaren eigenen Erinnerungen und Erfahrungen beziehen.

Das Transkript des Interviews schicke ich nach der Erstellung zurück an Axel, damit er noch mal drüberschauen kann, ob irgendwas vor der Veröffentlichung gekürzt werden muss. Danach stelle ich es hier online. Ob ich's unter eine CC-Lizenz stellen darf, muss ich ihn auch noch fragen.

Das Interview mit Carola ist bedauerlicherweise ausgefallen. Auf dem Weg zum Informatikum stand sie leider recht lange im Stau, so dass die Zeit bis zu ihrem nächsten Termin nicht mehr reichte. Wir haben einen neuen Termin am nächsten Montag um 9 Uhr ausgemacht, also beinahe direkt vor dem Interview mit Christian. Das verkürzt zwar meine verbleibende Zeit für die Auswertung um fast eine Woche, aber bis dahin habe ich wohl auch so noch genug zu tun.

Ausblick

Abgesehen von der Transkribierung des Interviews mit Axel sind meine nächsten Baustellen die Kapitel 1.1, 2.1, 2.2 und 5. Die ersten beiden davon sollten nicht sehr lange dauern, das ist nur ein wenig Schreibarbeit.

Die Abgrenzung von ähnlichen Methoden erfordert vor allem noch Literaturrecherche, um diese ähnlichen Methoden erst mal zu finden, wobei ich bisher leider wenig Erfolg hatte. Die Bücher zur Didaktik der Informatik und speziell der Softwaretechnik, die mir bisher untergekommen sind, beschäftigen sich entweder mit dem Dasein als Informatiklehrer und der Planung eines monatelangen Curriculums oder mit Konzepten der Hochschullehre, die so direkt mit Teachlets auch nichts weiter zu tun haben. Im Moment blättere ich da so durch und hoffe auf einen Glückstreffer, aber ich bin mir auch nicht sicher, ob ich an den richtigen Stellen suche. Da muss ich auch mal gucken, ob sich da noch etwas ergibt oder wen ich da noch um Hilfe bitten kann.

Die Grenzen und Möglichkeiten sind das große Kapitel zu Zukunftsvisionen und Gedankenexperimenten. Da habe ich bisher nur die grobe Idee, die Definition stückweise auf ihre Flexibilität zu untersuchen, also inwieweit man mit den elementaren Bestandteilen vielleicht doch noch „spielen“ kann und wie neuartige Teachlets aussehen könnten. Das ist ein Kapitel, dem jetzt eigentlich nichts mehr im Wege steht, aber ich muss sagen, dass ich doch enorme Ehrfurcht davor habe. Nichtsdestotrotz muss ich mich eher bald als irgendwann mal da heranwagen. Ich werd's nach den einfachen Teilen mal versuchen und schauen, was bis nächste Woche klappt.

Spätestens nächsten Dienstag gibt es also den Bericht von den zwei ausstehenden Interviews. Zwischendurch halte ich euch weiter auf dem Laufenden hinsichtlich was ich gerade so schreibe, wie weit ich bin und ob es noch neue Entwicklungen gibt. Bis spätestens nächsten Dienstag!

Die Ereignisse überschlagen sich, es geht jetzt in einem Wahnsinnstempo voran. Muss es ja auch, wenn ich alles bis Ende des Monats schaffen will... aber nach den letzten Gesprächen mit Axel bin ich da vorsichtig optimistisch. Mit einem bisschen Disziplin und Glück wird das was.

Ich habe überlegt, ob ich auch das Tempo bzw. die Frequenz dieser Berichte steigern soll. Diese Woche bietet es sich wegen der vielen neuen Informationen an. Ich halte es mal so: Jeden Dienstag Abend gibt es wie gehabt auf jeden Fall einen Bericht. Dazwischen gibt es evtl. weitere, wenn der Neuigkeitenfluss es rechtfertigt. Wie sich das die nächsten vier Wochen noch so entwickelt, sehen wir dann.

Überarbeitete Gliederung

Auf der Basis eurer Kommentare und dem Feedback von Axel habe ich die Gliederung noch mal grundlegend überarbeitet. Hier die aktuelle Version:

1. Einführung
2. Die Teachlet-Idee
   • Abgrenzung von ähnlichen Methoden
3. Definition
   • Die ursprüngliche Definition und ihre Grenzen
   • Aktualisierte Definition
4. Bisherige Teachlet-Praxis
   • Berichte von Moderatoren
5. (Planspiel)
6. Zusammenfassung

Die Teachlet-Idee ist jetzt ein eigenes Kapitel und nicht mehr unterhalb der Einführung. Die Abgrenzung ist neu hinzugekommen. Das Definitionskapitel bleibt gleich, darauf folgt das Kapitel zur bisherigen Durchführung von Teachlets und den Berichten aus den Interviews. Für Kapitel 5 ist mir noch kein guter Titel eingefallen. In dem Kapitel soll es um die Frage gehen, was passiert, wenn man einzelne „essenzielle“ Teile der neuen Definition (z.B. die Entwurfsdiskussion oder die lauffähige Software) komplett weglässt und ob sich die Einheit dann noch „Teachlet“ nennen kann. Ein solches strittiges Beispiel wäre das iPhone-Teachlet aus Bericht 6, in dem es keine Entwurfsdiskussion in dem Sinne gab, wie sie in einem Teachlet normalerweise üblich und gefordert ist. Trotzdem stimmen alle Beteiligten zu, dass die Veranstaltung sich an den, naja, Teachlet-Spirit gehalten hat und als Teachlet zu zählen ist. Das Kapitel gleicht von daher einem Gedankenexperiment, das weiterführend dabei helfen soll, das Teachlet-Konzept einzugrenzen und vorstellbar zu machen.

Außerdem habe ich versucht, in dieser zweiten Gliederung den folgenden Kritikpunkten zu begegnen:

• Die fehlende Abgrenzung von ähnlichen Methoden wurde explizit aufgenommen.
• Der aktuelle Stand und die aktuelle Praxis werden vor den Zukunftsvisionen abgehandelt und nicht andersherum. Das Kapitel zur Definition bildet hierbei eine Ausnahme, da es mir sinnvoll erscheint, die neue Definition direkt an die alte anzuschließen und nicht den restlichen Hauptteil der Arbeit dazwischen zu drängen.
• Die Kapitelüberschriften sind nicht mehr als Fragen formuliert. Das entspricht so hoffentlich schon eher gängigen Konventionen.

Natürlich ist die Gliederung noch immer nicht in Stein gemeißelt. Wahrscheinlich wird bis zum Ende der Arbeit noch viel daran passieren.

Interviews

Drei Interview-Termine stehen fest:

• Di, 07.09., ab 14 Uhr, Axel Schmolitzky
• Di, 07.09., ab 16 Uhr, Carola Lilienthal
• Mo, 13.09., ab 11 Uhr, Christian Späh

Davon abgesehen habe ich eine kurze schriftliche Rückmeldung zum Thema von Kai Meyer. Ich bin gespannt, wie die Interviews so laufen und was sich dabei ergibt. Übrigens habe ich mich gegen weitere empirische Mittel (Fragebögen etc.) entschieden, da ich hoffe, durch den Interviewteil alles Wichtige klären zu können und sich der Aufwand meiner Ansicht nach für mich nicht lohnt.

Für die Aufnahme werde ich dann direkt meinen Laptop benutzen (trotzdem danke für das Angebot, vollkorn!).

Ausblick

Wenn ich schnell bin, dann könnt ihr Dienstag Abend vielleicht schon ein paar Ergebnisse von den Interviews lesen. Mindestens gibt es einen kurzen Bericht von mir, wie sie gelaufen sind. Außerdem ist mein Ziel, über das Wochenende und den Montag mindestens das Kapitel 3 zu schreiben, nachdem die Einleitung und das Kapitel zur Teachlet-Idee (noch ohne Abgrenzung) bereits existieren und auf Feedback von Axel warten.

Als Termin für den Kolloquiumsvortrag kristallisiert sich übrigens gerade der 4.10. heraus, aber noch ohne Gewähr. Wer den Ergebnisvortrag hören möchte, kann sich den Nachmittag des 4. Oktobers ja vielleicht schon mal freihalten. Eine richtige Einladung wird es auch noch geben, sobald der Termin festgeklopft ist und ich die Bestätigung habe, dass er keine Master-Immatrikulationsfristen oder so verletzt...

Es ist wieder Dienstag Abend und ich melde mich mit dem derzeitigen Status zurück. Für alle, die es evtl. verpasst haben: Letzten Samstag gab es außerhalb des Rhythmus einen Sonderbericht zum Organisatorischen. Zu den Interviews gibt es leider noch nichts Neues, stattdessen möchte ich euch heute meinen Entwurf einer Gliederung präsentieren.

Gliederung

Für den Aufbau einer wissenschaftlichen Arbeit gibt es bekanntermaßen einige Konventionen. So wird zumeist (nach einer Einleitung) eine Theorie aufgestellt, dann Experimente beschrieben und ausgewertet und zuletzt die Theorie damit widerlegt oder untermauert. Bei eher konzeptuellen Arbeiten – wie meiner – steht am Anfang eher eine Definition, die dann im Einzelnen untersucht und, wenn möglich, ausprobiert wird.

In diesem Sinne habe ich hier einen Vorschlag zur Gliederung meiner Arbeit. Die Bezeichnungen und Formulierungen sind nicht final und werden nur teilweise den Kapitelüberschriften entsprechen, aber ich hoffe man kann so erkennen, was in welcher Reihenfolge vorkommen soll:

• Einleitung
  • Die Teachlet-Idee
• Definition
  • Definition gemäß [Schmolitzky2005] und ihre Grenzen
  • Aktualisierte Definition
• Welche Formen können Teachlets annehmen?
  • Beispiele für außergewöhnliche Teachlets
• Wie wurden Teachlets bisher durchgeführt?
  • Berichte von Teachlet-Moderatoren
• Was sind vielversprechende neue Ideen?
• Was macht ein Teachlet zu einem guten Teachlet?
• Zusammenfassung

Im Lichte der aktuellen Entwicklung (aber auch sonst) sollte ich anfangen, Fließtext zu Papier, d.h. zu Tastatur, zu bringen. Man sagt ja, man schreibt zuerst die Einleitung, dann schreibt man den Rest der Arbeit, und dann schreibt man die Einleitung noch mal neu. In dem Sinne werde ich wohl mit der Einleitung und dem Kapitel zur Definition (die ja bereits überarbeitet worden ist) beginnen.

Wie immer gilt: Ich wünsche mir Feedback zur Gliederung. Wenn ihr Schwachstellen seht oder etwas besser fändet, wenn es anders gelöst wird, immer raus damit.

Partizipation

Was mich außerdem von euch interessieren würde: Inwieweit möchtet ihr diese Fließtexte in ihrer Entstehung verfolgen? Das Herumformulieren an so einer Einleitung stelle ich mir z.B. eher langweilig zu beobachten vor. Gibt es Interesse daran, hier Vorabversionen der Kapitel zu lesen? Wer von euch würde mir dann auch Feedback dazu geben? Oder ist das eher etwas, was ich mir direkt sparen kann? Eure Meinung interessiert mich.

Übrigens: Ich protokolliere keine IPs und habe keine Besucherstatistik. Allerdings bin ich inzwischen von so vielen von euch angesprochen worden („Hey, du bist doch der mit dem Blog und der Bachelorarbeit!“), dass ich weiß, dass ihr da seid. Axel, mein Betreuer, begegnet meinen Experimenten mit der Öffentlichkeit mit einer Prise gesunder Skepsis. Also wenn ihr mich dazu motivieren möchtet, mir mit meinen Berichten weiterhin Mühe zu geben, dann schreibt doch gerne einen kurzen Kommentar. Nicht jeder davon muss mich inhaltlich weiterbringen, auch über ein „Hey, ich lese jede Woche mit und finde es total cool“ würde ich mich freuen. Also wer sich noch nicht aufgerafft hat: Das Kommentarfeld beißt nicht, es geht alles ohne Account und Registrieren und Mailadresse und solchen Mist. Seit Neuestem gibt es sogar eine kleine Formatierungshilfe unter dem Kommentarfeld, aber das nur ganz am Rande. Also: Immer her mit den Kommentaren!

Ausblick

Bis nächsten Dienstag werde ich irgendwas wegen der Interviews geklärt haben. Entweder es stehen ein paar Termine, oder die Sache fällt flach. Da ich aber einfach mal präventiv für den nächsten Monat alles andere abgesagt habe, bin ich eigentlich guter Dinge. Ich muss die Leute also nur noch erreichen.

In meiner Planung ist außer den Interviews keine weitere Datenerhebung vorgesehen. Das heißt, der Rest ist kreatives Schreiben. Bis nächste Woche werfe ich also LaTeX an und schreibe mir die Finger wund. Bis dann!

Willkommen zurück zu meinem Bachelorarbeits-Bericht, heute mal außerhalb der Reihe aufgrund aktueller Entwicklungen im organisatorischen Bereich. Schnallt euch an, es wird turbulent.

Anmeldung und Fristen

Die gute Nachricht vorweg: Für die Anmeldung der Bachelorarbeit gibt es ein Formular (PDF), das Erst- und Zweitbetreuer unterschreiben müssen. Mit der Abgabe dieses Formulars beginnt die offizielle Bearbeitungszeit von drei Monaten. Dieses Formular habe ich seit gestern vollständig ausgefüllt und unterschrieben hier, so dass ich es gleich Montag abgeben kann, um meine Arbeit offiziell anzumelden. Alles, was ich bisher gemacht habe, wird dementsprechend rückwirkend als Vorbereitung und Einarbeitung in das Thema definiert. Soweit super.

Für das kommende Wintersemester habe ich auch schon meine Zulassung für den Masterstudiengang Informatik. Das heißt, dass neben der regulären Frist von drei Monaten Bearbeitungszeit für mich potenziell weitere Fristen greifen, wenn ich diesen Platz wahrnehmen möchte. Eigentlich soll man dafür ja schon bei der Bewerbung einen fertigen Bachelor vorweisen, tut wahrscheinlich kaum jemand. Stattdessen geht auch eine Planung, die sagt, dass man es wahrscheinlich schafft. So war es auch bei mir. Meine letzte Studienleistung ist die Bachelorarbeit, mit der ich ja diesen Herbst fertig werden will. Seinerzeit hab ich dann mal nachgeschaut, was es dazu so zu wissen gibt.

Ich hab hier so ein Dokument namens „Bewerbung für den Masterstudiengang Informatik“ auf der Platte, von dem ich nicht mehr weiß, woher ich es habe. Jedenfalls hab ich's im Juli als Anleitung für die Bewerbungsunterlagen benutzt. Dort heißt es:

Bewerbungen ohne Zeugnis des ersten Hochschulabschlusses sind möglich, sofern dieses Zeugnis bis Ende Dezember (bei der Bewerbung zum Wintersemester) bzw. Ende Juni (bei der Bewerbung zum Sommersemester) nachgereicht wird.

Ende Dezember, okay. Klingt ja halbwegs bequem. Natürlich ist Bachelorarbeit nicht gleich Bachelorzeugnis, aber bis Dezember wollte ich ja lange fertig sein – vor Vorlesungsbeginn schon, wenn es irgendwie geht. Es wäre also noch reichlich Zeit, auf die Gutachten zu warten. Soweit mein bisheriger Stand.

Nun höre ich von einem Kommilitonen, dass bereits zum 30.9. eine Bescheinigung des Erstbetreuers vorliegen muss, nach der eine 4,0 sicher ist. Das heißt, dass meine Arbeit bis dahin soweit fertig sein müsste, dass man sie irgendwie Bachelorarbeit nennen kann. Danach könnte ich dann noch den Feinschliff machen. Okay, klingt komisch, aber würde mich nicht weiter stören.

Also frage ich im Studienbüro nach. Dort sagt man mir, die Bachelorarbeit müsse bereits am 30.9. fertig sein und dem Prüfungsamt vorliegen. Bitte was? Ein Blick auf die Webseite, sieht nicht besser aus:

Für eine endgültige Zulassung zum Masterstudium muss Ihr Bachelorzeugnis dann aber bis spätestens 2 Wochen vor Beginn der Lehrveranstaltungen nachgereicht werden.

LV-Beginn wäre dieses Jahr der 18. Oktober, Stichtag also der 4.10., was keinen nenneswerten Unterschied macht. (Okay, vielleicht fürs Drucken und Binden noch mal ganz nett.) Aber wiederum ist hier ja sogar vom Zeugnis die Rede.

Und was jetzt?

Schaffe ich es, bis Ende September etwas zusammenzuschnipseln, wofür Axel bereit wäre, mir eine 4 zu geben? Wahrscheinlich. Bleiben dabei wichtige Aspekte auf der Strecke und die Arbeit unvollendet? Wahrscheinlich. Ärgere ich mich hinterher, wenn ich eine Bachelorarbeit einreiche, die weit unter meinen Möglichkeiten liegt? Sehr wahrscheinlich!

Mein präferierter Weg ist jetzt erst einmal, mich richtig ins Zeug zu legen und zu gucken, was irgendwie geht. Falls das nicht reicht, habe ich die Wahl, eine suboptimale Arbeit abzugeben und meine Note zu gefährden, oder meinen Masterplatz zu verlieren und damit ein Semester später anzufangen.

Was sagt ihr? Weiß jemand Genaueres über die Fristen, ist da noch etwas rauszuhandeln? Was würdet ihr machen?

Heute gibt es das versprochene Überraschungsthema: Im Rahmen des heute stattgefundenen iPhone Power Days wurde von Kai Meyer (einem Mitarbeiter der C1 WPS) ein Teachlet zum Thema „MapKit-Einbindung auf dem iPhone“ im Hörsaal ESA B vor ca. 100 Personen gehalten. Wir hatten uns aufgrund eines Tipps von Axel vorher kurzgeschlossen und ich habe mit ihm darüber gesprochen, was ein Teachlet-Moderator so zu beachten hat, was ich davon halte ein Teachlet mit einer so großen Teilnehmerzahl durchzuführen und wie ein solches Teachlet zu gestalten wäre.

Heute habe ich mich dann mit in den Hörsaal gesetzt und die Rolle des Trackers übernommen – ich habe also ein detailliertes Protokoll über den zeitlichen Verlauf angefertigt. In der Teachlet-Werkstatt soll dieses Protokoll den Teachlet-Entwicklern dazu dienen, die Choreographie zu überarbeiten und an die Realität anzupassen. In diesem Kontext hat mich vor allem interessiert, wie flüssig ein Vorlesungssaal-Teachlet funktionieren kann.

Angepeilt waren wohl 60 Minuten, gedauert hat es dann allerdings nur 45. Hier der Ablauf:

Kai Meyer, 24.08.2010, ESA B – iPhone Power Day

17:02 Begrüßung
17:04 Teachlet-Konzept Kurzerklärung

17:05 Ausgangssystem beschreiben
17:07 Aufgabe
17:08 Was ist MKMapView
17:09 Klassendiagramm Zielvorstellung

17:11 Ausgangssystem betrachten

17:12 Implementation beginnen
  :13 Button zum Interface hinzufügen
  :15 Action definieren
  :16 Action und Button verknüpfen
  :18 Methode als Dummy implementieren
  :19 Debugging
  :21 MapView hinzufügen
  :23 User Location anzeigen lassen
  :24 neuen UIViwController anlegen
  :25 Controller und Map verknüpfen
  :27 Controller aktivieren
  :28 Testlauf
  :31 MapType und Titel ändern

17:32 Aufgabe wurde erfüllt
17:33 vorbereitetes Zielsystem zeigen

17:34 Koordinatenübergabe zeigen
17:35 Automatischen Zoom zeigen
17:37 Zusammenfassung
17:39 Fragerunde
17:45 Ende

Gegenüber dem klassischen Teachlet hatte dieses ein paar Besonderheiten, die es für mich besonders spannend machen. Vor allem passiert es selten, dass ein Teachlet vor einem so großen Teilnehmerkreis gehalten wird. Damit geht vor allem einher, dass keine Entwurfdiskussion wie in einer seminarartigen Teachlet-Einheit stattfinden kann, weil erstens zu viele Leute anwesend sind, als das alle zu Wort kommen könnten, und weil zweitens die Akustik eine Diskussion zwischen einer kleineren Anzahl der Teilnehmer unmöglich macht. In diesem Fall hatte der Moderator ein Mikrofon, um bis in die hintersten Ränge verständlich zu sein. Aus dem Kreis der Teilnehmer (ich ertappe mich immer wieder dabei, „Publikum“ schreiben zu wollen) konnten nur kurze Zurufe erfolgen.

Was in meinen Augen unerwartet gut funktioniert hat, war, den Teilnehmern die Abfolge der Implementierung zu überlassen. Der Moderator hat die Teilnehmer komplett offen gefragt, was gemacht werden soll, und konnte dann jeden Zuruf direkt umsetzen. Die für Teachlets typische Federführung der Teilnehmer bei der Implementation ließ sich ohne große Schwierigkeiten auch hier umsetzen. Eine mögliche Einschränkung ist allerdings, dass die Zielgruppe keine fortgeschrittenen iPhone-Programmierer waren und die Teilnehmer vermutlich jeweils kaum eine andere Lösung kannten als die angepeilte.

Im Kontext und für die Zielsetzung denke ich, dass die Einheit klar gelungen ist. Die Frage, die für mich aber die größere Relevanz hat, ist die, ob es sich dabei auch wirklich um ein Teachlet im Sinne der revidierten Definition handelt.

Teachlet-Definition 2.0.1

Hier ist die Definition von vor zwei Wochen, in die ich außerdem die Korrekturen aus euren Kommentaren (mit noch kleinen Veränderungen von mir) eingepflegt habe:

Ein Teachlet ist eine sehr interaktive Lehreinheit, in der ein lauffähiges Stück Software so verändert wird, dass es eine klar definierte Aufgabenstellung erfüllt. Diese ist so gewählt, dass durch die Veränderung ein klar definiertes Lernziel erreicht werden kann. Ein Moderator motiviert das Ausgangssystem sowie die vorzunehmende Veränderung in einer mit den Teilnehmern gemeinsamen Sicht (etwa am Beamer) und lässt sich dann von den Teilnehmern anleiten, die dazu notwendigen Änderungsschritte an der Software vorzunehmen. Für die Lösung der Aufgabe soll ein Lösungsraum mit mehreren möglichen Varianten hinsichtlich der Architektur existieren, um eine Entwurfsdiskussion zu ermöglichen. Der Moderator hat dabei die Aufgabe, die Diskussion zu lenken, Zwischenergebnisse festzuhalten und eine Einigung über eine Zielsetzung für die Implementation herbeizuführen. Nach der gemeinsamen Implementierungsphase erfüllt die Software idealerweise die zuvor gestellte Aufgabe. Zu einem Teachlet gehört weiterhin eine Dokumentation, die für die Vorbereitung relevante Unterlagen wie eine detaillierte Choreographie und ein ausimplementiertes Zielsystem enthält.

Haben wir heute also ein Teachlet erlebt?

Kai Meyers Veranstaltung war sehr interaktiv und es wurde von den Teilnehmern Software verändert (programmiert). Eine klar definierte Aufgabenstellung wurde gegeben (ein MapView in die bestehende Software einbauen), die zu einem klar definierten Lernziel führte (die Einfachheit der MapKit-API kennen zu lernen). Gearbeitet wurde am Beamer und die Teilnehmer haben die Änderungsschritte gelenkt (durch Zurufen). Beim Lösungsraum ist es etwas hakelig... im Wesentlichen stand eine einzige Lösung im Raum, weil die Teilnehmer nicht genug Erfahrung hatten, um auf eine andere zu kommen. Prinzipiell wären aber auch andere Lösungen möglich gewesen und in der Definition steht auch nur ein „soll“ und kein „muss“ – von daher habe ich kein schlechtes Gefühl dabei, das durchgehen zu lassen. Der Moderator hat seine Aufgaben gut erfüllt, die Zielsetzung wurde erreicht (die Karte hat funktioniert). Inwieweit zu dem Teachlet eine ausführliche Dokumentation existiert, weiß ich jetzt nicht.

Fazit: Es zeichnet sich recht deutlich ab, dass die heute durchgeführte Ausprägung des Konzepts immer noch ein Teachlet ist, das lediglich in einigen Hinsichten unüblich ausgestaltet war. Funktioniert hat es, wie gesagt, trotzdem ziemlich gut.

Ausblick

Für nächste Woche erhoffe ich mir Neuigkeiten in Bezug auf die Interviews und vielleicht zum Organisatorischen. Morgen spreche ich noch mal mit Axel über den bisherigen Fortschritt und die nächsten Schritte. Spätestens am Dienstag erfahrt ihr dann hier, wie es weitergeht.

Diese Woche mache ich einen kleinen thematischen Sprung von der Teachlet-Definition zurück zu meiner Empirie. Vor ein paar Wochen habe ich bereits ein mal erwähnt, dass ich gerne Interviews führen möchte, um mehr „Futter“ für meine Arbeit zu sammeln. Heute möchte ich euch erklären, wie ich darauf gekommen bin, welche Methodik ich anwenden möchte und was ich damit erreichen will.

Arten von Interviews

Die Sozialforschung kennt eine beachtliche Vielzahl an Formen und Standards für Interviews. Für meine Herangehensweise sind vor allem die verschiedenen Arten von Leitfadeninterviews (im Gegensatz zu standardisierten Interviews) interessant, da diese im Vergleich eher offen strukturiert sind und während des Interviews das freie Erzählen des Befragten erlauben und sogar fördern, so dass Themen zur Sprache kommen können, die bei der Erstellung des Fragenkatalogs noch nicht erahnt werden konnten.

Sehr stark vereinfacht (Methodik-Puristen bitte kurz weghören) könnte man sagen: Bei Leitfadeninterviews müssen nicht alle Fragen im Vorfeld auf dem Papier stehen. Außerdem hofft der Leitfadeninterviewer tendenziell nicht auf möglichst kurze und präzise, sondern auf möglichst lange und ausführliche Antworten. Keine zwei Leitfadeninterviews sind identisch.

Das problemzentrierte Interview

Die Leitfadeninterviews sind dann weiter unterteilt. Nachdem ich mir einen groben Überblick verschafft habe, tendiere ich dazu, mich an der Herangehensweise des problemzentrierten Interviews zu orientieren (Zitat Wikipedia):

Das problemzentrierte Interview (engl.: problem-centeredinterview) ist eine Erhebungsmethode der qualitativen Sozialforschung, mit der Daten von Befragten erfragt (und ausgewertet) werden. Im Mittelpunkt stehen dabei die Erfahrungen, Wahrnehmungen und Reflexionen der Befragten zu einem ganz bestimmten Problem (Thema).

Die Methode macht dann noch weitere Anforderungen an die Systematik (z.B. einen ergänzenden Kurzfragebogen). Um zu entscheiden, ob die zusätzlichen Strukturen für mich netto lohnenswert sind, werde ich mich wohl erst mal ein bisschen einlesen müssen. Fest steht aber, dass der o.g. Einsatzkontext für mich sehr gut passt.

Interviewleitfaden

Das zentrale Dokument eines Leitfadeninterviews ist – Überraschung – der Interviewleitfaden. Dieser ist so etwas wie eine Agenda für das Interview. Er beinhaltet alle Themen (häufig auch vorformulierte Fragen), die der Interviewer besprechen möchte, in einer voraussichtlich sinnvollen Reihenfolge. Er dient dazu, den Überblick zu bewahren und sicherzustellen, dass im Verlauf des Interviews kein Thema vergessen wird.

Wahrscheinlich werde ich für jedes Interview einen eigenen Leitfaden entwickeln oder zumindest Anpassungen vornehmen müssen, da die Erfahrungen mit Teachlets bei verschiedenen Moderatoren unterschiedlicher Art sind. Trotzdem muss vorher ein Grundgerüst existieren. Daher sind hier schon mal (mehr oder weniger aus dem Bauch heraus) ein paar Fragen, die ich stellen möchte.

1. Welche Erfahrungen mit dem Teachlet-Konzept hast du bereits gesammelt?
2. Wie hast du Teachlets erlebt im Vergleich mit anderen Lehrformen, die du kennst?
3. Wo siehst du Grenzen des Konzepts? Wo würdest du Teachlets auf keinen Fall einsetzen?
4. Hast du Hinweise für zukünftige Teachlet-Moderatoren? Was ist noch kein etabliertes Wissen, sollte aber auf jeden Fall bedacht werden?

Welche Frage(n) könnte(n) sonst noch wichtig sein? Zur Erinnerung: Beim Interviewleitfaden soll nicht jede einzelne Frage vorformuliert dastehen, sondern es handelt sich eher um eine Art Checkliste, mit der man sicher geht, dass keine der enthaltenen Fragen im Laufe des Interviews vergessen wird.

Interviewte Personen

Neben Axel Schmolitzky und Christian Späh, die hier bereits mehrfach genannt wurden, gibt es noch eine Reihe von Personen, die schon Teachlets gehalten haben und die ich so einschätzen würde, dass sie für meine Arbeit wichtige Erkenntnisse beizutragen haben. Aus Rücksicht auf die Persönlichkeitsrechte dieser Personen führe ich diese Liste zunächst mal nicht öffentlich. Sobald allerdings Zusagen vorhanden sind und Terminabsprachen stattgefunden haben, werde ich alles Wichtige natürlich hier preisgeben. Inwieweit Protokolle und/oder Aufnahmen der Interviews veröffentlicht werden können, werde ich dann mit den interviewten Personen einzeln absprechen. Vielleicht möchte es jemand gar nicht, dann soll es daran nicht scheitern. Ich gehe aber eigentlich davon aus, dass einige davon hinterher hier zu finden sein werden.

Gibt es jemanden, der/die Wichtiges zu Teachlets zu sagen hat und gehört werden möchte? Bitte bei mir melden.

Ist jemand am Konzept der Leitfadeninterviews interessiert und möchte vielleicht einfach mal eins miterleben? Sollte meinetwegen klappen. Sagt bescheid.

Technik

Ein gerne vergessenes, aber wichtiges Detail ist die Frage der Aufnahmetechnik. Man braucht ein Gerät, das gesprochene Sprache in einem (hoffentlich) ruhigen Raum mit zufriedenstellender Qualität aufzeichnen kann. Ich habe es ausprobiert: Mein Mobiltelefon kann es leider nicht. Aber zur Not ist das Mikrofon in meinem Laptop empfindlich genug dafür.

Ausblick

Nächsten Dienstag gibt es voraussichtlich (vielleicht auch mit einem Tag Verspätung) ein Überraschungsthema, weil ich vergessen habe die Zuständigen zu fragen, inwieweit ich im Vorfeld darüber sprechen darf... Also baue ich eben ein wenig Spannung auf. Bis nächsten Dienstag!

Diese Woche möchte ich den ersten Versuch unternehmen, eine aktualisierte Teachlet-Definition aufzustellen. Das Endergebnis des heutigen Eintrags soll der erste Versuch einer aktualisierten Definition sein, was auch bedeutet, dass ich um dein Feedback bitte (jedenfalls sofern du Teachlet-Erfahrung hast oder dich aus anderen Gründen angesprochen fühlst).

Aber vorher noch mal die „historische" Definition:

Ein Teachlet ist eine interaktive Lehreinheit, in der ein lauffähiges Stück Software um eine klar definierte Funktionalität erweitert werden soll, um ein Entwurfsmuster oder ein Programmiersprachkonzept zu veranschaulichen. Ein Moderator motiviert mit Hilfe eines Rechners und eines Beamers das Ausgangssystem sowie die vorzunehmende Erweiterung und lässt sich dann von den Teilnehmern anleiten, die dazu notwendigen Änderungen am Quelltext vorzunehmen.

Aus den Ergebnissen von letzter Woche haben wir die Liste der zentralen Aspekte für Teachlets (statisch) und Teachlet-Einheiten (dynamisch).

Teachlet

• Aufgabe
• Lernziel
• Lösungsraum
• Ausgangssystem
• Implementation
• Architektur
• Zielsystem
• Dokumentation

Teachlet-Einheit

• Rechner
• Standard-Ablauf
• Gemeinsame Sicht (z.B. Beamer)
• Moderator
• Teilnehmer (aktive, >= 1)
• Zwischenergebnisse festhalten
• Entwurfsdiskussion
• Interaktion

Ich fange einfach mal so an, dass ich die bisherige Definition Satz für Satz versuche zu aktualisieren und dabei die Begriffen im Hinterkopf zu haben. Auf zum ersten Satz:

Ein Teachlet ist eine interaktive Lehreinheit, in der ein lauffähiges Stück Software um eine klar definierte Funktionalität erweitert werden soll, um ein Entwurfsmuster oder ein Programmiersprachkonzept zu veranschaulichen.

Was passt an diesem Satz nicht?

Ich würde zunächst die Interaktivität gerne mehr unterstreichen, da Teachlets unstreitbar in hohem Maße interaktiv sind und das eins der definierenden Elemente ist. Wenn einfach nur „interaktiv“ da steht, gibt das einen großen Interpretationsspielraum (manch einer würde evtl. Vorlesungen als interaktiv beschreiben, wenn Fragen gestellt werden können).

Der Begriff der lauffähigen Software ist in dieser Form sinnvoll.

Statt der Erweiterung der Funktionalität würde ich mir eine größere Flexibilität für die Aufgabenstellung wünschen. Eine Erweiterung der Funktionalität ist zwar der Normalfall, sollte jedoch nicht vorgeschrieben werden (denkbar wäre etwa auch ein großes Refactoring).

Die Formulierung „ein Entwurfsmuster oder ein Programmiersprachkonzept“ ist ebenfalls recht restriktiv und sollte im Hinblick auf andere mögliche Lernziele (bestimmte Algorithmen, Refactorings o.Ä.) verallgemeinert werden.

Mein Versuch eines neuen ersten Satzes, den ich dabei jedoch aus Stilgründen zweiteile:

Ein Teachlet ist eine höchst interaktive Lehreinheit, in der ein lauffähiges Stück Software so verändert wird, dass es eine bestimmte Aufgabenstellung erfüllt. Diese ist so gewählt, dass dadurch ein ganz bestimmtes Lernziel erreicht werden kann.

Kommen wir zum zweiten Satz:

Ein Moderator motiviert mit Hilfe eines Rechners und eines Beamers das Ausgangssystem sowie die vorzunehmende Erweiterung und lässt sich dann von den Teilnehmern anleiten, die dazu notwendigen Änderungen am Quelltext vorzunehmen.

Gut ist hier, dass der Moderator und die Teilnehmer erwähnt werden. Weniger gut ist die Einschränkung auf Rechner und Beamer, die (so der Konsens der Teachlet-Runde) besser auf eine „gemeinsame Sicht“ verallgemeinert werden sollte. So wären etwa auch Teachlets denkbar, bei denen sich Teilnehmer und Moderator nicht im selben physischen Raum aufhalten (z.B. Teleconferencing, Teachlets per Internet).

Das Ausgangssystem zu erwähnen ist ebenfalls sinnvoll. Statt einer Erweiterung sollte im o.g. Sinne eher von einer Veränderung gesprochen werden.

Letztlich ist zu diskutieren, inwieweit Teachlets auf die Veränderung von Quelltext festgelegt sein sollten, wo es doch auch z.B. visuelle Programmierung und sicher noch weitere Paradigmen der Softwareentwicklung gibt, in denen der Begriff des Quelltextes zugunsten anderer Implementationsmechanismen wegfällt.

Mal sehen, was wir daraus machen können:

Ein Moderator motiviert das Ausgangssystem sowie die vorzunehmende Veränderung in einer mit den Teilnehmern gemeinsamen Sicht (etwa am Beamer) und lässt sich dann von den Teilnehmern anleiten, die dazu notwendigen Änderungen an der Software vorzunehmen.

Zeit für eine kleine Bestandsaufnahme. Die folgenden Begriffe aus den obigen Listen sind noch nicht untergebracht: Lösungsraum, Implementation, Architektur, Zielsystem, Dokumentation; Rechner, Standard-Ablauf, Zwischenergebnisse festhalten, Entwurfsdiskussion.

Zwei davon würde ich gerne begründet ausklammern: Rechner weil das Vorhandensein eines Rechners durch die Veränderung lauffähiger Software implizit ist, und Standard-Ablauf weil dieser gerade durch die Definition dargestellt werden soll.

Um ein paar der restlichen Aspekte einzubringen, versuche ich jetzt, ein paar neue Sätze zu formulieren:

Für die Lösung der Aufgabe soll ein Lösungsraum mit mehreren möglichen Varianten hinsichtlich der Architektur existieren, um eine Entwurfsdiskussion zu ermöglichen. Der Moderator hat dabei die Aufgabe, die Diskussion zu lenken und Zwischenergebnisse festzuhalten. Nach der gemeinsamen Implementierungsphase ist das Ergebnis die veränderte Software.

Dann ist wohl noch etwas für das Drumherum nötig:

Zum Teachlet gehört weiterhin eine Dokumentation, die für die Vorbereitung relevante Unterlagen wie eine detaillierte Choreographie oder ein ausimplementiertes Zielsystem enthält.

Ich konnte nicht widerstehen, die Choreographie mit aufzunehmen, wenn wir schon das Zielsystem drin haben wollen. Trotzdem zweifle ich noch, ob dieser Satz mit zur elementaren Definition gehören sollte.

Hier ist also der Entwurf 1 der aktualisierten Teachlet-Definition:

Ein Teachlet ist eine höchst interaktive Lehreinheit, in der ein lauffähiges Stück Software so verändert wird, dass es eine bestimmte Aufgabenstellung erfüllt. Diese ist so gewählt, dass dadurch ein ganz bestimmtes Lernziel erreicht werden kann. Ein Moderator motiviert das Ausgangssystem sowie die vorzunehmende Veränderung in einer mit den Teilnehmern gemeinsamen Sicht (etwa am Beamer) und lässt sich dann von den Teilnehmern anleiten, die dazu notwendigen Änderungen an der Software vorzunehmen. Für die Lösung der Aufgabe soll ein Lösungsraum mit mehreren möglichen Varianten hinsichtlich der Architektur existieren, um eine Entwurfsdiskussion zu ermöglichen. Der Moderator hat dabei die Aufgabe, die Diskussion zu lenken und Zwischenergebnisse festzuhalten. Nach der gemeinsamen Implementierungsphase ist das Ergebnis die veränderte Software. Zum Teachlet gehört weiterhin eine Dokumentation, die für die Vorbereitung relevante Unterlagen wie eine detaillierte Choreographie oder ein ausimplementiertes Zielsystem enthält.

Puh, das ist etwas länger ausgefallen als die alte Definition, deckt allerdings auch deutlich mehr ab. Ich hoffe, dass der Ablauf klarer herausgestellt ist.

Ich wiederhole noch mal meine Bitte um Feedback zu diesem Entwurf. Idealerweise soll diese Definition mindestens so lange halten wie die vorherige, daher würde ich mögliche Probleme gerne jetzt schon identifizieren.

Wenn rechtzeitig etwas Feedback kommt, werde ich es bis nächste Woche in den Entwurf einpflegen. Ansonsten werde ich mir bis dahin mal ein paar Gedanken um den Leitfaden für meine Interviews machen. Bis dahin!

Letzten Donnerstag habe ich den Vormittag am Informatikum verbracht und in einer kleinen Gruppe von Teachlet-Interessierten am Grundgerüst für eine aktualisierte Teachlet-Definition gebastelt. Anwesend waren Axel, Christian, ein mir bis dahin unbekannter Kommilitone namens Daniel und ich selbst.

Wir haben uns die Aufgabe gestellt, ausgehend unserer Erfahrungen mit Teachlets in den letzten Jahren zentrale Aspekte und Teile von Teachlets zu identifizieren, damit daraus eine aktualisierte Definition entstehen kann. Grundsätzlich ist die Definition aus Axels Paper von vor ein paar Jahren immer noch weitgehend umfassend und zeitgemäßer, als ich vor unserem Treffen vermutet hatte; aber in einigen Hinsichten nimmt sie Aspekte vorweg, die so nicht allgemeingültig sind.

Wir haben zunächst in Form eines Brainstormings wichtige Begriffe gesammelt und sie mit von mir zusammengestellten Schlagworten aus Axels Paper ergänzt. In die so entstandenen Begriffsmenge haben wir dann versucht, Ordnung hineinzubringen.

Als erstes wurde der Unterschied offensichtlich zwischen Aspekten, die für das Teachlet in seiner statischen Form relevant sind, und solchen, die für die jeweilige Teachlet-Durchführung bestimmend sind. Natürlich wirken beinahe alle statischen Aspekte eines Teachlets sich auf die Teachlet-Einheiten in der Ausführung aus, dies gilt allerdings nicht für alle komplett.

Die Semantik der Farben und Markierungen ist wie folgt: Blaue Begriffe hatte ich vorher vorbereitet, rote Begriffe waren im Brainstorming als weitere wichtige Bestandteile identifiziert worden. Teilweise stehen Erläuterungen in schwarz auf den Karten. Die Begriffe mit roten Punkten auf der Karte sind genau die, die essenzielle, unverzichtbare Bestandteile des Teachlets bzw. der Teachlet-Einheit (je nachdem, auf welcher Seite sie liegen) sind. Ein roter Punkt auf einer Karte auf der statischen Seite bedeutet außerdem, dass dieser Aspekt in der Teachlet-Einheit ebenso wichtig ist wie im statischen Teachlet, während ein roter Kreis bedeutet, dass der Aspekt nur auf der statischen Seite von essenzieller Bedeutung ist. (Diese Systematik war nicht geplant sondern ist während des Treffens organisch gewachsen, das macht sie vor jeglicher Kritik immun.)

Meine nächste Aufgabe ist jetzt, aus den Begriffen eine textuelle Definition zu erarbeiten, die zukunftsfähig ist. Obwohl ich im Moment noch mal vîel anderes um die Ohren habe, ist mein Ziel, euch nächste Woche hier den ersten Entwurf zu präsentieren. Dann auch hoffentlich wieder ohne Verspätung...

Heute geht es um Empirie und Datenerhebung. Ich möchte euch gerne darstellen, welche Überlegungen ich bezüglich meiner Datenquellen bisher angestellt habe, und was ich ungefähr für Daten erheben möchte.

Bachelorarbeiten und Datenerhebung

Eine Bachelorarbeit im Studienfach Informatik befasst sich typischerweise mit einer Problemstellung, die sich theoretisch analysieren oder sogar implementieren lässt. Etwas seltener sind Themen, die tatsächlich Feldforschung erfordern, die durch Befragungen oder ähnliche Methoden geleistet werden kann. Zu letzteren ist auch mein Thema zu zählen.

Datenquellen

Für meine Forschungsfrage(n) zur Vielseitigkeit von Teachlets gibt es nur eine kleine Menge an Datenquellen, die mir ggf. weiterhelfen können.

• Da gibt es zunächst mal das Teachlet-Archiv, in dem eine große Anzahl bestehender Teachlets aus den vergangenen Teachlet-Werkstätten konserviert ist. Jedes enthält idealerweise die komplette Teachlet-Choreographie, alle Folien, Systeme und Materialien, sowie mit etwas Glück Erfahrungen von bisherigen Durchführungen. Für die Frage, was Teachlets im Kern ausmacht, ist es mit Sicherheit sinnvoll, nicht nur von der Seite der Theorie mit der Definition zu arbeiten, sondern auch vorhandene Teachlets auf Gemeinsamkeiten und allgemeine Strukturen zu untersuchen.
• Weiterhin habe ich die Hoffnung, Interviews mit einigen erfahrenen Teachlet-Moderatoren zu führen. Im Umfeld unserer Uni gibt es vielleicht ein halbes Dutzend Leute, die bereits mehrfach und reflektiert Teachlets eingesetzt haben. Diese Leute möchte ich gerne zu fassen bekommen und zum Thema befragen, in der Hoffnung, dass sich aus den Interviews verwertbare Erkenntnisse gewinnen lassen.
• Zuletzt bleibt die Beobachtung aus erster Hand. Ein Teachlet, das Ende August hier an der Uni mit über 100 Leuten durchgeführt werden soll, habe ich mir dafür herausgepickt und werde es beobachten – „tracken“, wie der Teachlet-Kenner sagen würde; das bezeichnet das minutengenaue Protokollieren, welcher Abschnitt wie lange gedauert hat, speziell um den tatsächlichen Ablauf hinterher mit der Planung vergleichen zu können. Dabei ist vor allem interessant, wie das Teachlet-Konzept bei einer so großen Teilnehmerzahl läuft.

Schwierigkeiten

Der Datenerhebung sind schon dadurch Grenzen gesetzt, dass sich ein Teachlet nicht „mal eben testweise“ durchführen lässt, weil man dafür eine bestimmte Anzahl an Teilnehmern braucht. An diesem Punkt ist die probeweise Durchführung eines Teachlets im Anschluss an eine OOPM-Vorlesung im vergangenen Semester gescheitert – neimand hatte Lust, dafür länger zu bleiben, was natürlich verständlich ist. Ich muss also sehr genau darauf achten, alle verfügbaren Quellen zu nutzen, denn es ist eine sehr begrenzte Zahl.

Ein weiteres „Problem“ ist, dass die Daten, die ich erhebe, größtenteils eher qualitativ als quantitativ sind. Es wird nicht allzu viel zu vergleichen und in hübsche Diagramme zu packen geben, dafür aber umso mehr unterschiedliche Aussagen und Wertungen, aus denen ein kohärentes Gesamtbild extrahiert werden muss. Das wird gerade für einen Naturwissenschaftler wie mich ein hartes Stück Arbeit.

Organisatorisches

Seit letzter Woche habe ich einen Zweitbetreuer. Prof. Oberquelle hat sich dazu bereiterklärt. Jetzt, wo dieser Posten besetzt ist, steht einer Anmeldung der Arbeit im Prinzip nichts mehr im Wege. Ich werde das mal mit Axel besprechen.

Ende

Hoffentlich ist meine Darstellung der Konzepte zur Datenerhebung halbwegs verständlich. Was haltet ihr davon? Ist es so lesbar geschrieben, oder soll ich noch mehr auf typische Teachlet-Begriffe eingehen, wenn ich sie verwende?

Nächste Woche berichte ich dann vom Brainstorming-Treffen mit Axel und Christian, bei dem hoffentlich schon ein paar Grunderkenntnisse über die Definition von Teachlets gewonnen werden können. Das Treffen wird Donnerstag stattfinden, nächsten Dienstag ungefähr um diese Zeit gibt es dann hier die Ergebnisse zu sehen.

Der überwältigende Konsens scheint zu sein, dass die Entstehung meiner Bachelorarbeit wenigstens ein paar Leute interessiert. Hier also der erste Bericht von hoffentlich vielen, in dem ich zunächst mal das Thema erklären und ein wenig aus meinem Exposé zitieren werde.

Was sind Teachlets?

Teachlets sind ein am Fachbereich Informatik der Universität Hamburg entwickeltes Lehrkonzept für Inhalte der praktischen Informatik, das im Spannungsfeld zwischen theoretischem Vortrag und praktischer Programmierübung existiert und dabei versucht, die Vorteile beider Herangehensweisen zu aggregieren. Bei einem Teachlet gibt es vortragsartige Abschnitte, aber auch offene Entwurfsdiskussionen im Plenum, die vom Moderator geleitet live auf dem Präsentationsrechner in Code umgesetzt werden.

Durch die spezielle Methodik von Teachlets werden die Teilnehmer eines Teachlets stärker dabei gefördert, das Vorgestellte sofort zu reflektieren und anzuwenden, als bei einem traditionellen Vortrag.

Bisherige Forschung

Es gibt im Wesentlichen zwei Paper zum Thema, die Teachlets in abstrakter Form behandeln, beide vom Erfinder des Konzepts und Betreuer meiner Bachelorarbeit, Axel Schmolitzky.

• Schmolitzky, A., A Laboratory for Teaching Object-Oriented Language and Design Concepts with Teachlets. In Proc. OOPSLA ’05 (Companion: Educators’ Symposium), (San Diego, CA, 2005), ACM Press.
• Schmolitzky, A., Patterns for Teaching Software in Classroom. Paper presented at the 12th European Conference on Pattern Languages of Programs (EuroPLoP 2007), Irsee, Germany.

Wie man sieht ist das Feld bisher kaum beackert.

Meine Ziele

In meiner Arbeit möchte ich das Teachlet-Konzept systematischer definieren und abgrenzen, als das in Axels Original-Paper geschehen ist. Hier ist die dort gegebene Definition des Begriffs:

Ein Teachlet ist eine interaktive Lehreinheit, in der ein lauffähiges Stück Software um eine klar definierte Funktionalität erweitert werden soll, um ein Entwurfsmuster oder ein Programmiersprachkonzept zu veranschaulichen. Ein Moderator motiviert mit Hilfe eines Rechners und eines Beamers das Ausgangssystem sowie die vorzunehmende Erweiterung und lässt sich dann von den Teilnehmern anleiten, die dazu notwendigen Änderungen am Quelltext vorzunehmen.

Diese Definition gibt eine gute Vorstellung davon, wie ein Teachlet funktionieren kann. Gleichzeitig enthält sie allerdings eine ungenannte Anzahl Einschränkungen und Annahmen, die für den praktischen Einsatz evtl. gar nicht allgemeingültig sind, und lässt andere strukturelle Fragen ungeklärt.

Ich möchte als erstes eine neue Definition erarbeiten, die die Erfahrungen aus den Teachlet-Werkstätten der letzten Jahre sowie von externen Moderatoren berücksichtigt, um mit der Theorie zur Praxis aufzuschließen.

Weiterhin möchte ich untersuchen, in welchen Kontexten Teachlets funktionieren können und was dabei jeweils beachtet werden muss. Dabei wird es um Fragen gehen wie: Kann man ein Teachlet statt in einem Seminar mit 20 Teilnehmern auch in einer Vorlesung mit 100 Teilnehmern durchführen? Welche Veränderungen am Teachlet und an der Choreographie sind dafür nötig?

Didaktik, Pädagogik und ich

Eine Frage drängt sich auf: Inwieweit ist das Thema geeignet für eine Bachelorarbeit im Studienfach Informatik? Den Unkenrufen, dass das Thema doch eher für Studierende der Erziehungswissenschaften oder Lehramtsaspiranten geeignet sei, entgegne ich wie folgt:

• Es ist richtig, dass mir der Hintergrund fehlt, um Teachlets hinsichtlich ihrer didaktischen Qualitäten zu bewerten. Das ist aber auch gar nicht mein Ziel. Meine Arbeit wird in hohem Maße deskriptiv und weitgehend frei von Bewertungen, insbesondere bezogen auf die Didaktik, sein.
• Teachlets sind ein Lehrkonzept, das tief in Strukturen der Informatik angesiedelt ist und bspw. von Live-Programmierung ausgeht. Eine Übertragung auf ganz andere Themen wäre vermutlich denkbar, wird allerdings in meiner Arbeit nicht passieren.

Ende

Das war ein erster Einblick in Thema und Zielsetzung. Schaut auch nächste Woche wieder rein, wenn es um Empirie und Datenerhebung gehen wird. Fragen und Kommentare zu den Themen dieser und nächster Woche sind hochgradig erwünscht, da sie mich dazu motivieren, diese Berichterstattung durchzuziehen. ;)

Wie einige von euch wissen, stecke ich schon seit einiger Zeit in der inoffiziellen Vorbereitungszeit für meine Bachelorarbeit. Das Thema steht fest: „Das Teachlet-Konzept: Grenzen und Möglichkeiten einer Lehrform für Software-Entwurfsdiskussionen“, betreut von Axel Schmolitzky. Genau mein Wunschthema, wenn auch nicht unbedingt dem Kernbereich der Informatik zuzuordnen.

Demnächst möchte ich die Arbeit offiziell anmelden und so richtig mit der inhaltlichen Arbeit loslegen. Vor dem Hintergrund von dem, was Muelli im Moment auf seinem Blog so treibt, hatte ich die Idee, dass vielleicht abgesehen von meinem Betreuer noch mehr Leute daran interessiert sein könnten, die Entstehung einer Bachelorarbeit vom Exposé bis zum Endergebnis einfach mal mit zu verfolgen.

Um abschätzen zu können, ob das überhaupt jemanden interessiert (und wenn ja, wie viele) bitte ich alle Interessenten, mir hier einen kurzen Kommentar zu hinterlassen, falls ihr so etwas z.B. in Form von wöchentlichen Updates gerne lesen wollen würdet.

Gibt es daran Interesse? (Wenn nicht, spare ich mir die Arbeit.) Hinterlasst mir gerne Wünsche und Feedback zu der Idee.

Schon seit einigen Semestern bietet die Uni Hamburg einen Service namens Lecture2Go an. Die dort Zuständigen haben Equipment und Know-How zur gelungenen Aufzeichnung von Vorlesungen und anderen Vorträgen. Dort findet man zum Beispiel auch die Vorlesungen zum Modul Softwareentwicklung 2.

Vor etwa einem Semester hatte ich mitbekommen, dass ein Kommilitone ein solches Lecture2Go-Aufnahmeset für einen Vortrag im KunterBuntenSeminar organisiert hatte. Das fand ich sofort spannend, weil ich viel davon halte, Wissen möglichst allen Menschen zugänglich zu machen, die Interesse daran haben. Eine Aufzeichnung wie die mit Lecture2Go erlaubt es, die Grenzen der persönlichen Anwesenheit zu sprengen und einen Vortrag zu einem späteren Zeitpunkt und/oder an einem anderen Ort der Welt mit zu erleben.

Für meinen Vortrag am letzten Dienstag zum Thema „Mehrsprachigkeit in der Lehre an der Universität Hamburg“ habe ich es dann mal in Angriff genommen: Ich habe alles Nötige organisiert und durchgeführt, um diesen aufzuzeichnen und auf Lecture2Go weltöffentlich zugänglich zu machen. Vielleicht interessiert euch, wie ich dabei vorgegangen bin.

Organisatorisches in der Lehrveranstaltung

Zunächst mal muss der Veranstalter natürlich einverstanden sein, in diesem Fall war ich das nicht selbst, sondern Dr. Bernd Meyer aus der Linguistik. Unterschreiben musste dieser letztlich allerdings nichts, das musste nur ich als Vortragender.

Weiterhin sollte das Publikum über Lecture2Go und die Aufnahme im Vorfeld informiert werden. Da das Publikum normalerweise nicht mitgefilmt wird, gibt es keine Zustimmungspflicht. Höflicherweise sollte man allerdings darauf hinweisen, dass Gespräche und Geräusche im Raum in der Aufnahme leise zu hören sein können.

Interaktion mit dem Lecture2Go-Team

Das Lecture2Go-Projekt gehört zum Medienkompetenzzentrum des RRZ. Dort, in der Schlüterstraße, findet man diese Leute dann auch. Das sind drei sehr engagierte junge Mitarbeiter, die Freude an ihrem Projekt haben und normalerweise sehr entgegenkommend sind.

Dort kann man sich die Aufnahmehardware ausleihen. Außerdem unterschreibt man, dass man ihnen das Recht einräumt, die Aufzeichnung im Web zu veröffentlichen (nicht-exklusiv). An Verpflichtungen hat man eigentlich nur, sicherzustellen, dass durch den Vortrag (also insbesondere die Folien) keine Rechte Dritter verletzt werden, dass man also z.B. keine Bilder geklaut hat. Aber das stellt man ja sowieso sicher, von daher kostet auch das keine große Überwindung.

Aufnahme

Technisch funktioniert das mit einer Videokamera samt Stativ, einem Funkmikro, einem VGA-Splitter der das Videosignal des Präsentationsrechners zum Mitschnitt bereitstellen kann, sowie einem Apple MacBook an das das alles angeschlossen ist. Die Software zur Aufnahme und Nachbearbeitung ist jetzt schon recht idiotensicher, wird aber auch immer noch verfeinert. Für Informatikstudierende mit Sicherheit kein Problem. Trotzdem sollte man sie sich vorher ein mal zeigen lassen, das können die MCC-Leute machen oder man kennt jemanden (z.B. mich), der das vorher schon mal gemacht hat.

Für meinen Vortrag hat André sich netterweise bereit erklärt, die Kamera zu bedienen, da er das Verfahren schon aus Softwareentwicklung 1 kennt. Danke André!

Veröffentlichung

Nachdem man das fertige Video in einer Handvoll Formaten vorliegen hat, kann es auf die Lecture2Go-Webseite gestellt werden. Dieser Schritt ist leider derzeit noch der aufwändigste, jedenfalls einmalig. Accounts müssen vom Lecture2Go-Team erstellt und Lehrveranstaltungen zugewiesen werden. Nur Videos hochladen und Beschreibungstexte editieren kann man dann selbst. Es bleibt zu hoffen, dass dieser Prozess noch stromlinienförmiger gestaltet werden kann, wenn das System weiter hochskaliert werden soll.

Fazit

Auf meine Frage, ob dieses Experiment (Aufzeichnung eines Seminarvortrags eines Studenten) aus ihrer Sicht sinnvoll und weiterzuempfehlen ist, war die Antwort des Lecture2Go-Teams ein enthusiastisches „Na klar!“. Auch ich hatte Spaß daran und werde bei zukünftigen Vorträgen bestimmt wieder darauf zurück kommen.

Meine erste Lecture2Go-Aufzeichnung

P.S. Wie Murphy es nun mal so will, ist Lecture2Go anscheinend down, während ich gerade diese Zeilen schreibe. Hoffen wir, dass möglichst bald alles wieder funktioniert.

Im großen Feld der esoterischen Programmiersprachen gibt es einige besondere Exemplare, die über die kleine Gemeinde der Programmiersprachenfreaks hinaus in Hackerkreisen wenigstens ansatzweise bekannt sind. Eine davon ist Piet, auch „diese komische grafische Programmiersprache“ genannt.

In Kürze: Der Kontrollfluss bewegt sich zwischen zusammenhängenden Pixelfeldern, der „Cursor“ startet oben links und zeigt zunächst nach rechts, Farben sind „Opcodes“ (Arithmetik, Stackverarbeitung, I/O) und die Anzahl der Pixel in einem Feld dient als Repräsentation für Integer-Zahlen.

Piet zu „schreiben“ ist eine nette Denksportaufgabe, man bekommt nach recht kurzer Zeit passable kleine Programme hin. Es gibt sogar geduldige Menschen, die richtige Kunstwerke zeichnen, die gleichzeitig valide Piet-Programme sind. Es gibt Interpreter und sogar Assembler, so dass man die Programme tatsächlich ausführen (und in begrenztem Maße debuggen) kann.

Da konnte ich natürlich nicht widerstehen. Hier ist mein erstes Piet-Programm:

Für alle Neugierigen: Dieses kleine Programm gibt meinen Vornamen aus und beendet sich danach.

Aus Wikipedia:

Ein Quine ist ein Computerprogramm, das eine Kopie seiner selbst (üblicherweise seines Quelltextes) als Ausgabe schreibt.

Solche Quines sind bekannt für viele verbreitete und weniger verbreitete Programmiersprachen, Beispiele finden sich im obigen Wikipedia-Artikel und im restlichen Internet zu Genüge.

Aber dann gibt es natürlich auch wieder Leute, denen der Standard nicht verrückt genug ist.

Vor etwa sechs Monaten veröffentlichte ku-ma-me, ein japanischer Blogger, den folgenden Ruby-Code:

# ruby
l=92.chr;eval s="s=s.dump[r=1..-2].gsub(/("+l*4+"){4,}(?!\")/){|t|'\"+l*%d+\"'%(t
.size/2)};5.times{s=s.dump[r]};puts\"# python\\nprint(\\\"# perl\\\\nprint(\\\\\\
\"# lua"+l*4+"nprint("+l*7+"\"(* ocaml *)"+l*8+"nprint_endline"+l*15+"\"-- haskel
l"+l*16+"nimport Data.List;import Data.Bits;import Data.Char;main=putStrLn("+l*31
+"\"/* C */"+l*32+"n#include<stdio.h>"+l*32+"nint main(void){char*s[501]={"+l*31+
"\"++intercalate"+l*31+"\","+l*31+"\"(c(tail(init(show("+l*31+"\"/* Java */"+l*32
+"npublic class QuineRelay{public static void main(String[]a){String[]s={"+l*31+"
\"++intercalate"+l*31+"\","+l*31+"\"(c("+l*31+"\"brainfuck"+l*64+"n++++++++[>++++
<-]+++++++++>>++++++++++"+l*31+"\"++(concat(snd(mapAccumL h 2("+l*31+"\"110"+l*31
+"\"++g(length s)++"+l*31+"\"22111211100111112021111102011112120012"+l*31+"\"++co
ncatMap("+l*32+"c->let d=ord c in if d<11then"+l*31+"\"21002"+l*31+"\"else"+l*31+
"\"111"+l*31+"\"++g d++"+l*31+"\"22102"+l*31+"\")s++"+l*31+"\"2100211101012021122
2211211101000120211021120221102111000110120211202"+l*31+"\"))))))++"+l*31+"\","+l
*63+"\""+l*64+"n"+l*63+"\"};int i=0;for(;i<94;i++)System.out.print(s[i]);}}"+l*31
+"\")))))++"+l*31+"\",0};int i=0;for(;s[i];i++)printf("+l*63+"\"%s"+l*63+"\",s[i]
);puts("+l*63+"\""+l*63+"\");return 0;}"+l*31+"\");c s=map("+l*32+"s->"+l*31+"\""
+l*63+"\""+l*31+"\"++s++"+l*31+"\""+l*63+"\""+l*31+"\")(unfoldr t s);t[]=Nothing;
t s=Just(splitAt(if length s>w&&s!!w=='"+l*31+"\"'then 501else w)s);w=500;f 0=Not
hing;f x=Just((if x`mod`2>0then '0'else '1'),x`div`2);g x= reverse (unfoldr f x);
h p c=let d=ord c-48in(d,replicate(abs(p-d))(if d<p then '<'else '>')++"+l*31+"\"
."+l*31+"\");s="+l*31+"\"# ruby"+l*32+"n"+l*31+"\"++"+l*31+"\"l=92.chr;eval s=\"+
(z=l*31)+\"\\\"\"+s+z+\"\\\""+l*31+"\"++"+l*31+"\""+l*32+"n"+l*31+"\""+l*15+"\""+
l*7+"\")"+l*4+"n\\\\\\\")\\\")\"########### (c) Yusuke Endoh, 2009 ###########\n"

(Muss wohl ohne Zeilenumbrüche abgespeichert werden.)

Was passiert nun, wenn man diesen Code ausführt? Der Shell-Output spricht für sich:

$ ruby QuineRelay.rb > QuineRelay.py
$ python QuineRelay.py > QuineRelay.pl
$ perl QuineRelay.pl > QuineRelay.lua
$ lua QuineRelay.lua > QuineRelay.ml
$ ocaml QuineRelay.ml > QuineRelay.hs
$ runghc QuineRelay.hs > QuineRelay.c
$ gcc -Wall -o QuineRelay QuineRelay.c && ./QuineRelay > QuineRelay.java
$ javac QuineRelay.java && java QuineRelay > QuineRelay.bf
$ beef QuineRelay.bf > QuineRelay.ws
$ wspace QuineRelay.ws > QuineRelay.unl
$ unlambda QuineRelay.unl > QuineRelay2.rb
$ diff QuineRelay.rb QuineRelay2.rb
$

Die verwendeten Versionen der Compiler und Interpreter finden sich im Original-Artikel.

Laut Aussage des Erfinders war das Erstellen dieses Codes „einfacher, als es aussieht“, er habe gerade mal drei Stunden dafür gebraucht. Das Ergebnis ist dennoch ganz und gar faszinierend.

Dies wird nun also der erste Eintrag in meinem neuen Blog. Nun habe ich nach über zwei Jahren wieder eine funktionierende Website, diesmal sogar mit richtig schön viel Inhalt. Der Besuch soll sich ja auch lohnen.

Gibt es für den ersten Blog-Eintrag eigentlich Traditionen? So wie bei einer Schiffstaufe zum Beispiel? Im Moment komme ich mir nicht gerade feierlich vor. Vorstellen muss ich mich auch nicht unbedingt, dafür ist schließlich der große „Über mich“-Button da. Dann vielleicht ein bisschen Meta-Infos, auch auf die Gefahr hin, dass die für Nicht-Programmierer nicht so spannend sind:

• Geschrieben ist diese Seite in XHTML, JavaScript, PHP und MySQL.
• Als Bibliotheken sind Smarty und jQuery im Einsatz. Die benutze ich beide zum ersten Mal und bin sehr zufrieden.
• Ansonsten stecken diverse kleinere Plugins drin: Markdown, PHP OpenID und vermutlich noch ein paar, die mir gerade nicht einfallen.
• Die Software ist ansonsten ein kompletter Eigenbau. Meine Motivation dafür ist, der Update-Mühle zu entkommen. Vorher hatte ich eine Drupal-Site, aber die ständigen Versionsupdates sind mir ganz schön auf die Nerven gegangen – und aktualisieren muss man ja, weil's immer wieder Sicherheitslücken gibt. Ich hoffe, dass diese Software klein genug ist, dass sie keine nennenswerte Angriffsfläche bietet.

Übrigens ist diese Website bilingual. Wer mit einem englischen Browser daherkommt, bekommt sie in englischer Sprache zu sehen. Nur die ganzen Downloads liegen lediglich auf Deutsch vor, das liegt aber nur daran, dass ich wenig Motivation habe, ein Dutzend PDF-Dateien zu übersetzen. Die Technologie wäre da. Kleines Easteregg: Man kann die Sprache auch erzwingen, indem man „/de“ oder „/en“ an die URL anhängt. Es gibt übrigens nur diese beiden Sprachen.

Wenn ich nichts übersehen habe, sollte diese Webseite in allen Kombinationen von CSS/JavaScript an/aus funktionieren. Natürlich sieht sie dann unterschiedlich aus, aber es sollte alles Wichtige da sein. Wer CSS eingeschaltet hat, bekommt ein hübsches Layout, und wer JavaScript eingeschaltet hat, bekommt etwas mehr Eye-Candy und ein bisschen Extra-Inhalt wie einen E-Mail-Button.

Dann mal auf gut Glück mit dieser neuen Website!