Nicht verwirren, sondern klare Wege anbieten!

»Das Zeugsein des Zeugs besteht in seiner Dienlichkeit. Aber wie steht es mit dieser selbst? Müssen wir nicht das dienliche Zeug in seinem Dienst aufsuchen?« (Heidegger)

In seiner ebenso informativen wie amüsanten Reihe zu den Stud.IP-Anfängen erläutert Cornelis sehr schön, was zum einen Triebfeder der Entwicklung war und zum anderen heute noch Hauptunterschied zu anderen Plattformen ist: Stud.IP ist nicht von der Theorie komplexer E-Learning-Szenarien her gedacht, sondern vom »normalen« Nutzer, der in der »traditionellen« Präsenzlehre deutscher Universitäten zu Hause ist und elektronische Unterstützung sucht.

Das heißt: Stud.IP geht nicht von umfassend medienerfahrenen Nutzern aus, für die ein Mehr an Gestaltungs- und Konfigurationsmöglichkeiten, ein Mehr an unterstützten didaktischen Szenarien, ein Mehr an fein abgestuften Varianten automatisch ein Gewinn an persönlicher Freiheit und Entfaltungsmöglichkeiten ist. Sondern: Stud.IP unterstützt besonders denjenigen, der sich langsam herantasten will an etwas Neues, der dankbar ist, wenn ihm eine Umgebung angeboten wird, die bereits so eingerichtet ist, dass er vertraute Begriffe wiederfindet und die Möglichkeiten und Funktionen nicht für jede Veranstaltung neu suchen und einrichten muss, sondern sich schnell und sicher zurechtfindet.

Deshalb lautet der sechste Punkt der Stud.IP-Philosophie:

NutzerInnen mit technischem Know-How und ambitionierten Sonderwünschen brauchen Stud.IP weniger dringend als Studierende und Lehrende mit Berührungsängsten oder wenig Lust und Zeit zur Einarbeitung in komplexe Abläufe. Stud.IP richet sich vor allem an NutzerInnen, die von der Technik eine grundlegende, einfach nutzbare und überschaubare Unterstützung ihrer inhaltlichen Arbeit erwarten. Deshalb soll nur behutsam von der Möglichkeit Gebrauch gemacht werden, beispielsweise aufwendige Content-Projekte mit Stud.IP zu koppeln.

Wir halten diesen Punkt für einen weiteren wesentlichen Baustein des Stud.IP-Erfolges. E-Learning-Spezialwerkzeuge für E-Learning-Spezialisten gibt es viele. E-Learning-Basiswerkzeuge für erfahrene Praktiker in der Präsenzlehre nur wenige.

Doch die Zeit steht nicht still und die Stud.IP-Entwicklung ebensowenig. Musste man vor zehn, fünf oder auch nur drei Jahren noch davon ausgehen, dass normale Lehrende und Studierende unserer Hochschulen wenig Erfahrung im Umgang mit Online-Medien verfügen und daher auch nur wenige Sonderwünsche konkret formulieren können, hat sich das Bild inzwischen etwas gewandelt. Zum Teil auch dank Stud.IP, denn an den Hochschulen, die das System seit längerem einsetzen, ist die Basisunterstützung und -nutzung selbstverständlich geworden. Der Blick der Nutzer weitet sich und die Wünsche werden spezieller. Hinzu kommt der derzeitige Trend zur Systemintegration. Die Anforderung, Stud.IP mit den vor Ort betriebenen Systemen X, Y und Z zu koppeln, gehört zum Standardanforderungskatalog neu hinzukommender Betreiber.

Dieser sechste Punkt der Stud.IP-Philosophie ist zweifelsohne der, gegen den die Entwickler in der Vergangenheit in gewisser Weise am häufigsten verstoßen haben. Zu leicht landen Features im System, die für einen Standort oder eine bestimmte Nutzergruppe genau richtig und perfekt angepasst sind, anderen aber nur zum Teil schmecken. Diesem prinzipiellen Problem begegnen wir auf zwei Weisen:

