db8dd2fbea4044e09285b7647331c4d85e68e7b8
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
db8dd2fbea |
147 Zeichen je Zeile -- am Kontrast lag es nicht
Filipe: „nur die kacheln noch viel geiler. so dass ich die texte auch
besser erkenne."
NAHELIEGEND WAERE GEWESEN, die Farben aufzuhellen. Erst gemessen,
dann gebaut -- und die Vermutung war falsch:
Kontrast .s-karte__text 15,7 : 1 (noetig 4,5)
Kontrast aller zehn Textarten 7,5 bis 15,7 : 1
ZEICHEN JE ZEILE 147 (angenehm 45-75)
Am Kontrast lag es nicht; der ist ueberall ueppig. Es lag an der
ZEILENLAENGE. Auf 1280 px lief der Meldungstext ueber die ganze
Kartenbreite: 1120 px, knapp 150 Zeichen. Beim Zeilenwechsel findet
das Auge die naechste Zeile nicht mehr sicher -- man liest dieselbe
zweimal oder ueberspringt eine. Das ist der groesste Hebel beim
Lesen, und er kostet nichts.
GEAENDERT
Meldungstext 15,2 -> 17 px, max-width 72ch, Zeilenhoehe 1.6
Verlaufstext 14,4 -> 15,2 px, max-width 70ch
Kartenrand 16/18/15/22 -> 18/20/16/24 px
Trennlinie zwischen Meldung und Verlauf
147 -> 78 Zeichen je Zeile (PC), 39 auf dem Handy
`ch` UND NICHT PIXEL: `ch` ist die Breite der Null und waechst mit
der Schrift mit. Eine Angabe in Pixeln waere bei der naechsten
Schriftgroesse wieder falsch -- dieselbe Falle wie jede feste Zahl.
MEHR RAND, WEIL DIE SCHRIFT GEWACHSEN IST. Bei unveraendertem Rand
haette sie die Kante beruehrt, und die Karte waere voller gewirkt
statt lesbarer. Links bleibt es breiter: dort laeuft die
Leuchtschiene in der Farbe des Stands.
DIE TRENNLINIE kostet einen Pixel und beantwortet „wo hoert die
Meldung auf und wo faengt die Vorgeschichte an?". Vorher lief beides
ohne Zaesur ineinander.
EIN FEHLER IN MEINER EIGENEN MESSUNG -- und er haette Schaden
angerichtet
Die erste Fassung der Kontrastrechnung meldete fuer drei gut lesbare
Texte einen Kontrast von 1,04. Ich war nah dran, Farben zu
„reparieren", die in Ordnung sind.
Der Grund: `rgb()` zaehlt 0..255, `color(srgb …)` zaehlt 0..1 -- und
genau das liefert Chrome fuer jedes `color-mix()`. 0,77 als 0,77/255
gelesen ist fast Schwarz. Aufgefallen ist es nur, weil die Zahl
nicht zum Bildschirmfoto passte: Dort waren die Texte deutlich
lesbar.
DESHALB STEHT IN DER PRUEFUNG EINE GEGENPROBE IM BROWSER: Ein
absichtlich zu blasser Absatz wird eingehaengt und MUSS auffallen
(gemessen 1,23 : 1). Ohne sie waere „alle ueber 4,5" auch dann
gruen, wenn die Rechnung kaputt ist -- und genau das war sie.
GEPRUEFT -- pruef-support-bilder 56 -> 64 ok
9 Textarten in der Karte gemessen
der Meldungstext ist 16.96 px gross (mindestens 16)
und bricht nach etwa 78 Zeichen um (hoechstens 85, vorher 147)
der Verlaufstext: 15.2 px, etwa 75 Zeichen
jeder Text haelt die Kontrastschwelle (0 darunter)
— schwaechster 7.55 : 1
Gegenprobe: ein absichtlich blasser Text faellt auf (1.23 : 1)
auf 390 px ragt mit der groesseren Schrift nichts heraus (0 px)
und die Zeile bleibt lesbar lang (etwa 39 Zeichen)
Dazu gruen: pruef-css-klassen · pruef-fingermass.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a1c2d49260 |
Drei Bilder konnte man schon -- nur sagte es niemand
Filipes Frage: „koennen die leute auch schon mehrere fotos schicken wenn die im support was melden wollen?" Technisch seit dem 02.10. (VanVans Meldung #11), und heute mehrfach am laufenden Server nachgemessen. Beim Nachsehen auf der SEITE stand aber: Knopf: „Bild anhängen" -- Einzahl Unterzeile: „häng ein Bild dran" -- Einzahl daneben: (nichts) Wer nicht zufaellig ein zweites Mal auf den Knopf tippt, schickt eines. Aus seiner Sicht waere VanVans Meldung ungeloest -- und er haette recht. EINE MOEGLICHKEIT, VON DER MAN NICHTS WEISS, GIBT ES NICHT. Das ist dieselbe Sorte wie ein Knopf, der eine Absage holt, nur andersherum: Dort verspricht die Oberflaeche zu viel, hier zu wenig. Beides kostet denselben Menschen dieselbe Zeit. GEAENDERT Knopf: „Bilder anhängen" Unterzeile: „häng Bilder dran" daneben: „bis zu 3 Bilder" -- bevor man etwas waehlt nach einem: „eins.png · 24 KB · noch 2 möglich" Die letzte Zeile ist die wichtigere von beiden: „eins.png · 24 KB" allein sagt nicht, dass ein zweites geht -- und genau an dieser Stelle hoert jemand auf. DIE ZAHL KOMMT VOM SERVER (`bilder_max`) und wird neu geschrieben, sobald sie da ist. Ohne das stuende beim ersten Laden der Vorgabewert dort -- heute zufaellig derselbe, morgen vielleicht nicht. Eine Zahl, die zufaellig stimmt, ist keine Auskunft. GEPRUEFT -- pruef-support-bilder 52 -> 56 ok der Knopf steht in der Mehrzahl („Bilder anhängen") und daneben steht, wie viele gehen („bis zu 3 Bilder") auch die Unterzeile sagt nicht mehr „ein Bild" und daneben steht, dass noch Platz ist („eins.png · 0 KB · noch 2 möglich") Dazu gruen: pruef-zeichen 7 · pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ae5b467e9a |
Der Supportverlauf: eine Zeitachse, eine Farbe je Runde
Filipe: „ich will diese komplette seite vom support viel
uebersichtlicher, profissioneller, jede runde soll auch immer eine
spezielle farbe haben und anders aufgestellt aufgeteilt sein damit
man einen viel besseren und krasseren ueberblick hat."
WAS VORHER DASTAND -- an einem Bild mit zwei Runden nachgesehen,
bevor eine Zeile angefasst wurde: vier Textzeilen untereinander,
alle in derselben Farbe. „RUNDE 1", Antwort, „Ging noch nicht · …",
„RUNDE 2". Bei fuenf Runden muss man die Runden ZAEHLEN, statt sie
zu sehen -- und wer spricht, stand nur als kleiner Name daneben.
VIER TEILE SIND NEU
1. EINE LEISTE OBEN. Ein Punkt je Runde, in ihrer Farbe, mit ihrer
Nummer -- und der Rand sagt, wie sie ausgegangen ist. Damit ist
„wie oft ging es schon hin und her?" eine Frage des Hinsehens.
Erst ab zwei Runden: bei einer waere sie ein Punkt neben nichts.
2. EINE ZEITACHSE statt einer Liste. Jede Runde haengt mit einem
Punkt an einer Linie in IHRER Farbe. Die Linie ist ein Rand an
der Runde selbst, nicht am Behaelter -- so traegt jede ihr
eigenes Stueck Achse.
3. ZWEI SPRECHRICHTUNGEN je Runde, als getrennte Kaesten:
„GEANTWORTET" in der Rundenfarbe, darunter „GING NOCH NICHT"
(Bernstein) oder „GEHT WIEDER" (gruen) oder „WARTET AUF
ANTWORT". Vorher standen beide Saetze als Absaetze untereinander
und sahen gleich aus; man musste lesen, um zu wissen, von wem
sie sind. Jetzt sagt es die Form.
4. DIE LETZTEN ZWEI OFFEN, aeltere hinter „3 fruehere Runden
zeigen". Die Leiste sagt ohnehin, wie viele es gab; im Wortlaut
braucht es nicht alle. Zwei und nicht eine: Die letzte sagt, wo
es steht, die vorletzte, woran es davor lag.
DIE FARBE WIRD GERECHNET, NICHT GEPFLEGT
`rundenTon(nr)` gibt 200 + ((nr-1) mod 4) * 32 Grad. Eine Liste mit
fuenf Farben waere die naheliegende Loesung und die falsche: Runde
sechs bekaeme keine. Diese Sorte Liste hat im Haus schon dreimal
etwas gekostet.
DER BEREICH IST ENG UND ABSICHTLICH: 200 bis 296 Grad, Blau ueber
Indigo nach Violett -- die Palette der Seite (babyblau mit lila) und
der Bereich, in dem KEINE Farbe nach „gut" oder „schlecht" aussieht.
Gruen und Bernstein sind fuer den AUSGANG reserviert; waere eine
Rundenfarbe rot, stuenden zwei Aussagen in einer Farbe.
AUGENSCHONEND: 52 % Saettigung, 64 % Helligkeit -- fuer alle Toene
gleich, und nur im CSS. Sonst waere Runde drei blasser als Runde
eins, und augenschonend ist das Gegenteil von zufaellig. Kein Neon,
kein Gluehen. Die Farbe ordnet Zeilen zu; sie schreit nicht.
UND DIE FARBE ALLEIN TRAEGT NICHTS: Die Nummer steht daneben, der
Ausgang in Worten. Fuer Vorleseprogramme gibt es statt elf Punkten
einen Satz.
EIN FUND UNTERWEGS: DIE MESSUNG MASS SEIT ZWEI TAGEN NICHTS
`mess-support-runde.mjs` schickte die Rueckmeldung noch als JSON.
Am 02.10. ist die Route auf den Kopf-Weg umgestellt worden
(`x-geht`, `x-text`); seither antwortete sie mit 400. Gemerkt hat es
niemand, weil diese Datei Bilder macht und keine Rueckgabewerte
prueft: Auf dem Bild stand danach EINE Runde statt vier, und das
sieht aus wie ein Ergebnis. Aufgefallen ist es erst, als die Bilder
vier Rundenfarben zeigen sollten.
Eine Messung, die nach einem Umbau stillschweigend etwas anderes
misst, ist schlimmer als keine -- man glaubt ihr. Sie meldet den
Fehlschlag jetzt mit Code und Text.
GEPRUEFT -- pruef-support-bilder 39 -> 52 ok
die Leiste zeigt jede Runde (5 Punkte) · mit ihrer Nummer
die ersten vier Runden haben vier verschiedene Farben (4)
und die fuenfte faengt die Reihe wieder von vorn an
Gegenprobe: sie sind nicht alle gleich (4 Farben)
auch die Rundennummern tragen ihre Farbe (2 von 2)
offen stehen die letzten zwei Runden (2)
und die aelteren sind einen Griff entfernt
jede Runde zeigt beide Seiten
aufgeklappt stehen alle da (5) · und wieder zu
auf 390 px ragt nichts heraus (0 px)
bei einer einzigen Runde gibt es keine Leiste (0)
Die Gegenprobe „sie sind nicht alle gleich" ist die wichtigste:
Waere `--ton` nicht angekommen, waeren alle Punkte grau -- und „vier
Punkte" waere gruen gewesen, ohne dass eine Farbe zu sehen ist.
Gemessen wird die ANGEZEIGTE Farbe, nicht die Zahl im Attribut.
Dazu gruen: pruef-support 104 · pruef-css-klassen · pruef-zeichen 7 ·
pruef-fingermass 5.
Eine Schriftgroesse musste nachgebessert werden: .7rem sind 11,2 px,
und unter 11,5 px faengt im Haus die Grenze an, ab der man
zusammenkneift.
NUR DAS AGENTURHAUS: Die Supportseite liegt unter `/workspace`.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
63211252d2 |
VanVans Satz hatte zwei Haelften -- gemessen war eine
Meldung #11, Runde 2, woertlich: „man kann nicht mehrere Bilder zum hinzufuegen AUSWAEHLEN. Und wenn man es NACHEINANDER versucht hinzuzufuegen wird das Bild immer nur ersetzt" Das NACHEINANDER stand seit gestern in der Pruefung -- es war die Haelfte, die ich kaputt gebaut hatte und die mir deshalb im Kopf war. Das AUSWAEHLEN nicht: drei Dateien in EINEM Griff, so wie der Dateidialog sie uebergibt, wenn man sie mit gedrueckter Taste markiert. Das haengt am `multiple` im Feld, und ohne Messung war es eine Behauptung im HTML. Aufgefallen beim Durchgehen ihres Satzes Wort fuer Wort, nachdem Filipe auf den Screenshot gezeigt hat. Kaputt war nichts -- aber unbewiesen, und das ist derselbe Zustand wie ungeprueft, nur mit besserem Gefuehl. NEU GEPRUEFT drei auf einen Griff ausgewaehlt ergeben drei (3) und zwar in der Reihenfolge des Dialogs das Feld laesst Mehrfachauswahl ausdruecklich zu (multiple) Die letzte Zeile ist die Gegenprobe zur ersten: Ohne `multiple` gaebe der Browser nur EINE Datei weiter, egal wie viele man markiert -- und die Drei darueber koennte auch aus drei einzelnen Griffen stammen. Gemessen wird deshalb das Merkmal selbst. Davor wird ausdruecklich alles geleert („Alle weg"), sonst misst die Zeile, was vorher schon dastand. GEPRUEFT -- pruef-support-bilder 36 -> 39 ok AUSSERDEM HEUTE AM LAUFENDEN SERVER NACHGEMESSEN (Meldung #11, auf einer Kopie der echten Datenbank, eigener Port, nichts im Live-System): er nennt die Grenze: 3 die Meldung geht durch (201) · alle drei haengen dran (3) jedes kommt in SEINER Reihenfolge und mit SEINEM Typ zurueck (3/3) vier werden abgelehnt, mit einem Satz der alte Einzelbild-Weg ist weg (404) — es gibt nur noch einen Und: Die Dateien, die VanVans Browser laedt, sind Byte fuer Byte die geprueften -- support.js und support.css haben live dieselbe Pruefsumme wie hier. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b31bd9b515 |
Zwei bis drei Bilder je Supportmeldung -- und zwei Funde unterwegs
VanVan im Support, Meldung #11, VIERMAL gemeldet: „Hier im Supportbereich kann man immer nur ein Bild hinzufuegen bei einer Meldung. 2-3 waeren besser." Und in der zweiten Runde der Satz, auf den es ankommt: „wenn man es nacheinander versucht hinzuzufuegen wird das Bild immer nur ersetzt." EINE TABELLE STATT NEUER SPALTEN `support_bilder` haelt ab jetzt JEDES Supportbild -- das der Meldung (`runde_nr` NULL) und das einer Antwort (`runde_nr` = Runde). Die Alternative waere `bild2_datei`, `bild3_datei` gewesen, und beim vierten Bild wieder. Eine Zeile je Bild kennt keine Obergrenze im Schema; die Grenze steht an EINER Stelle im Code (`BILDER_MAX = 3`) und kommt von dort in die Oberflaeche, statt dort ein zweites Mal zu stehen. DIE ACHT VORHANDENEN BILDER WANDERN MIT. Ohne diesen Schritt haette die neue Tabelle ab heute recht und die alten Bilder waeren unsichtbar -- ohne Fehler, ohne rote Zeile, nur acht leere Karten. Der Umzug steht NACH der Spaltennachruestung: Er liest `urteil_bild_datei`, und die gibt es in einer bestehenden Datenbank erst, nachdem sie ergaenzt wurde. Stuende er davor, scheiterte er genau dort, wo es darauf ankommt -- live, waehrend lokal alles gruen bliebe, weil jede Pruefung ihre Datenbank frisch anlegt. DREI BILDER IN EINER ANFRAGE `x-bilder: 20481,15320` sagt, wo zu schneiden ist, der Rumpf ist die Aneinanderreihung. `multipart/form-data` haette einen Zerleger gebraucht, den dieses Haus nicht hat; drei Anfragen nacheinander haetten den Zustand „Meldung da, Bild zwei laedt noch" erzeugt -- genau den, gegen den die Kommentare an dieser Route schon vorher argumentieren. Die Summe muss auf das Byte stimmen, und jedes Stueck wird einzeln an seinen ersten Bytes erkannt: Wer falsch schneidet, bekommt eine Absage, kein verfaelschtes Bild. Ohne den Kopf gilt der ganze Rumpf als ein Bild -- derselbe Satz mit einer Laenge, damit eine Seite aus dem Zwischenspeicher weiterlaeuft. EINE ROUTE STATT DREI. `/:id/bild` und `/:id/runde/:nr/bild` sind weg; es gibt `/:id/bild/:bid`. Wohin ein Bild gehoert, steht in seiner Zeile -- der Weg muss es nicht wiederholen. Die Meldungsnummer bleibt trotzdem im Pfad: Sie ist die Sichtbarkeitsfrage, und beides muss zusammenpassen (gemessen). ZWEI FUNDE, DIE DIE PRUEFUNG GEMACHT HAT UND NICHT ICH 1. UEBER DIE SEITE KAM GAR KEIN BILD MEHR AN. Beim Melden stand kein `Content-Type`. Das ging gut, solange der Rumpf eine einzelne Datei war -- ein `File` bringt seinen Typ mit. Ein `Blob` aus mehreren hat keinen, `fetch` schickt die Zeile dann gar nicht, `express.raw` fuehlt sich nicht zustaendig, und der Server bekam einen leeren Rumpf. Die Meldung waere durchgegangen, der Text angekommen, die Bilder weg -- ohne Fehlermeldung. Alle Pruefungen am Server waren dabei gruen; gefunden hat es erst der echte Browser. 2. DAS KREUZ DES DRITTEN BILDES LAG AUF DEM ZWEITEN. Der Entfernen-Knopf ist 44 px breit und absolut gesetzt, der Kasten aber nur so breit wie sein Bild. Bei einem schmalen Bild ragt er darueber hinaus -- wer „das zweite weg" antippt, loescht das dritte. `min-width`/`min-height` loesen das an der Ursache: Ein Kasten ist nie schmaler als der Knopf in ihm. WAS ICH FALSCH ANGENOMMEN HATTE: Ich hatte eingebaut, dass ein Nachtrag in derselben Runde die Bilder ersetzt. Die Pruefung dazu wurde rot -- zu Recht: Eine zweite Antwort in derselben Runde kann es nicht geben, die erste verlaesst den Stand „wartet". Der Code waere nie gelaufen und damit nie pruefbar gewesen. Er ist weg; an seiner Stelle steht der Beweis, dass er nicht fehlt. DREI WEITERE ROTE ZEILEN, DIE NICHT ZU DIESEM UMBAU GEHOERTEN * `manager-ziele.js` hatte einen ZWEITEN Notnagel (`frageNach ? … : confirm(…)`). `nachfrage.js` hat denselben laengst, und zwar mit dem vollstaendigen Text; der hiesige war der kuerzere und haette gewonnen. Zwei Antworten auf dieselbe Frage -- gemeldet von `pruef-nachfrage`. * Zwei Mittelpunkte in `reaktion.css` standen woertlich im `content`. Sie liegen im Latin-1-Block, wo `pruef-zeichen` die Truemmer einer verunglueckten Kodierung sucht. Jetzt als Escape -- im Browser nachgemessen, es steht Zeichen fuer Zeichen dasselbe da. * Das Aufraeumen nach 90 Tagen loeschte nur das EINE Bild der Meldung; die Bilder aus den Antwortrunden blieben ohne Zeile auf der Platte liegen. Die Liste kommt jetzt aus einer Abfrage statt aus einer Spalte und kann deshalb nicht wieder unvollstaendig sein. GEPRUEFT pruef-support 78 -> 104 ok darunter: der Umzug der alten Bilder auf einer eigenen Wegwerf-Datenbank -- zweimal und dreimal gestartet, nichts verdoppelt, Datum von damals erhalten pruef-support-bilder NEU, 36 ok (echter Browser) dreimal nacheinander waehlen ergibt drei, das vierte wird mit einem Satz abgelehnt, dasselbe zaehlt nicht doppelt, einzeln entfernen laesst die anderen stehen, alle drei laden wirklich (naturalWidth), Kreuze 44x44 und keines verdeckt (mit Gegenprobe per Deckel), nichts ragt auf 390 px heraus pruef-nachfrage 69 -> 74 ok pruef-struktur 102 ok, 413 Routen (vorher 414: zwei weg, eine neu) pruef-zeichen 7 ok (vorher 1 Fehler) pruef-aufbewahrung 45 ok pruef-manager-ziele 216 ok pruef-ports 10 ok · pruef-portnummern 41 ok (die neue Pruefdatei verschiebt die abgeleiteten Nummern) NUR DAS AGENTURHAUS IST BETROFFEN. Die Supportseite liegt unter `/workspace`; am Crew-Haus aendert sich keine Zeile. Co-Authored-By: Claude Opus 5 <[email protected]> |