Mit Big Data von Business Intelligence zum datengetriebenen Unternehmen

„… aber unser Business Intelligence System verarbeitet schon heute ganz viele Daten.“ Mit dieser Antwort regaieren IT-Verantwortliche häufig, wenn das Management oder eine Fachabteilung nach „Big Data“ fragt.

Wenn Datarella um Unterstützung angefragt wird, liegt allerdings meistens schon ein konkretes Problem vor. An einem bestimmten Punkt ist das Unternehmen an die Grenze dessen gestoßen, was seine bestehenden Systemwelt zu leisten vermag. An diesem Punkt stellt sich eine fachliche Herausforderung an die Datenverarbeitung, die über die bestehende Business Intelligence hinausgeht.

Viele Unternehmen haben in den 80er und 90er Jahren in Business Intelligence investiert, ERP, ‚Enterprise Resource Planning‘ und Data Warehouses aufgebaut. Der initiale Aufwand und die Maintenance dieser Systeme ist beträchtlich. Die Strukturen und Prozesse der Unternehmen wurden nicht selten regelrecht um die rigide Architektur der BI heraumgebaut: „Das geht nicht, das bekommen wir nicht umgesetzt“ ist eine des öfteren zu hörende Aussage.

Mangelnde Flexibilität von BI Systemen

Ein wesentlicher Grund für die mangelnde Flexibilität und geringe Anpassungsfähigkeit der BI-Systeme liegt in ihrem Grundkonzept. ETL – ‚Extract, Transform, Load‘ ist der Grundprozess der Data Warehouses. Die Daten werden dabei aus dem Produktionssystem extrahiert, dann geeignet umgeformt und in die Tabellen relationaler Datenbanksysteme wie Oracle oder SAP gespeichert. Jede Veränderung der Datenstruktur, jedes neue Datenfeld, jede neue Datenquelle, die angebunden werden soll, zieht eine lange Kette von notwendigen Änderungen im Data Warehouse nach sich.

Der schwerwiegende Nachteil des klassischen ETL-Prozesses besteht jedoch darin, dass die Rohdaten aus den Produktionssystemen zuerst transformiert werden, in eine geeignete Form gebracht, bevor sie abgespeichert werden. Dabei gehen viele Daten endgültig verloren. Es ist nicht mehr möglich, die fehlenden Daten nachträglich wieder herzustellen.

Unnötiger Datenverlust 

Ein Beispiel sind die Logfiles von Webservers. Viele Unternehmen extrahieren daraus Clicks, die Links, durch die die Nutzer auf die Seite gekommen sind (Referrer) und weitere Daten zur Nutzung. Diese Daten werden dann in Tabellenform gebracht, eine zum Beispiel mit der Summe der Clicks pro Stunde, eine andere mit den verweisenden Links, eine dritte mit den Browser-Typen und den Endgeräten. Die Verbindung, welcher Nutzer mit was für einem Gerät wann auf welchen Link geklickt hat, geht dabei verloren. Genau diese Verbindung aber ist die Grundlage für wirkungsvolle Empfehlungssysteme, wie sie etwa in einem Webshop angeboten werden sollten. Ebenso ist fast niemals mehr nachvollziehbar, wie die Website zum Zeitpunkt des Clicks ausgesehen hatte, welcher Content genau auf der Seite zu finden war.

Data Intelligence 2.0

An diesem Punkt spätestens kommt Datarella ins Spiel: Eine neue Data Intelligence wird entwickelt. Wir bauen für unsere Kunden einen Datenprozess, der so weit wie möglich die Rohdaten der Produktivsysteme beibehãlt. Aus den Live-Systemen fließen die Daten in ein Auffangbecken – ein ‚Bucket‘ – und werden als mehr oder weniger unstrukturierter ‚Datensee‘ – Data Lake – gesichert. Für die unterschiedlichen Anwendungen werden daraus im zweiten Schritt Reportingsysteme wie ERP bzw. das Data Warehouse befüllt, oder auch Echtzeit-Anwendungen wie Targeting, Empfehlungsmarketing oder Systeme zum Schutz vor Betrug betrieben. Anforderungen und Datenstruktur können dabei auch nach Fertigstellung agil angepasst werden.

Unsere Erfahrung aus zahlreichen Projekten der letzten Jahre zeigt: Der Big-Data-Weg zu Business Intelligence ist nicht nur das passende Werkzeug auf die Anforderung nach Flexibilität und Echtzeitfähigkeit, sondern auch wesentlich günstiger und schneller zu realisieren, als die klassische BI. Mit Big Data wird aus Business Intelligence das datengetriebene Unternehmen.

Was ist Big Data?

Big Data, „große Daten“, ist ein seltsamer Begriff – ein Marketing-Buzzword. Dabei fasst Big Data eine ganze Reihe von Entwicklungen zusammen, die in ihrer Bedeutung für fast jeden Bereich unseres Lebens gar nicht überschätzt werden können: es handelt sich um nicht weniger, als einen vollständigen Paradigmenwechsel, technologisch getrieben, aber schon längst weit jenseits der Technologie wirksam. Nach dem World Wide Web vor 20 Jahren, Social Media (aka Web 2.0) vor 10 Jahren, ist es die dritte Welle von Technologie, die aus dem Internet entstanden ist und sich weltweit ausgebreitet hat.

