Usabilityverbesserung bei Artikelbearbeitung

[tmaterna]

Ich habe einen Artikel mit knapp 60 Inhaltselementen die fortlaufend angezeigt werden. Wenn ich beispielsweise das 35. bearbeiten möchte muss ich nach dem speichern und schließen wieder ganz runter scrollen um das 36. zu bearbeiten.

Vorschlag: nach speichern und schließen zum zu letzt bearbeiteten Inhaltselement in der Liste springen.

[frontendschlampe]

finde ich eine gute Idee

[k-webdesign]

Gute Idee, aber die Wahlmöglichkeit sollte in den Einstellungen vorhanden sein. In manchen Fällen nervt es sicherlich, wieder irgendwo in der Mitte der Seite zu hängen.

[frontendschlampe]

bei Modulen, Newsbeiträgen etc. sollte das dann aber auch passieren - also einheitlich

[Aybee]

Nur so am Rande bemerkt: Deshalb habe ich mir angewöhnt in solchen Fällen nicht Speichern und Schließen, sondern Speichern und dann Browser zurück zu benutzen.

[pagestyles]

Sehr gute Idee!

[jankout]

+1

[leofeyer]

@contao/developers Ne Idee, wie man das umsetzen könnte?

[Toflar]

'attributes'          => 'onclick="Backend.getScrollOffset()"'

auf die edit-Operation?

[aschempp]

@Toflar soweit ich weis würde er dann im Bearbeiten-Modus auch an diese Position springen…

[Toflar]

Naja dann halt einfach im mode 4?

[leofeyer]

Wenn es so einfach wäre, hätte ich nicht gefragt :)

[Toflar]

Was daran funktioniert denn nicht?

[leofeyer]

Der Wert wird auf der Bearbeitungsseite überschrieben, weil es auch dort einen Scroll-Observer gibt.

[Toflar]

Und genau das sollte doch eben nicht getan werden? Die DC_Table::edit() macht z.B. bei $_POST['saveNclose']ein \System::setCookie('BE_PAGE_OFFSET', 0, 0). Würde sie das nicht tun, wäre doch alles klar? Warum tut sie das überhaupt?

[leofeyer]

Weil sonst die Übersichtsseite auf den Wert gescrollt würde, den die Bearbeitungsmaske als letztes hatte bevor "Speichern und Schließen" geklickt wurde.

[Toflar]

Was ja das Ziel wäre bei Mode 4?

[leofeyer]

Nein, die Übersichtsseite sollte auf den Wert gescrollt werden, den die Übersichtsseite als letztes hatte, nicht den, den die Bearbeitungsseite als letztes hatte.

[Toflar]

Ja, sag ich doch längst. Genau das würde ja geschehen wenn die Edit Operation das genannte Attribute setzt und die Edit View das Cookie nicht resettet?

[leofeyer]

Versuch es doch einfach, dann siehst Du. Ansonsten erkläre ich es Dir beim nächsten Call.

[leofeyer]

Wie am 5. November auf Mumble besprochen, würde es eventuell mit zwei Cookies gehen (eins für den Bearbeitungsmodus und eins für die Listendarstellung).

[leofeyer]

Allerdings unterstützt die zwei Cookie-Lösung nicht "Speichern und zurück".

[Toflar]

Ich habe mir noch einmal ein paar Gedanken dazu gemacht. Ich denke es ist eigentlich nicht richtig, dass wir überhaupt ein Cookie benutzen. Ich will eigentlich nicht, dass wenn ich zwei Tabs offen habe diese einander gegenseitig beeinflussen. Insofern müsste es eigentlich pro Tab bzw. Fenster sein und in meinen Augen gibt es auch keinen Grund so etwas dauerhaft abzuspeichern. Während ich es z.B. für nett halte, dass sich Contao nach einem Monat noch daran erinnert, dass ich in den Systemeinstellungen alle Legenden der Übersicht wegen zugeklappt hatte, so ist es völlig unerheblich ob es sich daran erinnert, wo ich vor einem Monat geklickt habe. Insofern könnte man für diese Funktionalität das Cookie killen und durch window.sessionStorage ersetzen. Ob da dann 2 Keys oder 5 drin sind, ist ja unerheblich.

[aschempp]

Wo das ganze gespeichert wird ändert doch überhaupt nichts an der Problematik?

[Toflar]

