neues GUI für die webedition 6.4 > Grundüberlegungen

In diesem Forum können Wünsche für die Weiterentwicklung von webEdition diskutiert werden.
Gerade bei umfangreichen Änderungen ist es sinnvoll, diese vor einem Eintrag in die Bugbase zu diskutieren. Das Ergebnis kann dann mit Verweis auf den Forumseintrag in die Bugbase eingetragen werden.
Forumsregeln
Bitte achtet hier besonders darauf, nicht abzuschweifen.
Wir werden hier verstärkt moderieren und ggf. Dinge in andere Foren (Smalltalk etc.) auslagern.
ThomasGoebe

neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon ThomasGoebe » Mo 16. Apr 2012, 12:51

Die webEdition 6.4 soll ein überarbeitetes Userinterface bekommen.
In diesem Thread können wir über die Wünsche an solche eine Überarbeitung diskutieren.

Er resultiert aus ersten Diskussionen in der Bugbase in http://qa.webedition.org/tracker/view.php?id=6247.

Also: was schwebt Euch bei einer Änderung der Benutzeroberfläche für webEdition vor? Welche Wünsche gibt es? Was soll auf keinen Fall kommen?

Ich beginne mit einem allgemeinen Ziel:
webEdition soll (noch) browserunabhängiger werden, die Oberfläche soll sowohl für Laien intuitiv erfassbar sein (m.E. der SEE-Mode) als auch für Experten viele Eingriffsmöglichkeiten bieten (Normal-Modus)

Gruß
Thomas

Kane
Junior Member
Beiträge: 6
Registriert: Di 8. Dez 2009, 15:14

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon Kane » Mo 16. Apr 2012, 13:13

Wie schon in der Bugbase geschrieben wäre es wünschenswert, sämtliche iFrames zu entfernen und die GUI komplett durch JS+Ajax Requests zu betreiben. Das spart Resourcen (IFrames laden eigene CSS/JS Files (mehr Requests an den webserver), haben einen kompletten HTML Head usw) und ist schneller als mehrere iFrames zu laden. Mit einem Javascript Framework wird das alles auch problemlos Browserunabhängig.
Beispielsweise Prototype oder jQuery. Wäre sowieso wünschenswert damit zu arbeiten. Dürfte den JS Code ziemlich entschlacken.

Keine Browserfenster Popups mehr, sondern ebenfalls durch Ajax Requests ersetzen. So ist es z.b problemlos möglich, zwei WYSIWYG Editore gleichzeitig zu nutzen. Momentan ist dies nicht möglich. Vor allem wäre es dann möglich, mehrere Tabs gleichzeitig zu bearbeiten.

Dann wäre ein Drag & Drop in den Menüs ein sehr großer Fortschritt. So könnte man z.b. um ein Dokument in einen anderen Ordner zu verschieben, diesen einfach dorthin ziehen anstatt "Datei -> Verschieben -> Ordner auswählen -> Häkchen setzen" durchzuführen.

Dann könnte man zudem die Navigation auch Links als Tab integrieren anstelle des Menüpunktes. Dort könnte man dann genauso das Drag & Drop nutzen um die Menüs umzustrukturieren. So wäre es auch viel einfacher, die Menüpunkte zu sortieren.

Benutzeravatar
Chefpraktikant
Senior Member
Beiträge: 302
Registriert: Do 1. Jan 1970, 02:00
Wohnort: Freising
Kontaktdaten:

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon Chefpraktikant » Mo 16. Apr 2012, 16:22

Die ständigen Reloads vermeiden und gerade durchgeführte Änderungen über AJAX darstellen.
Internetagentur Aysberg • www.aysberg.dewebEdition Partner

mokraemer
Senior Member
Beiträge: 3619
Registriert: So 8. Aug 2010, 01:23
Wohnort: Mainz

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon mokraemer » Mo 16. Apr 2012, 16:37

