Titel: QUADROTOUR – ein krpano-Tourbuilder, der im TYPO3-13-CMS läuft (in Entwicklung)
Hallo zusammen,
nachdem Panotour Pro 2 eingestellt wurde, habe ich angefangen, mir einen eigenen Nachfolger zu bauen. Er heißt QUADROTOUR, nutzt krpano als Render-Engine – und unterscheidet sich von den üblichen eigenständigen Tourbuildern in einem Punkt: er läuft im CMS TYPO3 13.
Ich stelle das Konzept hier vor, weil der CMS-Ansatz aus meiner Sicht ein paar Probleme löst, die hier im Forum immer wieder auftauchen. Und weil mich eure Einschätzung interessiert – gerade dort, wo ihr Schwachstellen seht.
Die Grundidee
Eine klassische Tour ist ein abgeschlossenes Paket. Man baut sie im Desktop-Werkzeug, exportiert, lädt hoch, und dann liegt sie als eigenständiger Ordner auf dem Server. Das funktioniert wunderbar – bis der Kunde anruft und in einem Hotspot ein Wort geändert haben will. Dann heißt es: Projekt öffnen, ändern, neu exportieren, neu hochladen, Caches leeren, hoffen, dass sonst nichts verrutscht ist.
Bei QUADROTOUR ist die Tour kein separates Artefakt. Szenen, Hotspots und Inhalte sind Datensätze in der CMS-Datenbank, und das XML, das krpano lädt, wird daraus erzeugt. Ein Hotspot enthält also keine Kopie irgendeines Textes – er verweist auf ein TYPO3-Inhaltselement. Der Kunde pflegt dieses Element im Backend genauso wie jeden anderen Seiteninhalt, und die Änderung ist beim nächsten Aufruf in der Tour zu sehen. Einen Export-Schritt gibt es überhaupt nicht mehr.
Was die CMS-Basis mitbringt
Das ist der Teil, den ich am Anfang unterschätzt habe. Vieles, was in einem eigenständigen Tourbuilder wirklich mühsam ist, ist in einem CMS schlicht ein gelöstes Problem:
- Sämtliche vorhandenen Inhaltstypen stehen in der Tour zur Verfügung. Text mit Bild, Galerien, Video, Akkordeons, Formulare, News, Shop-Produkte – alles, was die Seite darstellen kann, lässt sich in einen Hotspot holen. Und jede Extension, die ein Projekt ohnehin einsetzt, kommt gratis mit, ohne dass ich eine Entsprechung nachbauen muss.
- Redaktioneller Arbeitsablauf. Versionierung, Arbeitsumgebungen, Vorschau vor der Veröffentlichung, Rückgängig. Der Kunde kann eine Änderung vorbereiten, jemand schaut drüber, dann geht sie live.
- Rechte. Backend-Benutzergruppen regeln, wer welche Tour, welche Szenen, welche Inhalte anfassen darf. Bei größeren Seiten mit mehreren Redakteuren ist das kein Nebenschauplatz.
- Der Dateipool (FAL). Panoramen und Bilder liegen im selben Speicher wie alles andere, mit Metadaten, Alternativtexten, Urheberrechtsfeldern und automatischer Bildverarbeitung. Eine Datei einmal ersetzen – und sie ist überall aktualisiert, wo sie verwendet wird.
- SEO und Adressen. Szenen können echte sprechende URLs und eigene Metadaten bekommen und sind damit einzeln verlinkbar und auffindbar, statt hinter einem Rautenzeichen zu verschwinden.
- Barrierefreiheit. Mit dem BFSG bzw. dem European Accessibility Act ist das für viele meiner Kunden keine Kür mehr. Inhalte in einem ordentlichen Redaktionssystem statt fest im XML machen WCAG 2.1 AA realistisch erreichbar.
- Mehrsprachigkeit – geplant. Darauf freue ich mich am meisten, und es war der Hauptgrund für die Entscheidung zugunsten eines CMS. Die Übersetzungsverwaltung von TYPO3 ist ausgereift: Übersetzungsworkflow, Sprachfallbacks, Sprachmenüs – seit Jahren in tausenden Projekten im Einsatz. Sobald QUADROTOUR das durchreicht, bedeutet eine mehrsprachige Tour: Inhaltsdatensätze ganz normal übersetzen, statt pro Sprache ein eigenes XML zu pflegen. Umgesetzt ist es noch nicht – aber das Fundament dafür liegt schon da, und genau darum geht es.
Was ich darauf gebaut habe
Die eigentliche Arbeit steckt in der krpano-Seite:
- Szenen-Editor im Backend. Panorama in einer laufenden krpano-Ansicht, Hotspots per Klick setzen, per Ziehen verschieben, Blickrichtung aus der aktuellen Ansicht übernehmen. Werkzeugleiste für die verschiedenen Hotspot-Typen, Polygonflächen, Kamerastandorte.
- Übersichtsgraph. Alle Szenen als Vorschaubilder, die Verknüpfungen dazwischen als Pfeile gezeichnet. So sieht man den Aufbau der Tour auf einen Blick – und findet kaputte oder einseitige Verbindungen sofort.
- Verortung. Grundriss, Google Maps und OpenStreetMap, dazu automatische Platzierung aus den GPS-Daten in EXIF/XMP der Panoramen. Letzteres spart bei Außentouren viel stumpfe Arbeit – man muss nur die Aufnahmen abfangen, die auf der Nullinsel gelandet sind.
- Kacheln nur bei Bedarf. Multiresolution-Kacheln werden je Tour mit einstellbarer Qualität erzeugt, und das System merkt sich pro Szene, ob die Kacheln aktuell, fehlend oder nach einem Bildtausch veraltet sind. Kein Neuberechnen von 200 Panoramen, weil eines ausgetauscht wurde.
- Hotspot-Stile als Datensätze. Aussehen und Verhalten zentral definiert und wiederverwendet, statt dass jeder Hotspot seine eigenen Einstellungen mitschleppt.
- Aktions-Katalog. Pro Knopf eine freie Liste von Aktionen – Szenenwechsel, Inhaltselement in der Lightbox öffnen, externer Link, Ton, eigene krpano-Aktion.
- Startverhalten. Little-Planet-Einflug, Autorotation mit einstellbarer Wartezeit, geführte Auto-Tour nach Blickrichtung.
Stand der Dinge
Aktive Entwicklung, läuft in echten Projekten. Noch nichts zum Herunterladen – ich überlege noch, in welcher Form ich es herausgebe (Extension für bestehende TYPO3-Seiten oder Komplettpaket). Meine Arbeit mit Drohnen- und Bodenpanoramen treibt die Funktionsliste, es entsteht also an echten Aufträgen und nicht am Reißbrett.
Anschauen / mitverfolgen
Aktueller Entwicklungsstand (live, in Arbeit – ein paar Ecken und Kanten inklusive):
Facebook-Gruppe zu QUADROTOUR, wo ich den Fortschritt poste:
Facebook
Worüber ich mich freuen würde
- Wer von euch ist von Panotour weggegangen: Wo seid ihr gelandet, und was fehlt euch bis heute?
- Betreibt jemand sonst krpano-Touren aus einem CMS heraus? Mich würde interessieren, wie ihr XML-Erzeugung und Caching löst.
- Und die ehrliche Frage: Ist die CMS-Kopplung aus eurer Sicht ein Vorteil oder eine Fessel? Sie bringt viel – aber die Tour ist eben kein Ordner mehr, den man auf einen USB-Stick kopiert und dem Kunden in die Hand drückt. Dass das ein echter Zielkonflikt ist, ist mir bewusst.
Danke fürs Lesen – und danke an Klaus für krpano, das hier die Hauptarbeit macht.
Dirk Wohlrabe
QUADRONET Internetlösungen, Bad Bergzabern