Farben der #jumpToQuestionNrX in default.css definieren

[fenglisch]

... falls das möglich ist. Es geht um die Hintergrundfarbe (grün, gelb, rot), nachdem die These beantwortet wurde. Aktuell werden sie in der general.js definiert

[msteudtn]

Die Funktion GENERAL.JS / fnTransformPositionToColor() benutzt die Farben, welche auch in den Bootstrap-CSS-Klassen genutzt werden.

Mittelfristig möchte ich die Navigation (Knöpfe unter den Fragen) ersetzen. Dann wäre das keine Tabelle mehr, sondern eine Reihe von Bootstrap-Buttons oder etwas ähnliches.
In dem Fall würde man "sowieso" auf die Klassen btn-danger, btn-warning, btn-success bzw. bg-danger, bg-warning, bg-success zurückgreifen. Diese können auch in den /STYLES/angepasst werden.

Kurzfristig wäre so eine Option (möglich aber) mit Kanonen auf Spatzen schießen. :(

[fenglisch]

Genau, ich meine die Zeile var arColors = new Array("#d9534f","#f0ad4e","#5cb85c"). Mit deinem Plan hat sich das aber erledigt :-)

[lrusch]

Zu dem Thema hatte ich eine Idee. In der default.css wird das wohl nichts werden, da die Farben von progressbar.css teilweise überschrieben werden. Ich war so frei und habe diese Methode: fnTransformPositionToColor durch diese: fnGetJumpToQuestionColorForPosition ersetzt, die die Klassen der Fragen folgendermaßen aufbaut

bg-danger td-jump-to-question-decline
bg-warning td-jump-to-question-neutral
bg-success td-jump-to-question-approve
td-jump-to-question-skip

so werden die defaults von bg-... genommen und können mit td-jump-to... überschrieben werden. Da bei bg-... teilweise !importants standen, müssen die td-klassen dann auch mit !important bg überschreiben. Damit diese überschrieben werden können, habe ich eine navigation.css eingefügt und hinter progressbar.css eingebunden.

Den merge-conflict, wahrscheinlich formatter... habe ich noch nicht verstanden und muss ich noch beheben. Sry für die vielen commits...

[msteudtn]

Die gute Nachricht: Es funktioniert mit dem Anpassen der CSS-Stylesheets in der neuen NAVIGATION.CSS

Ich habe aber noch ein paar Bauchschmerzen mit der Tabelle als Navigations-Element. Das war (m)eine Design-Entscheidung vor vielen Jahren, welche endlich korrigiert werden muss. Gerade in Bezug auf Barrierefreiheit sollten hier lieber "normale" Navigationselemente wie <ul> <li> Link zu XY </li> </ul> oder ein <button> stehen.

Dann steht die grundsätzliche Frage an, ob die Farben einen Mehrwert für die Nutzer haben? In der jetzigen Form stehen da nur bunte Zahlen. Wird ein Nutzer wieder zurück zu "2" gehen, wenn er/sie schon bei Frage 14 ist? (Das war ein Hinweis aus meinem UX-Coaching.) Vielleicht wird das aber mit (der geplanten) #44 etwas übersichtlicher.

