Slider - Range-Option funktioniert

[JuMi2006]

Naja ... zweigeteilte Meinung:

Ich denke dass Vorder- und Hintergrund der Widgets dem Design "gehören".
Der Autor hat sich was dabei gemacht, sich mühe gegeben und aufeinander abgestimmt. Irgendwann hat ein einfacher slider dann 156 Klassen und Attribute ... so wird der Editor nie fertig, die Übersicht geht verloren und das "Bauen" der Visu wird nervig.

Andererseits finde ich die Freiheit mit slider-range, dots, stylings schon gut und nötig. Neue Farben kann man ja wirklich in der custom.css anlegen ... wenn unbedingt einer was am Design ändern will bekommt er das auch hin, das ist wirklich simpel. Hierfür müsste sich aber z.B. slider-range die Farbe nicht aus einer separaten Class holen sondern aus einer der (neu definierten) Standardfarben.

Versteht Ihr mich ?

[MicHau]

Neue Farben kann man ja wirklich in der custom.css anlegen ... wenn unbedingt einer was am Design ändern will bekommt er das auch hin, das ist wirklich simpel.

Ich halte das für einen Normalanwender nicht für simpel. Für uns "Versteher" klappt das ohne größeren Aufwand, aber wir bräuchten auch keinen Editor. Trotzdem wird einer für die Normalanwender benötigt und implementiert.

Der Autor hat sich was dabei gemacht, sich mühe gegeben und aufeinander abgestimmt.

Da stimme voll zu, nichtsdestotrotz sehe ich die Notwendigkeit, bestimmte Elemente der Visu farblich vom Rest abzuheben.

Und ich sehe gerade in diesem Thread, dass dort genau ein solcher Bedarf auch festgestellt und entsprechendes implementiert wurde. Allerdings muss man da auch noch mit CSS hantieren, was ich für einen Normalanwender für nicht tauglich halte.

Ich hätte mir ähnlich zu dem <layout>-Tag ein nennen wir es mal "color-customizing"- oder "design-customizing"-Tag vorgestellt, in dem man bestimmte vorgegebene Werte für ein Element verändern kann. Alternativ könnte man Definitionen im Meta-Bereich einführen, die dann beliebig verwendet werden können.

[JuMi2006]

Und ich sehe gerade in diesem Thread, dass dort genau ein solcher Bedarf auch festgestellt und entsprechendes implementiert wurde.

Das meinte ich mit 154 Classes und Attribute, wer soll das dokumentieren, vermitteln, verstehen ohne vorher die Entwicklungsgeschichte zur CV gelesen haben zu müssen? Irgendwann muss/kann mal Schluss sein mit customizing ... zumindest für einen einfachen User. Ich fürchte das geht sonst zu Lasten der Akzeptanz.

Ich hätte mir ähnlich zu dem <layout>-Tag ein nennen wir es mal "color-customizing"- oder "design-customizing"-Tag vorgestellt, in dem man bestimmte vorgegebene Werte für ein Element verändern kann. Alternativ könnte man Definitionen im Meta-Bereich einführen, die dann beliebig verwendet werden können.

Das könnte doch flavour sein. Flavour ist dann was globales und wenn einem die Wunschfarbe fehlt wird Sie einfach in der custom.css eingetragen. Diese drei Zeilen kann man demjenigen der es wieder mega-extra-super-hyper-individuell haben möchte zumuten. Das Flavour "wunschfarbe" holt sich dann die Farbe aus der css ".wunschfarbe". Aber ganz ehrlich ich hab keine Ahnung ob das technisch überhaupt geht und wie man sowas programmiert.

.wunschfarbe
{
color: #f7931e ;
}

Ich hab meine Visu zum Release des metal-Designs erstellt, dann noch zwei Wochen mitgelesen und steh jetzt schon wie der Ochs vorm Berg was man nun wie alles "attributieren" und "classieren" kann/soll

Gruß

[MicHau]

