Tag Archives: html5

IT architecture

Rethink reuse

Although I cannot share details of my current work except of fancy presentations there’s one general topic that keeps haunting me in a lot of discussions: The question of reusing code and components across platforms, target audiences, use cases, etc.

At first glance it looks like a brilliant idea: You build something once and use it several times for various use cases. Technicians love such a concepts because they’re motivated by complex problems; business people of course are fond of possible cost-reduction; IT architects love to draw boxes with arrows around them and usually feel big pain when comparable boxes appear twice in their diagrams.

The problem: Good ideas do not always work out. And what annoys me the most is the fact that software reuse seems to be an unchallenged goal, a mantra nobody dares to question. A lot of the obvious side-effects are rarely considered when going for reuse, such as:

  • growing complexity by serving additional requirements. This complexity exists in many areas, e.g. coding, testing, decision-making, etc.
  • operational issues by serving multiple target groups/stakeholders, e.g. when can you do a maintenance window?
  • losing advantages you’d have from very focused implementations, e.g. performance, optimized UX, etc.

The Space Shuttle: a terrible example of reuse

Let’s look at an example outside of my world of IT: The Space Shuttle – or better called the Space Transportation System (STS) – is an almost perfect case study where cost reduction and related benefits where promised from reusing components.

Just by looking at the picture below you can actually see (or at least imagine) all the parts which were only needed to fulfill reuse: wings with their heat shield, a tail, landing gear including unnecessarily heavy tyres, a fully functional cockpit for landing, solid liquid boosters (two rockets on the side) which fell down back into the ocean, etc.

As it turned out the Space Shuttle was limited in capacity, only reached low orbits, was more expensive and eventually killed more people than any other comparable space launch system. (A nice read on forbes.com)

Space Shuttle Launch
One of the most impressive vehicles ever built – and a total fail: The Space Transportation System.

Not being an expert on space travel let’s get back to IT. The example above just shows that there was tremendous overhead just to satisfy the requirement of reuse. As an architect I will in the future try to think twice and try to locate the space shuttle projects amongst my tasks. Reusing stuff is really cool, but only as long as it makes sense.

hacks

Tetris 3D!

Vor kurzem habe ich über die Tetris-Maschine, einen Algorithmus zum Finden optimaler Raum-Zeit-Kombinationen in Reservierungssystemen, gebloggt. Diesmal ist die Aufgabe dieselbe, der Lösungsweg allerdings ein gänzlich anderer.

März oder Oktober – die WU plant – wie andere Universitäten ebenso – Lehrveranstaltungstermine des jeweils kommenden Semesters. Der Prozess gleicht dem Einräumen meines Kühlschranks nach dem Großeinkauf: Zuerst müssen große Veranstaltungen fixiert werden, kleinere müssen sich an die Gegebenheiten anpassen – also nehmen, was noch übrig ist. Mit zunehmender Fragmentierung durch Blockveranstaltungen oder Prüfungstermine wird es somit immer schwieriger, einen fixen Raum oder auch nur eine stabile Beginn- und Endzeit für Veranstaltungen zu finden. In diesem Fall kann eine Visualisierung der Belegung sinnvoll sein.

Doch wie soll man knapp 20.000 Veranstaltungen in 150 Räumen pro Semester übersichtlich darstellen?

Die Referenz

Anbei ein Screenshot vom aktuellen Buchungssystem: Wochentagsweise werden die Belegungen dargestellt – pro Raum gibt es eine derartige Auswertung. Die einzelnen Kürzel codieren die Veranstaltungen, ein Überblick über den gesamten Campus ist allerdings so nicht möglich.

Belegung eines Raums über ein ganzes Semester nach Wochentagen. ASCII-Art rules!

Der Re-Write

Trotz des geekigen Charmes der obigen ASCII-Darstellung lautete der Plan, die Belegungen interaktiv zu visualisieren. Typische Anwendungsfälle sind etwa:

  • “Ich benötige kommendes Semester einen 60er-Raum am Donnerstag Nachmittag.”
  • “Ich benötige in der ersten Semesterhälfte einen 30er-Raum am Montag und Mittwoch zur selben Beginnzeit.”
  • “Ich benötige für Termine 1, 2, 3, 4 und 5 einen Hörsaal.”

