1c00770ec5df385cefd7c925641a285cf09c2c4f
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
1c00770ec5 |
Lesbarere Kaesten, und DogFather kann durch fremde Augen sehen
SCREEN 1 -- "die Kachel ganz leicht dunkler, so dass man den Text besser gelesen bekommt, aber nicht zu viel, so dass man den Hasen noch sieht." Die Erklaerkaesten stehen jetzt auf 88 statt 78 Prozent Deckung. Zehn Punkte sind gemessen der Unterschied zwischen muehsam und ruhig lesbar und lassen zwoelf Prozent Bild durch -- das Motiv bleibt sichtbar. "und die von wichtigen und neuen PDFs sollen auch staerker sein." Das war kein Geschmack, sondern ein Fehler: `background` ist eine Eigenschaft, keine Schicht. Die Zeile `background: rgba(232,192,125,.045)` hat die Flaeche nicht getoent, sondern ERSETZT -- uebrig blieben viereinhalb Prozent Deckung. Damit war ausgerechnet die Anleitung, die jeder lesen soll, die am schwersten lesbare der Seite. Die Toenung liegt jetzt als Schicht darueber. Gemessen: 88 % gegen 78 % bei einer gewoehnlichen. pruef-lesbarkeit.mjs misst das an ECHTEN PIXELN (Text kurz unsichtbar machen, Flaeche fotografieren, WCAG-Formel) und kennt ZWEI Grenzen -- lesbar genug UND durchsichtig genug. Mit nur einer haette sie eine schwarze Flaeche am besten gefunden, und das wollte niemand. SCREEN 2 -- "ich will alles von den Scouts und Managern einsehen koennen, auswaehlen, was und von wem. Ueberall, auf jeder Seite. NUR WIR BEIDE SOLLEN DIESE OPTION HABEN." Die naheliegende Loesung waere ein Filter je Seite gewesen -- also eine zweite Rechteregel in zwoelf Modulen, und eine Rechteregel an zwoelf Stellen stimmt irgendwann an elf. Stattdessen wird die PERSON getauscht, nicht die Regel: Waehlt DogFather einen Scout, laufen alle vorhandenen Sichtbarkeitsregeln unveraendert mit diesem Scout. Er sieht exakt dessen Arbeitsplatz -- nicht mehr, nicht weniger. Keine neue Rechteregel. Im Browser genauso: EIN Ort statt vierzehn. fetch wird einmal umgeleitet und haengt den Wert an jede lesende Abfrage an. Neue Seiten sind damit von selbst dabei; man kann es nicht vergessen. Drei Sicherungen: nur admin (auf dem SERVER geprueft, nicht in der Oberflaeche), nur lesend (geschrieben wird immer im eigenen Namen -- sonst staende im Protokoll der falsche Name), nur aktive Personen. Und ein Rahmen um die Seite, solange eine fremde Sicht laeuft. Der gefaehrlichste Fall ist nicht, dass man nicht umschalten kann, sondern dass man vergisst, dass man umgeschaltet hat -- und drei Aufgaben statt dreissig fuer den Bestand haelt. FUENF FEHLER, DIE DIE PRUEFUNGEN GEFUNDEN HABEN: 1. steckbrief.html hat die Kopfleiste NIE gefuellt -- dort stand monatelang "…" statt des eigenen Namens. Aufgefallen, weil der Umschalter dort fehlte. Jetzt zusaetzlich ein Netz darunter: Meldet sich nach kurzer Zeit niemand, holt der Kopf sich selbst, wer angemeldet ist. Die naechste neue Seite kann es nicht mehr vergessen. 2. Der Umschalter sprengte die Kopfleiste (46 px am Rechner, 117 px am Handy) und drueckte den Abmelden-Knopf hinaus. 3. Ich habe das <select> gestaltet -- wahl.js ersetzt aber jedes Auswahlfeld durch einen eigenen Knopf und schrumpft das echte Feld auf einen Pixel. Meine Regeln haben es wieder auf 20 x 44 aufgeblasen, wo es als unsichtbares Hindernis ueber dem Knopf lag. Gestaltet wird jetzt der Knopf. 4. Ein Wettlauf: Auf profil.html rufen zwei Dateien werZeigen() auf. Beide kamen an "gibt es den Umschalter schon?" vorbei, bevor eine ihn angehaengt hatte -- zwei Umschalter uebereinander. Die Sperre gehoert vor das erste await. 5. Die Handy-Pruefung bemaengelte ein Schild, das dort per display:none gar nicht erscheint. Sie sieht jetzt nur noch sichtbaren Text an -- eine Pruefung, die Unsichtbares anmahnt, gewoehnt man sich ab zu lesen. Dazu zwei Messfehler in den Pruefungen selbst: getComputedStyle liefert ein LEBENDES Objekt (die Farbe wurde gelesen, nachdem der Text unsichtbar gemacht war -- gemeldet wurden 1,17:1 fuer tadellos lesbaren Text), und ein Vergleich lief still ins Leere, weil die Vergleichsdaten fehlten. pruef-sicht.mjs stellt den MISSBRAUCH an den Anfang: Scout, Manager und Creator haengen ?sicht= an und muessen ignoriert werden; erfundene Nummern, Buchstaben und ein Einschleusversuch fallen auf die eigene Sicht zurueck; eine abgeschaltete Person liefert keine Sicht mehr; und was DogFather bei fremder Sicht anlegt, steht unter SEINEM Namen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
a129525cb7 |
Kennzahlen werden Wege, Team wird sichtbar, Felder bekommen ein Aussehen
Vier Wuensche vom 01.09.2026, dazu ein gemeldeter Fehler.
SCREEN 1 -- "wenn man auf die Kisten drueckt, sofort zu der Seite,
diesem Punkt". Jede Kennzahl im Bericht fuehrt jetzt dorthin, wo die
gezaehlten Dinge stehen: nicht nur auf die richtige Seite, sondern auf
die richtige Stelle (?zeigen=...). Ein gemeinsamer Helfer in kopf.js,
damit nicht jede Seite ihr eigenes Sprungverhalten erfindet.
Auf dem Aufgabenbrett wird HERVORGEHOBEN, nicht gefiltert -- das Brett
lebt davon, dass man die vier Spalten nebeneinander sieht. Bei den
Dateien wird gefiltert, denn die Seite hat ohnehin eine Filterleiste,
und deren Knoepfe zeigen dann mit an, wo man steht. Der Kalender
schaltet auf die Liste um: In der Monatsansicht liesse sich
"vergangen" gar nicht sinnvoll markieren.
Immer mit einem Weg zurueck ("Alles zeigen"), der auch den Parameter
aus der Adresse nimmt. Eine Seite, die gefiltert bleibt, ist eine
Falle: Man kommt spaeter wieder, sieht drei von zwanzig Aufgaben und
haelt das fuer den Bestand.
Drei Entscheidungen gegen den ersten Entwurf:
* KEIN ?creator= im Verweis. Das sah hilfreich aus und waere eine
Luege gewesen -- keine Zielseite liest den Wert.
* Kisten mit Null fuehren NIRGENDWOHIN. Ein Weg zu null Dingen ist
eine Enttaeuschung, kein Angebot.
* "neu angelegt" fuehrt ohne Ausschnitt aufs Brett: Der Bericht zaehlt
einen Zeitraum, das Brett kennt keinen. Eine Hervorhebung, die nicht
dieselbe Menge trifft, ist schlimmer als keine.
SCREEN 2 -- "ich will, dass wir Manager, Scouts, DogFather auch die
Fotos, Namen und so alles sehen". Der Steckbrief war eine Einbahnstrasse:
Jeder pflegte seinen, niemand bekam ihn je zu Gesicht. Die
Schnittstelle dafuer lag fertig da und wurde von keiner Seite
aufgerufen. Jetzt steht "Das Team" auf steckbrief.html und (fuer
Creator) auf profil.html -- nach Rollen gruppiert, mit Bild, Rolle,
eigenem Satz und Kanaelen. Wer wen sieht, entscheidet weiterhin der
Server; ein Creator sieht seine Betreuung, nicht die anderen Creator.
SCREEN 4 -- "das soll richtig geil aussehen und nicht so einfach, auch
die Schrift". Die Ursache war kein Geschmack, sondern ein Loch im
Aufbau: Jede Seite gestaltete ihre Felder mit einem EIGENEN Selektor,
und wer ein Feld anderswo hinsetzt, faellt durch alle Netze. Genau so
stand "Ein Satz ueber dich" als grauer Kasten in MONOSPACE da --
<textarea> faellt ohne `font: inherit` auf Schreibmaschinenschrift
zurueck. Jetzt gibt es eine Grundlage fuer jedes Feld, und die drei
wortgleichen Kopien in aufgaben/profil/bereich sind weg.
Der erste Anlauf setzte dort auch `width: 100%` -- die Pruefung
meldete sofort Felder von 28 statt 362 Pixeln. Breite ist LAYOUT und
gehoert der Seite; eine Grundlage mit Staerke null verliert jeden
Breitenstreit, also darf sie ihn nicht anfangen.
SCREEN 5 -- "wieso seh ich mein Bild da nicht?" Ein lehrreicher Fehler:
Der Server liefert das Bild laengst mit, und im Quelltext dort steht
ausdruecklich "es steht in der Kopfleiste JEDER Seite UND IN DER
BEGRUESSUNG". Die Absicht war aufgeschrieben, die Haelfte nie gebaut --
und aufgefallen ist es nicht, weil ein Buchstabe im Kreis nicht falsch
aussieht, nur eben nicht wie man selbst.
PRUEFUNGEN. Zwei neue (pruef-sprung, pruef-team), eine erweiterte
(pruef-formulare). Sie haben vier echte Fehler gefunden, die mit blossem
Auge nicht zu sehen waren:
* Der Sprung auf "dringend" hob auch ERLEDIGTE dringende Eintraege
hervor -- man klickt auf "2" und bekommt drei markiert.
* Auf einer leeren Zielseite erschien gar keine Erklaerung (frueher
Ausstieg uebersprang sie). Das ist der wichtigere Fall: Wer auf eine
Zahl klickt und im Leeren landet, glaubt, er sei falsch abgebogen.
* Das Kachel-Merkzeichen stiess mit der Zahl zusammen.
* Die Feldpruefung fand vier RICHTIGE Felder falsch (die Kanaele holen
ihren Rahmen vom Umschlag mit dem "@"). Eine Pruefung, die
Richtiges anmahnt, gewoehnt man sich ab zu lesen.
Und zwei Faelle, in denen die Pruefung sich selbst belogen haette: null
gefundene Felder galten als "in Ordnung", und der Ueberdeckungsvergleich
war nach einer Aenderung ohne ein einziges Vergleichselement gruen.
Beide zaehlen jetzt mit, wie viel sie tatsaechlich angesehen haben.
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
|
24048ff0e0 |
Zustaendigkeit: DogFather und Manager zaehlen wie ein Scout
Filipe: "dogfather soll auch zaehlen wie bananastift und patrick."
Beim Nachsehen war das kein Wunsch, sondern ein Fehlerbericht. In der
Auswahl "Betreut von" stand "DogFather" -- aber als LEER-Wert, nicht als
Person. Es sah aus wie eine Zuordnung und war keine. Genau dieselben
Creator zaehlten deshalb gleichzeitig im Hinweis "Creator ohne
zustaendige Person". Zwei Aussagen ueber denselben Sachverhalt, beide auf
demselben Bildschirm, beide fuer sich stimmig.
Jetzt kann jede betreuende Rolle eingetragen werden -- DogFather, Manager
und Scouts, in der ueblichen Reihenfolge. Der Leer-Wert heisst, was er
ist: "— niemand —". Bei DogFather und Manager steht die Rolle in
Klammern dabei; bei aehnlichen Namen ist sonst nicht zu erkennen, wen man
eintraegt. Und "betreut N Creator" steht jetzt an jeder betreuenden
Person, nicht nur an Scouts.
DER WICHTIGE TEIL: An den RECHTEN aendert das nichts.
Die Zustaendigkeit steuert die Sichtbarkeit NUR beim Scout -- die Leitung
sieht ohnehin jeden Creator. Waere das anders, haette eine
Anzeigeeinstellung still Rechte vergeben. Der Test weist beide Richtungen
nach:
* Tili auf DogFather eingetragen -> KEIN Scout sieht sie.
* Tili auf Patrick eingetragen -> nur Patrick sieht sie, BananaStift
weiterhin nicht.
* Zurueck auf DogFather -> Patrick verliert die Sicht wieder.
* DogFather sieht in allen drei Faellen unveraendert beide Creator.
Ein Creator kann nicht zustaendig sein -- das waere eine Rolle, die es
nicht gibt. Und ein Scout kann die Zustaendigkeit weiterhin nicht selbst
setzen (404), sonst haette er die Rechtevergabe in der Hand, die ihn
begrenzen soll.
20 Pruefungen, darunter die Gegenprobe zum Hinweis: Auf "niemand"
zurueckgesetzt MUSS er wiederkommen, sonst waere er wertlos.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
ec712a3a32 |
Personen: jede Rolle einzeln auf- und zuklappbar
Wunsch Filipe: "ich will ueberall die liste zu machen koennen und nur
aufmachen wenn ich sie sehen will."
Jede der vier Rollen klappt jetzt einzeln auf und zu. Das ERSETZT den
Sammelknopf von vorhin ("5 weitere zeigen") -- zwei Mechanismen
nebeneinander, die dasselbe verstecken, waeren eine Einladung zum
Missverstaendnis. Der Knopf oben rechts macht jetzt etwas anderes: alles
auf einmal ("Alle aufklappen" / "Alle zuklappen"), damit man bei vier
Rollen nicht viermal klicken muss.
Der entscheidende Unterschied zum Ausblenden: Die UEBERSCHRIFT mit der
Anzahl bleibt IMMER stehen, auch zugeklappt. Man sieht jederzeit, DASS es
einen Manager gibt -- nur nicht, welchen. Wer eine ganze Rolle spurlos
verschwinden laesst, haelt sie irgendwann fuer leer.
Und zugeklappt zaehlt genau eine Frage: Steckt da etwas Gesperrtes drin,
das ich sehen muesste? Deshalb steht am Manager auch zugeklappt
"1 gesperrt", in Warnfarbe.
Die Ueberschrift IST der Knopf, als echtes <button> -- ein eigener
kleiner Schalter daneben waere ein zweites Ziel fuer dieselbe Absicht,
und ein kleineres. Als Knopf-Element statt div mit Klick-Zuhoerer machen
Tastatur und Vorleseprogramme es ohne Zutun richtig.
Der Zustand wird JE ROLLE gemerkt, nicht als "alles auf/zu": Wer die
Creator zuklappt und die Scouts offen laesst, findet das nach dem Laden
genau so wieder.
30 Pruefungen. Darunter weiterhin der wichtigste: Zuklappen ist eine
ANSICHT, kein Recht -- Tili kann sich anmelden und normal arbeiten,
waehrend ihre Rolle zugeklappt ist, und der Server liefert unveraendert
alle sieben Personen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
ac81f288c8 |
Personen loeschen -- mit Vorschau und einer Sicherung unmittelbar davor
Wunsch Filipe: "ich will auch die moeglichkeit haben die loeschen zu
koennen."
Das ist die einzige Handlung im ganzen Workspace, die sich nicht
rueckgaengig machen laesst. Vier Vorkehrungen:
1. NUR DOGFATHER. Nicht die Leitung, nicht ein Manager -- "nur DogFather
hat alle endgueltigen Rechte" heisst genau hier etwas. Ein Manager
kann weiterhin sperren; das reicht fuer den Alltag und ist umkehrbar.
Alle anderen bekommen 404, auch fuer die Vorschau: Die verraet, wie
viel an einer Person haengt.
2. VORSCHAU. Vor dem Klick steht da, was MITGEHT (Profil, Start-Check,
Content-Saeulen, Sitzungen, Zustaendigkeit) und was BLEIBT und nur
seine Zuordnung verliert (Aufgaben, Termine, Bereichseintraege,
Dateien, Leads). Eine Aufgabe verschwinden zu lassen, weil jemand
geht, waere Geschichtsfaelschung.
Dazu die gefaehrlichste Einzelwarnung: Wer einen Scout loescht, nimmt
seinen Creators die zustaendige Person weg. Die Vorschau nennt sie
beim Namen.
3. EINE SICHERUNG DIREKT DAVOR -- und wenn sie scheitert, wird NICHT
geloescht. Damit ist "geloescht" wiederherstellbar. Das ist der
eigentliche Gewinn aus der Sicherungsarbeit von heute Nachmittag.
4. Der Name muss getippt werden. Nicht als Schikane: Der Loeschknopf
sitzt neben dem Sperrknopf, und die beiden sind sehr verschieden. Wer
den Namen tippt, hat die Zeile gelesen, die er trifft.
ZWEI FEHLER, die erst die Pruefung sichtbar gemacht hat:
a) Alle Loeschungen schrieben in DIESELBE Tagessicherung. Nach der
dritten kannte sie die erste geloeschte Person nicht mehr -- die
Sicherung haette genau in dem Fall versagt, fuer den sie da ist.
Loeschungen bekommen jetzt eine eigene Datei ("vorher-…") mit
Zeitstempel, die nie ueberschrieben wird. Aufgefallen nur, weil die
Pruefung die ANZAHL der Dateien zaehlt und nicht bloss, ob eine da ist.
b) Der Zeitstempel hatte Sekundenaufloesung -- drei Loeschungen in
derselben Sekunde ergaben wieder eine einzige Datei. Jetzt mit
Millisekunden, plus Zaehler als Notloesung. Und: Eine Sicherung vor
dem Loeschen setzt NICHT den Vermerk fuer den planmaessigen Lauf,
sonst faellt die naechtliche Sicherung aus.
Dabei auch ein Fehler in meiner eigenen Pruefung gefunden: Sie griff die
alphabetisch erste Datei und nannte sie "die aelteste" -- "vorher-…-2.db"
sortiert aber VOR "vorher-….db", weil "-" kleiner ist als ".". Sie prueft
jetzt die Eigenschaft selbst: JEDE geloeschte Person muss sich aus
irgendeiner Sicherung zurueckholen lassen.
43 Pruefungen, Schwerpunkt auf dem, was NICHT gehen darf.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2dbf9fb57a |
Personen: eine Kategorie je Rolle, Reihenfolge wie auf der Zugangsseite
Wunsch Filipe: "ich will dass die auch immer die gleiche reihenfolge
haben, am besten sogar jeder seine eigene kategorie und die reihenfolge
genau wie in der zugangsseite."
Dabei kam ein echter Fehler ans Licht. Die Abfrage sortierte mit
ORDER BY p.aktiv DESC, <Rolle>, p.name
Das "p.aktiv DESC" stand VOR der Rolle -- dadurch wanderte jede gesperrte
Person ans Ende der GESAMTEN Liste, quer durch alle Rollen. Im Bild vom
31.08.2026 stand der gesperrte Manager BanaStift deshalb ganz unten unter
den Creators. Die Reihenfolge DogFather-Manager-Scout-Creator, die
ueberall sonst gilt (ROLLEN_SORTIERUNG, CLAUDE.md), war ausgerechnet auf
der Personenseite aufgehoben -- und es sah nach Absicht aus.
Jetzt: Rolle zuerst, dann Gesperrtes ans Ende SEINER Rolle, dann Name.
Dazu vier Abschnitte mit Ueberschrift, Anzahl und demselben Zusatztext
wie auf der Zugangsseite ("Eigene Pipeline & Kontakte" usw.) -- wer sich
eben angemeldet hat, findet hier dieselbe Sprache wieder. Eine Rolle ohne
Personen wird weggelassen: Eine leere Ueberschrift ist kein
Ordnungsmerkmal, sondern eine Luecke.
Die Gruppen-Gestaltung kommt aus start.css und wird nur wiederverwendet
-- dieselbe Sprache wie auf der Startseite, kein zweiter Entwurf.
Nebenbei ein Eigentor: Der Kommentar zur Sortierung stand zuerst INNERHALB
der SQL-Zeichenkette und enthielt Rueckwaerts-Anfuehrungszeichen. Die
beenden ein Template-Literal -- der Server startete nicht mehr. Steht
jetzt darueber, mit einem Hinweis darauf.
30 Pruefungen. Neu darunter: dass die vier Abschnitte in genau dieser
Reihenfolge stehen, dass der gesperrte Manager bei den Managern steht und
nicht bei den Creators, und dass zugeklappt nur der DogFather-Abschnitt
da ist.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
099d9a7693 |
Personenliste: standardmaessig nur DogFather, Rest auf Knopfdruck
Wunsch Filipe: "ich will da nur mich und vanvan sehen, ich will dass ich
einen knopf habe wenn ich die anderen sehen will oder nicht."
Drei Dinge, die dabei nicht schiefgehen duerfen:
1. Das ist eine ANSICHT, kein Recht. Wer eingeklappt ist, ist nicht weg
-- er wird nur nicht gezeigt. Verwechselt man das, haelt man
irgendwann jemanden fuer geloescht, der noch vollen Zugang hat. Der
Test weist das ausdruecklich nach: Tili kann sich anmelden und normal
arbeiten, waehrend sie ausgeblendet ist, und der Server liefert
weiterhin ALLE sieben Personen. Gekuerzt wird nur die Anzeige --
waere es serverseitig, wuerde die naechste Auswertung stillschweigend
Personen uebersehen.
2. Auf dem Knopf steht IMMER, wie viele gerade fehlen ("5 weitere
zeigen · 1 gesperrt"). "Alle zeigen" allein sagt nicht, wovon man
gerade nichts sieht -- und dass eine Person gesperrt ist, gehoert zu
den Dingen, die man nicht uebersehen darf.
3. Der Zustand bleibt erhalten. Ein Knopf, den man nach jedem Laden neu
druecken muss, ist keine Einstellung, sondern eine Zumutung.
Gesperrte Personen werden beim Aufklappen ganz normal mitgezeigt -- eine
gesperrte Person zu verstecken waere genau die Zeile, die man sehen
muesste.
24 Pruefungen, Computer und Handy.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