Aber was ist dieses „Big Data“? Oft ist von den „Drei Vs“ die Rede – Volume, Velocity, Variety. Große Datenmengen, die in schneller Folge gemessen werden sind aber für sich genommen noch nichts Neues. Datenbanken, die auf gewaltigen Servern in Rechenzentren hochperformant „EDV“ machen, gibt es schon lange. Völlig neu aber ist, dass es seit wenigen Jahren Betriebssysteme und Datenbanken gibt, die auf billiger Standard-Hardware laufen; viel leistungsfähiger und nahezu beliebig skalierbar; und das meiste davon ist Open Source.

Hadoop kann man als das „Betriebssystem“ von Big Data bezeichnen. Hadoop, ein Open Source Projekt der Apache-Foundation ist gerade zehn Jahre alt geworden. Es liefert vor allem ein Filesystem, mit dem sich beliebig viele Rechner zu einer einzigen großen Festplatte zusammenschalten lassen. Um Hadoop hat sich schnell ein „Ökosystem“ aus frei verfügbaren sowie kommerziellen Anwendungen entwickelt – ganz wie wir es „damals“ mit Microsoft Windows und dem PC erlebt haben.

Für viele Anwendungen ist es aber nicht einmal nötig, selbst die Infrastruktur aufzubauen. Cloud-Computing wie Amazon Webservices ermöglichen ohne großen Aufwand oder tiefe Fachkenntnisse, größte Datenmengen zu verarbeiten. Da das Pricing nach Rechenzeit geht, kann man mit Test-Daten beginnen und nach erfolgreichem Test skalieren. Dadurch ist es selbst kleinen Teams oder sogar Einzelpersonen möglich, Datenanalyse zu liefern, die vor kurzem ausschließlich größten Rechenzentren vorbehalten war.

Die Daten werden auf den Cloud Systemen a la Hadoop zunächst unstrukturiert abgespeichert. Über Konsistenz, fehlende Werte oder falsche Formatierung macht man sich erst danach Gedanken. Statt wie beim klassischen Data Warehouse die Daten erst in die passende Tabellenform zu transformieren und dann in die Datenbank hochzuladen, bleiben die Daten am besten als Rohdaten auf dem Laufwerk liegen, genau wie sie angekommen sind.

Das Dateiformat, dass sich in der Big-Data-Kultur für alle Metadaten (also Daten, die die eigentlichen Daten – wie Bilder oder Videos – beschreiben) durchgesetzt hat, ist die „Java Script Object Notation“ JSON, in der Informationen als Paare von Schlüsseln und Werten dokumentiert werden, „Key-Value-Pairs“.

Die unstrukturiert auf dem Cloud-System abgelegten Daten können in Datenbanken hochgeladen werden – je nach Bedarf. Dabei kommen neue Datenbank-Konzepte zum Einsatz, die speziell auf unstrukturierte oder halbstrukturierte Daten ausgelegt sind. Diese Datenbanken werden oft als NoSQL bezeichnet. Der Begriff „NoSQL“ leitet dabei in die Irre: auch wenn viele der Big-Data-Datenbanken keine relationalen Systeme mit Tabellen-Logik sind, haben die meisten eine Abfragesprache, die sich stark an SQL orientiert.

Für Datananalyse wird die Programmiersprache Python mehr und mehr zum Standard. Python ist schnell zu lernen – viel intuitiver als die meisten anderen Programmiersprachen in der Anwendung. Für Python gibt es eine gewaltige Menge an Code-Bibliotheken, die praktisch jeden Bereich von Datananalyse abdecken.

Das Programmier-Framework Spark bietet schließlich alle Funktionen, um datengetriebene Anwendungen auf verteilten Rechenanalgen industriell zu skalieren.

Hadoop und Cloud-Computing, Datenbanken für unstrukturierte Daten, Metadaten in JSON, Datenanalyse (z.B. in Python und Spark) – ergeben zusammen Big Data. Und das Beste: für alle Fragen gibt es im Netz jede Menge Unterstützung. Also: keine Angst vor Big Data – einfach ausprobieren!

Alogrithmen Ethik auf der SXSW Konferenz 2016!

Bitte unterstützt unsere Session mit eurer Stimme!

Algorithmen Ethik – Werturteile, subjektive Entscheidungen, sogar völlige Willkür – beherrschen die mathematischen Verfahren in unseren Smart Devices. Darüber haben wir schon einiges erzählt.

Über dieses wichtige Thema wollen wir auf der SXSW Konferenz sprechen. Die SXSW ist die wichtigste und größte Konferenz zu digitaler Kultur und Medien weltweit. Damit unsere Session angenommen wird, brauchen wir unterstützung. Auf der Website gibt es einen einfachen Voting-Prozess.

Hier ist der Link:
http://panelpicker.sxsw.com/vote/46293

Danke für eure Hilfe!

Kontext – bei Smartwatch Apps besonders wichtig

Wenn wir auf die Uhr sehen, so erwarten wir, dass die Uhr uns zeigt, wie spät es ist. Für Uhren ist die Frage „Wie spät ist es?“ der einzige Kontext und ihre Funktion ist (bis auf modische Ausnahmen) völlig auf diese eine Aufgabe zugeschnitten.

