2 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	d7cf598b00	"Heute" war zwei Stunden lang gestern -- und vier Fehler auf Handy und PC ... Auftrag: "einen grossen Check machen, ob alles klappt, auf dem Handy und PC." Dafuer ein neuer Rundgang (pruef-grosscheck.mjs), der stumpf ueber alles geht: 19 Workspace-Seiten mal 4 Rollen mal 2 Bildschirmgroessen plus 33 oeffentliche Seiten, zweimal. 208 Seiten, 50 774 Elemente. Solche Rundgaenge finden andere Fehler als gezielte Pruefungen: nicht den falsch gerechneten Wert, sondern die Seite, die bei genau einer Rolle ueberlaeuft. === DER WICHTIGSTE FUND: "heute" war in UTC gerechnet === Der Check lief um 01:10 Uhr. Ortszeit war der 2. September, in UTC noch der 1. -- und in diesem Fenster rechnete die Anwendung an ZWOELF Stellen "heute" als toISOString(), also in UTC. Server und Benutzer stehen beide auf Europe/Berlin. Was das im Alltag bedeutete, jede Nacht zwischen 0 und 2 Uhr: * eine heute faellige Aufgabe galt noch nicht als faellig * eine um Mitternacht ueberfaellig gewordene erschien erst um 2 Uhr * der Filter "Heute faellig" zeigte den Vortag * Datumsfelder schlugen gestern vor * der Kalender begann seine Vorgabe einen Tag zu frueh Also genau dann, wenn nach einem Stream gearbeitet wird. kalender.js machte es die ganze Zeit RICHTIG -- samt Begruendung, warum die ARITHMETIK trotzdem in UTC laufen muss (UTC-Mittag ueberlebt die Zeitumstellung; wer lokal rechnet, verliert am 27. Oktober einen Tag). Diese Trennung gilt jetzt ueberall, aus je einer Quelle: RECHNEN mit Datumsangaben -> UTC-Mittag, unveraendert WELCHER TAG IST HEUTE -> Ortszeit (heuteLokal/tagLokal im Server, window.heuteLokal in kopf.js) WIE ES AUFFIEL, und das ist die eigentliche Lehre: Zuerst schlugen zwei Pruefungen fehl -- und die Ursache lag in IHNEN, sie rechneten selbst in UTC (36 Stellen in 17 Dateien). Nach deren Reparatur schlugen sie WIEDER fehl, und erst da zeigten sie auf die Anwendung. Wer beim ersten Mal aufgehoert haette ("ist ja nur die Pruefung"), haette den echten Fehler nie gesehen. Nachtrag desselben Musters: pruef-uebersicht legte den Termin weiterhin in UTC an, waehrend die Erwartung schon auf Ortszeit stand. Wer eine Datumsrechnung umstellt, muss BEIDE Seiten umstellen -- die, die schreibt, und die, die prueft. === VIER FEHLER AUF HANDY UND PC === 1. Ein langer Creator-Name ("SpongBobSchwammKopf") schob die Startseite auf dem Handy um 48 Pixel aus dem Bild -- ein Wort ohne Trennstelle, und die Seite liess sich seitlich wegschieben. Trifft echte Namen: Creator heissen selten "Tim". 2. Die klebende Speicherleiste verdeckte auf dem Handy ein Textfeld. Beim Tippen sieht man die eigene Zeile nicht. Behoben mit scroll-margin-bottom (WCAG 2.2, 2.4.11 "Focus Not Obscured"). 3./4. Zwei Beschriftungen waren mit 9,6 px (Uebersicht: "ueberfaellig", "dringend", "offen") und 9,9 px (Kalender: "heute") zu klein. Fuers Handy gab es laengst eine Ausnahme -- nur der Rechner war vergessen worden. Ausgerechnet die Woerter, die den Zahlen ihre Bedeutung geben. === WAS KEINE FEHLER WAREN === Der erste Durchgang meldete 19 Maengel, die keine waren. Alle einzeln im Quelltext nachgeprueft und dem Rundgang beigebracht: * Kacheln und Kopfzeilen "abgeschnitten" -- das Wasserzeichen ragt ABSICHTLICH ueber den Rand (steht so im Quelltext) * "verdeckt: wahl2__echt" -- das echte <select> liegt absichtlich unsichtbar unter seinem Knopf * "zurueck-knopf__text abgeschnitten" -- das uebliche Muster fuer "nur fuer Vorleseprogramme" * drei "zu kleine" Verweise -- WCAG 2.5.8 nimmt Verweise im Fliesstext AUSDRUECKLICH aus. Eine Pruefung, die ihre eigene Messlatte nicht kennt, misst nichts. Beim vierten Punkt haette ich fast an der falschen Stelle repariert. Und statt die Sticky-Meldung abzuschalten (dann faende sie auch echte Ueberdeckungen nie mehr), wurde sie GENAUER: Ueberdeckt etwas Klebendes ein Eingabefeld, ist das nur in Ordnung, wenn das Feld genug scroll-margin-bottom hat, um darunter hervorzukommen. Aus einer vagen Meldung wird eine pruefbare Zusage. Vier Gegenproben belegen, dass der Rundgang ueberhaupt etwas finden kann: ein zu breites Element, ein winziger Knopf, ein winziger Verweis AUSSERHALB eines Satzes und ein wirklich abgeschnittenes Wort werden alle gemeldet. Ohne diesen Nachweis waere "alles in Ordnung" wertlos. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-02 01:51:28 +02:00
DogFatherGitandClaude Opus 5	372a0eb95a	Ampel und Rueckmeldungen - bewerten darf nur die Betreuung ... Der Wunsch: "der Creator sieht, ob es gut ist oder schlecht. Und wenn nicht gut, dann muss es verbessert werden -- und nur der Ansprechpartner kann das aendern. Die Creator koennen nur Nachrichten hinterlassen zum Kommunizieren." ZWEI GETRENNTE DINGE, und sie getrennt zu halten ist der ganze Punkt: DIE AMPEL ist eine Beurteilung. Sie gehoert dem Betreuer, und nur er setzt sie. Koennte ein Creator sich selbst auf gruen stellen, waere sie wertlos -- dann stuende ueberall gruen. Der Server lehnt es mit 403 ab und sagt dabei, wer es kann. DIE NACHRICHT ist ein Gespraech. Sie gehoert beiden. Ein Creator, der auf eine Bewertung nicht antworten kann, bekommt ein Urteil statt einer Betreuung. DREI STUFEN, NICHT FUENF. Eine Zahl von 1 bis 5 klingt genauer und ist es nicht: Niemand kann den Unterschied zwischen 3 und 4 erklaeren, und am Ende steht ueberall die 3. Die Frage lautet "reicht das schon?", und darauf gibt es drei ehrliche Antworten -- passt so, noch verbessern, noch nicht angesehen. "NOCH VERBESSERN" VERLANGT EINE BEGRUENDUNG. Eine Bewertung, mit der der Creator nichts anfangen kann, ist nicht streng, sondern nur entmutigend. Der Server lehnt sie ohne Grund ab; die Oberflaeche fragt deshalb gleich danach, statt hinterher eine Fehlermeldung zu zeigen. "Passt so" braucht keinen -- da gibt es nichts zu erklaeren. Die Stufe steht IMMER an der Karte, auch fuer den Creator, auch wenn sie "noch nicht angesehen" lautet. Er soll sehen, wo er steht, ohne fragen zu muessen. Der Grund steht daneben in voller Breite, nicht in einer Ecke. FREMDE NACHRICHTEN BLEIBEN STEHEN -- auch fuer DogFather. Ein Gespraech nachtraeglich umzuschreiben waere schlimmer, als eine unbedachte Aeusserung stehen zu lassen. Wer etwas richtigstellen will, schreibt eine neue. VORLAGEN AUCH FUER COMMUNITY UND TECHNIK (Screens 11 und 12): 14 Moderations-, Aktions- und Konfliktpunkte, 12 Technikpunkte. Ton steht vorn, weil schlechter Ton der Grund Nummer eins ist, warum Leute einen Stream verlassen. Die drei Bereiche laufen jetzt ueber EINE Zuordnung statt drei fast gleicher Bloecke -- sonst weicht der dritte irgendwann ab. Die beiden alten Zweige wurden entfernt: Toter Code, den man stehen laesst, wird beim naechsten Mal fuer lebenden gehalten. Die Ampeln einer ganzen Liste kommen in EINER Abfrage. Zwanzig Eintraege einzeln zu fragen waeren zwanzig Anfragen, und die Seite ruckelte sichtbar beim Aufbau. Die Sichtbarkeitspruefung laeuft dabei je Eintrag, nicht einmal pauschal -- ein fremder Eintrag taucht auch in der Sammelabfrage nicht auf. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-01 16:49:56 +02:00