Blockpraktikum “Informationsvisualisierung mit Processing”

Vom 1. bis 9. März. fand dieses Jahr erstmals das Blockpraktikum “Informationsvisualisierung mit Processing” statt. Diese Veranstaltung richtete sich an Studenten von Medieninformatik und Kunst und Multimedia. Spezielle Vorkenntnisse waren nicht nötig, so dass auch Studenten aus den ersten Semestern teilnehmen konnten. Einen Einblick in den Ablauf und die einzelnen Tage geben die folgenden Berichte, Bilder und ein Video:

Die Teilnehmer erhielten in den ersten beiden Praktikumstagen eine theoretische Einführung in die Grundlagen der Informationsvisualisierung und wurden in praktischen Übungen an die Programmiersprache Processing herangeführt. Processing ist eine auf Java basierende, speziell auf grafische Ausgabe ausgelegte Programmiersprache, welche eine sehr schnelle Skizzierung von Ideen durch wenig Code ermöglicht. Da Processing ursprünglich zu Lehrzwecken entwickelt wurde, erlaubt die Sprache zudem einen sehr einfachen Einstieg und eine steile Lernkurve. In diesem Sinne konnten bereits an den ersten Tagen schon interessante kleine Programme erstellt werden, die mit Blick auf die anschließenden Infovis-Projekte wichtige praktische Konzepte und Kenntnisse vermitteln sollten: Dazu gehören neben den grundsätzlichen Möglichkeiten für das Zeichnen und Gestalten grafischer Elemente auch Animationen, einfache physikalische Simulationen, Mausinterkation sowie natürlich das Einlesen von externen Daten. Einige dieser Übungen und Spielereien der ersten Tage können hier abgerufen und direkt im Browser ausprobiert werden: Openprocessing Classroom


Für die anschließenden Gruppenprojekte mussten die Teams sich jeweils als erstes auf eine Datengrundlage einigen: Was sollte visualisiert werden? Dazu wurden in einer Kreativ- und Recherchephase verschiedene offene Daten gesucht und bewertet, Hand in Hand mit der Entwicklung erster grober Konzepte zu möglichen Darstellungsformen. Hinsichtlich der Informationen ging es vor allem darum, Daten zu finden, deren nähere Betrachtung potentiell interessante Einsichten ermöglichen würde. In diesem Sinne wurden schließlich Konzepte für die interaktive Darstellung der gewählten Informationen weiter ausgearbeitet. Als ersten Schritt erstellten die Gruppen hierbei ein großformatiges Poster, anhand dessen sie den anderen ihre Visualisierungsidee vorstellen konnten. In den anschließenden Diskussionen mit den anderen Gruppen ergaben sich somit bereits hilfreiche Hinweise und Vorschläge bezüglich der Konzepte sowie möglicher Implementierungsansätze.

Mit dem Feedback aus der Posterpräsentation machten sich die Teams dann an die Arbeit. Einen näheren Einblick in den jeweiligen Verlauf der Gruppenprojekte geben die Berichte der Teilnehmer selbst weiter unten in diesem Beitrag. An dieser Stelle folgt ein eher allgemeiner Überblick: So musste zu Projektbeginn erst einmal eine gemeinsame Arbeitsplattform ausgetüftelt werden, da sich Processing nicht direkt mit einer Versionsverwaltung o. ä. verknüpfen lässt. Eine Möglichkeit schien zunächst der Multi-User-Editor für Processing auf http://www.sketchpadd.cc, der jedoch diverse Probleme und Inkompatibilitäten zeigte, sodass die Gruppen sich schließlich auf eine gemeinsame Dropbox einigten. Im Gegensatz zu Java erlaubt Processing das Aufteilen von Methoden (der Hauptklasse) auf verschiedene Dateien, was sich für gemeinsames und paralleles Arbeiten als sehr nützlich heraus stellte.

Auf dieser Grundlage begannen die Gruppen mit der Umsetzung erster fundamentaler Funktionen, wie etwa dem Einlesen der Daten bzw. einer API-Anbindung (LastFM, Twitter, s. u.). Einige Teile dafür konnten aus den vorangegangen Übungen wieder verwendet werden, was somit eine gute Startgrundlage ergab. An vielen Stellen mussten die gewählten Datensätze allerdings erst noch aufbereitet werden, um den geplanten Visualisierungskonzepten dienlicher vorzuliegen. Dadurch ergab sich hier bereits auch eine sehr gute Möglichkeit zur Arbeitsteilung: Auf der einen Seite wurde an der Datenverarbeitung gefeilt, während andererseits gleichzeitig bereits erste Funktionalitäten zur Darstellung implementiert werden konnten. Auch ein paar externe Libraries, von denen es für Processing sehr viele gute gibt, fanden sinnvoll Verwendung; z.B. für GUI-Elemente sowie geometrische Berechnungen (etwa Punkt-in-Polygon-Test) und Transformationen. Im Laufe der Woche setzten die Teams ihre Ideen dann mit Processing um. Nach einer arbeitsreichen Woche fand abschließend eine Präsentation vor den Kursteilnehmern, Mitarbeitern des Lehrstuhls und interessierten Studenten statt, bei der die Teams ihre Ergebnisse vorstellten und Feedback erhalten konnten.

Es folgen nun die “Entwicklertagebücher” der Teilnehmer. Die Texte wurden von den jeweiligen Gruppen verfasst. An dieser Stelle nochmals vielen herzlichen Dank an alle Teilnehmer, die den Kurs zu einer gelungenen Veranstaltung gemacht haben! 🙂

Gruppe 1: TweeTree

Wir haben uns für das Projekt für eine Visualisierung von Tweets entschieden.
Dabei sollen für einen auswählbaren Nutzer eine bestimmte Anzahl der aktuellsten Tweets mit einem Knotengraphen visualisiert werden.
Bei einem MouseOver über die Knoten soll der Text des Tweets angezeigt werden.
Tweets, die Mentions enthalten, sollen gesondert markiert werden und anklickbar sein.
Bei einem Klick auf diese soll ein Weiterer Graph mit den Tweets des erwähnten Nutzers als neuer Ast entstehen.

Tag 1:

Über die Twitter-API können die Tweets eines Nutzers abgefragt werden. Diese können für den root-Nutzer auch bereits angezeigt werden. Für die Darstellung wird das sogennante Force-Directed-Layout genutzt. Tweets, die eine Mention enthalten, werden gesondert dargestellt.

Tag 2:

Unten ist nun ein Textfeld mit einem Start-Knopf, der eine Anfrage startet. Tweets, die Mentions enthalten, sind nun anklickbar und stellen über die Twitter-API die passende Anfrage, damit ein neuer Ast ensteht. Am Ende der Äste wird das Profilbild des Nutzers angezeigt. Wenn dieses angeklickt wird, wird ein neuer Baum mit dem entsprechenden Nutzer als Wurzel erzeugt.

Tag 3:

Die Zertifizierung der .jar-Dateien für Browser wurde (endlich) möglich. Somit lässt sich die Anwendung auch in Webseiten darstellen, obwohl zur Laufzeit Daten von Twitter abgerufen werden.Die Verbindungen zwischen den Knoten sind nun für jeden Strang einzeln eingefärbt. Das jeweilige Profilbild des aktivierten Twitterers wird nun auch unten neben dem Eingabefeld angezeigt, um dem User intiutiv klar zu machen, dass er in Daten von nur einem Twitterer navigiert (und die übrigen Äste relativ zu diesem stehen).
Tweets, welche eine Erwähnung enthalten, sind nun grün gefärbt; wenn sie angeklickt wurden, dunkelgrün. Beim MouseOver über einen Knoten wird jetzt auch der Text des zugehörigen Tweets in ein GLabel geschrieben und neben dem Knoten angezeigt.
Um die Darstellung flüssiger – weil performanter – zu machen, wird nun OpenGL verwendet. Schade nur, dass es die Grafiken unschön verzerrt!

Tag 4:

Es werden nun viele verschiedene HTTP Response-Fehler abgefangen. Dies verhindert Programmabstürze und gibt dem User Rückmeldung bezüglich einer nicht funktionierenden Interaktion seinerseits: In einem GLabel erscheinen kurze Info-Texte, die mit einem Timer langsam ausgeblendet werden. Funktioniert leider (noch) nicht immer.
Profilbilder sind jetzt in der jeweiligen Farbe des zugehörigen Stranges umrandet, um die Übersichtlichkeit zu verbessern.

Endlich ist nun das Problem, dass die Abstände zwischen den Knoten so stark variierten, gelöst! Ursache war eine temporäre Liste der Tweets, die nicht wieder gelöscht wurde… Darum konnten wir OpenGL wieder deaktivieren, welches unsere Grafik zwischenzeitlich negativ beeinflusst hatte.

Die Verbindungslinien der Knoten sind jetzt nicht mehr ganz so zufällig eingefärbt. Für den nächsten Tag ist eine Möglichkeit des Zoomens/Scrollens angedacht, wofür der Silder schon mal vorbereitet ist.

Tag 5:

Die letzten Tage stießen wir beim Testen häufig an die Grenzen der API-Anfragen: Nur 150 Anfragen pro Stunde darf jede IP-Adresse stellen, danach wird man blockiert. Die Ursache für unsere häufigen Blockaden war, dass wir pro nötiger Anfrage jeweils erst eine HTTP-Anfrage und dann eine XML-Anfrage verschickten. Fehler behoben: Jetzt gibt es nur noch eine API-Anfrage pro Klick.

Zoomen/Scrollen/Slider wurden gestrichen, eine einfache Begrenzung der Objekte innerhalb des Fensters genügt nun, da die Abstände zwischen den Knoten im Rahmen bleiben.Letzte Anpassungen am Layoutaufbau sind gemacht und andere kleinere Fehler sind behoben.

Das lästige Zittern, das die Ästhetik von TweeTree stark verschlechterte, sind nun durch einen „coolDown“ verhindert, welcher das automatische Ausrichtung des TweetTrees nach einiger Zeit stoppt. Schließlich erstellten wir noch die Abschluss-Präsentation.

Schlusswort: Ein gelungenes Praktikum! Ein herzliches DANKE an die großartigen Tutoren – es hat Spaß gemacht!

Gruppe 2: HIV-Infektionen

Wir haben im Internet nach einer passenden Statistik gesucht, die sich gut in Processing umsetzten lässt. Kriterien dafür waren unter anderem die örtliche und zeitliche Darstellung, sowie ein allgemein gültiges und interessantes Thema. Deswegen haben wir uns für die Visualisierung der HIV-Infizierten im Länderdurchschnitt entschieden.

Tag 1:

Dazu haben wir uns eine Weltkarte als Vektorgrafik gesucht, bei der wir in der Datentabelle manuell die einzelnen Ländern den Kontinenten zugeordnet haben. Anschließend haben wir die ersten zwei Kontinente in Processing eingebunden und die Farbe verändert. Ebenso wurde als Testausgabe die Werte der jeweiligen Kontinente in der Konsole ausgegeben.

Tag 2:

Am 2. Tag wurde der Rest der Weltkarte eingebunden, sowie die Farbzuweisung anhand des Mappings begonnen. Wir haben erste Knopfvorlagen erstellt, aus denen wir Knöpfe für die Grafik gebaut haben. Außerdem haben wir den Farbraum von RGB zu HSB geändert und mit dem neuen Farbraum experimentiert und wiederum per Mapping angepasst.
Die Knöpfe wurden zu ImageButtons geändert.

Die Ziele die wir uns für den nächsten Tag gesetzt haben waren, die Knöpfe noch zu verbessre oder zu verändern, Übergänge zwischen den einzelnen Frames zu schaffen, eine Timeline zu erstellen sowie zusätzlich ein mouseOver einzubinden.

Tag 3:

Am 3. Tag haben wir es geschafft, eine Scrollbar zu erstellen und einzubinden, die sich mit den einzelnen Jahren und beim betätigen der Buttons mitbewegt. Den Ausgangspunkt der Scrollbar haben wir auf den Anfang setzten können, da er anfangs in der Mitte stand.
Es wurden nochmals die ImageButtons geändert und ein Pauseknopf implementiert. Die Größe und Platzierung der Jahreszahl wurde angepasst.

Wir haben außerdem den Text der auszugebenden Daten gelayoutet (Textfarbe, Schrift mit transparenten Kästen hinterlegt, Koordinaten des Textes ausgemacht) und der Durchnitt der Kontinente pro Jahr wurde im Programm errechnet.

Ziele:
Slider der Scrollbar soll gemappt werden


Tag 4:

Die unterlegten transparenten Zahlenfelder wurden der Zahlenlänge angepasst.
Der durch falsche Werte im Code hervorgerufene Absturz wurde behoben. Die Farbe der Jahreszahl, die sich zeitweise mit den Slider der Scrollbar verändert hat, wurde wiederhergestellt. Anhand der lerpColor()-Funktion haben wir es geschafft, einen Farbübergang von einer Farbe (jetzt: weiß) zu einer anderen Farbe (rot) zu schaffen.
Außerdem haben wir die Größe der Gesamtfläche in Relation gesetzt.
Und anhand eine mouse.Overs zusätzliche Daten zu den einzelnen Kontinenten miteingebenden.

Tag 5:

Präsentation wurde vorbereitet.

Gruppe 3: Holzschlagung in verschiedenen Ländern

Tag 1:

Angefangen haben wir, indem wir erstmal das „Grundgerüst“ gefertigt haben, also die Objekte des Waldes und deren Animation. Da jeder an bestimmten Einzelteilen gearbeitet hat, mussten wir schließlich alles zusammenfügen. Dazu kam dann am rechten Bildrand noch eine Leiste mit der Start- und Endjahreszahl.

Tag 2:

Am 2. Tag haben wir begonnen die Daten aus der Tabelle einzulesen und die entsprechenden Jahreszahlen an die Leiste zu binden. Ausserdem haben wir einen interaktiven Punkt auf der Leiste erstellt, mit welchem man das Jahr auswählen kann. Dazu wurde ein leicht transparentes Rechteck an die Säge gebunden, quasi zur „Ausradierung“ des Waldes, abhängig von der Kubikmeterzahl. Ausserdem haben wir einen Schirftzug angebunden, der Jahr und Kubikmeterdaten anzeigt, z.B. „Im Jahr 2009 wurden in Deutschland 86550 Kubikmeter Holz geschlagen“. Die „Ausradierung“ haben wir danach in mehrere transparente Rechteckte geändert, damit der Übergang flüssiger ist. Auch die Säge sollte flüssiger durchs Bild laufen, was wir mithilfe einer Map-Methode geschafft haben.


Tag 3:

Nun haben wir noch einen Hintergrund eingefügt. Wir haben dafür ein Stock-Foto aus dem Internet genommen und mit Photoshop noch entsprechend bearbeitet. Dazu kommen noch weitere Details, wie z.B. die Bienen die durch den Wald fliegen. Ausserdem haben wir die Animation der Eule und des Bären so geändert, dass diese traurig aussehen, wenn die Kubikmeterzahl des geschlagenen Holzes einen bestimmtem Prozentsatz erreicht.

Tag 4:

Am letzten Arbeitstag haben wir noch weitere Länder eingebunden und deren Flaggen ins Bild eingefügt, so dass man diese durch klicken auswählen kann. Dann haben wir noch den Schriftzug optimal formatiert, die Säge animiert – und fertig 🙂

Gruppe 4:Top Artists der Welt – LastFM

Tag 1:

Am Montag ging es zunächst darum, ein passendes Thema für unsere Visualisierung zu finden. Als wir erfahren haben, dass unter anderem last.fm eine API anbietet und wir uns also von dort Daten holen könnten, waren wir sofort überzeugt. Unsere Idee war dann, für jedes Land die Top Ten-Interpreten abzufragen, auf einer Karte darzustellen und Verbindungen zwischen Ländern mit gleichen Interpreten sichtbar zu machen.
Die ersten Schritte waren anschließend das Auseinandersetzen mit der last.fm-API, Suchen einer passenden Karte und deren Einbindung in unseren Sketch. Wir fanden eine svg-Datei aus den Wikimedia Commons, in der sich die Länder über ID’s gezielt ansprechen ließen und dank Normierung auch für die Anfragen bei last.fm geeignet waren, womit wir also die Verbindung zwischen Ländern und Daten erreichen konnten.


Tag 2:

Am Dienstag fanden wir eine externe Bibliothek (geomerative), die es uns ermöglichte, svg-Pfade zu analysieren, damit zu bestimmen, über welchem Land sich der Cursor gerade befindet und außerdem für die späteren Verbindungen Mittelpunkte der einzelnen Länder zu finden. Hier ergab sich die Schwierigkeit, dass diese Mittelpunkte dann ziemlich falsch lagen, wenn das Land Gebiete auf mehreren Kontinenten besaß oder sich die Form zu sehr von der eines Rechtecks unterschied.
Außerdem haben wir uns eines Darstellungsform für die Top-Interpreten eines Landes überlegt – zunächst wollten wir in jedes Land zehn Punkte setzen, für jeden Interpreten einen. Dies stellte sich aber als viel zu unübersichtlich heraus. Teilweise gelang es uns am Dienstag bereits, die Namen der Länder aus einer externen Datei einzulesen und dann beim Klick auf ein Land die zugehörigen Top-Interpreten anzuzeigen.


Tag 3:

Am Mittwoch erreichten wir dies dann nach Ausbesserung der Länderliste für alle Länder. Bei einem weiteren Klick wurden die Detailinfos auch wieder ausgeblendet.
Zudem begannen wir, an einer Möglichkeit für Zooming und Panning zu arbeiten, wobei sich aber zunächst einige Probleme zeigten, weil nicht alle Elemente mitskaliert wurden und der aktuelle Darstellungszustand teilweise nicht beivehalten wurde.
Schließlich erstellten wir am Mittwoch noch eine Liste, die alle Interpreten enthält und zudem für jeden eine Liste aller Länder, in denen er zu den Top Ten gehört.

Tag 4:

Am Donnerstag haben wir mit Hilfe dieser Liste Verbindungslinien zwischen einem ausgewähltem Land und allen Ländern mit gleichen Top-Interpreten ziehen können, jeweils vom Mittelpunkt des einen zum anderen Land. Außerdem bauten wir in unseren Sketch die Möglichkeit ein, alle diese Linien übereinanderzulegen und so die Weltkarte mit einem Netz aus Linien zu überspannen. Eigentlich hatten wir zu Beginn gedacht, dass die Verbindungen ein aufschlussreicheres Bild liefern würden. Letztendlich stellte sich aber heraus, dass die Top Ten-Interpreten fast überall auf der Welt sehr ähnlich waren und keine nennenswerten Grenzen zwischen (Kultur-)Bereiche sichtbar waren. Entweder hat also der „Durchschnittsmensch“ jeden Landes einen ähnlichen Geschmack oder last.fm schlägt seinen Hörern in jedem Land das Gleiche vor und bietet auch nicht von alle möglichen Interpreten einen Titel an.
Außerdem kam am Donnerstag die Arbeit am Zoom und Panning zu einem guten Ergebnis und wir begannen mit der gestalterischen Ausarbeitung.


Tag 5:

Am Freitag schließlich vereinheitlichten wir unseren Code und beseitigten unnötige Überbleibsel. Als letzten Schritt bauten wir noch die Funktion ein, dass sich aus den Top-Interpreten eines Landes ein einzelner anwählen ließ und dann nur dessen Verbindungslinien gezeigt wurden. Wir mussten also noch einmal die Cursorposition mit dem passenden Namen in Verbindung bringen und die Länge des klickbaren Bereichs zur Laufzeit festlegen, was uns dann im letzten Moment glücklicherweise noch gelang.

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s