Wenn wir unser Smartphone aus der Tasche ziehen, gibt es hingegen viele unterschiedliche Motive und Bedürfnisse: Wir erwarten eine Email, wir haben eine Notification erhalten und wollen nachsehen, um was es geht, uns ist langweilig und wir lesen in unserer Facebook-Timeline, was unsere Freunde schreiben, um uns zu unterhalten, wir wollen nach dem Weg sehen und öffnen Google Maps, und so weiter. Was wir mit unserem mobilen Gerät vorhaben, hängt sehr stark davon ab, wo wir uns gerade befinden und was wir gerade machen: Es ist der Kontext, der bestimmt, was wir für wichtig erachten, und was uns dagegen lästig erscheint. Während wir auf einem Laptop oder PC relativ einfach navigieren können, bedienen wir das Smartphone oft nur mit einer Hand. Jeder Klick stört – wir erwarten, dass die Apps uns von sich aus, kontextabhängig ihre Inhalte anbieten.

Smartwatches unterscheiden sich von Smartphones in der Bedienung in drei Aspekten grundlegend:

  • – Zum Ersten tragen wir die Uhr an einem Arm, damit fällt schon rein physikalisch die Bedienung mit zwei Händen aus.
  • – Zum Zweiten ist der Bildschirm wesentlich kleiner, und
  • – zum Dritten ist die Smartwatch sehr schnell zur Hand – ein kurzer Blick auf’s Handgelenk, selbst in Situationen, bei denen wir kaum wagen würden, unser Smartphone zu zücken, wie bei Tisch oder am Steuer unseres Autos.

Alle drei Punkte verlangen nach maßgeschneiderten Apps, sowohl was die Bedienung betrifft, als auch in Bezug auf die dargestellten Inhalte.

Bisher enttäuschen die Smartwatches und ihre Apps in dieser Hinsicht. Besonders von der Apple Watch hatten wir uns hier mehr versprochen. Die oben dargestellte Kritik von Robert Scoble trifft es auf den Punkt. Von einem persönlichen Begleiter erwarten wir, dass er sich zumindest grob auf unsere aktuelle Lebenssituation einstellt. Dazu wäre es gar nicht nötig, die Privatsphäre zu verletzen. Smartwatches und Smartphones messen über ihre Sensoren alle möglichen Informationen über uns, und zwar lokal. Diese Information kann auch lokal, also in der App selbst und auf dem mobilen Endgerät verarbeitet werden. Ohne dass die App irgendwelche Daten versendet, kann auf dem Gerät selbst der ganze „Simple Context“ berechnet werden, der Ort, an dem wir uns befinden, wie wir uns bewegen und fortbewegen, die Lautstärke und Helligkeit unserer Umgebung, und vieles mehr. Über eine Complex Event Processing Engine kann die App aus diesen Informationen sich sehr präzise auf uns einstellen. Und wie gesagt, es ist dafür nicht notwendig, die Daten aus unserem Mobilfunkgerät irgendwo ins Internet zu übertragen. Gute Beispiele für derartige kontextsensitive Apps gibt es bereits.

Hoffentlich wird die nächste Generation von Smartwatch Apps sich dem Kontext unseres Lebens besser anpassen – das ist nicht schwer, aber konzeptionell eine grössere Herausforderung, als die simple Anpassung einer Smartphone App auf einen kleineren Smartwatch Screen.

App-Entwicklung für die Smartwatch

Der Verkaufsstart der Apple Watch steht unmittelbar bevor. In der Mobilbranche glauben die meisten Insider, dass es Apple erneut gelingen wird, einen großen Trend loszutreten. Viele Anbieter von Apps beginnen daher, Konzepte zu entwickeln, ihre bestehenden Smartphone Apps auf die Smartwatches anzupassen. Wir bemerken eine wachsende Nachfrage nach Beratung und Unterstützung unserer Kunden bei dieser Aufgabe.

Durch die über hundert Smartwatches, die schon heute auf dem Markt sind, gibt es genügend Erkenntnisse, die wir uns für die erfolgreiche App-Entwicklung zunutze machen können. Und tatsächlich gibt es einige Punkte zu beachten, um gute Apps für Smartwatches zu entwickeln.

Displaygröße

Kling trivial, ist aber offensichtlich keineswegs selbstverständlich: Smartwaches haben ein sehr beschränktes Display. Publisher sind offenbar inzwischen durch die wachsenden Bildschirmdiagonalen verwöhnt und können sich nur schwer darauf einstellen, ihre Ansprüche wieder herunterzuschrauben. Aber genau darum geht es. Beim Blick auf das kleine „Ziffernblatt“ muss die relevante Information sofort gut sichtbar in der Mitte platziert stehen.

Der schnelle Blick

Niemand hat den Nerv, sich auf einer Smartwatch umständlich durch ein Menü zu klicken. Die Navigation der Apple Watch ist darauf optimiert, schnell eine App aus dem Homescreen heranzuzoomen. Jede App sollte daher nur genau eine Sache können – die aber dafür gut. Viele Use-Cases klassischer Smartphone Apps sind nicht sinnvoll auf Smartwatches übertragbar. Wir empfehlen daher, im Zweifel auf Features zu verzichten. Die Smartwatches sind (zumindest heute) auch nicht vergleichbar leistungsfähig mit Smartphones – weder von der Rechenleistung, noch vom Speicherplatz. Ökonomischer Umgang mit den Ressourcen ist daher ein Gebot der Höflichkeit gegenüber den Nutzern. Diese werden Bescheidenheit im Umgang mit den knappen Ressourcen auf ihrer Uhr damit danken, dass sie die App nicht gleich wieder löschen.

