WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)

Frontend-Edit Überlegungen

<< < (2/11) > >>

BlackBird:

--- Quote from: chio on July 27, 2010, 10:22:31 AM ---Dazu kommen andere Fallstricke: Hat man mehrere Abschnitte, kann man immer nur einen speichern. Im Frontend wäre das völlig verwaschen, da wird es wohl viel Gefluche geben.

Für viele Module geht das gar nicht; die Formulare sind zu umfangreich/komplex. Es kommt also in jedem Fall eine Mischung aus Frontend-Edit und klassischem Backend raus -> ergo: Alles was im Frontend bearbeitbar wäre, muss immer auch noch im Backend bearbeitbar sein.

--- End quote ---

Übrigens wäre es auch eine sehr schöne (Kompromiß-)Lösung, den entsprechenden Teil in einer Dialogbox zu öffnen. (jQuery UI Dialog) Mit "entsprechend" meine ich etwa die Ausgabe der modify.php des Moduls ohne den Backend-Rahmen. Ließe sich relativ leicht mit ein bißchen Ajax realisieren. Das ist zwar immer noch kein echtes Frontend-Edit, aber daß es das im derzeitigen Core nicht geben kann, wurde ja bereits gesagt.

Waldschwein:
Damit nicht schon wieder der Thread zerpflückt wird mit Angelegenheiten, die nichts mit dem Thema zu tun haben, wurde es geteilt. Für Sicherheit usw. geht's hierlang: https://forum.WebsiteBaker.org/index.php/topic,18860.msg125774.html#msg125774

Hier ist Frontend-Edit.

Gruß Michael

Stefek:
Hallo,

da ich auch auf Useability stehe,
hier mal meine Überlegungen zu Edit in Place, Frontend Edit und Edit Link zum Backend


Das wären so die verschiedenen Oberbegriffe.
Im Moment gibt es nur dieses Ding mit den Links ins Backend, aber die verweisen auch nicht auf Abschnitte der Seite sondern auf die "Gesamtseite" = ein Link für Edit für alle Sections und alle Blöcke (wenn mehr Blöcke im Template verwendet werden).

Das ist wenig verständlich für den "Normaluser", weil er nicht unbeding immer eine klare, für ihn sinvolle, Linie, zwischen den verschiedenen Abschnitten ziehen kann.

All diese Punkte hier wurden schon besprochen, ich will versuchen, den Kindern jeweils einen Namen zu geben und weitere Überlegungen anstellen.
Wie gesagt, ich habe sehr viel Interesse, dass es so etwas für WB gibt.


EDIT IN PLACE
Das sieht auf den ersten Blick am interessantesten aus. Man klickt den EDIT Knopf und kann genau an der Stelle editieren, wo der Block/Section steht.

Probleme die damit einhergehen:
[+]Ein richtiges "Edit in Place" hängt auch von den dazugehörigen CSS Files ab. Verschiedene Blöcke (nicht Sections) können unterschiedliche Hintergründe und andere unterschiedliche Style angaben haben, sodass es schwierig werden könnte, ein voll integriertes "Edit in Place" zu gewährleisten".
[+]Außerdem sind einige Blöcke zu schmal, um da auch gleich die Schaltflächen des Editors drin zu haben.
[+]Dann gibt es das Problem, dass Änderungen sofort "scharf" sind, aber das ist ohnehin so bei WB, es sei denn, man verwendet Thorns History Patch.[/list]

Sieht recht kompliziert aus, das alles "schön" hin zu bekommen.
Für nicht-WYSIWYG Module müßte dann ohnehin eine andere Lösung her.

FRONTEND EDIT
Das ist eine interessante Sache. Eben das, was Bianca beschrieben hat:


--- Quote from: BlackBird on July 27, 2010, 06:09:02 PM ---Übrigens wäre es auch eine sehr schöne (Kompromiß-)Lösung, den entsprechenden Teil in einer Dialogbox zu öffnen. (jQuery UI Dialog) Mit "entsprechend" meine ich etwa die Ausgabe der modify.php des Moduls ohne den Backend-Rahmen. Ließe sich relativ leicht mit ein bißchen Ajax realisieren.

--- End quote ---
Aber auch hier gibt es Probleme, weil die Module nicht alle einheitlich sind.
Wenn ich da an die "Modify" des Guestbooks denke, oder des "Form" Moduls - viele Einträge können sich echt langziehen.
Aber es wäre durchaus vertretbar.
Aber es gibt auch Module wie eben Guestbook, wo man das "Frontend-Edit" in der view.php integrieren könnte.
Szenario: ich logge mich ein, um das Guestbook zu bearbeiten und sehe im FE die neuen Beiträge (da eingeloggt) in einem abweichenden Stil (einem, der unmißverständlich zeigt, dass die noch nicht freigeschaltet sind).
Ich kann gleich im FE entscheiden, ob ich es freischalte/lösche, die Buttons sind da. Auch ob ich eines korrigiere oder einen Kommentar dafür schreibe.
Bei diesem Modul wäre es viel praktischer und mit etwas AJAX und Verständnis für Sicherheit könnte man das durchaus machen.

Dann gibt es noch die dritte Kategorie:
LINK ZUM BACKEND
Das allein würde schon viel mehr Komfort bringen und vielen "Editoren" die Arbeit erleichtern.

Für gewöhnlich gibt es bei jeder Section, die in WB angelegt wird, einen Anchor-Tag, etwa
<a class="section_anchor" id="wb_193" name="wb_193">
Man könnte diese Anchors so präparieren, dass man im Eingeloggten Zustand, wenn man an dem jeweiligen Abschnitt (Section) Editoren-Rechte hat, einen EDIT-BUTTON zu Gesicht bekommt.
Vielleicht könnte man es so arrangieren, dass auch der ganze Bereich "umrahmt" wird, wenn man eigeloggt ist - nicht markant, aber wahrnehmbar.
Das würde den Editoren immer einen guten Überblick über deren  "editierbaren Bereiche" vermitteln.
Normalerweise sind die Backends so vorgesehen (auch wenn sich zwischenzeitlich ein Bug eingeschlichen hatte), dass jeder Abschnitt im Backend ebenfalls einen Anker hat, sodass solch ein Link direkt zu dem Abschnitt im Backend "springen" würde.


Als general Lösung, dürfte die dritte am einfachsten und sogar vom CoreTeam vertretbar sein.

Mir persönlich gefällt aber auch die "mittlere Lösung", die auch Bianca angesprochen hat.
Aber es würde nie ein einheitliches Ding werden, weil nicht jedes Modul das unterstützen würde - also nicht ohne anpassungen.

Edit-in-Place würde für die wenigsten Module überhaupt Sinn machen.
Ich mag die Idee, aber zu utopisch.
(Vielleicht gut für WYSIWYG, aber nur, wenn man adäquate CSS fies für den Editor bereitstellt).


Am meisten gefällt mir die 3te Idee - zum derzeitigen Zeitpunkt.
Mit viel Mühe und Arbeit könnte man eine gute Handvoll Module so überarbeiten, dass sie auch mit der "mittleren Edit in Place" Lösung gut arbeiten. Das aber müßte eine Schulter an Schulter anstrengung sein, und da wir uns hier alle gegenseitig kennen und wissen, wie scharf hier die eigenen "Genialitäten" vertreten werden, wird es nicht kommen.

Aber durchaus kann es sein, dass der eine oder andere das ein oder andere Modul auf diese Weise umsetzt und dann gibt es zumindest einige Module, die das "haben".



Das waren einfach nur ein paar Ideen, die ich mal mitteilen wollte.
Und während ich das schrieb, ist mir auch aufgefallen, wieviele unterschiedliche Ideen man dazu haben kann.

