Wechselwirkungen - Interactions

Idee & Vision

Donaustadt ist der größte Wiener Bezirk mit den höchsten Zuzugsraten und einer großen internationalen Community, u.a. ist hier die UNO mit mehreren tausend Mitarbeiterinnen aus aller Welt situiert.

Um allen Neuankömmlingen, aber auch den alteingesessenen Donaustädterinnen eine wirkliche Erleichterung im täglichen Leben zu bieten, wurde in langen Brainstorming-Sitzungen die Idee geboren, einen virtuellen Bezirksführer für Smartphones zu entwickeln.

Hauptziel in unserem Projekt ist die Entwicklung und Verfügbarmachung des „virtuellen Bezirksführer Donaustadt“. In Zusammenarbeit mit der Bezirksvorstehung werden in einer Smartphone Applikation die wesentlichen administrativen Informationen des Bezirkes, wie Öffnungszeiten, Adressen, Kontakte und Zuständigkeiten diverser Ämter und Behörden nicht nur online gebracht sondern vor allem in einem intuitiv zugänglichen Userinterface aufbereitet.

Dadurch sollen die Zeit/Orts/Zuständigkeits-Probleme bei oftmals sowieso anstrengenden Behördenwegen weitgehend vermieden werden. Einen echten Mehrwert bieten weiterhin die im Projekt enthaltenen Guides zu Sehenswürdigkeiten, öffentlichen Verkehrsmittel, Restaurants und Einkaufsmöglichkeiten.
Ein weiteres Ziel ist die leichte Adaptierbarkeit auf andere Zonen oder Bezirke bzw. wollen wir künftig auch maßgeschneiderte Anwendungen für Firmen und Behörden entwickeln, die ihren Mitarbeitern oder Kunden eine moderne und spannende Applikation bieten wollen um sich in neuen oder unübersichtlichen öffentlichen oder privaten Räumen zurechtzufinden. Gespräche laufen diesbezüglich mit einer Magistratsabteilung der Stadt Wien sowie mit der Geschäftsführung eines großen Einkaufszentrums.

Wie heutzutage üblich begannen wir unsere Recherchen im Internet, insbesondere da auf unserem Gebiet nicht nur lokale Erkenntnisse maßgeblich sind sondern vor allem die internationalen Entwicklungen. Trotzdem führten wir natürlich auch eine Literaturrecherche (Bibliothek der TU Wien) durch, die aber nicht den aktuellsten Forschungsstand zeigte.
Weiters besuchten wir im Rahmen des Projektes die Ausstellung „Geo City Data“ in der Wiener Planungswerkstatt (Ausstellungszentrum der Stadtentwicklung), bei welcher wir auch zur Finissage zur Projektpräsentation eingeladen wurden.

Projektziel & Beschreibung

Seit einiger Zeit spielt der Tourismus auch jenseits der Donau, so zum Beispiel auch in der Donaustadt, eine immer größere Rolle. Viele Touristen, aber auch Einheimische sind jedoch mit den derzeit am Markt vorhandenen Stadt- bzw. Bezirksführern unzufrieden, da diese unübersichtlich, unvollständig, umständlich in der Handhabung sind. Ebenso zeigen diese Führer oft nur einen kleinen beschränkten Ausschnitt aus dem Kulturangebot, veraltete Daten, beziehungsweise unzureichend aufbereitete Informationen.

Um dieses Problem zu lösen, entwickeln wir einen softwarebasierenden Stadt- bzw. Bezirksführer für Smartphones aufbauend auf der Android-Plattform. Der Benutzer kann ein Objekt mittels der eingebauten Handykamera identifizieren, er kann aber auch nach Objekten in der Datenbank suchen.
Die Software, die unter dem Namen „Virtueller Bezirksführer Donausatdt“ erstellt wird, bietet einige einzigartige, innovative Funktionen und Eigenschaften:

Erster digitaler Bezirksführer in Wien
Neuartige und interaktive Führung des Nutzers durch den Bezirk
Leichte und schnell aktualisierbare Datenbasis

Diese Anwendung revolutioniert das Angebot von Tourismusführern. Dem Benutzer wird die lästige Aufgabe abgenommen, das gewünschte Ziel auf einer Karte zu suchen. Ebenfalls unterstützt der digitale Bezirksführer den User dabei, ein potentielles Ziel zu finden.

Das Programm kann auf weitere Bezirke und ganz neue Städte ausgebaut werden. Durch das modular aufgebaute System kann das Programm einfach adaptiert und an anderer Städte angepasst werden. Durch die Erstellung eines kompletten Paketes (Server, Anwendung, Webinterface) kann der Bezirksführer ohne viel Einarbeitungszeit angepasst werden.