bzgl. Framework erscheint mir Ext-JS (http://www.sencha.com/products/extjs/) immer noch am geeignetesten.

Aber das sollen die Leute entscheiden, die es implementieren.
webEdition-Kern-Entwickler

WBTMagnum
webEdition Partner
webEdition Partner
Beiträge: 1825
Registriert: Di 7. Mär 2006, 16:50
Wohnort: Wien
Kontaktdaten:

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon WBTMagnum » Di 17. Apr 2012, 10:09

Ein paar Inputs aus unserer Erfahrung zum Thema:

Derzeitige Stärken:
  • Die Baumstruktur (Dokumente/Objekte) ist - meiner Ansicht nach - für die RedakteurInnen gut erfassbar.
  • Das der Bearbeitungsmodus der tatsächlichen Darstellung schon sehr nahe kommt (das hängt natürlich von der Umsetzung der Templates ab).
  • Die Vorschaufunktion.
  • Das Navigationstool ist sehr mächtig. Wenn man das Konzept einmal verstanden hat ;-).
  • Die Fehlerbehandlung/-erkennung hat sich in den letzten Version erheblich verbessert und gibt so schon frühzeitig Hinweise auf mögliche Fehler.
  • Funktionen um mehrere Dokumente/Objekte gleichzeitig zu bearbeiten (verschieben, publizieren, löschen, ...).
Derzeitige Schwächen:
  • Unsaubere HTML/CSS/JS Umsetzung im Backend. Die derzeit verwendeten Tabellen-/IFrame-Konstrukte blasen den Code auf, erschweren die Anpassung ungemein und führen zu unerwarteten Problemen.
  • Der WYSIWYG-Editor ist in vielerlei Hinsicht nicht mehr Zeitgemäß.
  • Die Verknüpfung vom Dokumenten mit der Navigation ist für die RedakteurInnen oft schwer zu verstehen. Das Tool unter "Eigenschaften" ist nicht praktisch und (war zumindest früher) sehr fehleranfällig. Hier eine bessere Integration zu schaffen wäre hilfreich.
  • Das Backend wirkt oftmals langsam und behäbig (bezieht sich auf <= V6.2).
  • Im Reiter Eigenschaften bei Dokumenten/Objekten sind meiner Ansicht nach zu viele Infos für einfache RedakteurInnen untergebracht. Das zu reduzieren bzw. einzuschränken halte ich für sinnvoll.
Weitere Inputs / Wünsche / Ideen:
  • Meiner Ansicht nach braucht es den See-Mode überhaupt nicht. Ich fände es besser, wenn das Backend - entsprechend der Benutzerrolle - anpassbar ist.
  • Bessere Kontrolle über den WYSIWYG-Editor (Stichwort Stile). Das sollte sich mit der Integration eines anderen Editors aber hoffentlich irgendwann von selbst erledigen.
  • Die Suche (von Dokumenten, Objekten, ...) könnte man dahingehend verbessern, dass sie ähnlich wie die Quick-Search (= Filter) vom Thunderbird funktioniert. Dadurch können die RedakteurInnen Inhalte sehr schnell finden.
  • Ein Digital-Assett-Management wäre zumindest eine Überlegung wert.
  • Eine bessere Zugänglichkeit des Backends war mal als ZIel angedacht. Das halte ich noch immer für sinnvoll.

Liebe Grüße,
Sascha

mokraemer
Senior Member
Beiträge: 3619
Registriert: So 8. Aug 2010, 01:23
Wohnort: Mainz

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon mokraemer » Di 17. Apr 2012, 18:02

Hallo Sascha,
ein paar Inputs dazu:
  • WYSIWYG: da arbeitet Lukas gerade an der Integration von tinymce, der dann hoffentlich für 6.3.1 kommt.
  • Backend: die Umsetzung der IFrames etc. hat sich da auch verbessert - ist aber extrem schwer, weil es Bergeweise JS Kode gibt, der bei allen Anpassungen gleich aus der Kurve fliegt. Ich konnte bisher schon einige IFrames auch entfernen, weshalb dann erst auch mal das Neuladen des Menüs (Frame-Reload geht nicht mehr) nicht mehr ging. Leider gibt es auch ein paar Eigenschaften die nur von Frames unterstützt werden: unload bspw. - damit wird der Speichern Dialog realisiert.
  • Eigenschaften: hast du eine Idee dazu? weiterer Reiter? Nur die Basics auf Eigenschaften, der Rest woanders?
  • SEE-Mode: lange Zeit war er kaum benutzbar - denke er ist auch "falsch beworben" worden (ist glaube ich ein Abfallprodukt von weLight gewesen). Für normale Redakteure, die nur ein paar Sachen ändern müssen kann er vermutlich schon einfacher sein als die "volle" Version.
  • Suche: könnte man ggfs. mit etwas JS überlegen - wer machts?
