bc9a902ffbb0d703ab3fa9a74fcc16113bbf59b5
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 DogFatherGit
|
bc9a902ffb |
Die Knoepfe stehen nicht mehr vor dem Text -- und verteilt wird bei "Eure Aufgaben"
ZWEI WUENSCHE, EINE URSACHE: beide gehen auf den Block "Noch jemanden dazunehmen" zurueck, der am 21.09. ins Aufgabenformular kam. 1. "DIE ZWEI BUTTONS SOLLEN NICHT VOR DEM TEXT STEHEN" Gemessen bei 1280 px: "Anlegen" und "Abbrechen" lagen ueber zwei Hinweisen, mit 363x27 und 363x10 Pixeln Ueberlappung. Die Ursache ist eine Regel vom 17.09., und sie ist richtig: Der Hinweis haengt ABSOLUT unter seinem Feld, damit die Eingaben auf einer Linie bleiben. Was aus dem Fluss genommen wird, belegt aber keinen Platz -- solange darunter nur der Rasterabstand kam, fiel das nicht auf. Mit dem neuen Knopf wurde die Zelle hoeher, und der Hinweis wanderte mit, direkt auf die Knoepfe. Jetzt bekommt das Raster unter sich 44 px, wenn es einen haengenden Hinweis gibt (`:has()`, nicht pauschal -- ein Formular ohne Hinweis bekaeme sonst Leere geschenkt). Die Hoehe ist gemessen: ein Hinweis ist zweizeilig 35 px hoch plus 4 px Abstand. UND EIN ZWEITER FUND AN DERSELBEN STELLE: Der Block sass IN der Zelle "Wer macht es?". Dadurch stand deren Eingabe bei 780..824, die Nachbarin "Fuer welchen Kanal?" bei 833..877 -- 53 Pixel Versatz, und genau das sieht man als "verzogen". Er steht jetzt als eigene Rasterzeile hinter beiden; danach sind sie wieder buendig. Als eigene Zeile ist er ausserdem ehrlicher: "Noch jemanden dazunehmen" ist ein zweiter Schritt, kein Teil des ersten. Gefunden hat beides pruef-formulare, die seit dem 07.09. auf buendige Unterkanten prueft und seit dem 21.09. rot war. 2. "BEI EURE AUFGABEN DIE AUFGABEN VERTEILEN" Filipe, zum wiederholten Mal -- und so stand es auch im Auftrag vom 21.09. (Abschnitt 2). Auf "Eure Aufgaben" steht jetzt ein Band "Aufgabe verteilen". Es nimmt die gerade gewaehlte Person mit: "Aufgabe fuer Kessi" fuehrt auf das Aufgabenbrett, oeffnet das Formular und traegt sie ein. EIN WEG, KEIN ZWEITES FORMULAR. Zwei Formulare fuer dieselbe Sache waeren zwei Gelegenheiten, eines zu vergessen -- und man wuesste nie, welches das richtige ist. Beim Bauen gemessen: Das Band blieb unsichtbar, bis man eine Person anklickte -- `window.__ich` kommt ueber das Netz und steht beim ersten Aufruf noch nicht. Jetzt wird darauf gewartet, laengstens drei Sekunden, statt eine Zahl aus dem Kopf zu setzen. Zwei Pruefungen waren selbst kaputt: pruef-formulare zaehlte ein Eingabefeld mit, das in einem zugeklappten Block liegt und Hoehe 0 hat -- ein Feld, das man nicht sieht, kann nicht schief stehen. pruef-entwicklung verlangte, dass ein Modi "Eure Aufgaben" NICHT bekommt; das hat Filipe heute umgedreht. Geprueft: pruef-formulare 19/0 (war 18 ok / 1 FEHL), pruef-entwicklung 48/0 (war 45/1), pruef-aufgabenbrett 49/0, pruef-css-klassen 30/0. Der ganze Weg am Bildschirm gemessen: Band sichtbar, Person mitgenommen, Formular offen, richtige Person gewaehlt, keine Skriptfehler. |
||
|
DogFatherGit
|
4b87f27451 |
Niemand erfaehrt, was er nicht hat -- und die Kacheln tragen ihre Farbe
ZWEI WUENSCHE, DIE ZUSAMMENGEHOEREN: die Willkommensseite.
1. "KEINER SOLL WISSEN WAS ER NICHT SIEHT"
Filipe: "das geht keinen was an. sie sehen die sachen ja nicht weil es
sie nichts angeht und das muss auch nicht erwaehnt werden.
kontrollier das ueberall bitte."
Durchgesehen: Das Haus macht es ueberall sonst schon richtig -- der
Server antwortet mit 404 statt 403, damit ein "das darfst du nicht"
gar nicht erst verraet, dass es etwas gibt. GENAU ZWEI Stellen taten
das Gegenteil, beide auf der Willkommensseite:
der Hinweis "Was du nicht siehst" (linke Hand),
und in ihrer Einleitung "Was du NICHT hast: Personen anlegen,
Rollen aendern und den vertraulichen Meldeweg".
Beide entfernt, der Hinweis mit einem Kommentar an seiner Stelle --
damit ihn niemand spaeter "nachtraegt", weil er ihn fuer vergessen
haelt. Im Kopf derselben Datei stand die Ueberlegung uebrigens schon:
"Eine Liste von Dingen, die man nicht darf, ist keine Orientierung,
sondern eine Kraenkung."
Die Pruefung verlangte bis heute das GEGENTEIL ("ihr wird gesagt, was
sie nicht hat"). Sie misst jetzt alle fuenf Rollen gegen acht Muster,
mit Gegenprobe -- das "ueberall" aus dem Auftrag.
2. DIE FARBEN DER STARTSEITE
Der Server reicht `ton` durch, die Kachel traegt `data-ton="N"`, und
start.css macht daraus `--ton`. Keine eigene Farbtabelle: Die waere
die, die beim naechsten Farbwechsel stehen bleibt -- genau das ist am
19.09. elf Seiten passiert.
Drei Stellen tragen die Farbe, keine davon eine Flaeche: das Zeichen,
eine schmale Kante links und ein leiser Schimmer in der oberen Ecke.
Eine eingefaerbte Kachelflaeche waere bunt und schlecht lesbar.
UND EIN FEHLER, DEN NUR DAS MESSEN GEZEIGT HAT: Mein erster Anlauf
setzte `--ton: var(--akzent)` als Vorgabe auf `.w-kachel`. Gleiche
Spezifitaet wie `[data-ton="N"]` in start.css -- und willkommen.css
laedt SPAETER. Ergebnis: 0 von 14 Kacheln trugen die richtige Farbe,
alle waren blau. Der Rueckfall gehoert an die Verwendung
(`var(--ton, …)`), nicht an die Deklaration. Danach: 14 von 14.
Geprueft: pruef-willkommen 67/0, pruef-css-klassen 30/0.
|
||
|
DogFatherGit
|
82335c783d |
Die rechte Hand legt selbst Personen an -- und sieht die Codes
Filipe: "dan will ich dass die rechte hand auch neue personen hinzufuegen kann. also neue erstellen kann und die codes genau so sieht wie dogfather, damit sie das auch machen kann wenn er live ist." WAS SIE DARF: Modis und Community anlegen, und deren Codes neu setzen. Die Liste ist ABGELEITET aus ROLLEN_ZUM_AENDERN -- dieselben zwei Rollen, die sie ohnehin vergeben darf. Zwei Listen waeren zwei Gelegenheiten, eine davon zu aendern und die andere zu vergessen. WAS SIE NICHT DARF: eine zweite rechte Hand, eine linke Hand oder einen zweiten DogFather anlegen -- und an einer linken Hand auch nichts aendern. Ohne die zweite Schranke haette sie den Code einer linken Hand neu setzen koennen und damit einen Zugang in der Hand, der fast so viel darf wie sie selbst. Die alte Schranke kannte nur "admin" und "manager". NUR DIE RECHTE, NICHT DIE LINKE. `istHand()` haette beide getroffen; fuer die linke Hand ist "legt niemanden an" eine ausdrueckliche Entscheidung vom 21.09. VIER STELLEN IN DER OBERFLAECHE, die alle an Rollennamen hingen: `nurLesen = ich.rolle === 'hand'` -- sie bekam die Liste und kein Formular. Jetzt abgeleitet aus `darf_anlegen`. Die Wache darueber warf sie auf die Startseite, sobald `nurLesen` falsch wurde. Die Seite ging fuer sie einfach nicht auf, ohne Meldung. Der Sendeweg hing an `ich.rolle === 'admin'`. Fuer sie gab es damit GAR KEINEN: Die Seite antwortete "Fuer die Rolle modi gibt es hier keinen Weg" -- ein Satz, der wie ein Formularfehler klingt und eine fehlende Zeile war. UND EIN ECHTER FUND: `rollenwahlErgaenzen()` hing jede Zusatzrolle an das Formular, die mit der Personenliste kam -- ohne zu fragen, ob man sie anlegen darf. Solange nur DogFather das Formular sah, fiel es nicht auf: Er darf sie alle. Der rechten Hand bot es "rechte Hand" und "linke Hand" an. Der Server haette es abgelehnt -- aber der Knopf verriet eine Rolle, die sie nicht vergeben soll. Zwei Pruefungen waren dabei selbst kaputt: pruef-personen-formular erwartete sieben Rollen (seit "linke" am 21.09. sind es acht) und suchte den Namen im sichtbaren Text -- die Abschnitte sind zugeklappt und zeigen nur Anfangsbuchstaben. Beides abgeleitet statt gezaehlt. Geprueft: pruef-personen-formular 43/0 (war 34 ok / 2 FEHL), davon neun am echten Bildschirm auf der Crew-Adresse -- anmelden, Formular oeffnen, anlegen, Code lesen, Person in der Liste wiederfinden. pruef-haus-trennung 81/0 (war 72 ok / 2 FEHL), pruef-rollen-anlegen 11/0. |
||
|
DogFatherGit
|
39c0b4dc1f |
Ein Modi sieht nur SEINE Aufgaben -- und gibt sich selbst keine
Filipe, unmissverstaendlich und mehrfach: "die modis sollen immer nur ihre aufgaben auch sehen und nicht die von anderen, so wie bei den daten ... damit wir endlich den modis aufgaben anstaendig verteilen koennen und sie sich nicht selber aufgaben geben." DAS DREHT DIE ENTSCHEIDUNG VOM 09.09. AUSDRUECKLICH UM. Damals: "ja, sie sind untereinander ein team", damit ein Schichttausch ohne Umweg geht. Beides steht jetzt im Code nebeneinander, damit niemand spaeter die aeltere findet und fuer die gueltige haelt. VIER AENDERUNGEN: Die Sicht. Ein Modi sieht nur `a.verantwortlich_id = ich`. Was ihm ueber aufgaben_zuteilung gegeben wurde, haengt mitZugeteilten() an -- ein Pool, in dem er steht, bleibt also sichtbar, bis ihn jemand uebernimmt. Die rechte und die linke Hand behalten die Uebersicht. Das Anlegen. Im Team Dogi legt nur an, wer auch verteilen darf. In der AGENTUR bleibt es, wie es war -- dort ist eine Aufgabe eine Notiz an sich selbst, kein Auftrag von jemandem. Eine Regel, die beide Haeuser ueber einen Kamm schert, waere falsch. Der Knopf. "Neue Aufgabe" steht fuer einen Modi gar nicht mehr da. Ein Knopf, der mit 403 antwortet, ist schlimmer als keiner: Die Meldung erscheint ganz oben, und wer weiter unten steht, sieht nur, dass nichts passiert. Die Kacheln. Ein Modi sieht jetzt den Bereich "Entwicklung & Nachwuchs" mit denselben zwei Kacheln wie die Leitung -- nicht mehr zwei eigene mit anderem Namen. Zwei Namen fuer dieselbe Sache ist genau der Fehler, der am 19.09. zwei Kacheln "Chat" ergeben hat. "Talente" bleibt draussen: Dort stehen Notizen ueber Zuschauer, die nichts davon wissen. UND DIE LINKE HAND SIEHT "DEIN TEAM" NICHT MEHR (Filipes Wunsch). Abgeleitet, nicht nachgebaut: Ihre Liste ist die der rechten Hand MINUS dieser einen Kachel, erkannt am ZIEL statt am Namen -- der Name ist am 17.09. schon einmal gewandert. Gemessen: admin 30 Kacheln, hand 30, linke 29 (ohne "Dein Team"), modi 25 (mit dem Bereich, ohne Talente). Zwei Pruefungen hielten die alte Regel fest und wurden dadurch rot -- genau ihre Aufgabe. Beide umgedreht, mit der alten Entscheidung im Kommentar. pruef-zuteilung 65/0, pruef-verteilen 19/0 (war 15), pruef-aufgabenbrett 49/0. |
||
|
DogFatherGit
|
ea32d6790b |
Das Auge ist am Finger ein volles Ziel -- und die Leiste bleibt eine Reihe
Filipe zur offenen Entscheidung "36-px-Auge oder 44-px-Fingerziel":
"mach was du am besten haelst es soll nur immer alles einfach zu
bedienen sein und geil aussehen fertig."
DIE ENTSCHEIDUNG WAR EINE SCHEINALTERNATIVE. Gemessen am echten
Aufbau, statt der Notiz zu glauben:
Breite Auge uebrige Knoepfe Leiste
360 px 42 x 44 alle 44 x 44 zwei Reihen
390 px 42 x 44 alle 44 x 44 zwei Reihen
412 px 34 x 44 alle 44 x 44 eine Reihe
1280 px 116 x 32 mit Beschriftung
Die HOEHE stimmte laengst. Es fehlten zwei Pixel Breite -- bei 412 px
zehn. Der Umschalter war als einziger Knopf der Leiste kein volles
Ziel, und ausgerechnet er sitzt zwischen zwei anderen.
ZWEIMAL DIE ALTE FALLE AUF DEM WEG:
Erster Anlauf vergroesserte nur den Knopf. Gemessen bei 412 px:
Knopf 44, Behaelter 36 -- der Knopf ragte 3 px ueber den Nachbarn.
Genau so lag am 11.09. der Umschalter ueber dem Chat-Knopf, und wer
"Meine Sicht" antippte, landete im Chat. Die Lehre von damals steht
in start.css ("wer nur den Rahmen begrenzt, begrenzt nichts") und
gilt andersherum genauso.
Danach brach die Leiste bei 412 um -- "Abmelden" in einer zweiten
Zeile, genau Filipes Beanstandung vom 09.09. Gerechnet: 386 px
noetig, 380 verfuegbar. Sechs Pixel. Sie kommen jetzt aus dem
Weissraum (4->2 zwischen den Zeichenknoepfen, 10->6 zur linken
Gruppe), nicht aus den Tippzielen -- am Ziel zu sparen ist genau der
Fehler, der sie ueberhaupt erst auf 34 und 36 gebracht hat.
NEBENGEWINN, nicht geplant: Bei 390 px -- der haeufigsten Breite --
geht die Leiste dadurch von zwei Reihen auf eine, 117 px auf 69. Bei
360 px bleibt sie zweireihig, und das ist richtig: Dort fehlen auch
so noch zwoelf Pixel, und Umbrechen ist die ehrliche Antwort auf zu
wenig Platz.
Am Rechner unveraendert: 116 x 32 mit Beschriftung, weil dort eine
Maus zielt und kein Daumen. Die Regel haengt an `pointer: coarse`.
Gemessen nachher: alle vier Breiten 44 x 44, keine Ueberlappung,
nichts breiter als der Schirm. pruef-tippziele 11/0,
pruef-css-klassen 30/0.
|
||
|
DogFatherGit
|
2b6c2be1ad |
Die Stelle bleibt -- auch wenn die Seite dazwischen neu laedt
Filipe, zum vierten Mal: "wenn ich in eine kategorie rein gehe und dan zurueck geh die hauptseite immer wieder ganz hoch ... ohne dass die seite hoch scrollt ODER NEU LAEDT." DAS "ODER NEU LAEDT" WAR DER HINWEIS, und ich habe ihn zweimal ueberlesen. kopf.js laedt die Seite selbst neu, sobald der Browser sie aus seinem Rueckwaerts-Speicher holt -- damit keine veralteten Zahlen dastehen. Nach einem Neuladen heisst die Navigationsart aber "reload", nicht "back_forward". UND DIE EIGENTLICHE BOSHEIT stand in einer Zeile, die ich selbst geschrieben habe: Wurde eine Ankunft nicht als Zurueck erkannt, wurde die gemerkte Stelle GELOESCHT. Ein einziges Neuladen reichte -- danach half auch das naechste Zurueckgehen nicht mehr. Deshalb "geht es immer noch nicht", obwohl ich es dreimal fuer behoben hielt. WARUM ES IN JEDER MESSUNG FUNKTIONIERT HAT: kopf.js haelt einen Ereignisstrom offen, und der sperrt den Rueckwaerts-Speicher aus. `persisted` bleibt hier immer false, die Neulade-Zeile lief nie. Auf einem echten Handy greift er sehr wohl. Man muss den Weg gehen, den der Mensch geht -- und wenn man ihn nicht nachstellen kann, baut man gegen ALLE Wege robust statt gegen einen. FUENF AENDERUNGEN: Die Stelle wird LAUFEND gemerkt (gedrosselt auf 250 ms), nicht nur beim Klicken und Verlassen. Deckt auch die Glocke, eine Benachrichtigung und einen Absturz des Reiters ab. Nichts wird mehr geloescht. Die Stelle verfaellt von selbst nach einer Stunde. Wiederhergestellt wird jetzt auch bei "reload" und bei "navigate mit Herkunft aus diesem Haus" -- nicht nur bei "back_forward". Vor dem Neuladen aus dem Rueckwaerts-Speicher wird die Stelle samt Merker festgehalten. Der Pfeil in der Kopfleiste setzt den Merker jetzt fuer BEIDE seiner Wege. Er nimmt history.back() nur, wenn `document.referrer` da ist -- sonst location.assign(), und das ist fuer den Browser ein Hingehen. Hier stand "der braucht nichts"; fuer den zweiten Weg stimmte das nie. Ein Neuanfang faengt weiterhin oben an: keine Herkunft, kein Merker -- also vom Startbildschirm, aus einer Benachrichtigung, ueber die Adresszeile. Beim Bauen fast hineingelaufen: `START` steht in einem anderen Block derselben Datei und waere an der neuen Stelle ein Absturz gewesen -- dieselbe Falle wie bei `$` am 21.09. Jetzt gibt der erste Block ihn einmal bekannt, statt ihn abzuschreiben. Geprueft: pruef-stelle 15/0 (war 9) -- Brotkrume (navigate), Browser-Zurueck (back_forward), NEULADEN (reload), Neuanfang oben, und dass eine fremde Ankunft die Stelle nicht wegwirft. Dazu pruef-sprung 43/0, pruef-start-ansicht 153/0, pruef-css-klassen 30/0. |
||
|
DogFatherGit
|
66789aabcd |
Willkommen: eine Seite, die erklaert, was es hier gibt
Auftrag vom 21.09.2026, Abschnitte 7 und 8. Aus der Kachel "Der Treff" wird die Willkommensseite. WARUM DAS NICHTS VERLIERT, gemessen am echten Bestand: Das Brett "treff" hatte NULL Eintraege, der Treff-Chat daneben 29 Nachrichten. Geredet wird im Chat; das Brett war eine Kachel ohne Inhalt. DIE SEITE ERKLAERT NICHT "DIE WEBSITE", SONDERN DEINE. Sie baut sich aus derselben Kachelliste wie die Startseite, durch denselben Filter (darfSeite). Wer morgen eine Kachel bekommt, bekommt automatisch auch ihre Erklaerung -- und wer eine nicht hat, liest nicht davon. Eine Liste von Dingen, die man nicht darf, ist keine Orientierung. Gemessen: DogFather 30 Kacheln, Modi 25, Community 11 -- und keine einzige davon ist fuer den Betreffenden gesperrt. DREI FEHLER, DIE ERST DAS BILDSCHIRMFOTO GEZEIGT HAT: body class="gate" ist die ANMELDEWAND (display:flex, zentriert). Kopfleiste und Inhalt standen dadurch NEBENEINANDER -- am Handy blieben dem Text 260 von 390 Pixeln. .huelle gibt es im Haus gar nicht. Der Inhalt stand linksbuendig statt mittig, ohne Sicherheitsrand an randlosen Geraeten. Jetzt .inhalt wie jede andere Seite. Der Text stand direkt auf dem Buehnenbild: Kontrast 1.68:1 am Rechner, 2.23:1 am Handy (noetig 4.5). Die Hausregel stand daneben in start.css -- "der Text steht auf eigenen Flaechen" -- und diese Seite hielt sich als einzige nicht daran. Jetzt 5.19 und 7.73. UND EIN LECK, ZUM DRITTEN MAL DIESELBE URSACHE: Die Kachel umzuleiten nahm dem Brett "treff" die Zugehoerigkeit -- TREFF_BRETTER wird aus Kachelzielen abgeleitet. Die Schranke laesst eine AGENTURROLLE unbesehen durch, wenn ein Brett in keiner Liste steht: Eine Creatorin konnte das Brett des Treffs lesen. Behoben, und diesmal dauerhaft laut gemacht: Nachgemessen ist die Trennung exakt und in beide Richtungen deckungsgleich -- die Bretter mit `fuerAlle` sind genau die des Treffs plus die Agenturablage. Das ist eine Eigenschaft des BRETTS und wandert nicht, wenn jemand eine Kachel umleitet. pruef-treff prueft das jetzt. Mein erster Entwurf der Regel war zu breit und meldete `content` und `schutz` -- beides Agenturbretter, die eine Agenturrolle zu Recht liest. Eine Pruefung, die zu viel meldet, wird abgeschaltet. AUSSERDEM: 16 Kennungen aus workspace-zuteilung.js hatten keinen deutschen Satz -- auf dem Bildschirm haette woertlich "nicht_zugeteilt" gestanden. Gefunden von pruef-meldungen am selben Tag. Und zwei Erwartungen in pruef-treff abgeleitet statt gezaehlt: die Zahl der Rollenkacheln auf der Wand (die Anmeldung sucht WHERE rolle=?, eine Rolle ohne Kachel ist unerreichbar) und "die breite Kachel steht vorne" ueber die Eigenschaft statt ueber den Namen. Geprueft: pruef-willkommen 66/0 (neu), pruef-treff 80/0 (war 59 ok / 13 FEHL), pruef-buehne fuer die neue Seite 10/0, pruef-meldungen 8/0, pruef-css-klassen 30/0, pruef-rechtetafel 19/0. |