c64732b16d4f5bb8d6aef717e74ca44a907291da
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
d47ccf0d5f |
Die Blase hört auf, eine Farbfläche zu sein -- der Chat sieht anders aus
Filipe: „es hat sich nichts verändert quasi … auch die kachel das
aussehen. die blasen. die schriften. alles soll anders und geiler
aussehen, moderner und spezieller."
ER HATTE RECHT, UND ICH WEISS JETZT WARUM. Der erste Anlauf hat
poliert statt umgebaut -- weil ich die FARBE der Blase für unantastbar
gehalten habe. Genau sie war das Problem: Zwei Drittel jeder Nachricht
waren eine deckende, kräftige Fläche, und darauf kämpfte alles andere
um Aufmerksamkeit. Jede Feinheit, die man darauf legt, verschwindet.
DIE BLASE IST JETZT DUNKLES GLAS -- für jeden dieselbe. Die persönliche
Farbe ist vollständig erhalten, sie sitzt nur woanders:
* als leuchtende KANTE an der Sprechseite (links beim Gegenüber,
rechts bei einem selbst),
* im NAMEN, aufgehellt, damit auch ein dunkler Ton trägt,
* als Hauch im oberen Verlauf und als Schein unter der Blase.
Man erkennt die Person weiterhin an der Farbe -- und der Text steht
endlich auf einem ruhigen Grund.
DAZU: Die Fußzeile bekommt eine Kante in der Farbe und wird zur
Beschriftung (Versalien, gesperrt, gedämpft); die Uhrzeit trennt sich
von den fünf Handgriffen; die Blase wird schmaler (66 % / 62 Zeichen --
darüber verliert man beim Zeilenwechsel die nächste Zeile); der Text
bekommt Durchschuss, weil helle Schrift auf dunklem Grund optisch
ausstrahlt; das Zeichen neben der Blase spricht dieselbe Sprache wie
die Liste; die offene Gesprächszeile bekommt dieselbe Kante wie die
Blasen.
WAS DAS FÜR DIE MESSUNGEN HEISST -- und das ist der wichtigere Teil:
pruef-chatkachel und pruef-chat-neu haben bis heute gerechnet „Schrift
X auf Kachelfarbe Y". Das gibt es nicht mehr. Die eine wäre GRÜN
geblieben und hätte nichts mehr über den Bildschirm gesagt (die
gefährlichste Sorte, in diesem Haus schon dreimal vorgekommen), die
andere wurde sofort rot. Beide sind mitgezogen:
* Die feste Schrift wird gegen den festen Blasengrund gemessen --
und zwar im SCHLIMMSTEN Fall: Die Blase ist zu 92 % deckend,
dahinter liegt ein Foto, gerechnet wird mit Weiss dahinter.
Gemessen 14,2:1 (nötig 7) und 7,9:1 (nötig 4,5).
* NEU: Jede der 13 Kacheln UND alle 360 Töne des Farbrings müssen
als NAME auf diesem Grund lesbar sein. Das ist die Stelle, an der
es heute kippen kann.
* Beides liest `--blasengrund` und `--namen-anteil` aus chat.css
statt sie abzuschreiben. Wer dort etwas ändert, ändert die
Prüfung mit.
UND SIE HAT SOFORT ETWAS GEFUNDEN: Mit 58 % Aufhellung schaffte der Ton
„Ziegel" als Name nur 4,31:1 -- unter den nötigen 4,5. Auf dem
Bildschirm sah er gut aus, weil hinter der Blase gerade nichts Helles
lag. Jetzt 50 % und 5,20:1. Dazu eine Gegenprobe, die beweist, dass das
Aufhellen keine Zierde ist (ohne sie: 2,05:1).
DREI EIGENE FEHLER, ALLE VON PRÜFUNGEN GEMELDET
* 0,66 rem für die Fußzeile = 10,56 px, drei Stellen unter der
Hausgrenze von 11,5 px. Jetzt 0,72 rem; leise wirkt sie durch
Versalien und Deckung, nicht durch Kleinheit.
* Auf dem Handy brach die Fußzeile in drei Zeilen -- schuld war meine
eigene Regel `margin-right: auto` an der Uhrzeit, die am Rechner
richtig ist. Dort jetzt Kleinbuchstaben und kein Schub.
* Der Handy-Block stand MITTEN in der Datei. Eine Medienabfrage
erhöht die Spezifität nicht -- jede spätere Basisregel gewann
gegen ihn, und er wirkte halb. Er steht jetzt am Ende.
GEPRÜFT: chatkachel, chat-optik, chat-ausbau, chat, chat-neu,
chat-kanaele, css-klassen, lesbarkeit, tippziele — alle 0 Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7a6749630c |
Das Rudel meint den ganzen Raum -- und die Kachelfarbe wird ein Ring
Zwei Auftraege vom 23.09.2026.
SCREEN 1: "da steht links immer noch der treff anstatt das rudel"
Und er hatte recht, auf eine Art, die niemand sehen konnte:
TREFF_NAME stand schon seit der Umbenennung auf "Das Rudel". Nur
setzt treffRaumId() den Namen ausschliesslich BEIM ANLEGEN -- der
Raum existierte laengst, also blieb die Zeile in der Datenbank auf
"Der Treff" stehen. Im Code das eine, auf dem Bildschirm das andere.
Dieselbe Falle stand direkt nebenan schon beschrieben ("drei Stellen,
von denen die dritte vergessen wird") -- die Vorsorge galt aber nur
fuer die Teilnehmer, nicht fuer den Namen. Eine halbe Selbstheilung
heilt die andere Haelfte nicht. Jetzt gleicht treffAngleichen() auch
den Namen ab; eine kuenftige Umbenennung ist wieder eine Zeile.
(IS NOT statt !=: Bei NULL ergaebe != in SQLite NULL, und die Zeile
bliebe unveraendert liegen.)
"und wenn wir da im chat @rudel machen will ich dass jeder in dem
chat markiert wird. nicht nur team ... und sehr wichtig ich rede nur
von dem chat wo die ganze community auch drin ist."
Bis heute erreichte der Ruf ueberall nur Team Dogi. Die Begruendung
stand im Code und war nicht falsch -- im Rudel-Raum sitzt die
Community. Genau das will Filipe jetzt, und zwar nur dort:
im Rudel-Raum -> alle, die drin sind
ueberall sonst -> Team Dogi, unveraendert
Was die alte Sorge entschaerft: RUFEN darf weiterhin nur Team Dogi --
kein Zuschauer kann alle wecken. Und die Nachtruhe gilt dort ohnehin.
darf_rudel folgt derselben Frage. Sonst entstuende ein stiller
Widerspruch: Ein Modi mit neun Zuschauern und ohne zweites
Teammitglied traefe mit @rudel neun Leute -- der Vorschlag beim
Tippen waere aber ausgeblendet. Die Funktion gaebe es, und niemand
faende sie.
Das Schild sagt jetzt die Wahrheit: "alle in diesem Chat" statt
"alle im Team". Stuende dort weiter das alte, waere es im Rudel-Raum
gelogen -- und zwar nach unten, also in die Richtung, in der man
leichtfertig drueckt.
Gegenprobe in pruef-erwaehnung: In der Testgruppe sitzen DogFather
und zwei Scouts; ein @rudel dort ruft NIEMANDEN. Waere die Regel
versehentlich im ganzen Haus aktiv, waeren die Scouts markiert.
"sonst nichts anfassen" ist damit gemessen, nicht versprochen.
SCREEN 2: "so eine art diagramm, wo man mit einem kreis herum gehen
kann und die farbe ganz genau selber auswaehlen kann"
Der Haken daran ist nicht die Optik. Die zwoelf Kacheln waren
GERECHNET, damit niemand sich unlesbar machen kann -- alle auf
derselben Leuchtdichte. Ein Farbkreis, der einfach den Farbton dreht,
wirft das weg: Ein gesaettigtes Gelb ist um ein Vielfaches heller als
ein gesaettigtes Blau, und helle Schrift ist darauf nicht mehr zu
lesen.
Der Ring ist deshalb KEINE neue Rechnung, sondern dieselbe in 360
Schritten statt in zwoelf. tools/chat-kacheln-rechnen.mjs --kreis
schreibt server/chat-kreis.js; buntest() und die Kontrastpruefung
darin gelten unveraendert. Ergebnis: ein Ring gleicher Helligkeit --
kein blendendes Gelb, kein abgesoffenes Blau. Das sieht ruhiger aus
als der uebliche Farbkreis, und genau das ist der Punkt.
Der Browser rechnet nichts. Er bekommt die 360 fertigen Farben und
legt sie in dieselbe Tabelle wie die Kacheln -- ab da ist "ton-214"
ein Schluessel wie "veilchen", und jede Stelle, die eine Farbe
nachschlaegt, funktioniert unveraendert.
Welche Kacheln neben dem Ring bleiben, wird ABGELEITET statt
aufgezaehlt: Grau hat keinen Farbton, Babyblau ist die eine helle mit
eigener Schrift. Nachgemessen liegen die elf bunten zwischen 0,0 und
2,4 von ihrer Ringfarbe entfernt, Grau bei 75,4 und Babyblau bei
192,9 -- zwischen 2,4 und 75 ist so viel Luft, dass die Schwelle
nicht knapp ist.
Gespeichert wird erst beim Loslassen. Wer einmal um den Ring fuehrt,
erzeugte sonst dreihundert Anfragen.
Gemessen (pruef-chat-neu, jetzt 32 Pruefungen, als Modi auf crew. mit
dem Finger): 265 px gross, aus 361 Farben gemalt, touch-action none
(sonst schiebt das Handy die Seite weg statt zu drehen), Drehen auf
drei Uhr ergibt genau Winkel 90, die Mitte zeigt exakt #675102,
vorgelesen als "Goldbraun, 90 Grad", in der Datenbank steht ton-90,
Pfeiltaste dreht ein Grad weiter. Und das eigentliche Versprechen:
alle 360 Toene tragen die Schrift der Blase, knappster Faktor 1,000.
Dabei zwei eigene Fehler, beide aufgeschrieben: Der erste Anlauf
wartete 30 Sekunden auf den Farbknopf -- am Handy weicht die Spalte
mit den Gespraechen zur Seite, sobald ein Chat offen ist. "Ist im
HTML" und "ist erreichbar" sind zwei Aussagen. Und die Schriftfarben
wurden an der falschen Klasse gemessen, was einen roten Haken an
einer heilen Stelle ergab.
Ausserdem: Das native confirm() beim Herausnehmen eines GIFs ist
weg -- meine eigene Abkuerzung vom Morgen. Gemeldet hat es
pruef-nachfrage, allerdings erst, nachdem der verlorene Backslash in
derselben Datei repariert war.
Zahlen: pruef-erwaehnung 122 (vorher 119), pruef-chat-neu 32
(vorher 19), pruef-nachfrage 46 bestanden.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
c0d2896419 |
pruef-chat-neu: die drei neuen Sachen am Stueck, als Modi, auf dem Handy
Jedes Stueck war geprueft -- und jedes in einer anderen Lage als der
echten:
pruef-chat-anhaenge Sprachnachricht und GIF, aber als DogFather
auf der AGENTURadresse, mit der Maus
pruef-erwaehnung der Rudel-Ruf, aber gegen den Server
Der Fall, den Filipe wirklich hat -- ein MODI auf crew., mit dem
FINGER, und ein zweiter Mensch, der es bekommen soll -- war nie am
Stueck gemessen. Genau in solchen Luecken sitzen die Fehler, die
niemand sieht: Jeder Einzeltest ist gruen, und zusammen geht es
trotzdem nicht.
ZWEI BROWSER, ZWEI MENSCHEN. Eine Sprachnachricht, die nur beim
Absender im Verlauf steht, ist keine. Jede der drei Proben wartet
deshalb darauf, dass die ZWEITE Person sie von selbst bekommt -- ohne
Neuladen.
19 Pruefungen, 0 Fehler:
* Sprachnachricht: Knopf da, Zeit laeuft, Blase mit Laenge, passt auf
390 px, kommt bei der zweiten Modi an
* GIF-Kiste: passt auf den Bildschirm, sagt was zu tun ist, GIF
hineinlegen, verschicken, ankommen -- und die zweite Modi sieht
dasselbe GIF in IHRER Kiste (sie gehoert dem Rudel)
* Rudel-Ruf: das @ oeffnet die Liste, "rudel" steht oben mit "alle im
Team" daneben, 44 px hoch, im Bild; die Nachricht kommt an, der Ruf
leuchtet beim Empfaenger (Gewicht 700), und in der Datenbank stehen
genau die Richtigen -- die andere Modi und DogFather, nicht der
Rufer selbst
ZWEI EIGENE FEHLER BEIM BAUEN, beide in der Datei aufgeschrieben, weil
sie sich wiederholen werden:
(1) OHNE NOTBREMSE. Der erste Lauf blieb stehen und sah von aussen
aus wie "laeuft noch" -- ich musste ihn von Hand abbrechen. Ein
Werkzeug, das haengt, ist schlimmer als eines, das scheitert;
das steht seit dem 06.09. in den Hausregeln, und ich habe es
beim Bauen eines Wegwerf-Werkzeugs trotzdem weggelassen.
(2) MIT ENTER ABGESCHICKT. Auf einem Beruehrgeraet schickt Enter
ABSICHTLICH nicht ab -- sonst kaeme man nie zu einer zweiten
Zeile. Die Messung meldete daraufhin "kommt nicht an"; in
Wahrheit war nie etwas abgeschickt worden. Dasselbe Muster wie
beim `pointer: coarse` heute frueh: Wer im falschen
Geraeteprofil misst, misst ein anderes Programm.
Die Datei ist aus einem Wegwerf-Werkzeug entstanden. Sie bleibt, weil
der Weg, den sie geht, sonst von keiner Pruefung gegangen wird.
pruef-ports: 8 von 8 -- die neue Datei verschiebt die Portnummern
aller spaeteren, und das haelt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|