webEdition-Kern-Entwickler

ThomasGoebe

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon ThomasGoebe » So 6. Mai 2012, 16:51

Hallo Sascha,

ein Wort zum SeeMode:
es wird m.E. ein Modus für Laien gebraucht, die mit einem Baum z.B. gar nichts anfangen können. Sollte sich das über Nutzerrollen abbilden lassen - sehr gerne. Dann könnte man letzlich jedem Redakteur eine eigene Oberfläche bauen (Redakteur 1 braucht den Baum, 2 nicht, 1 braucht sidebar, 2 soll die nie sehen, 3 wiederum braucht einen erweiterten Dateiselektor, 4 wiederum nur ein einfaches Auswählen einer Grafik).

Die Frage ist einfach, wie weit lässt sich das wirklich anpassbar machen oder ist es da nicht einfacher, zwei Modi zu nutzen? Dank we:ifSeemode kann man im Moment ja auch sehr gut für für die "einfachen" Redakteure noch zusätzliche Hilfen anzeigen etc.

Gruß
Thomas

excogito
Junior Member
Beiträge: 23
Registriert: Mo 11. Mai 2009, 16:50

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon excogito » Mi 18. Jul 2012, 11:59

- Möglichkeit für Redakteure, im Dokument die Position von Elementen zu verschieben (nicht nur innerhalb von Blöcken)
Beispiel: ein 50/50 Text-Bildbereich, ein dreispaltiger Bereich, ein Nur-Text auf 100% Breite sind im Template angelegt und jeder einzelne kann dann im Dokument vom Redakteur ausgewählt und nach Wunsch um eine Position nach oben oder unten geschoben werden. Gesehen bei campaignmonitor.com bei den vorgefertigten Newsletter-Templates, da geht es sogar per Drag & Drop, was noch toller wäre. Kann man dort übrigens ausprobieren (Kostenlos registrieren, Template anlegen, Newsletter anlegen): die Bearbeitung der Templates, das hochladen von Bildern etc. ist dort überhaupt genial gelöst. Wenn das bei WebEdition so wäre, wäre es unschlagbar.

- Dateien, Objekte, Templates verschieben per Drag & Drop
(Stimme Kane in diesem Punkt voll zu)

- Objektbearbeitung für Redakteure vereinfachen – Optionen ausblenden
die Bearbeitung von Objekten ist für Redakteure deshalb kompliziert, weil er dort zu viele Reiter und Optionen hat, die er zum Teil gar nicht bearbeiten können soll. Hier wäre es super, wenn man in der Benutzerverwaltung noch mehr Elemente für bestimmte Benutzer ausblenden könnte. (Beispiel: Reiter Arbeitsbereich / unter Eigenschaften: Kategorien (manchmal vielleicht nicht erwünscht) / Zeichencodierung / CSS) etc ... ) Das würde die Bearbeitung wesentlich erleichtern.

- Ajax Requests statt Reloads und Popups
(stimme Kane und Chefpraktikant zu)
Carolin Moll, Freiburg

mokraemer
Senior Member
Beiträge: 3619
Registriert: So 8. Aug 2010, 01:23
Wohnort: Mainz

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon mokraemer » Do 19. Jul 2012, 23:27

Aktuell ist eines der Hauptprobleme Leute zu finden, die neben Ihrer Arbeit etwas mitentwickeln.
Der GUI Umbau ist eine tolle Sache und auch eine gute Idee. Stößt nur zusammen mit den Bug-Fixes an die Grenzen dessen was man mal so nebenbei leisten kann. Allein die Integration des neuen wysiwyg-editors hinkt deshalb, weil der alte doch nicht ganz aufgegeben werden soll und derzeit wieder Probleme im IE gefixt werden....

