Das Physical Web im Detail

Das Physical Web im Detail

Das Physical Web ist ein Konzept, das festgelegt, wie Objekte und Orte Informationen über sich bereitstellen oder erweiterte Funktionalität am Smartphone eines Nutzers in der Nähe anbieten können. Dies geschieht mittels so genannter Eddystones, die URLs über das Bluetooth Low-Energy-Beacon-Profile aussenden. Dies ermöglicht es Entwicklern, Web-Apps einen Objekt- oder Ortskontext mitzugeben, ohne dass eine dedizierte App installiert sein muss. Dies unterscheidet diese Art der Beacons von den bekannteren iBeacons. Trotzdem wären mit Eddystones auch Deeplinks direkt in installierte Apps möglich, sofern diese zusätzlich benötigt wird.

(Hinweis: Wenn Sie jetzt nicht zu sehr in die Tiefe gehen wollen, sondern nur wissen wollen, wie man es in Betrieb nehmen kann, scrollen Sie hinunter bis „Die einfachste Art das Physical Web zu nutzen„.)

Voraussetzungen

Damit das Ganze auch wirklich am Smartphone des Nutzers funktioniert, gibt es einige Voraussetzung. Einerseits benötigt der Nutzer Google Chrome in der aktuellen Version, das Smartphone muss mit dem Bluetooth Low-Energy-Beacon-Profile umgehen können (Android 4.3+, iOS 7+) und der User muss Bluetooth und Location Services aktiviert haben.

Heutzutage erfüllen bereits viele Nutzer diese Voraussetzungen, da Location Services von vielen verbreiteten Apps genutzt werden und Bluetooth-Low-Energy für Activity Tracker oder Smartwatches verwendet wird. Zudem ist Bluetooth ob der Nutzung im Auto ohnehin meist an.

Natürlich braucht man auch die Web-App selbst. Also eine für Mobilgeräte optimierte Web-App mit CMS für die Verwaltung des Contents und der Orte/Dinge. (Hinweis: Das macht xamoom out-of-the-box!)

Um die Web-App tauglich für das Physical Web zu machen, muss diese mittels SSL-Verschlüsselung gesichert sein und darf keine URLs enthalten, die länger als 17 Bytes lang sind. Bei diesen 17 Bytes gibt es aber ein paar Besonderheiten. So zählt das „https://“ oder „.com“ jeweils nur als ein Zeichen. Das bedeutet, dass „https://m.xamoom.com/abc123“ genau 17 Bytes lang ist.

  • https:// => 1
  • m.xamoom => 8
  • .com => 1
  • /abc123 => 7

Indexing und andere Herausforderungen

Sofern die Web-App diese Voraussetzungen erfüllt, gilt es noch ein anderes Problem zu lösen: Google muss sie richtig indizieren. Um genau zu sein, muss ein Bot namens „Google-PhysicalWeb“ die richtigen Informationen für jeden Eddystone finden. Dies macht der Bot, indem er nach folgenden Meta-Informationen sucht.

<head>
                <meta charset="UTF-8">
                <meta name="description" content="YOUR CONTENT DESCRIPTION">
                <link rel="shortcut icon" href="YOUR FAV ICON">
                <title>YOUR CONTENT TITLE</title>
</head>

Wenn Ihr Content sehr statisch ist, lässt sich das leicht realisieren. Die Wahrheit ist aber, dass eine moderne Web-App ihre Inhalte, für jeden Ort bzw. jedes Ding dynamisch laden wird und da wird es etwas schwieriger. ALLES muss schon da sein, wenn der Bot die Seite indiziert und der liest ausschließlich den HTML-Source durch ohne – wie etwa ein Browser – Scripte auszuführen. Um zu testen, was ihre Web-App so liefert, kann der Eddystone-Validator genutzt werden.

Der Bot nutzt später diese Informationen, um die Notification (siehe Titelbild) zu erzeugen.

Das nächste Problem besteht darin, dass Google und andere Bots Ihre Web-App indizieren werden und sie somit in deren Suchergebnissen aufscheint. Im Fall von orts-/dingbezogenen Diensten will man das aber meist nicht, da der Inhalt oder die Funktion lediglich vor Ort oder am Objekt konsumiert werden soll.

Nun könnte man alle Bots mittels robots.txt aussperren, jedoch würde der „Google-PhysicalWeb-Bot“ von nun an nichts mehr indizieren und könnte somit auch keine Benachrichtigungen von einem Eddystone mehr anzeigen. Das zweite Problem ist, dass Google, wenn es Inhalte doppelt findet („Duplicate Content“ auf der Webseite des Kunden und in der Web App) diesen Umstand mit einem schlechteren Search Ranking bestraft. Dieses Dilemma zu umgehen, stellt die Entwickler einer Web-App für diesen konkreten Anwendungsfall sehr schnell vor große Probleme.

Silent Notifications

Wie bereits erwähnt, generiert der Eddstone – sofern alles richtig läuft – eine Notification am Gerät des Users. Diese ist allerdings silent und low-priority. Das heißt, dass man unter Android die Notification Bar öffnen muss, um sie zu sehen. Unter Chrome am iPhone wird diese im Notification Center angezeigt – allerdings erst, wenn man dort manuell Chrome hinzugefügt hat. Außerdem machen diese Notifications auf kein Geräusch.

Der Grund dafür ist, dass wenn viele Eddystone deployt sind, die Telefone der Nutzer dauern klingeln würden. Man gibt also die Entscheidung wann und wo der Nutzer interagieren will, zurück an den User, was aus UX-Sicht betrachtet eine schöne Lösung ist.

Die einfachste Art, das Physical Web zu nutzen

Nun da Sie wissen, dass das Ganze gar nicht so einfach zu implementieren ist, haben wir eine gute Nachricht: Mit xamoom benötigen Sie lediglich eine HTTPS-Domain und ein paar Eddystones, die sie mit den, vom xamoom-Backend für Sie generierten URLs, beschreiben müssen. Dann einfach einen Build des xamoom Web-Clients für ihre Domain bei uns anfordern und auf ihrem Webspace hochladen. So einfach kann es sein.

Eine kleine Einführung in Eddystones, alle Möglichkeiten zur Nutzung sowie Vor- und Nachteile gibt es in diesem xamoom-Blogpost.

By | 2017-06-12T13:32:15+00:00 8. November 2016|