Eine Plugin-Schnittstelle erlaubt es, beliebig spezialisierten Code zu produzieren, der nicht zur Stud.IP-Grundausstattung gehört, aber von den Betreibern vor Ort einfach hinzugeladen werden kann. Unter http://plugins.studip.de findet sich eine stetig wachsende Liste veröffentlichter Plugins. Wer die einsetzt muss sich darüber im Klaren sein, dass dort nicht alle Punkte der Stud.IP-Philosophie in gleichem Maße gelten und die Lösungen häufig spezifische Fälle abdecken, die nicht mit den eigenen übereinstimmen. Aber dort wie sonst auch gilt: Die Entwickler sind nur eine handvoll Klicks entfernt und helfen gern und schnell.

Die zweite Möglichkeit, speziellere individuelle Ansprüche an Stud.IP als E-Learning-System erfüllen zu können, besteht in der so genannten E-Learning-Schnittstelle. Mit ILIAS und PmWiki lassen sich zwei Systeme, die multimedial aufbereitete E-Learning-Inhalte samt Autorenumgebung vorhalten können, direkt an Stud.IP anbinden. Zwar findet ein gewisser Bruch statt, das Layout ist nicht identisch, ein neues Fenster öffnet sich, aber damit auch beliebige Gestaltungsoptionen. Spezielle vorgefertige Skins und Templates mildern den Bruch ab und das wichtigste: Alle Fragen der Nutzerauthentifizierung und -authorisierung werden unsichtbar im Hintergrund erledigt.

Mit diesen beiden Optionen wird Stud.IP auch für Sonderanforderungen, Spezialanwendungen und ganz individuelle E-Learning-Szenarien zur Schaltstelle und Drehscheibe. Denn das wird von allen Nutzern an »Stud.IP-Hochschulen« immer wieder als der alles schlagende Vorteil genannt: Endlich alles an einem Platz, endlich alles einheitlich geregelt, endlich alles verständlich und sauber immer und von überall zugänglich.

…findet am 18. und 19.09. 2007 statt.

Ja, diesmal zweitägig.
Hatten sich so viele Besucher (wegen der teils recht langen Anfahrtswege) gewünscht. Und Wünsche erfüllen wir doch gerne.

Die Tagung feiert halbrunden Geburtstag: zum fünften Mal lädt data-quest nun schon ein, um den Dialog zwischen Entwicklern und Nutzern zu fördern. Deshalb heißt es auch “Tagung für Betreiber und Anwender” – hier findet weniger Code-Talk statt (dafür gibt es ja die Entwicklertagung im Frühjahr) als vielmehr Information zu Nutzung und Entwicklungen und gegenseitiger Austausch.

Die diesjährige Tagung verspricht wieder spannend zu werden: neben den Schwerpunkten Content und gemeinsame Nutzung über mehrere Hochschulen gibt es viele weitere interessante Vorträge und Workshops zu aktuellen Themen. Das Programm ist (finde ich persönlich) wieder sehr gut und abwechselungsreich geworden. Sowohl Betreiber als auch Entwickler, Didaktiker und Anwender sollten darin etwas für sie interessantes finden können.

Ein großes “Danke” geht an alle, die beim Programm mitgearbeitet haben und sich mit Beiträgen beteiligen – insbesondere Herrn Quathamer von der ELAN AG, der an der Gestaltung maßgeblich beteiligt war. Da Niedersachsen Stud.IP im ELAN III-Projekt besonders fördert, können wir uns nicht nur auf den Besuch von Minister Stratmann freuen, sondern auch auf informative Aussichten über zukünftige Entwicklungen.