Ich hab ja im Hauptfenster fast alle Frames (bis auf wenige entfernt). Aber auch das ist extrem schwer, weil der ganze bestehende JS Kode darauf aufbaut das die Struktur ist, wie sie ist. Allein durch das entfernen des Frames um das Menü gingen alle Menü-Reloads nicht mehr, in der Folge gab es JS Fehler, die dann ggfs. wiederum dazu geführt haben das sich das Frontend nicht mehr bedienen lies, weil der JS-Interpreter gestoppt hat (und hier reagiert jeder Browser wieder unterschiedlich).
Der GUI Umbau ist schon recht heikel. Man kann auch nicht einfach sagen, wir fangen mal mit dem Hauptfenster an, die Module/Tools kommen später. Denn auch die greifen über Meldungen, schließen von Dokumenten, reloads etc. direkt ins Hauptfenster mit ein.....

Was man vielleicht noch erwähnen sollte - keiner von uns hat bisher mit einem der Frameworks wirklich schon mal eine GUI für eine Applikation entworfen - d.h. man kennt die Fallstricke noch nicht, die ein vorhandenes Desgin über den Haufen werfen könnte.

Ich hoffe ich hab mal einen kleinen Überblick gegeben, warum es so schwierig ist und man nicht eben mal schnell die GUI austauschen kann.
webEdition-Kern-Entwickler

Benutzeravatar
Chefpraktikant
Senior Member
Beiträge: 302
Registriert: Do 1. Jan 1970, 02:00
Wohnort: Freising
Kontaktdaten:

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon Chefpraktikant » Mo 23. Jul 2012, 13:25

Ganz ehrlich: Wenn ich mir Typo3 anschaue oder kürzlich erst eZ Publish muss ich sagen, dass die Oberfläche von webEdition zwar etwas altbacken aber immer noch super intuitiv ist. Auch von Kunden kommt immer wieder die Bestätigung. Also bloß nichts übereilen, wenn keine Ressourcen dafür da sind!
Internetagentur Aysberg • www.aysberg.dewebEdition Partner

mokraemer
Senior Member
Beiträge: 3619
Registriert: So 8. Aug 2010, 01:23
Wohnort: Mainz

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon mokraemer » Di 24. Jul 2012, 00:42

klar, das sollte nicht das Ziel sein!
Ich denke die Grundstruktur etc. soll schon beibehalten bleiben - die große Hoffnung an ein Framework wäre u.a. flüssigere Bedienung, weniger reloads und bessere Browserkompatibilität.
Gerade die alten Frames müssen weg - wer weiß wie lange die noch im Browser unterstützt werden.
webEdition-Kern-Entwickler

excogito
Junior Member
Beiträge: 23
Registriert: Mo 11. Mai 2009, 16:50

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon excogito » Mi 8. Aug 2012, 14:36

Mein erster Feature-Wunsch ( Möglichkeit für Redakteure, im Dokument die Position von Elementen zu verschieben) geht ja schon mit WebEdition-Bordmitteln! (we:block mit we:select für Auswahl der entsprechenden Codeschnipsel, die man darunter mit we:ifVar abfragt. Ist das schon irgendwo dokumentiert? Wo könnte ich den entsprechenden Codeschnipsel für die Community hinterlegen?
Carolin Moll, Freiburg

rkempf
Member
Beiträge: 83
Registriert: Do 6. Jul 2006, 10:36

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon rkempf » Di 4. Sep 2012, 11:43

tinymce ist besser als der Webedition Editor. Die Kunden kommen besser damit zurecht, weil er flexibler ist. Jedoch wünsche ich mir die Verknüpfungsmöglichkeit von Bildern und Dokumenten aus der Datenbank. Es wäre toll, wenn man Bilder und Dokumente über das Menü einbinden und auch schneller Links zuweisen könnte. In der derzeitigen Lösung muss das alles von Hand geschehen, d.h. die Pfade müssen manuell eingetragen werden. Das ist bei vielen Einbindungen mühsam. In der Version 6.3.3. sind auch die Menüpunkte alle in englisch, das war in der Vorversion nicht.

mokraemer
Senior Member
Beiträge: 3619
Registriert: So 8. Aug 2010, 01:23
Wohnort: Mainz

Re: neues GUI für die webedition 6.4 > Grundüberlegungen

Beitragvon mokraemer » Di 4. Sep 2012, 23:42

der Bug (englisch) ist in 6.3.4 behoben - für die Sprache wurde der CSS-Dateiname falsch generiert.
webEdition-Kern-Entwickler


Zurück zu „webEdition Feature Requests“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 10 Gäste