Archiv des Autors: Tobias Thelen

Entwicklerworkshop ’09: 26.-27. März in Osnabrück

Der alljährlich stattfindende Entwicklerworkshop bringt die aktiven Stud.IP-Entwickler, Neueinsteiger und alle anderen an den eher technischen Aspekten der Stud.IP-Entwicklung Interessierten zusammen. In diesem Jahr findet der Workshop von Donnerstag, 26. März 2009 bis Freitag, 27. März 2009 an der Universität Osnabrück statt. Wer Lust auf mehr hat, kann ein Verlängerungswochenende bis Sonntag, 29. März 2009 anhängen.

Entwicklertagung

Programm

Folgende Themen werden im Mittelpunkt des Workshops stehen:

  • Gründung eines Arbeitskreises „Barrierefreies Stud.IP“
  • Einstieg in die Stud.IP-Entwicklung: Workshop für Neueinsteiger und Verbesserung der Dokumentation
  • Weiterführung des GUI-Redesigns
  • Vorstellung lokaler Entwicklungen und Plugins und Diskussion über ihre Eignung für andere Standorte

Das genaue Programm wird am 10. März veröffentlicht, bis dahin ist der aktuelle Stand im Wiki der Veranstaltung „Stud.IP-Entwicklertagung 2009“ auf dem Developer-Server einsehbar. Weitere Vorschläge für Beiträge sind herzlich willkommen und können dort direkt eingetragen werden.

Anmeldung

