Entwickler Unterstützung gesucht - Release-Vorbereitung

[makki]

Also meine Ansicht - bitte nicht als Kritik oder letzte autoritative Meinung speichern - ist:
Es gibt ein Release, das ist sehr stabil und gut! Und das möchte ich im Sinne der Anwender beibehalten, die "einfach nur ein paar Schalter" auf der Visu - mit geringstmöglichem Aufwand - haben wollen (zu dieser Zielgruppe gehöre ich, die 5 Grafiken kann ich mir als iframe einbinden, auch wenns mit Flot natürlich schöner geht)
Das sind die 99% die nicht laut schreien..

Wartungs-Aufwand? =0 Es gab keinen Grund, groben Bug o.ä. da seit ewig was zu drehen (das spricht ausdrücklich für die CV!)

Das nächste wird (teils zu meinem Leidwesen, auch keine Kritik sondern wenn bitte nur Anregung wo man hin will?!) eher ein Malprogramm, wo man mit colspan, rowspan und groups sich die dollsten Sachen machen kann.. Aber gezwungen wird zu "malen". Ist schön, Anwenderwunsch, ganz klar, kommt beim NBF und beim Geek besser an, finde ich auch schön - ist mir *persönlich* aber schon viel zu aufwändig!

Bis wir die goldene Mitte zwischen Visu-malen und meinem Traum vom Auto-Layout gefunden haben, bin ich ganz klar für zwei Versionen, beim jetzigen Release 0.6 gibts wenig zu pflegen, das geht hundertfach, gibt aber halt keine neuen Features.. Gut, ist halt so.
Der überwiegende Wunsch der stillen Mehrheit, die sowas dutzendfach im Feld haben (und damit der Mehrheit der zahlenden Kunden, denn die wollen möglichst wenig Aufwand zahlen müssen) ist jedoch schnelle Einrichtung und einfache Wartbarkeit, darauf konzentriere ich mich dann
Wobei ich ja durchaus was mitnehme, von dem tollen was ihr da macht! Nur so eine config für ein Metal-Design, ganz ehrlich, da braucht man ein freies WE oder so, das war nie mein Ziel, den HS als Sehenscheidentzünder abzulösen

Makki

[Chris M.]

Zitat von makki Das nächste wird (teils zu meinem Leidwesen, auch keine Kritik sondern wenn bitte nur Anregung wo man hin will?!) eher ein Malprogramm, wo man mit colspan, rowspan und groups sich die dollsten Sachen machen kann.. Aber gezwungen wird zu "malen". Ist schön, Anwenderwunsch, ganz klar, kommt beim NBF und beim Geek besser an, finde ich auch schön - ist mir *persönlich* aber schon viel zu aufwändig!

Das ist, glaub ich, der Punkt, der noch nicht wirklich angekommen ist: auch aktuelles SVN ist kein zwingendes Malprogramm!
Wenn Du willst, kannst Du, klar - aber wenn Du nicht willst, geht's genau so wie vorher.

Keine colspan und rowspan definiert? Wunderbar, dann macht er das Widget genau eine halbe Seite breit (wie war das noch mal unter 0.6.x? ...)

Meine persönliche Test-Seite für's SVN sieht genau so aus, wie meine täglich genutzte Test-Seite des 0.6 Release - es ist meine persönliche Visu an der Wand und die Config-Dateien sind quasi identisch. (Ich war nicht mal so artig die readonly/writeonly zu übersetzen...)

=> Wenn ein automatisches Skript die Config-Datei übersetzt (und das brauchen wir IMHO zwingend), dann wird ein Anwender den Wechsel nur durch den anderen Editor merken.

Die Zeit einer Visu-Erstellung und Pflege ist bei gleichem Visu-Umgang (d.h. wenn man die neuen Design-Möglichkeiten nicht nutzt) identisch (Annahme: Bedienzeit zwischen altem und neuem Editor ist sehr ähnlich)

[henfri]

Hallo Chris,

ich glaube, du überschätzt da einen großen Teil der Anwender:
Ich kenne viele, die sich beim aktuellen Editor -und das soll wirklich keine Kritik sein- umdrehen und gehen würden.
Das ist einfach nix für die, weil's nach "Programmieren" riecht. Und für die -die Makki ja auch anspricht- wird der alte Editor benötigt.
Dazu hatte ich hier ja einen Vorschlag gemacht:

Zitat von henfri Eine andere Möglichkeit: Kann man nicht den alten WYSIWYG Editor weiter nutzen? Damit kann man die neuen Features zwar nicht nutzen, aber sonst... Das hätte den Vorteil, dass man nicht mehrere Codes im Umlauf hat. Dann gäb es auch nur eine Doku, in der dann einmal der WYSIWYG Editor beschriben wird und einmal der neue. Nachteil: Es müssten Features als "Expertenfeatures" dokumentiert werden (eben alles neue, was mit WYSIWYG nicht geht). Andererseits: Die "light" Version wird ja v.a. von Leuten benutzt werden, die nicht so auf Handbücher stehen ;-)

Gruß,
Hendrik

[Bodo]

Hoi

Das sehe ich genau so. Der alte Editor sollte erhalten bleiben, sozusagen als Einstieg.

[Chris M.]

Zitat von henfri ich glaube, du überschätzt da einen großen Teil der Anwender: Ich kenne viele, die sich beim aktuellen Editor -und das soll wirklich keine Kritik sein- umdrehen und gehen würden. Das ist einfach nix für die, weil's nach "Programmieren" riecht. Und für die -die Makki ja auch anspricht- wird der alte Editor benötigt.

Ich bin mit der Usability vom neuen auch noch nicht glücklich - hab ich auch schon im Editor-Thread geschrieben - sehe das aber noch also Work-in-Progress an und das Potential, da deutlich nachlegen zu können.
Der zugrunde liegende Ansatz ist auch richtig - auch wenn ich der Meinung war mit dem bestehenden es auch hinbekommen zu können. Das sind aber Programmier-Philosophische Beweggründe und beide haben ihre Berechtigung.

Zitat von henfri Dazu hatte ich hier ja einen Vorschlag gemacht: Eine andere Möglichkeit: Kann man nicht den alten WYSIWYG Editor weiter nutzen?

Das wäre auch mein Wunsch - aber der alte Editor hat die Config-Dateien definitiv beschädigt, sobald neue Features drinnen waren. Wie bekommt man das einem Anwender erklärt?

Geben wir dem neuen Editor doch noch etwas Zeit. Das sonstige Release ist ja unabhängig vom Editor - und hier habe ich bisher noch nichts gehört, vgl. mein Ursprungsposting. D.h. wenn das so weiter geht, wird es noch sehr lange dauern, bis es kommt...

PS: Editor Milestone 4 (der nächste) spricht von:

- preview for a selected node without the need of replacing the configuration on the server

[MicHau]

Zitat von Chris M. Das sonstige Release ist ja unabhängig vom Editor - und hier habe ich bisher noch nichts gehört, vgl. mein Ursprungsposting. D.h. wenn das so weiter geht, wird es noch sehr lange dauern, bis es kommt...

Ich nehme an, du spielst darauf an:

Zitat von Chris M. Somit würden wir als nächstes Richtung Freeze der internen Strukturen schauen - und genau da sehe ich noch Handlungsbedarf! [HILFE]Ich such Unterstützung beim Aufräumen und polieren (neudeutsch: Refactoring) der internen Strukturen![/HILFE] So ist z.B. die templateenginge.js inzwischen sehr "gewachsen". Mit der der hatte ich damals angefangen, als ich noch nicht sonderlich viel über JavaScript Internas wusste... (Der iconhandler.js ist da schon deutlich weiter - und JavaScript Profis wissen sicher nochmals deutlich mehr)

Ich biete meine Hilfe gerne an, bin aber alles andere als eine JavaScript Profi. Ich würde mich als Script-Anfänger mit Profi-Knowhow in Nicht-Script-Sprachen bezeichnen. Wenn mir jemand auf die Sprünge hilft, was da genau wo zu ändern wäre bzw. was aktuell nicht geschickt gelöst ist, kann ich mich damit auseinander setzen (learning-by-doing hat bisher noch immer funktioniert).

[Chris M.]

Zitat von MicHau Ich nehme an, du spielst darauf an:

Ja

Zitat von MicHau Ich biete meine Hilfe gerne an, bin aber alles andere als eine JavaScript Profi. Ich würde mich als Script-Anfänger mit Profi-Knowhow in Nicht-Script-Sprachen bezeichnen. Wenn mir jemand auf die Sprünge hilft, was da genau wo zu ändern wäre bzw. was aktuell nicht geschickt gelöst ist, kann ich mich damit auseinander setzen (learning-by-doing hat bisher noch immer funktioniert).

Das klingt schon mal sehr gut - wenn leider auch nicht perfekt. Denn da bin ich auch gestartet und habe so etwas wie die templateengine.js verbrochen...

