Ankündigung

Einklappen
Keine Ankündigung bisher.

Editor-Entwicklung

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Chris M.
    antwortet
    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!

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    Zitat von perf Beitrag anzeigen
    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!
    Zitat von iwan Beitrag anzeigen
    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)

    Einen Kommentar schreiben:


  • iwan
    antwortet
    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

    Einen Kommentar schreiben:


  • netzkind
    antwortet
    Zitat von iwan Beitrag anzeigen
    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.

    Einen Kommentar schreiben:


  • iwan
    antwortet
    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

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • netzkind
    antwortet
    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.

    Einen Kommentar schreiben:


  • alexbeer
    antwortet
    na klar.

    ist im Anhang - einfach .zip der Datei-Extension entfernen.
    Angehängte Dateien

    Einen Kommentar schreiben:


  • netzkind
    antwortet
    Zitat von alexbeer Beitrag anzeigen
    Hi,
    Also scheint es ja an meiner Config zu liegen.
    Kannst du mir die zukommen lassen?

    Einen Kommentar schreiben:


  • perf
    antwortet
    Zitat von netzkind Beitrag anzeigen
    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

    Einen Kommentar schreiben:


  • alexbeer
    antwortet
    Hi,

    getestet mit
    • Firefox 16.0.2
    • Chrome 23.0.1271.64 m
    • Safari iOS5

    Überall das selbe Ergebnis.
    Mit der Config "Metall" sehe ich zumindest den Editor... Also scheint es ja an meiner Config zu liegen.

    Habe da lediglich ein paar Mappings hinzugefügt - sonst alles Standard.

    Einen Kommentar schreiben:


  • netzkind
    antwortet
    Morgen,

    Zitat von alexbeer Beitrag anzeigen
    Was mache ich da falsch?
    Welchen Browser nutzt du denn?
    Beim Entwickeln wurde getestet auf Firefox und (stellvertretend für Webkit-Browser) Chrome.

    Einen Kommentar schreiben:


  • alexbeer
    antwortet
    Guten Morgen,
    Habe gerade auf rev 1164 upgedatet.
    Bekomme sowohl bei der Demo, als auch meiner eigenen Config folgende Fehlermeldung vom Editor:
    The configuration appears to be not valid. Please check with 'check_config.php' for details. Error: 'schema/xsd appears to be invalid, complexType "meta" can not be found'
    Check_config.php gibt meine Config als valide aus.

    Was mache ich da falsch?

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    Das mag sein, aber das Problem ist nicht, dass das topbar_datetime oder gar strftime in die Config hinzugefügt wurde - sondern dass der XSD nicht gesagt wurde, dass es das jetzt geben kann...

    Einen Kommentar schreiben:


  • hannes loehr
    antwortet
    Guten Morgen,

    ich habe den ganzen Strang hier nicht ganz verfolgt. Aber beim Stichwort nicht valide Config fällt mir ein, dass ich vor ein paar Wochen ein Beispiel für strftime auf der erweiterten Beispielpluginseite eingebaut hatte. Vielleicht bin ich hier dann der Schuldige

    Einen Kommentar schreiben:

Lädt...
X