Dazu gibt es natürlich noch ein paar spezielle Highlights, wie das bunte SourceTalk-Rahmenprogamm oder die Möglichkeit, eine ganztägige Adminschulung zu besuchen. Im letzten Jahr haben wir erstmals mit einem “Social Event” experimentiert. Das hat fantastischen Anklang gefunden, daher wiederholen wir es in diesem Jahr wieder. Es gibt nichts Netteres, als bei einem gepflegten Umtrunk über unser aller Lieblingsthema zu netzwerken und gemeinsam neue Projekte zu planen.

Natürlich wird die Tagung auch in diesem Jahr für die Organisatoren wieder stressig.
Natürlich wird es wieder Augenringe vor Müdigkeit und komische-Dinge-in-letzter-Sekunde geben.

Ich freue mich trotzdem total darauf.

Ob die Stud.IP-Tagung nun im September, Oktober oder November abgehalten wird, irgend etwas findet anscheinend immer parallel statt, dass für eine Verknappung und dementsprechen Verteuerung der Übernachtungsmöglichkeiten sorgt: entweder eine Monstertagug in Göttingen (2005) oder tausend Einzeltagungen in Göttingen (2006) oder eine Messe für irgendwas in Hannover (2007) .

Hoteliers reiben sich natürlich die Hände: plötzlich wird ein Einzelzimmer, das normalerweise 45 Euro kostet, zu Preisen von 110 Euro angeboten. Natürlich werden die Preise von Angebot und Nachfrage bestimmt – aber DAS grenzt an Unverschämtheit. Zudem ist es nicht möglich, vernünftige Kontingente zu bekommen. Für die Stud.IP-Tagung wurde uns ein Kontingent an Zimmern zu halbwegs humanen Preisen bis zum 10.09. zugesagt. Eine Woche vor der Tagung – das ist okay. Dann heißt es plötzlich: “Sorry, aber wir haben so viele Anfragen – das Kontingent kann maximal bis zum 05.08. freigehalten werden”.
Verhandlung nicht möglich.
Was soll denn sowas? Wenn wir bei data-quest den Preis eines Produktes fast verdreifachen und zudem den Lieferzeitraum nicht einhalten würden – wir hätten in Kürze keine Kunden mehr.

Aber im Hotelgewerbe geht sowas anscheinend.
Schlafen und essen muss man ja immer.

Grrrh.

Fehlerfreie Software gibt es ja bekanntlich nicht, aber Stud.IP ist schon dicht dran. Zumindest wurden wieder einige Bugs aufgespürt und erlegt. Ab sofort liegt die aktualisierte Version 1.5.0-2 auf den SourceForge-Servern zum Download bereit.

Sommer 2000: Was man auf einen ersten, unachtsamen Blick für eine Laienspieltruppe halten könnte, die zum ersten Mal mit PHP-Förmchen spielt, sich mit MySQL-Sand bewirft und seltsames HTML sabbert, entpuppt sich schnell als eine hochmotivierte und nahezu unbezahlte Arbeitsgruppe, die verbissen ihre Vision eines Lernmanagement-Systems (LMS) umsetzt. Zu diesem Zeitpunkt ist allerdings noch niemand auf die Idee gekommen, über den Tellerrand zu schauen. Man glaubt also noch, etwas konkurrenzlos Einzigartiges zu erschaffen.
Der Kommunikationswissenschaftler namens Ralf Stockmann wirft im sekundentakt neue Programmieraufgaben an seine Hiwis aus, die eigentlich für andere Aufgaben wie Kaffeekochen oder IT-Babysitting bei Dozenten eingestellt wurden, aber irgendwie in seine Fänge geraten sind. Manche freiwillig, wie der blutjunge Student Cornelis Kater, andere über geringfügige Geldversprechen. Der einzige, der Ralfs Tatendrang gelegentlich stoppt, ist der Biologe, der niemand anders ist als Stefan Suchi:
„Also, in dieser Woche müssen die Veranstaltungsverwaltung, die Nutzerhomepage, das Dateisystem, toll aussehende Reiter…“
„Wir brauchen ein Rechtesystem. “
„…Newsfunktion, Einrichtungsverwaltung…“
„Das bringt alles nichts ohne ein Rechtesystem!“
„…Teilnehmerliste? Wer redet hier denn immer von einem Rechtesystem? Ist so was wichtig?“
„Ja. Ohne ein Rechtesystem gäbe es keinen Administrator, der du bestimmt sein willst. Also?“
Ralf gibt sich geschlagen, die Programmierer ergeben sich ihrem Schicksal und begeben sich zurück an die Arbeit in ihren düsteren Parzellen, die früher einmal Krankenhauszimmer gewesen sind.