Unterwegs

Mediennutzung auf den großen Smartphones, die Phablets und Tablets findet hauptsächlich zu hause auf dem Sofa oder im Bett statt, das zeigen alle einschlägigen Studien. Die Smartwatch dagegen hat man stets am Handgelenk. Man muss sie nicht erst aus der Tasche ziehen, man kann stets darauf schauen. An diese Nutzungssituation müssen sich die Apps anpassen – es ist echte mobile Nutzung. Apps sollten daher so autonom wie möglich arbeiten und nicht ständig via UMTS oder Wifi nach Daten aus dem Netz verlangen. Das bedeutet: Nur native Apps haben eine Chance.

Mit einer Hand (oder sogar mit keiner!)

Sport ist der naheliegende Use-Case für alle Wearables. Smartwatches werden aber auch beim Autofahren genutzt. Typische Anwendung: Diktieren! Gerade Chat-Apps wie Whatsapp oder Snappchat machen vor, wie aus das „Texting“ zum „Voicing“ wird. Viele Leute (je jünger desto mehr) sprechen ihre Chat-Nachrichten direkt in das Gerät. Was heute schon beim Smartphone gut funktioniert, wird bei Smartwatches zum zentralen Feature: Einfach die Hand anheben, die Nachricht in die Uhr sprechen, fertig.
Schon bei Apps auf Mobiltelefonen ist es wichtig, dass man die App im Wesentlichen nur mit dem Daumen bedienen kann. Leider nehmen viele Publisher keine Rücksicht auf die Bedienung mit nur einer Hand. Bei Smartwatches gibt es logischer Weise gar keine Alternative, man kann gar nicht mit zwei Händen agieren. Hier ist es noch wichtiger, einfache Gesten einzusetzen – ein Fingertipp muss genügen. Idealer Weise lässt sich die App sogar komplett mit einfachen Sprachkommandos steuern.

Second Screen oder Stand-Alone

Die meisten Smartwatches und auch die Apple Watch sind Zusatzgeräte zum Smartphone, arbeiten also nicht eigenständig. Ein guter Use-Case ist daher, Apps, die auf dem Fon laufen, auf die Watch zu verlängern. Nach kurzer Zeit spielt sich dabei häufig ein neues Nutzungsmuster der Geräte ein. Das Smartphone wird zunehmen seltener aus der Tasche gezogen, da man ja nichts mehr verpasst. Die meisten Nachrichten wie SMS, Twitter oder Whatsapp sind so kurz, dass man sie auch ohne Probleme ganz und gar auf dem Display der Smartwatch anzeigen lassen kann. Das hat zur Konsequenz, dass die Zeit dramatisch zurück geht, in der die Leute auf ihren Smartphone-Bildschirm starren. Schon allein deshalb ist es für jeden Publisher wichtig, den Nutzern einen guten Grund zu liefern, auch weiterhin die Inhalte zu nutzen. Der Weg führt über eine sinnvolle Kombination von Smartphone-App mit Smartwatch-App – die Stamm-App wird auf das Ziffernblatt der Smartwatch verlängert. Umgekehrt werden manche Nutzungsformen deutlich einfacher. Während es oft nicht opportun ist, das Handy aus der Tasche zu ziehen, ist der schnelle Blick auf die Armbanduhr in der Regel kein Problem. Apps, die diese Nebenbeinutzung unterstützen haben daher mehr Chancen auf Erfolg.

Auch wenn zunächst das Smartphone als „Schaltzentrale“ in der Tasche weiter läuft, bietet es sich durchaus an, über Apps nachzudenken, die ausschließlich auf der Smartwatch laufen. Generische Smartphone Apps werden über kurz oder lang das Rennen machen, genauso, wie erfolgreiche Mobile-Apps auch keinen Computer im Hintergrund mehr benötigen. Apps, die sich bisher mittels HTML5-Websites über echte Smartphone-Funktionalität hinweg gemogelt haben, werden auf Smartwatches kaum Chancen haben.

Spam-Nachrichten vermeiden

Das Smartwatch-Display dient als Nachrichtenticker. „You always have Mail“ ist allerdings die traurige Wahrheit. Wir brauchen nicht noch mehr Hinweise auf Dinge, von denen wir ohnehin nichts hören wollen. Apps, die ihre Nutzer mit Notifications belästigen, werden als lästiger Spam schnell wieder gelöscht. Benachrichtigungen sollten immer die Ausnahme bleiben. Eine Nachricht ist nur wert, was wirklich unbedingt sofort am Handgelenk verfügbar sein muss, z.B. zur Navigation.

Energieverbrauch