Die Idee: Die Belegung sollte Raum, Uhrzeit und Datum dreidimensional darstellen, also Datum über Datum legen. Mit semitransparenten Balken pro Belegungen könnte die Farbintensität somit die Dichte der Buchungen codieren. Durch Zu- und Wegschalten einzelner Tage, wäre es außerdem möglich, schnell in der Datenmenge zu navigieren.

Mock-up Dez. 2011: Meine ursprüngliche Idee, wie man dreidimensional durch die Buchungen am Campus blicken sollte.
Low-Fidelity Prototype auf Papier. Die Achsen für Uhrzeiten und Räume sind nun vertauscht, denn eine variable Anzahl an Räumen expandiert besser nach unten als nach rechts.

Nach einigen Spielereien mit absoluter Positionierung von <div>-Elementen im DOM fiel die Wahl doch recht schnell auf das weitaus effektivere d3.js. Diese Javascript-Library ermöglicht das Erstellen interaktiver SVG-Dokumente. Meine Hassliebe zu Javascript war jedenfalls überwunden, als das method chaining der Library endlich von den Fingern ins Gehirn übergegangen war:

function actually_draw(data) {

  d3.select("#bookings")
    .append("g")
      .attr("id", "day" + data.day)
    .selectAll("rect.booking")
    .data(data.bookings)
    .enter()
    .append("rect")
      .attr("class", "booking")
      .attr("width", function(d) {
        return linear_scale(time_to_float(d.end)) - linear_scale( time_to_float(d.start))
       })
      .attr("height", R_AXIS.incr - 2)
      .attr("x", function(d) { return linear_scale( time_to_float(d.start) ) } )
      .attr("y", function(d) { return  room_y(d.room)});  
}

Exzessives method chaining gepaart mit einigen wenig intuitiven Methoden wie .selectAll() (macht man, obwohl noch nichts vorhanden ist) oder .data(data).enter() (“steigt” hinein in die Daten). Ist man da mal durch, ist plötzlich alles möglich!

Endergebnis: Über 2000 Termine auf einer Seite visualisiert, interaktiv mit dem Kalender zu steuern. Echte Daten der WU im Sommersemester 2013.

Auch wenn der Screenshot noch nicht toll aussieht: Der Browser holt sich mehrere tausend Termine und rendert diese ohne Performance-Probleme bei jedem Klick im Kalender. Sourcecode und Live-Demo sind verfügbar unter:

http://www.zieglergasse.at/stuff/2012/bookingviz/view.html

 

meta

Schluss mit den Apps!

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.

 

Vergangene Woche sprach Sir Tim Berners-Lee in der Spanischen Hofreitschule anlässlich des future.talk 2011  über die Freiheit des World Wide Web. (Dazu: “Das WWW war ein Erfolg, weil es keine Patente gab” auf derStandard.at)

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.

hacks

Redesign SAP Finanzbericht

Zur Thematik, dass erfolgreiche ERP-Systeme nicht zwangsweise durch einfach bedienbare User Interfaces glänzen, habe ich bereits gebloggt. Spätestens, seitdem ich meine eigene Kostenstelle verantworte, war’s nun aber höchste Zeit, den Bericht, der mir Überblick über meine Finanzen geben sollte, zu überarbeiten.

Zu allererst ein Blick auf den Status Quo

Nach einigem Herumgeklicke und der Erkenntnis, dass SAP-Jahre aus 16 Monaten bestehen, erreiche ich Woche für Woche den Überblick über meine Kostenstelle im Look & Feel von Teletext, aka SAP GUI.

Der Bericht listet alle von mir unterschriebenen Rechnungen mit Betrag, Datum, Belegtext sowie Kostenart. Um den Leser nicht mit Details zu verwirren (so interessant sind meine Zahlen nun auch wieder nicht), habe ich die Berichtsstruktur hervorgehoben:

Der Bericht zeigt auf Kontierungselemente (Kostenstellen) gebuchte Kosten aufgeschlüsselt nach Kostenarten (Konten). Die Logik des Berichts orientiert sich mMn zu stark am System.

Im Großen und Ganzen befinden sich auf der Seite zwei interessante Blöcke: eine Übersicht oben links, sowie eine Tabelle mit den Buchungen darunter.

Wenn ich mir nun überlege, welche Aufgaben ich mit dem Bericht abwickeln muss, dann sind das nach absteigender Wichtigkeit:

  1. Überblick über Planungs- sowie Ist-Stand meiner Finanzen
  2. Details zu einzelnen Rechnungen (z.B.: im Falle von Reklamationen)
  3. Analyse meiner Kostenstruktur nach Zeit und Kostenart

Traurig, aber wahr: bereits der erste Task ist mit dem Bericht nicht ohne Weiteres möglich. Die Transaktion, also der SAP-Name für eine Bildschirm-Maske, listet entweder Plan- oder Ist-Daten. Die jeweils andere Ansicht erreicht man durch Beenden und Neustart des Berichts nach anderen Auswahlkriterien. (…)

Finanzbericht Marke Eigenbau

Eine kleiner Entwurf auf einer McDonalds-Rechnung (ein so genannter Low-Fidelity Mockup) und ein paar Stunden Datenexport, HTML, SQL, Javascript und Python später ist die Alternative fertig: Eine Webseite, die die drei oben genannten Tasks auf einen Blick ermöglicht.

Der Kasten oben links bietet mir die Gesamtsummen von Ist und Plan als Zahlen, zusätzlich verdeutlicht ein Prozentwert das Verhältnis (Wieviel ist schon weg?).  Darüber ein einziges Auswahlfeld für das Berichtsjahr, kein Formular-Moloch. Rechts daneben befindet sich Säulendiagramm, das mir dieses Plan/Ist-Verhältnis nochmal grafisch verdeutlicht. Bei mehreren Jahren – bei mir nicht der Fall – sieht man so automatisch den Budgetverlauf.

Die Details zu einzelnen Rechnungen finden sich darunter. Die Tabelle verwendet das jQuery-Plugin DataTables, welches Such-, Sortierfunktion und Pagination bietet. So sind ein Sortieren nach Datum, oder das Suchen einer bestimmten Rechnung keine große Hexerei. Die rein Client-seitige Umsetzung sorgt dafür, dass das Ding responsive bleibt.

Alternativvorschlag: Ein Überblick über Plan und Ist (gleichzeitig!) oben links, eine Tabelle aller Buchungen mit Sortier- und Suchfunktion darunter. Oben rechts ein paar grafische Darstellungen eben jener Daten.

Den Zuckerguss stellen die drei Diagramme im TabbedView oben rechts dar. Neben dem bereits besprochenen Jahresüberblick, gibt es noch ein Liniendiagramm, welches den Planungsstand mit dem Iststand unterjährig vergleicht. Dadurch dass auf Jahresebene geplant wird, ist eine kumulative Auswertung sinnvoll.

Die wichtigste Frage auf einen Blick beantwortet: Bin ich drüber oder drunter?

Abschließend noch eine Auswertung nach Kostenarten, die eine hierarchische Datenstruktur mit variabler Tiefe darstellen. In diesem Fall habe ich mich für eine Treemap entschieden. Diese codiert zwei Variable (Größe des Rechtecks entspricht der Summe; Farbe ist die Abweichung) in eine klickbare Fläche. Das “Entdecken” der Kostenzusammensetzung macht so richtig Spaß.

Sehr schöne Visualisierung einer hierarchischen Datenstruktur: die Größe entspricht der Summe, die Farbe der Plan/Ist-Abweichung

Die hier dargestellte Kritik an aktuellen Berichten ist positiv gemeint und soll keineswegs als SAP-Bashing missverstanden werden. Dass die Software derart erfolgreich war, ist und vermutlich bleiben wird, hat schon seine guten Gründe. Ich bin selbst überrascht, wie sich mein Blick auf eben jenen Bericht verändert hat, seitdem ich auch wirklich ein Anwender bin. (…)