Tag Archives: javascript

IT explained

Mathias at openslava

Nach inzwischen mehr als zwei Jahren in sehr unterschiedlichen Rollen für George, fragen mich Freunde und frühere Weggefährten oft, was ich in der Bank denn so tue. Vielleicht erklärt’s ja mein Talk bei der openslava 2016😉

IT explained

George bloggt

2012 habe ich an dieser Stelle über IT in Banken gebloggt. Dass ich zweieinhalb Jahre später selbst tief drinnen in der IT einer Bank arbeite, hätte ich damals nicht gedacht. 

Als Teil des Teams rund um George gibt’s nun einen Beitrag über Sicherheit und Datenschutz – ein wirklich spannendes IT-Thema im Kontext von Bankensoftware! Hier geht’s zu meinem Artikel im George Blog.

Und die Tatsache, dass es besser geschrieben ist, als die Texte hier in meinem Blog, liegt an meinem Ghostwriter Dag;-)


Designing APIs that work

With something around 20 systems that need interconnection, building APIs might currently be my main task at work. The systems involved range from access control, digital signage, kiosk and wayfinding terminals, CO2-sensors, facility management, resource allocation, geo-information to payment for printing or catering. In the context of an awfully huge project virtually everything needs data from somewhere else with schedules being extremely tight and vendor-side flexibility sometimes not being present at all. This simply means interface hell.

So be prepared for some lessons learned from someone who’s already made every possible mistake by himself:

One of the first public interfaces I wrote was a course data export for a mobile app, then running on iOS. The app developer and I decided on JSON using a list for the various attributes (title, location, time, etc.) of every course record:

  ["09W", "1985", "Wirtschaft im rechtlichen Kontext ", "H. 3.33 (B)", "UZA 1", "19:00", "21:00", 
      [5803, "Lastname M."],
      [9651, "Lastname2 D."]
    ], "course", "20091212"

As a matter of fact my first call came with two design failures attached: a badly chosen data structure and an unnecessary invention of something that was widely available anyway.

Use key-value pairs

