Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
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...
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.
Code:
.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
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.
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.
Ich hab die Falvours nicht verstanden und eigentlich sind das nur kleine grafische Gimmicks die ich gemacht hab.
Ich kann mich mit den Flavours auch nicht so richtig anfreunden.
Sie sind die einzige Möglichkeit für einen User, die Farben anzupassen. Aber er ist nicht in der Lage eigene Farben zu verwenden, sondern kann nur das nehmen, was im Design implementiert ist, sofern er nicht selbst Profi ist und CSS-Anpassungen im custom-css machen kann.
Ich halte das für eine zu große Einschränkung. Ich denke, dass man eine einfachere Möglichkeit schaffen muss, Vorder- und Hintergrund von Widgets zu bestimmen. Bin ich mit dieser Meinung alleine?
Ich hab die Falvours nicht verstanden und eigentlich sind das nur kleine grafische Gimmicks die ich gemacht hab.
Ich erkenne da jetzt nur den dot_gold als unterschied zum vorhandenen (die "Goldene Slider-Range" ist schon vor einiger Zeit eingecheckt worden. Den kannst Du gerne einchecken. Alles was optional ist, bereichert nur die Darstellungsmöglichkeiten des Designs und ist aus meiner Sicht immer willkommen.
Die Flavour-Geschichte ist nicht weiter kompliziert. Du definierst in deiner Config eine page mit einem Flavour z.B.
Code:
<page flavour="gold">
Und kannst den z.B. per Css Selektor das Design für dieses Flavour anpassen, also z.B. für die Slider-Range sollte das hier passen.
Hier sieht man übrigens auch schön die "null" im Sliderknopf bei Chrome und bei Firefox nicht.
Bei welchem Browser wird die "null" den angezeigt? Da ich hauptsächlich mit Chrome und Firefox teste, erklärt das schonmal, warum ich das Problem nicht gesehen habe. (Am besten gibst Du die Antwort in dem urprünglichen Thread zu diesem Thema, ist hier ein bischen Off-Topic).
Ich hab die Falvours nicht verstanden und eigentlich sind das nur kleine grafische Gimmicks die ich gemacht hab.
Für mehr fehlt momentan auch Zeit. Ich hab da zu viel um die Ohren, bei mir wird das nix. Hier sieht man übrigens auch schön die "null" im Sliderknopf bei Chrome und bei Firefox nicht.
Ich habe heute mal das "gold" als Standardfarbe mit in die css genommen und ein paar kleinigkeiten in der metal css angepasst. Unter anderem auch einen dot_gold gebaut.
Wenn gewünscht würde ich das dann mal ins SVN schieben, allerdings würde mich da eure Meinung, vorallem die des Design-Vaters mal interessieren.
Kannst Du da mal einen Screenshot von machen, damit man das mal sehen kann?
Eine pauschale Änderung für alle Slider sehe ich da eher skeptisch, da Geschmäcker nunmal unterschiedlich sind und jeder andere Farben bevorzugt. Ohne mich bisher weiter mit den Flavours auseinandergesetzt zu haben, scheint mir das hier der klassische Anwendungsfall dafür zu sein.
Wenn Du alle Slider einer Page anpassen willst, sollte das doch mit der aktuellen Flavour Implementierung schon möglich sein. Für individuellere Sachen müsste man die Flavours dann auf Widget Ebene bringen.
Wie gesagt Flavours sind im Metal-Design noch nicht implementiert, aber da kannst Du gerne mit starten, macht an dieser Stelle IMHO absolut Sinn. Wenn ich die Zeit finde gucke ich mir die ganze Flavour Geschichte mal genauer an, um zu sehen wieviel Aufwand nötig wäre um die auf Widget Ebene zu bringen.
Wird die slider range noch optional bzw. farblich über stytlings anpassbar?
Ich habe heute mal das "gold" als Standardfarbe mit in die css genommen und ein paar kleinigkeiten in der metal css angepasst. Unter anderem auch einen dot_gold gebaut.
Wenn gewünscht würde ich das dann mal ins SVN schieben, allerdings würde mich da eure Meinung, vorallem die des Design-Vaters mal interessieren.
Ich kenne mich noch zu wenig aus, ich hätte jetzt spontan an Stylings gedacht.
Da verwechselst Du etwas:
Ein Styling ist dazu gedacht das Aussehen eines angezeigten Wertes von seinem Wert selbst abhängig zu machen.
So kann z.B. ein geschlossenes Fenster auf der Visu als "geschlossen" dargestellt werden, ein geöffnetes dagegen als "offen".
Von daher ist ein Styling erst mal nicht dazu gedacht das Erscheinungsbild eines Widgets selbst zu ändern.
Etwas anderes wäre es, wenn man die Slider-Farbe von der Slider-Stellung abhängig machen möchte...
Allerdings habe ich damit noch ein grundlegendes Verständnisproblem. Es wird einem ja hiermit suggeriert, das man irgendwie das Styling einer Komponente beeinflussen kann.
Jain. Der User kann definieren, wie die Komponente bei verschiedenen Werten dynamisch aussehen soll.
Aber wenn das Design das nicht unterstützt, komme ich doch nicht weiter, oder?
Richtig. Ist genau so wie bei den Flavours.
Wenn ein Design dieses Feature nicht implementiert, hat der, der es verwenden will einfach Pech gehabt.
(Man kann sich dann dadurch behelfen, dass man die custom.css verwendet um das Design doch noch zu befähigen - besser wäre es aber natürlich das Design im SVN zu fixen)
Z.B. wenn für "purple" ein gelber Vordergrund im Design angegeben ist, kann schreiben, was ich will, ohne das gewünschte Ergebnis zu erreichen.
Täusche ich mich da?
Wäre nein, wäre es nicht sinnvoll, dem User in der Styling-Definition ein paar Möglichkeiten zur Formatierung anzubieten, beispielsweise Vorder- und Hintergrund?
Ja, das ist so. Bewusst!
Das Design hat die Hoheit darüber, wie ein Widget optimal darstellen soll, dass der Wert nun "purple" ist.
Wenn Dir die Lösung des Designs nicht gefällt, dann musst Du das in der custom.css überschreiben - oder ein eigenes Design machen.
Es ist halt die alte Frage, wo das Optimum zwischen Einfachheit und Komplexität liegt.
Da es Open Source ist und auch noch die custom.css existiert dürfte damit vom Experten über den erfahrenen Anwender bis hin zum Anfänger eigentlich allen geholfen sein.
Zur Farbe:
Ich hatte mir schon öfters gedacht, ob nicht Flavours auch auf Widget-Level eingeführt werden sollten...
Ich kenne mich noch zu wenig aus, ich hätte jetzt spontan an Stylings gedacht.
Allerdings habe ich damit noch ein grundlegendes Verständnisproblem. Es wird einem ja hiermit suggeriert, das man irgendwie das Styling einer Komponente beeinflussen kann. Aber wenn das Design das nicht unterstützt, komme ich doch nicht weiter, oder? Z.B. wenn für "purple" ein gelber Vordergrund im Design angegeben ist, kann schreiben, was ich will, ohne das gewünschte Ergebnis zu erreichen.
Täusche ich mich da?
Wäre nein, wäre es nicht sinnvoll, dem User in der Styling-Definition ein paar Möglichkeiten zur Formatierung anzubieten, beispielsweise Vorder- und Hintergrund?
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: