f9bf7d5674ce4e8d7a023a45676fccfc31f3d38a
12
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
9267797d1d |
Feste Checklisten statt Vorschlaege - in allen vier Bereichen
"Die neuen Sachen in der LIVE-Analyse soll der Creator FEST sehen, auch
schoen kategorisiert, und der Ansprechpartner soll anklicken koennen,
wenn er findet, dass der Creator was verbessern sollte."
DER UMBAU. Vorher waren die Punkte Vorschlaege zum Uebernehmen: Man
holte sie sich und bekam einen eigenen Eintrag. Das war falsch gedacht.
Eine Checkliste, die man erst anfordern muss, ist keine Checkliste --
und schlimmer: Zwei Creator haetten unterschiedliche Listen gehabt, je
nachdem wer sich was geholt hat. Genau das macht einen Vergleich
unmoeglich, und um Vergleich geht es bei einer Betreuung.
Jetzt stehen dieselben Punkte fuer JEDEN fest da, gruppiert:
LIVE 21 Punkte -- vor, waehrend, nach der Sendung
Community 14 Punkte -- Moderation vorbereiten, aufbauen, wenn es kippt
Technik 12 Punkte -- Einrichtung, Ausfall, was geholfen hat
Content 13 Ideen -- nach Saeule (70/20/10) statt nach Ablauf
Jede Gruppe hat einen Satz, der erklaert, wofuer sie da ist. Eine
Ueberschrift allein sagt das nicht.
Was sich je Creator unterscheidet, ist nur der STAND -- und den setzt
die Betreuung: "Passt so" oder "Verbessern". Ein Creator kann sich nicht
selbst bewerten; koennte er es, stuende alles auf gruen. "Verbessern"
verlangt einen Satz, WAS zu verbessern ist -- eine Bewertung, mit der er
nichts anfangen kann, ist nicht streng, sondern nur entmutigend.
Der Creator sieht alles: die Stufe, den Grund, den Namen und den
Zeitpunkt. Und er kann an JEDEM Punkt antworten -- das ist der Kanal,
ueber den er ueberhaupt etwas sagen kann.
Oben steht eine Bilanz in einer Zeile: wie viele passen, wie viele sind
zu verbessern, wie viele hat noch niemand angesehen. Das ist die Frage,
die beide Seiten zuerst haben.
STABILE SCHLUESSEL statt Positionen. Ein Stand haengt am Schluessel des
Punktes ("ton-geprueft"), nicht an seiner Nummer. Haenge er an der
Position, waere beim Einfuegen eines Punktes in der Mitte jede Bewertung
dahinter am falschen Punkt -- und niemand wuerde es merken, weil beides
plausibel aussieht. 64 Punkte haben jetzt einen.
"Offen" loescht den Stand, statt ihn auf "offen" zu setzen: Ein
Datensatz, der nichts aussagt, ist Ballast.
ZWEI EIGENE FEHLER, VON DEN PRUEFUNGEN GEFUNDEN:
1. DAS CSS LAG IN DER FALSCHEN DATEI. Ich hatte es in content.css
geschrieben -- bereich.html laedt die gar nicht. Die Punkte standen
auf drei von vier Seiten nackt und ohne Flaeche da. Es ist derselbe
Fehler wie im August bei .knopf-still, .schalter und .kopf-zeile, und
es gibt seitdem eine Warnung dazu in start.css. Sie hat nichts
genutzt, solange keine Pruefung sie nachhielt.
Jetzt gibt es eine: Sie misst, ob eine Karte wirklich eine Kante und
Polsterung hat -- nicht nur, ob das Element existiert. Gegenprobe
gemacht: Klasse umbenannt, Pruefung meldet "STIL FEHLT".
2. Ein Betreuer sah beim Oeffnen keine Bewertungsknoepfe, weil noch kein
Creator gewaehlt war -- und musste erst raten, dass er oben jemanden
auswaehlen soll. Jetzt nimmt der Server den ersten betreuten Creator,
wenn keiner angegeben ist.
Die alte Oberflaechenpruefung fuer den Vorschlaege-Block wurde entfernt
statt angepasst: Sie verlangte etwas, das es nicht mehr gibt. Eine
dauerhaft rote Pruefung ist schlimmer als keine -- man gewoehnt sich
daran, und beim naechsten echten Fehler sieht niemand hin.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2bebab156b |
Profilbild gebaendigt, Steckbrief von der Creator-Akte getrennt
ZWEI FEHLER, DIE FILIPE GESEHEN HAT.
1. DAS PROFILBILD LAG UEBER DER HALBEN SEITE. Als Patrick sein Bild
hochlud, zog sich ein roter Balken quer ueber die Startseite.
Ursache: Die CSS-Regel .wer__bild hat GEFEHLT. Das Element wurde in
kopf.js erzeugt, die Regel dazu nie geschrieben -- und ein <img> ohne
Groessenangabe nimmt seine natuerliche Groesse an, bei einem Handyfoto
also mehrere tausend Pixel. Dazu fehlte overflow: hidden am Traeger.
WARUM KEINE PRUEFUNG DAS GEFUNDEN HAT: Sie lud ein 1x1-Pixel-PNG hoch.
Klein, schnell, von Hand gebaut -- und voellig unfaehig, irgendetwas
zu ueberdecken. Die Pruefung war gruen, der Fehler war da, und gesehen
hat ihn der Nutzer. Sie arbeitet jetzt mit einem 1200x1200-Bild, also
in der Groesse, die wirklich hochgeladen wird, und misst danach: Bleibt
das Bild in seinem 28-px-Feld, ragt es irgendwo heraus, laeuft die
Seite ueber. Gegenprobe gemacht -- ohne die Regel meldet sie
1200x1200 in 28x28 und 918 px Ueberlauf.
2. ZWEI PERSONEN AUF EINEM BILDSCHIRM. Auf der Profilseite stand oben
"Profil: SpongBobSchwammKopf" und mittendrin "MEIN PROFIL: Dogfather".
Niemand konnte sagen, welche Angabe zu wem gehoert.
Es sind auch wirklich zwei verschiedene Dinge:
MEIN STECKBRIEF gehoert MIR -- Bild, ein Satz ueber mich, meine
Kanaele. Fuehre ich selbst.
CREATOR-PROFILE die BETREUUNGSAKTE eines anderen Menschen --
Ziele, 90-Tage-Plan, interne Notizen. Fuehren die
Betreuer.
Scouts, Manager und DogFather haben jetzt zwei getrennte Kacheln und
eine eigene Seite (steckbrief.html, serverseitig geschuetzt). Ein
Creator behaelt beides zusammen -- er hat nur eine Seite und sieht
dort ausschliesslich sich selbst. Die Logik liegt in einer eigenen
Datei statt hinten an profil.js: Sie gehoert der angemeldeten Person,
nicht der Akte.
ACHTZEHN KACHELN, ACHTZEHN FARBEN. Die neue Kachel haette sich ihren
Farbton mit den Creator-Profilen geteilt -- zwei Nachbarn in derselben
Farbe. Statt eine Farbe dazuzuerfinden, wurde tools/kachel-farben.mjs
fuer 18 Winkel neu gerechnet, samt der neuen Nachbarschaft im Raster.
Der kleinste Abstand zweier Nachbarn liegt weiterhin bei 100 Grad.
Gefunden hat das die Startseitenpruefung ("17 Farben auf 18 Kacheln").
Die Trennung wird jetzt fuer JEDE Rolle geprueft: welche Kacheln sie
sieht, dass auf der Akte kein fremder Steckbrief steht, und dass die
eigene Seite die richtige Person zeigt. Eine alte Pruefung, die das
Gegenteil verlangte, wurde ersetzt statt stehen gelassen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1fe443e59c |
Handy durchgeprueft, Lichtfarbe je Kachel, haengendes Licht behoben
DAS LICHT BLIEB HAENGEN -- vier Ursachen, jede einzeln behoben:
1. EIN WETTLAUF. Zwischen dem Anmelden eines Bildaufbaus und seinem
Ablauf konnte der Zeiger die Karte laengst verlassen haben. Dann hatte
pointerout schon aufgeraeumt, und der Bildaufbau schaltete das Licht
gleich wieder AN. Der haeufigste Fall und der unauffaelligste.
2. UEBER EINE LUECKE VERLASSEN. Wer eine Karte nicht ueber eine
Nachbarkarte verliess, sondern ueber den Zwischenraum, loeste kein
Ereignis aus, das die alte Karte kannte.
3. GESCROLLT, OHNE DIE MAUS ZU BEWEGEN. Die Karte wandert unter dem
stehenden Zeiger weg -- es kommt gar kein Zeigerereignis. Jetzt wird
beim Scrollen nachgesehen, ob die beleuchtete Karte noch unter dem
Zeiger liegt.
4. FENSTER ODER TAB VERLASSEN. Auch dort kommt nichts mehr.
Es gibt jetzt genau EINE beleuchtete Karte -- mehr kann es nicht geben,
es gibt ja nur einen Zeiger. Beim Wechsel geht die alte aus, bevor die
neue angeht.
DIE FARBE GEHOERT ZUR KACHEL. Auf der Wissensseite leuchteten alle sechs
Welten violett, weil die Farbe dort --w heisst und der ganze uebrige
Workspace --ton benutzt. Das Licht griff auf --ton zu, fand nichts und
nahm den Farbton der SEITE. Dieselbe Luecke bei den Aufgaben-Spalten
(--sfarbe), den Kalenderkarten (--afarbe) und den Kalenderzeilen
(--zfarbe). Alle vier setzen jetzt --ton mit.
Nachgewiesen an echten Bildpunkten, nicht am Quelltext: Der Zeiger wird
auf die Aufgaben-Kachel gesetzt (dort muss Rot ueberwiegen: 85 zu 22)
und auf die Kalender-Kachel (dort Blau: 71 zu 13). Ein
Zeichenkettenvergleich haette das nicht gekonnt -- der Browser rechnet
color-mix() aus und schreibt je nach Fassung rgb(), color() oder oklab()
zurueck.
DAS HANDY, komplett durchgeprueft: neue pruef-handy.mjs faehrt alle
fuenfzehn Seiten auf DREI echten Geraetegroessen ab (320 px iPhone SE,
390 px iPhone, 412 px Android) und misst fuenf Dinge, die am Rechner
unsichtbar sind. Gefunden und behoben:
* ZWEI ECHTE UEBERLAEUFE (startcheck +27 px, automation +33 px). Die
Seite liess sich waagerecht schieben -- auf einem Telefon der
schlimmste Fehler. Ursachen: zwoelf Raster mit festem Mindestmass
(minmax(280px, 1fr) kann nicht schrumpfen -> min(280px, 100%)),
zwoelf feste Mindestbreiten an Auswahlfeldern, und ein "flex: none"
an den Stufen-Knoepfen, das jedes Schrumpfen verbot. "width: 100%"
allein reichte dort nicht.
* BERUEHRZIELE unter 24 px (WCAG 2.2, Kriterium 2.5.8). Auswahlfelder
waren 18 bis 22 px hoch. Jetzt 44 px -- die Empfehlung von Apple und
Google, und der Daumen ist nun einmal breiter als ein Mauszeiger.
Nebenbei behebt die Schriftgroesse 16 px das Hineinzoomen von iOS.
* SCHRIFT unter 11,7 px an 52 Stellen. Gesucht wurden sie nicht von
Hand -- das waere ein Ratespiel gewesen und haette die Haelfte
uebersehen -- sondern durch Durchsuchen der Stildateien nach
font-size unter 0,73rem.
ZWEI FEHLER IN DEN EIGENEN PRUEFUNGEN gefunden und behoben: Die
Schriftregel griff zuerst gar nicht (start.css wird VOR den Seitenstilen
geladen, bei gleicher Staerke gewinnt die spaetere -- jetzt mit
body.start qualifiziert), und die Lichtpruefung scrollte 600 px und
stellte nicht zurueck, sodass die folgende Pruefung ins Leere zeigte.
GEGENPROBE gemacht: Mit absichtlich eingebauten Fehlern (8-px-Schrift,
500 px breiter Inhalt) meldet die Handypruefung sofort Rot. Eine
Pruefung, die immer bestaetigt, bestaetigt nichts.
Alle achtzehn Pruefungen laufen gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
766c75b51d |
Die Buehnen richtig: nicht mehr beschnitten, hell, mit Lesespur
Drei handfeste Fehler, alle im Screenshot zu sehen gewesen. 1. ABGESCHNITTEN. background-size stand auf "138% auto". Auf einem 2540 px breiten Schirm wurde das Bild damit 3500 px breit und knapp 2000 px hoch -- in einem 1300 px hohen Fenster fehlten 700 px, und zwar oben. Genau deshalb waren die Figuren riesig und ihre Koepfe weg. Jetzt cover mit Verankerung auf 50% 42%: Die Flaeche wird immer gefuellt, so wenig wie noetig skaliert, und wenn etwas beschnitten werden muss, dann Fussboden und Decke -- nicht die Gesichter. 2. DIE VIGNETTE LAG FALSCH HERUM. Abgedunkelt wurde die MITTE, also genau der Teil, in dem die Szene steht. Man sah die Raender des Bildes und in der Mitte einen grauen Fleck. Jetzt laufen die RAENDER ins Dunkle und die Mitte bleibt klar -- so wie in der Fotografie. 3. ZWEI SCHICHTEN DUNKELHEIT. Zusaetzlich zur Vignette legte der Schleier .86/.58/.44 Schwarz ueber dasselbe Bild. Jetzt nur noch oben (Kopfleiste) und unten (Seitenende) ein Streifen. Dazu die Bilder selbst: Helligkeit 0.66 -> 0.88, mehr Kontrast und Farbe. Sie sind ein BILD, kein Nebel. DIE LESESPUR ist der eigentliche Kniff. In allen neun Szenen stehen HasiDog und DogFather AUSSEN, die Mitte ist frei -- danach wurden sie ausgesucht. Diese Aufteilung wird jetzt benutzt statt bekaempft: aussen bleibt das Bild hell und scharf, in der Mitte (wo der Text steht) wird gedaempft. Der klare Rand ist in jedem Fenster mindestens 400 px breit. Auf dem Handy gibt es daneben keinen Platz, dort deckt die Spur alles. Was frei stand und keine Karte hatte, bekommt eine Lesezone mit backdrop-filter: Der Hintergrund bleibt in Farbe und Form sichtbar, wird an dieser Stelle aber weichgezeichnet. Die billige Loesung waere gewesen, das Bild wieder abzudunkeln -- damit waere man dort, wo man angefangen hat. ZWEITER FUND AN DER EIGENEN KONTRASTMESSUNG. Sie tastete ausschliesslich NEBEN dem Element ab. Traegt ein Text seine Flaeche aber selbst (eine Beschriftung mit Hintergrund und Polsterung), liegt jeder Punkt daneben schon auf dem Bild -- gemeldet wurden 1,89:1, obwohl der Text auf deckender Flaeche steht und tadellos lesbar ist. Jetzt wird zuerst in der eigenen Polsterung gemessen, also auf dem, worauf der Text WIRKLICH liegt. (Der erste Fund an derselben Stelle war gestern: Sie mass Text gegen Nachbartext.) Nach dem Aufhellen einmal komplett durchgemessen: von sieben roten Stellen auf null. Schlechtester Wert jetzt 4,70:1 bei 4,5:1 Norm. Die Bilder sind groesser geworden (580 KB -> 1,8 MB fuer alle achtzehn), weil weniger Dunkelheit weniger komprimierbar ist. Geladen wird pro Seite genau eine: 42 bis 132 KB. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
fc4fde0f02 |
Buehnen hell, Flaechen dicht - und die Kopfleiste wieder kurz
DIE BUEHNEN WAREN ZU DUNKEL. Bei 0.42 Helligkeit sah man Schemen, nicht die Szene -- "zu dunkel und sieht ganz komisch aus" traf es genau. Jetzt 0.66 mit etwas mehr Farbe (1.08), die Vignette schwaecher (0.52 statt 0.72). Die Bilder kommen durch. MOEGLICH IST DAS NUR MIT DEM GEGENZUG: Alle Kacheln, Karten und Spalten lagen bei 2 bis 3 Prozent WEISS -- also praktisch durchsichtig. Solange der Hintergrund fast schwarz war, fiel das nicht auf; sobald er hell wurde, lief das Bild mitten durch den Text. Jetzt gibt es --flaeche (rgba(9,13,22,.78)), eine deckende dunkle Flaeche, und 44 Stellen in 16 Dateien holen sich ihre Farbe von dort. Der Unterschied ist genau der, den Filipe beschrieben hat: Der Hintergrund bleibt sichtbar, aber ZWISCHEN den Kacheln -- nicht hinter der Schrift. Wer die Flaechen kuenftig dichter oder durchlaessiger will, aendert eine einzige Zeile statt 44. Die Kacheln selbst tragen ihren Farbton jetzt AUF der Flaeche (color-mix mit --flaeche statt mit transparent) -- dadurch bleibt die Farbe erkennbar, ohne dass die Kachel durchsichtig wird. DIE KOPFLEISTE war so breit wie das ganze Fenster, obwohl der Text kurz ist: .marke__text stand auf flex: 1 1 auto. Das war unsichtbar, solange der Schriftzug nur Text war -- seit er einen Rahmen traegt, lief die Pille quer durchs Bild. Jetzt flex: 0 1 auto (schrumpfen ja, wachsen nein). Gemessen: 375 px statt 1280. Kontrast an echten Bildpunkten auf allen sechs Seiten nachgemessen -- haelt trotz des viel helleren Bildes (schlechtester Wert 4,69:1). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e65827a6db |
Begruessung, Schriftzug, hellerer Hintergrund - und "Wissen" fuer Creator
Vier Wuensche auf einmal, alle auf der Startseite und der Kopfleiste. BEGRUESSUNG. Dort stand "Angemeldet" ueber dem Namen -- eine Zeile, die nichts hinzufuegt, weil oben rechts ohnehin Name und Rolle stehen. Jetzt beantwortet der Kopf die drei Fragen, die man beim Reinkommen hat: WANN (Wochentag, Datum, Kalenderwoche nach ISO 8601, selbst gerechnet), WER (Plakette mit dem Anfangsbuchstaben in der Farbe der Rolle -- der einzige runde Koerper der Seite, dadurch sofort als Person lesbar) und WIE es steht (ein Satz aus denselben Hinweisen, die darunter stehen -- keine zweite Zaehlung). An Tagen mit Charakter kommt ein Wort dazu: Neue Woche, Endspurt, Wochenende. Der Gruss ist feiner gestuft und der Name eigenstaendig ausgezeichnet: das Grusswort leise, der Name kraeftig. SCHRIFTZUG oben links. Vorher alles gleich laut, der Trenner ein Satzzeichen wie jedes andere. Jetzt hat er Rang: der Name vorn und kraeftig, der Ort dahinter und leiser, dazwischen eine kleine Raute in der Hausfarbe. Aufgeteilt zentral in kopf.js statt in sechzehn HTML- Dateien, und nur die Textknoten -- Verweise bleiben unberuehrt. HINTERGRUND heller, wie gewuenscht: Der Schleier liegt bei .86/.58/.44 statt .95/.72/.60, dazu zwei sehr weiche Farbschimmer, die dem Bild das reine Schwarz nehmen. Der Kontrast wurde danach an echten Bildpunkten nachgemessen und haelt ueberall (schlechtester Wert 4,78:1). "WISSEN" statt "Team & System" -- aber nur fuer Creator. Von der Gruppe bleibt fuer ihn genau eine Kachel uebrig; eine Ueberschrift, die Team und System verspricht und nur die Bibliothek zeigt, verspricht etwas Falsches. DREI FUNDE DURCH DIE PRUEFUNGEN: 1. Die Kontrastmessung war kaputt, seit Text neben Text steht. Sie tastete stur 4 px rechts vom Text ab -- und traf dort den NACHBARTEXT statt den Untergrund (1,10:1 gemeldet, ohne dass etwas schlecht lesbar war). Jetzt werden sechs Stellen rings um den Text angeboten und jede zuerst gefragt, ob dort wirklich Untergrund liegt. Strenger, nicht lockerer. Texte ohne freie Stelle werden GEZAEHLT und ausgegeben, nicht still uebersprungen. 2. bereich.html hatte als einzige Seite kein span.marke__text. Damit griffen dort weder die Ueberlauf-Kuerzung noch der neue Rang. Stand seit Monaten so, aufgefallen erst, als die Seitenpruefung die Marke auf allen dreizehn Seiten nachgesehen hat. 3. Die Datumspruefung haette im Maerz stillschweigend versagt: \w kennt ohne Unicode-Schalter kein "ae". Ein Fehler, der sieben Monate wartet. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
1816ed9e1f |
Hinweisliste "Was ist dran": Zeichen, Zahl und Farbe der Zielkachel
Die Zeilen waren die letzten schmucklosen Elemente der Startseite. Jetzt
traegt jede das Zeichen UND die Farbe der Kachel, zu der sie fuehrt --
Hinweis und Ziel gehoeren dadurch sichtbar zusammen, ohne dass die
Zuordnung ein zweites Mal irgendwo steht (sie kommt aus derselben
Tabelle wie die Zahl auf der Kachel). Die Anzahl steht vorn, getrennt vom
Satz und in gleicher Zeichenbreite; beim Ueberfliegen von sieben Zeilen
liest man genau sie zuerst. Ueberfaellig schlaegt Bereichsfarbe und
bleibt rot -- wenn etwas brennt, zaehlt zuerst, DASS es brennt.
Dabei gefunden und behoben: Die Farbtoene hingen an .kachel[data-ton=n].
Um sie fuer die Hinweiszeilen mitzunutzen, wurde .kachel entfernt --
damit gewann aber die Voreinstellung ".kachel { --ton: var(--akzent) }"
weiter unten in der Datei den Wettstreit der Regeln, und alle siebzehn
Kacheln waeren blau gewesen. Die Voreinstellung steht jetzt in :where()
und zaehlt dabei als nicht vorhanden. Die Browserpruefung hat das
gemeldet ("1 Farbe auf 17 Kacheln"), nicht das Auge.
"Nichts offen" ist kein gestrichelter Kasten mehr, sondern eine gute
Nachricht mit ruhigem Gruen und Haken. Weil er jetzt display:flex hat,
war er staerker als das hidden des Browsers und haette IMMER dagestanden
-- eigene Regel dafuer plus eine Pruefung, die beide Richtungen misst.
Neue Pruefungen (pruef-start-ansicht): Zeichen, vorangestellte Zahl,
keine doppelte Zahl im Satz, ganzer Satz fuer Vorleseprogramme, Farbe
gleich der Kachelfarbe an echten Bildpunkten, rot nur bei ueberfaellig.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e74254263f |
Buehne aus den echten Marken-Bildern, Kopfleiste und Begruessung neu
Filipe hatte recht, und zwar zweifach: Der Husky war der FALSCHE (ein fremder Neon-Husky aus dem alten Bilderordner statt DogFather), und zwei in die Ecken geklebte Bilder ergeben noch kein Bild. DIE BUEHNE, zweiter Anlauf. Aus den zehn geschickten Bildern das Studio gewaehlt, in dem HasiDog und DogFather stehen -- nicht aus Geschmack, sondern wegen der ANORDNUNG: Die beiden stehen weit aussen, die Mitte ist dunkel. Genau dort steht der Inhalt. Bei den Bildern mit den Figuren in der Mitte waeren sie hinter dem Text gelandet. Ueber die ganze Flaeche, fest an der Scheibe, 138 % breit: Bei 100 % staenden die beiden bei 20 % und 78 % der Breite -- mitten unter der Textspalte. Vergroessert man das Bild ueber die Scheibe hinaus, wandern sie nach aussen (rund 9 % und 88 %) und der leere Hallenboden liegt dort, wo gelesen wird. Ein Bild groesser zu machen, damit WENIGER davon im Weg ist, klingt verkehrt und ist genau richtig. Fuer schmale Schirme ein eigener Hochkant-Ausschnitt derselben Szene -- ein auf 9:16 gequetschtes Breitbild zeigt nur noch Wand. 1,9 MB PNG -> 28 KB WebP. DIE VIER STELLEN aus den Bildschirmfotos: * Kopfleiste: der DogFather-Kopf davor. Als MASKE aus dem Logo gerechnet (Dunkelheit wird Deckkraft), nicht als Bild -- so laesst er sich im Stil einfaerben; ein fertig eingefaerbtes Bild muesste man fuer jede Farbe neu bauen. 114 KB -> 3 KB. * "Dogfather · DogFather" war der peinlichste Punkt: Name und Rolle lasen sich gleich, es sah nach einem Fehler aus. Jetzt drei unterscheidbare Dinge -- Zeichen mit dem Anfangsbuchstaben, Name, Rolle als Marke in ihrer Farbe. Gebaut in kopf.js, EINMAL statt vierzehnmal: Jede Seitendatei setzte diese Zeile bisher selbst zusammen. * Begruessung: leuchtender Strich, groesserer Gruss, auslaufende Trennlinie. Dieselben Striche vor "WAS IST DRAN" und "DEINE AUFGABEN" -- so gehoert sichtbar zusammen, was zusammengehoert. ZWEI EIGENE FEHLER, die die Pruefungen gefunden haben: 1. Ich hatte Verlaeufe IM TEXT gebaut (background-clip mit durchsichtiger Schrift). Sah gut aus, und der Kontrasttest meldete 1,05:1 -- zu Recht. Durchsichtige Schrift haengt an einer einzigen Technik; faellt sie aus (Kontrastmodus, Druck, aeltere Browser), ist der Text UNSICHTBAR statt nur anders gefaerbt. Das ist kein Schoenheitsfehler, das ist ein Ausfall. Jetzt feste Farbe mit einem Hauch Leuchten. 2. Auf dem Handy stand der Abmelden-Knopf 9 px aus dem Bild. Die Suche nach der Ursache ging zuerst in die Irre -- der Test nannte das Wasserzeichen, das aber von seiner Kachel sauber abgeschnitten wird und nur seine Masse meldet. Gemessen war es die Marke: 209 px + 139 px rechte Gruppe passten nicht in 390 px. Auf dem Handy bleibt jetzt nur der Kopf stehen; der Markenzug steht zwei Zeilen tiefer ohnehin als Ueberschrift. Fuer Vorleseprogramme bleibt er im Dokument. Und einmal habe ich mir beim Ersetzen eines CSS-Blocks das halbe Stylesheet geloescht (die Kachel-Regeln lagen zwischen den beiden Suchmarken). Aufgefallen sofort am Bildschirmfoto, zurueckgeholt aus Git, danach zeilengenau ersetzt. 118 Pruefungen, alle gruen. Der Kontrast wird weiterhin an echten Bildpunkten gemessen, jetzt an bis zu 35 Stellen je Seite. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
fcebbd18bb |
Workspace: Casper und HasiDog als Buehne im Hintergrund
Filipe: "der hintergrund soll genau so krass und speziell sein, benutz
den hasen und husky."
Gefunden in assets/img: hero-husky.png (Casper, neonblau auf dunkel --
farblich genau die Oberflaeche) und char-hasidog.jpg (HasiDog). Der
Sticker "HasiDog & Casper" hat bestaetigt, dass die beiden zusammen
gehoeren.
Beide sitzen FEST an der Scheibe in den unteren Ecken -- sie scrollen
nicht mit, sondern stehen da wie ein Buehnenbild, vor dem gearbeitet
wird. Die Mitte bleibt frei, dort steht der Inhalt. HasiDog ist weiter
nach aussen geschoben und schwaecher als Casper: Er ist heller, sein
Gesicht zieht den Blick staerker, und direkt neben einer Kachel wuerde
man ihn ansehen statt der Kachel.
AUFBEREITET STATT EINGEBUNDEN (tools/buehne-bauen.mjs):
* stark abgedunkelt und leicht entsaettigt -- Stimmung, kein Motiv
* weiche Raender ins Bild EINGERECHNET. Ein hartes Rechteck saehe nach
aufgeklebtem Foto aus; und eine Maske ueber ein 900-Pixel-Bild kostet
bei jedem Bildaufbau Rechenzeit.
* 290 KB PNG -> 41 KB WebP, 110 KB -> 32 KB
Gerechnet mit dem Browser, der ohnehin fuer die Pruefungen da ist -- kein
Bildprogramm, keine neue Abhaengigkeit, 0 EUR.
GEPRUEFT WIRD NICHT, OB ES HUEBSCH IST, sondern ob der Text noch lesbar
ist -- an echten BILDPUNKTEN aus dem fertigen Bildschirmfoto, nicht an
der Farbangabe im Stil. Die weiss naemlich nichts davon, was
dahinterliegt. Gemessen wird der Untergrund direkt NEBEN jedem sichtbaren
Text, auf fuenf Seiten, auf Computer und Handy: bis zu 34 Stellen je
Seite gegen den WCAG-Massstab (4,5:1, bei grosser Schrift 3:1).
UND DAS HAT SOFORT EINEN ALTEN FEHLER GEFUNDEN: Der leiseste Grauton
(--text-still) lag bei 4,43:1 -- knapp UNTER der Norm. Das war schon
lange so, nur hatte es nie jemand nachgerechnet, weil bisher niemand an
echten Bildpunkten gemessen hat. Von #6d7d92 auf #75859a angehoben; jetzt
4,95:1 auf dem hellsten Untergrund. Das gilt fuer JEDE Seite, nicht nur
fuer die mit dem Hintergrundbild.
Schlechtester Wert jetzt: 4,97:1. Alle 30 Messungen bestanden.
Nebenbei eine Falle in den Pruefungen selbst: Ein haengengebliebener
Testserver auf demselben Port fing die Anfragen ab -- der Test sprach mit
einem ALTEN Prozess und dessen anderer Datenbank, und meldete "no such
table". Der Port ist jetzt ein anderer; die Lehre steht hier, weil das
Bild "Server laeuft" trotzdem erscheint und alles richtig aussieht.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7673c12136 |
Startseite: 17 eigene Farben -- gerechnet, nicht gewaehlt
Filipe: "jede kiste soll seine eigene farbe haben. und die kacheln sollen viel spezieller, viel spezieller sein." BEIM ERSTEN MAL HATTE ICH ABGELEHNT, und das war zu bequem. Mein Einwand stimmte zwar -- ein Versuch mit frei gewaehlten Farben ergab Paare mit 1,4 Grad Abstand, also praktisch dieselbe Farbe -- aber daraus "geht nicht" zu machen, war falsch. Es geht, man muss nur rechnen. Der Denkfehler war die Annahme, alle 17 muessten sich voneinander unterscheiden. Das Auge vergleicht aber nur, was NEBENEINANDER liegt. Also: 1. 17 Toene, gleichmaessig um den Farbkreis (je 21 Grad), gerechnet in OKLCH -- dort sind gleiche Abstaende auch fuer das Auge gleich. Helligkeit und Farbstaerke konstant, damit keine sich vordraengt. Wo die Farbstaerke den darstellbaren Bereich verliesse (Gelb und Gruen frueher als der Rest), wird sie gesenkt, bis sie hineinpasst. 2. Die ZUORDNUNG ist eine Suche ueber die tatsaechlichen Nachbarschaften im Raster (nebeneinander UND untereinander). Gesucht: die Anordnung mit dem groesstmoeglichen kleinsten Nachbarabstand. Ergebnis: mindestens 105,9 Grad zwischen allen Nachbarn. 3. Unter allen Anordnungen, die eine harte Untergrenze schaffen, gewinnt die passendste: LIVE rot, Technik gelb, Reports gruen, Personen rot-gold, Schutz stahlblau. Steht als tools/kachel-farben.mjs im Repo, mit festem Zufallsstartwert -- derselbe Lauf ergibt dieselben Farben. Wer Kacheln umsortiert, aendert die Nachbarschaften und muss es neu laufen lassen; das steht auch in start.js. Geprueft: Helligkeitsband, Farbstaerke und Kontrast bestehen fuer alle siebzehn gegen genau diesen Hintergrund. VIEL SPEZIELLER -- das WASSERZEICHEN: Jede Kachel traegt ihr eigenes Zeichen noch einmal, riesig, angeschnitten und fast unsichtbar (7 % Deckung) in der Ecke. Das ist der Grund, warum siebzehn Kacheln nicht mehr wie siebzehn Kaesten aussehen: Jede bekommt eine eigene grosse Form, ohne dass ein einziges zusaetzliches Bild geladen wird -- es ist derselbe Pfad, nur groesser. Bewusst so schwach, dass man es nicht liest, sondern nur spuert. Beim Ueberfahren wird es etwas deutlicher und wandert zwei Pixel. Dazu: Zeichenfeld 46 auf 52 px mit farbigem Schein darunter, Name auf 1,06 rem, mehr Polsterung. Alles mit prefers-reduced-motion abgesichert. 44 Pruefungen. Neu: dass jede Kachel eine EIGENE Farbe hat (17 Farben auf 17 Kacheln, gemessen an der berechneten Strichfarbe) und dass das Wasserzeichen da und schwach genug ist. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e25a22149b |
Startseite: groessere Kacheln, und das Licht folgt dem Zeiger
Rueckmeldung Filipe: "richtige richtung, die sollen nur bissl groesser
sein und noch bissl mehr spezieller."
GROESSER, gemessen statt geglaubt:
Zeichenfeld 38 -> 46 px (Dashboard 56)
Name .93 -> 1.02 rem (Dashboard 1.18)
Polsterung 14 -> 18 px, Ecken 15 -> 18 px
Kachelhoehe rund 60 -> ueber 80 px
Dabei fiel der eigene Test von vorhin sofort ein: Bei 880 px Seitenbreite
sind drei Kacheln je 285 px breit, und in den groesseren Schriften brach
der Text an ZWOELF Stellen ab. Statt die Schrift wieder zu verkleinern
bekommt die Startseite die volle Breite (1240 px) -- das ist die
ehrlichere Loesung. Hinweise, Begruessung und Fusstext behalten ihr Mass
von 940 px: Eine Textzeile ueber 1240 px zu ziehen macht sie nicht
lesbarer, sondern anstrengender.
SPEZIELLER, drei Dinge:
1. DAS LICHT FOLGT DEM ZEIGER. Jede Kachel traegt einen weichen
Lichtfleck. Er sitzt ruhend oben links und wandert unter dem Zeiger
mit. Kein Blinken, keine Bewegung des Inhalts -- es wird nur an einer
anderen Stelle heller. Das ist die Kleinigkeit, die man nicht sieht,
sondern erst beim Benutzen merkt.
EIN Zuhoerer fuer alle Kacheln statt siebzehn, und in einem Bild je
Rahmen: pointermove feuert dutzendfach je Sekunde, wer bei jedem
Ereignis in den Stil schreibt, laesst den Browser umsonst rechnen.
Beim Verlassen zurueck in die Ruhelage -- sonst blieben die Kacheln
nach einer Weile alle unterschiedlich beleuchtet stehen. Auf
Fingerbedienung und bei "weniger Bewegung" bleibt es ganz aus; dort
gibt es keinen Zeiger, dem etwas folgen koennte. Beides geprueft.
2. Eine feine helle Linie an der Oberkante jeder Kachel. Ein Pixel, kaum
sichtbar -- aber die Kachel wirkt dadurch von oben beleuchtet statt
aufgeklebt. Das Zeichenfeld bekommt denselben Lichtrand und einen
Verlauf, wodurch es gepraegt statt gemalt wirkt.
3. Beim Ueberfahren: farbiger Schein unter der Kachel im eigenen Ton,
die Kante links waechst von 3 auf 4 px, das Zeichen um 4 Prozent.
Alles unter zwei Pixeln Bewegung.
Die Trennlinie der Gruppenueberschriften laeuft nach rechts aus, statt
hart abzubrechen -- eine durchgezogene Linie zerschneidet die Seite, eine
auslaufende gliedert sie nur.
47 Pruefungen. Neu darunter: Zeichenfeld und Schriftgroesse werden
gemessen ("sieht groesser aus" ist kein Nachweis), und das Licht wird mit
echten Mausbewegungen an drei Stellen geprueft.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d05a772ee4 |
Startseite: aus siebzehn gleichen Rechtecken wird eine Uebersicht
Sie war eine Wand: siebzehn identische Kaesten, auf jedem stand "OEFFNEN".
Wenn alles gleich aussieht, ist alles gleich wichtig -- also nichts. Und
"OEFFNEN" ist keine Information; dass eine Kachel sich oeffnen laesst,
weiss man.
Drei Aenderungen, jede mit einem Grund:
1. GRUPPEN statt einer Liste. "Taeglich" (was man sowieso jeden Tag
aufmacht), "Rund um den Creator" (die Betreuungsakte), "Team & System"
(was den Laden am Laufen haelt). Das sind drei verschiedene Absichten.
2. ZAHLEN STATT "OEFFNEN". Auf der Kachel steht jetzt, wo Arbeit liegt --
"Aufgaben 4", rot markiert, weil etwas ueberfaellig ist. Gespeist aus
DERSELBEN Quelle wie die Hinweisliste darueber, kein zweiter Zaehler:
Zwei verschiedene Wahrheiten uebereinander auf einem Bildschirm waeren
schlimmer als gar keine Zahl.
3. ZEICHEN UND FARBE. Siebzehn eigene Linienzeichen (eigene Pfade, keine
Fremdbibliothek -- kleiner als jede Schriftart und keine zusaetzliche
Lieferkette) und acht Farbtoene.
Warum acht Toene und nicht siebzehn: Ich hatte zuerst eine eigene Farbe
je Kachel gebaut und das Ergebnis pruefen lassen. Zwei Paare hatten einen
Abstand von 1.4 und 5.6 -- also praktisch dieselbe Farbe. Das sieht nach
Zufall aus, nicht nach Absicht. Die acht jetzt verwendeten sind gegen
genau diesen Hintergrund gerechnet und bestehen alle Pruefungen
(Helligkeitsband, Farbstaerke, Farbfehlsichtigkeit dE 8.4,
Normalsicht 19.3, Kontrast). Verteilt so, dass in einer Zeile nie
zweimal derselbe Ton steht. Die Farbe stuetzt nur -- WAS eine Kachel
ist, sagen Zeichen und Name.
Dazu:
- Begruessung nach Tageszeit statt immer "Willkommen".
- Sechs Nullen nebeneinander sind Rauschen: Ist wirklich nichts offen,
steht dort ein Satz und der Platz gehoert den Bereichen.
- Die Hinweisliste stand mit sieben Zeilen im Weg. Jetzt vier sichtbar,
Rest auf Knopfdruck -- derselbe Helfer wie im Protokoll und im Verlauf.
- Gestaffelter Einlauf, aber in einer no-preference-Abfrage: Bei
"weniger Bewegung" entsteht gar keine Animation, nicht nur eine ohne
Dauer. Geprueft mit reducedMotion.
Beim Ansehen des ersten Bildes fielen abgeschnittene Untertitel auf
("Stammdaten, Ziele, 90-..."). Abgeschnittener Text ist der haeufigste
stille Fehler in einer Kachel, weil er nach Absicht aussieht. Texte
gekuerzt -- und der Test misst jetzt die tatsaechliche Textbreite gegen
die verfuegbare, damit es nicht wiederkommt.
40 Pruefungen, Computer und Handy, alle vier Rollen: Ein Creator sieht
"Mein Profil" statt der Liste aller Creator, keine Personenverwaltung,
keine Pipeline, keine Automationen -- und trotzdem drei saubere Gruppen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