livev2

Steht der Benutzer z.B. bei der U-Bahn Station Kagran und möchte zum Finanzamt wird von der Smartphonekamera die aktuelle Umgebung abgebildet, das System blendet Öffnungszeiten, Ansprechpersonen, Entfernung und Wegbeschreibung ein. Für sehbehinderte Personen werden Audiokommentare bzw. entsprechende Vibrationssignale ausgegeben. Im Gebäude angekommen kann sie sich über strategisch platzierte QR-Codes auch innen (also ohne GPS-Unterstützung) orientieren und so zur Ansprechperson ihrer Wahl finden. Weiters bietet das System Alternativen, Telefonnummern etc. an.

livev

Anschließend sucht der Benutzer ein ethischen Restaurant ihrer Wahl, welches ihr ebenso vom System vorgeschlagen wird wie die schnellsten öffentlichen Verbindungen oder ihr noch neue Sehenswürdigkeiten im näheren Umkreis.

Unser Unic-Selling-Point liegt in der gezielten Weiterentwicklung aktuellster Technologien zur Umsetzung unseres Projektzieles - einer im täglichen Leben sinnvoll verwendbaren Anwendung. Technologien werden nicht um ihrer selbst willen für Techno-Nerds entwickelt sondern um die Benutzerinnen bestmöglich zu unterstützen und dadurch den Menschen im Alltagsleben konkret zu helfen.

Technische Lösungswege

Die Technologien die wir zu Erstellung unseres Programmes verwendete haben umfassen u.a. Fotografie, GPS, Gyroskop, Internet (insbesondere Google Maps und andere Dienste), QR-Codes sowie die entsprechenden 2d- und 3d-Darstellungen am mobilen Gerät. Um den Bezirksführer so weit nutzbar wie möglich zu machen, wird nicht für eine bestimmte Marke sondern für (fast) alle offenen Mobile-Betriebssysteme entwickelt.

Die Anwendung wird mit der Programmiersprache JAVA realisiert und wird auf Smartphones mit einem Android Betriebssystem lauffähig sein. Als Entwicklungsumgebung wird die freie Software, Eclipse verwendet. Die Sehenswürdigkeiten werden in einer MySQL-Datenbank gespeichert. Der Zugriff auf diese Datenbank wird mittels einer eigens erstellten Schnittstelle realisiert. Die Kartendaten werden durch das OpenStreet Map Projekt bereitgestellt.

Die Datenbank liegt auf einem Internet-Server, während die lokalen Clients unter Berücksichtigung von Standort, Bewegungs- und Lagedaten sowie natürlich dem entsprechenden Input der Benutzerin sowohl die nötigen Berechnungen anhand der programmierten Algorithmen durchführen als auch die Ergebnisse in grafischer Form ausgeben, teilweise als Overlay auf Karte, Foto bzw. aktueller Ansicht .
Besonderes Augenmerk wird dabei auf die Benutzbarkeit auch für nicht-technikaffine Menschen, auf Barrierefreiheit sowie auf eine international verständliche Iconisierung gelegt.

Zu Beginn unserer Arbeit an der Applikation begannen uns mit den Eigenheiten der Android Plattform und lernten auf die Plattformspezifische API zuzugreifen über die wir die gesamten Hardwarezugriffe abgewickelt haben. (Kammera, GPS, Lagesensor)

Datenbank

Als Datenbank Software zum Speichern der Objekten entschieden wir uns für das freie MySQL und als Verwaltungssoftware phpMyAdmin. Da diese beiden Softwarelösung für uns die beste Möglichkeit waren, da wir mit diesen schon viel im Schulbetrieb gearbeitet haben.

Um die Datenbank automatischen mit den in XML vorhandenen Daten, aus dem OpenStreetMap Projekt, in die Datenbank zu speichern, entwickelten wir einen automatischen Interpreter welche das XML (bis zu 40000 Datensätzen) auf Relevanz beurteilt und unwichtige Daten automatisch aussortiert.

Da wir einen sicheren Zugang zu der Datenbank benötigten entschieden wir uns einen API zu entwickeln die Anfragen des Mobiltelefons nach Objekten beantwortete. Diese API übersetzte zum Erreichen dieses Ziel die Anfrage des Mobiltelefons in ein SQL Abfrage. Ebenso überprüft die API ob die Anfrage auch korrekt ist.
Ein weitere Benifit der API lag daran das wir durch den Aufbau dieser, einen typische SQL-Injektion (Angriff auf die Datenbank) verhindern konnte.

Arbeitsaufwand