Smartwatches leiden unter geringer Batteriekapazität. Apps, die durch ihren Stromhunger die ohnehin kurze Laufzeit der Uhr merklich verkürzen, werden schnell gelöscht. Die Smartwatches bieten umgekehrt noch mehr faszinierende Daten, die sie über ihre Sensoren sammeln. Neben den üblichen Bewegungsmessern wie Gyroskop oder Accelerometer kommen physiologische Sonden wie z.B. Messung von Puls oder Sauerstoffsättigung im Blut dazu. Damit Eröffnen Smartwatches viele neue Möglichkeiten im Bereich Wellness, Sport und Gesundheit.
Beim abtasten der Sensordaten gibt es keine Kompromisse. Hier muss auf äußerste Sparsamkeit im Stromverbrauch geachtet werden. Dabei ist es häufig besser, nicht die Standard-Schnittstellen der Betriebssysteme zu nutzen. Hier sind die Einstellungen, den Verbrauch zu Regeln oft begrenzt. Am besten ist es, die Sensortechnik direkt in die App einzuprogrammieren. Dadurch lässt sich der Verbrauch meist im erträglichen Rahmen halten.

App-Marketing

Smartwatch-Apps brauchen eigenes Marketing. Nur weil der Use-Case der herkömmlichen Smartwatch-App für die Nutzer klar ist, heißt das noch lange nicht, dass die App auch auf die Uhr installiert wird. Smartwatches genießen zur Zeit hohe Aufmerksamkeit. Es bietet sich daher an, die Smartwatch-App primär zu bewerben und die „klassische“ App Huckepack zu nehmen und nicht umgekehrt. Besonders die ungewohnte Ästhetik der Smartphone-Displays ist ein Eye-Catcher. Die Kommunikation einer App, die jetzt neu für Smartphones bereit steht, wird auch die zu Grunde liegende Smartphone-App in den Fokus rücken.

Gutes Briefing

Wie immer steht am Anfang einer erfolgreichen Entwicklung das gute Briefing. Wir empfehlen aus Erfahrung ein agiles, iteratives Vorgehen – Design Thinking. Da es nur wenig Erfahrungswerte mit Smartwatch-Apps gibt, ist es wichtig, offen für Änderungen am Konzept zu bleiben. Nicht jede Idee, die anfangs plausibel erschien, hält der Realität stand. Es ist bei einer so ungewohnten Technologie hilfreich, sehr schnell zu ersten Prototypen zu kommen. Oft lässt sich die User-Acceptance schon mit einem einfachen Dummy testen. Selbst aus Pappe und Papier lassen sich sinnvolle Testversionen basteln, die häufig viel Zeit und Geld sparen, indem man Sackgassen vermeidet und schnell aufs Wesentliche im User Interface kommt. Am Ende der ersten Entwicklungsphase steht dann ein Minimum Viable Product, ein MVP. Das MVP liefert genau die Funktionalität, mit der die App gerade ihre Aufgabe erfüllen kann. Das ist häufig zwar schon an sich ausreichend, aber bei Bedarf kann man von hier aus immernoch ins Detail gehen.

Der Wettbewerb bei den Smartwatch-Apps werden auf jeden Fall noch sehr viel stärker, als im klassischen App-Store. Smartwatches bieten aber auch viele neue, faszinierende Möglichkeiten für die Publisher. Für jedes App-Projekt lohnt sich heute, die Anwendung auf der Smartwatch in die Ideenfindung einzubeziehen. Und selbst, wenn (noch) keine Smartwatch-App entwickelt wird: Der Purismus, den die knappen Ressourcen auf der Smartwatch der App-Entwicklung abverlangt, tut jeder App gut, selbst wenn sie auf einem Hochleistungs-Tablet laufen soll.

Mehr zum Thema:


Erfolgreiche App-Entwicklung mit Location Based Services

Second Screen
Batterie – Die Achillesferse für Mobile Tech
Smartwatches – Our most personal data yet.

Data is the new Media

Data Storytelling, Daten-Journalismus und sogar „Data Fiction“ – seit Big Data auf die Bühne getreten ist, werden Daten mehr und mehr zum Handwerkszeug für Erzählungen. Mit Mustererkennung, explorativer Datenanalyse und besonders mit Datenvisualisierung verlagert sich der Schwerpunkt von Daten von quantitativ zu qualitativ.

Immer mehr Anwendungen unterstützen uns dabei, mit Daten eine Geschichte zu erzählen. Dashboards wie Tableau oder DataLion zapfen unsere Datenquellen an und übersetzen die Zahlen in ein visuelles Format, dass wesentlich leichter verdaulich ist. Sogar hoch multivariate Daten legen uns ihre Bedeutung offen, wenn wir zur Analyse tools wie Gephi oder sage wir das berüchtigte Palantir einsetzen. Diese Hilfsmittel machen auch Social Media Analysen und Text-Mining für Sozialforschung und für die Markt- und Werbeforschung zugänglich.

Jawbone Up not only tracks our sleep. The app also shares our data in a meaningful way with our friends - like we share our thoughts on Twitter.
Jawbone Up verfolgt nicht nur unseren Schlaf. Die App teilt unsere Daten auf sinnvolle Weise auch unseren Freunden mit – ganz so, wie wir unsere Gedanken über Twitter mit ihnen teilen.
Data driven Storytelling hat inzwischen die meisten Sachtexte erobert. News Publisher wie die New York Times oder der Guardian beschäftigen enorme Teams aus Infografik-Spezialisten, um ihre Reportagen mit sinnvollen Datenvisualisierungen anzureichern. Einige der Redakteure haben großartige Sammlungen mit wunderschönen Beispielen zusammengestellt, z.B. informationisbeautiful.net.