Das meinte ich mit 154 Classes und Attribute, wer soll das dokumentieren, vermitteln, verstehen ohne vorher die Entwicklungsgeschichte zur CV gelesen haben zu müssen? Irgendwann muss/kann mal Schluss sein mit customizing ... zumindest für einen einfachen User. Ich fürchte das geht sonst zu Lasten der Akzeptanz.

Ja, da gebe ich dir recht. Die hier implementierte Lösung ist meines Erachtens auch alles andere als endanwendertauglich.

Naja, ich gebe mich ja auch geschlagen. Ich komme gut zurecht mit den aktuellen Mechanismen, aber ich mache mir halt Gedanken, ob man damit weit kommt bei den Endusern. We will see...

[peuter]

Mit Rev. #1203 habe ich eine rudmentäre Unterstützung der Flavours fürs Metal-Design eingecheckt.
Als Erweiterung kann man die Slider ebenfalls direkt mit einem flavour versehen. Um jetzt das Aussehen der Slider vor dieser Änderung zu erhalten (die orangenen Hintergründe bei den Slidern) muss man die Slider folgendermaßen definieren

<slide...flavour="sodium">

Ansonsten sind die Hintergründe wieder so wie zu Beginn des Metal-Designs.

Nach dem Muster der vorhandenen Flavours kann jetzt jeder auch beliebige eigene Flavours in seiner custum.css definieren und benutzen.

Wenn das keine allzu großen Probleme macht, würde ich die Flavours auf Widget-Ebene für alle Widgets implementieren.

Ich denke das noch mehr Möglichkeiten des Customizing an dieser Stelle auch kontraproduktiv ist. Die Möglichkeiten sind da, und wer seine Visu so detailliert verändert möchte, dem würde ich diese Hürde momentan einfach mal ohne schlechtes Gewissen zumuten. Um da ein neues Flavour nach eigenem Farb-Geschmack zu definieren, genügt ein wenig copy&paste ohne komplett zu verstehen was man da eigentlich tut.

[MicHau]

siehe hier
Doppeltes Feature

Ich würde sagen, man sollte Flavour dann bei allen Widgets einbauen, es macht eigentlich dann überall Sinn.

[Chris M.]

Da's hier eigentlich OT ist, schreib ich mal einen neuen Thread zu Flavour und Class -> weiteres dort.

[makki]

Eine (fast) OT-Anmerkung, 2ct: (hat mir jemand aus diesem Forum mit Erfahrung in Usability-Tests mal so schlüssig erklärt..*)

Verwendet doch für stati (An/Aus) eindeutige Farben kein rot/grün, das ist immer zweideutig, kein grün/gold sondern z.B. grau/schwarz/weiss=eher aus, rot/lila/blau/grün/gelb (natürlich dann durchgängig) ist eher = an.

*: ich empfinde es schon mit dem ansehen diverser Beispiel-Visus und Demos über die Jahre als richtig: man weiss als dritter betrachter nie, ob orange, rot, grün blau oder potassium jetzt nun = "an" oder "aus" ist..

Ich bervorzuge übrigens die Textform, die ist aber auch sehr zweideutig, weil man nicht weiss ob man beim Druck auf "Aus" ausschaltet oder auf "An" toggelt, insodern ist die umgebende Farbe des Icons/Symbols eine zusätzliche, wertvolle Hilfe..

Sorry, mag jetzt albern klingen aber ist IMHO extrem praxisrelevant, das jeder (oder zumindest die mehrzahl) Anwender auch intuitiv versteht, wie der aktuelle Status ist und was passiert wenn man da drückt..

Makki

[daviid]

Zum Thema Rot/Grün.

Ich hab das jetzt mit Icons gelöst, und zwar weiß für Aus und orange für An.
Sieht erstens im Metal Design verdammt cool aus und zweitens versteht das wirklich jeder

[MicHau]

Ich hab das jetzt mit Icons gelöst, und zwar weiß für Aus und orange für An.
Sieht erstens im Metal Design verdammt cool aus und zweitens versteht das wirklich jeder

So mache ich das auch, und das ist mit den neuen Features (Flavour bei Icons, orange Icons default-mäßig schon vorhanden) auch echt einfach.

[kleinklausi]