Der orignale Wahl-o-Mat nutzt z.B. nur einfache Kreise ohne Farben (z.B. WoM Rheinland-Pfalz 2021 https://www.wahl-o-mat.de/rlp2021/app/main_app.html) Das hat auch den Vorteil, dass die Nutzer nicht durch zu viele Farben abgelenkt werden.

Hier kann @fenglisch vielleicht Erfahrungen aus der Praxis einbringen?

Lange Rede, kurzer Sinn: Ich kann die Änderungen einspielen. Wenn wir Pech haben, fliegen sie bei einer neuen Navigation aber wieder raus. (z.B. nur Punkte) :-( Vielleicht bilden sie aber auch die Basis für die Farben der neuen Navigation. (z.B. Buttons) :-)

[lrusch]

Hi Mathias,   wir können das auch gern vernünftig machen und nächste Woche darüber sprechen, wie deine Vorstellungen sind. Das wäre auch eher ein gutes Thema, anstatt über die Anpassung einer Schleife und einer Bedingung zu sprechen :-).   Bis später Lars   Gesendet: Sonntag, 01. August 2021 um 17:18 Uhr Von: "Mathias" ***@***.***> An: "msteudtn/Mat-O-Wahl" ***@***.***> Cc: "lrusch" ***@***.***>, "Comment" ***@***.***> Betreff: Re: [msteudtn/Mat-O-Wahl] Farben der #jumpToQuestionNrX in default.css definieren (#36)   Die gute Nachricht: Es funktioniert mit dem Anpassen der CSS-Stylesheets in der neuen NAVIGATION.CSS Ich habe aber noch ein paar Bauchschmerzen mit der Tabelle als Navigations-Element. Das war (m)eine Design-Entscheidung vor vielen Jahren, welche endlich korrigiert werden muss. Gerade in Bezug auf Barrierefreiheit sollten hier lieber "normale" Navigationselemente wie <ul> <li> Link zu XY </li> </ul> oder ein <button> stehen. Dann steht die grundsätzliche Frage an, ob die Farben einen Mehrwert für die Nutzer haben? In der jetzigen Form stehen da nur bunte Zahlen. Wird ein Nutzer wieder zurück zu "2" gehen, wenn er/sie schon bei Frage 14 ist? (Das war ein Hinweis aus meinem UX-Coaching.) Vielleicht wird das aber mit (der geplanten) #44 etwas übersichtlicher. Der orignale Wahl-o-Mat nutzt z.B. nur einfache Kreise ohne Farben (z.B. WoM Rheinland-Pfalz 2021 https://www.wahl-o-mat.de/rlp2021/app/main_app.html) Das hat auch den Vorteil, dass die Nutzer nicht durch zu viele Farben abgelenkt werden. Hier kann @fenglisch vielleicht Erfahrungen aus der Praxis einbringen? Lange Rede, kurzer Sinn: Ich kann die Änderungen einspielen. Wenn wir Pech haben, fliegen sie bei einer neuen Navigation aber wieder raus. (z.B. nur Punkte) :-( Vielleicht bilden sie aber auch die Basis für die Farben der neuen Navigation. (z.B. Buttons) :-) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[fenglisch]

Ich habe hierfür eine ganz simpel umsetzbare Idee, die gleich mehrere Fliegen mit einer Klappe schlägt: Anstatt von HEX-Werten werden CSS-Variablen in der general.js definiert, also z. B.:

var arColors = new Array("var(--danger)", "var(--warning)","var(--success)")

Es ergibt ohnehin sehr viel Sinn, in der CSS-Datei mit Variablen zu arbeiten (nicht nur für Farben). Ähnlich wie in den Addons muss man dann nur einmal ganz oben beim :root-Selektor die Variablen definieren und schon ist der komplette Mitwirk-O-Mat umgestyled. Und für dann kann man die Variablen natürlich auch gleich in der general.js verwenden.

Ein weiterer Vorteil: In den meisten Mitwirk-O-Maten haben wir eingestellt, dass die Link-Farbe in den Zellen sich zu weiß oder schwarz ändert, wenn die Hintergrundfarbe der Zelle sich ändert, da der Kontrast der originalen Link-Farbe zur neuen Hintergrundfarbe sonst zu schwach wäre. Dafür haben wir einen ziemlich umständlichen Selektor, den wir jedes Mal anpassen müssen:

td[style^="border-color: rgb(255, 177, 92); background-color: rgb(255, 177, 92);"]  a,
td[style^="border-color: rgb(126, 194, 102); background-color: rgb(126, 194, 102);"]  a,
td[style^="border-color: rgb(227, 121, 1); background-color: rgb(227, 121, 1);"]  a {
  color: #000;
}

Mit Variablen wäre das kürzer und vor allem jedes Mal gleich

[fenglisch]

Das würde besser in Ticket "Update CSS" passen, aber trotzdem hier als Plädoyer, generell Variablen zu verwenden, ein Überblick über die Variablen, die wir für den Mitwirk-O-Mat nutzen:

:root {
  --body-font: "Montserrat";
  --heading-font: "EB Garamond";
  --primary-color: #42818f; /* Color of the card and some buttons. Should be rather dark. Main color of the website fits well. */
  --link-color: #42818f; /* Usually same as main-color. Must be dark enough to be readable on white background. */
  --secondary-color: #6eb8bb; /* Color of the start button, the "agree to statistics" and resultsByThesis/Parties buttons. Good contrast to main color. Maybe a green tone? */
  --success: #7ec266; /* For ranking bar and answer buttons. Ideally dark enough to read white text on it */
  --warning: #ffb15c;
  --danger: #e37901;
  --border-radius: 0;
  --display-made-with-love: none; /* "block" (label shown) or "none" (label hidden)  */
}