Neben den Arbeiten im Schulunterricht ist ein derartiges Projekt natürlich nur mit zahlreichem Einsatz in der Freizeit möglich. Insgesamt haben wir bis Anfang März ca. 1200 Personenstunden am Projekt gearbeitet, bis zum Projektende Angang Juni werden sicherlich nochmals 800 Personenstunden dazukommen.

Schlussfolgerungen

Die im Projekt gewonnenen Erfahrungen sowie das Interesse, welches schon unser Prototyp hervorruft, stimmt uns optimistisch bezüglich einer konkreten kommerziellen Verwertung des Projektes nach dem Projektende in der Schule.
Neben der augenscheinlichen Kommerzialisierung des Bezirksführers Donaustadt im Android Store, bei welchen wir den Bezirksführer zu einem sehr konkurrenzfähigen Preis anbieten wollen, schwebt uns vor allem die Anpassung des Systems für interessierte Firmen oder Institutionen vor (Vorgespräche laufen bereits jetzt Ende Februar). Wir hoffen damit in den Monaten und Jahren nach der Matura (und während des Studiums) genug weitere Entwicklungsarbeiten finanzieren zu können um uns eventuell zu einem späteren Zeitpunkt in diesem Themenbereich erfolgreich selbständig machen zu können.

Live View

Die LiveView ist die zentrale Funktion der Anwendung. Um die Position des Benutzers genau zu bestimmen verwendeten wir einen GPS Listener, welcher jeweils bei Location Updates einen Broadcast an die Anwendung schickt, sodass währendem es keinen neuen Updates empfangen keine CPU-Zeit beansprucht wird.
Ein großes Problem bei der Erstellung der LiveView war die Errechnung und Umrechnung der Daten des Lagesensors. Die Daten die wir von dem Lagesensor erhalten ist eine Matrix mit Daten von einem Sensor der die Stärke des Magnetfelds misst. Mittels einer Umrechnungsalgorithmus konnten wir aus diesen Daten die Himmelsrichtung extrahieren, welche wir zur Anzeige von den Objekten benötigt wird. Die Kalkulation dieser Objekte wird in einenm eigenen Berechnungsthread ausgelegt, sodass der Nutzer trotz der langen Berechnungsdauer keinen spürbaren Unterschied bei der Reaktionszeit der GUI merkt.

Ein wichtiger Gesichtspunkt dieser Applikation war das nahtlose Nachladen der Objekte im Umfeld des Benützer, sodass der Nutzer nichts von dem Ladevorgang mitbekommt. Dies realisierten wir mittels einen dynmaischen Cache, welcher sobald der Benutzer eine gewisse Distanz zurückgelegt hat, wieder neue Daten nachlädt. Da das Laden durch die, durch die Mobilfunktechnik, gegeben hohe Latenz, ziemlich viel Zeit in Anspruch nimmt, wurde das Laden in einen eigenen Thread ausgelagert.

livev

Advisor

Der Ratgeber ermöglicht den Benutzer einfach und schnell mittels einer geführten Suche sein gewünschtes Ziel zu erreichen. Um den Benutzer das Navigieren durch die verschiedenen Aktionskategorien (Essen&Trinken, NightLife, Unterhaltung, usw.) entschieden wir uns für einen Listen-Darstellung.

advisor

Suche

Ein weitere Kritikpunkt an den herkömmlichen Führern war der, dass es schwer war ein bestimmtes Objekt zu finden. Es gab zwar oft einen Index dieser war aber oft falsch beziehungsweise nicht komplett. Deshalb fügten wir zu der Applikation eine Suche ein. Die Suche baut auf einer „Fuzzy-Search“ auf. Diese ermöglicht eine ungenau Suche nach bestimmten Objekten, sodass die Objekte auch gefunden werden wenn ein ungenauer Suchbegriff eingegeben wurde.

Maps

Ein häufiger Kritikpunkt bei konventionellen Stadtführern sind die umständlichen und nicht vollständigen Karten. Um diese Problem zu adressieren entwickelten wir eine Kartenansicht. Diese kann entweder alle verfügbaren Kategorien anzeigen, aber auch nur spezielle, wie zum Beispiel Restaurants oder Sehenswürdigkeiten.

Das Kartenmaterial (Bilder, Satelietenansicht) beziehen wir von Google Maps. Um das Problem des langen Ladevorgangs und Darstellung der einzelnen Objekte auf der Karte entschieden wir auch hier einen Thread einzusetzen. Dieses ermöglicht den Benutzer weiterhin mit der Karte zu agieren (zoomen, Ansicht verändern,...) währendem die Objekte nach und nach auf dem Bildschirm erscheinen. Bei diesem Ladevorgang werden Objekte zuerst geladen welche sich in der unmittelbaren Umgebung des Benutzers befinden.

map