Die Teilnahme am Workshop ist kostenlos. Wir bitten allerdings um Anmeldung bis zum 25. März 2009, damit wir Räume, Kaffeeversorgung etc. planen können.
Um sich anzumelden:

  • Tragen Sie sich entweder einfach in die Veranstaltung „Stud.IP-Entwicklertagung 2009“ auf dem Developer-Server (http://develop.studip.de) ein. Dort finden Sie auch alle aktuellen Informationen zum Workshop und dort können Sie sich noch in die Planung einbringen.
  • Oder schicken Sie eine E-Mail an kursmanager@uni-osnabrueck.de.

Verlängerungswochenende

Besonders Engagierte und Interessierte haben die Möglichkeit, zwei zusätzliche Tage Stud.IP-Entwicklung anzuhängen. Ganz freiwillig (und nicht als Teil des offiziellen Programms) laden die Osnabrücker Stud.IP-Entwickler zu einem Entwicklerwochenende im Anschluss an den Workshop ein. Unterkünfte können privat gestellt werden, gearbeitet wird im Zentrum virtUOS, Verpflegung und Freizeitprogramm gemeinschaftlich vor Ort organisiert. Auf dem Programm steht das, was die Teilnehmer mitbringen: Spannende neue Features umsetzen, Dokumentation vervollständigen, Bugs fixen, Diskutieren bis zum Morgengrauen oder einfach gegenseitiges Über-Die-Schulter-Schauen. Wer Lust hat, am Entwicklerwochenende teilzunehmen (das Dutzend werden wir sicherlich vollbekommen), melde sich bitte im Forum der Veranstaltung „Stud.IP-Entwicklertagung 2009“ auf dem Developer-Server.

Weitere Informationen

Informationen zu Anreise, Unterkunft und Ansprechpartnern finden Sie auf den Seiten des Zentrum virtUOS unter: http://www.virtuos.uni-osnabrueck.de/VirtUOS/StudIPDev09

CodeCamp ’08: Tote BIESTer. Viele tote BIESTer. Sehr viele tote BIESTer.

Obwohl das CodeCamp auf einem Veganerhof gastieren durfte, gibt es jede Menge erlegten Getiers – nein, nicht zu beklagen, sondern – zu bejubeln. Viele dutzend erledigte Bugs, im Stud.IP-Jargon BIESTs genannt, säumen den Weg der furchtlosen Camper.

So ganz vollkommen makellos und fehlerfrei ist Software ja nie und im Laufe der Jahre versammeln sich in staubigen Ecken größere Mengen scheintoter Käfer, die nur darauf warten, im richtigen Moment zuzuschlagen. Vor einigen Monaten wurden die nie endenden Versuche, die BIESTer zu bändigen, aus dem in grauer Vorzeit selbstgestrickten Stud.IP-Wiki-Formularverhau in ein viel mächtigeres trac verlegt. Was noch ausstand: Mal kräftig durchfegen und in alle Ecken gucken.

Jedes einzelne BIEST, das aus den vergangenen Jahren übriggeblieben ist und das irgendwann mal jemand gemeldet hat, ist jetzt sorgfältig untersucht worden. Die meisten bewegten sich irgendwo zwischen: „Auf der Semesterferienverwaltungsseite fehlt ein Punkt“, „Manchmal funktioniert bei mir irgendwas nicht ganz richtig“ und „Ich habe eine Ausnahmesituation gefunden, in der die selten verwendete Funktion xy nicht das richtige Ergebnis liefert.“ Viele angestaubte Käfer konnten gleich aussortiert werden, weil die Verbesserungen der letzten Versionen ihnen jeden Nährboden entzogen haben. Andere ließen sich beim besten Willen nicht aus ihrem Versteck hervorlocken und wurden deshalb abgeschrieben.

Jetzt können wir nicht ganz ohne Stolz verkünden: Der Bug-Zoo ist gut aufgeräumt. Ein paar BIESTern bleibt noch der Garaus zu machen, aber wir wissen jetzt genau, wo sie wohnen. Die Verschnaufpause wird allerdings nur kurz sein. Beim genauen Hinschauen haben wir schon ein paar ganz neue Arten frisch mutierter Krabbelviecher gefunden.

CodeCamp ’08: Es geht los!

Wir sind da! Alle Kabel sind gelegt, Björn meldet vollen WLAN-Empfang, Nina und Tobias sind auch schon drin. Fotos gibt’s später, weil mein Handy sowas nicht kann und die Menschen mit den Kameras noch unterwegs sind. Schiefgehen kann aber nicht mehr viel. Es sieht gemütlich aus, es sieht nach Arbeit aus und es sieht nach spannenden kreativen Tagen aus. Mehr live aus dem CodeCamp später an dieser Stelle. Bleiben Sie dran!

Stud.IP und Firefox 3: Sichere Verbindung fehlgeschlagen?

Viele Nutzer, die in den letzten Tagen auf die neue Firefox-Version 3 umgestiegen sind, bekommen eine Fehlermeldung angezeigt, wenn sie wie gewohnt das Stud.IP ihrer Hochschule nutzen wollen:

studip-firefox3-sicherheits.jpg

Ungültiges Sicherheitszertifikat? sec_error_untrusted_issuer? Was ist da los? Sind die Stud.IP-Entwickler zu blöd, ihr System auch mit dem Firefox ans Laufen zu bekommen? Nein, daran liegt es nicht.

Es liegt daran, dass Firefox nun wesentlich schärfer mit unbekannten Zertifikaten umgeht und – im Gegensatz zum Internet Explorer – den Zertifikaten, die vom DFN ausgestellt wurden, nicht von vornherein als vertrauenswürdig einstuft. DFN-Zertifikate verwenden fast alle deutschen Hochschulen für ihre personalisierten Dienste und somit auch fast alle Stud.IP-Installationen.

So weit die Kurzfassung. Wer mehr wissen will, wird hier fündig.

Lift me up!

Es gibt Dinge, die sind irgendwie peinlich und hat man sie endlich abgestellt, weiß man so recht gar nicht, ob man freudestrahlend jubeln darf. Mit sechs noch am Daumen zu lutschen gehört dazu. Oder mit knapp dreißig noch die Wäsche von Mama gewaschen zu bekommen.

Stud.IP ist jetzt 8. Daumenlutschen war noch nie ein Problem und Wäschewaschen wird Stud.IP trotz aller Funktionsvielfalt wohl niemals können. Trotzdem gibt es aber ein paar Eigenarten, die abgestellt gehören, so praktisch oder aus der Historie heraus verständlich und erklärbar sie auch gewesen sein mögen.

Ein Beispiel, das fast jeder Stud.IP-Nutzer schonmal leidvoll erleben musste: In vielen Fällen ist es nicht möglich, mit mehreren Browserfenstern oder Browser-Tabs parallel im System unterwegs zu sein. Entweder kommt dann eine Fehlermeldung »Sie haben kein Objekt gewählt« oder der Forenbeitrag landet gar in der falschen Veranstaltung.

Die Entwickler sind sich schon länger einig: Stud.IP muss auch mit mehreren Tabs einwandfrei funktionieren. Das Problem allerdings: Die dazu nötigen Änderungen ziehen sich quer durchs System und sind nicht mal eben in einem Rutsch zu erledigen. Das liegt an einem recht alten Konzept, der »gewählten Veranstaltung«. Die wird in den so genannten Session-Daten gespeichert und die gibt es pro angemeldetem Benutzer nur einmal. Die Lösung also: Fast alle Stellen, an denen Stud.IP-interne Links generiert werden, so umbauen, dass alle notwendigen Informationen direkt mitgegeben werden. Technisch nicht sonderlich aufwendig. Aber nicht mal eben nebenher zu erledigen.

Das bisherige Entwicklungsmodell verpackt alle Änderungsvorschläge in »StEPs«, das sind die »Stud.IP Enhancement Proposals«, über die diskutiert und abgestimmt wird und die bis zum nächsten Release in spätestens sechs Monaten entweder ganz oder gar nicht umgesetzt werden müssen. Aufwendige Umbauten quer durch das System sind damit kaum umzusetzen, weil die Entwicklerkapazitäten, um mehrere Versionen parallel zu pflegen, schlicht und einfach fehlen.

Jetzt tritt neben die »StEPs« ein neues Modell, die »Lifters«, das steht für »Laufende, inkrementelle Technikrenovierung für Stud.IP«. (Zugegeben, die Abkürzung ist deutlich eingängiger als die Langform.) Lifters müssen nicht bis zum nächsten Release fertig sein, sondern ermöglichen sozusagen den Umbau im laufenden Betrieb. Deshalb gilt für Lifters: Alter Code muss lauffähig bleiben, zumindest bis alle anzupassenden Stellen im System erledigt sind.

Erste Lifters sind schon formuliert und angenommen. Ganz oben auf der Liste steht, kaum verwunderlich: »Unterstützung von Tabbed Browsing«. Die Entwickler waren schon fleißig und auf dem Developer-Server kann bereits mit mehreren Tabs gearbeitet werden. In der Arbeitsansicht von Veranstaltungen funktioniert schon fast alles, der Administrationsbereich steht aber noch zur Umsetzung an.

Irgendwann ist dann alles fertig, die Entwickler vergewissern sich noch einmal, dass nicht vergessen wurde und mit dem folgenden Release kann dann verkündet werden: »Stud.IP geliftet! Daumenlutschen Tab-Verbot endgültig abgestellt.«

#7 Geringstmögliche technische Anforderungen für NutzerInnen.

Ich durfte längere Zeit mit einer Web-Anwendung arbeiten, die ein komplexes Zusammenspiel aus Javascript, Real-Player und SVG-Plugin realisiert hat, um wirklich tolle Dinge zu leisten. Oder sagen wir bessern: Hätte dürfen. Wenn mich die permanenten Plugin-Download-Aufforderungen, Plugin-Versionsproblem-Meldungen und Browserinkompatibilitäten nicht hartnäckig davon abgehalten hätten. Ich hatte den Eindruck, dass eine der Komponenten immer veraltet war, egal, wann ich das System genutzt habe.

Prinzipiell lässt sich auch als Web-Anwendung fast alles realisieren, was man sich erträumen könnte. Insbesondere für die Entwickler ist es einfacher, sich dabei auf mehr als HTML stützen zu können. Oder exotische Browser außen vor zu lassen. Aktuelle Versionen von jedem und allem zu fordern.

Aber wie sieht das bei den NutzerInnen aus? Jedes zu installierende Plugin, jede Browser-Einschränkung schafft Hürden. Stud.IP ist ein Informations- und Kommunikationssystem, das mit ganz unterschiedlichen Voraussetzungen genutzt wird. Zum Beispiel von einem beliebigen Rechner unterwegs. Da lassen sich keine Plugins installieren. Sollte man deshalb jemanden davon ausschließen, sich für eine Veranstaltung anzumelden?

Deshalb lautet der siebte und letzte Punkt der Stud.IP-Philosophie:

Stud.IP erfordert neben einem Internetzugang und einem Webbrowser keine besonderen technischen Voraussetzungen. Das System ist mit jedem aktuell verbreiteten Browser nutzbar, Javascript und besondere Plugins werden für die Grundfunktionen des Systems nicht benötigt.

Wir nehmen das ernst. Wirklich. Stud.IP lässt sich auch mit Urlaut-Netscapes der Versionen 4.7 (Baujahr 1999) bedienen. Nicht perfekt und manches sieht etwas unschön aus. Aber es funktioniert. Wer jetzt gähnt, laut „Web 2.0!“ schreit und sich fragt, wer denn sowas Prähistorisches noch benutzt, dem sei gesagt: Wir finden häufig Sekretariatsrechner, die seit der Jahrtausendwende kein Browserupdate mehr gesehen haben.

Derart alte Browser sind aber nicht der Hauptgrund für die geringen technischen Anforderungen. Beispiel Javascript: Wir wollen weder NutzerInnen mit wenig verbreiteten Browsern aussperren, noch die, die aus Sicherheitsbedenken Javascript abgeschaltet lassen wollen. Darum funktioniert Stud.IP auch ohne Javascript. Etwas unbequemer, aber es tut alles Notwendige. Jetzt zeigt der „Web-2.0!“-Rufer wieder auf. Modernes Web heißt doch Ajax und Drag und Drop und volldynamisch und das ganze eben wie eine Desktopanwendung. Das geht nicht ohne Javascript. Wer darauf verzichtet, baut altbackene, langweilige Sachen.

Das mag stimmen, ein bisschen. Deshalb gibt es ab Version 1.6 auch Ajax-Effekte in Stud.IP. Und eine verbindliche Regelung für den Umgang mit Ajax, die als StEP101 beschlossen wurde. Darin heißt es: „Das System muss weiterhin auch ohne Java-Script vollständig bedienbar bleiben.“ Das heißt: Tolle Web-2.0-Effekte — Ja. Aber: Es muss immer noch einen Weg ohne geben. Der kann etwas umständlicher sein, aber – auch wenn das für die Entwickler doppelten Aufwand bedeutet – ohne geht es nicht.

Für Plugins gelten diese harten Auflagen übrigens nicht zwangsläufig. Überlegen Sie deshalb als Betreiber gut, ob Sie Ihren NutzerInnen mit installierten Plugins Steine in den Weg legen, die der Einsatzzweck nicht rechtfertigt.

Dieser Beitrag ist eine Fortsetzung zu #6 Unterstützung für alle statt Spezialfeatures für wenige.

Ausgefuchst suchen

Kennen Sie das Gefühl, bei langgenutzter Software plötzlich etwas zu entdecken, das schon immer da gewesen sein muss, Ihnen aber nie aufgefallen ist? Und das das Leben um einiges erleichtert? Firefox ist ein Allzeit-Kandidat für solche Entdeckungen; hier eine, die auch beim Umgang mit Stud.IP hilfreich sein kann. Das Zauberwort heißt „Schlüsselwort für diese Suche hinzufügen“. Sehen und staunen Sie.

Eine oft genutzte Funktion in Stud.IP ist die Suche nach Personen. Wann hat Prof. Meier Sprechstunde? Hat dieser Michael endlich neue Votings auf seiner Homepage? Wie ist die Telefonnummer der Prüfungsamtssekretärin? Vier bis fünf Klicks sind normalerweise nötig, um zur gewünschten Information zu kommen. Nicht viel, aber wenn man’s oft genug macht, ein paar Klicks zu viel. Bis Stud.IP selbst kürzere Wege anbietet, hilft Firefox.

1 . Suchformular aufrufen

ffsuche1.jpg

Rufen Sie zunächst wie gewohnt das Suchformular für Personen auf. Dann klicken Sie mit der rechten Maustaste in das Feld „Nachname“. Das dann erscheinende Menu enthält einen Punkt „Ein Schlüsselwort für diese Suche hinzufügen…“. Falls Sie sich hier fragen: War das schon immer so? Die Antwort ist: Ja. Jedenfalls schon seit einigen Firefox-Versionen. Seine Sie mutig und klicken Sie drauf..

2. „Schlüsselwort für diese Suche hinzufügen“

ffsuche2.jpg

Es erscheint eine Dialogbox, die ein Lesezeichen hinzufügen lässt. Lesezeichen? Will ich das? Ja. „Name“ und „Erstellen in“ werden wie gewohnt gefüllt, damit Sie das Lesezeichen später auch in Ihrer Lesezeichenliste wiederfinden können. Die Magie steckt hier aber im Feld „Schlüsselwort“. Wählen Sie eine kurze, aber leicht merkbare Zeichenfolge. Kurz, weil Sie sie später häufig tippen werden. Leicht zu merken, weil… Naja, Sie wissen schon. Hier im Beispiel habe ich „sp“ für „Stud.IP Personensuche“ gewählt. Aber das ist nur ein Beispiel.

Das war’s! Fertig! Und jetzt?

3. Und so wird’s benutzt

ffsuche3.jpg

Wann immer Sie von nunan in Stud.IP unterwegs sind und eine Person suchen wollen, sagen wir mal Herrn Thelen, klicken Sie einfach in die Adressleiste Ihres Browsers und tippen Sie „sp Thelen“. Und Enter. Dann erscheint die Ergebnisliste ganz so, als hätten Sie umständlich das Suchformular aufgerufen, ausgefüllt und abgeschickt.

ffsuche4.jpg

Ich find’s praktisch!

Hinweise:

Das ganze funktioniert nur, wenn Sie in Stud.IP angemeldet sind. Falls nicht, erscheint ein Login-Formular und nach dem Ausfüllen das Suchformular, leider leer und ohne Ergebnisse. (Mag einer der Entwickler das ändern?)

Es funktioniert auch nicht, wenn Sie zum Einloggen eine andere URL benutzt haben, als beim Erstellen des Schlüsselwortes (z.B. http://test.studip.de statt http://develop.studip.de). Das ist aber in den allermeisten Fällen nicht der Fall.

Das Feature funktioniert natürlich nicht nur für Stud.IP. Übungsaufgabe: Überreden Sie Ihren Firefox dazu, bei der Eingabe von „w Klappergrasmücke“ in der deutschen Wikipedia nach „Klappergrasmücke“ zu suchen.

Wir nennen es Stud.IP – Spontanpräsentation am 25.8. in Berlin

Vom 23.-26. August startet in Berlin zum ersten mal das »9to5. Wir nennen es Arbeit – Festival-Camp« Das offizielle Programm beginnt jeweils um 21 Uhr, aber auch vorher gibt es schon (und noch dazu kostenlos) Gelegenheit, im Radialsystem V zu leben, zu arbeiten, zu netzwerken – oder z.B. zum OpenBeamer-Forum zu gehen. Das lohnt sich besonders am Samstag, wenn das Tagesmotto »Weltverbesserung« lautet und um 18.00 Uhr im Raum »Bremen« ein fruchtiger Spontanvortrag von Tobias Thelen und anderen mitgereisten Osnabrückern steigt:

Thema: Open-Source-Lernplattform zwischen Enthusiasmus und Institutionalisierung

25.8.2007, Berlin – Radialsystem V, 18.00 Uhr

»Man flirtet und chattet statt zu arbeiten«
(ein entrüsteter Professor über Stud.IP)

Stud.IP (Witze über den Namen sind willkommen, aber: Wir kennen sie alle schon!) ist vor fast 8 Jahren als Open-Source-Projekt mit subversivem Enthusiasmus gestartet: Ein paar Gedanken, die man heute als »2.0« bezeichnen würde, sollten systematisch in den Uni-Alltag geschmuggelt werden.

Entstanden ist eine »Lern- und Kommunikationsplattform«, die sich deutlich von kommerziellen Konkurrenzplattformen abheben will. Bei denen wird Studium und Bildung nämlich gerne mit Begriffen wie »Instruktion«, »Lernfortschrittskontrolle« und »Training« in Verbindung gebracht. Im Gegensatz dazu und zu zentralen, reinen Studi-Netzwerken wie z.B. StudiVZ war und ist der Stud.IP-Ansatz: Je eine Installation vor Ort, vorhandene Strukturen aufgreifen, Lehrende einbeziehen, gleichberechtigte Kommunikation zwischen Studierenden und Lehrenden.

Inzwischen ist das Projekt sehr »erfolgreich«. Mehr als ein dutzend Hochschulen setzen voll auf Stud.IP, finanzieren die Entwicklung mit oder stellen Mitarbeiter für die Entwicklung ab. Um das Projekt herum sind Verdienstmöglichkeiten für Support und Entwicklungsdienstleitungen entstanden.

Neben einer Vorstellung der Grundgedanken, einigen ganz kurzen Einblicken in das »Leben« in der Plattform und ein paar Bemerkungen zur Organisationsform als Open-Source-Projekt möchten wir vor allem den Fragen nachgehen: Was ist aus dem Enthusiasmus geworden? Ist das Projekt auf die schiefe Bahn der Institutionalisierung geraten? Wie ist das Verhältnis zwischen »freien Ideen« und bezahlten Entwicklungen? Wie kann es gelingen, dass so etwas wie Stud.IP sexy bleibt? Fertige Patentlösungen für die Fragen haben wir nicht und freuen wir uns auf spannende Diskussionen.

Seid dabei! Erzählt es weiter! Schaut rein! Macht mit! Oder werdet wichtige Fragen – wenn ihr nicht selbst kommen könnt – wenigstens im Forum vorab los: http://9to5.wirnennenesarbeit.de/forum/topic.php?id=20&page. Wer nochwas anregen möchte: Mail an mich, Forum auf dem Developer-Server oder Kommentar hierlassen.

#6 Unterstützung für alle statt Spezialfeatures für wenige.

Der Tumbau zu Babel
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.