Das Raumbuchungstool des Campus WU ist darauf ausgelegt, dass Mitarbeiter_innen wie Studierende – also etwa 30.000 Personen – selbständig und unbürokratisch Räume buchen können. Das dadurch drohende Chaos eines heillos belegten Gebäudes verhindern wir durch mehrere Parameter, wie etwa schrittweises Freigeben von Ressourcen, Speichern von Bedarfen in Raumgruppen anstatt in spezifischen Räumen, automatisierte Allokation, oder individuelle Berechtigungen. (Viele der hier genannten Dinge haben wir uns übrigens bei der Konkurrenz simulieren lassen.)
i have to admit: programming makes me happy. (on days like this I wish there were no more weekends)
Anyway – wir sind nun seit genau einer Woche online und haben rund 8.000 Termine und somit bereits die Hälfte des kommenden Wintersemesters eingesammelt. Die Frage liegt also nahe, welche Räume (Raumgruppen) stark nachgefragt werden, und – am allerwichtigsten – wo etwaige Konflikte auftreten. Nach ein paar Stunden Python und Javascript kam dann mein Erfolgserlebnis, das ich auch gleich auf Twitter verewigen musste.
Programmieren mit d3.js (Data Driven Documents) macht also Spaß.
Ergebnis der Bastelarbeiten ist ein interaktives Diagramm, das mit dem Kalender-Widget oben gesteuert wird. Entlang der Tageszeit wird pro Raum-Pool (die Kapazität ist anhand der Fläche codiert) die Belegung inkl. der angefragten Termine visualisiert. Je stärker die Nachfrage, desto dunkler der Blauton. Liegt die Nachfrage über dem Angebot, wird das Blau zu einem gefährlichen Rot – hier gibt’s also dann etwas zu bereinigen.
Visualisierung der angefragten und verfügbaren Kapazitäten pro Datum.
Das Ergebnis mit der traumhaft-schönen Animation auf YouTube. Das Diagramm ist erstaunlich responsive – immerhin werden mit jedem Klick eine Tabelle mit einer halben Million Einträge sechsmal durchsucht, der Tag in 60 Viertelstunden zerteilt und anschließend die Auslastung live berechnet.
Der innerste Kern meiner Tätigkeit als Softwareentwickler ist die Erschaffung von Algorithmen. Dass das deutlich spannender sein kann als es klingt, will ich anhand eines aktuellen Projekts zeigen.
Beginnen wir mit einer Aufgabe: Gegeben ist die dargestellte Auslastung von vier Hörsälen. Es soll nun eine weitere Veranstaltung zwischen 13:00 und 14:00 (blau markiert) gebucht werden – welcher Raum ist nicht nur verfügbar, sondern auch optimal passend?
In welchem Raum soll der gewünschte Termin (13:00 bis 14:00) untergebracht werden?
Als Algorithmen werden in der Informatik Handlungsanweisungen zur Lösung eines Problems verstanden. Algorithmen können so etwa als Kochrezepte für Computerprogramme verstanden werden. Sie berechnen Manager-Boni, kümmern sich bei Word um die Rechtschreibkorrektur, twittern Aktienkurse oder – wie in meinem Fall – verhelfen der WU künftig zu einer optimierten Ausnutzung der Ressource Raum.
Algorithmisches Denken ist die Umkehrung von Schul-Mathematik. Beim Programmieren ist die Lösung bekannt, aber es gilt den Weg dorthin zu entdecken.
Das Teaching Center am Campus WU: Stählerner Schauplatz für Raumbuchungs-Tetris im XXL-Format. Mathias, 2012.
Jedenfalls: Bei unserem Re-Write der Raumverwaltung für den Campus WU sind wir mit einigen, höchst spannenden Anforderungen konfrontiert: Raumbuchungen sollen künftig automatisch und optimal durchgeführt werden, den Administratoren bleibt allerdings jedwede Flexibilität erhalten. Die Software kümmert sich dabei um Studien- wie Stundenpläne, um Verfügbarkeit der Lehrenden und “Extrawürschteln” ebenso, wie um Minimierung von Buchungslücken oder Reduktion unnötigen Reinigungsaufwands aufgrund zu vieler, “angepatzter” Hörsäle. Die Ressourcen sollen flexibel verfügbar sein (Stichwort dynamische Lagerhaltung), ein allzu häufiger Ortswechsel macht Studierende wie Lehrende aber wohl kaum glücklich.
Wir benötigen daher wieder einmal den “Do what I want“-Button:
+-----------------+
| |
| DO WHAT I WANT |
| |
+-----------------+
Button, der in jeder Software genau
das tut, was der User will.
(Grobkonzept)
Von der Idee zum Algorithmus
Die Aufgabenstellung lautet demnach:
Liefere für eine Serie von Terminen (z.B.: ein ganzes Semester) Buchungsvorschläge
innerhalb der angefragten Raumkategorie,
versuche dabei die gewünschten Zeiten zu erfüllen,
d.h. immer dieselbe Beginnzeit zu ermöglichen,
vermeide außerdem Raumwechsel,
aber vermeide noch viel mehr den Wechsel von Gebäuden.
Beachte, dass Buchungen nahtlos aufeinanderfolgen sollten.
Entstehen dennoch Lücken, so sind z.B.: 30 Minuten sehr schlecht, weil dieser Zeitraum sicher verloren ist,
90 Minuten hingegen sind gar nicht so schlimm, weil ja noch etwas reinpassen könnte.
Bereits “angepatzte” Räume sind leeren vorzuziehen, weil dadurch der Reinigungsaufwand verkleinert wird.
Geistreiche Bilder vom Entstehungsprozess des Algorithmus. (…)
Die Grenzen der Berechenbarkeit
Ein naiver Lösungsansatz wäre nun, alle Möglichkeiten zu versuchen und die beste zu wählen. (Tatsächlich funktionieren viele Algorithmen nach diesem Prinzip.) In diesem Fall bekommen wir aber ein Problem mit der Dimension der Aufgabe:
Will etwa jemand an acht Montagen irgendwann zwischen 9:00 und 12:00 eine zweistündige Lehrveranstaltung abhalten, so ergeben sich (zu) viele Buchungsmöglichkeiten. Entlang eines 15-minütigen Rasters erhalten wir zunächst fünf mögliche Beginnzeiten (9:00, 9:15, 9:30, 9:45, 10:00). Diese fünf Beginnzeiten über rund 50 gleichwertige Seminarräume an acht Montagen ergeben acht mal fünf mal 50 – also zweitausend – Einzelmöglichkeiten. Die Berechnung der Kombinationsmöglichkeiten ergibt 15 Quintillionen [sic - 250hoch8 - eine 15 mit 18 Nullen]!
Wir reden allerdings nicht nur von einer Veranstaltung, sondern von knapp 4000 jährlich mit rund 35000 Einzelterminen – Tendenz Dank erweiterter Buchungsmöglichkeit für Mitarbeiter und Studierende stark steigend. Selbst wenn ein leistungsfähiger Rechner eine Milliarde Kombinationen pro Sekunde ausprobieren würde, wäre die erste Raumbuchung erst nach knapp 500 Jahren fertig…
Tetris
Glücklicherweise gibt es Tetris! Ähnlich wie bei den von oben fallenden Steinen kommen auch die Buchungswünsche Schritt für Schritt herein. Jede Buchung muss auf die jeweils aktuelle Belegung Rücksicht nehmen, kümmert sich aber nicht um das, was noch kommt. Genauso wie bei Tetris ist es auch bei Raumbuchungen sinnvoll, Lücken bestmöglich zu füllen, oder doch für passgenaue Steine in naher Zukunft frei zu halten.
Tetris-Klon von Nintendo: Dr. Mario. Aufgrund unseres akademischen Kontexts an der WU die wohl bessere Analogie.
Die Matrix
Tetris-Analogie hin oder her, noch besteht das Problem der zu vielen Lösungen. Manchmal hilft es, die Aufgabenstellung in kleine Teile zu trennen, das Problem zu abstrahieren, sich typische Situationen aber vor allem auch Grenzfälle (corner cases) zu überlegen.
Eine Terminserie zu unterschiedlichen Beginnzeiten, in Gebäuden und darin enthaltenen Räumen entspricht einer vierdimensionalen Matrix, so einer Art Excel-Tabelle, wo in jeder Zelle nochmal eine Tabelle enthalten ist. (Keine Sorge, so etwas kann auch ich mir nicht wirklich vorstellen.)
Die Einträge in dieser Matrix sind jedenfalls:
pro Termin
pro Beginnzeit
pro Gebäude
jede verfügbare Raumnummer
mit Bewertung der Passgenauigkeit
Die Passgenauigkeit beträgt 1, wenn der Raum einfach frei ist, 0 wenn er gebucht ist. Sollte ein Termin nahtlos reinpassen, erhöht sich der Wert über 1, bleiben Lücken, so bekommt der Raum Strafabzüge. Die Datenstruktur sieht früher oder später so aus:
Die beste Lösung findet man nun nicht durch stumpfsinniges Ausprobieren, sondern durch geschicktes Durchschreiten der Datenstruktur. Der Lösungsweg lautet:
FÜR jede Terminanfrage
FÜR jede Beginnzeit gereiht nach Häufigkeit terminunabhängig
FÜR jedes Gebäude gereiht nach Häufigkeit in Beginnzeit
FÜR jeden Raum gereiht nach Passgenauigkeit in Beginnzeit
VERSUCHE zu buchen
ODER gehe weiter
Die Lösung der eingangs gestellten Aufgabe lautet übrigens “Raum B”. Oder wenn Sie zufällig ein Algorithmus sind:
Dem so genannten Octopus habe ich mich an dieser Stelle bereits ausgiebig gewidmet. Der von uns als Buckelwal bezeichnete Kiosk-Terminal kam bislang zu kurz. Hier also ein schnelles Update.
Der Anwendungsfall ist nicht neu: Im öffentlichen Bereich der WU Wirtschaftsuniversität Wien sollen Kiosk-Terminals schnellen und unkomplizierten Zugang zu Informationen, also dem Internet, sichern. Seit mehr als zehn Jahren gibt es mit der so genannten ByteBar bereits eine Lösung. Inzwischen macht sie vielleicht optisch nicht mehr allzu viel her – auf Seiten der Zuverlässigkeit und Wartungsarmut läuft das System allerdings beeindruckend vor sich hin.
ByteBar WU Wirtschaftsuniversität Wien.
Als ich mir gegen Ende 2010 das erste Mal Gedanken machte, was man am Baulichen und Haptischen verbessern könnte, fiel mein Blick auf die Suchmaschine bei Ikea. Diese vereint in durchdachter Schlichtheit und Pragmatik Features wie Stabilität, Touchscreen und/oder Tastatur, Kosteneffizienz, Servicierungskonzept, Sicherheit und Raumausnutzung.
Bei Ikea wissen die Designer was sie tun: Optimale Raumausnutzung, Schutz gegen Wagerl-Kollisionen, Kosteneffizienz. Mathias, Ikea Wien Süd (2010)
Mit dem schwedischen role model im Gepäck beauftragte ich 2011 einen Kiosk-Hersteller mit der Anfertigung eines Prototypen. Aus Designgründen entschieden wir, die Hardware hinter der Oberfläche verschwinden zu lassen, unterschiedliche Arbeitsplatzhöhen sollten außerdem unser Bekenntnis zu mehr Barrierefreiheit verdeutlichen.
Rendering unseres Prototypen: Unterschiedliche Arbeitsplatzhöhen, viel Karma für Design-Götter.
Nach Liefer-Verzögerungen und einigen Tests wurde der Prototyp Februar 2012 an der WU aufgestellt. Die Software läuft nach wie vor noch nicht so, wie wir uns das am Ende vorstellen. Aber Sinn und Zweck eines Prototypen ist ja eben der vorzeitige Erkenntnisgewinn.
Steht seit Februar 2012 an der WU für öffentliche Tests.
Öffentliches Internet versus die Abwehr anonymer Surfer
Der Großteil des studentischen Feedbacks auf Facebook drehte sich schon bald um die Haptik der Tastatur. Ich ahnte bis dato jedenfalls nicht, wie viel Emotion im Tastatur-Thema liegen kann. Nach einer Abstimmung unter den Studierenden fiel die Wahl schließlich auf eine (hygienische) Metalltastatur mit Trackpad.
Ende Juni veröffentlichte ich das Abstimmungsergebnis auf Facebook. Gleich die allererste Reaktionen sollte das Thema Browser/Software nochmal komplett drehen:
“Viel wichtiger wäre es wenn das ZID es endlich mal schaffen würde das man auf der WU eigenen (!) Homepage endlich die Suchfunktion nutzen könnte! Ich habe dass schön mehrmals angeregt bin bis jetzt aber immer auf taube Ohren gestoßen.”
Studierender auf Facebook
An der ByteBar erhält man beim Aufruf WU-fremder Seiten eine Fehlermeldung: Der Zugriff auf externe Seiten wird nämlich verhindert, um Surfzeiten zu begrenzen und somit Wartezeiten für andere zu verkürzen. Diese Maßnahme erachte ich allerdings aus zwei Gründen für höchst fraglich:
Im Zeitalter von Web 2.0, Cloud und whatever liegen nunmal sehr viele nützliche Dinge nicht innerhalb der WU. Spätestens bei der outgesourcten Suche über Google – wie oben mokiert – wird die Sache peinlich.
Die Begrenzung des Internetzugangs war vor zwölf Jahren sicher sinnvoll. Doch ist sie das dank Breitband und Smartphones noch immer?
Mein Vorschlag, Internet einfach “aufzudrehen”, fand jedenfalls keine Mehrheit. Ich kann die Bedenken nachvollziehen, dass dadurch jeder Fremde an die WU surfen kommen könnte – unangenehm wird das jedenfalls bei strafbaren Aktionen im Netz… Kurzum: Ein Login-Mechanismus musste her.
Python + WebKit + Studierendenausweis
Gemeinsam mit unserem kongenialen Hightech-Partner La Gentz war schnell die Idee geboren, den Studierendenausweis alternativ zur mühsamen Username/Passwort-Authentisierung zu verwenden. Eine Authentisierung soll innerhalb kürzester Zeit erfolgen – das simple Hinhalten der MIFARE-Karte erfüllt diese Anforderung perfekt.
Außerdem entschieden wir uns, einen WebKit-basierten Browser from scratch zu implementieren. Das erspart die mühvolle Arbeit, den Browser gegen noch so kreative Usereingriffe abzusichern. Ein Login-Widget liegt semi-transparent über den Inhalten des Browserfensters und fordert zum Hinhalten der Karte auf. Aktuell überprüfen wir das UI noch auf seine Usability.
Details zur technischen Umsetzung finden sich im La Gentz Blog.
Fehlermeldung im unauthentisierten Betrieb. Das semi-transparente Widget lädt zum Einloggen via Karte oder Username/Passwort ein.
Nach dem Login ist unbegrenztes Surfen möglich. Ein Countdown visualisiert die verbleibende Zeit im Falle von Inaktivität.
Siehe da: Nach dem Login darf ich unbegrenzt surfen. Danach kann ich mich abmelden oder werde nach 1:30 Inaktivität automatisch rausgeschmissen.
Mit Ubuntu ist ein Betriebssystem ohne Wintendo-Krankheiten gefunden, LDAP bzw. JSON-RPC dienen zur Authentisierung. Demnächst folgt noch der Netzwerk-Boot (ähnlich den Door Displays).
Somit ist Websurfen künftig zufriendenstellend möglich, und wir brauchen keine Angst vor Internet-absaugenden Massen zu haben;-)
Auf meinem Flug nach Mumbai sehe ich eine Dokumentation über den Bau des Londoner Aquatics Centre, dem Landmark der Olympischen Spiele 2012. Selbe Architektin, noch größere Dimensionen spielen sich bekanntlich derzeit am Campus WU ab. Angesichts dieser ehrfurchtgebietenden Superlativa drängt sich eine Frage auf, die ich in den vergangenen Monaten immer wieder gehört habe: “Warum wird die Campus-Software von der WU selbst und nicht von professionellen Anbietern entwickelt?”
Eigentlich sind es zwei Fragen, die hier gestellt werden:
Warum greifen wir nicht auf Standard-Software zurück?
Warum wird Individualsoftware nicht durch Externe entwickelt?
Eins vorweg: Natürlich verwenden (und vor allem integrieren) wir Standardsoftware. Softwareentwicklung wird bei uns in den unterschiedlichsten Konstellationen und natürlich auch von Externen durchgeführt. Aber wir entwickeln etwa mit der Raumbuchung, dem automatisiertem Schließsystem oder den digitalen Hörsaalanzeigen viele Kernthemen der IT am Campus aus gutem Grund selbst.
Kabeltassen im Gebäude W1E - hier fließt schon bald unsere Software durch die Leitung.
Um bei einer Metapher des Bauprojekts zu bleiben wirkt es so, als ob wir unsere eigenen Maschinen, unseren eigenen Stahl und unseren eigenen Beton herstellten. Was bei klassisch-produzierenden Unternehmen sich wohl kaum rechnen würde, ist in der Softwareentwicklung allerdings Normalität. Durch den Wegfall von Fixkosten (keine Stahlwerke notwendig) und die de-facto nicht gegebene Standardisierung habe ich bei jedem Teilprojekt die Möglichkeit, eine individuelle make-or-buy Entscheidung zu treffen.
Make or buy?
Für eine Eigenerstellung sprechen jedenfalls die Kosten: Um Urlaubs- und Fehlzeiten bereinigte Stundensätze interner Entwickler betragen rund ein Drittel jener von Externen. Dass bei Dienstleistern und Softwarehäusern ständig die richtigen Experten abrufbereit säßen, ist ein leider allzu weit verbreiteter Irrglaube. Hüben wie drüben muss man Einarbeitungszeiten, Schulungen und Irrwege letztlich bezahlen.
Kommunikation unter Kollegen ist jedenfalls einfacher, als Projektmanagement zwischen Unternehmen. Mit Pflichten- und Lastenheften, die Sales oder Legal jedoch nicht den Entwicklern dienen, mit juristischen Prozessen rund um Beschaffung oder service level agreements, mit Excel-bewaffneten Consultants, die eine zusätzliche Abstraktionsschicht zwischen Anforderung und Umsetzung einziehen, entwickeln sich IT-Projekte sehr schnell zu bürokratischen Meeting-Marathons. Auf diesem Weg entstandene Software tut am Ende oft ganz anderes, als es die Prozessdokumentation sagt, und die Kosten stehen schließlich in zweifelhaftem Verhältnis zum Ergebnis. Ich habe mehrfach die paradoxe Situation erlebt, dass ein schneller, interner Hack bereits fertig war, bevor noch ein Kick-Off stattfand. (…)
Gleichzeitig gibt es allerdings eine Reihe an IT-nahen Dienstleistungen, die sehr gut ausgelagert werden können: Betrieb von Hardware, Grafik-Design oder Dateneingabe sind Beispiele, wo ich kaum überlegen würde.
Immer wenn die technischen Anforderungen entweder niedrig oder extrem hoch sind, jedenfalls aber wirklich nur wenn die Anforderungen der Benutzer klar sind, dann zahlt sich Outsourcing aus.
Denn dann sind Leistungen überschaubar und somit Preise verhandelbar, und man profitiert vom Spezialwissen der Experten. (Das Stacey Diagramm lässt sich also womöglich auch für make-or-buy Entscheidungen vergewaltigen.)
Die Standarsoft-Mär
Wäre die Diskussion über die Vorteile interner und externer Individualentwicklung nicht ohnehin hinfällig, würde man von vornherein auf Standardsoftware setzen? Nun, vieles, was bei Individualentwicklung zum Einsatz kommt, ist ohnehin standardisierte Software in Form von Betriebssystemen, Datenbanken, Frameworks und Libraries. Software zu entwickeln bedeutet zu einem großen Teil, derartig generell-anwendbare Bausteine zu einem individuell-leistungsfähigen System zu kombinieren.
Gleichzeitig ist vieles, was Standardsoftware heißt, fernab von Standardisierung, wie man sich das etwa bei einem Auto vom Fließband vorstellt. Auch wenn Banken, Airlines oder eben Universitäten Software der Big Player einsetzen, so passiert bei der Integration ins Unternehmen zwangsweise immer wieder dasselbe: Früher oder später enden die Möglichkeiten des Customizing, und Berater, Sub-Firmen oder interne Entwickler schreiben spezialisierte Programme, um das Ding zum Laufen zu bringen. Das bedeutet aber auch, dass die Abhängigkeit von einzelnen Personen auch bei Standardsoftware nicht geringer ist.
Business-IT ohne Abhängigkeit von einzelnen Schlüsselpersonen ist eine Mär!
Mit steigender Komplexität der Anforderungen wird es also zunehmend unwahrscheinlich, dass ein Anbieter genau das erfüllt, was ein ein Unternehmen benötigt. Das Resultat heißt bei Standardsoftware dann erst wieder Individualentwicklung.
Indien - Land der IT-Hotlines und heiligen Kühe. Mathias, Mumbai 2012.
Und hier schließt sich der Kreis, zu den oben gestellten Fragen. Ich genieße jetzt mal meine Tage in Indien – übrigens ein Land, wo mein Job aus genannten Gründen doch nicht so schnell hinwandern wird…
Meine Blog-Posts zum Thema Campus WU drehten sich bislang eher um Hardware-Projekte. (SB-Terminals, Infoscreens, elektronische Türschilder, etc. – alle müssen mit großer Vorlaufzeit geplant und beschafft werden.) Dabei gibt es mit der Raumverwaltung ein Software-Thema, das sich aus zwei Gründen zu meinem Lieblingsprojekt entwickelt: Einerseits stellt eine Raumbuchungssoftware DAS absolute Querschnittsthema in einem intelligenten Gebäude dar, andererseits wird unser Projekt die Art und Weise, wie Menschen am Campus zusammentreffen um zu lehren, forschen und lernen, nachhaltig verändern. Davon bin ich inzwischen überzeugt.
Room Resourcing – hinter diesem Anglizismus versteckt sich ein WU-weites Projekt, welches die unbürokratische und vor allem effiziente Bereitstellung von Räumen am Campus 2013 zum Ziel hat. Zum process owner gekürt, treffe ich in diesem Projekt, anders als in meiner sonst dienstleistenden Rolle als IT-Fachkraft/Nerd, auch inhaltliche Entscheidungen.
Ausgangslage
An der WU werden pro Semester einige tausend Veranstaltungen abgehalten. Der überwiegende Teil davon ist dem Bereich Lehre zuzuordnen, der – wenig überraschend – unseren Kernprozess darstellt. Die Buchung von Lehrveranstaltungen hat folglich mit zahlreichen Regelungen und Randbedingungen wie Gesetzen, Dienstverträgen, Gehaltsabrechnungen oder Studienplänen zu tun. Die Buchung eines Meetingraums in einem beliebigen Bürogebäude ist mit unseren Anforderungen jedenfalls wenig vergleichbar.
Derzeit werden diese Buchungen über eine zentrale Stelle organisiert. Nur so kann sichergestellt werden, dass alle Veranstaltungen in ein räumlich doch sehr begrenztes Gebäude passen. Buchungswünsche abseits der Lehre, werden von einer separaten Organisationseinheit in ebenso separaten Raumgruppen gebucht. Es wird also ein Prozessproblem durch Aufteilen der Flächen umgangen, was teilweise dazu führt, dass Anfragen trotz freier Ressourcen im anderen Bereich nicht erfüllt werden können.
Veränderte Bedingungen
Durch den Umzug auf den Campus WU wird eines der zentralen Probleme der Universität (großteils) der Vergangenheit angehören: Platznot. Moderne und vielseitig nutzbare Veranstaltungsflächen, Hörsäle, Seminar-, Projekt- und Meetingräume werden Lehre und Forschung Platz schaffen und ihnen dadurch neue Qualität verleihen.
Dennoch wird es weiterhin Engpässe geben. Beliebte Wochentage, Uhrzeiten oder uni-typische Saisonen werden nach wie vor zu Nachfragespitzen führen, die selbst mit dem doppelten Raumangebot nicht befriedigt werden könnten.
Die Herausforderungen bei der Erstellung eines Raumverwaltungssystems besteht demnach im Lösen eines Verteilungsproblems. Dazu kommen einige interessante Ideen – hier also unser Plan:
Chaos pur!
Wie schafft man es also, ein Mehr an Veranstaltungen in einem fix dimensionierten Gebäude unterzubringen? Die Antwort lautet chaotische Lagerhaltung. Dieses Logistik-Konzept beschreibt Lager ohne festes Ordnungssystem. Das bedeutet, dass Pakete dank Identifizierung via Barcodes oder RFID genau dort abgelegt werden, wo sie haargenau Platz finden. Lager werden dadurch besser ausgelastet, Ranbedingungen wie etwa Wegzeiten außerdem optimiert.
Umgelegt auf unser Raumbuchungssystem werden Veranstaltungen eben genau in jenen Räumen platziert, die möglichst lückenlos frei stehen. Es werden also neue Ressourcen frei, weil etwa 45minütige Leerstände oder nicht notwendige Rüstzeiten (Änderung der Bestuhlung) reduziert werden. Ein Leitsatz bei unseren Planungen war es, dass die räumliche Flexibilität der Lehrenden eher eingefordert werden sollte, als die zeitliche. Oder andersrum: Lehrende sollen zu ihren Wunschzeiten lehren, müssen aber mit einem automatisiert zugewiesenen Raum auskommen.
Ich wähle meine Wunschzeit, die Software weist mir automatisch einen passenden Raum zu.
Um gleich ein Gegenargument zu entkräften: Gelegentliche Ortswechsel einer wöchentlichen abgehaltenen Veranstaltung bedeuten kein großes Malheur, da die Räume ohnehin standardisiert sind. Denn obwohl 2013 mehr Räume zur Verfügung stehen werden, wird es weniger unterschiedliche Raumtypen geben. Ein Bereitstellen der Buchungslage auf Smartphones und Infoscreens reduziert den Planungsaufwand auf ein vertretbares Minimum: Man wird immer sehr schnell sehen können, wo man hin sollte.
Von 5 auf 30.000 Nutzer_innen
Der zweite Paradigmenwechsel passiert auf Ebene der Buchenden selbst. Zurzeit sind das etwa fünf Personen, da der Prozess zentralisiert ist. Doch mit kommenden Jahr will die WU die Buchung in die Hände der Mitarbeiter und Studierenden geben! Alle Menschen an der Universität erhalten dann die Möglichkeit, ihre Veranstaltungen dezentral zu reservieren, unbürokratisch zu verschieben, kurzfristig nach Flächen zu suchen, usw.
Je mehr ich über diese De-Zentralisierung nachdenke, desto mehr freue ich mich auf den Campus WU. Eine Universität, die ihren Mitarbeitern und Studierenden qualitativ hochwertige Räume zur Verfügung stellt, ist ein spannender Ort zum Lernen und Forschen – ein Nährboden für große Leistungen!
Mock-up der Ansicht für Mitarbeiter wie Studierende.
Natürlich gibt es eine Reihe an Randbedingungen wie Planungssicherheit für Lehrveranstaltungen oder Fair Use, da wichtige Veranstaltungen stattfinden müssen, und es nicht sein kann, dass Spaßvögel das Haus “voll-reservieren”. Dem Problem wird mit einem Berechtigungssysten begegnet, welches elegant – weil einfach – als Etappenbuchung konzipiert ist: Lehrveranstaltungen werden frühzeitig eingebucht, Mitarbeiter können ihre Besprechungen erst danach fixieren. Studierende können lediglich kurzfristig nach Räumen für ihre Lerngruppen suchen.
Da wir unsere Software agil entwickeln, ist ein kleiner Bestandteil dieses Moduls bereits produktiv und wird auch heftig genutzt. (Raumansuchen Online)
Querschnitt wohin man schaut
Ich habe das Projekt oben als Querschnittsmaterie bezeichnet und wahrlich, die Software ist der Behälter, wo all das Wissen, all die Konzepte und Überlegungen zum Neubau zusammenfließen.
Elektronische Beschilderung ist das Um und Auf in einem Gebäude, dessen Flächen dynamisch vergeben werden. Schon jetzt versuchen wir mit QR-Codes und NFC-Tags, die physische Welt der Räume mit der Online-Welt zu verknüpfen. Das Öffnen und Schließen eben dieser Säle funktioniert nur in enger Kopplung mit einem Schließsystem, welches vollelektronisch sein und mit Studierenden- wie Mitarbeiterausweis funktionieren wird. Ein Geoinformationssystem kann die Lage der Räume visualisieren, oder auch Räume in unmittelbarer Nähe publizieren. Die Buchung selbst wird via für Smartphones optimierter Webseiten erledigt, oder auf Terminals, die ebenso ein großes IT-Projekt im Schnittpunkt Hardware und Architektur darstellen.
Aus Spaß habe ich alle Software-/Hardwareprojekte mit Codenamen versehen. Als Taucher fiel meine Wahl auf Fische und andere Meeresbewohner. Room Resourcing ist aber kein weiteres Tier, es ist eher der Ozean selbst in dem alle schlussendlich zusammenspielen.
Insofern wird mit diesem Eintrag und dem Themen-Rundumschlag gegen Ende der Countdown zur Inbetriebnahme des Campus WU eingeläutet. Dieser Blog hilft mir persönlich, meine Projekte zu strukturieren und den Fokus nicht aus den Augen zu lassen. Meine Projekte gehen zwischen Jänner und Juni 2013 in die heiße Phase – Danke fürs Lesen // Kommentare willkommen!
tltr;
Am Campus WU wird die Raumbuchung dezentralisiert, unbürokratisch, teils automatisiert und mit vielen, vielen weiteren IT-Themen vermengt.
Das Projekt liegt derzeit auf Eis, weil meine Begeisterung nicht immer geteilt wird. Technisch funktioniert der beschriebene Ansatz allerdings sehr wohl.
Digital Signage bedeutet nichts anderes, als Beschilderung mit Hilfe von Bildschirmen und dahinter liegenden Informationssystemen. Es wundert mich nach wie vor, wie etwas derart Triviales so ein Hype sein kann…
Am Campus WU werden rund 300 Displays für Personenleitung, Terminübersicht, Information und Eigendarstellung sorgen. Bislang sind alle Konzepte, in denen man mit STRG+F das Wort content findet, frei von Werbung, was ich aus Sicht der Gebrauchstauglichkeit aber auch politischer Überzeugung sehr gut finde. Was wir mit den kleinen Door-Displays vorhaben, habe ich bereits gebloggt. Diesmal will ich ein paar Zeilen zu den größeren Infodisplays schreiben.
Digital Signage: Systeme und Hardware
Mitten in einem Bauprojekt sind verständlicherweise Software-Themen noch kein großes Ding. Daher lag auch bislang das Hauptaugenmerk bei der Positionierung der Displays und den benötigten Netzwerk- und Stromanschlüssen. Letzteres hat aber bereits sehr viel mit den später (hoffentlich noch) möglichen Systemen zu tun. Wir wollten uns jedenfalls ein Maximum an Flexibilität offenhalten. Folgende Entscheidungen wurden daher getroffen und inzwischen – wortwörtlich – betoniert:
Display und Rechner aus Wartungsgründen getrennt und damit keine Panel-PCs. Dadurch sind aber auch zwei Stromanschlüsse notwendig.
1920 x 1080 Pixel / Full-HD am Display.
HDMI zwischen Display und Rechner. Wenn der Rechner schläft, geht das Display automatisch schlafen, womit wir uns die übliche Steuerlogik über RS-232 sparen.
x86-Architektur beim Rechner und folglich kein dezidierter digital signage player. Damit bleiben alle Optionen für Spielereien oder denkbar andere Sensoren offen.
Qualitative Benchmark: Flüssiges Darstellen von Full-HD Video via Netzwerk.
Während im 9. Bezirk Rechner-Spezifikationen ausgetüftelt werden, werden im 2. Bezirk bereits Kabelkanäle in Beton gegossen. Campus WU, Dezember 2011.
Neben Investitionskosten sind ebenso Wartungskosten erheblich, da die Rechner an schwer zugänglichen Stellen und in hoher Stückzahl vorhanden sind. Stromverbrauch ist, selbst über die gesamte Lebensdauer betrachtet, kein relevanter Kostenfaktor, aber das Bauprojekt schreibt sich aus gutem Grund das Wort green auf die Fahnen. Der fit-pc 3 hat jedenfalls laut unseren Kalkulationen die beste total cost of ownership (TCO), da bewegliche und somit wartungsanfällige Teile gänzlich fehlen, und die robuste Bauweise überdies Langlebigkeit verspricht. Mit 7-15 Watt Leistungsaufnahme besitzen alle rund 70 Rechner zusammen genommen den Stromverbrauch eines halben Händetrockners.
Digital Signage “Solution”
Der Markt für Digital Signage Software ist unüberschaubar groß, und die Angebote richten sich aufgrund der Nähe zur Werbewelt nicht an Techniker. Dementsprechend orientieren sich auch die Features der Produkte an Anforderungen der Werbeplatz-Verkäufer; die Produkt-Kataloge sind voller Reizwörter: turnkey solution, industry-leading & award-winning, plug & play.
Die Empirie lehrt mich jedoch, dass die bunten Schirme mit den professionellen ‘”Solutions” zum Teil erschreckende Ausfallzeiten besitzen. In den vergangenen Monaten habe ich eine beeindruckende Sammlung an Handy-Fotos von Fehlermeldungen derartiger Schirme auf Bahnhöfen, Flughäfen, Universitäten, Fachhochschulen, Einkaufszentren, usw. zusammengetragen.
Windows-Warnhinweis über zwei Wochen auf der großen Leinwand in der WU-Mensa sichtbar...
Zeit also, mit Hirn, Neugierde und etwas Arroganz das Thema richtig anzupacken.
Eine bessere Architektur
Ein Designfehler wirklich jedes einzelnen Digital Signage Systems, das ich in den vergangenen zwei Jahren angesehen habe, ist die Vermischung von Content Management und Content Scheduling.
Die Frage, welche Inhalte wo und wann angezeigt werden, ist ein gänzlich anderer Aufgabenbereich, als das Erstellen der Inhalte selbst. Bei einer Installation von Größenordnung und Komplexität der WU (6 Gebäude, 200 Lehr- und Projekträume, 80 Institute, mind. 250 Autoren, 70 große Bildschirme) sind diese Aufgaben in unabhängige Module zu trennen.
“Do one thing and do it well.” Doug McIlroy
Dieser, zum Unix-Kanon gehörende Designansatz ist für mich inzwischen zu einem zentralen Punkt all meiner beruflichen Entscheidungen geworden.
Content Management
Für die Aufgabe der Erstellung von Inhalten gibt es ein seit Jahren stabil laufendes Tool samt Support, motiviertem Team und geschulten Anwendern: Das CMS der WU. Anstatt also ein paralleles CMS für Digital Signage einzuführen, wird das bereits bekannte System mit-verwendet. Dadurch gewinnen Inhalte sowohl im Web, als auch auf den Schirmen an Aktualität, es entfallen doppelte Administration und Schulungen. Ich finde den Ansatz elegant, kosteneffizient und risikominimierend zugleich.
Dabei müssen die Inhalte auf den Bildschirmen nicht notwendigerweise wie Inhalte auf der Webseite aussehen. Denn was zwar im Backend nur einmal erstellt wird, kann im Frontend durchaus für den jeweiligen Anwendungsfall optimiert dargestellt werden.
Publikation der WU-Webseite für Signage-Bildschirme gerendert: Größere Schrift, erhöhte Kontraste, wenig Text, keine Navigation o.ä. (Test an der WU)
Content Scheduling
Welcher Inhalt wann, wo und vor allem auch wie oft geschalten wird, bedeutet für werbefinanzierte Installationen das Um und Auf. Viele Systeme bieten hier zahlreiche Features von Zeitleisten, die per Drag&Drop bedient werden, bis hin zu Statistik-Tools, die zur Abrechnung gegenüber den Werbetreibenden verwendet werden.
Für eine Universität sind diese Funktionen allerdings unnötig und schlicht zu komplex. Die einzige Notwendigkeit ist eine Zuordnung zwischen den Inhalten aus dem CMS (als RSS-Feeds) und den jeweiligen Schirmen. Damit laufen dann Lehrveranstaltungen vor den Hörsälen und Informationen der Bibliothek eben vor dieser. Natürlich will man auch priorisierte Inhalte über den gesamten Campus verteilen, oder Lücken mit niedriger priorisierten Meldungen auffüllen.
Gemeinsam mit dem Python- und JavaScript-Profis von La Gentz haben wir einen als Dispatcher bezeichneten Server implementiert, der genau diese Aufgaben erfüllt. Dieser Mechanismus holt aus beliebig vielen Backends die jeweiligen RSS-Feeds und verteilt deren Inhalte letztlich auf den Schirmen. Die Client-Rechner erhalten demnach URLs und fordern ihre Inhalte per Web-Request an.
Technischer Knackpunkt der Lösung ist übrigens die Multi-Display-Anzeige von Kursen. Mehrere parallele Displays sollen an Punkten mit hoher Besucherfrequenz gemeinsame Inhalte zeigen. Es ist wichtig, dass ein Folienwechsel gleichzeitig passiert; etwas, was mit Standard-Webtechnologien allerdings gar nicht so leicht hinzubekommen ist. Die aussichtsreichste Lösung scheinen WebSockets, der aktuell “heißeste Scheiß” im Internet, zu sein. Der Tüftler-Geist der Beteiligten ist jedenfalls geweckt – und ich darf zuversichtlich sein.
Vergleich konventioneller Systeme zu unserem Ansatz: Bestehende CMS werden über RSS-Feeds eingebunden, der "Dispatcher" sagt den Displays, welche URLs sie aufrufen müssen. Ganz einfaches HTML, keine Magie.
Client-Installation
Ein Techniker, der auf einer Leiter stehend, das Betriebssystem einer Überkopf-Anzeigetafel updated? Immer wieder beobachtet – lächerlich und traurig zugleich. Unser System sieht einen Netzwerk-Boot mittels PXE vor. Auf den Rechnern selbst läuft lediglich ein aktueller Chromium-Browser, da die Inhalte alle online zur Verfügung stehen und das Netzwerk schnell und ausfallsicher genug ist. Den Rechnern wird in Abhängigkeit von ihrer IP-Adresse der jeweilige Content zugeordnet. Mit Wake On LAN können auch über Nacht abgeschaltete Rechner morgens wieder ihre Arbeit aufnehmen – mit neuem Betriebssystem vom zentralen Server wohlgemerkt.
Fazit (tltr;)
Unser Ansatz lautet, bestehende CMS als Backend eines Digital Signage Systems zu verwenden. Dabei soll das System auf Web-Standards beruhen. Wer bis hierher gelesen hat, hat sich das Video vom Prototyp verdient – die Rechner sind übrigens sieben Jahre alt.
Ein kurzes Update zu unserem Projekt Octopus, einfach weil’s so geil läuft. (Und ich hasse normalerweise das Wort geil, aber in diesem Fall ist es angebracht!)
Unser heldenhafter Möbelprofi hat’s vollbracht: Alle Komponenten sind im Gehäuse sicher und für zukünftige Wartungen optimiert untergebracht. Außenrum bleibt das Interface “clean” und daher für die Benutzer übersichtlich. Der A4-Drucker ist dank Umbau des Papierauswurfs runter auf eine Fehlerrate von 1:300 und somit unterhalb der Quote, die wir mit den Originalteilen des Herstellers messen. Sämtliche Bedienelemente befinden sich in Greifhöhe für Rollstuhlfahrer. Die L-förmige Lichtleiste wird das Bedienkonzept einer Art “Farbleitung” ermöglichen. Aber was schreibe ich, wenn es Bilder gibt:
Der Mock-up ist beinahe fertig. Ursprüngliches Ziel - ein "cleanes" Interface - geschafft.
Materialkunde
Für jemand, der normalerweise mit Bits und Bytes zu tun hat, ist die Wahl der Materialen zugegebenermaßen eine Herausforderung. Immerhin sind Langlebigkeit, Kosten, Widerstandsfähigkeit gegen Reinigungsmittel und Vandalismus zu bedenken. Unser Ergebnis: Weiße Melaminplatte auf blankem Stahl – passend zum Gebäude, das mit Sichtbeton und schrägen Wänden auffallen wird.
Lokalaugenschein am künftigen Standort - ein echter Business-Termin.
Software: Python, Python, Python!
Abseits vom Möbelstück hat sich auch bei der Software unglaublich viel getan.
So wurde etwa beim Bezahlmodul eine proprietäre Library durch eine quelloffene Implementierung des Protokolls ZVT 700 in Python ersetzt. Damit können wir, von der Plattform unabhängig, den Leser der Card Complete einsetzen. “Abfallprodukt” dieser Entscheidung ist, dass wir künftig auch Zahlungen per Kreditkarte akzeptieren können.
Integration "Bankomat": Hard- und Software verschmelzen mit unserem Terminal.
Bei Webcam und den drei (!) Druckern lautete die Marschrichtung ebenso hin zu offenen Schnittstellen. Protokolle wie Apples CUPS machen die Ansteuerung der einzelnen Komponenten einfach(er), da viel der Komplexität versteckt wird. Anstatt des Modells “Treiber + lokal Anstecken” hat sich ein rein TCP/IP-basierter Aufbau durchgesetzt.
Als User Interface Library fiel die Wahl auf Nokias Qt - ein Wahnsinn in Sachen Flexibilität und Robustheit. (Nicht zuletzt darum tut mir der Einstieg von Windows Phone 7 bei Nokia im Herzen weh…) Die Python Bindings für Qt (PyQt) ermöglichen die Entwicklung in reinem Python-Code. Mit QWebview, einem für den User unsichtbar in das UI eingebetteten WebKit (Google Chrome), werden wir einen Teil der Funktionalität mittels Web-Technologien implementieren. Diese hybride Art der Applikationsentwicklung wird ansonsten häufig bei mobilen Apps betrieben, um Apps auf Android, iOS und Co. mit nur einer Codebasis zu betreiben. Bei uns geht’s allerdings eher um die Entwicklungsgeschwindigkeit, da HTTP schlicht die lingua franca in der IT ist.
Richtig abgehoben wird das Projekt letztlich bei der Lichtsteuerung, einem Bedienkonzept, welches Benutzer anhand von Lichtimpulsen und Farben anstatt von Beschriftungen und Erklärungstexten leiten soll. Ein prototypisches Video kann bei Google Plus angesehen werden.
Photoshooter
Obwohl ich mich eher um die Projektabwicklung, als um die tatsächliche Implementierung kümmere, wollte ich eine Sache selbst hinbekommen: Die Software für den Photoshooter. Jeder WU-Student kennt das Ding, muss man doch am Tag der Inskription genau dort hinein lachen…
Erste Erfolge mit der Webcam.
Eines war mir jedenfalls nicht so ganz klar, als ich das Modul übernommen hatte: Dass ich eine long and winding road begehen würde bevor das Ziel auch nur halbwegs in Blickweite sein würde…
Kurzum, nach zahllosen gescheiterten Versuchen mit diversen APIs von VoIP-Clients bis hin zum Sourcecode der Kamera des Nokia N900 bin ich nun mit opencv glücklich. Diese Library für maschinelles Sehen tut aber nur am Rande, wonach ich hauptsächlich gesucht habe. Fokus liegt eher bei der Bilderkennung, und so war dann auch – das nächste “Abfallprodukt” – eine Gesichtserkennung schnell implementiert. Während man jetzt den Bildausschnitt mit dem Gesicht manuell auswählen muss, übernimmt das künftig die Software. Die überraschend geringe Fehlerrate bei der Gesichtserkennung trägt außerdem dazu bei, dass künftig nur noch erkennbare Bilder akzeptiert werden. Ein, wie ich, fauler Programmierer spart sich außerdem das ganze Gezoome und Gecroppe im UI.
Gesichterkennung mit Intels opencv: Das Gesicht kommt künftig automatisch erkannt auf den Studierendenausweis. Ergebnis sind ein einfacheres UI und eine indirekte Qualitätskontrolle, da der Algorithmus nur richtig belichtete Gesichter erkennt.
Linux statt Windows
Plattformunabhängigkeit, Python, offene Schnittstellen – all das dient letztlich dazu eine der letzten Domänen von Windows zu beenden: Jene der interaktiven Terminals. Unser Betriebssystem wird Ubuntu Linux 12.04 LTS. Mit TFTP-Boot und automatisiertem Checkout aus dem SVN-Repository ist auch hier die Reduktion der Wartung bereits Teil des Kernkonzepts.
Schon während der Entwicklung setzen wir auf continuous integration. Das bedeutet, dass zwei Testrechner laufend selbständig nach neuen Releases suchen und sich im Falle notwendiger Updates automatisch aktualisieren. Was jetzt also das Testen ungemein erleichtert, bedeutet im Produktivsystem einen stabilen Rollout-Mechanismus, der keinerlei manuelle Eingriffe benötigt.
Und noch so viel zu tun…
Nach einem guten halben Jahr Entwicklung sind wir nun an dem Punkt, wo alle Teile für sich alleine funktionieren. Nun heißt es, die einzelnen proofs-of-concept zu einem Ganzen zu verbinden und danach zu testen, zu testen und zu testen. Bis hierher sieht es also gut aus, aber die Geschichte bleibt spannend…
Das für Außenstehende wohl spannendste, weil greifbarste, Projekt meiner Tätigkeit ist das Service Terminal Plus. Mit beinahe 500.000 Euro Budget geht am Campus WU der Nachfolger der heutigen Selbstbedienungsterminals in Betrieb. Zeit für einen Erlebnisbericht, der sich für mich wie eine Hintergrundgeschichte zur (zweiten) Mondlandung schreibt…
Beim Service Terminal Plus handelt es sich um einen interaktiven Terminal, der RFID-Leser, Kartendrucker, Touchscreen, Webcam, Bezahlfunktion für Bankomat und Kreditkarte, Ausdruck auf Normal- und Zeugnispapier im A4-Format, zusätzlich Rechnungsdruck auf Thermopapier sowie Lichtsteuerung vereint. Kein Wunder also, dass der interne Codename des Projekts Riesenkrake lautet, besitzt der Automat wie sein tierisches Vorbild (mindestens) acht Arme und neun Gehirne…
Aktuelle Version der SB-Terminals an der WU Wirtschaftsuniversität Wien: Foto für den Ausweis, Rückmelden inkl. Bezahlen, Ausdruck von Zeugnissen und Bestätigungen.
Die aktuellen SB-Terminals wurden 2001 von Siemens geliefert, zwischenzeitlich mussten einige Hardwarekomponenten getauscht werden. Die Software wurde 2006 aufgrund vieler Ändeurngswünsche komplett neu in-house entwickelt.
Dank der in zehn Jahren Betrieb gesammelten Erfahrung wollen wir nun einen Automaten bauen, der in seiner Wartbarkeit deutlich verbessert wird. Die spannendsten Änderungen spielen sich allerdings auf Seiten der Benutzungstauglichkeit ab, wo wir in den vergangenen Monaten einige interessante Ideen geboren, aber vor allem auch zur Reife gebracht haben.
Künftiger Standort ist das LLC am Campus WU. Wir nehmen Anleihe an der Architektur und holen den "Geist des Gebäudes" ins Projekt.
Eine der ersten Studien zum Service Terminal Plus.
Barrierefreiheit: Einer für Alle!
Ein Thema, das keinesfalls zu kurz kommen darf, lautet Barrierefreiheit. Die bisherige Lösung bot zehn Terminals für normale Menschen und einen für Behinderte.
Wem sich beim vorigen Satz auch der Magen umdreht, mir geht’s genau so.
Wir wollen weg vom Separieren von Menschen mit Behinderungen hin zu Gleichbehandlung. Das heißt im konkreten Fall, alle Terminals werden (mit Kompromissen) barrierefrei sein. Das bedeutet aber auch, dass viele Studierende sich werden bücken, Rollstuhlfahrer eben auch strecken müssen. Mir gefällt der Ansatz, etwas fundierter nennt sich das Inklusion.
Die Bedienelemente werden auf einem Kragarm platziert, der für Rollstühle unterfahrbar ist.
Zielsetzung mit dem nächsten Protoypen wird unter anderem sein, Rollstuhlfahrer testen zu lassen, um so zu verwertbarem Feedback abseits abstrakter Gesetzesnormen zu kommen.
Technische Neuerungen
Doch auch technisch wird sich viel tun. Seit Smartphones und Tabs will niemand mehr einen resistiven Touchschirm bedienen – die neue Generation ist kapazitiv und bietet deutlich erhöhten Bedienkomfort. Teure, weil vandalismussichere Tastaturen sind dank dieser Technologie ebenso Geschichte – das erledigt neuerdings die Software.
Die größte Innovation scheint uns aber im Bereich des Druckens zu gelingen: Während in der aktuellen Version immer wieder Papierstaus auftreten, glauben wir, das Problem nun endgültig geknackt zu haben. Dank Modifikation des Beförderungsmechanismus wird der Drucker rückwärts verbaut. Das bedeutet, dass künftig sämtliche Wartungsarbeiten von hinten durchgeführt werden, während vorne das User Interface keine Ladeklappen benötigt, also “clean” bleibt. Gemäß dem alles beherrschenden Motto “Was nicht existiert, geht nicht kaputt”, kann Papier nirgends mehr stecken bleiben. Es fällt einfach nach unten in eine Lade.
Das Innenleben eines Lexmark T652dn: Wir ändern die Richtung des Papierauswurfs und erreichen: Drucken vorne - Nachfüllen hinten.
Einheitliches User Interface (UI)
Als Softwareentwickler denke ich bei UI vorrangig an das, was sich letztlich am Bildschirm tut. Doch beim Service Terminal Plus ergeben sich durch den Möbelbau ungeahnte Möglichkeiten: Wie am Foto der aktuellen Generation erkennbar, ist das physische UI zurzeit stark zerklüftet. Drucker, Bankomatkassa und Kartenleser befinden sich in einem separaten Möbelstück rechts des Bildschirms. Der Zahlungsbeleg hingegen wird unterhalb des Bildschirms gedruckt, weit weg also vom eigentlichen Bezahlvorgang. Zumindest ich finde so etwas verwirrend.
Am Mockup des Möbelbauers werden die Komponenten verortet. Zusammengehöriges wird mittels Fräsung umrandet und dadurch zusammengefasst. Eine Lichtsteuerung leitet schließlich den Benutzer von Bedienfeld zu Bedienfeld.
Agil versus legal, oder: Grenzen des Outsourcings
Wie auf den Bildern erkennbar haben wir Spezialmöbelbauer im Team, mit denen die Zusammenarbeit auf Basis von Mock-ups abläuft. Es ist unglaublich hilfreich und effizient, ein Projekt anhand eines an-greifbar-en Prototypen zu be-greifen, anstatt detailliert zu planen. Das Gesamtprojekt ist schlicht zu komplex, als dass man es abschließend spezifizieren könnte. Trial and Error ist hier der richtige Weg.
Eine der größten Herausforderungen des Projekts liegt daher weitab aller technischen Sphären: im Vergaberecht, an das sich öffentliche Auftraggeber halten müssen. Beschaffungen ab gewissen Schwellenwerten haben über Ausschreibungen zu erfolgen. Was etwa bei Standardmöbeln zu transparenter und effizienter Haushaltsführung führt, stößt bei derartigen Spezialthemen an Grenzen. Die Aufgabe lautet daher, gemeinsam mit einem vertrauenswürdigen Partner ein Produkt zu entwerfen, dass später als Referenz für eine Ausschreibung an einen unbekannten Bieterkreis dienen soll. Im Regelfall stellt sich diese Schwierigkeit nicht, da oft so genannte Integratoren wie IBM oder eben Siemens eine Gesamtleistung anbieten. Die Erfahrung lehrt uns aber, dass es viele Themen gibt, die besser in-house gelöst werden, da ein komplexes Projekt nicht beliebig auf Externe verteilbar ist.
Getting real!
Wer sich von den Entwicklungen aus nächster Nähe überzeugen will: Bereits im Sommer 2012 soll “Nummer 1″ noch am Altstandort in Betrieb gehen. Dann wird sich zeigen, ob sich die vielen, vielen Arbeitsstunden hinter Monitoren, Mock-ups und Kaffeemaschinen rechnen…
UPDATE: WUdoo x5 gibt’s inzwischen unter short.wu.ac.at/wudoo - plattformunabhängig und frei verfügbar.
Bevor ich meinen digitalen Rundumschlag gegen Office-Dokumente oder SharePoint beende, um endlich wieder über Dinge, die ich kreiere anstatt nur kritisiere, zu schreiben, muss ich mich hier noch einem Übel annehmen: dem Hype um Apps.
Das Internet ist nicht erst seit dem Arabischen Frühling politische Bühne: Information kann nur dort frei fließen, wo Telekom-Provider und deren Gesetzgeber Netzneutralität garantieren. Abseits der Frage der wertneutralen Datenübertragung ist auch die Datenspeicherung ein brisantes Thema: Immer mehr Content wandert von dezentralen Servern in Richtung Facebook; ein beängstigendes Phänomen, das mich übrigens zur Wiederbelebung dieses Blogs brachte. Die dritte Komponente schwindender Informationsfreiheit ist schließlich der Trend weg vom plattformunabhängigen WWW hin zu (mobilen) Apps. Denn diese sind an Betriebssysteme gebunden und unterliegen der Zensur der Marktplatzbetreiber.
Doch Apps sind gerade modern und somit cool. Und daher beginnt meine Geschichte der Abneigung gegenüber Apps auch ganz anders, und zwar als Erfolgsgeschichte:
WUdoo: (m)eine Success-Story
Als spätestens 2009 Apple’s iPhone seinen Siegeszug durch Österreichs Mobilfunklandschaft begonnen hatte, wurde uns an der WU Wirtschaftsuniversität Wien eines klar: die Zukunft der Nutzung unserer Services liegt (auch) am Smartphone. Genug dieser Erkenntnis, es war Zeit für Nägel mit Köpfen:
Mit der persönlichen Kursübersicht war jedenfalls schnell ein sinnvoller, mobiler Anwendungsfall gefunden. Für die Entwicklung der App holten wir uns Martin Kahr ins Boot, ein absoluter Profi auf der Apple-Plattform – die Zusammenarbeit war unkompliziert, erfolgreich und inspirierend zugleich! Das Backend wie Datenbankabfragen, Authentisierung, etc. hatte ich zwischenzeitlich mit viel Vorfreude in den Fingern programmiert.
WUdoo, Jänner 2010 - die erste universitäre App Österreichs.
Meine Frau Isabella stiftete den Namen WUdoo für das Projekt, das bis dahin holprig als WU iPhone App firmierte.
Die App ging in den Review-Prozess, darauf folgte ungeduldiges Warten über Weihnachten und schließlich, kurz nach Neujahr, war Apple mit deren Voodoo fertig und WUdoo konnte aus dem App Store heruntergeladen werden:
Und es war ein voller Erfolg;-)
Innerhalb kürzester Zeit hatten wir rund 3.500 Installationen. Ein erstaunlicher Marktanteil bei knapp 30.000 Studierenden und Mitarbeiter/inne/n und einem iPhone-Anteil von (damals) schätzungsweise 15%.
Das Feedback per E-Mail oder App Store war atemberaubend, werden IT-Abteilungen ansonsten doch eher als reiner Hygienefaktor im Universitätsbetrieb gesehen. Als vermeintlicher Innovator schafften wir’s schließlich sogar in die Presse; eine Fan-Seite auf Facebook folgte.
Schönheitsfehler im goldenen Käfig
Mit dem Erfolg kamen verständlicherweise sehr bald Ideen und Wünsche für weitere Features von WUdoo. Auf Entwickler-Seite musste ich aber schnell feststellen, dass das Hinzufügen neuer Funktionalität, Testen oder Logging immer aufwendiger wurden. Besonders ärgerlich waren die Updates auf iOS4 und iOS5, die beide Male mit neuartigen Crashes der App überraschten. Mein Punkt: Entwicklung und Betrieb einer Webseite sind deutlich wirtschaftlicher.
Währenddessen regte sich bei den Benutzer/inne/n von Android, Blackberry und Co. Unbehangen, warum wir als Universität nur Apples Betriebssystem unterstützten. Gute Frage eigentlich, ich wusste jedenfalls nur eine enttäuschende Antwort: Das Multiplizieren der oben geschilderten Probleme auf die jeweils nächste Plattform wollten wir uns nicht antun. (Christoph Weber entwickelte dann doch noch den schlanken WUdoo-Klon WUdroid, aber für mich war die Sache mit den Apps bereits gelaufen.)
Optimierte Webseiten sind besser!
Unser Ansatz: Webseiten sowohl für Desktops als auch für Smartphones erstellen - einmal entwickeln und warten, überall verwenden!
Im Laufe des Jahres 2010 setzte ich mich immer stärker dafür ein, den Irrweg mit den Apps nicht mehr zu beschreiten. Die Kolleg/inn/en vom CMS-Team taten dann auch einen tollen Job, als die WU Anfang diesen Jahres eine mobile Webseite (m.wu.ac.at) anstatt einer WU-App präsentierte.
Meine eigenen Projekte waren ähnlich gestrickt: Mit dem WU Directory ging eine Webseite in Betrieb, die sowohl für Desktop und Smartphone konzipiert war.
Für Neugierige: Detailseite am Desktop öffnen und die Elemente wie Menü, Spalten, Schriften usw. beim Verkleinern des Browserfensters beobachten. Die gut lesbare Anzeige am iPhone ist im Screenshot dargestellt.
Was passiert mit WUdoo?
Nun, die Entwicklungen an einem Nachfolger in Form einer mobil nutzbaren Webseite laufen. Damit wird die Anwendung für alle Smartphones, aber natürlich genauso für Desktops zur Verfügung stehen. Wir ersparen uns aufwendiges Programmieren für iOS, Android usw. Diesen Vorteil wollen wir in ein vielleicht umfangreicheres, vielleicht auch “nur” fehlerfreieres Produkt stecken.
Ob wir WUdoo (mutwillig) abdrehen, oder einfach nur auslaufen lassen, muss ich mir noch überlegen. Im Internet herrschte von Anfang an befruchtende Konkurrenz. Wenn schließlich die Studierenden meinen, das neue, webbasierte WUdoo sei viel besser, als das alte aus dem App Store, dann kann ich zufrieden sein.
Die Idee ist ebenso genial wie einfach zugleich: Personen produzieren CO2. Der Gehalt des Gases in der Raumluft lässt daher Rückschlüsse auf die Anzahl der Atmenden zu. Soweit die Hypothese – Zeit für einen Reality Check.
Am Campus WU ist die Klimatisierung in eine umfassende Gebäudeleittechnik integriert. Wo früher mühsam verkabelt wurde, da reicht heute ein einziges TCP/IP-Signal aus. Zu Testzwecken haben wir einen CO2-Sensor mit Webserver ausgestattet und in einem Hörsaal (2.18) der WU platziert.
Im Hörsaal befindet sich ein CO2-Sensor, der Rückschlüsse auf die Raumbelegung liefern soll.
Von der Decke des Hörsaals aus wird nun ununterbrochen gerochen, in einer Datenbank wird der CO2-Wert protokolliert.
It works!
Die Freude war jedenfalls groß, als heute das Setup in Betrieb genommen wurde und auch sofort “angeschlagen” hat.
Unter dem CO2-Sensor stehen und sprechen, kurz rausgehen, direktes Hineinatmen, Raum verlassen. It works!
Was nun?
Nun folgt eine mathematische Aufgabe: Wie kommen wir von einem Co2-Level (eigentlich einer elektrischen Spannung) zu einer Personenzahl? Der Wert wird stark von der tatsächlichen Kubatur des Raums abhängen, von Faktoren wie Zustand der Fenster und der Klimatisierung; bösartig könnte man auch noch den Inhalt der Lehrveranstaltung als Faktor ansehen. Meine Meinung: Menschen können Muster ohnehin sehr gut erkennen; der Mockup des künftigen Raumbuchungs-Systems zeigt bereits ohne errechnete Werte, was Sache ist:
Kleine Diagramme visualisieren den Verlauf des CO2-Gehalts; Menschen sind ohnehin gute Muster-Erkenner bei geeigneter Darstellung.
Update
Mit 3. Oktober konnte ich das Setup erstmals mit echten Lehrveranstaltungen testen. Laut Vorlesungsverzeichnis gab es zwei Lehrveranstaltungen, die gebuchten Zeiten habe ich farblich hinterlegt. LV1 hat 15 Minuten verspätet begonnen, es gab zusätzlich ein paar Pausen oder geöffnete Fenster. LV2 lief lediglich rund 20 Minuten – durchaus üblich zu Semesterbeginn, wo beispielsweise nur der Ablauf erklärt wird.
CO2-Verlauf im Raum während des Tages und zwei gebuchten Lehrveranstaltungen.
About