ÖV-Sightseeing
Wer im Linienbus sitzt, schaut gerne auf sein Handy. Doch wie wär’s, wenn alle öfter einen Blick aus dem Fenster werfen würden? Mit unserer Idee wollen wir ÖV-Strecken erlebbar machen.
Audioguides kennt man von Museen oder Ausstellungen. Durch sie rückt der Fokus auf die Bilder und die Eindrücke, begleitet durch den Museumsführer. Jeder Text, der sonst gelesen wird, kann auditiv wahrgenommen werden. Dieses Konzept wollen wir mit unserer Website weiterentwickeln und für alle zugänglich machen. Die Busstrecke der Linie 433 vom Bahnhof Sargans nach Mels soll erstmals dafür genutzt werden, zurückzulehnen, aus dem Fenster zu blicken und mehr Wissenswertes über die Umgebung kennenzulernen.
Irgendwo, eines Tages, auf einer Open Bus Sightseeingtour, auf einer gerade weniger interessanten Strecke kamen Fragen auf, ob es für dieses Angebot wirklich so einen teuren Bus braucht. Wer baut diese und wie funktioniert das? Ist es nötig, dass jeder Sitz ausgestattet ist mit einem Gerät, in welches diese im Preis inbegriffenen Billigkopfhörer eingestöpselt werden? Ist das im heutigen, digitalen Zeitalter noch nötig? Wir finden: NEIN! Die Anwendung ÖV Sightseeing bedarf keiner grossartigen Technik oder Umbauten am Bus. Man braucht nur sein Handy und die eigenen, angenehm sitzenden Kopfhörer. Nach dem Aufruf unserer Webseite kommst du sofort in das Feeling einer Sightseeingtour in den Ferien – mit GA praktisch umsonst! Zugegeben, das offene Dach können wir leider nicht bieten. Aber interessante Infos und Facts rund um den Ort, an dem sich der Bus gerade befindet, sind garantiert! Wie beim Original sind die richtigen Infos zum richtigen Zeitpunkt nicht abhängig von Fahrgeschwindigkeit oder einsteigenden Passagieren. Dank GPS wird der Informationsfluss geregelt und wenn gerade nichts zu sehen ist, wird man mit Musik vertröstet.
Als Pilotprojekt dient die Strecke von Sargans über Mels. Das Konzept beinhaltet, dass weitere Strecken einfach implementiert werden können. Jetzt, wo der Grundstein für diese Anwendung steht, ist es an der Zeit, im nächsten Digezz neue Touren zu definieren und anhand des Feedbacks Bugs beheben.
Für die Nutzung der App ist ein Zugriff auf den Standort nötig. Ausserdem funktioniert die App im Google Chrome Browser am besten. Jetzt ist alles gesagt. Viel Spass beim Busfahren!
(stm)
Idee
Die erste Idee war, eine App zu machen, die es erlaubt, in irgendein öffentliches Verkehrsmittel einzusteigen und je nach Standort ein lokales Audiofile anzuhören und so das Feeling einer Sightseeing Tour zu haben.
Lars konnte sich von Anfang an am meisten für das Aufnehmen der Audios begeistern. Nicolas entschied sich für die Programmierung der Website und das Herausknobeln der richtigen Kodierung. Später hat Nicolas das Titelbild, den Artikel und die Kritik verfasst. Lars hat sich um die Kritik bezüglich dem Audioguide gekümmert.
Ursprünglich wollten wir in der Stadt Chur eine Buslinie wählen und über diesen Rundkurs schreiben. Jedoch hatten wir während zahlreicher Testfahrten den Eindruck, wenig über eine solche Buslinie sagen zu können, da die meisten Busse an wenig spektakuläre Orte fuhren, zum Beispiel durch das Industriequartier. Lars war durch seinen alten Wohnort, der Rundkurs vom Bahnhof Sargans bis Mels im Bus 433 bekannt. Diese Strecke sind wir dann zu zweit abgefahren. Dabei stellten wir fest, wieviel diese Strecke zu bieten hat.
Ursprünglich wollten wir in der Stadt Chur eine Buslinie wählen und über diesen Rundkurs schreiben. Jedoch hatten wir während zahlreicher Testfahrten den Eindruck, wenig über eine solche Buslinie sagen zu können, da die meisten Busse an wenig spektakuläre Orte fuhren, zum Beispiel durch das Industriequartier. Lars war durch seinen alten Wohnort, der Rundkurs vom Bahnhof Sargans bis Mels im Bus 433 bekannt. Diese Strecke sind wir dann zu zweit abgefahren. Dabei stellten wir fest, wieviel diese Strecke zu bieten hat.
Umsetzung der Website
Programmieren
Nach dem Digezz Coaching war uns klar, welche wichtigen Code Schnippsel wir brauchten. Das waren die play und pause DOMs, die getLocation property, sowie das Koordinatensystem, welches auch von Google Maps eingesetzt wird. Letzteres war wichtig, weil wir Audios an bestimmten Standorten abspielen wollten.
Nach Upload of den Hosttech Server via Subdomain hatte Nicolas zunächst Mühe, die Basics hinzubekommen, nähmlich das Verlinken des javascript-Files mit der ersten HTML-Seite. Die Lösung für das Problem war dann durch Austausch mit MMP-Programmierprofis zum Glück schnell gefunden. Da wir zu Beginn noch keine Audiofiles hatte, nutzte Nicolas zum Testen ein Audiofile. Vor dem eigentlichen Coden wurden alle relevanten Fragen aufgeschrieben. So entstand ein Überblick darüber, welche Snippets benötigt werden. Dazu nutzte Nicolas das Internet aber auch Chat GPT, was ein nützliches Tool war. Es kann Beispiele generieren, die in den Code eingesetzt werden können. Um die Distanz zu berechnen, gibt es eine sehr komplexe Formel, die dank Chat GPT viel schneller zusammengetragen werden konnte. Dann ging es darum den Standort zu überprüfen. Dazu diente die Funktion checkLocation. Dank dieser Funktion kann in einer for Schlaufe regelmässig der aktuelle Standort des Nutzers überprüft werden und der Radius definiert werden, indem das Audio abspielen darf. Mit getLocation wird später auf den Standort zugegriffen. Nun mussten mit einem Array alle Standorte der Tour den passenden Audios mitgegeben werden. Das Abspielen regelt die Funktion playAudio. Dann ging es ans Testen im Bus 433.
Beim Abspielen tauchten jedoch viele kleine Fehler auf. Die Audios waren alle 5-10 Minuten lang. Weil das nächste Ziel in Reichweite war, bevor das zuvor gestartete Audio zu Ende war, enstand eine Überlagerung von bis zu 5 Audios oder mehr was extrem störend anzuhören war. Ausserdem spielten Audios auch auf der Startseite ab. Um beide Fehler zu lösen benötigt man mindestens 5 Anläufe. Lars fuhr also die Tour ein Dutzend Mal ab und Nicolas tweakte in der Zwischenzeit am Code. Das erste Problem konnte erst am Sonntag Abend vor der Abgabe gelöst werden. Die Lösung konnte dann zusammen mit einem schlauen Kollegen ausfindig gemacht werden. Die Lösung für das zweite Problem war schneller gefunden, mit einer Bedingung, die besagt, dass nur auf der bustour.html Seite Audio abspielen darf. Nun musste nur noch verhindert werden, dass am Ende des Rundkurses, das Anfangsaudio abspielt, bevor das letzte Audio fertig ist. Das regelte dann die Cooldown Funktion. Am Schluss sorgt redirectToStartseite dafür, dass der User nach Ende des letzten Audios auf die Startseite zurückgeleitet wird. Dies ist während der Tour mit einem Mausklick auch manuell möglich. Ausserdem wurden gewisse Audios gekürzt und Standorte angepasst, um jedem Audio genügend Spielzeit zu geben.
Audio Aufnahmen
Nachdem die Recherche und grobe Auslese der Texte abgeschlossen war, wurden die Audiodateien von Lars erstellt. Erfahrungswerte der Testfahrten haben nur bedingt Auskunft darüber gegeben, wie lange maximal gesprochen werden darf. Die Dauer zwischen den einzelnen Haltestellen hängt stark vom Passagiervolumen ab und somit auch davon, ob der Busfahrer Zeit aufholen muss, bis zur nächsten Haltestelle. Die Texte wurden in der Tonkabine aufgenommen und anschliessend mit Soundeffekten hinterlegt. Als Puffer dient stimmungsmässig passende Musik, welche angehängt wurde. Sogar noch nach dem Einfügen der definitiven Audiofiles wurde später bestimmt, drei Files wieder aus dem Programm zu nehmen. Sie existieren jedoch noch auf der Webseite und dienen als Easteregg für Menschen, welche dank den developer Tools gerne tiefere Einblicke in eine Webseite haben. Es handelt sich dabei um die zweite Begrüssung, ein Gebäude, welches jetzt private Wohnungen sind, sowie aus Zeitgründen auf das letzte File verzichtet wurde. Einerseits existieren ungenutzte, fertigte Audiofiles, sowie Infos in Textform. Es wäre nicht undenkbar, eine zweite Tour, mit anderen Infos für denselben Bus zu einem späteren Zeitpunkt zu gestalten.
Learnings
Grob gerechnet, wenn ein Bus mit 50 Km/h durch einen Radius von 30 Meter fährt, hat das Handy weniger als 4.5 Sekunden Zeit zu erkennen, wo es sich befindet. Das Intervall dieser Abfragung geschieht jedoch auch, je nach Modell und weiteren Parametern, alle paar Sekunden. Dass also ein definierter GPS-Koordinatenpunkt übersprungen wird, ist bei diesem Radius sehr plausibel. Zu einem späteren Zeitpunkt wurden sämtliche Koordinaten nochmal neu definiert, inklusive neuem Radius, welcher nun fast doppelt so gross ist.
Es lohnt sich seinen Code so früh wie möglich und so häufig wie möglich zu testen. Gerade, wenn man vorhat eine Standortabhängige Bustour zu programmieren. Man kann auf Google Chrome seinen lokalen Standort auch verändern. Allerdings sind wir noch nicht auf eine App gestossen, die eine Standortverschiebung simulieren kann, die das Fahren im Bus simulieren könnte. Das dürfte wohl auch rechtlich heikel sein. Vielleicht noch Zukunftsmusik. Stattdessen, kann man auch Orte in der Nähe anpeilen, die sehr Nahe beieinander liegen. Nur ist es immer umständlich, den Code unterwegs anzupassen. Aber man kann das mit Handy-Hotspot durchaus auch auf einer Busfahrt ausprobieren. Leider war der Bus 433 nicht klimatisiert, was nachmittags im Juni ziemlich unangenehm sein kann. Es ist auch wichtig den richtigen Browser zu verwenden. Chrome ist maximal optimiert und darum sehr empfehlenswert. Es kann dennoch vorkommen, dass auf Touch Displays der selbe Button, der im Desktop noch funktioniert hat, nicht reagiert. Das ist meistens ein Zeichen dafür, dass der Code Bugs beinhaltet. Audiofiles und Standorte sollten auch immer der Strecke und dem Code angepasst werden. Darum trifft wiedereinmal der Satz Kill your Darlings zu. Manchmal muss ein Audio auch ganz verschwinden, weil die Strecke und die Geschwindigkeit des Buses es nicht anders zulassen.
Für dieses Vorhaben empfiehlt sich eine Kreistour, keine Linientour. Das Testen der kompletten Anwendung kann auch mit dem Velo durchgeführt werden, oder wie Lars mit dem E-Bike.