Unsere allerpersönlichsten Daten werden jedoch auf unseren Mobiltelefonen und tragbaren Geräten erzeugt. Auf unseren Smartphones, Armbändern oder Smartwatches sammeln etwa zwanzig Sensoren ununterbrochen Daten über unser Verhalten und unsere Handlungen. Eine Vielzahl von Apps nutzt diese Mobile Data: Sie unterstützen unser Training, zeigen uns den Weg, finden Freunde in der Nähe, lassen uns Bilder teilen, u.s.w.

Many people already share their daily workout via apps like Strava or Runtastic. It is even quite common to let such apps automatically post your training results into your social media timeline, e.g. to Twitter or Facebook.
Viele Leute teilen schon heute ihren täglichen Sport mit Apps wie Strava oder Runtastic. Es ist sogar ziemlich verbreitet, dass wir diese Apps unsere Training-Ergebnisse automatisch in unsere Social Media Timeline posten lassen, z.b. auf Twitter oder Facebook.

Apps wie Jawbone Up oder Strava verfolgen nicht nur unsere sportlichen Aktivitäten, sie bieten auch einen einfachen Weg, die Daten, die sie gemessen haben, zu teilen. Wir veröffentlichen unsere Trainingsdaten genauso, wie wir unsere Geschichten auf Twitter oder Facebook veröffentlichen. Unsere Daten werden gleichwertig mit unseren Texten und den Bildern, die wir posten. Die am weitesten integrierte Version dieses Daten-als-Geschichte-Erzählens bietet Google Now.

Image on top: Google Now. Google Now follows the idea to display all kinds of information in the form of tiles, like Twitter or Facebook would display the posts of the people you follow in a timeline. Funny enough, Google obviously has no clue where my "place of work" seams to be.
Zum Bild ganz oben: Google Now verfolgt die Idee, alle möglichen Informationen in Form von Kacheln darzustellen, so wie Facebook oder Twitter die Posts von Leuten, denen wir folgen, in unserer Timeline darstellt. Lustiger Weise scheint Google offenbar keine Ahnung zu haben, wo mein „Arbeitsplatz“ tatsächlich liegt.“

Daten als Medien – das gilt nicht nur für die Inhalte. Werbung, die ja im Großen und Ganzen schon seit Jahrzehnten durch Daten getrieben wurde, ist heute in einem gewaltigen Umbruch begriffen. Mediaplanung und Mediaeinkauf – die Kunstfertigkeit, Werbung auf so effizient wie möglich zu schalten, das heißt, die Wirkung bei gegebenem Budget zu optimieren – verändern sich dramatisch. Etwa 20% der Werbung wird inzwischen programmatisch geschaltet. Programmatic Buying bedeutet, das ein Algorithmus entscheidet, ob ein bestimmter User der richtige ist, unsere Kampagne ausgespielt zu sehen, anstelle dass eine Werbeplatzierung explizit durch einen Auftrag bestellt wird, so wie in der Vergangenheit. Die Entscheidung, welcher User genau dem Ziel der Kampagne entspricht, wird auf Basis einer Vorhersage getroffen, die aus dem Daten der Verhaltensbeobachtung des Users berechnet wird. Daten bestimmen somit, welche Werbung wir sehen.

Mit der Idee des ‚Quantified Self‚ beginnen Daten sogar unsere Vorstellung von Identität zu erobern. Wir sind nicht nur, was wir sagen, wie wir erscheinen, wie wir willkürlich handeln, vielmehr sind wir ebenso durch unser Innenleben definiert, unsere körperlichen Funktionen, durch die Daten, die unser physisches Selbst erzeugt. Die Konzeption des Selbst verändert sich durch diese Betrachtungsweise, indem die strenge Trennung von Geist und Körper, von bewusst und unbewusst überwunden wird. Die physischen Aspekte unseres Lebens treten nun als gleichbereichtiger, wahrhaftiger Teil unseres Selbst auf.

Daten werden zum integralen Bestandteil unserer Erzählungen. Sie durchdringen alle Medien. Wir sollten lernen, Daten als Teil unseres Lebens zu sehen, so wie wir daran gewöhnt sind, über unser Leben mit Worten zu erzählen.

Weiter zum Thema:

We are content!
Daten Stories: Von Fakten zu Fiktion.

Erfolgreiche App-Entwicklung mit Location Based Services

Alle Smartphones besitzen Navigation. Die Geo-Location ist eine der wichtigsten und meistgenutzen Funktionen unserer mobilen Endgeräte. Smartphones helfen uns unterwegs. Wo wir uns befinden, ist ein wesentlicher Kontext für unsere Handlungen und unsere Bedürfnisse. Und viele Apps können durch Einbeziehung unserer Position viel nützlicher für uns werden. Ob Tipps zum Ausgehen in der Umgebung, ob „Einchecken“ an interessanten Orten, damit unsere Freunde sehen, wo wir sind – es gibt unendlich viele Anwendungen für Location Based Services, LBS. Auch für den kommerziellen Einsatz gibt es mannigfaltige Fälle: Sonderangebote im Café für treue Kunden, die regelmäßg vorbeikommen, Empfehlungsmarketing „Kunden, die diese Waren gesucht haben, kauften auch dieses Produkt“ und natürlich Marktforschung und Werbeplanung für die Wirksamkeit von Out-Of-Home Werbung.

