Back-Button, History, Formulare usw. in Web 2.0 CEs

[deerwood]

Moin,

ich gestehe, hier im Forum nicht gesucht zu haben, vielleicht ist dennoch jemand freundlich genug, mich in die richtige Richtung zu weisen.

Contao bringt bereits im Core das MooTools Akkordeon mit. Zudem gibt es andere Web 2.0 Erweiterungen wie etwa TabControl und pk_noobslide, um nur einige wenige Prominete zu nennen.

Alle diese Inhaltselemente haben gemeinsam, dass sie zwar auf den ersten Blick "schick" und "modern" sind ... aber wenn man sie einsetzt, zeigt sich, dass sie in mancher Beziehung doch recht unfreundlich zum Benutzer sind. Einige Beispiele:

• gezieltes Öffnen via Link: das Akkordeon hat gar keinen Mechanismus dafür. Man muss das JS Template ändern, um ein bestimmtes Element von vornherein offen zu haben; sobald man mehr als ein Akkordeon einsetzt (auf verschiedenen Seiten), ist man zur Zeit gezwungen, mehrere Seitenlayouts zu verwenden. TabControl hat immerhin einen rudimentären Support via "fragment identifier" aka "hash" aka "Anker" (.../my_page.html#some_pane_id).
• Formulare: hat man ein Formular in einem Akkordeon/Tab, das nicht per default aufgeklappt ist, und validiert das Formular nicht, dann wird die Seite neu geladen, um die Fehler anzuzeigen, aber das "schicke/moderne" kommt diesem Zweck in die Quere: es wird NICHT das Akkordeon/Tab mit den Fehlern gezeigt, sondern irgend ein anderes. Dem Besucher wird damit eher signalisiert, dass seine Aktion erfolgreich war ... und wundert sich, wenn er, eher durch Zufall, das Akkordeon/Tab mit den Fehlern wieder anzeigt.
• blätterbare Inhalte: hat man eine mehrseitige Galerie oder News usw. in einem Tab/Akkordeon, dann wird beim Blättern die Seite neu geladen ... aber das Tab/Akkordeon mit der nächsten Seite der Galerie/News nicht angezeigt. Sehr anstrengend und nervig für den Besucher!
• Links: folgt der Besucher einem Link in einem Akkordeon/Tab und benutzt dann den Back-Button des Browsers, dann landet er nicht an der Stelle, von der aus er den Link geklickt hat. Auch das ist sehr frustrierend und höchst unfreundlich.
• Bookmarks: es ist nicht möglich, eine Seite mit Tabs/Akkordeons so zu merken, dass sie genau den richtigen Zustand wiederspiegelt. Versendet man z.B. die URL an einen Freund, dann sieht der irgend etwas, aber ziemlich sicher NICHT den Zustand auf den man sich bezieht.

Ich befasse mich gerade mit Lösungs-Ansätzen für Akkordeon (Wiki bzw. Forum) und TabControl (Forum, auch die Beiträge davor lesen) ... und für die beiden Erweiterungen funktioniert das auch bereits recht brauchbar.

Aber das sind "halbgare" Lösungen. Die Session-Cookies helfen schon ein wenig weiter, aber das Bookmarking z.B. ist damit garnicht möglich.

Und es gibt ja noch reichlich andere Erweiterungen, die ähnliche Probleme haben. Ich müsste nach und nach sämtliche diesbezügliche Erweiterungen durchgehen und jeweils Speziallösungen implementieren. Das kann ich sicher ncht leisten.

Das Thema an sich ist uralt: jede Web 2.0 Anwendung (mit oder ohne Ajax) hat ähnliche Probleme. Und es gibt Lösungsansätze. Generelles History JS (auch mit HTML 5 Features und Fallback). Ich verlinke absichtlich nicht, weil ich Eure Vorschläge lesen möchte.

Ich denke, es ist an der Zeit, dass Contao einen Mechanismus für modernste History Handhabung mitbringt.

Was denkt Ihr?

LG, Georg

[Wichteldesign]

Interessanter Gedanke. Die Probleme die du da ansprichst sind uns sicher allen nur zu gut bekannt. Für die meisten gibt es mehr oder weniger saubere Workarounds.
Ich frag mich gerade aber wie so ein History-Handling aussehen könnte? Wo setzt das an?

[dieselboy]

Hallo Georg,

das Akkordeon lässt sich mit ein paar Javascript- oder PHP-Kenntnissen anpassen. So ließe sich ein GET-Parameter nutzen und abfragen, mithilfe dessen ein Element geöffnet angezeigt werden kann. Das hat auch gleich den großen Vorteil, dass die Browser-History dadurch beeinflusst werden kann.

Wie das bequem über das Contao-Backend zu lösen ist, weiß ich nicht. Allerdings sind dafür auch nicht mehrere Seitenlayouts nötig.

Formulare: hat man ein Formular in einem Akkordeon/Tab, das nicht per default aufgeklappt ist, und validiert das Formular nicht, dann wird die Seite neu geladen, um die Fehler anzuzeigen, aber das "schicke/moderne" kommt diesem Zweck in die Quere: es wird NICHT das Akkordeon/Tab mit den Fehlern gezeigt, sondern irgend ein anderes. Dem Besucher wird damit eher signalisiert, dass seine Aktion erfolgreich war ... und wundert sich, wenn er, eher durch Zufall, das Akkordeon/Tab mit den Fehlern wieder anzeigt.

Das lässt sich genauso mit einem GET-Parameter lösen. Beim Absenden des Formulars muss dieser nur mitgegeben werden.

Viele Grüße
Daniel

[backbone]

Die einzig saubere Lösung die mit allen SEs funtkioniert gibt es erst mit der HTML5 History, da aber ists super easy was das FE-Scripting angeht, man muss nur ein bissl mehr Logik auf der Serverseite haben, da jeder Tab dann seinen eigenen DeepLink brauch und der auch irgendwie verwaltbar ist.

Mit anderen History Plugins, welche das Hash missbrauchen gibt es immer Einschränkung, aber die größte, nämlich das SEO, kann inzwischen von Google trotzdem behandelt werden: wenn der Hash mit einen "!" beginnt, erkennt Google das es sich um einen Ajax-Deeplink handelt und schickt eine gesonderte Anfrage mit einem zusätzlichen GET-Param "ESCAPED_HASH_FRAGMENTS" (oder so ähnlich). Man kommt auf jeden Fall nicht drum herum die FE-"Markup-Generation" im Serverscript zu reproduzieren, damit der Server die plainen Seiten der DeepLinks ausliefern kann.
Für letzteres hat im Prinzip 3 Arten von Requests:
- AJAX-Request direkt vom FE-Script
- Google-Requests mit dem zusätzlichen GET
- DirectLink Requests wo man nicht entscheiden kann, welcher DeepLink genommen wurde (da keine Hashinformationen). Hier muss eine Seite mit Platzhaltern ausgeliefert werden, die per JS/AJAX nachträglich mit einem AJAX-Request ersetzt werden.

Mit HTML5-History brauch man sich um diese 3 Fälle keine sorgen mehr machen und muss egtl nur ein bisschen mehr Brain ins FE-Skript geben, das die URL updaten muss (via HTML5 History) und die ausgelieferten Seiten zusammenbaut (solange der Server nur ganze HTML Seiten ausliefert). Das Ganze kann man noch verfeinern indem AJAX-Request nur mit - vom Request abhängigen - speziellen (vorzugweise JSON-)Daten beantwortet werden und man sich so ein komplettes HTML-Rendering im Server sparen kann.