First, using a list was a bad idea since position mattered and extending the interface immediately became a challenge since we quickly had 3.000 client-side installations out in the field. When using key-value pairs you retain the possibility of extending the data structure.

  {"semester": "09W",
   "course_id": "1985",
   "title": "Wirtschaft im rechtlichen Kontext ",

Use wide-spread formats

Second, I suffered from the NIH anti-pattern since there was a decent exchange format available anyway: iCalendar. With a rewrite to the latter format data became usable even outside our app. People started importing personalized course lists into their calendars of choice.

Add metadata

After some time I realized that my course export was not only useful in its intended context but also in many other places: on digital signage screens for example. The latter project needed metdata so I added a timestamp and nested the payload inside the top level data structure.  

{"last_update": "2013-03-17T13:19:18",
      {"semester": "09W",
       "course_id": "1985",
       "title": "Wirtschaft im rechtlichen Kontext ",


With calls available for courses, organizations, employees, publications, rooms, etc. in different flavours – usually search(), list() and get() – the overall structure soon became messy. Especially inconsistent naming started to be a pain when programming the server backend: employees had a "first_name" as members of organizational units whereas the same people carried a "firstName" when they authored publications.

While the key-value approach was a fine idea on the public side of my API the backend urgently needed refurbishment. I steadily moved my code to a more object-oriented approach which meant that I used Employee() objects rather than simple data structures. Nevertheless the API’s output consists of simple data types – so the magic of turning objects into JSON strings is mainly done by a serialize() method which every class must have:

class Employee(object):
    """Main Employee class"""
    def serialize(self):
        return {
	    'tid': self.tid,
	    'first_name': self.first_name,
	    'last_name': self.last_name,

Add options

With more and more applications using the calls the clients became more demanding. For our wayfinding kiosk application I was asked to add pagination and custom sorting to some of the calls. I decided to provide an API-wide feature.
The result should look like this while sorting, limit, offset, etc. can be passed as arguments to the call (as key-value pairs rather than positional arguments of course!):

{"last_update": "2013-03-17T13:19:18",
  "offset": 100,
  "limit": 25,
  "sorting": {
      "fields": ["semester", "title"],
      "reverse": false
      {"semester": "09W",
       "course_id": "1985",
       "title": "Wirtschaft im rechtlichen Kontext ",

Instead of painfully implementing pagination and sorting in a hundred different places I wrote a decorator that enables the functionality in a single place. The available sorting parameters have to be passed to the decorator since they differ from call to call.
@search_option_factory(set(['semester', 'title']))
def search_courses(self, value):
    """A sophisticated course search"""
    return courses

The decorator itself looks a bit complicated since passing arguments to decorators is a bit tricky. You actually have to write a function that handles the input and returns a decorator. Thanks to stackoverflow it’s not that difficult after all.
    def search_option_factory(sorting_set):
        """A decorator factory that handles generic options for calls.
        sorting_set: set that defines sortable fields
        according to Robert's spec:
        paging-objekt (struct) mit folgenden keys verwenden:
        - offset (null/int)
        - limit (null/int)
        - order (null/string)
        - desc (null/false/true)        
        def search_decorator(method):
            def wrapper(self, value, options):

                # call the method
                recs = method(self, value)

                # count the recs
                count = len(recs)

                ## parse the options
                if not options:
                    options = {}
                sorting = options.get('sorting')
                if sorting:            
                    reverse = False
                    if options.has_key('reverse'):
                        r = options['reverse']
                        assert(isinstance(r, bool))
                        reverse = r
                    assert isinstance(sorting, list)
                    assert set(sorting).issubset(sorting_set)
                    sortator = ','.join(['d.%s' % x for x in sorting])
                    recs = sorted(recs, key=lambda d: (eval(sortator)), reverse=reverse)
                offset = options.get('offset')
                if offset:
                    assert isinstance(offset, int)
                    recs = recs[offset:]
                limit = options.get('limit')
                if limit:
                    assert isinstance(limit, int)
                    recs = recs[:limit]
                return {
                    'count': count,
                    'limit': limit,
                    'offset': offset,
                    'payload': recs,
                    'created_at': datetime.datetime.now().isoformat()
            return wrapper
        return search_decorator


Project visualization with redesigned Gantt charts

When reading the Edward Tufte forum on Project Management Graphics I was surprised (and relieved) that a lot of people seem to have their problems with Gantt charts and their doubtful usefulness for project management.

After some thoughts on the topic I’d like to present my proposal for visualization of project flows. In case it matters: I’m currently part of a half a billion Euro construction project in Austria.

The real world example

The image below shows one Gantt chart of the project I’m currently involved in.

Actual Gantt chart of “my” current project.

Aside from its professional look it transports surprisingly little content. My main points of criticism are:

  • On the one hand, with more than a hundred tasks on the left I get overwhelmed by things I’m not responsible for anyway.
  • On the other, my 15 tasks lack important detail.
  • Since it’s not possible to combine overview with sub-project specific detail I have to manage my tasks in parallel.
  • I easily lose track between tasks and the bars on the far right. Gridlines would be a bad idea as well since they add too much clutter.
  • Data is sparse and the chart needs too much space for the presentation thereof.
  • In my context of software development the chart’s implicit focus on sequential, waterfall-like project flows does not fit my reality of ever-changing project plans.
  • I definitely need to print it out to be able to use it.

What would I need?

First of all: Everybody can read a Gantt chart so let’s stick to some reasonable habits: bars that encode project duration by length and diamond symbols that mean milestones, i.e. important dates.

When I think of project management, the whole story is about one core task: Align your output and handover dates with those of others.

As a member of any project team I simply cannot be interested in the task of each individual. However the Gantt chart’s focus lies on the presentation of single tasks. I state that any visualization for project management should focus on people or teams, i.e. responsibilities, rather than tasks.

My second point revolves around overview and detail: My own tasks should be presented in greater detail than data of other teams. My only concern with them is deliverables when we approach mutual handover dates.

The Redesign

Here’s some example data taken from one of my schedules:

Responsible Task Start End
Construction Define location Sun Jan 01 2012 Sun Apr 15 2012
Construction Finish site Thu Aug 01 2013 Milestone
IT Develop prototype Sun Jan 15 2012 Sat Jun 02 2012
IT Testing Sun Jun 03 2012 Sun Jul 01 2012
Business Process Give feedback Sun Jun 03 2012 Sun Jul 01 2012
Supplier Deliver parts (prototype) Thu Mar 01 2012 Sun Aug 05 2012
IT Update integration Sun Jul 01 2012 Tue Aug 14 2012
IT Evaluate prototype (hands-on) Wed Aug 15 2012 Mon Oct 01 2012
IT Evaluate prototype (remote monitoring) Tue Oct 02 2012 Wed May 01 2013
IT Production Mon Aug 19 2013 Wed Jan 01 2014
Business Process Launch prototype environment Wed Aug 15 2012 Milestone
Business Process Go live Mon Aug 19 2013 Milestone
Procurement Procure Mon Apr 01 2013 Wed May 01 2013
Supplier Deliver parts (production) Wed May 01 2013 Mon Aug 12 2013

Classic Gantt chart

And here goes the corresponding Gantt chart:

Gantt chart encoding the tabular data above. (Written in JavaScript).

My version, aka: Gantt90

My enhanced version is shown below. Instead of single tasks I only show the responsible team. Additionally I rotate by 90 degrees – thus Gantt90 – to shift the attention from process flow to responsibility, from a mechanical point of view to a more social one if you want to put it like this.

While the information conveyed is almost equal, the charts size is halved. Hence even the thumbnail becomes readable.

Proposed redesign of a Gantt chart: teams instead of tasks and rotation by 90 degrees.

Adding detail

Since I’m a member of IT, the two blue bars on the right should now convey more information than the others. I do that by highlighting my team and showing the specific tasks along the time axis. Enough detail for the team, and I manage to simultaneously keep track of other teams’ schedules.

Overview and detail combined. The chart could even be made recursive with sub-teams of IT on the right. (…)

Thinking of my big example from the beginning it will be necessary to further divide the detail view on the right. Since projects – tasks as well as teams responsible – fit into hierarchical, tree-like data structures my chart would recursively expand to the right. (IT would then be divided into developers, testers, administrators, etc. and the new chart would resemble its left neighbour – both aligned with the common time axis.)

What about connecting lines?

You may have noticed that I skipped the connecting lines between the taks. I’m convinced that a proper visualization should signalize the project’s inherent structure on its own. Even if the lines are not there, you can see the dependencies between tasks and/or milestones anyway. Your brain does quite a good job at pattern recognition.

tldr: Like spreadsheets, Gantt charts are used to visualize business fiction rather than to manage projects. I’ve proposed a modified Gantt chart to better visualize projects by drawing attention to responsibility rather to single tasks.

Thanks to Elena Reitman’s tweet I stumbled upon the Tufte forum.

I highly recommend the book Envisioning information by Edward Tufte. The charts and the source code used can be found here.


Campus-Tetris revisited

Ich habe bereits über die Raumbuchung am Campus WU und eine damit verbundene Visualisierung der Belegung gebloggt. Hier in aller Kürze eine Visualisierung der Nachfrage nach Räumen.

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.)

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ß.

      .attr("id", "application-frame")
      .attr("class", "application_frame")
      .attr("x", function(d) { return linear_scale(time_to_float(d.start) ) })
      .attr("y", function(d) { return POOL_POS[d.pool_id].y } )
      .attr("height", function(d) { return POOL_POS[d.pool_id].height } )
      .style("fill", function(d) { return occupancy_to_color(d.occupancy) })
        .duration(500) // this is 1s
        .delay(function() { i = i +1; return i * 2; })         

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.



Web to speech

Eine Sache habe ich in den vergangenen drei Jahren verinnerlicht: Das Web und dessen Technologien sind unglaublich dominant, weil sie auf offenen Standards beruhen.

Folglich sind mobile Apps inzwischen oft nur noch Programme, die einen (verstümmelten) Browser öffnen. Auf unserem Selbstbedienungs-Terminal werden Webseiten eingebettet, anstatt dass wir User Interfaces in Qt oder sonstwo entwickelt hätten. Mein Fernseher rendert inzwischen HTML/CSS für sein Menü oder EPG.

Was soll man allerdings machen, wenn das User Interface natürliche Sprache (speech) ausgeben soll – etwas, was man mit JavaScript auch im Jahr 2012 nicht so richtig hinbekommt? Im konkreten Anwendungsfall, dem unten gezeigten Terminal, sollen diverse Informationen zur Orientierung von Personen sowohl für Blinde (Sprachausgabe), als auch Sehende (Klick/Touch) zur Verfügung stehen.

Meine Idee ist eine hybride Anwendung, bestehend aus zentralem Webserver, Browser und lokalem Webserver, der Sprache erzeugt. (Eine Architektur, die ich mir übrigens von der lokalen Bürgerkartenumgebung abgeschaut habe.)

Barrierefreies Leitsystem-Terminal auf Basis unseres Terminals, Codename Humpback. Für Blinde bzw. Personen mit Sehbehinderung soll Sprachausgabe vorhanden sein.

Ein offensichtlich langweiliger Samstagabend und ein paar Tassen Kaffee später läuft unter ein Webserver, der das Kommando say aufruft, welches am Mac die Sprachausgabe regelt. Für Linux käme beispielsweise flite zum Einsatz. D.h. die Webseiten und der Content kommen von einem zentralen Webserver, soll allerdings Sprache ausgegeben werden, so postet die Webseite (mittels AJAX) auf den lokalen Server. Dieser hat Zugang zu Sprachsynthese und Audio. (Oder theroetisch jeder anderen Hardware, die man sich vorstellen will.)

Im konkreten Anwendungsfall könnte man sich nun etwas spielen und häufig verwendete Textbausteine professionell sprechen lassen. Nur dynamischer Content müsste dann von der Computerstimme gesprochen (synthetisiert) werden. Aber ein Proof-of concept ist’s allemal:

Wer auf einem Mac zuhause ist, sollte übrigens das hier in ein Terminal pasten – viel Spaß:

osascript -e 'say "Dum dum dum dum dum dum dum he he he ho ho ho fa lah lah lah lah lah lah fa lah full hoo hoo hoo" using "Cellos"'


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) {

      .attr("id", "day" + data.day)
      .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:




Interactive Digital Signage (part 2)

Although our signage solution using Microsoft’s Kinect has been out in the field for a few months now we’ve decided to beat the big drum for it. My earlier blog post explains all the details, so here’s the buzz:


Interactive Digital Signage with MS Kinect

Despite the high bullshit to fact ratio SIME Vienna was fruitful as Florian Dorfbauer (LaGentz) and I came up with the idea of using Microsoft’s Kinect as a controlling device for public user interfaces.

At WU Wirtschaftsuniversität Wien we’re throwing the current course schedule on large screens. Given the fact that we have up to two hundred courses in the list but – in contrast to airports – only a limited budget for the task the students are presented a slideshow rather than an array of expensive displays. You can imagine that it’s quite boring to watch the screen for a few minutes until your content appears…

Enough of background talk, here’s a video of the prototype solution.

What next?

The nice thing about the proof of concept is that it uses a web browser for content display. So anything can be displayed. The commands from Kinect are entered into the browser as key strokes (thus no browser APIs, compilation, or anything involved).

The challenge from here will be twofold: First we still need a user interface that automatically explains the  interaction possibilities to the user. Second, the Kinect is a brandnew device designed for your living room. So we have no data on its durability out in the field…


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. (…)