Flavour und Class

[Chris M.]

Das das Thema Flavour noch nicht richtig verstanden wurde hatte ich immer schon befürchtet und sehe es im aktuellen Thread bestätigt. Also hier ein kleines Posting, was schon jetzt geht und wo's evtl. hin gehen sollte.

Stand jetzt ist die Philosophie die, dass der Design-Designer alles festlegt, inkl. gewisser Variabilitäten, aus denen der Anwender aussuchen kann:
Das <styling> ist wohl gut bekannt, da kann der Anwender vom Designer festgelegte Farben auf Werte mappen. (Wieso vom Designer festgelegt? Nun ein hartes Rot wie #ff0000 mag sich bei einer Visu im oragnenen Stil beißen, aber es wird sicher eine Rot-Variante geben, die passt).
Außerdem gibt es noch das Flavour (aktuell wohl nur im Design Pure umgesetzt), mit dem sich der Stil einer ganzen (Sub-)Seite ändern lässt. Man könnte so alle Gemeinschaftsräume Weiß, alle individuellen Zimmer Gelb, die Heizungsanlage Rot, den Garten Grün, ... wählen, so dass beim Blick auf die Seite sofort klar ist, worum es geht.
Poweruser können bei allem schon jetzt das Design übersteuerern durch die custom.css...

Bei den beiden aktuellen Threads kam heraus, dass dies nicht ausreicht, sondern dass Bedarf besteht feingliedriger Sub-Stile für Groups oder gar Widgets festzulegen.

Individuell eingefärbte Icons hatte ich da schnell verstanden, da wäre es nur konsequent diesen ein (optionales) Flavour Attribut mit zu geben.

Und wenn man da schon dabei ist, kann man das gleich verallgemeinern und allen Widgets ein Flavour-Attribut spendieren, dass, wenn gesetzt, das Flavour der Seite dort übersteuert.
=> Ich bin dafür

Nun kam auch noch die Idee der Classes auf, zu dem ich mich auch schon positiv geäußert habe. Dass damit nun auf zwei Arten das gleiche implementiert wird, sehe ich so nicht - im Gegenteil, ich finde das ergänzt sich wunderbar!

Classes erlauben denen, die es können, leicht eine starke Individualisierung ohne weitere Struktur zu beschädigen. Da die allerdings eher wie ein Freitext-Feld zu sehen sind, erkauft man sich die Freiheit durch eigene Verantwortung.
Und genau da helfen die Flavours - hier kann auch ein Anfänger leicht etwas umstellen, dass der Design-Entwickler so extra dafür freigegeben hat. Ohne HTML und CSS Kenntnisse!

=> Ich bin für beides, gleichzeitig!
Und eine bessere Doku mit Erkläung der Flavours...

PS: Die Flavour-Namen des Pure-Designs haben einen gewissen Sinn: es sind die Flammfärbungen dieser Materialien. Ich fand das passend zum Thema Kometen-Schweif... Andere Designs dürfen gerne andere Namen für die Farben finden.
PPS: Optimaler Weise macht der Editor beim Flavour-Attribut eine Dropdown-Liste. Wie man diese "Sonderlocke" bei diesem speziellen Attribut geschickt und zukunftsfähig umsetzt wäre ein TODO

[daviid]

Full ACK


Noch ne Frage zu meiner dirty Zwischenlösung zum benutzen der orangenen Icons.
Es gibt doch atm keinen anderen Weg als dießen, oder?

Außer das Hier

Aber das ist wenn man das für Alle Icons gemacht genauso blöd, find ich.



Ich versuch mich nacher mal in den Code ein zu arbeiten um zu verstehen wie man den icons auch nen flavour verpassen kann, ob ichs versteh ist ne andere Sache

[Chris M.]

Na, Stand jetzt geht's noch nicht. D.h. für Deine lokale Kopie IMHO i.O. - aber im Repository find ich's zu gefährlich als dass hier der falsche Weg bereitet wird...

[MicHau]

Das Provisorium ist entfernt. Man kann nun beim <icon>-Tag das Flavour-Attribut setzen. Die Icons aus dem Verzeichnis "icon/knx-uf-iconset/128x128_or/" sind unter dem Flavour "sodium" verfügbar.

Von alter Config

  <meta>
    <icons>
      <icon-definition name="LichtOn" uri="./icon/knx-uf-iconset/128x128_or/licht_licht.png" style="height:2em;"/>
      <icon-definition name="LichtOff" uri="./icon/knx-uf-iconset/128x128_ws/licht_licht.png" style="height:2em;"/>
      <icon-definition name="AutoOn" uri="./icon/knx-uf-iconset/128x128_or/zeit_automatik.png" style="height:2em;"/>
      <icon-definition name="AutoOff" uri="./icon/knx-uf-iconset/128x128_ws/zeit_automatik.png" style="height:2em;"/>
    </icons>
    <mappings>
      <mapping name="OnOff_Licht">
        <entry value="0"><icon name="LichtOff"/></entry>
        <entry value="1"><icon name="LichtOn"/></entry>
     </mapping>
      <mapping name="OnOff_Auto">
        <entry value="0"><icon name="AutoOff"/></entry>
        <entry value="1"><icon name="AutoOn"/></entry>
     </mapping>
    </mappings>
  </meta>

zu neuer Config

  <meta>
    <mappings>
      <mapping name="OnOff_Licht">
        <entry value="0"><icon name="licht_licht" flavour="white"/></entry>
        <entry value="1"><icon name="licht_licht" flavour="sodium"/></entry>
     </mapping>
      <mapping name="OnOff_Auto">
        <entry value="0"><icon name="zeit_automatik" flavour="white"/></entry>
        <entry value="1"><icon name="zeit_automatik" flavour="sodium"/></entry>
     </mapping>
    </mappings>
  </meta>

[daviid]

Cool, sehr nice.

[makki]

Sorry, ich komm da grad nicht hinterher (obwohl ich glaube das es genau das ist, wovon ich schon immer träume )
-> ich fände es toll wenn für sowas eine (eigene) Demo-config mit ins SVN wandern würde, mit passendem Design, Stylings, Flavours etc - so wie man es eben gemeint hat.. (hat man ja vermutlich eh..)
Kann man später immernoch mergen..

Makki

[MicHau]

ich fände es toll wenn für sowas eine (eigene) Demo-config mit ins SVN wandern würde, mit passendem Design, Stylings, Flavours etc - so wie man es eben gemeint hat..

Ich habe die farbigen Icons mal in der Metal-Demo eingebaut unter KNX=>Wohnzimmer=>Licht mit Icons

[peuter]

Ich habe Flavour jetzt auf Widget-Ebene implementiert, d.h. jedes Widget kann mit einem eigenen flavour versehen werden.

Aktuell werden im Metal-Design jedoch nur slider (Hintergrundfarbe) und groups (Rahmen + Hintergrund der Überschrift) durch ein flavour optisch verändert. Bei allen anderen Widgets sehe ich keine sinnvolle, allgemeingültige und optisch ansprechende Vorgabe für eine farbliche Designveränderung. Da ich mal gelernt habe mit Farben beim GUI-Design vorsichtig umzugehen, werde ich in der Richtung wohl auch nicht mehr viel ändern.

In der Metal-Config gibts eine Beispielseite für die vorhandenen flavour, da kann man sehen wie das dann aussieht.

[makki]

Cool!

Mit demo sieht man auch von was ihr sprecht
Die SVN-Demo (dank an Bodo!):
CometVisu Live-Demo SVN
inkl. demo-configs versuche ich übrigens nun auch wieder aktuell zu halten:
CometVisu Metal-Demo

Makki

[MicHau]

Ich habe Flavour jetzt auf Widget-Ebene implementiert, d.h. jedes Widget kann mit einem eigenen flavour versehen werden.

Super, sieht echt gut aus.
Ich habe mich ja nun mit den Flavours angefreundet , insbesondere nach der obigen Implementierung durch Tobias, denn jetzt kann man sie so einsetzen, wie ich es mir anfangs vorgestellt hatte.

Nun kam auch noch die Idee der Classes auf, zu dem ich mich auch schon positiv geäußert habe. Dass damit nun auf zwei Arten das gleiche implementiert wird, sehe ich so nicht - im Gegenteil, ich finde das ergänzt sich wunderbar!

Classes erlauben denen, die es können, leicht eine starke Individualisierung ohne weitere Struktur zu beschädigen. Da die allerdings eher wie ein Freitext-Feld zu sehen sind, erkauft man sich die Freiheit durch eigene Verantwortung.
Und genau da helfen die Flavours - hier kann auch ein Anfänger leicht etwas umstellen, dass der Design-Entwickler so extra dafür freigegeben hat. Ohne HTML und CSS Kenntnisse!

Aber ich sehe dennoch flavours und classes äußerst dich beisammen. Niemand wird gehindert, den gleichen Freitext aus classes auch in flavours einzutragen, z.B. "myOwnDesign". Ob er nun in der custom.css ".custom_myOwnDesign" oder ".flavour_myOwnDesign" definiert, ist jawohl Jacke wie Hose. Da kommt genau das gleiche dabei raus. Ich kann echt beim besten Willen keinen Unterschied erkennen. Aber vielleicht übersehe ich ja auch was. Ich lasse mich gerne aufklären.

[netsrac]

Aber ich sehe dennoch flavours und classes äußerst dich beisammen. Niemand wird gehindert, den gleichen Freitext aus classes auch in flavours einzutragen, z.B. "myOwnDesign". Ob er nun in der custom.css ".custom_myOwnDesign" oder ".flavour_myOwnDesign" definiert, ist jawohl Jacke wie Hose. Da kommt genau das gleiche dabei raus. Ich kann echt beim besten Willen keinen Unterschied erkennen. Aber vielleicht übersehe ich ja auch was. Ich lasse mich gerne aufklären.

Prinzipiell hast Du ja recht....für mich ist es viel mehr die Psychologie dahinter - ein Flavor wäre für mich immer auf die ganze Seite bezogen, eine Class immer auf einzelne Elemente.

Klar kann man das nun auch über's Flavor "tweaken", aber letztendlich könnte man ja alle stylings darüber machen (z.B. align) und das gibt es ja auch als extra Parameter :-)

Ich will nicht an "meiner" Idee der "Classes" festhalten, wenn die Allgemeinheit das nicht braucht. Solange ich in der Lange bin, irgendwie mein Layout so anzupassen, wie ich es brauche, ist mir das egal...

Gruß, Netsrac

[makki]

Ich sehe das ähnlich wie Chris: wenns einen Fall dafür gibt, macht es Sinn..
Im aktuellen Editor tun solche Locken nicht mehr so weh, also was solls..

Makki

P.S.: Wie der geneigte Leser weiss, lege ich nur auf Funktion&Bedienbarkeit Wert, jegliche Optik die über 1D hinausgeht halte ich für schnickschnack (oder NBF) aber meine Meinung ist inbs. bei entusiastischen Visu-Neulingen nicht mehrheitsfähig - und ich freue mich, wenn sich da andere mit mehr Detailliebe einbringen!
Auch wenn ihr das in 3J anders sehen werdet

[jensgulow]

@ alle:

Kann es sein, dass die Flavours hier:

CometVisu-Client

bei den Slidern irgendwie nicht funktionieren. Habe mir das Ganze schon auf drei Rechnern angeschaut. Überall finde ich nur die "sodium" Hintergründe bei allen Slidern.

Jens

[netsrac]

Nach langer Zeit mal wieder ein SVN Update gemacht und festgestellt, dass "meine" Classes dem Rotstift zum Opfer gefallen sind.

Ist der offizielle Weg also nun, das über die flavors zu machen?! Will eigentlich ungerne auf die Möglichkeiten, die man damit hatte verzichten...


Gruß, Netsrac

[netsrac]

Vergesst es...meine doofheit. Hatte das customs.css nicht mit rüber kopiert. Kaum ist es da, funktioniert es auch wieder :-)