Finale Ausarbeitung MB - Lehrgebiet Kooperative Systeme

Finale Ausarbeitung MB - Lehrgebiet Kooperative Systeme

Bachelorarbeit
Geographische Visualisierung von Community-Beiträgen
am Beispiel der Good-Practice Community Patongo
von
Martin Buda
Sonnenstraße 59
97456 Dittelbrunn
Matrikelnummer: 6469981
angefertigt am
Lehrgebiet Kooperative Systeme,
Fakultät Mathematik & Informatik
FernUniversität Hagen
Betreuer:
Dr. Till Schümmer
11.11.2009
1
Zusammenfassung:
Ausgehend von einer konkreten Good-Practice-Community wird in dieser Arbeit
der Wert der Unterstützung von Prozessen der Wissenskommunikation durch
geographische Darstellung von Community-Beiträgen gezeigt. Typische Ziele, wie
z. B. das Auffinden von Verfassern solcher Beiträge in der Nähe, u. a. aufgrund
der schnellen Erfassbarkeit von räumlichen Informationen durch geographische
Visualisierung, intuitiv realisiert werden. Allgemein wird beschrieben, wie
geographische Visualisierung den Umgang mit den Community-Beiträgen und der
Interaktion der Mitglieder unterstützen kann. Als konkretes Beispiel wird dabei
die im Verbundprojekt "Patongo" adressierte Community von haupt- und ehrenamtlichen Mitarbeitern der evangelischen Kirche in Deutschland betrachtet.
Diese Untersuchung bildet die Basis für die Analyse, das Design und die Implementierung einer Anwendung zur Visualisierung von geographisch lokalisierbaren
Beiträgen einer Web-Community. Eine Untersuchung der Funktionalitäten und
Techniken der graphischen Visualisierung in existierenden Web-Anwendungen
zeigt die Möglichkeiten, welche die Community-Mitglieder bei der Exploration
der Beiträge unterstützten. Dabei werden aktuelle Techniken im Rahmen des
Web 2.0 berücksichtigt.
Der Stand der Technik zeigt, dass eine entsprechende Anwendung, die alle Anforderungen der Community berücksichtigt, noch nicht exsistiert. Daher wird in dieser Arbeit eine Anwendung auf der Basis von geographischen Karten entwickelt.
Es werden Userstories entwickelt, welche die Anforderungen der Community-Mitglieder erfüllen. Deren Implementierung erfolgt auf Basis der dafür optimalen
Funktionalitäten.
2
Hiermit versichere ich, dass ich diese Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich
gemacht habe.
_________________________________
Ort, Datum
_______________________________
Unterschrift
3
1.Inhaltsverzeichnis
1.Einführung....................................................................5
1.1 Motivation der Problemstellung...................................................5
1.2 Definition des Problems............................................................7
1.3 Übersicht über die folgenden Kapitel der Arbeit................................8
2.Anforderungsanalyse .......................................................9
2.1 Detaillierte Untersuchung des Problembereichs................................9
2.2 Zusammenfassung der Anforderungen...........................................18
3.Übersicht über den aktuellen Erkenntnisstand........................20
3.1 Communities im Kontext des Begriffs Web 2.0 ................................20
3.2 Geographische Visualisierung von Community-Inhalten: der aktuelle Stand. 24
3.3 Diskussion der Beispiele in Hinblick auf Wiederverwendbarkeit............34
4.Beschreibung der Lösung..................................................35
4.1 Ableitung der Userstories.........................................................35
4.1.1 Herleitung der notwendigen Datenobjekte...............................35
4.1.2 Userstories zur Erfassung der notwendigen Daten.......................35
4.1.3 Userstories zu den Funktionalitäten der Praxis-Karte...................36
4.2 Allgemeine technische Voraussetzungen für die Lösung......................39
4.3 Konzeptioneller Überblick........................................................40
5.Details zur Lösung .........................................................41
5.1 Wichtige technische Details für die Implementierung.......................41
5.2 Beschreibung verwendeter Techniken...........................................47
5.3 Herleitung der erforderlichen Datenbasis......................................49
5.3.1 Das Datenmodell..............................................................50
5.4 Beschreibung des Benutzerinterface-Designs..................................53
5.5 Besondere Implementierungsdetails............................................64
6.Zusammenfassung .........................................................66
6.1 Kurzfassung des Problems und wie es gelöst wurde...........................66
6.2 Offene Fragen für weitere Abschlussarbeiten..................................66
7.Quellenverzeichnisse......................................................67
7.1 Literaturverzeichnis...............................................................67
7.2 Quellen für Design-Elemente und Teile des Quellcodes......................69
7.3 Abbildungsverzeichnis.............................................................70
4
1.
Einführung
1.1 Motivation der Problemstellung
Im Internet werden Community-Websites, die ihren Benutzern anbieten eigenständig Inhalte zu produzieren, mit anderen zu teilen und über diese zu reflektieren, immer populärer. Beispiele hierzu sind u. a. Seiten wie "Wikipedia1", "YouTube2" oder "flickr3". Dafür wurden Online-Community-Systeme entwickelt, die
die Aufgabe haben, die produzierten Inhalte zu verwalten und den Benutzern zur
Verfügung zu stellen.
Diese Arbeit beschäftigt sich mit der Frage, wie ein solches System die Mitglieder
der Community beim Umgang mit diesen Informationen und bei der Interaktion
mit den anderen Mitgliedern unterstützen kann. Dies wird am Beispiel einer konkreten Community, der haupt- und ehrenamtlichen Mitarbeiter der evangelischen
Kirche in Deutschland (EKD), betrachtet. Ziel dieser Community ist der Austausch
von guten Praktiken, um "die Qualität des Handelns in den Gemeinden und
Gliedkirchen4 zu verbessern" 5. Das Online-Community-System, das im Verbundprojekt "Patongo" entwickelt wird, soll die Kommunikation, Koordination und
Kooperation innerhalb dieser Community unterstützen. Die Idee des Verbundprojekts basiert auf der Weitergabe von Handlungswissen mittels "Patterns"
(auch Handlungsmuster) für Aktivitäten innerhalb der NGO, die auf Grund ihres
Abstraktionsgrades ortsunabhängig durchführbar sein sollen. Die unterschiedlichen Erfahrungen mit diesen Aktivitäten sollen dokumentiert werden und in die
stete Verbesserung der Beschreibung der Handlungsmuster einfließen. Ziel des
Verbundprojekts ist, den Nutzen dieser Art des Wissensaustausches allgemein für
NGOs (Nicht-Regierungs-Organisationen) zu untersuchen5.
"Das Forschungsprojekt PATONGO (Patterns and Tools for NGOs) untersucht,
wie Technologien und Partizipationsprozesse des Web 2.0 den Austausch
über gute Praktiken fördern können und so zu einer Weiterentwicklung der
gesamten vernetzen Organisation beitragen können." [Schuem092009]
Betrachtet man die möglichen Szenarien, die bei der Wissenskommunikation auftreten können, so lässt sich daraus ein Konzept für die Art und Weise der Unterstützung entwickeln:
1 http://de.wikipedia.org/wiki/Main_Page
2 http://www.youtube.com
3 http://www.flickr.com
4 der Begriff "Gliedkirche" entspricht dem der "Landeskirche". ( siehe hierzu [EKD062008])
5 siehe [Schuem092009]
5
1. Ein Mitarbeiter einer Gemeinde möchte ein weiteres Mitglied der Community in seiner Nähe als Ansprechpartner finden.
2. Ein Mitarbeiter einer Gemeinde kennt eine Praxis und sucht nach den
Standorten, an denen sie durchgeführt wurde. Er möchte dann für jeden
Standort den dortigen Ansprechpartner finden.
3. Ein Mitarbeiter einer Gemeinde möchte das Gemeindeleben aktiver gestalten, z.B. zu einem bestimmten Thema (bzgl. eines kirchlichen Festes)
oder um Ideen für mögliche Aktivitäten zur Belebung und Förderung der
Glaubensgemeinschaft zu entwickeln. Dazu informiert er sich über alle
existierenden Praktiken, reduziert diese auf die für ihn interessanten
Praktiken und informiert sich über die dazugehörigen Ansprechpartner in
seiner Nähe.
Zunächst bestimmt man die Objekte, die in diesen Szenarien vorkommen. Dies
sind zunächst Personen, die Mitarbeiter einer Gemeinde sind. Sie sind die potentiellen "Benutzer" des Community-Systems. Ein weiteres Objekt ist die Gemeinde.
Die Gemeinde besitzt einen zentralen Ort (Kirche oder Gemeindezentrum – allgemein bezeichnet als "Institution"), an dem sie sich treffen und gemeinsame Aktivitäten durchführen. Die Community-Mitglieder möchten sich über Praktiken austauschen, die sie in ihren jeweiligen Orten anwenden wollen oder angewendet
haben. Institutionen sind also automatisch auch "Praxisstandorte". Die Benutzer
sind sowohl "Praxis-Anwender" als auch "Autoren", die ihr Handlungswissen über
die Anwendung dieser Praktiken als Beiträge schriftlich niederlegen.
Hieraus ergibt sich die Feststellung, dass die Benutzer des Systems sich über
existierende Praktiken informieren und sich mit anderen Benutzern darüber austauschen wollen. Dazu müssen dem Benutzer sowohl die Informationen über die
Praktiken als auch die über die anderen Mitglieder der Community dem Benutzer
angezeigt und zugänglich gemacht werden. Somit stellt sich nun die Frage
welcher Art die Darstellung dieser Informationen sein sollte, damit der Benutzer
die in den Szenarien beschrieben Ziele auf einfache Weise erreichen kann.
Auffallend ist, dass in allen Szenarien räumliche Begriffe wie "Nähe" oder "Ort"
(der Ansprechpartner) verwendet werden. Weiterhin werden die Praktiken stets
an einem bestimmten Ort angewandt und an die dortigen Umstände angepasst.
Offensichtlich ist auch für die Praktiken der Ortsbezug von Bedeutung.
Um Beziehungen zwischen Objekten od er Inhalten darzustellen bietet sich eine
bildliche Darstellung an. Anders als in fortlaufenden Texten, Listen oder verlinkten Hypertextseiten, kann sich beim Betrachten einer räumlichen verteilten
Darstellung von Inhalten viel schneller eine Vorstellung der Zusammenhänge bilden. Sie muss nicht Stück für Stück selbst erarbeitet werden.
6
"Der Betrachter nimmt Bilder immer als Gesamtheit wahr, während er einen
Text Wort für Wort abtastet und erfasst. [...] Diese Eigenschaft von Bildern
qualifiziert sie, um Zusammenhänge darzustellen: Während das Bild simultan eine Situation präsentiert, kann der Text sie nur nach und nach entwickeln." [JanSchar1999]; S. 72
Bei allen in den Szenarien genannten Orten handelt es sich um Adressen im deutschen Raum, die eindeutig geographisch lokalisierbar sind. Prädestiniert für die
bildliche Darstellung räumlicher Bezüge von Objekten mit eindeutigen geographischen Adressen ist die Visualisierung mittels einer geographischen Karte.
Sie ermöglicht, bezogen auf den konkreten Fall, die direkte Lokalisierung von
Institutionen und bildet damit auch direkt die räumliche Verteilung der Standorte der Community-Mitglieder, also aller potentiellen Ansprechpartner, ab. Die
Tatsache, dass geographisches Kartenmaterial an sich noch weitere, wichtige Informationen enthält, die bei rein textbasierter Auflistung von Beiträgen nicht
vorhanden sind, spricht ebenfalls für deren Einsatz. Bei Straßenkarten sind die
Zusatzinformationen klar ersichtlich. Die Frage "Wo finde ich in meiner Nähe
einen Ansprechpartner?" lässt sich direkt ablesen. Vor allem bei kleinen Maßstäben findet der Benutzer, vor allem wenn er sich in seinem Umkreis befindet,
recht schnell ihm bekannte Landmarken, da zumindest die Straßenkartendarstellung der Umgebung des Wohnortes den meisten Benutzern bekannt sein dürfte.
Diese Wiedererkennung bekannter Strukturen der physischen Umgebung erhöht
den Realitätsbezug, erzeugt ein "Sich zu Hause fühlen" und fördert damit die Akzeptanz der Darstellung bzw. Anwendung. Diese informelle Erleichterung fällt vor
allem im Vergleich mit lediglich listenbasierten Darstellungen auf. Aber auch die
topologischen Aspekte von Karten sind z. B. für die Organisation von Außenaktivitäten von Nutzen. Beispiele für die Nützlichkeit dieser implizit vorhandenen Informationen finden sich im Kapitel 3.
Auf der Basis dieser Betrachtung kann nun die konkrete Problemstellung der
Arbeit formuliert werden.
1.2 Definition des Problems
Diese Arbeit fokussiert nun auf die Frage der Art und Weise, wie die Community
-Beiträge dargestellt werden sollen, damit die Mitglieder ihre Ziele im Rahmen
der Wissenskommunikation effizient erreichen können. Dabei soll die Durchführbarkeit der Szenarien gewährleistet sein. Eine vertiefte Analyse des Problembereichs des Konzeptes sollte die Nützlichkeit der geographischen Darstellung
belegen und in der Formulierung von Anforderung an die zu entwickelnde Applikation resultieren.
7
1.3 Übersicht über die folgenden Kapitel der Arbeit
Im nächsten Abschnitt wird der überall verwendete Begriff des Web 2.0 und dessen Bedeutung für diese Arbeit vorab erklärt.
Im folgenden Kapitel 2. werden die Szenarien detaillierter analysiert und notwendige Begrifflichkeiten und Hintergrundinformationen erläutert, die für die
Anforderungsanalyse relevant sind. Ergebnis ist eine Zusammenfassung von
Anforderungen an die Anwendung.
In Kapitel 3. wird der Stand der Technik beschrieben.
Kapitel 4. beschreibt die Lösung der Problemstellung. Dabei werden aus den Anforderungen umsetzbare Userstories abgeleitet.
Kapitel 5. stellt die Details der Implementierung der Userstories vor. Es werden
die notwendigen Techniken beschrieben und deren Einsatz in der Anwendung.
Die Beschreibung der Implementierung teilt sich in die Beschreibung des Datenmodells und der Umsetzung der Benutzeroberfläche.
In Kapitel 6. findet die Zusammenfassung der Ergebnisse sowie die Benennung
von möglichen Themen für anschließende Arbeiten statt.
8
2.
Anforderungsanalyse
2.1 Detaillierte Untersuchung des Problembereichs
Zunächst werden die Szenarien aufgeführt und die während der bereits in Kapitel 1.1 erfolgten grobe Analyse ermittelten Erfordernisse als Anforderungen
formuliert.
1. Ein Mitarbeiter einer Gemeinde möchte ein weiteres Mitglied der Community in seiner Nähe als Ansprechpartner finden.
2. Ein Mitarbeiter einer Gemeinde kennt eine Praxis und sucht nach den
Standorten, an denen sie durchgeführt wurde. Er möchte dann für jeden
Standort den dortigen Ansprechpartner finden.
3. Ein Mitarbeiter einer Gemeinde möchte das Gemeindeleben aktiver gestalten, z. B. zu einem bestimmten Thema (bzgl. eines kirchlichen Festes)
oder um Ideen für mögliche Aktivitäten zur Belebung und Förderung der
Glaubensgemeinschaft zu entwickeln. Dazu informiert er sich über alle
existierenden Praktiken, reduziert diese auf die für ihn interessanten
Praktiken und informiert sich über die dazugehörigen Ansprechpartner in
seiner Nähe.
Anforderung 1:
Aus dem Ziel des Benutzers, Ansprechpartner "in seiner Nähe" zu finden resultiert die Anforderung:
A1. Geographische Bezüge müssen in der Darstellung leicht ersichtlich sein.
Anforderung 2:
Ziel der betrachteten Community ist es die Handlungskompetenz der Mitglieder
zu fördern Daher ist die Community auch eine Lerngemeinschaft, die kooperativ
gemeinsames Wissen erarbeitet und deren Mitglieder sich gegenseitig beim
Lernen unterstützen. Um eine solche soziale Interaktion innerhalb der Community
zu fördern ist die Erzeugung und Verstärkung eines Gruppenbewusstseins erstrebenswert. Die Wahl der geographischen Darstellung unterstützt diesen wichtigen Prozess. Durch hervorgehobenes Markieren des Standortes des Benutzers
erfolgt eine optische Verortung in der Gemeinschaft, die auch eine emotionale
Verortung innerhalb der Community nach sich ziehen kann.
A2. Der Benutzer soll sich optisch innerhalb der Gemeinschaft verorten
können.
9
Anforderung 3:
Für die Mitglieder ist es außerdem von Interesse, wie weit eine Praxis verbreitet
ist, z. B. um abzuleiten wie erfolgreich sich eine Praxis anwenden lässt.
A3. Die Verteilung der Institutionen, an denen eine einzelne Praxis angewendet
wurde, soll erkennbar sein.
Einschub: Wichtige Aspekte von Informationsvisualisierung
Jenseits dieser ortsbezogenen Anforderungen sind ebenso nicht-geographische
Inhaltliche Aspekte der Praktiken zu berücksichtigen. Szenario 3. beschreibt die
Absicht des Benutzers sich über die vorhandenen Praktiken zu informieren. Dabei
sucht er nicht gezielt nach einer Praxis, sondern versucht durch Eingrenzung der
Praktiken, die für ihn relevanten heraus zu filtern. Die hier beschriebene Vorgehensweise des Informations-Selektion wird auch als "Exploration" bezeichnet,
also das Erkunden der vorhandenen Praktiken. Der Begriff "Exploration" lässt sich
am deutlichsten im Unterschied zum Begriff "Suche" erläutern. In [BluPel2009]
werden die unterschiedlichen Ziele von suchenden bzw. explorierenden Benutzern von Anwendungen, zu welchen die im Zitat genannten Autoren und Akteuren
gehören, wie folgt beschrieben:
"Neben der anlassorientierten Suche mittels Google und ähnlicher traditioneller Suchmaschinen entsteht bei Autoren und Akteuren zunehmend das
Bedürfnis, sich ihre Netzwerkumgebung und bestimmte Bereiche aus der Vogelperspektive zu betrachten und systematisch zu erkunden." [BluPel2009];
S. 313
Ziel der Suche ist also das Finden von Informationen, von welcher der Suchende
bereits weiß, dass sie existieren. Die Exploration einer Informationsdomäne soll
dem Akteur jedoch den Aufbau eines mentalen Modells der Domäne ermöglichen.
Diese Vorgehensweise soll die geplante bildliche Darstellung ebenfalls unterstützen. Verallgemeinert betrachtet besteht also das Problem der visuellen Exploration von Inhalten und deren Reduzierung. Dies ist das Thema des Forschungsbereich Informationsvisualisierung. Hier werden Lösungen zur Darstellung von
strukturierten Informationen untersucht, weshalb zunächst eine allgemeine Einführung in diesen Bereich erfolgt.
Es wird zuerst der allgemeinere Fall der Visualisierung von Informationen mittels
nicht-geographischen Karten und Diagramme betrachtet, um die notwendigen
Grundprinzipien zu erläutern.
Die Informationsvisualisierung soll bei der Exploration von unbekannten Begriffsdomänen unterstützen. Dazu muss zunächst eine virtuelle Struktur der Domäne
aufgebaut werden, die u. a. die wichtigsten Schlagwörter und Kategorien ent-
10
hält. Diese wird so dargestellt, dass der Benutzer die für ihn wichtigen Informationen einfach erkennen kann und dass eine einfache Navigation innerhalb der
Darstellung möglich ist:
"The outcome for structural modelling is a virtual structure. It is this virtual structure that information visualisation aims to reveal to users in a
graphical and visually understandable form." [Chen2006]; S. 34
Die Wahl von Graphiken zur Darstellung beliebiger (auch abstrakter) Informationen
begründet sich in der Eigenschaft solcher Darstellungen Strukturen und Zusammenhänge auf einen Blick sichtbar machen zu können. Zur deutlichen Differenzierung grenzt man die dargestellten Elemente und deren Werte voneinander ab.
Z. B. unterscheidet man bei Infographiken laut [JanSchar1999]; S. 72 zwischen
drei grundlegenden Arten: die Prinzipdarstellungen, die geographischen Karten
und die Bildstatistiken. Während erstere abstrakte Strukturen wie z. B. Organigramme darstellen, basieren die Karten konkret auf existierenden topologischen
Formen. Letztere Art veranschaulicht meist relative Wertigkeiten von Elementen, die entweder als Bild, Piktogramm oder nur durch einen Begriff beschrieben
werden.
Ontologien z. B. können so als Struktur direkt abgebildet und erkannt werden.
Dabei sind die darzustellenden Elemente die in der Ontologie enthaltenen Begriffe. Sie haben als Wert die Häufigkeit der Verwendung oder aber die Relevanz
in Bezug auf die Thematik der Ontologie. Wie oben bereits erwähnt, können diese semantische Zusammenhänge am besten durch graphische Darstellungen
räumlich verteilter Objekte erreicht werden. Im Gegensatz zu textbasierten Darstellungen ermöglichen sie dem Betrachter wesentlich direkter das Erstellen einer mentalen Landkarte. Diesen Effekt nutzen auch Mind-Maps, die u. a. in kooperativen Anwendungen in Brainstorming-Sitzungen angewendet werden, um
Ergebnisse zu dokumentieren und zu strukturieren1. Dabei werden die gesammelten Begriffe in Form eines Graphen mit Kanten verbunden, die wiederum mit assoziativen Floskeln beschriebenen sind (Künstler schafft ein> Kunstwerk). Direkt
abzuleitende also semantisch nahe Begriffe liegen somit auf benachbarten Knoten.
Auf gleichem Prinzip basierende Darstellungen nutzen auch die in [Chen2006] beschriebenen Visualisierungsmethoden. Bei einigen Darstellungen entspricht dabei
die räumliche Nähe der semantischen Nähe der zu strukturierenden Begriffe.
Konkreten Einsatz finden solche Visualisierungen u. A. in zunächst als Suchmaschine ausgelegten Anwendungen wie die in [Foen032006] beschriebene
http://www.kartoo.com. Diese Meta-Suchmaschine bietet einen graphischen
Suchmodus an, dessen Funktion schon sehr nahe an eine Oberfläche zur Exploration eines Themenbereichs herankommt (siehe Abb. 2.1.1). Der Ausgangspunkt
ist hier der eingegebene Suchbegriff. Dieser ist die Wurzel des Suchbaums, der
1 siehe auch hierzu: [LukCSCW07] S.31 Kapitel 1.10.1
11
dann graphisch dargestellt wird. Zum Suchbegriff gefundene Unterbegriffe werden in Form einer verteilten Karte dargestellt und können zur Verfeinerung einer
erneuten Suche übernommen werden. Diese Begriffe leiten weiter zu Knoten,
welche die Internetseiten präsentieren, zu denen beim Überstreichen mit der
Maus ein Informations-Fenster (in Form eines Flyouts) kurze Inhaltsangaben angezeigt. Ein Klick auf die Knoten öffnet die Seiten in einem neuen Fenster. Ziel
ist es den Nutzer durch die Gewichtung der Seiten und Angebote für einschränkende Unterbegriffe bei der Optimierung seiner Suchstrategie zu unterstützen.
Abbildung 2.1.1: Ergebnis-Visualisierung bei www.kartoo.com
Neben der räumlichen Verteilung kann auch die Größe der Fläche eines Objektes
zu Visualisierung von ihm immanenten Werten genutzt werden. So z. B. realisiert
in der Darstellung eines Dateisystems mit Hilfe einer TreeMap1. Der Speicherbedarf einer Datei innerhalb eines Ordners wird dabei prozentual zum gesamten
Speicherplatz angezeigt. Der gesamte Speicherplatz entspricht einem Rechteck
maximal möglicher Fläche. Jede Datei ist ein darin enthaltenes weiteres Rechteck, dessen Größe dem prozentualen Anteil am Gesamtspeicherplatz entspricht.
Gleichzeitig wird, wie der Name TreeMap bereits andeutet, eine Hierarchie der
Dateien abgebildet. Anders als bei der Darstellung als bei aufklappbaren, listenähnlichen Darstellungen wie beim Datei-Browser von Microsoft-Windows bedeutet hier das Enthalten-sein einer Fläche B in einer Fläche A die Unterordnung
von B unter die hierarchische Ebene von A.
1 siehe: [Chen2006], S. 92
12
Diese zwei Beispiele zeigen den Weg der Visualisierung. Die wichtigen räumlichen Objektverteilungen oder Objekt-Werte werden durch die direkt wahrnehmbare räumliche Visualisierung dargestellt und durch die Nutzung der räumlichen und graphischen Variablen Größe, Form und Richtung hervorgehoben.
Andere vorhandenen Werte können zunächst nur durch die verbleibenden nichträumlichen graphischen Variablen Muster, Farbe oder Dunkelwert dargestellt
werden. Eine weitere Möglichkeit besteht darin den werttragenden Objekten zusätzliche Piktogramme zuzuordnen1, die dann den entsprechenden Wert in Form
z. B. eines Längenmaßes anzeigen. Dies erhöht die Vergleichbarkeit der Werte
gegenüber einer wertekorrellierten Farbabstufung bzw. Strukturierung oder einer
Darstellung als Zahl, die zunächst mental interpretiert und zueinander ins Verhältnis gesetzt werden müssten.
Die Besonderheiten der geographischen Attribute
Bei der Verwendung von topologischen Karten fallen die räumlichen, graphischen
Variablen als Möglichkeit zur Wertdarstellung weg. Die geographischen Attribute
beinhalten bereits die Werte einer räumlichen Verteilung und/oder einer räumliche Ausdehnung der dargestellten Objekte. Abbildung 2.1.2 zeigt eine Illustration, in der die relative Größe der Kontinente und Länder entsprechend der darzu-
Abbildung 2.1.2: Wertabhängige Verzerrung der Weltkarte bei www.Worldmapper.com
stellenden Werte variiert wird. Dies führt zu einem Aussehen ähnlich einer Karikatur, das nur auf Grund der dem Betrachter bereits bekannten normalen Umrisse der Weltkarte zur Wiedererkennung derselben führt (siehe Abb. 2.1.2)
1 siehe: [Chen2006], S. 186
13
Solche Verformungen sind in normalen geographischen Darstellungen nicht hilfreich. Wie bereits in der Diskussion über die Einsetzbarkeit von graphischen Variablen erwähnt, können damit nur noch zwei Wege zur weiteren Informationsvisualisierung gegangen werden. Sind weitere, räumlich fixe Informationen wie z.
B. Straßenverläufe oder Oberflächenreliefs irrelevant, so können den geographischen Flächen mittels Farbabstufungen Werte zugewiesen werden. In den meisten Fällen jedoch sind bereits weitere, vor allem farblich verschiedene Objekte
auf den Karten vorhanden (Straßenkarten). Daher bleibt nur noch der 2. Weg,
der des Abbildens weiterer Information tragender Objekte.
Problematisch wird die Darstellung bei einer sehr großen Anzahl von Informationen. Daher muss dem Benutzer die Möglichkeit gegeben werden, die Zahl der Informationen zu reduzieren. Dieser Vorgang ist Teil der Exploration. Diese folgt
einem "Mantra", wie es in der viel zitierten Arbeit [Shneid121999] beschrieben
wird und grundlegend für jede Exploration unterstützende Oberfläche ist (im
Weiteren als "Seeking-Mantra" bezeichnet):
"There are many visual design guidelines but the basic principle might be:
summarized as the Visual Information Seeking Mantra:
Overview first, zoom and filter, then details-on-demand" [Shneid121999];
S.2
Resultate aus den Betrachtungen zur Informationsvisualisierung
Ausgehend von diesen Betrachtungen und unter Berücksichtigung des SeekingMantras folgen daraus weitere Anforderungen. Dabei wird die Relevanz der Forderungen aus dem Mantra für die Szenarien geprüft.
Anforderung 4:
Zunächst einmal wird die Darstellung eines Überblicks (Overview) über die vorhandenen Informationen gefordert. Dies entspricht der Ausgangssituation des
Szenarios 3.
A4. Alle Praktiken und Institutionen sollen angezeigt werden können.
Anforderung 5:
Als nächstes soll eine Reduzierung der angezeigten Informationen möglich sein.
Dies gilt sowohl für die geographischen als auch für die nicht-geographischen Informationen, also Informationen, die auf den Inhalten der Praxisbeschreibungen
beruhen. Für den Benutzer bedeutet dies zunächst, wie in Szenario 3, dass er die
Praktiken inhaltlich reduzieren kann.
A5. Die Anzahl der dargestellten Praktiken soll durch inhaltliche Filter
reduziert werden können.
14
Anforderung 6:
Die räumliche Dimension soll ebenfalls filterbar sein. Der Benutzer soll also, wie
in allen drei Szenarien beschrieben, die Ansicht auf die Institutionen und Praktiken in einem geographischen Gebiet reduzieren können. Dieses Gebiet ist zum
einen die Umgebung innerhalb eines Umkreises um seinen Standort:
A6. Die Anzahl der dargestellten Praktiken soll durch entfernungsbezogene
Eingrenzung der Umgebung des Benutzerstandortes reduziert werden
können.
Anforderung 7:
Der zweite geographische Filter basiert auf Regionen. Bei der Informationsvisualisierung werden, wie beim TreeMap1 beschrieben, Werte durch die Größe von
Gebieten dargestellt. Dabei werden zweidimensionale Hierarchien abgebildet.
Einzelne Flächen können somit direkt selektiert werden. Das gleiche Prinzip kann
bei der Darstellung von geographischen Gebieten nutzen. Beispielsweise können
die Gebiete zunächst durch Landesgrenzen dann durch Gemeindegrenzen und
schließlich durch Stadtgrenzen hierarchisch unterteilt werden. Dies bietet eine
weitere Möglichkeit zur Reduzierung der Praktiken an.
A7. Die Anzahl der dargestellten Praktiken soll durch Auswahl einer hierarchisch
geordneten Region reduziert werden können.
Anforderung 8:
Als dritter Schritt des Seeking-Mantras sollen "details-on-demand" visualisiert
werden. Konkret bedeutet dies die Anzeige der zusätzlichen Informationen zu einer Institution, die gleichzeitig ein Praxisstandort ist. Das heißt, es sollen auch
Informationen im Kontext der dort angewandten Praktiken angezeigt werden. Im
Weiteren werden diese Informationen als "sekundäre Informationen" bezeichnet.
A8. Zu den Institutionen können sekundäre Informationen angezeigt werden.
Anforderung 9:
Der letzte Aspekt, der bei der Filterung zu beachten ist, ist die Bedienung der
Filterelemente. Bei Untersuchungen des Bedienverhaltens von Benutzern von Informationsvisualisierungs-Software wurde beobachtet, dass die Benutzer meist
zum Ausgangspunkt der Suche, also der Übersicht, zurückkehren, falls sie durch
zu viele Einschränkungen in einem Zustand angekommen sind, die Ihren Vorstellungen nicht entspricht. Nur selten gehen die Benutzer schrittweise zurück.
1 siehe: [Chen2006], S. 92
15
„Dillon et al. (1990) points out that when users navigate through an abstract structure such as a deep tree, if they select wrong options at a deep
level they tend to return to the top of the tree rather than just take one
step back.“ [Chen2006] S. 22
Daher wird die Möglichkeit des Zurücksetzens aller Filtereinstellungen gefordert.
A9. Es muss die Möglichkeit bestehen wieder zur Übersicht ohne aktive Filter
zurückzukehren.
Betrachtung der sozialen Aspekte der Online-Community
Bisher wurde der Aspekt der Community als Gemeinschaft von Gleichgesinnten
bzw. als Gruppe von Lernenden noch nicht betrachtet. Dies liefert weitere Hinweise auf notwendige Anforderungen.
Als Ausgangspunkt dazu sind die Erkenntnisse der Untersuchungen zur Motivation
eines Benutzers, sich in Online-Gemeinschaften zu engagieren. Dabei berücksichtigt man die Dimension des Benutzers als soziales Wesen.
„Gruppenbildung. Prozeß, während dessen sich aus einer Mehrzahl oder bloßen Ansammlung von Individuen eine Gruppe bildet. Voraussetzung für das
Entstehen von Gruppen sind: 1) Die Motivation der Individuen, sich in einer
Gruppe anzuschließen […]; 2) Kommunikation bzw. Kontkt unter den Individuen (erleichtert durch räumliche Nähe oder allg. geringe soziale Distanz);
3) Eindruck der gegenseitigen Anerkennung der einzelnen Individuen.“[Arnold1988]; S.818
Voraussetzung für die Erstellung von Applikationen für Online-Communities, die
in [PorEng2008] untersucht wird, ist die Erkenntnis, dass Internet-Benutzer versuchen im Netz den selben Bedürfnissen nachzukommen, wie in der realen Welt:
"Menschen setzen Software ein, um genau dieselben Dinge zu tun, die sie
zuvor auch ohne Software getan haben: miteinander reden, Gruppen bilden,
Ansehen gewinnen, ihr Leben gestalten, Spaß haben." [PorEng2008], S. 14
Anforderung 10:
Soziale Bedürfnisse, hier seinen vor allem die Kommunikation und der Gewinn sozialer Anerkennung mit Hilfe der Selbstdarstellung genannt, werden bei solchen
Software-Systemen durch die Möglichkeit der Veröffentlichung der durch den Benutzer generierten Inhalte erfüllt. Dieses "Ansehen" bezieht sich zunächst auf den
Benutzer persönlich. Die individuelle Partizipation am Verfassen einer Praxisbeschreibung oder gar die Initiation einer solchen kommt diesem Bedürfnis entgegen.
Eine Anzeige der Autorenschaft der Beiträge ermöglicht die persönliche Selbstdarstellung. Gleichzeitig ist der Benutzer auch Teil einer realen Gemeinschaft (Gruppe) einer Institution, konkret der dort ansässigen Gemeinde. Durch die zumeist
16
starke, soziale Einbindung in die Gemeinde und Identifikation mit derselben werden deren Erfolge auch als die persönlichen empfunden. Daher bewirkt eine sich
als sehr aktiv darstellende Gemeinde auch als Selbstbestätigung für deren Mitglieder. Die Anzeige aller Praktiken, die bereits an einer Institution umgesetzt wurden,
hilft im Sinne eines Wettbewerbs eine Institution als aktiver erscheinen zu lassen
als andere. Dies alles lässt sich in folgender Anforderung zusammenfassen:
A10. Die Mitglieder, die an einem Ort Praktiken angewendet haben sowie die
Praktiken selbst sollen für jeden Ort sichtbar gemacht werden.
Anforderung 11:
Ebenso ist eine visuelle Präsentation der Institution z. B. in Form eines Bildes der
Kirche bzw. des Ortes für die Community-Mitglieder von Interesse. Sie ermöglicht
und fördert beim Betrachter eine wesentlich konkretere Vorstellung und damit
konkreteren Bezug zum realen Umfeld der Mitglieder der jeweiligen Institution.
Dies fördert den persönlichen Bezug des Betrachters zu den dargestellten Institutionen und deren Mitglieder.
A11. Es sollte die Möglichkeit einer visuellen Präsentation der Institutionen
geben.
Anforderung 12:
Ein weiterer Aspekt des Social Web Designs ist die Benutzerzentiertheit. Es wird
auf hohe Benutzbarkeit (Usability) der Web-Applikationen Wert gelegt.Daher
wird darauf geachtet, dass die Benutzeroberfläche intuitiv zu bedienen also für
den Benutzer erwartungskonform gestaltet ist. Die Nutzung eines bekannten
Kontextes bei der Darstellung der Informationen erweist sich als hilfreich, um
dem Benutzer eine Basis zur Orientierung zu geben und so eine intuitive Erfassung der Funktonalität der Darstellung zu ermöglichen. Wie bereits erwähnt erfüllen Straßenkarten dieses Kriterium ohne weiteren Aufwand, da den meisten
Benutzern die kartographische Umgebung von Deutschland, bzw. - detaillierter die Umgebung seines Standortes, bekannt ist.
A12. Dem Benutzer soll durch Darstellung wiedererkennbarer, bekannter
Strukturen eine Orientierungshilfe angeboten werden.
Anforderung 13:
Auswirkungen der Benutzerorientierung des Web Designs für Communities lassen
sich unter anderem an der Wahl der angewandten Techniken ablesen. Technische
Neuerungen und deren Einsatz sollen nicht mehr an sich das Ziel von Weiterentwicklungen sein (was ist alles möglich?), sondern vielmehr deren Nützlichkeit für
die Verbesserungen in der Benutzbarkeit von Anwendungen (was hat es für einen
Nutzen?). Die Notwendigkeiten, die Mängel in deren Gebrauchstauglichkeit führen zu technischen Neuerungen.
17
"The social perspective pushes Web science researchers toward a deep understanding of the information and services users want. The disruptive shift
involves moving away from studying the technology toward studying what
users can do with the technology." [Shneid052007]; S. 1
Soweit dies in Hinblick auf diese Forderung akzeptabel erscheint, können spielerische Momente in explorativen Benutzeroberflächen die Motivation des Benutzers
zur Interaktion erhöhen.
Von großer Wichtigkeit ist die unbedingte Orientierung an der Frage: Hat die Technik effektive unterstützende Funktion oder ist sie eher eine zu große Behinderung
oder Ablenkung von der eigentlichen Funktionalität?
A13. Eine leichte Erkennbarkeit bzw. Auffindbarkeit der Bedienelemente
und Funktionalitäten soll die Richtlinie für die Benutzeroberfläche sein.
Allerdings soll das spielerische Moment, das zur Exploration motiviert
nicht zu kurz kommen.
2.2 Zusammenfassung der Anforderungen
Folgende Anforderungen werden nun an die Anwendung gestellt:
A1. Geographische Bezüge müssen in der Darstellung leicht ersichtlich sein.
A2. Der Benutzer soll sich optisch innerhalb der Gemeinschaft verorten können.
A3. Die Verteilung der Institutionen, an denen eine einzelne Praxis angewendet
wurde, soll erkennbar sein.
A4. Alle Praktiken und Institutionen sollen angezeigt werden können.
A5. Die Anzahl der dargestellten Praktiken soll durch inhaltliche Filter reduziert
werden können.
A6. Die Anzahl der dargestellten Praktiken soll durch entfernungsbezogene Eingrenzung der Umgebung des Benutzerstandortes reduziert werden können.
A7. Die Anzahl der dargestellten Praktiken soll durch Auswahl einer hierarchisch
geordneten Region reduziert werden können.
A8. Zu den Institutionen können sekundäre Informationen angezeigt werden.
A9. Es muss die Möglichkeit bestehen wieder zur Übersicht ohne aktive Filter zurückzukehren.
A10. Die Mitglieder, die an einem Ort Praktiken angewendet haben sowie die
Praktiken selbst sollen für jeden Ort sichtbar gemacht werden.
A11. Es sollte die Möglichkeit einer visuellen Präsentation der Institutionen geben.
18
A12. Dem Benutzer soll durch Darstellung wiedererkennbarer, bekannter Strukturen eine Orientierungshilfe angeboten werden.
A13. Eine leichte Erkennbarkeit bzw. Auffindbarkeit der Bedienelemente und
Funktionalitäten soll die Richtlinie für die Benutzeroberfläche sein. Allerdings soll das spielerische Moment, das zur Exploration motiviert nicht zu
kurz kommen.
Die wichtigsten Anforderungen werden auf dem Hintergrund der geographischen
Karte betrachtet, und somit wird belegt, dass diese Darstellung den Anforderungen genügt (Abb. 2.2.1).
Abbildung 2.2.1: Erfüllung der Anforderungen durch geographische Karten
19
3.
Übersicht über den aktuellen Erkenntnisstand
Im Folgenden wird zunächst der Begriff Web 2.0 und einige relevante Web 2.0Techniken erläutert und anschließend werden aktuelle Anwendungen aus diesem
Bereich der Webanwendungen, die benutzergenerierte Inhalte geographisch darstellen, vorgestellt.
3.1 Communities im Kontext des Begriffs Web 2.0
Dieser Abschnitt behandelt den Begriff Web 2.0, da er direkten Bezug zum Thema Online-Communities hat. Das Web 2.0 wird u. A. auch als das "Mitmach-Web"
bezeichnet, was die Beteiligung der Web-Benutzer unterstreichen soll. Auch das
Verbundprojekt Patongo reiht sich in die Anwendungen, die sich den Web 2.0-Errungenschaften bedienen, ein. Explizit wird in der Beschreibung des Verbundprojekts auf die Verwendung von Web 2.0 Technologien hingewiesen, die schon für
andere Funktionalitäten im Bereich von Online-Communities zum Einsatz gekommen sind und deren Nutzung einer guten Benutzerfreundlichkeit dienen sollen.
"Web 2.0-Technologien können auf allen drei Ebenen den Prozess unterstützen. Dazu soll ein Online-Community-System entstehen, das Kommunikation, Koordination und Kooperation in der Community unterstützt und an die
Bedürfnisse der Beteiligten angepasst wird. Dadurch soll sichergestellt werden, dass die Nutzung so intuitiv wie möglich gestaltet wird "
[Schuem092009]
Die im Weiteren kompakt vorgestellten Begriffe und Konzepte tauchen verteilt in
der Arbeit immer wieder auf und werden deshalb hier zusammenhängend erklärt.
Die Vielschichtigkeit des Begriffs resultiert aus dessen unscharfer, weil uneinheitlicher Definition.
"Als die Webpioniere Tim O'Reilly und Dale Dougherty im Herbst 2004 den
Begriff Web. 2.0 prägten, [...] ließ sich kein auch nur ansatzweise klares
Gesamtbild [der dadurch beschriebenen Veränderungen] ableiten." [Fried2009]; S. 33
Der Begriff lässt sich nur unter Berücksichtigung des sich um ihn entwickelten
begrifflichen Kontextes erfassen1. Dabei sind vier Begriffskomplexe von besonderem Interesse. Begriffe wie "Participation", "Sozial Software" fokussieren auf die
Bedürfnisse und Motivationen der das Web nutzenden Personen und auf deren Art
und Weise es zu nutzen. Die Benutzer versuchen im Netz den selben Bedürfnissen nachzukommen, wie in der realen Welt:
1 siehe prominenteste Schlagwortsammlung von Markus Angermeier:
http://nerdwideweb.com/web20/index.html#web20en
20
"Menschen setzen Software ein, um genau dieselben Dinge zu tun, die sie
zuvor auch ohne Software getan haben: miteinander reden, Gruppen bilden,
Ansehen gewinnen, ihr Leben gestalten, Spaß haben." [PorEng2008], S. 14
"Blogs", "Wikis" beschreiben z. B. die Funktionalitäten, die zur Erfüllung der Bedürfnisse eingesetzt werden. "Usability" und "OpenAPIs" gehören zum Begriffskomplex der technischen Eigenschaften und deren Einsatz. Schließlich existiert
noch der Bereich der ökonomischen Nutzung des Netzes zu dem u. a. Begriffe
wie "Long Tail" und "Vertrauen" gehören.
Viele Techniken und Konzepte die als ausschlaggebend für den Erfolg des
Web 2.0 genannt wurden waren bereits vorher existent. Einer der elementaren
Grundlagen, damit im Rahmen des Web 2.0 all diese Merkmale umgesetzt werden können, ist die Verbesserung der Infrastruktur, die den Benutzern des
Web 2.0 den Zugang zum Netz ermöglichen. In [Alby2007] wird dargestellt, dass
die Funktionalitäten ohne z. B. die seit 1999 zur Verfügung stehenden BreitbandZugängen (DSL) mit Flatrate-Angeboten nicht effizient hätten umgesetzt und genutzt werden können. Dadurch fehlte der "Benuzter 2.0" der mit Hilfe dieser Techniken die Umsetzung der Web 2.0-Konzepte überhaupt hätte umsetzen können.
"Wenn wir den gegenwärtigen Entwicklungsstand des Web mit der Versionsnummer 2.0 versehen, dann konnte die Version 1.0 nicht fehlerfrei laufen,
[...]. Die Systemanforderungen an das Web 2.0 waren der Benutzer 2.0,
welcher selbst Zugangsgeschwindigkeiten 2.0 und Zugangskosten 2.0 erforderte." [Alby2007]; S. 2
Erst diese Tatsache erlaubt es, die in dieser Arbeit verwendeten Techniken einzusetzen.
1
Die sozialen Elemente und Funktionalitäten des Web 2.0
Bezüglich der sozialen Elemente, die sich für Web 2.0 als charakteristisch herausgebildet haben, sei hier die Betrachtung des Benutzers als soziales Wesen als
Erstes genannt. Standen vor Web 2.0 die Produkte und deren Präsentation im
Vordergrund, so wird im Web 2.0 der Benutzer, dessen soziale Bedürfnisse und
vor allem dessen Meinung immer wichtiger. Soziale Bedürfnisse, hier seinen vor
allem die Kommunikation - das "miteinander Reden", wie oben Zitiert - und der
Gewinn sozialer Anerkennung mit Hilfe der Selbstdarstellung (z. B. Textbeiträge
in Foren oder selbst erstellte Videos) genannt, werden im Internet durch die
Möglichkeit der Veröffentlichung dieser Inhalte erfüllt. Auch die Eigendarstellung
mittels einer eigenen Homepage gehört dazu. Auch kommerzielle Anbietr haben
die Mitteilungsbedürftigkeit ihrer Kunden erkannt und unter dem Label Web 2.0
darauf reagiert. Daher haben sich Funktionalitäten wie z. B. Ratings und die
Möglichkeit zur Rezension von Produkten1 herausgebildet, sowie die Funktionalität
1 siehe z. B. http://www.amazon.com/
21
Hinweise über interessante Produkte Freunden direkt mitzuteilen. Diese Funktionalitäten fördern außerdem die soziale Vernetzung der Benutzer sowie das Gefühl des sozialen Eingebundenseins. Aus kommerzieller Sicht soll dies dem Ziel
einer stärkeren Kundenbindung dienen.
"Ging es vor wenigen Jahren überwiegend um die präsentierten Inhalte, so
geht es heute ebenso darum, die Informationen attraktiv zu gestalten und
die Webbesucher durch interaktive Online-Plattformen und Dienste zum Informationsaustausch und zur Mitgestaltung zu animieren." [Fried2009]; S.
28
Das gesamte Web als solches ist also ein Gemeinschaftswerk der Internet-Community. In Grundzügen war dies auch die ursprüngliche Aufgabe des Internets in
seinen Anfängen als ARPANET, zumindest was die Kommunikation angeht. Diese
im Laufe der Zeit unübersichtlich gewordene Menge an gemeinsam geschaffenen
Inhalten werden durch Funktionalitäten wie das "Tagging", also das Verschlagworten der Inhalte, gemeinschaftlich strukturiert. Ihr Hauptmerkmal ist die Tatsache, dass sie nicht analytisch-wissenschaftlich erstellt werden. Das Tagging
wird von allen Community-Anwendungen angeboten, die eine große Menge von
Community-generierten Daten verwalten. Als Beispiele seien hier http://www.youtube.com oder auch http://www.flickr.com genannt. Eine weitere Art der gemeinschaftlichen Strukturierung ist das Anlegen von Themen bezogenen Sammlung von Links (z. B. http://www.mister-wong.de , http://www.delicious.com).
Auch hier werden die Themen verschlagwortet. Bei "mister-wong" werden diese
als "Tag-Clouds" dargestellt, bei denen besonders häufig auftretende oder als besonders relevant eingestufte Begriffe durch geänderte graphische Variablen1 wie
Farbe und Größe aus der Menge der weniger gewichtigen Begriffe hervorgehoben
werden.
Im Laufe der Entwicklung des Internets seit 2000 entstanden aus diesen Erkenntnissen heraus mehr und mehr Seiten, deren primäre Inhalte sich direkt an die
Bedürfnissen der das Internet nutzenden Menschen richten und nur sekundär
kommerzielle Inhalte z. B. in Form von Werbebanner präsentieren. Beispiele
hierfür sind die Social Community Websites wie Wer-Kennt-Wen.de, Twitter.com,
StudiVZ.de etc., die den Wunsch nach Zugehörigkeit und Kommunikation innerhalb von Gemeinschaften gleichgesinnter unterstützen.
2
Relevante Web 2.0-Techniken
Im Laufe der Entwicklung des Internets seit 2000 entstanden mehr und mehr Seiten, deren primäre Inhalte sich direkt an die Bedürfnissen der das Internet nutzenden Menschen richten und sekundäre kommerzielle Inhalte z. B. in Form von
1 siehe [JanSchar1999], S. 152
22
Werbebanner präsentieren. Beispiele hierfür sind die Social Community Websites
wie WKW, Twitter, StudiVZ etc., die den Wunsch nach Zugehörigkeit und Kommunikation innerhalb von Gemeinschaften gleichgesinnter unterstützen.
Es zeigt sich hierin die zentrale Wichtigkeit der Berücksichtigung sozialer Interaktion für den Entwurf von Web-Anwendungen, die, wie in [PorEng2008] weiter
ausgeführt wird, auf "sozialen Objekte" fokussieren, "[...] die soziale Aktivitäten
auslösen" [PorEng2008]; S. 52. Haupteigenschaft dieser Objekte sollte sein, dass
ein direkter Zugriff darauf möglich ist und somit Verweise darauf innerhalb einer
sozialen Gemeinschaft verteilt werden können. Dies hat direkten Einfluss auf die
Datenverwaltung der Applikation (s. u.). Es könnte in Folge dessen auch an eine
mögliche Einbindung einer bereits genannten "Sharing"-Funktionalität (im Sinne
von "mit-teilen") gedacht werden. Sie ist mittlerweile Standard auf allen erfolgreichen Seiten1
Die "Mash-Up"-Technologie nutzt diese Möglichkeit des direkten Zugriffs auf Daten. Mash-Ups sind eine der wichtigsten Funktionalitäten im Web 2.0. Basis der
Technologie sind Web-Services mit einer öffentlich zugänglichen Schnittstelle.
Viele Web-Plattformen bieten mittlerweile solche Services an und veröffentlichen APIs, die die angebotenen Daten spezifizieren und die Anfrage-Parameter
definieren, mit denen man auf die zur Verfügung gestellten Daten zugreifen
kann. Zur Parameterübertragung werden Standard-Übertragungsprotokolle wie
z.B. SOAP2 genutzt, das jedoch wg. seiner Komplexität mehr und mehr in den
Hintergrund tritt. Mittlerweile gibt es vermehrt Services, die auf der REST-Architektur3 (Representational State Transfer) aufbauen4. Solche Services werden auch
als "RESTfull Services" bezeichnet. Setzt man diese Architektur im Rahmen des
HTTP-Protokolls ein nutzt man vollständig die Verben des HTTP-Protokolls. Das
Standardverb GET, das standardmäßig von einem Client zum Abrufen einer Seite
an den Server gesendet wird, bietet die Möglichkeit des direkten Zugriffs auf
eine Ressource. D. h. die Anfrage nach einer Ressource ist eine einfache URL mit
angehängten Parametern, was die Programmierung enorm erleichtert. Die Parameter entsprechen dabei dem Standard für diese Schnittstelle.
1 vergl. auch Produkt-Detailbeschreibungen auf den Seiten http://www.amazon.com/ ,
http://www.ebay.com/ oder http://www.YouTube.com/
2 Standard: http://www.w3.org/tr/soap
3 Eingeführt durch Roy Fielding:
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
4 Vergleiche: http://www.programmableweb.com/apis/directory/ (1044 APIs mit REST basierenden Services und nur 308 Services mit SOAP)
23
3.2 Geographische Visualisierung von Community-Inhalten: der
aktuelle Stand
Ausgehend von dem Grund des Entstehens einer Community sind die Themen der
Commuinities und damit die Inhalte, die die Mitglieder zum gemeinschaftlichen
Datenpool beitragen extrem unterschiedlich. Die Inhalte reichen von alltäglichen
Beiträgen zu aktuellen Themen bis zu sozial hoch relevanten Sammlungen von
Informationen die teilweise die Basis von kommunalen bis hin zu politischen Entscheidungen bilden. Dabei sind die Formate der Beiträge größtenteils identisch.
Es sind Textbeiträge in Wikis oder Blogs, Bilder und andere multimediale Formate.
Im Vergleich zu der in dieser Arbeit betrachteten Community sind vom Inhalt her
die Wikipedia-Beiträge wohl am ähnlichsten. Diese haben aber von Hause aus
keinen Ortsbezug. Je bedeutungsvoller die Inhalte sind desto mehr fällt der Wert
des gemeinschaftlichen Zusammentragens von Wissen und Information auf und
wird durch die Möglichkeit des dezentralen Zugriffs auf die gemeinsame Ressource gefördert. Vor allem bei der kollaborativen Bearbeitung von Karten, die früher nur physikalisch an einem Ort erfolgen konnte, bringt der webbasierte Ansatz einen enormen Nutzen mit sich:
"Perhaps the most obvious aspect of PGIS1 that is coming to fruition via the
Geospacial Web is that of community empowerment through collaborative
mapping. [...] users are able to create and collate far more data than an
single individual or group could generate." [SchaTosWuJai2007]; S. 156
Als Beispiel führt der Autor das Projekt http://www.OpenStreetMap.com an, bei
dem Straßenkarten durch normale Benutzer, also keine Geographie-Experten, erstellt werden. Ziel ist das Zusammenstellen von kostenlosem Kartenmaterial
ohne kommerzielle Copyright Beschränkungen. Hierbei sind die geographischen
Daten an sich die Beiträge der Mitglieder.
Jenseits dieser eher seltenen kooperativen Bearbeitung von kartographischen,
topologischen Daten gibt es eine Vielzahl von nicht-geographischen Daten, die
erst durch Geotagging2 auf Karten darstellbar gemacht werden können. Aufgrund
der mittlerweile meist automatischen Generierung genäherter Standortdaten
durch Geokodier-Services3, ist das Assoziieren von Community-generierten Inhalten bereits recht transparent geworden. Diese Services bieten über eine API die
Möglichkeit für Adressen geographische Koordinaten zu liefern. Dazu besitzen sie
eine Datenbank als Backend, in der diese Informationen gespeichert sein müssen.
1 Participatory GIS: Beschreibt das kollaborative Bearbeiten von Kartenmaterial durch Mitglieder einer Intiernet-Community. Näheres siehe Abschnitt: "Einschub: Begriffe im Rahmen von
Anwendungen zur Manipulation
webbasierter Karten"
2 Zuweisen von Koordinaten zu nicht geographischen Informationen
3 Siehe auch Kapitel Fehler: Referenz nicht gefunden Abschnitt: "Lokalisierung von nicht-geographischen Daten"
24
Auf den Seiten der Community-Plattformen wie http://www.wer-kennt-wen.de
ist das Community-Mitglied an sich das soziale Objekt dessen Profil als individueller Beitrag dargestellt und dessen Standort mittels der angegebenen Adresse
ermittelt wird.. Die kartographische Darstellung erfolgt auf einer kleinen Landkarte (siehe Abb. 3.2.1), auf der das Mitglied und die ihm bekannten Mitglieder
dargestellt sind. Auf den Effekt der optischen Vermittlung von Gruppenbewusstsein wurde bereits hingewiesen1. Bei "wer-kennt-wen" können Diskussionsgruppen
beliebiger Themen begründet werden. Dort ist auch der Ort an dem weitere als
"Bekannte" definierte Mitglieder akquiriert werden. Nicht selten füllt sich dadurch der gesamtdeutsche Raum mit Bekannten aus. So einfach diese Graphik
auch ist, so erzeugt sie doch bereits auf den ersten Blick ein Gefühl einer "allumfassenden" Bekanntheit. Nur durch textliches Auflisten der Orte der bekannten
Mitglieder ist dies kaum zu erreichen. Da diese Karten auch von Nicht-Bekannten
eingesehen werden können, kann bei neuen Mitgliedern die Motivation erzeugt
werden, die eigene Karte entsprechend aufzufüllen.
Abbildung 3.2.1: Verteilung von
Bekannten in Deutschland
1 siehe Kapitel 2; Begründung zur Anforderung A2.
25
Die beschriebene, automatische Lokalisierungsmethode wird auch bei Beiträgen
in Blogs oder Foren genutzt. Hierbei wird der Standort des Autors dem Beitrag
desselben zugeordnet. Ein recht anschauliches und interessanteste Beispiel für
Abbildung 3.2.2: Zeitnahe Darstellung von Beiträgen in twittermap.de
geographische Darstellungen von Beiträgen der Nutzer der Community-Plattform
"twitter.de" findet man auf der Seite http://www.twittermap.de (Abb. 3.2.2).
Dies ist ein Mash-Up, das die Personen die aktuellen Beiträge bei twitter generieren, quasi live (mit gewisser Verzögerung) beschränkt auf Deutschland darstellt.
Weiterhin werden auch die Relationen zwischen zusammengehörenden Beiträgen
26
angezeigt. Durch die Darstellung des Zeitverlaufs als dritte Informationsdimension schafft dies eine recht lebendige Atmosphäre der Twitter-Szene. Dies kann
aber nur mit einer großen Zahl an Mitgliedern funktionieren, um jederzeit ausreichend Aktivitäten anzeigen zu können. Ein ähnliches, weniger zeitnahes Visualisierungsprinzip existiert bei dem Mash-Up: http://www.flickrvision.com. Es
zeigt die neuesten Bildersammlungen auf der gesamten Welt dar.
Bei den bisherigen Beispielen waren die Geo-Daten von eher sekundärem Interesse. Die nicht-geographischen Inhalte sind das eigentliche Ziel der Kollaboration
der Mitglieder. Anders sieht es bei den folgenden Beispielen aus. Dort ist vor allem
der Ort an sich von Interesse, weniger die ihn beschreibenden Informationen. Es
gibt viele Seiten, auf denen die Community-Mitglieder Informationen über ihre
direkte Umgebung veröffentlichen können. So entstehen Sammlungen von Ortsbeschreibung in vielfältiger, medialer Form. Das Prinzip ist dabei immer das Selbe.
Als Beispiel sei hier http://www.Tagzania.com (Abb. 3.2.3) genannt, auf der die
Benuzter individuell Karten ihrer Umgebung und ihre speziellen POIs eintragen
können. Diese Beiträge werden dann nach Kategorien sortiert angeboten. Die Kategorie "Nearest" bietet hierbei die Anzeige kommentierter POIs an und eine Galerie von Bildern, die innerhalb dieses geographischen Gebiets lokalisiert sind. An
dem weißen Bild mit dem Markenzeichen "flickr" lässt sich erkennen, dass auch
hier stark von der Mash-Up-Technologie Gebrauch gemacht wird. Wie bei vielen
anderen Seiten auch sind natürlich kommerzielle Komponenten mit enthalten.
Dies ist für die Finanzierung dieser Seiten grundlegend, und das eigentliche Geschäftsmodell. In diesem Falle wird die Suche nach Hotels unterstützt (siehe rote
Label rechts unten).
Abbildung 3.2.3: Benutzer-generierte Karte bei www.Tagzania.com
27
Zusätzlich zu den von den Benutzern generierten Inhalten können bei Verwendung von GoogleMaps noch weitere Layer hinzugefügt werden z. B. Bilder aus
der Foto-Community-Site "Panoramio" oder Videos aus YouTube, die dort geolokalisiert wurden.Es gibt viele Beispiele von Seiten, die ihren Mitgliedern die
Möglichkeit anbieten ihre Reiseberichte und Erfahrungen auch kartographisch
zu erfassen.
Bei http://www.TravBuddy.com z. B. können Text-Blogs mit integrierten Bildern zu
bestimmten Reisezielen eingestellt werden. Dazu gehört eine (recht kleine) WebMap (siehe Abb. 3.2.4), auf der die Reiseroute mittels eines Linienzuges gekennzeichnet ist. Wichtige Reiseziele können angeklickt werden und führen daraufhin zum erneuten Laden der Seite, da sich
dann der Inhalt des Blogs ausschließlich Abbildung 3.2.4: Reiseroute bei
auf den Zielort bezieht.
TravBuddy
Abbildung 3.2.5: Kategorisierte POIs mit Info-Windows bei SlowTravel
28
Auf der Seite http://www.Slowtrav.com (siehe Abb. 3.2.5) sind nur in Ausnahmefällen Routen zu finden, jedoch sind die Informationen zu einem POI direkt in
einem Informationsfenster ersichtlich. Weiterhin können die POIs umfangreich
kategorisiert und gefiltert werden. Dies erleichtert die Exploration der einzelnen
Beiträge innerhalb eines Reiseberichts. Direkte kommerzielle Hinweise, außer im
globalen Navigationsmenü, sind auf der Seite des Reiseberichts nicht zu finden.
Neben weltweiten Reiseberichten können auch lokal begrenzte Routeninformationen von Interesse sein. Im Ergebnis recht aufwändige Beiträge können bei
http://www.jogmap.de (Abb. 3.2.6) recht einfach mit Hilfe einer speziellen Jogging-Uhr erstellt werden. Diese Uhren sind eine Kombination aus Puls-, Zeit- und
Höhenmesser und besitzen zusätzlich noch die Funktion einers GeoLoggers. Die
während einer Strecke gesammelten Daten können über USB direkt auf den Server
geladen und dargestellt werden (wobei die biometrischen Daten ausgespart werden). Die daraufhin dargestellte Laufstrecke bietet eine Animationsfunktionalität,
bei der der Marker die Strecke "abläuft" und parallel dazu im unteren Balkendiagramm das Höhenrelief markiert wird. Bei Wahl der Terrain- oder Satelliten-
Abbildung 3.2.6: Topographische Karte mit Joggingroute bei jogmap.de
29
Ansicht kann sich der Betrachter sehr genau vorstellen, wie der Kontext der
Laufstrecke tatsächlich ist. Hier machen sich die implizit in den Karten enthaltenen geographischen und topologischen Informationen als sehr hilfreich bemerkbar.
Die Darstellung der Menge an nicht-geographischen Informationen für eine weitere "Sportart", das "Geocaching"1 ist im Vergleich dazu umfangreicher. Ein "Cache"
ist dabei Behälter mit Tauschgegenständen, der auf der Website mit seinen Koordinaten eingetragen wird. Ziel ist es für andere Geocacher den versteckten Behälter zu finden und den Fund zu dokumentieren sowie evtl. die enthaltenen
Gegenstände auszutauschen. Zwar sind keine Routeninformationen von Nöten,
aber die Menge an verschiedenen aber begrenzten "Cachearten" muss unterscheidbar visualisiert und filterbar sein. Da textbasierte Kategorisierung unnötig
viel Platz in Anspruch nehmen würde, wird die Unterscheidung durch Symbolbilder für die auf der Karte dargestellten Marker erreicht. Weiterhin muss auf
der gleichen Seite auch Beschreibungen zu den einzelnen Behältern angezeigt
werden. Um diese Informationen gleichzeitig darstellen zu können, wird eine Liste
innerhalb einer Fläche fixer Größe mit (hier grünem) Rollbalken genutzt (Liste
rechts unten). Die Zugehörigkeit zwischen einer Beschreibung und des dazugehörigen "Caches" wird durch wechselnde, farbliche Umrandung des Cache-Symbols
erreicht (Fragezeichen rechts unten und farblich markierte Zeile mit Tooltip).
Abbildung 3.2.7: Umfangreiche Informationsdarstellung bei GeoChaching
1 Webgestützte "Schatzsuche", siehe dazu http://de.wikipedia.org/wiki/Geocaching und die
Hauptseite http://www.geocaching.com/
30
Im Gegensatz zu diesen freizeitrelevanten Inhalten gibt es Communities, für die
das gemeinsame Zusammenstellen von lokalen, geographischen Daten von elementarer Bedeutung sind. Dazu sind zunächst einige Begriffe zu klären.
Einschub: Begriffe im Rahmen von Anwendungen zur Manipulation
webbasierter Karten
Im Themenbereich von Anwendungen und Services, die webbasierte geographische Karten nutzen oder zur Verfügung stellen ist im Laufe der Zeit eine Vielzahl
von Begriffen entstanden, die sich zum einen auf die Infrastruktur zum anderen
auf die Nutzung von geographischen Daten bezieht.
Der Begriff "Web-Mapping" und der damit in Verbindung stehende Begriff "WebGIS" beziehen sich auf die Infrastruktur geographischer Datensysteme. GIS steht
für "Geographic Information System" und bezeichnet in Anlehnung an die Definition von [Dickmann2001] Daten-Services, die eine Schnittstelle für eine vertiefte
Untersuchung von geographischen Daten erlaubt, wie Flächen- und Streckenbezogene Suchanfragen, Enthaltenseins-Anfragen oder statistische Anfragen geokodierter Informationen. Diese Operationen bezeichnet er als GIS-Operationen.
Die Trennung der beiden Begriffe kann wie folgt beschrieben werden:
"Im Folgenden soll von Web-GIS in Abgrenzung zu Web-Mapping und kartographischen Informationssystemen gesprochen werden, wenn ein Nutzer
nicht nur kartographische Darstellungen visualisieren und einfache AnsichtsManipulationen [...] sondern darüber hinaus [...] GIS-Operationen selbständig durchführen kann." [Dickmann2001]; S. 18–19
Diese vertiefte Analyse durch GIS-Operationen wird für Nutzer notwendig, z. B.
für Mitarbeiter von Regierungsorganisationen, um bessere Entscheidungen im
Bereich regionaler Entwicklungsvorhaben treffen zu können. In diesem offiziellen,
staatlich geförderten Rahmen haben sich auch die ersten GIS-Infrastrukturen zusammen mit Universitäten gebildet und dann mehr und mehr in den Bereich der
Internetanwendungen ausgebreitet.
Mit der zunehmenden Veröffentlichung der Daten und der aufgrund der Möglichkeit des dezentralen Zugriffs auf Web-Mapping- und Web-GIS-Anwendungen im
Internet haben sich Web-PGIS-Projekte entwickelt. PGIS (Participatory GIS) bezeichnet das kollaborative Zusammentragen von geographisch lokalisierbaren
Fakten im konkreten räumlichen Umfeld realer Sozialgemeinschaften (social
Communities) bzw. NGOs. Die so (von Laien) ermittelten Fakten werden dann auf
Landkarten übertragen, um existierende Probleme zu visualisieren und auf dieser
Basis Entscheidungen über das weitere Vorgehen treffen zu können. In vielen
Projekten hat sich gezeigt, das dieses optische Lokalisieren und damit das Bewusst werden von Problemen bei den Betroffenheit bzgl. dieser Probleme enorm
gefördert hat. PGIS ist dabei zunächst nicht gebunden an webbasierte Anwen-
31
dungen und wurde zumeist mit physikalischen Karten durchgeführt. Die webbasierte Variante hat jedoch zu einer wesentlichen Vergrößerung der Zahl der
Beteiligten geführt.
In [Gunt062005] beschreibt die Gründerin des "Green Map Systems"1 die Wirkung
der kartographischen Visualisierung auf das Umweltbewusstsein, also das bewusste
Wahrnehmen der direkten Umgebung und der dortigen Probleme wie folgt:
"According to Brawer, the funcion of a Green Map is simple: "it gives you a
fresh perspective on where you live; you see it from a totally new vantage
point." "On a Green Map", she explanins, "the environment is not the background, but the foreground" [Gunt062005]; S. 2
"Green Maps" sind das Ergebnis eben dieser kollaborativen Kartenerstellung mit
dem primären Ziel, Umweltprobleme wie Eingriffe in schützenswerte Biosphären
oder Fälle von Umweltverschmutzung zu belegen und zu veröffentlichen.
Solche Projekte haben sich auch im Bereich der Sozialarbeit in Entwicklungsländern als hoch effizient erwiesen. Dort wird zusammen mit den Bewohnern der
Gebiete, meist im Rahmen von NGOs, eine Zustandskarte der sozialökonomischen Verhältnisse erstellt. Das Zusammentragen des gemeinsamen und unterschiedlichen lokalen Wissens um die Beschaffenheit des umgebenden Landes mit
allen seinen Ressourcen und Besitzverhältnissen zu illustrieren führt dazu, dass
lokales Wissen einzelner anschaulich und so für die Communitiy als ganzes nutzbar wird.
Zunächst in den Ländern, in denen der Zugriff auf das Internet recht früh möglich war, bildeten sich lokale Gemeinschaften die die zunächst nicht digitale
Technik des gemeinsamen Erstellens von lokalen Landkarten auf Web-Maps übertrugen. Basis dieser Idee ist das bereits erwähnte Web-PGIS. Als Beispiel wird
eine frei zugängliche "Green Map" dargestellt. Die dort verwendeten Symbole
sind mittlerweile standardisiert. Es finden sich alle bisherigen Funktionalitäten
wieder. Zusätzlich wird auf einem der Reiter eine Suchfunktion angeboten (siehe
Abb. 3.2.9). Sie bezieht sich auf das dargestellte Gebiet und leitet bei Eingabe
eines Begriffes von der Kartendarstellung zu einer Liste von Standorten weiter.
Bei der Rückkehr zur Kartendarstellung muss diese neu aufgebaut werden. Evtl.
wäre hier eine Liste wie beim Geocaching ebenfalls angezeigt.
1 siehe Homepage: http://www.opengreenmap.org
32
Abbildung 3.2.8: Kollaborative Karte zur OpenGreenMap
Abbildung 3.2.9: Suchfunktion
33
3.3 Diskussion der Beispiele in Hinblick auf Wiederverwendbarkeit
Einige der Techniken und Designelemente der beschriebenen Anwendungen
können wiederverwendet werden. Obwohl "geocaching" am ehesten den Anforderungen entspricht, erfüllt es nicht die vollständigen Anforderungen bzgl. der
Objekte „Benutzer“ und der „Institution“.
Allgemein lässt sich feststellen, das sich das Einbinden von applikations-externen
Daten durch die Verwendung von Mash-Ups als Standard herausgebildet hat. Handelt es sich dabei nicht um essentielle Daten, die von den Benutzern eingegeben
wurden (z. B. die Bilder im Fall des Beispiels von "Tagzania"), so bedarf es keinerlei Überprüfung auf deren Existenz, was bei "flickr" auch erschwert wird, da
auf jeden Fall eine Antwort (in Form eines Fehlerbildes) erfolgt.
Bei Irrelevanz der Genauigkeit von angefragten geographischen Daten zur Verortung von Beiträgen oder Benutzern, wie z. B. bei der Suche nach dem Benutzerstandort bei "wer-kennt-wen", ist eine Rückversicherung beim Benutzer nicht
notwendig.
Bei großen Mengen von nicht-geographischen Informationen werden zusätzlich
mittels Checkboxen selektierbare Kategorien zur Filterung der angezeigten
Layer-Objekte angeboten. (z. B. "geocaching").
Auf der Seite von http://www.Palatio.com wird nach der dort angebotenen standardsuche "find X near Y" ein automatisches Panning zum Ort Y zusammen mit
einem Zoom auf die detaillierteste Stufe durchgeführt, ungeachtet der Tatsache,
ob sich dort überhaupt Layer- oder auch nur Basis-Karten-Daten befinden. Dies
wird auch durchgeführt wenn als Ort Y z. B. "Afrika" eingegeben wird. Dies führt
häufig zu einer leeren Kartendarstellung. Eine Zoom-Stufe zu wählen, die zumindest ausreichen geographischen Kontext anzeigt, um sich orientieren zu können,
wäre hier angeraten.
Welche der oben beschriebenen vorhanden Techniken und Konzepte in dieser
Arbeit verwendet werden, wird bei der Beschreibung der Lösung sowie bei der
Implementierung in den nächsten zwei Kapiteln erläutert.
34
4.
Beschreibung der Lösung
In diesem Kapitel werden aus den Anforderungen konkrete Userstories formuliert.
Daraufhin werden die allgemeinen, technischen Voraussetzungen genannt.
Das Kapitel schließt mit einem Überblick über das Konzept der Implementierung
unter Berücksichtigung dieser Voraussetzungen ab.
4.1 Ableitung der Userstories
In diesem Kapitel werden die Userstories auf Basis der Anforderungen formuliert.
4.1.1
Herleitung der notwendigen Datenobjekte
In Anforderung A2. und A4. werden zunächst die grundlegenden Objekte der Anwendung genannt. Dies sind:
1. Die Praxis
2. Der Benutzer
3. Die Institution
Die Anforderung nach inhaltlicher Filterung (A5.) erfordert die Festlegung nach
welchen Inhalten der Praktiken gefiltert werden soll. Dafür kann das auf den
Seiten "geocaching" und "slowtravel" verwendete Konzept der Filterung nach
Kategorien genutzt werden. Dies resultiert in der Einführung eines weiteren
Datenobjekts:
4. Die Kategorie
Zur Lokalisierung der Institutionen sowie für die Darstellung der geographischen
Bezüge (Anforderung A1., A3.) wird eine
5. Adresse
benötigt. Auf dieser Basis lässt sich auch der entfernungsbezogene Filter implementieren.
Der Filter für Regionen (Anforderung A7.) benötigt für diese ein zusätzliches
Datenobjekt. In diesem Falle wird als Region der Organisationsbezirk "Landeskirche" verwendet, weshalb sie als
6. Organisationselement
bezeichnet wird.
Das Anlegen dieser Objekte muss durch Userstories abgedeckt werden.
4.1.2
Userstories zur Erfassung der notwendigen Daten
Die geographische Darstellung der Informationen und der Filter-Bedienelemente
werden im Weiteren als "Praxis-Karte" bezeichnet.
35
Zunächst müssen die grundlegenden, darzustellenden Objekte angelegt werden
können. Die entsprechenden Anforderungen sind bei den jeweiligen Objekten
aufgeführt, soweit nicht explizit angegeben.
Zentrales Objekt ist die Praxis.
US1. Der Benutzer gibt den Titel, eine kurze Zusammenfassung und eine
detaillierte Beschreibung der Praxis ein und ordnet sie Kategorien zu.
Besondere Daten in Bezug auf die Institution sind deren geographischer Standort,
sowie die Information über das die Institution darstellende Bild (Anforderung A11.).
US2. Bei der Eingabe der Daten für eine Institution bestimmt der Benutzer
die geographischen Daten der Institution sowie die Zugehörigkeit zur
Organisationshierarchie der EKD.
US3. Bei der Eingabe der Daten für eine Institution kann der Benutzer ein
Bild zur Illustration der Institution festlegen.
Drittes Datenobjekt ist der Benutzer: Durch die Zuordnung zu einer Institution
wird er automatisch verortet (Anforderung A2.)
US4. Der Benutzer legt einen neuen Benutzer an und ordnet diesem eine
Institution zu.
Im Rahmen der Dateneingabe müssen die Attribute der drei Objekte "Benutzer",
"Institution" und "Praxis" änderbar sein. Die Details der Objekte soll auch nur
lesend angezeigt werden.
US5. Der Benutzer ändert oder betrachtet die Daten eines Benutzers, einer Praxis oder einer Institution.
4.1.3
1
Userstories zu den Funktionalitäten der Praxis-Karte
Darstellung
Zentrales Objekt der Exploration sind die Praktiken. Die Personen, die mit diesen
Praktiken vertraut sind, werden als sekundäre Informationen gehandhabt. Die
Praktiken sollen erkennbar auf der Seite gelistet sein und durch Filterung reduziert werden können.(Anforderung A4., A5., A6.)
US6. Der Benutzer sieht auf der Seite der Praxis-Karte eine Tabelle mit
Praktiken, die mit den sichtbaren Institutionsmarkierungen korrespondieren.
36
Die Institutionen sind die primär sichtbaren Objekt auf einer geographischen Karte.
Diese Wahl des Hintergrunds erfüllt die Anforderung A1. und A12., wie in der
Analyse dazu bereits beschrieben. Zu ihnen können sekundäre Informationen angezeigt werden. (Anforderungen A1., A4., A8., A10., A11.)
US7. Der Benutzer sieht eine Kartendarstellung von Deutschland und darauf alle vorhanden Institutionen. Zu den Institutionen kann jeweils zusätzliche Informationen angezeigt werden.
Um sich innerhalb der Institutionen lokalisieren zu können muss der Benutzer
einen eigenen Standort besitzen (Anforderung A2.)
US8. Jeder Benutzers besitzt auf der Praxis-Karte einen besonders gekennzeichneten Standort.
Dieser soll interaktiv geändert werden können, um auch die Region, die durch
die entfernungsbasierte Einschränkung entsteht flexibel verschieben zu können.
(Anforderungen A6.)
US9. Der Standort des Benutzers kann geändert werden. Der Umgebungsfilter wird dabei mit verschoben.
2
Filtermöglichkeiten
Zunächst soll eine elementare Stichwortsuche im Volltext der Praktiken existieren.
Dies entspricht dem zur Verfügung stellen einer zusätzlichen, frei wählbaren Kategorie, die allerdings dominant filtert. (Anforderung A5.)
US10. Der Benutzer kann auf Basis eines Stichwort in den allen zu den
Praktiken eingegebenen Texten die Praktiken filtern.
Weiterführend ist die Einschränkung der Kategorien zu unterstützen. (Anforderung A5.)
US11. Der Benutzer kann durch Einschränkung der Auswahl der Kategorien
die Praktiken filtern.
Neben diesen inhaltlichen Filtern sollte eine Einschränkung des Radius um den
Standort des Benutzers ermöglicht werden. Institutionen außerhalb des Radius
und nur dort erstellte Praktiken sind zu filtern. (Anforderung A6.)
US12. Der Benutzer kann den zu betrachteten Radius um seinen Standort
herum einschränken und so die Anzahl der angezeigten Institutionen
und somit die Anzahl der Praktiken reduzieren bzw. erweitern.
Eine weiter Möglichkeit der geographischen Filterung bieten die Organisationselemente. (Anforderung A7.)
37
US13. Die Institutionen einer Landeskirche und die mit ihnen explizit assoziierten Praktiken können durch (ab)wählen von Landeskirchen aus
einer hierarchischen Liste, in der auch die Namen der Institutionen
aufgeführt sind, ein- und ausgeblendet werden.
Ein zurücksetzen bzw. deaktivieren der Filtermöglichkeiten ermöglicht dem Benutzer die Rückkehr zu einem neutralen Ausgangspunkt bei der Suche. (Anforderung A9.)
US14. Dem Benutzer ist es möglich die Wirkung der gesetzten Filter einzeln oder gleichzeitig zu deaktivieren.
US15. Dem Benutzer ist es möglich alle Filter gemeinsam auf einen Standardwert zurückzusetzen.
Um der Anforderung A3. zu genügen muss die Möglichkeit gegeben sein alle Institutionen außer denen, an der die Praxis angewendet wurde, auszublenden.
US16. Dem Benutzer kann explizit alle Standorte einer Praxis anzeigen.
3
Navigation innerhalb der Domain und Datenverwaltung
Wie bei jeder benutzerorientierten Anwendung ist die Benutzerverwaltung ein
notwendiges Element. Gefordert ist eine leichte Zugänglichkeit der Anwendung.
Da das Hauptziel das Auffinden von Praktiken und den dazugehörigen Informationen (Autoren und Standorte) ist, soll für diese Funktionalitäten ein ungehinderter Zugang ermöglicht werden.
US17. Ein nicht registrierter Benutzer kann direkt von der Startseite aus
zur Übersicht der Praktiken bzw. auf die Seite der Praxis-Karte navigieren und wird dabei automatisch als Gast-Benutzer angemeldet.
Ein registrierter Benutzer kann sämtliche Daten der Anwendung manipulieren.
US18. Ein registrierter Benutzer meldet sich mit Login-Name und Passwort
an und kann sämtliche Daten editieren.
Die Anforderung A13. wird durch Wahl der Designelemente und deren Anordnung
während der Umsetzung der Userstories mit berücksichtigt.
38
4.2 Allgemeine technische Voraussetzungen für die Lösung
Einer der zusätzlichen Aspekte der in dieser Arbeit zu entwickelnden Web-Applikation ist deren potentielle Wiederverwendbarkeit innerhalb des Verbundprojekts. Daher sollten möglichst alle technischen und, soweit sinnvoll, inhaltlichen Anforderungen des Verbundprojekts Berücksichtigung finden.
Technische Voraussetzung ist die Verwendung des Frameworks Ruby-On-Rails1.
Dieses ermöglicht eine schnelle Erstellung von Model-View-Controller-Gerüsten
inkl. Datenanbindung. Verwendung findet hierbei das Datenbanksystem MySQL2.
Der Ausgangspunkt für die Datenbasis dieser Arbeit sind die Inhalte bereits existierender Good-Practice-Anwendungen3. Diese werden im Weiteren als "Testdaten" bezeichnet. Diese werden zum Teil in die Anwendung integriert und evtl.
durch weitere, notwendige Daten erweitert. Folglich stellt sich zunächst die Aufgabe eine entsprechende Datenbasis zu schaffen, auf deren Grundlage dann eine
Darstellung dieser Inhalte erfolgen kann.
Der Hauptteil der Techniken, die in dieser Arbeit verwendet wurde wird durch
das Ruby on Rails Framework (in Folge "RoR" abgekürzt) vorgegeben. Zentraler
Bestandteil bzgl. der Datenverarbeitung ist die Kapselung der Datenbankaktivitäten mittels des in RoR integrierten "ActiveRecord"-Frameworks. Es erzeugt automatisch die notwendigen SQL-Befehle aus Model-Klassen, deren Eigen- und Attributnamen durch Konvention vorgeschrieben und vom Framework so automatisch
verarbeitet werden können.
Das RoR-Framework wurde ab der Version 2.0 einige Funktionalitäten entfernt,
die hier wieder als Plugins eingebunden wurden (siehe Quellenverzeichnisse).
Die Bibliothek "authlogic" zur Verwaltung des Logins und der Usersessions konnte
jedoch nur als direkte Rails-Erweiterung installiert werden.
Eine weitere Vorgabe sind die schon integrierten JavaScript-Bibliotheken "Prototype", die JavaScript um zusätzliche Klassen vor allem im Bereich DOM erweitert, und die Bibliothek "script.aculo.us", die dynamische Effekte und Unterstützung bei Auto-Complete-Problemen und InPlaceEditing bietet.
Einige der Scripten bzw. graphischen Elemente (wie z. B. gif-Bilder für AktivitätsIndikatoren) sind entsprechend dem DRY-Prinzip, frei verfügbarem OpenSourceQuellen entnommen auf die ebenfalls im Anhang verwiesen wird.
1 http://rubyonrails.org/
2 http://www.mysql.com/
3 Eine Sammlung guter Praktiken (verwendet als Testdatenbasis) findet sich unter:
http://www.kirche-im-aufbruch.ekd.de/praxis.html
39
4.3 Konzeptioneller Überblick
Zunächst werden die Techniken und Ressourcen eruiert, die zusätzlich zu den zuvor genannten zur Implementierung benötigt werden.
Die Implementierung der Anwendung erfolgt schließlich in 3 Schritten:
1. Erstellung der Datenbasis und rudimentäre Eingabefunktionalität und Daten-Importroutinen zur Datengenerierung.
2. Implementierung der Praxis-Karten-Funktionalitäten
3. Anpassen der Anzeige- und Eingabefunktionen für die Daten im Web 2.0Stil mit Fokussierung auf die Eingabe von Institutionen.
Um größere Sicherheit vor Nebenwirkungen bei Refaktorisierungen und Datenbankänderungen zu gewährleisten werden sowohl die vom RoR-Framework unterstützten Unit-Test auf Modell-Ebene als auch die funktionalen Tests auf Controller-Ebene genutzt. Diese Framework allein reicht jedoch nicht für die rein
JavaScript-basierende Web-Oberfläche der Anwendung aus. Daher muss zusätzlich noch das Test-Framework "Selenium"1 für Integrationstests eingesetzt werden. Es besteht aus einem Client-Plugin für Ruby und einem Java-basierenden
Proxyserver. Das Framework ist in der Lage unter externer Kontrolle der Standardbrowser Firefox, Microsoft Internet Explorer oder Safari Webseiten-Elemente
wie Buttons, Checkboxen, Links etc. automatisiert zu aktivieren. Weiterhin kann
es über den Proxy-Server als "Man In the Middle" den Ablauf von Ajax-Anfragen an
den Applikations-Server nachverfolgen und darauf reagieren. Dabei werden auch
verschiedene Betriebssysteme unterstützt.
1 Homepage: http://seleniumhq.org/
40
5.
Details zur Lösung
5.1 Wichtige technische Details für die Implementierung
1
Wichtige Formate zum Austausch von geographischen Daten
Bei der Modellierung von geographischen Attribute bzw. Daten gibt es verschiedene Standards, die direkten Einfluss auf die Schnittstellendefinition bei der
Datenübertragung im Internet haben. In [KorZeh2008] werden als maßgebende
Institutionen ISO1 (International Standardisation Organisation), OGC2 (Open
Geospacial Consortium) und OMG3 (Object Management Group) genannt.
OGC hat - mittlerweile in Abstimmung mit ISO - das XML basierte Datenformat
GML (Geography Markup Language) standardisiert. Entsprechend dem zugrunde
liegenden Modell von OGC4 existieren Standards unterschiedlicher Komplexität
und Abstraktionsniveaus. Im einfachsten Fall werden "Simple Feature Types"
spezifiziert, die lediglich Punkte, Linien und Polygone beschreiben, die als "Collections" dann zu unregelmäßigen Poly-Linienzügen bzw. Polygonen werden.
"Im Simple Feature Type werden keine Meta-Informationen mitgeführt und
die Geometrietypen sind beschränkt auf Punkte, Linien und Polygone. [...]
Mehrere Geometrien vom gleichen Typ können zu einer GeometryCollection
zusammengefasst werden." [KorZeh2008]; S. 65
Diese stellen die Basistypen für komplexere Typen von geometrischen, dreidimensionalen Formen dar, die zumeist als Overlay-Objekte auf User generierten
Karten Verwendung finden. Die dritte Dimension ist dabei die Höhe eines Ortes
über dem Meeresspiegel. Angereichert werden diese Objekte durch nicht-geographische Meta-Informationen. Wie diese Meta-Informationen strukturiert sind
wird durch Angabe des entsprechenden XML-Schemas im Kopf des GML-Dokuments definiert.
Ein weitere bekannte Gruppe von geographischen Internetformaten sind die
GeoRSS-Microformats (Geograhically Encoded Objects for RSS), bei denen RSSFeeds verschiedenen Formats durch geolokalisierte Daten erweitert werden. Das
GeoRSS Simple bzw. GeoRSS RDF5 Format ergänzt nur dreidimensionale, punktuelle Angaben während das GeoRSS GML Format auch Formen bis hin zu unregelmäßigen Polygonen beschreiben kann.
1 siehe http://www.iso.org/
2 siehe http://www.opengeospatial.org/
3 siehe http://www.omg.org/
4 siehe [KorZeh2008], S.64
5 W3C Standard für Resource Description Framework: http://www.w3.org/standards/techs/rdf
41
Für diese Arbeit ist das Format KML1 (Keyhole Markup Language) von Interesse,
das die Firma Google von Keyhole Inc. nach dessen Kauf übernommen und das
mittlerweile Teil der Standardisierung der OGC geworden ist.
2
Quellen für geographische Daten im Internet
Die oben genannten Formate sind Antwortformate von Geo-Daten-Server die
Geo-Daten-Services anbieten. Diese Server speichern die Daten meist in speziell
dafür ausgelegten Datenbanksystemen. Die bekanntesten Vertreter der relationalen Datenbanken unterstützen direkt die Verarbeitung von räumlichen Daten.
Für die OpenSource Datenbank PostgreSQL existiert seit 2000 die "PostGis" Erweiterung als direkter Support von GIS Daten 2. In der Release 2004-10-23 der
OpenSource Datenbank MySQL 4.1 wurde eine Unterstützung von ortsreferenzierten Daten (spatial data)3 eingeführt. Von kommerzieller Seite sollte als Vorreiter die Oracle Datenbank erwähnt werden. Seit 1993 ist im Kernel der Oracle 7 Datenbank die "Spatial Data Option" bzw. "SDO" eingebaut worden. Davor gab es
bereits proprietäre Erweiterungen, die einfache ortsabhängige Daten verwalten
konnten. Der "Spatial Data Support" wurde vom Nachzügler Mircrosoft erst für
den MS SQL-Server 20074 geplant und umgesetzt.
Die Services stellen geographische Basisdaten an öffentlichen oder privaten Internet-Schnittstellen zur Verfügung. Für die Parametrisierung der Anfragen an
diese Services gibt es wiederum Standards wie z. B. WMS (Web Map Service),
WFS (Web Feature Service) und den WRS (Web Registry Service). Das Zusammenspiel dieser Services wird z. B. in [SchaTosWuJai2007] beschrieben. [SchaTosWuJai2007] verweist dabei auf die Nähe der Anfrage- und Antwort-Format-Spezifikationen.
"The [Web Feature Service] WFS, like GML, supports requests and transactions that can include both geographic and non-geographic information."
[SchaTosWuJai2007]; S. 19
Im Prinzip werden also von dem WMS-Server dem Client Basis-Kartenmaterial und
von den WFS-Server Objekt und Metadaten zur Verfügung gestellt, passend zu
dem vom Client angefragten geographischen Bereich und den gewünschten geographischen Features. Der Zugriff erfolgt meist über RESTfull Services (s. o.). Die
Services bilden somit einen Teil der Mash-Up Infrastruktur in Form von verteilten
Datenbanken.
1 OGC Standard für KML: http://www.opengeospatial.org/standards/kml/
2 lt. Hersteller: http://www.refractions.net/products/postgis/history/
3 siehe: http://dev.mysql.com/doc/refman/4.1/en/spatial-extensions.html und http://www.mysql.com/about/legal/lifecycle/#calendar
4 vergl. [MSInc122006]
42
Von primärem Interesse für Web-Mapping Anwendungen sind zunächst jedoch die
universelleren "Map-Services", die anders als die oben genannten speziell spezifizierten Services ein "Gesamtpaket" und Informationen liefern. Das Prinzip der
Servicenutzung kann grob wie folgt beschrieben werden. Meist wird von dem so-
Abbildung 5.1.1: Prinzip der Web-Service-Server-Nutzung
genannten "Applikationsserver" lediglich auf den Map-Service-Server zugegriffen.
Der Applikationsserver stellt dann für den Client-Rechner die eigentliche Anwendung zur Verfügung. Vom Map-Service-Server wiederum erfolgt ein Zugriff auf
weitere, speziellere Server (s. o.) auf denen die benötigten einzelnen Informationen gespeichert sind. Dies sind die Ressourcen aus Datenbanken mit dem BasisKartenmaterial, der Geo-Datenbank mit Konvertierungsdaten z. B. von Adressen
zu Koordinaten, einer Datenbank für weitere Bilder (z. B. für Marker) u.s.w.. Der
Map-Service fasst diese Daten zusammen und überträgt sie als ganzes zum Applikationsserver. Zusätzlich zu diesen Daten kann der Applikationsserver noch eigene,
lokal gespeicherte Ressourcen hinzufügen. So können auch dort gespeicherte
Multimediadaten zusätzlich auf der Karte dargestellt werden.
Solche zusätzlichen auf der eigentlichen Basis-Karte dargestellten Objekte können z. B. in Form der bereits erwähnten Overlays eingebunden werden. Diese
sind meist Ausgangspunkt für weitere Interaktionsmöglichkeiten, wie weiterführende Links oder Informationsfenster mit Text oder Multimedia-Inhalten.
Flächendeckende, evtl. transparente Overlays können als Gebietsmarkierung
über die Basiskarte gelegt werden. Dabei kann bei ausreichender Transparenz die
Lesbarkeit der dahinter liegenden Basis-Karte gewährleistet werden. Nicht transparente Overlays bezeichnet man auch als "Abdecklayer" und werden meist zur
Hervorhebung von wichtigen Bereichen eingesetzt.
43
Die bekanntesten öffentlichen Map-Services sind GoogleMaps1, YahooMaps2,
OpenStreetMap3 oder Microsoft Virtual Earth4. Sie stellen nicht nur Basis-Kartenmaterial zur Verfügung, sondern bieten mindestens ein JavaScript-Framework als
API an, das den Einbau der jeweiligen Karte in eine dynamische Webseite sehr
leicht ermöglicht. Einschränkungen bei der Benutzung gibt es z. B. bei GoogleMaps. Es wird gefordert, dass die Seiten, die die GoogleMaps-API einbinden sich
mit ihrer URL registrieren und ohne Log-In direkt aufrufbar sind. Ansonsten fallen
Nutzungsgebühren an. Die Registrierung wird mittels eines Schlüssels, der mit jeder Anfrage mitgesendet wird, überprüft. Eine Ausnahme bildet nur OpenStreetMap, deren Daten OpenSource sind.
Das oben beschriebene Prinzip der Servicenutzung findet sich bei dem hier verwendeten GoogleMaps System wieder, wobei die Client-Server-Kommunikation
vom Applikations- zum Map-Service-Server von der von Google zur Verfügung
gestellten JavaScript-Bibliothek übernommen wird. Das Format KML bildet dabei
das Antwortformat für Anfragen an den mittels JavaScript direkt ansprechbaren
Geokodier-Service von GoogleMaps.
3
Lokalisierung von nicht-geographischen Daten
Um die hier zu betrachtenden Community-Beiträge auf einer Karte lokalisieren
zu können, muss zunächst deren Verbindung zu einem geographischen Ort oder
Areal erfasst und zugeordnet werden. Dieser Vorgang, also das Assoziieren von
Geo-Daten mit den betreffenden Inhalten, wird auch "Geotagging" genannt. Es
gibt dabei verschiedene Verfahren.
Alle Verfahren bedienen sich Services, die dem Benutzer die Suche nach geographisch markierten Daten ermöglichen. Die wohl ungenaueste Methode ist die
Suche nach dem Standort eines Clients anhand seiner IP-Adresse. Diese weist
meist nur auf den Standort des Providers hin.
Eine bessere Möglichkeit, falls die Daten verfügbar sind, bietet die Nutzung eines
Services, der Suchanfragen nach der postalischen Adresse von Clients akzeptieren. Ein Beispielservice ist www.geonames.org5 Dabei hängt die Genauigkeit
sowohl von der Detailliertheit der vorliegenden Daten ab, als auch vom Datenbestand des angefragten Services. Fehlt z. B. der Eintrag einer Postleitzahl in
der Datenbank des Servers und ist dies das einzige Datum, so liefert der Service
den Ort 0.0, 0.0 zurück, der sich im Nordatlantik befindet. Dies muss bei der
Verwendung mit berücksichtigt werden.
1 http://code.google.com/apis/maps/
2 http://developer.yahoo.com/maps/ajax/
3 http://www.openstreetmap.info/examples/webmap.html
4 http://www.microsoft.com/maps/isdk/ajax/-+
5 http://www.geonames.org/export/geonames-search.html
44
Die Automatisierung des Geotaggings wird zusehend ausgefeilter. Zwar müssen
Beiträge in Wikipedia wegen der geforderten Korrektheit der Standortsinformation noch manuell geolokalisiert werden, jedoch sind auch schon Techniken entwickelt worden dies ebenfalls programmatisch durchführen können. Das in [SchaTosWuJai2007] dargestellte Verfahren des "Geo-Parsing" wird von einer speziellen
Suchmaschine genutzt, um bei ortsspezifischen Anfragen durch Benutzer, zu diesem (geographischen) Ort entsprechende Seiten zu finden. Dazu werden Webseiten nach geographisch lokalisierbaren Angaben (z. B. Städtenamen, Sehenswürdigkeiten, natürliche bekannte Landmarken) hin durchsucht. Diese Informationen (evtl. mit Kontext) werden extrahiert und die Geo-Daten mittels Geokodierung auf einer Karte dargestellt. So werden Handlungs- bzw. geschichtliche
Abläufe konkret sichtbar.
4
Interaktionsmöglichkeiten bei Web-Mapping-Anwendungen
Bei der Entwicklung einer explorativen Anwendung steht eine interaktive Benutzeroberfläche im Mittelpunkt. Die Anbieter von Map-Services bieten bereits in ihren APIs zahlreiche Interaktionsmöglichkeiten an. Weiterhin können durch dynamische Webseiten weitere Funktionalitäten hinzugefügt werden.
5
Elemente interaktiver Karten
Diese weitere Schicht von Objekten werden im Kontext Web basierter Karten
"Layer" genannt. Verweisen die Objekte genau auf einen Punkt so spricht man
von "Marker", bei großflächigen Objekten von "Overlay". Illustrationen dieser
Objekte sind auf jeder weiter unten vorgestellten konkreten Anwendungen zu
sehen und werden ebenfalls in dieser Arbeit verwendet.
6
Manipulation der Kartendarstellung
Web-Mapping-Funktionalitäten beziehen sich nach [Dickmann2001] zunächst auf
die Manipulation der Kartendarstellung.
Der dargestellte Kartenbereich lässt sich durch "Zooming" vergrößern und verkleinern. Dies wird entweder durch dafür vorgesehene Kontrollelemente ("Controls" bei GoogleMaps) gesteuert, oder aber über Maus-Ereignisse wie z. B. dem
Drehen des Mittelrades.
Wie erwähnt ist die Nutzung aller möglichen Funktionalitäten einer Karten-API
nicht immer zu empfehlen. So ist vor allem bei Seiten, die höher sind als der
Bildschirm des Betrachters, ein Zoom-Effekt auf Basis des Maus-Mittelrades nicht
zu empfehlen. Denn wenn beim unbewussten Herunterrollen der Seite der Mauszeiger über der Karte schwebt, so ändert sich spontan die Funktion des Mittelrades, aktiviert die Zoom-Funktionalität und initiiert eine Ajax-Anfrage und Neuaufbau der Karte. Da dabei meist der Kartenbereich zunächst verschwindet, sind
die meisten Benutzer im ersten Moment im besten Falle irritiert, wenn nicht ver45
wirrt, benutzen das Mausrad, um aus dem Gebiet wieder herauszurollen und
initiieren einen erneuten Zoom. Allgemein sind Doppelbelegungen wie oben beschrieben zu vermeiden und im Zweifelsfalle die gewohnheitskonforme Funktion
zu wählen.
Weiterhin existieren Kontrollelemente (meist Buttons) zur Änderung der BasisKarten-Darstellung. Hier existieren topologische Karten, Straßen- und SatellitenKarten bzw. Kombinationen aus diesen Typen.
Eine weitere Möglichkeit ist das Einbinden von ortsbezogenen Multimedia-Daten
wie Videos oder Wikipedia-Beiträge, deren Darstellung über Checkboxen aktiviert werden kann.
Durch Halten der linken Maustaste über der Basis-Karten-Darstellung lässt sich
der gesamte sichtbare Kartenbereich in der Ebene verschieben ("Dragging"). Auch
hierfür gibt es Kontrollelemente.
Auch Marker und Overlays lassen sich relativ zu den Basis-Karten durch "DragAndDrop" verschieben. Dabei erfolgt in der Regel ein automatisches Nachführen der
Basis-Karten-Darstellung, falls das Objekt aus dem sichtbaren Kartenbereich hinaus verschoben werden soll. Dieser "Panning" genannte Vorgang kann unter Umständen auch ein Nachladen von Karten-Bildmaterial bewirken.
Meist reagieren die Overlays und Marker auf einen Links-Klick sensibel und es
öffnet sich daraufhin ein (weiteres) Overlay in Form eines schließbaren Fensters
("Info-Window"), in dem direkt weitere Informationen angezeigt werden – bis hin
zu eingebundenen Flash-Videos - oder Links zu detaillierteren Informationen.
Dies ist vor allem dann hilfreich, wenn beim direkten Anzeigen dieser Zusatzinformationen eine Überfüllung der Karte entstehen würde.
Der größte Teil aller bisher genannten Funktionalitäten werden von den Frameworks der jeweiligen Web-Map-Services unterstützt. Sie sind also ohne größeren
Aufwand als Funktionalität einbindbar. Benötigt die Darstellung durch Dragging
der Basis-Karten oder Zooming neue Daten, werden diese über Ajax-Anfragen
vom Map-Server abgerufen. Daher sollten die angebotenen Funktionalitäten mit
Bedacht gewählt werden, um die Antwortzeiten der Anwendung so gering wie
möglich zu halten.
7
Hinzufügen von Daten, erweiterte Filterung und Suchfunktionen
Mehr in den Bereich der GIS-Operationen fallen Funktionalitäten, wie das selektierte Anzeigen vorhandener Objekte aufgrund Inhaltlicher bzw. semantischer
Kriterien oder das Hinzufügen von weiteren Objekten.
Die semantische Filterung von Objekten muss vom Entwickler der Applikation eigenständig implementiert werden. Dabei können die Kategorien textbasiert eingegeben, oder vorgegebene Kategorien mit Hilfe von Checkboxen zur Selektion
angeboten werden. Eine Suchanfrage erfolgt dabei meist unter Nutzung der
Ajax-Technologie, um einen vollständiges Laden der Seite zu umgehen.
46
Beim Angebot des Erstellens von Reiseberichten wird u. a. die Möglichkeit gegeben mit Marker verschiedener Symbolik oder Farbgebung mehrere "Point Of
Interest" (POI) auf der Basis-Karte zu lokalisieren und Informationen des damit
assoziierten Info-Window einzugeben.
Manche Anwendungen ermöglichen es dem Benutzer Streckenverläufe auf der
Karte einzugeben. Dies sind Linienzüge, deren Stützpunkte definiert werden. Auf
die gleiche Art und Weise können auch Polygone erzeugt werden, die jeweils
eine "Area Of Interest" (AOI) kennzeichnen.
Zu den Standard-Suchdiensten zählt das Ermitteln von Routen ("Directions") zwischen zwei geographischen bzw. postalisch angegeben Orten. Die Zusatzinformationen, wie Dauer, wichtige Streckenmarkierungen etc. werden i. d. R. außerhalb des Kartenbereichs angezeigt. Auch diese Funktionalität wird teilweise von
den Frameworks unterstützt.
5.2 Beschreibung verwendeter Techniken
Zunächst muss festgelegt werden, auf welcher Basis die Kartendarstellung der
Praxis-Karte erfolgen soll. Die Wahl fällt auf GoogleMaps unter Nutzung der dort
angebotenen JavaScript-Frameworks. Wegen der guten Dokumentation und der
bereits langjährigen Nutzung der API kann sicher davon ausgegangen werden, das
keine größeren Programmierprobleme entstehen werden. Grobe Fehler im
JavaScript-Framework sind mit hoher Wahrscheinlichkeit durch die OpenSource
Nutzung bereits ausgemerzt. Die JavaScript-Bibliothek mit den Basisklassen wird
dynamisch beim Laden der Seite hinzugefügt.
Aufgrund der großen Menge an anzuzeigenden Informationen für eine Praxis bietet sich das Listendesign wie auf der Seite http://www.geocaching.de an. Da jedoch die Kategorien, in die die Praktiken eingeordnet werden zu zahlreich und
abstrakt für leicht ersichtliche Symbolik sind und die Liste der Kategorien vermutlich auch dynamisch gehalten wird, empfiehlt sich die Verwendung KartenExterner Checkboxen und eine Darstellung der so selektierbaren Kategorien in
einem Rahmen mit Rollbalken.
Die Verwendung von Mash-Ups sieht wie folgt aus. GoogleMaps ist durch seine
verteilten Ressourcen bereits Mash-Up basierend. Durch Nutzung des Such-APIs
der Firma Google werden Bilder der Institutionen oder der dazugehörigen Gemeinden direkt innerhalb des Eingabevorgangs ohne zusätzlichen Seitenwechsel
gesucht und zur Auswahl angeboten. Die dort gefundenen direkten URL-Verweise
auf im Web veröffentlichte Bilder werden dann beim Anzeigen der InstitutionsDetails eingebunden.
Mash-Ups werden weiterhin bei der halbautomatischen Festlegung der Institutionsorte verwendet. Durch Nutzung des von Google angebotenen Geokodier-Services werden die Koordinaten entweder sofort exakt ermittelt oder sie bilden
lediglich die Basis für die weitere Festlegung der Institutionskoordinaten durch
47
den Benutzer. Dies ist vor allem dann notwendig, wenn z. B. die angefragte Straße
oder die Hausnummer dem Geokodier-Service nicht bekannt ist. Dann muss der
Benutzer evtl. durch Verschieben des Lokalisierungsmarkers auf der Karte den
Standort genau festlegen. Dies erscheint notwendig vor allem in Ballungsgebieten, in denen mehrere Kirchengemeinden auf engstem Raum anzutreffen sein
werden. Die Zuordnung von Institutionen zu den jeweiligen Landeskirchen wird
manuell mittels DropDown-Selektionsfeld implementiert.
Die von Rails zur Verfügung gestellten Vorlagen für die Modifikation und Listenansichten der Daten sind noch nicht im Web 2.0 – Design. Hier wird eine Verbesserung durchgeführt.
Zur Darstellung des durch den eingestellten Radius begrenzten Bereiches wird
eine Art "Lupe" eingesetzt, die die räumlich nicht relevanten Gebiete halb transparent abdeckt. Relevante Orte sind dadurch ohne Überdeckung sichtbar.
In dieser Arbeit ist es die Praxis, die das zentrale Objekt der Interaktion darstellt. Die Nutzung einer "Sharing"-Funktionalität für diese Objekte könnte unterstützend wirken, da man Mitbenutzer im Rahmen des Verbundprojekts auf dieses
oder jenes Pattern (diese oder jene Praxis) durch einfache Weitergabe einer URL
aufmerksam machen kann, und diese dann ohne Umwege einen direkten Zugriff
auf die Informationsquellen haben. Jedoch würde dies die Einbindung einer MailFunktionalität benötigen, was jedoch nicht innerhalb dieses Teilprojekts geplant
ist. Im Prinzip wird jedoch durch das Zulassen des öffentlichen Zugriffs auf z. B.
die Ressource "Praxis" bereits das als REST-Architektur bezeichnete Prinzip (s. o.)
erfüllt. Durch eine eindeutige URL, wie durch die Architektur verlangt, kann auf
die Detailseite einer Praxis direkt zugegriffen werden, womit die Basis eines
Services bereits gelegt ist.
Insgesamt ergibt sich folgender, prinzipieller Aufbau der Anwendung: (Web-Scraping wird unter Abschnitt 5.5 erläutert)
48
Abbildung 5.2.1: Prinzipieller Aufbau der Anwendung
5.3 Herleitung der erforderlichen Datenbasis
Basierend auf den o. g. Begriffen und Userstories kann nun die Ermittlung der
notwendigen Datenbasis erfolgen. In die Datenbasis sollen dann die Testdaten
halbautomatisch migriert werden können.
Praxis:
Von denen für eine Praxis auf der Quellseite existierenden Informationen wird
die Projektnummer, der Projektname, die Beschreibung bzw. die Bemerkung als
Attribute übernommen. Schließlich wird noch ein Attribut für den externen Verweis auf die Seite der Testdaten benötigt. Jeder Praxis sind Benutzer zugeordnet, die als Autoren fungieren.
Benutzer:
Für einen Benutzer benötigt man auf jeden Fall einen Log-In-Namen für die Anmeldung im System sowie ein Passwort. Weiterhin besitzt der Benutzer eine Berufsbezeichnung, eine Zuordnung zu einer Institution und eine davon unabhän-
49
gige, eigene Adresse. Eine Zuordnung zu einer Institution ist notwendig und folglich immer vorhanden, da darauf die Lokalisierung des Benutzers auf der PraxisKarte basiert.
Institution:
Für eine Institution ist die geographische Lokalisierung elementar wichtig, die
automatisch aus deren Adresse ermittelt und dieser zugeordnet werden soll. Sie
muss eindeutig festgelegt werden. Eine eindeutige Identifizierung erfolgt durch
ihren Namen und den Standort. Weiterhin benötigt man einen Verweis auf das
der Institution zugewiesene Bild, und die Zuordnung zur Landeskirche.
Adresse:
Für die Adresse wird keine Eindeutigkeit verlangt, sondern nur in Bezug auf die
Institutionen.Sie enthält u. a. die gewohnten Attribute Stadt, Straße und PLZ.
Kategorien:
Die Kategorien werden den Testdaten entnommen und besitzen einen eindeutigen Namen. Sie sind nicht frei über die Applikation editierbar. Diese werden den
Testdaten entnommen.
(Autoren)rollen:
Die (Autoren)rollen werden allgemein gehalten, falls noch andere Benutzerrollen
benötigt werden. Dies wären, z. B. aktive Teilnehmer an einer Praxis, die sich als
Ansprechpartner für konkrete Fragen bzgl. der Umsetzung zur Verfügung stellen,
sich jedoch nicht an der Edition der Praxisbeschreibung beteiligen, sonder nur an
deren Kommentierung. Auch diese Rollenbezeichnungen sind fixe, vorgegebene
Daten.
Organisationselemente (hier Landeskirchen):
Sie sind durch ihren Namen eindeutig bestimmt und bilden eine Hierarchie, indem sie einen Verweis auf das Element der höher liegenden Hierarchieebene besitzen (hier die EKD). Den Landeskirchen sind dann die einzelnen Institutionen
zugeordnet.
5.3.1
Das Datenmodell
Die Speicherung der hierarchischen Bereichsstruktur der Landeskirchen und ihrer
Gemeinden wir auf Basis des RoR-Plugins "acts_as_tree" implementiert, das bereits Methoden zur Navigation innerhalb eines Hierarchiebaumes anbietet.
Anschließend wird das Ergebnis des Datenmodells sowie einige Besonderheiten
erläutert, die nicht aus dem Diagramm hervorgehen. Die Multiplizitäten sind im
Diagramm angegeben.
50
Die Bezeichner innerhalb der Applikation sind sämtlich die korrespondieren englischen Begriffe, da die Funktionalität des automatisierten Frameworks von RoR
auf programmatischer Konstruktion von Plural-Ausdrücken zur Reflexion von u. a.
Klassennamen und Pfadnamen basiert (siehe Beschreibung der vorhandenen
Techniken). Konflikte bei der Verwendung von nicht englischen Ausdrücken soll
dabei vermieden werden.
Für folgende Begriffe ist die Übersetzung der Attribute nicht eindeutig, und wird
daher explizit genannt:
Praxis: ("practice") Die Testdaten besitzen für jede Praxis einen Schlüssel der als
"remote_identifier" gespeichert wird. Die Attribute der Testdaten Projektname,
Beschreibung bzw. Bemerkung werden als "title" ,"abstract" bzw. "description"
bezeichnet. Um einen direkten Verweis auf die gesamte Beschreibung der Praxis
auf der Seite der Testdaten zu ermöglichen wird ein Attribut "url_to_remote"
vorgehalten, das aber nicht im definierten Sinne Verwendung findet, da tlw.
lediglich auf die Homepage verwiesen wird. Dies ist nicht anders lösbar, da die
gesuchten Daten auf eine der Seiten der Testdaten nur nach vorheriger Anmeldung erreichbar sind.
Benutzer ("user") besitzen zusätzliche Attribute zur Speicherung von Informationen für die von einem Benutzer durchgeführten Authentifizierung, die von einem
RubyOnRails-Plugin verwaltet wird.
Die Assoziation zwischen Praxis und Benutzer werden in der Relationstabelle
"participants" gespeichert (an der Praxis beteiligte). Die Relation hat die Rolle
des Benutzers bzgl. einer Praxis als Attribut.
Um evtl. andere Rollen außerhalb der Kategorie "Autor" zu ermöglichen (siehe
Herleitung der Zielobjekte) werden die Autorenrollen in der Tabelle "roles" gespeichert.
Die Assoziation zwischen Praxis und Institution (=Praxisstandort)werden in der
Relationstabelle "practicelocation" gespeichert.
Die Rekursivität der "division"-Tabelle (Organisationselemente) ermöglicht den
Aufbau eines allgemeinen Baumes. Die Einhaltung der Regeln für einen allgemeinen Baum mit mehreren Kind-Knoten, vor allem die Verhinderung von Zirkelschlüssen, muss durch die Applikationslogik sichergestellt werden.
Die geographischen Attribute bei der Adresse sind die im Goolge-Map-API verwendeten Größen; Längen- und Breitengrad ("longitude" , "latitude"). Sie werden
für Benutzer nicht genutzt, da deren Lokalisierung sich immer auf die ihnen zugeordnete Institution bezieht.
51
Alle anderen Adressen-Attribute können verwendet werden, falls sie sich von der
der Institution unterscheiden. Diese personenbezogenen Daten werden dann als
Kontaktinformationen angezeigt.
Abbildung 5.3.1.1: Die relevanten Teile des Datenmodells
52
Die Tabelle "session" wird von der Sitzungsverwaltung des Frameworks benötigt,
das alle zu persistierenden Zustandsdaten in der Datenbank und nicht in Cookies
ablegt werden.
5.4 Beschreibung des Benutzerinterface-Designs
In diesem Abschnitt wird das Design der Anwendung beschrieben und in welchen
Teilen den Userstories Rechnung getragen wird.
1
Der Seitenrahmen
Für die gesamte Anwendung ist der obere Bereich der Seite einheitlich. Er enthält den Titel der Anwendung, ein Logo und das Haupt-Navigationsmenü. Auf diesem ist stets der Titel der aktuellen Seite zu erkennbar.
Abbildung 5.4.1: Seitenrahmen mit Hauptmenü
Im Seitenrahmen wird die Möglichkeit des sofortigen Abmeldens eingebaut, das
jeder Zeit das Verlassen der Applikation ermöglicht. Dieser ist oberhalb der
Haupt-Navigationsleiste angebracht.
Für Nachrichten beim erfolgreichen Absichern von Daten oder im Falle von Fehlermeldungen wurde unter dem Menü ein Bereich freigehalten, damit der Benutzer immer die Informationen an der selben Stelle finden kann.
2
Die Startseite
Es existiert die Möglichkeit des Einloggens als registrierter Benutzer mit einem
speziellen Benutzernamen und einem Passwort. (US18.)
Aufgrund des Anmeldeverfahrens über einen Verantwortungsträger der Institution ist das Anlegen eines Benutzerkontos durch den Benutzer selbst nicht erlaubt.
Allerdings wird die Möglichkeit gegeben direkt auf die Seite der Praxis-Karte und
die Übersicht über die Praktiken zu navigieren (US17.). Dabei erfolgt ein indirekter Login als Gast-Benutzer.
53
3
Die Praxis-Karte
Abbildung 5.4.2: Initialer Zustand der Praxis-Karte
54
Die Abbildung 5.4.2 zeigt den initialen Zustand der Praxis-Karte nach dem Laden
der Seite: Der gelbe Marker in der Mitte der Karte zeigt bei Gastnutzern den geographischen Mittelpunkt aller Institutionen und bei angemeldeten Nutzern den
Ort der ihm zugeordneten Institution (US8.). Die Institutionen sind als violette
Kirchensymbole markiert (US7.). Durch Mausklick auf die Symbole (Marker) wird
ein Info-Window mit dem Namen der Institution, dem zugeordneten Bild, den
dort durchgeführten Praktiken sowie den Ansprechpartnern angezeigt. (siehe
Abb. 5.4.2)
Die Praxis-Tabelle als wichtigstes Element ist links oben lokalisiert (US6.). Die
Nutzer der Anwendung werden primär aus dem deutschen Umfeld kommen daher
wird eine links oben -> rechts unten Orientierung beim Lesen erwartet. Beim
Überstreichen einer Zeile mit dem Mauszeiger wird die Zeile hervorgehoben (siehe Praxis "Titel 2") und die Institutionen, zu denen die Praxis zugeordnet ist,
durch grüne Marker statt der Kirchensymbole gekennzeichnet. Befindet sich der
Mauszeiger außerhalb des Praxis-Tabellenbereichs werden die grünen Marker
wieder gegen die Kirchensymbole ausgetauscht. Die Bedienelemente zur Filterung der angezeigten Praktiken und Institutionsmarkierungen sind in den Spalten
rechts und links von der Karte angebracht. Dabei wird eine klare Trennung zwischen den inhaltlichen (US10., US11.) und geographischen Filtern (US12., US13.)
eingehalten, um dem Nutzer eine optimale funktionale Orientierung anzubieten.
Die für die Filter beider Seiten gemeinsam gültigen Bedienelemente sind mittig
über der Karte angebracht. Diese zentrale Filter-Deaktivierung sowie die Möglichkeit des vollständigen Zurücksetzens der Filtereinstellungen berücksichtigt
das oben bereits beschriebene Benutzerverhalten, im Zustand eines nicht gewünschten Ergebnisses und zu vielen verschiedenen Filtereinstellungen ohne Umwege auf die Ausgangssituation zurückzukehren, um von dort nochmals zu starten. (US15., US14.)
Ebenfalls mittig wird bei jeder Ajax basierten Anfrage, die im Hintergrund abläuft ein Progress-Indikator eingeblendet, um dem Prinzip der sofortigen Reaktion auf Benutzer-Aktionen zu genügen1.
Jeder Filter ist durch eine Checkbox "aktiv" separat deaktivierbar. (US14.)
Weiterhin wurde darauf geachtet, unbeabsichtigte Aktivitäten des User zu verhindern. Dies soll vor allem zur Reduzierung von Ajax-Anfragen führen. Dazu wird
z. B. die Zoom-Funktionalität des Mausrads innerhalb des Kartenbereichs deaktiviert. Zoom-Vorgänge muss der Benutzer explizit an den dafür vorhandenen Kontrollelementen auf der linken Seite initiieren.
Es existieren zwei Inhaltsfilter. Der eine ist der Kategorien-Filter, bei dem mittels Checkboxen die Kategorien gewählt werden können. Der andere ist der
Stichwortfilter. Um die Gültigkeit von Eingaben darzustellen bedarf es einer weiteren Anzeigefläche unterhalb "Aktueller Filterbegriff". Dort wird der Begriff an1 siehe [ScoNei2009]; S. 286 Principle: "React Immediately"
55
gezeigt, der bei der Filterung der aktuellen Praktiken verwendet ist. Bei Eingabe
eines neuen Begriffes wird der aktuelle Filterbegriff zusätzlich weiterhin angezeigt. Falls das Eingabefeld verändert wird, ohne die Änderung durch den Knopf
"Praktiken filtern" zu senden, hat die Eingabe keine Bedeutung. Durch den Knopf
"Löschen" wird der aktive Begriff und das Eingabefeld gelöscht. Es findet keine
Filterung mehr statt. Unterstützt wird die Eingabe durch Ajax-basiertes AutoVervollständigen auf Basis der Textattribute aller Praktiken.
Abbildung 5.4.3: Gültiger Filterbegriff "Titel"
Ist die Checkbox "exakter Titel" gewählt, so wird der eingegebene Text direkt mit
dem Titeln der Praktiken verglichen. Dies ist notwendig, falls ein Titel Teil eines
längeren Titels ist. Ist die Option nicht gewählt, so wird geprüft ob der Begriff in
einem der drei Text-Attributen der Praxis vorkommt.
Abbildung 5.4.4: Farbige Kennzeichnung eines noch nicht gültigen Eintrages
Ein anderer Weg wird bei der Eingabe des Radius gegangen (US12.; siehe
Abb. 5.4.4), da das Feld direkt mit dem Slider als Ausgabefeld korreliert ist, aber
auch als Eingabefeld dient. Ein noch nicht abgesendetes und daher nicht gültiger
Wert des Radius - weil nicht mit dem Slider und der Darstellung übereinstimmend - wird farblich hinterlegt und die Knöpfe "Setzen" und "Abbrechen" werden
aktiviert. Durch "Abbrechen" wird der ursprüngliche Wert (der Darstellung und
damit des Sliders) wieder angezeigt.
56
Abbildung 5.4.5: DragAndDrop des Benuzterstandorts
Weiterhin ist es möglich den Standort des gelben Standort-Marker durch
DragAndDrop zu verändern (US9.). Dabei wird die "Lupe" mit verschoben. Stößt
sie an die Grenzen der Karte, bewegt sich die darunter liegende Basis-Karte mittels Panning entgegen der Drag-Bewegung. Während des Vorgang werden alle
existierenden Institutionen angezeigt. Dies gibt einen Überblick, mit dessen Hilfe
der Benutzer eine bessere Entscheidung über den Zielort und somit über die
Filterung treffen kann (siehe Information Seeking Mantra). Nach Erreichen des
neuen Standorts wird die dort gültige Postleitzahl ermittelt. Im Info-Window des
Markers wird, soweit vorhanden, die dortige Adresse angezeigt (Abb. 5.4.2). Der
Standort wird in die Mitte der Karte verschoben.
Eine weitere Möglichkeit den Standort festzulegen ist die Eingabe der Postleitzahl des gewünschten Zielortes. Es folgt ein direkter Wechsel zu diesem Ort unter Berücksichtigung des Umgebungsfilters.
Die Baumansicht (siehe Abb. 5.4.6) auf der rechten Seite der Karte ermöglicht
das Deselektieren einzelner Landeskirchen-Gebiete. Standardmäßig sind alle Gebiete zur Anzeige selektiert (US13.). Die im Baum angezeigten Institutionen unterliegen ebenfalls der Filterung. Es werden folglich nur die Institutionen angezeigt, die auf der Karte zu sehen sind. Durch einen Maus-Klick auf die Institutionen im Baum wird das zur Institution gehörige Info-Window angezeigt.
57
Abbildung 5.4.6: Baumansicht der Institutionen mit geöffnetem Info-Window
Die Einträge in der Praxis-Tabelle sind als links ausgelegt. Per Maus-Klick öffnet
sich ein Menü mit drei Aktionsangeboten (außer dem Schließen des Menüs) (Abb.
5.4.7) . Der erste Eintrag ist selbsterklärend. Die anderen Aktivitäten sind quasi
nur "Makros" für die Filterung. Der zweite Eintrag ermöglicht ein exaktes Filtern
des Titels und zwar nur in der aktuell sichtbaren Umgebung. Dazu wird der Stichwortfilter programmatisch auf den angeklickten Titel gesetzt und die "exakter
Text"-Option gewählt und das Filtern angestoßen. Der dritte Eintrag ändert zusätzlich noch den Radius, sodass alle Institutionen mit dieser Praxis sichtbar werden (US16.). Ist nur eine Institution mit dieser Praxis vorhanden (diese ist dann
natürlich sichtbar) ändert sich nichts.
Abbildung 5.4.8. zeigt den Zustand nach auswählen der Praxis "Titel 1". Es wird
ein Knopf oberhalb der Praxis-Tabelle angezeigt, durch den sich die Titel-Filterung Rückgängig machen lässt, und der daraufhin wieder verschwindet.
58
Abbildung 5.4.7: Flyout-Menü für die Praktiken
Abbildung 5.4.8: Zustand nach Aktivierung der Filterung einer Praxis
59
4
Anlegen einer Institution
Abbildung 5.4.9: Anlegen einer neuen Institution: Initialzustand
Besonderes Augenmerk wurde auf die Ablaufsteuerung bei der Implementierung
der Eingabemaske für Institutionen gelegt, daher wird hier die Benutzeroberfläche kurz erläutert (siehe Abb. 5.4.9). Hier findet die Implemetierung der Userstories US2. und US3. statt.
Zunächst ist das Speichern der Institution deaktiviert, weil die geforderten Eingaben noch nicht vorhanden ist. Ausgangspunkt ist explitzit die Postleitzahl. Diese wird als erstes eingegeben und daraus über eine Ajax-Anfrage an den Geoservice von Google die dazugehörige Stadt ermittelt und in das entsprechende Feld
eingetragen. Damit wird auch die Eingabe der Straße freigegeben (Abb. 5.4.10).
Ist diese eingegeben, so wird durch drücken des Knopfes "Koordinaten ermitteln"
eine detailliertere Anfrage an den Geoservice gesendet. Ist die Adresse genau
bekannt, werden die Koordinaten direkt übernommen. Eine grüne Nachricht und
das Ändern des Markersymbols zu einem Punkt informiert den Benutzer über das
60
erfolgreiche Ermitteln des Standorts (Abb. 5.4.12). Ist jedoch z. B. die Hausnumgeändert, und der Benutzer
kann den genauen Standort durch DragAndDrop festlegen(Abb 5.4.11).
Es erfolgt eine Rücküberprüfung, ob bei den neuen Koordinaten die Straße noch
immer stimmt. Im negativen Fall wird der Benutzer mit einer roten Schrift zur
Abbildung 5.4.10: Freigabe aller Adressfelder zur
Koordinatenermittlung
Abbildung 5.4.11: Genaue Adresse nicht gefunden
61
Überprüfung aufgefordert, es muss jedoch keine Änderung vorgenommen werden. Nach Eingabe des Namens der Institution kann bereits die Informationen gespeichert werden. Ohne explizite Eingabe der Landeskirche wird die Institution
zu einer unbekannten Landeskirche zugeordnet. Bei der Festlegung des Bildes
hat der Benutzer die Wahl ein eigenes Bild auf den Applikationsserver zu laden
oder eine Suchanfrage auf Basis der bereits eingegebenen Informationen zu starten. Dazu wird aus der Adresse und dem Namen der Institution eine Standardanfrage zusammengestellt, die jedoch editiert werden kann und die mit "Anfrage
Senden" gestartet wird. Wird aus dem Suchergebnis ein Bild ausgewählt, so übernimmt die Anwendung beim Speichern lediglich die URL des Bildes und stellt das
Bild auf dieser Basis dar. Der Endzustand nach Eingabe aller möglichen Felder
zeigt Abb. 5.4.12. Fehlt eine geforderte Eingabe, wird dies mittels einem Warnhinweis dem Benutzer mitgeteilt und das Speichern wird unterbrochen. Beim
Speichern (also Senden der Daten an den Server) wird dann überprüft, ob sich an
dem Ort bereits eine Institution befindet. Das Sichern wird verwehrt und der Benutzer informiert, falls dem so ist.
Abbildung 5.4.12: Anlegen einer neuen Institution vor der Speicherung
62
5
Die Anzeige - und Eingabeseiten für Daten
Die Eingabeformulare der Objekte "Benutzer" und "Praxis" sind Standardlayouts
des RoR-Frameworks und werden hier nicht dargestellt. Sie implementieren die
Userstories US1., US4. und US5.
Beim Layout der Übersichtstabellen werden die Erkenntnisse aus [Victor2006]
weitgehend umgesetzt. Im Web 2.0 Design wird empfohlen Aktivitäten mit so
wenig Klicks und möglichst ohne erneutes, vollständiges Seitenladen zu unterstützen. Ein Beispiel hierfür ist "in place editing", also das direkte Verändern von
Inhalten z. B. in Tabellen. Dadurch wird Manipulation und Informationsaufnahme
in einer Oberfläche integriert. Diese Kombination kann leicht zu einem schlechten Design führen. In [Victor2006] wird eindringlich davor gewarnt, die Darstellung der Informationen zugunsten einer ausgefeilten Darstellung der Manipulationsmöglichkeiten der Informationen zu vernachlässigen. Der Autor fokussiert dabei auf das primäre Ziel des Benutzers: Sein mentales Modell zu modifizieren,
also zu lernen bzw. Informationen zu sammeln und einzuordnen. Erst zweitrangig
sollen die zur Manipulation verwendeten Objekte auffallen:
"Much current software fulfilling these needs [of learning] presents mechanical metaphors and objects to manipulate, but this is deceiving. People
using this [information] software do not care about these artificial [manipulation] objects; they care about seeing information and understanding
choices—manipulating a model in their heads." [Victor2006]
Daher erfolgt in diesem Design eine Trennung zwischen den Elementen zur Manipulation der Informationen und der Darstellung der Informationen, soweit möglich. Veränderungen der Inhalte wird, auch aufgrund der Komplexität einiger Dateneingaben, einheitlich auf einer separat zu ladenden Seite, also nicht in den
Übersichtslisten angeboten.
Im Rahmen der Forderung nach der Berücksichtigung des "sozialen Objekts" (siehe Kapitel 3.1 Erläuterung zum Begriff "Web 2.0") wird empfohlen: "Weisen Sie
den sozialen Objekten einen URL zu." ([PorEng2008];S. 54). Aus diesem Grund
wird der direkte Verweis auf eine Detailseite der Praxisbeschreibung vorgehalten. Diese kann dann einfach weitergegeben werden. Die momentane Konfiguration der Quellseite lässt dies aktuell nicht zu, weshalb nur der Verweis auf
den Auszug der Beschreibung im Datenpool der hier erstellten Applikation, und
ein Verweis lediglich auf die Homepage der Quellseite verwendet wird.
Bis auf die Übersichtsliste und die Details der Praktiken sind sämtliche andere
Seiten der Datenverwaltung nur für angemeldete Benutzer zugänglich, nicht aber
für Gastnutzer. Auch die dazugehörigen Navigationsmenü-Einträge werden für
Gastnutzer nicht angezeigt.
63
5.5 Besondere Implementierungsdetails
Um die Einschränkung durch die freie Nutzung des GoogleMaps-Services zu berücksichtigen muss für nicht registrierte Benutzer ein direkter Zugang zur Praxis-Karte
vorgehalten werden. Deshalb muss eine Login-Verwaltung existieren, die einen
Gastbenutzer von einem registrierten Benutzer unterscheiden kann. Findet kein Login statt, wird der Benutzer beim direkten Zugriff auf die Praxis-Karte automatisch
als Gast registriert. Dieser spezielle Benutzer hat wesentlich eingeschränktere
Rechte. Er darf nur lesend auf die Praktiken und auf die Praxis-Karte zugreifen. In
den Informationsfenstern der Praxis-Karte werden nur minimale personenbezogene
Daten dargestellt (nur Nachname), um dem Datenschutzforderungen nach zu kommen. Registrierten Benutzer werden dagegen alle Kontaktdaten angezeigt.
Die Templates des RoR-Frameworks zur Darstellung von Informationen aus der
Datenbank sind sämtlich tabellenbasierend. Dies entspricht nicht mehr den Standards für eine gute Übersichtlichkeit, wie sie für Benutzerfreundlichkeit gefor-
Abbildung 5.5.1: Tabellenlayout nach Vorlage des RoR-Frameworks
dert ist. Daher wurden die Übersichtsanzeigen entsprechend den Empfehlungen
aus [Victor2006] und [Fried2009] in Form von "Zebra-Listen" umgearbeitet. Die
Endform ermöglicht das sofortige Wahrnehmen mehr relevanter Informationen
als bei der herkömmlichen Tabellenform. So sind auch Expertise der Autoren und
Institutionen ebenfalls einfach sichtbar. Alle wichtigen Informationen sind im
neuen Layout auf der linken Seite einer Listenzeile. Die Hyperlinks für die möglichen Funktionalitäten sind ebenfalls sämtlich links platziert. Ein nach rechts Rollen z. B. bei langen Titeln oder zur Nutzung der Funktionalitäten ist so nicht
mehr nötig. Unterschiedliche Typographie helfen zusätzlich beim Lesen.
Eine Herausforderung war die Implementierung des "Lupeneffekts" oder besser
des Ausblend-Effekts. Aufgrund der schlechten Performance der JavaScript-Engine des Internet-Explorers (als der relevanteste Browser), musste eine Rechenoptimierung für die Darstellung gefunden werden. Daher wurden zwei Alternativen
eingebaut. Einmal einer bildbasierte Lösung, die flächendeckend arbeitet und
einmal durch Anzeige von einfachen, schnell berechenbaren nicht flächigen Polylines.
64
Abbildung 5.5.2: Tabellenlayout nach Web 2.0 Designprinzipien
Das Dry-Prinzip (Don't repeat yourself), das eines der Grundprinzipien des RoRFramework ist, musste für die Berechnung des Abstandes von Institutionen zum
Standpunkt des Benutzers missachtet werden. Der Grund liegt in der sonst nicht
zu gewährleistenden Performance beim Verschieben des Standorts bzw. einstellen des Radius sowie der darauf folgenden Filterung der Daten auf Basis der veränderten Werte per Ajax-Anfrage. Würde stetig für jede Standort- bzw. RadiusÄnderung eine Ajax-Anfrage zu starten wäre der kontinuierliche Lupen-Vergrößerungs-Effekt nicht realisierbar. Daher werden die Institutionsmarkierungen aufgrund von Berechnungen auf der Clientseite aus- bzw. eingeblendet. Andererseits muss das entsprechende Filterungsergebnis auch auf dem Server zur Verfügung stehen, da damit auch die Filterung der Praxis-Tabelle erfolgt. Um bei der
zu erwartenden Anzahl der Institutionen die Ajax-Anfrage im vertretbarer Größe
zu halten, ist also eine korrelierte Berechnung (nur mit den Daten Radius und
Geo-Koordinaten des Benutzerstandortes) auf dem Server nötig.
Bei der Suche nach Bildern wir noch eine zweite Technik angewendet, die sich
"Web Scraping" nennt. Dabei wird durch Parsen auf Basis von regulären Ausdrücken Daten aus normalen Webseiten extrahiert die das Ergebnis einer normalen Seiten-Anfrage an den Server sind. Diesem Verfahren liegt also kein API zugrunde. Dabei muss zunächst eine Regelmäßigkeit in der Darstellung der Daten
erkennbar sein. In diesem Falle sind es Standard-Suchanfragen an die BilderSuchmaschine http://elzr.com/imagery. Die Ergebnisseiten enthalten dabei direkte Verweise auf die Zielbilder, die es zu extrahieren gilt. Imagery bietet, anders als Google, keine Such-API mit einer RESTfull-Service Schnittstelle an, der
Standard-Seitenaufruf kann jedoch ähnlich diesem Prinzip der einfachen URL-Erstellung mit Parametern und einer Server-Anfrage mit GET-Verb erfolgen. Imagery lieferte bei stichprobenartigen Suchanfragen leicht bessere Ergebnisse in den
ersten Treffern. Daher lohnte sich der Aufwand des "Web Scraping" der Daten von
Imagery, um diese Ergebnisse schon bei der ersten Anfrage mit einbeziehen zu
können.
65
6.
Zusammenfassung
6.1 Kurzfassung des Problems und wie es gelöst wurde
Ziel der Arbeit war die Analyse, Design und Implementierung einer Anwendung zur
Visualisierung von geographisch lokalisierbaren Beiträgen einer Web-Community.
Dabei sollte die Partner-Community des Verbundprojekts Patongo als konkreter
Anhaltspunkt dienen. Die getroffenen Designentscheidungen wurden durch Literatur und dem Vergleich mit existierenden Implementationen untermauert.
Dazu wurden zunächst die Anforderungen aus den zu unterstützenden Szenarien
unter Berücksichtigung der im Verbundprojekt adressierten Community abgeleitet.
Daraufhin wurde der aktuelle Stand der Forschung recherchiert. Die dort verwendeten Techniken und Designs bildeten dann die Grundlage für die Designentscheidungen, die dann zur Implementierung der Anwendung führten. Den Abschluss bildete die schriftliche Aufarbeitung des Projekts.
6.2 Offene Fragen für weitere Abschlussarbeiten
Folgende Funktionalitäten könnten das vorhandene Tool zusätzlich zur geographischen Visualisierung sinnvoll erweitern.
Es wäre zu überlegen, ob es sinnvoll ist mittels eines Mash-Ups, das auf andere
Community-Seiten zugreift, den Online-Status, der dort gemeldeten Benutzer,
hinzuzufügen, um die Wahrnehmbarkeit der Aktivitäten dieser Mitglieder im Sinne einer Group-Awareness darzustellen.
Es sollte untersucht werden inwieweit eine Tag-Cloud auf der Seite der PraxisKarte zusätzlich zu der Kategorisierung einen Mehrwert bringt. Als Quelle könnte
die im Verbundprojekt geplante Datenbasis des Semantischen Netzes genutzt
werden, oder ob eher ein Querverweis auf die Seite der Praxis-Karte aus dem
Semantischen Netz heraus ausreichend ist.
In Hinblick auf eine mögliche Zuordnung von Institutionen zu den jeweiligen Landeskirchen könnte die Nutzung des Spatial Data Supports, der in MySQL enthalten
ist für die Speicherung der Koordinaten und darauf basierend Enthaltenseins-Anfragen von Vorteil sein. Nach einer Ermittlung der genauen geographischen
Grenzverläufe der Landeskirchen mittels Definition über geokodierte Polygone,
könnte eine automatische Einordnung von neuen Institutionen erfolgen.
66
7.
Quellenverzeichnisse
7.1 Literaturverzeichnis
[Alby2007]
ALBY, T. 2007"Web 2.0". Konzepte, Anwendungen,
Technologien. München.
[Arnold1988]
ARNOLD, W. 1988 "Lexikon der Psychologie". Neuausg. Freiburg im Breisgau.
[BluPel2009]
BLUMAUER, A. & PELLEGRINI, T. 2009 "Social Semantic Web". Web 2.0 - was nun? Berlin.
[WWW] http://www.gbv.de/dms/bsz/toc/bsz266277306inh.pdf.
[Chen2006]
CHEN, C. 2006
"Information visualization".
Beyond the horizon. 2nd ed. New York.
[Dickmann2001]
DICKMANN, F. 2001 "Web-Mapping und Web-GIS". 1.
Aufl. Braunschweig.
[EckBau2004]
"Extreme programming and agile processes in software engineering". 5th international conference, XP
2004, Garmisch-Partenkirchen, Germany, June 6 - 10,
2004 ; proceedings. Berlin. (Lecture notes in computer
science). [WWW] http://dx.doi.org/10.1007/b98150.
[Fried2009]
FRIEDMAN, V. 2009 "Praxisbuch Web 2.0". Moderne
Webseiten programmieren und gestalten ; [Web 2.0Design verstehen und realisieren ; Schritt für Schritt
zur aktuellen Webseite ; Farb- und Seitengestaltung
mit Photoshop ; DVD-ROM Video-Lektionen zu Adobe
Photoshop und CSS]. 2., aktualisierte und erw. Aufl.
Bonn.[WWW]
http://www.gbv.de/dms/ilmenau/toc/578429659.PDF.
[Foen032006]
FOENIX-RIOU, B. 2006. Visualisation Technologies.
When Search Engines Play at Maps. ONLINE, 2006
(Mar/Apr), S. 29–32.
[Gunt062005]
GUNTZEL, S. 2005. 'Green Maps' motivate activism.
National Catholic Reporter. 17. Juni. [WWW]
http://findarticles.com/p/articles/mi_m1141/is_32_4
1/ai_n14814075/. (11. Oktober 2009).
67
[HaaSchwaWess2004]
HAAKE, J., SCHWABE, G. & WESSNER, M. 2004 "CSCLKompendium". Lehr- und Handbuch zum computerunterstützten kooperativen Lernen. München.
[WWW] http://www.gbv.de/dms/bsz/toc/bsz107644134inh.pdf.
[JanSchar1999]
JANSEN, A. & SCHARFE, W. 1999 "Handbuch der Infografik". Visuelle Information in Publizistik, Werbung
und Öffentlichkeitsarbeit. Berlin. [WWW] http://www.gbv.de/dms/hebis-darmstadt/toc/75773961.pdf.
[KorZeh2008]
KORDUAN, P., ZEHNER, M. L. & KORDUAN-ZEHNER.
2008 "Geoinformation im Internet". Technologien zur
Nutzung raumbezogener Informationen im WWW. Heidelberg. [WWW]
http://www.gbv.de/dms/ilmenau/toc/525124233.PDF.
[KramC't202009]
KRAMER, A. 2009. Ortung muss sein. Geräte und Software, um Fotos mit Geodaten zu bestücken. c't, 2009
(20), S. 132–141.
[LukCSCW07]
LUKOSCH, S. 04/07 "Computerunterstütztes kooperatives Arbeiten - CWCW". Script zum Kurs 1880. Hagen:
Fernuniversität Hagen.
[ManMus2002]
MANHARTSBERGER, M. & MUSIL, S. 2002 "Web usability". Das Prinzip des Vertrauens. 1. Aufl. Bonn.
[MorOtt2008]
Morsy, H. & Otto, T. 2008 "Ruby on Rails 2". Das Entwickler-Handbuch ; [Installation, Programmierung, Administration ; umfangreiche Einführung in Ruby und
MVC ; inkl. Performance, Sicherheit, Plug-ins]. 1. Aufl.
Bonn.
[MSInc122006]
"Enterprise_Software_Roadmap_GER.pdf". [WWW]
http://www.hansevision.net/hansevision/Portals/0/do
wnloads/ppt_etc/Enterprise_Software_Roadmap_GER.
pdf. (14. Oktober 2009).
[PorEng2008]
Porter, J. & Engel, R. 2008 "Social Web design". Erfolgreiches Webdesign im Web 2.0 ; [die Interaktion zwischen den Usern als zentraler Bestandteil ihres Designs
; die wirklichen Gründe, warum Menschen online gehen ; erfolgreich von null auf tausend User]. 1. Aufl.
Bonn.[WWW]
http://www.gbv.de/dms/bs/toc/578545020.pdf.
68
[SchaTosWuJai2007]
SCHARL, A. et al. 2007
"The Geospatial Web". How
Geobrowsers, Social Software and the Web 2.0 are
Shaping the Network Society. London. (Springer11645 /Dig. Serial]). [WWW]
http://dx.doi.org/10.1007/978-1-84628-827-2.
[ScoNei2009]
SCOTT, B. & NEIL, T. 2009 "Designing web interfaces".
[principles and patterns for rich interactions]. 1. Aufl.
Beijing.
[Schuem092009]
"Forschung im PATONGO-Projekt". [WWW] http://patongo.fernuni-hagen.de/forschung.html. (1. November
2009).
[SchuemLuk2007]
SCHÜMMER, T. & LUKOSCH, S. 2007
"Patterns for
computer-mediated interaction". Chichester. [WWW]
http://www.loc.gov/catdir/enhancements/fy0739/200
7009229-b.html.
[Shneid052007]
"Web Science: A Provocative Invitation to Computer
Science". [WWW]
http://www.cs.umd.edu/~ben/ShneidermanCACM62007.pdf. (13. August 2009).
[Shneid121999]
SHNEIDERMAN, B. 1999
"The Eyes Have It: A Task by
Data Type Taxonomy for Information Visualizations".
(1. November 2009).
[Victor2006]
"Magic Ink: Information Software and the Graphical
Interface". (5. August 2009).
7.2 Quellen für Design-Elemente und Teile des Quellcodes
●
Aktivitäts-Indikator von Martin Jerpersen:
http://mentalized.net/activity-indicators/
●
dtree von Geir Landrö:
http://www.destroydrop.com/javascripts/tree/
69
7.3 Abbildungsverzeichnis
Abbildung 2.1.1: Ergebnis-Visualisierung bei www.kartoo.com....................12
Abbildung 2.1.2: Wertabhängige Verzerrung der Weltkarte bei www.Worldmapper.com......................................................................................13
Abbildung 2.2.1: Erfüllung der Anforderungen durch geographische Karten......19
Abbildung 3.2.1: Verteilung von Bekannten in Deutschland.........................25
Abbildung 3.2.2: Zeitnahe Darstellung von Beiträgen in twittermap.de...........26
Abbildung 3.2.3: Benutzer-generierte Karte bei www.Tagzania.com..............27
Abbildung 3.2.4: Reiseroute bei TravBuddy............................................28
Abbildung 3.2.5: Kategorisierte POIs mit Info-Windows bei SlowTravel...........28
Abbildung 3.2.6: Topographische Karte mit Joggingroute bei jogmap.de.........29
Abbildung 3.2.7: Umfangreiche Informationsdarstellung bei GeoChaching.......30
Abbildung 3.2.8: Kollaborative Karte zur OpenGreenMap...........................33
Abbildung 3.2.9: Suchfunktion...........................................................33
Abbildung 5.1.1: Prinzip der Web-Service-Server-Nutzung..........................43
Abbildung 5.2.1: Prinzipieller Aufbau der Anwendung................................49
Abbildung 5.3.1.1: Die relevanten Teile des Datenmodells..........................52
Abbildung 5.4.1: Seitenrahmen mit Hauptmenü......................................53
Abbildung 5.4.2: Initialer Zustand der Praxis-Karte..................................54
Abbildung 5.4.3: Gültiger Filterbegriff "Titel".........................................56
Abbildung 5.4.4: Farbige Kennzeichnung eines noch nicht gültigen Eintrages....56
Abbildung 5.4.5: DragAndDrop des Benuzterstandorts...............................57
Abbildung 5.4.6: Baumansicht der Institutionen mit geöffnetem Info-Window...58
Abbildung 5.4.7: Flyout-Menü für die Praktiken.......................................59
Abbildung 5.4.8: Zustand nach Aktivierung der Filterung einer Praxis.............59
Abbildung 5.4.9: Anlegen einer neuen Institution: Initialzustand..................60
Abbildung 5.4.10: Freigabe aller Adressfelder zur Koordinatenermittlung........61
Abbildung 5.4.11: Genaue Adresse nicht gefunden ..................................61
Abbildung 5.4.12: Anlegen einer neuen Institution vor der Speicherung..........62
Abbildung 5.5.1: Tabellenlayout nach Vorlage des RoR-Frameworks...............64
Abbildung 5.5.2: Tabellenlayout nach Web 2.0 Designprinzipien...................65
70