Bevor jedoch die Version 0.2 einer breiten Öffentlichkeit – nämlich allen Studierenden in allen Veranstaltungen des frisch gegründeten Zentrums für interdisziplinäre Medienwissenschaft – zugänglich gemacht werden kann, müssen jedoch noch zwei wichtige Dinge gefunden werden: Ein Name für die Software und jemand, der es schafft, dass sie tatsächlich fertig wird.
Um das erste Problem zu lösen, betritt Cornelis noch nichts ahnend Ralfs Büro, in keinster Weise auf die schwere Bürde vorbereitet, die ihm nur Sekunden später aufgelastet werden wird.
„Wir müssen uns mit dem „Internet und Datenbanken“-Projekt für einen Wettbewerb bewerben und brauchen dafür einen wohlklingenden Namen. Du hast jetzt die Möglichkeit, viel Ruhm und Ehre zu ernten und dir diesen auszudenken.“
„Ok, cool. Ich grübele dann mal, kläre die internationalen Namensrechte…“
„Wir haben nur 15 Minuten. Und es müssen die Begriffe „studentisch“, „Internet“ und „Präsenzlehre“ vorkommen.“
„Uh…“
„Und, kochst du uns vorher noch einen Kaffee? Soviel Zeit muss sein!“
Wenig später ist der „Studentische Internetsupport von Präsenzlehre“ geboren (das Wort studentisch wird später allerdings klammheimlich gegen studienbegleitend getauscht) und wird fortan verkürzt als Stud.IP bezeichnet.

Ein Problem für den Fortschritt der Programmierarbeiten sind die beiden Tagelöhner, die frühzeitig als Programmierer angeheuert wurden. Der eine von beiden klaut seinen Code lediglich zusammen, während man bei dem anderen hofft, der Code wäre wenigstens von etwas halbwegs Funktionierendem geklaut.
„Die Zeit wird langsam knapp und Stud.IP ist ist noch lange nicht einsatzfähig… Wir haben lauter nette Einzelteile, ein halbfertiges Rechtesystem, eine desolate Nutzerhomepage aber viel zu wenig Programmierer und viel zu wenig Zeit“ panikt Ralf.
„Wir müssen nebenbei auch noch studieren und Schlafen soll eine feine Sache sein, haben wir gehört.“ werfen die drei Hiwis im Chor ein.
Ralf überlegt eine Weile und stellt dem Team wenig später André Noack vor, einen alten Kollegen aus den Zeiten der Computerkistenschieber, bei denen sie gemeinsam während ihres Studiums Kisten geschoben haben. Nicht wissend, wie ihm geschieht, muss André noch schneller als alle anderen Programmieren lernen. Eine Entscheidung, die für das Projekt nicht besser hätte sein können. Und das, obwohl André ein Sakrileg begehend als erstes eine Teemaschine im Projektbüro aufbaut.

Wenige Monate später fluten die Studierenden des neuen ZiM das System, das nur gefühlte Sekunden zuvor fertig geworden ist.
Diese Version zeigt auch, warum das Hintergrundbild in Stud.IP bis heute den Namen „bathtile.jpg“ trägt, denn aus unerfindlichen Gründen fühlten sich die damaligen Programmierer nur wohl, wenn sie die Software vor einem Badezimmerfliesenhintergrund gestalten durften…