Das ist ja nur ein Stack? Kann doch nicht so schwer sein? Ich versuch mich an einem PR morgen.

[leofeyer]

Danke, @Toflar. Ich denke auch, dass es nicht so schwer sein kann.

[Toflar]

Meine Analyse:
Im Prinzip ist die jetzige Implementierung sehr seltsam. Auf jeder Operation kann man festlegen, ob man gerne den Scroll-Offset gespeichert hätte oder nicht. Dies erfolgt durch:

'attributes'          => 'onclick="Backend.getScrollOffset()"',

Das ist aber doch eigentlich Schwachsinn, weil es macht ja immer Sinn, wieder zu dem Kontext zu hüpfen wo man gerade vorher war, richtig? Also ich sehe keinen Grund, warum man beim Duplizieren wieder ganz runter zur Liste springen sollte und beim Löschen nicht. Das ist natürlich jetzt ein theoretisches Beispiel, weil beide Operations, also sowohl copy als auch delete die Anweisung 'onclick="Backend.getScrollOffset()"' bereits enthalten aber gerade diese Tatsache belegt doch eigentlich, dass es immer Sinn macht?
Diejenigen Operations die 'onclick="Backend.getScrollOffset()"' im Moment noch nicht enthalten, sind diejenigen, die auf eine andere Ansicht springen (eben edit) oder bei denen es keinen Sinn macht aber eigentlich auch nicht schaden würde (show). Beim edit ist das verständlich, weil man ja sonst auf der Edit-Maske plötzlich ganz unten landen würde, sollte man auf der vorherigen Listenansicht weit unten auf die edit Operation geklickt haben.

Lösungsvorschlag:
Eigentlich müsste man doch nur den Offset an die aktuelle URL binden und bei jeder Operation die man klickt speichern. Also immer. So könnte ich auf der Listenansicht auf den Edit-Button klicken, würde auf die Edit-Ansicht weitergeleitet. Die hätte eine andere URL und der Offset würde somit ignoriert. Wenn ich da auf irgendwas klicke das den Offset gespeichert haben möchte, wäre das ja auch wieder auf der aktuellen URL und würde somit immer noch funktionieren. Klicke ich dann z.B. auf Speichern und schliessen würde ich zurück auf die Listenansicht springen, auf deren URL noch immer der Offset gespeichert ist und wäre somit korrekt an dem Ort an dem ich zuletzt den Edit-Button betätigt habe.

Nun ergäbe sich dadurch aber eine weitere Problematik: Ich klicke in der News xy ganz unten im Fenster auf ein beliebiges-Inhaltselement und bearbeite das (edit Operation), entscheide mich aber dann im Edit-Modus nix zu speichern sondern direkt z.B. zu den Benutzern zu springen. Nun ist es halt einfach so, dass ich beim nächsten mal wenn ich wieder die News xy bearbeiten möchte, ich wieder direkt nach ganz unten geleitet werde obwohl ich evtl. das schon lange ignoriert habe und wieder oben anfangen möchte.

Das kann man womöglich sowohl als korrektes Verhalten à la "das war ja auch der letzte Zustand in dem du die Liste verlassen hast", als auch als nerviges Verhalten taxieren.
Was meint ihr?

[discordier]

Du koenntest den gespeicherten URLs eine Verfallszeit geben, aber ich sehe das allgemeine Problem wie du.
Da es jedoch nur im session storage gespeichert werden sollte, ist dies meiner Meinung nach vernachlaessigbar.
Viel interessanter wird es, wenn du pagination hast und den scroll offset. Wie verhaelt es sich dann?
speichert er "Seite 3 ganz unten" aber wenn du wieder rein wechselst startest du auf Seite 1 ganz unten?

[Toflar]

Die Antwort kennst du. Die Pagination funktioniert über Session statt über die URL und würde somit auch immer falsch springen bzw. nur wenn zwischenzeitlich die Session verändert wurde.

[aschempp]

man müsste ausserdem das Token aus der URL entfernen. Und mit Tabs funktioniert das auch nicht. Es ist allerdings die beste Variante welche ich bisher gehört habe...

[leofeyer]

Wie am 18. Oktober erneut auf Mumble besprochen, lässt sich das Problem doch nicht so einfach umsetzen wie anfangs gedacht. Am besten wäre es daher, wenn Du in so einem Fall einfach neue Tabs aufmachst.