Sie werden aus „130d0027600c30“ nicht schlau? Dann geht es Ihnen wie wahrscheinlich den meisten Menschen, und das ist völlig in Ordnung. Doch genau diesen Zeichensalat sendet Ihnen ein Sensor regelmäßig zu. Diese Daten sind sehr gut von Maschinen les- und auswertbar. Von Menschen dagegen nicht. Deswegen ist es notwendig die Sensordaten so aufzubereiten, dass ein Mensch sie gut verstehen und interpretieren kann.
Der vom Programmieraufwand einfachste Weg zur Datenvisualisierung wäre eine Liste mit Zeitstempeln, Sensornamen und decodierten Sensordaten. Im Falle unseres obigen Zeichensalats, stammen die Daten von einem Raumklimasensor, der Temperatur und Feuchtigkeit misst. Hat man jedoch mehr als ein oder zwei Sensoren und läuft das Ganze länger als eine Woche, wird diese Liste sehr lang und unübersichtlich. Deshalb ist es häufig so, dass ein Dashboard, also eine Visualisierung der Daten, genauso wichtig ist wie die Sensoren selbst.
Ein Dashboard hat den Vorteil, dass Sensordaten durch Design und Aufbau eine Struktur bekommen, die für den Menschen leicht verständlich ist. Mit Hilfe von Graphen werden aktuelle sowie historische Daten visualisiert und so für den Menschen nutzbar gemacht. Zusätzlich kann auf bestimmte Situationen wie Alarme und Grenzwertüberschreitungen aufmerksam gemacht werden und die Informationen genau den Personen zur Verfügung gestellt werden, die sie benötigen.
Doch damit dies zuverlässig und zufriedenstellend gelingt, müssen Sie bei der Entwicklung des Dashboards auf einige Dinge achten:
Was ist das Ziel des Dashboards? Was soll damit erreicht werden?
Das Ziel des Dashboards ist eine grundlegende Frage für dessen Entwicklung. Arbeitet das Entwicklungsteam hier anfangs nicht gründlich genug, kann es im späteren Verlauf zu Unklarheiten und Problemen kommen. Die Ziele können dabei sehr unterschiedlich sein: Wollen Sie Grenzwerte und Zustände überwachen? Im historischen Verlauf Muster entdecken? Oder Kennzahlen auswerten? Je nach Ziel bereitet man die Daten anders auf und passt den Aufbau des Dashboards und die Auswahl der Graphen an die Ziele an. Stellt man sich den Bau eines Dashboards als Bau eines Hauses vor, so wäre die Zieldefinition etwas wie der Bauplan. Sind schon dort Fehler enthalten, hat dies weitreichende Folgen in der späteren Bauphase, da deren Behebung im weiteren Verlauf größeren Aufwand mit sich bringt als wäre der Bauplan von Beginn an entsprechend gestaltet.
Wer ist der Endnutzer des Dashboards? Und in welchem Kontext wird es genutzt?
Fast noch wichtiger als die Anpassung des Dashboards auf das Ziel ist die Anpassung an den Endnutzer und den Nutzungskontext. Was für ein Typ Mensch ist der Endnutzer? Interessieren ihn eher klare Zahlen oder helfen ihm grafische Elemente besser? Stellen Sie sich vor, Sie bauen ein Haus für einen Freund und richten sich aber nur nach Ihren eigenen Vorstellungen. Wenn dem Freund dann später die Einrichtung oder die Raumaufteilung nicht gefällt, wird er nicht in dem Haus wohnen wollen und die Arbeit war umsonst. Das gleiche kann beim Dashboard passieren: Findet sich der Endnutzer im Dashboard nicht zurecht, nutzt er es nicht gern.
Genauso ist es mit dem Nutzungskontext: Ist Ihr Freund viel unterwegs, gefällt ihm ein Campingwagen wahrscheinlich sogar besser als ein Haus. Dieses Prinzip lässt sich auch auf Dashboards übertragen: Wenn ein Dashboard von dessen Endnutzern hauptsächlich unterwegs genutzt wird, wie zum Beispiel einem Außendienstler, muss es für Smartphones optimiert werden damit die Nutzung praktisch und an die Bedürfnisse des Nutzers angepasst ist. Deshalb muss immer bedacht werden, ob auf Grund des Nutzungskontexts das Dashboard weitere Anforderungen erfüllen muss, damit der Endnutzer das Dashboard auch annimmt und nutzt.
Welche Daten sollen dargestellt werden? Werden dafür neben den Sensordaten noch zusätzliche Daten wie der Standort benötigt?
Die Sensordaten kann man als das Grundmaterial zum Bauen des Dashboards beschreiben. Ohne sie hat man keine Daten zum Darstellen. Doch meist reichen die reinen Sensordaten nicht aus. Selbst nachdem der Computer aus „130d0027600c30“ 41% Luftfeuchtigkeit und 23,2 Grad Celsius gemacht hat, fehlen uns noch Informationen wie der Standort des Sensors, bestimmte Grenzwerte und Kontaktinformationen bei Grenzwertüberschreitungen. Das Grundmaterial muss also aufbereitet und angereichert werden, damit es seine Aufgabe, die Dashboard-Ziele und -Anforderungen zu erfüllen, meistern kann. Eignet sich das Baumaterial nicht, kommen auch hier Probleme auf.
Welche Plattform eignet sich aufgrund der Anforderungen am besten?
Sind die Ziele und Anforderungen an das Dashboard klar, ist die nächste Entscheidung die Plattform. Sie legt die Möglichkeiten und Grenzen des Dashboards fest. Hat man sich einmal für eine Plattform entschieden und mit dem Bau des Dashboards begonnen, fällt ein Plattformwechsel meist schwer, da es hier zu Migrationsproblemen kommen kann. Ist das Fundament des Hauses einmal gegossen, entscheidet man sich ja in der Regel auch nicht für ein anderes Grundstück. Die Wahl muss also mit Bedacht erfolgen, da sich die Möglichkeiten und Grenzen der jeweiligen Plattform in Bezug auf Anpassung, Datenanalyse und Entwicklungsaufwand unterscheiden.
Sind diese Fragen geklärt, kann man das eigentliche Haus mit seinen Zimmern, also das Dashboard an sich mit seinen verschiedenen Graphen bauen.
Bei der Entwicklung von Dashboards gibt es also mehr zu beachten als nur die richtige Auswahl der Graphen. Sind die Ziele und Anforderungen nicht von Anfang an klar definiert, hat man im späteren Verlauf mit teilweise weitreichenden Folgen zu kämpfen, die im schlimmsten Fall das Projekt zum Scheitern bringen. Deshalb hilft es, hierfür Experten zu Rate zu ziehen, die objektiv entscheiden können und mit ihrer Erfahrung das Dashboard zum Erfolg führen können. Wenn Sie Hilfe bei der Entwicklung eines Dashboards benötigen, melden Sie sich gern bei uns!
