Editor-Entwicklung

[perf]

Und ich hab weder von wgplugin_info noch von topbar_datetime eine Ahnung, so dass ich das nicht hilfreich fixen kann ...

Chris: wgplugin_info soll bleiben, nicht wahr? Fehlt nur im xsd.

/Per

[netzkind]

Hi,
Also scheint es ja an meiner Config zu liegen.

Kannst du mir die zukommen lassen?

[alexbeer]

na klar.

ist im Anhang - einfach .zip der Datei-Extension entfernen.

[netzkind]

Hi Alex,

danke für das Szenario, ist jetzt im SVN gefixt. Hatte was mit Leerzeichen zu tun und einer Fehlinterpretation durch das Javascript-Schema.

[alexbeer]

Hi Julian,
danke für deinen Einsatz. Jetzt kann der Editor aufgerufen werden!

[iwan]

Hallo Zusammen

Ich habe den neuen Editor kurz angeschat.

Hm... ich möchte ja niemenden zu nahe treten, aber mir war der Editor in der Release Version einiges sympatischer.

Wieso das Rad neu erfinden? Habe ich was verpasst?

Ich denke besonders auch an die "reinen" User, das "Drag and Drop", mit 1:1 Preview war schon klasse.

Grüsse
Iwan

[netzkind]

Hm... ich möchte ja niemenden zu nahe treten, aber mir war der Editor in der Release Version einiges sympatischer.

Wieso das Rad neu erfinden? Habe ich was verpasst?

Da stimme ich mit dir grundsätzlich überein.

Aber:
das Frontend der Visu entwickelt sich stetig weiter. Der Editor wurde seit einigen Iterationen nicht mehr darauf angepasst. Es kann nicht das Ziel sein, den Editor jedes mal anpassen zu müssen, wenn an der Darstellung oder dem Programmcode der eigentlichen Visu gearbeitet wurde. Bei einigen der neueren Elementen ist es nicht mal mehr ohne weiteres möglich einen Platz zu finden an dem man die Editor-Elemente unterbringt. Ganz zu schweigen von den unterschiedlichen Designs mit denen es doch bitte auch funktionieren soll ...

Da es aber nicht möglich ist, WYSIWIG getrennt von der eigentlichen Visualisierung umzusetzen (oder man muss ständig alles doppelt pflegen), kann dieser Ansatz nicht nachhaltig verfolgt werden.

Ziel des neuen Editors ist es, vollkommen unabhängig vom Frontend der eigentlichen Visu zu funktionieren.
Das sollte gleichzeitig dazu führen, dass mehr Leute sich dafür interessieren neue Widgets zu programmieren, weil sie nicht mehr an den Editor denken müssen.

Davon unabhängig soll es aber auch im Editor eine Vorschau geben, aber die existiert bislang nur auf der TODO-Liste.

[iwan]

Hallo

OK, dass kann ich gut verstehen und leuchtet mir auch ein.

Wie wäre es damit um das ganze trotzdem etwas Benutzerfreundlicher zu machen:
Links ein Tree wie im Windows Explorer indem die Elemente sind.
Rechts erscheinen dann jeweils die Atribute des selektieren Elementes.

Das heisst konkret:
Das ... Icon wäre das + icon im Explorer.
Die + und - Icons könnten auf der rechten Seite sein oder rechts neben dem Knoten.

Um die "Knoten" etwas eifach zu finden könnet nicht nur typ sondern auch Name dort stehen zb "page (Übersicht)"

Was haltet ihr davon?

Iwan

[Chris M.]

Chris: wgplugin_info soll bleiben, nicht wahr? Fehlt nur im xsd.