Es gibt ein paar wichtige Regeln, die wir bei der Entwicklung von Apps gelernt haben, die Location Based Services anbieten. In den ersten vier Abschnitten stellen kurz ein paar technische Rahmenbedingung vor, in den letzten beiden Abschnitten gehen wir auf das Design der von Apps mit Location Based Services ein.

Viele Wege der Positionsbestimmung

Der Ortungsvorgang besteht aus zwei Schritten. Zuerst muss eine Position im Raum gemessen werden, zum Beispiel geografische Länge und Breite oder die Entfernung zu einer bestimmten Funkquelle. Diese Koordinaten sind für uns im Alltag allerdings weitgehend unbrauchbar: Es sind zunächst einfach nur Zahlen. Als Zweites muss daher die Position in einen echten Ort übersetzt werden, zum Beispiel einen Punkt auf einer Landkarte, eine Postadresse oder eine bestimmte Filiale einer Handelskette. Objekte oder Menschen in diesen zwei Stufen im Raum verorten nennt man im Fachjargon „Registrierung“ (engl. registration).

Rein technisch kann die Ortung der Position im Smartphone über viele verschiedene Sensoren erfolgen. Auch GPS, fast schon synonym für Geo-Location steht, ist die Ortung via Satellit vielleicht nicht einmal die wichtigste Quelle für unsere Koordinaten. Sobald das Smartphone Netzempfang hat, steht die Information über die Funkzellen zur Verfügung. Jede dieser Zellen umgibt einen Funkmasten und ist meist wenige hundert Meter im Durchmesser. Die Ortsbestimmung über Funkzellen ist im Verhältnis relativ ungenau, verbraucht aber im Gegenzug kaum zusätzlich Batterie, da das Telefon diesen Dienst sowieso nutzt.

Beacons sind schwache Bluetooth-Sender, die zum Beispiel in Läden oder Restaurants angebracht werden. Jeder Beacon hat seine eigene Kennung und kann daher von Apps zur Registrierung genutzt werden, sobald Bluetooth am Telefon eingeschaltet ist.

Wifi und Google Services

Besonders in Innenräumen sind schon heute Wifi-Netze gut zur Ortsbestimmung geeignet. Wenn Informationen über den Ort bestimmter Wifi-Kennungen vorliegen (z.B. die Wifis der eigenen Ladengeschäfte oder Restaurants), ist das Wifi sogar die beste Quelle für eine schnelle, batterieschonende Registrierung.

Wifi-Netze liefern sehr präzise die Position auch in Innenräumen ohne guten Satelliten- oder Netzempfang. Neben der SSID - dem "Namen" des Wifi, den man als Nutzer frei wählen kann, identifizieren sich die Wifi-Router über eine zweite, eindeutige Kennung, die BSSID.
Wifi-Netze liefern sehr präzise die Position auch in Innenräumen ohne guten Satelliten- oder Netzempfang. Neben der SSID – dem „Namen“ des Wifi, den man als Nutzer frei wählen kann, identifizieren sich die Wifi-Router über eine zweite, eindeutige Kennung, die BSSID.
Google stellt mit den Google Services ein Paket von Diensten für das Smartphone-Betriebssystem Android zur Verfügung, mit dem viele Wifi-Netze weltweit automatisch in Orte übersetzt werden. Allerdings sind diese Services nur in Andoid-Versionen von Google vorinstalliert. In den meisten generische Android-Distributionen wie Cyanogenemod oder Miui von Xiaomi müssen die Google Services erst von den Nutzern installiert werden. (Das Betriebssystem iOS von Apple bietet diese Funktion ebenfalls, allerdings gibt es von iOS keine unabhängigen Versionen – die Situation ist hier also einfacher).

In vielen Teilen der Welt, aber insbesondere in China, nutzen die große Mehrheit der Menschen Smartphones mit generischem Android, also ohne Google Services. Soll die Ortsbestimmung über Wifi auch für Nutzer außerhalb Europas und der USA funktionieren, ist es daher wichtig, um diese Lücke herumzuentwickeln. Braucht man für die Location Based Services nur die eigenen Standorte (zum Beispiel die Filialen einer Restaurantkette), können die Wifi-Netze in der App hinterlegt werden und die Positionierung kann ohne weitere, externe Information stattfinden.

Batterieverbrauch

GPS, Wifi und Bluetooth verbrauchen zusätzlich Strom, wenn der Ort bestimmt werden soll. Oft ist die User Experience bei Apps mit Location Based Services schlecht, weil sich die Akkulaufzeit drastisch verkürzt. Das Ergebnis: Die App fliegt wieder vom Telefon. Es ist daher wichtig, den Stromhunger der App zu steuern. Zunächst sollte der Ort nur dann und nur so oft abgefragt werden, als es auch tatsächlich notwenig ist, um die Funtionalität der App zu unterstützen. Wenn der Ort regelmäßig abgefragt werden muss, etwa weil die Position dynamisch bestimmt wird, während der Nutzer sich bewegt, sollte sich die Abtastrate an die Geschwindigkeit anpassen. Bewegt sich eine Nutzerin zu Fuß, reicht in der Regel ein Datenpunkt pro Minute oder sogar seltener. Auch bei höheren Geschwindigkeiten ist eine hohe Sampling-Rate nicht unbedingt erforderlich. Wenn die Bewegung gleichmäßig ist, sich also nicht Beschleunigungen und Bremsvorgänge abwechseln, ist es ebenfalls ausreichend, nur alle Minuten den Ort abzufragen. Schließlich sollte die App von selbst „respektieren“, wenn die Batterie zur Neige geht und die Ortungsfunktionen herunterfahren, bevor der Akkustand kritisch wird.