Ziel wären saubere Strukturen (wie z.B. im iconhandler.js oder Editor).

Punkte die gemacht werden müssten und sollten:

• Umstellen der templateengine.js auf saubereres Objekt, dass den globalen Namensraum nicht mehr verpestet
• Ggf. modulatisiern der templateengine - d.h. das gewachsenes identifizieren, dabei ggf. Gemeinsamkeiten zusammenfassen und ggf. auslagern, wenn sinnvoll
• Grundsätzlich immer ein Auge auf effiziente Strukturen haben
• Mal die ganze Anwendung profilien und nach Bottlenecks suchen (alleine das identifizieren ist schon viel wert!) (*)
• Die ganzen Widgets mal durchforsten, ob man da nicht auch mehr Code vereinheitlichen und ggf. Auslagern kann (d.h. den bestehenden Weg einfach weiter gehen)

Ich denke der letzte Punkt ist mit allgemeinem Programmier-KnowHow gut machbar. Der davor wohl auch.
Bei den Punkten der templateengine sollte man wissen, wie JavaScript tickt, d.h. erst mal bestehenden, guten Code wirklich verstanden haben. Die Sprache ist erstaunlich komplex und anders, dafür dass die sich optisch wie C / C++ / Java tarnt.

--
(*): Dabei wichtig zu wissen: Zum Release werden die Dateien zusammengefasst und Minimized. D.h. die reine Ladezeit ist hier nicht so wichtig. Aber sind die DOM-Updates geschickt? Muss der zwischendrinnen einen Reflow oder gar einen Redraw machen? Etc. pp. - das ist spannend.

[makki]

Zitat von Chris M. Das ist, glaub ich, der Punkt, der noch nicht wirklich angekommen ist: auch aktuelles SVN ist kein zwingendes Malprogramm!

Doch schon, ich benutze die CV (mal von der Demo abgesehen) selbst auch ausschliesslich so.. Nur beschleicht mich das Gefühl, das erheblich mehr in das Thema "Malprogramm in 1D/2D/3D" fliesst, als in das IMHO eigentliche "Killerfeature" der CV: "just do it"
Ich würde mich da sogar reinhängen, hab allerdings die Angst immer was vom "Malprogramm" kaputt zu machen (meine Meinung ist immernoch: jQuery-UI, Themes, keinerlei Layout in Code oder config!)

Natürlich kommen so Sachen die - mit beliebig hohem Aufwand - toll aussehen besser im Auge an, aber da bin ich nach 20J IT zu nüchtern für und suche eher die technisch richtige Lösung
Weil spätestens übermorgen will ich das die Visu aus dem ETS-Export fällt

Makki

[swiss]

Hmmm...

Naja so schlimm finde ich das "malen" mit der CV nicht. Der Aufwand ist wesentlich geringer als beim HS. Dazu kommt, dass ich die Funktion Rowspan sehr schätze. Was mich nämlich bei der Releas immer gestört hat war, dass wenn man ein paar Slider und Switch auf einer Seite plazierte sehr schnell an den Punkt kam wo man scrollen musste. Und ich hasse scrollen in einer Visu. Nun kann ich auch viele Steuerelemente übersichtlich anordnen und brauch nicht zu scrollen.

-> Scrollen in einer Visu ist für mich ein ein NoGo. Dann lieber einmal Sehnenscheidenenzündung und dann dafür aber eine gut bedienbare Visu.

[Chris M.]

Das malen hat ja noch nicht mal richtig angefangen, dass kommt erst mit den 2D Seiten (die Heizungs-Seite ist die einzige in der "freien Wildbahn" die ich da kenne...).
Und Malen ist ein Seegen gegenüber dem Konstruieren, dass man für die 3D Seiten brauchen wird...

Text-Seiten werden immer Just-do-It und für Skripte, etc. da sein. Nutzt man die ohne colspan, sind die auch 100% kompatibel zum Release. Und selbst mit colspan und group sind die ratz fatz gebaut - auch per Skript.

Dass mehr Aufwand in's Eye Candy fließt ist vollkommen klar:

• der einfache Text-Modus ist schon weitestgehend fertig
• das Eye Candy hat Nachholbedarf
• das ist komplexer und braucht dafür einfach mehr

Kaputt machen kann man da auch nicht viel. Zumindest wenn man an den Nicht-Design-Elementen dreht. Die Designs haben so robust zu sein, dass die das abkönnen.