Ich freue mich zu sehen, wer mit der ersten guten Umsetzung kommt.

Stefek

chio:
Danke Stefek, man merkt, dass du dich ebenfalls schon viel mit dem Thema befasst hast.

Wie gesagt habe ich bei Topics 0.6 bereits einen Anlauf gemacht; eher mal zum Testen, wie sich das anfühlt. Über "Theorie" kann man viel reden, und nicht jede gute Idee hält in der Praxis.

"Edit in Place" - ja: Ich habe schon mit CMS zu tun gehabt, in denen das funktioniert. Ist allerdings _sehr_ schwierig anzupassen; das schnell mal gemachte Template gibt es dann nicht mehr. Alles muss genau aufeinander abgestimmt werden.
Sind auch meistens teure Teile (Grundpreis + Anpassung + Wartung)

Frontend-Edit (mit Overlay)
Das macht eigentlich nur dort Sinn, wo schnell mal was geändert werden soll - oder wo Leute was machen sollen, die gar nicht ins Backend sollen.
"Optionen" haben da gar nichts verloren drin. Alles was zu Grundeinstellungen gehört, sollte im Backend bleiben. Damit sind ohnehin schon viele Module _keine_ Kandidaten mehr; eventuell gerade mal Gästebucheinträge löschen/Freischalten kann ich mir vorstellen.
Bei WYSIWYG, News, Topics usw - da funktioniert das gut, da könnte man einfach ein kleines Schalterchen dranhängen, sobald man angemeldet ist.

Was aber sein MUSS: Das Werkel zum Laden des iFrames, Schatten, Kram muss vom Core zur Verfügung gestellt werden. Es kann nicht sein, dass der eine FancyBox verwendet, der andere Colorbox und der Dritte sonstwas.
Es braucht einheitliche Klassen.

Und - was ebenfalls nicht schlecht wäre: Eine einheitliche Art, wie die Unterscheidung Frontend/Backend gemacht werden soll. Bei Topics schleife ich einen Parameter "fredit=1" durch. Wahrscheinlich besser wäre es aber, einen Wert in der $_SESSION zu speichern.

Ich könnte mir auch gut eine Mischform vorstellen: Das eine Modul öffnet im Frontend mit Overlay, das andere geht einfach ins Backend. Warum nicht?

Waldschwein:
Hallo!

Ich versuche mal auf der Basis des neuen Droplets "iEditThisPage" etwas zusammenbasteln - das funktioniert soweit schon recht gut ohne Anpassung, halt nur eben (noch) nicht per Abschnitt. Wenn es mit einem Droplet funktioniert, kann man ja sicherlich auch ein "echtes" Modul machen, wenn es sein soll.
Bestimmt muss es die eine oder andere Änderung im Core geben, aber gut, es ist nicht aller Tage abend.
Dass das Backend dann per jQuery reinfliegt kann evtl. sogar ohne Coreanpassungen funktionieren, mal gucken.
Probleme gibt's bestimmt viele, aber gut, man muss ja auch ein Ziel nach der WB 2.8.2 haben.  :-D

Für Edit in Place - nunja, ich denke, da müsste sehr viel angepasst werden an manchen Modulen. Irgendwie muss man halt einen Kompromiss aushandeln - aber warum muss man zwingend das Backend vollständig außen vor lassen, man kann sich ja Teile davon ins Frontend holen (zumindest, dass es so aussieht).
Sowas wie bei Joomla sollte man auf jeden Fall hinbiegen können, es muss ja vorerst mal nicht (mit WB 2.x eh kaum noch) die Deluxeversion sein.

Edit: Soll natürlich keinen abhalten, selber etwas zu machen, am Ende gewinnt eh das, was gefällt. Und wenn es unterschiedliche Lösungen gibt - umso besser, kann man am Ende sich das Beste aus allem Holen und irgendwie vereinen.

Gruß Michael

Navigation

[0] Message Index

[#] Next page

[*] Previous page