Offline

Häufig haben wir schlechen Internetempfang auf dem Smartphone. Außerhalb der Städte sind lahme Verbindungsgeschwindigkeitn wie EDGE oder gar GPRS eher die Regal als die Ausnahme. Und auf Reisen im Ausland fehlt uns meist die Internetverbindung komplett, wenn wir nicht teure Roaming-Gebühren in Kauf nehmen wollen. Eine App mit Location Based Services sollte dies berücksichtigen. Wenn die App nicht nativ läuft, sich also Web-Inhalte als HTML-Seiten holen muss, um ihren Dienst zu tun, ist es schlicht nicht möglich, einen guten Service unabhängig von der Netzverbindung anzubieten. Dabei ist es meistens nicht notwenidig, dass sich die App Informationen aus dem Netz in Echtzeit zieht. Sehr gut können Karten, Gutscheine, Aktionen hinterlegt werden, wann immer eine ausreichende Netzverbindung besteht. Die Nutzer erleben dann eine interaktive App mit Location Based Services ohne den frustrierenden, ewigen Ladekreisel oder die lästige Meldung „Connection timed out“. Mit einer Complex Event Processing Engine CEPE, wie Datarella sie entwickelt hat, lassen sich sogar komplexe Interaktionen völlig lokal steuern; eine Netzverbindung ist nur für gelegentliche Updates nötig, wofür das Wifi im Hotel oder zu Hause völlig ausreichen.

Eine Lösung für genau eine Aufgabe

Die App "München Navigator" der Deutschen Bahn hatte ursprünglich nur eine einzige Funktion: Sie zeigte die Position der S-Bahnen in Echtzeit - gerade wenn man umsteigen muss sehr praktisch. Leider hat die Bahn (wie so viele andere Unternehmen) diese App unglaublich aufgeblasen. Jetzt kann sie fast alles, aber nichts wirklich gut. Um auf ihre Kernfunktion zugreifen zu können, muss man drei mal klicken - für eine App, die man unterwegs benutzen soll ein absolutes No-Go.
Die App „München Navigator“ der Deutschen Bahn hatte ursprünglich nur eine einzige Funktion: Sie zeigte die Position der S-Bahnen in Echtzeit – gerade wenn man umsteigen muss sehr praktisch. Leider hat die Bahn (wie so viele andere Unternehmen) diese App unglaublich aufgeblasen. Jetzt kann sie fast alles, aber nichts wirklich gut. Um auf ihre Kernfunktion zugreifen zu können, muss man drei mal klicken – für eine App, die man unterwegs benutzen soll ein absolutes No-Go.
Location Bases Services werden logischer Weise vor allem unterwegs genutzt. Beim Gehen, beim kurzen Stehenbleiben an der Bushaltestelle oder beim Suchen nach den Sonderangeboten vor dem Regal im Supermarkt, will niemand sich mühsam durch Menüs klicken. Die Funktion der App muss sofort und ohne Umwege zur Verfügung stehen. Location Based Services verlangen also Apps mit hochspezifischer Funktion. Am besten, die App macht genau eine einzige Sache, aber diese gut. Leider gibt es viele Beispiele, bei denen alle möglichen Funktionen zum eigentlichen Location Based Service dazugepackt werden. Das Ergebnis: Die App wird seltener genutzt, die User Experience ist schlechter.

Bedienung mit einem Finger

Die Regel der Einfachheit gilt dabei nicht nur für die Funktionen sondern auch für das User Interface, die Benutzeroberfläche. Unterwegs haben wir meistens nur eine Hand frei und zwar nicht immer die rechte (wenn wir Rechtshänder sind). Die Benutzeroberfläche sollte unsere Einhändigkeit unterstützen. Die App sollte ausschließlich mit dem Daumen leicht bedienbar sein. Alle komplexeren Funktionen (wie zB Nutzereinstellungen) sollten in ein Menü gepackt werden, damit sie nicht von der Kernfunktion ablenken. Es gibt jede Menge Apps mit gelungenen User Interfaces, ein gutes Beispiel ist Tinder.

Die letzten drei Regeln gelten selbstverständlich für alle Apps, nicht nur für Location Based Services. Jahrelange Erfahrung zeigt, dass Apps, die diese beiden Regeln berücksichtigen, wesentlich besser bei den Usern ankommen. Für Apps, die vor allem unterwegs benutzt werden sollen, sind sie aber unverzichtbar. Wenn wir uns an diese einfachen Regeln beim App Design halten, kann schon fast nichts mehr schief gehen, mit unseren Location Based Services – vorausgesetzt, wir haben auch noch eine gute Idee, was unsere App eigentlich liefern soll 🙂

Mehr zum Thema

Batterie – die Achillesferse für Mobile Tech
Mobile Payment – für Starbucks bereits Realität
Neue Location-Tracking Funktion mit iOS 7
Mit Smartphone Daten die Geschichte unseres Alltags erzählen
Data Storytelling: Stepwise Abstraction from Raw Data