Sieht erstens im Metal Design verdammt cool aus und zweitens versteht das wirklich jeder

Ich finds auch cool, aber trotzdem bin ich mir nicht sicher dass das jeder versteht. Gibt Orange/Weiss den Status wieder oder den Wert, der angenommen werden soll, wenn man draufdrückt?

Ich finds wie gesagt auch cool :-)

[MGK]

sorry das ich die alte Thread-Leiche wiederbelebe, aber was gibt es denn für flavours?

      <slide min="0" max="100" step="1" mapping="On_Off" flavour="sodium">
        <label>R</label>
        <address transform="DPT:5.001" mode="readwrite">1/2/5</address>
        <address transform="DPT:5.001" mode="read">1/5/5</address>
      </slide>

klappt, aber 4x Sodium für meine LED RGBW slider ist doof, ich hätte gerne rot, blau, grün und weiss
Ich habe schon so offensichtliche Sachen wie "red" ausprobiert, aber es geht nur sodium, sonst ist der Slider immer standard schwarz-weiss.

Danke,
Michael

[Chris M.]

aber was gibt es denn für flavours?

Das kann man pauschal nicht sagen, denn "flavour" ist Design-Spezifisch.
D.h. jedes Design darf eigene Flavours definieren - man könnte die auch als Sub-Design sehen.
(Und da vielen eine Farbe meist wichtiger war, hatten wir extra deswegen auch Colors eingeführt, spontan weiß ich aber nicht, welche Widgets color und welche flavour unterstützen)

Die Idee dahinter ist, dass man z.B. "Warnungs-Seiten" haben kann (z.B. in einem roten Thema), ...

Die Flavours (alle!) die das Design Pure unterstützt, kannst Du leicht auf der entsprechende Seite der Demo-Config sehen.
Und durch den Design-Wechsel bei der Demo-Config kannst Du auch sehen, wie die anderen Designs mit genau diesen(!) Flavours umgeht - meine Vermutung ist, dass die alle einfach dem Vorbild von Pure folgen...

Kurzer Hintergrund zu den Flavour-Namen:
Pure ist ja ein absolut minimalistisches Design. Es hat nur ein paar Schmuckfarben - die Flavours. Und bei denen ist die Farbe von den Flammfärbungen der entsprechenden Elemente abgeleitet - die hatte ich bei der Assoziation mit einem Kometen für ganz sinnig gehalten

[MGK]

Moin,
wäre es nicht sinnvoll bei allen Colors und Flavours zumindest die 17 HTML-Grundfarben zu unterstützen? (besser natürlich alle 140 Standard-Farben), weitere kann der Design-Designer oder der Anwender dann ja zusätzlich integrieren.

bei slidern z.B. gehen "white" und "lithium" aber "red" und "green" nicht? (metal-Design) - finde ich extrem unlogisch.

ich weiss nicht wo das in den sourcen ist, aber sollte das nicht einfach copy&paste in alle Design sein?

Michael

[Chris M.]

Gehen tut viel - aber ist das auch sinnvoll?

Jeder Flavour und jede Farbe erzeugt jeweils mindestens eine CSS-Regel.
=> Je mehr um so langsamer wird die Seite - sowohl beim Laden als auch zur Laufzeit

Und wie ich oben zum Flavour geschrieben hatte - das ist nicht dazu da irgendwelchen Widgets hübsche Farben zu geben. Das ist dazu da, Seiten logisch zu strukturieren, so dass man auf einem Blick sieht ob's um Sicherheit, Komfort, Entertainment, ... geht.
(Das es anders verwendet wird ist eine andere Geschichte. Das ist genau so mit Bruchzahlen beim colspan - insb. beim Metal-Design vielfach genutzt, geplant war's nicht und offiziell unterstützt ist's eigentlich auch nicht...)

Die Farben dagegen sind für User-Einfärbungen von Widgets gedacht. Und da ist erst mal alles "übliche" definiert - und für alle Designs gleich (ein Design darf die Farben spezifisch etwas anpassen um diese kompatibel zu halten).
Was hier möglich ist, steht in der designglobals.css