In der Demo-Config so so viel wie möglich sein, um
a) komplett zu testen
b) Beispiele für alle Widgets zu haben
=> Alle Widgets sind Pflicht und möglichst alle Plugins sollten vertreten sein
(Es muss aber auf allen Geräten Out-of-the-Box laufen; bei einem Ich-binde-meine-Telefonanlage-an-Plugin wird's schwierig)

Die richtige Lösung ist, dass das alles in die XSD gehört.
Wenn's nicht drinnen ist, darf's aber auch nicht in die Demo-Config - denn die sollte immer valide sein!

aber mir war der Editor in der Release Version einiges sympatischer.

Jain

Grundsätzlich fallen mir zwei Arten einer möglichen Editor-Realisierung ein:

1. Intern (wie im letzten Release)
2. Extern (wie in der aktuellen Entwicklung)

Beide haben Vor- und Nachteile. Daher wäre es schön, wenn man beide parallel hat.


Julians Entscheidung nun auf einen externen zu gehen, kann ich absolut nachvollziehen.
Evtl. lässt der sich so erweitern, dass neben dem Tree-View in einem anderen [I]Frame die Visu angezeigt wird, ggf. synchronisiert.
=> Sollte schon deutlich intuitiver sein.


Wenn man dann noch ein interaktives Umsortieren hinbekommt (besonders mit den neuen Gruppen eine Herausforderung!), dann dürfte man dem Optimum schon sehr nahe sein.

(Gerne auch erst zum übernächsten Release, da können wir etwas Druck heraus nehmen)

[Chris M.]

Hab nun mal den neuen Editor probiert:

Sicher noch deutlich zu Früh, da wohl aktuell erst mal die Funktionalität im Vordergrund steht, hätte etwas Wünsche/Anregungen beim UI-Design:

Aktuell finde ich das etwas unübersichtlich. Neben dem "unterbrochenen" Tree des Tree-View finde ich da das Auf- und Zuklappen nicht intuitiv. Und durch die Unterbrechungen finde ich, verliert man den Kontext bzw. Überblick.

=> Vorschlag wäre das UI zweiteilen:
Links den TreeView und rechts die Attribute (vergleichbar Windows Explorer, eMail Clients, ...)

Und wenn man das mit der Visu als Vorschau / Kombination mit einem (abgespeckten) internen Editor hinbekommt dann könnte man das ganze dreiteilen:
Links oben: Tree-View
Links unten: Attribute des aktuellen Knoten
Rechts: Visu
(Links wäre schmal, rechts breit)

Der jetzige Stand ist aber schon eindrucksvoll!

[netzkind]

Das bisherige Design ist grundsätzlich dem Gedanken geschuldet, dass der Editor auch auf mobilen Endgeräten mit kleinem oder hochformatigem Bildschirm funktionieren soll. Entsprechend kam eine Aufteilung des Bildschirms erst mal nicht in Frage.

In der Ideenschublade steckt aber noch eine Stichwortsuche in Form eines Filters für den Editor, damit sollte das Auffinden des richtigen Elements wesentlich vereinfacht werden.

Ich kann mir vorstellen noch einen Hybriden zu finden, der bei Vorhandensein von ausreichend screen estate noch mehr Baumstruktur anbietet.

Grüße,
Julian

[netzkind]

Evtl. lässt der sich so erweitern, dass neben dem Tree-View in einem anderen [I]Frame die Visu angezeigt wird, ggf. synchronisiert.
=> Sollte schon deutlich intuitiver sein.

Auch das steckt schon in der Ideenschublade, hängt aber von der Performance ab, und ob wir eine saubere, dauerhafte (im Sinne von regression-fest) Schnittstelle vom Editor zur Visu hinbekommen.

Wenn man dann noch ein interaktives Umsortieren hinbekommt (besonders mit den neuen Gruppen eine Herausforderung!), dann dürfte man dem Optimum schon sehr nahe sein.

Was genau meinst du hier mit "interaktiv"?

[JuMi2006]

Darf ich mal kurz einhaken:

 Error: 'xsd does not match this configuration, or configuration is not valid for #text'

Macht nicht besonders schlau da mir check_config sagt dass alles gut ist. Gibt es da einen Anhaltspunkt ?

.xls -> .xml

[netzkind]

Aktuell finde ich das etwas unübersichtlich. Neben dem "unterbrochenen" Tree des Tree-View finde ich da das Auf- und Zuklappen nicht intuitiv. Und durch die Unterbrechungen finde ich, verliert man den Kontext bzw. Überblick.

OK, kann ich nachvollziehen.

=> Vorschlag wäre das UI zweiteilen:
Links den TreeView und rechts die Attribute (vergleichbar Windows Explorer, eMail Clients, ...)

Und wenn man das mit der Visu als Vorschau / Kombination mit einem (abgespeckten) internen Editor hinbekommt dann könnte man das ganze dreiteilen:
Links oben: Tree-View
Links unten: Attribute des aktuellen Knoten
Rechts: Visu
(Links wäre schmal, rechts breit)

Das geht in eine vergleichbare Richtung zu dem was Iwan schon schrieb. Das Feedback verpufft bei mir nicht, sondern fließt mit in die weitere Entwicklung ein.

Ich werde mal schauen, wie ich mir das technologisch vorstellen kann

[netzkind]

Darf ich mal kurz einhaken:

 Error: 'xsd does not match this configuration, or configuration is not valid for #text'

Macht nicht besonders schlau da mir check_config sagt dass alles gut ist. Gibt es da einen Anhaltspunkt ?

Das #text hatte ich da heute erst eingebaut als Ergebnis des Threads zum Thema mixed-content. Ich schau mir das mit deiner Config noch mal an.