d6df590224550add767cbdd9ee609f6e396676c8
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
461d41943a |
Keine Maschinensprache mehr auf dem Bildschirm
Filipe: "keine kryptischen oder technischen fehlermeldungen, sondern
klare aussagen darueber, was passiert ist und wie man das problem
loesen kann."
DAS PROBLEM, NACHGEMESSEN.
Der Server antwortet im Fehlerfall mit { fehler: "..." }. Darin stehen
ZWEI verschiedene Dinge, und von aussen sehen sie gleich aus:
Maschinenkennungen (nicht_verfuegbar, nicht_gefunden, ungueltig -- 43
verschiedene) und fertige deutsche Saetze.
An 84 Stellen stand `textContent = d.fehler` -- ungefiltert. Wer beim
Hochladen einer Datei Pech hatte, las woertlich "nicht_verfuegbar" auf
dem Bildschirm und wusste nicht einmal, ob er selbst schuld war.
Gezaehlt: 474 Antworten mit "nicht_verfuegbar", 392 mit
"nicht_gefunden", 125 mit "ungueltig".
DREI AUSGAENGE, NICHT ZWEI.
`sagWas()` in workspace/assets/js/meldung.js:
bekannte Kennung -> ihr Satz
unbekannte Kennung -> der Ersatzsatz der Stelle, NIE die Kennung
(sie geht in die Konsole, wo sie jemandem
auffaellt, der sie beheben kann)
fertiger Satz -> unveraendert durch
Erkannt wird eine Kennung daran, dass sie nur aus Kleinbuchstaben,
Ziffern und Unterstrichen besteht. Ein deutscher Satz hat immer
Leerzeichen; eine Kennung nie. Die Unterscheidung ist entschieden,
nicht geraten.
UND WARUM DIE TABELLE NICHT ALTERN KANN.
Eine von Hand gepflegte Liste ist hier schon zweimal teuer geworden
(die abgeschriebene Spaltenliste, die feste Umbruchschwelle). Deshalb
rechnet pruef-meldungen.mjs die Kennungen AUS DEM SERVER aus statt sie
zu kennen -- eine neue ohne Satz macht sie rot. Man kann es nicht mehr
vergessen.
Sie prueft drei Dinge und beweist zu jedem, dass sie auch "nicht in
Ordnung" sagen kann:
1. vollstaendig -- jede Kennung hat einen Satz
2. angeschlossen -- keine Rohanzeige, und jede Seite, deren Skript
sagWas benutzt, laedt auch meldung.js
3. lesbar -- kein Satz enthaelt Kennung, Zahl oder englisches Wort
GEFUNDEN HAT SIE SOFORT EINEN ECHTEN FEHLER: leistung.html laedt seine
Skripte ohne `defer` und fiel damit durch meinen Einbau. Dort waere
sagWas nicht definiert gewesen -- aus einer Fehlermeldung waere ein
Absturz geworden, also schlimmer als vorher.
NEBENBEFUND, DER MICH FAST EINE FALSCHE MELDUNG GEKOSTET HAETTE:
"alter_offen" heisst NICHT "etwas Aelteres ist offen", sondern
"Altersbestaetigung steht noch aus" (workspace.js:4864). Geraten
haette ich es falsch uebersetzt.
GEMESSEN: pruef-meldungen 8/0, alle 46 Skripte syntaktisch in Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
|
f9bf7d5674 |
"Hilfe anfordern" entfaellt - es bleibt die Rueckmeldung
Wunsch: "die sollen nirgendwo Hilfe anfordern koennen, sondern nur Rueckmeldungen." Es ist auch die klarere Loesung. Es gab zwei Wege, dasselbe zu sagen: einen Knopf, der eine Aufgabe erzeugte, und ein Textfeld, das eine Nachricht schrieb. Zwei Wege fuer eine Sache heisst, dass niemand weiss, welcher der richtige ist -- und dass Antworten mal als Aufgabe und mal als Nachricht landen. Wer dann nachsieht, findet die Haelfte nicht. Geblieben ist die Rueckmeldung an jedem Punkt: ein Verlauf, in dem beide Seiten schreiben koennen, sichtbar dort, wo es hingehoert -- am Punkt selbst und nicht in einer zweiten Liste. VOLLSTAENDIG entfernt, nicht nur ausgeblendet: * der Knopf in der Checkliste * der Knopf und die Marke "Hilfe moeglich" im Vorlagenblock * die Route /workspace/api/vorlagen/hilfe * 47 Datenfelder hilfe: true/false in den Vorlagen * die zugehoerigen Stile * der Abschnitt in pruef-vorlagen.mjs Datenfelder, die nichts mehr bewirken, und Routen, die niemand mehr aufruft, werden beim naechsten Mal fuer lebenden Code gehalten und mitgepflegt. Das ist teurer als das Entfernen heute. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
|
ca10479909 |
Fertige Vorlagen zum Uebernehmen - Content-Ideen und LIVE-Punkte
Der Wunsch stand an fuenf Stellen gleichlautend: "ich will dass da schon fertige Sachen stehen". Eine leere Seite mit einem Knopf "Neuer Eintrag" verlangt vom Creator genau das, was er noch nicht kann -- zu wissen, was ueberhaupt hineingehoert. WARUM VORLAGEN UND KEINE VORAUSGEFUELLTEN DATEN. Man koennte beim Anlegen eines Creators dreissig Eintraege in seine Datenbank schreiben. Das waere falsch: Sie waeren ab dem ersten Tag "seine" Eintraege und damit Altlast; aendert Filipe spaeter eine Formulierung, gilt sie nur fuer neue Creator; und die Liste saehe voll aus, obwohl noch nichts geschehen ist -- das Gegenteil einer ehrlichen Uebersicht. Vorlagen bleiben deshalb VORSCHLAEGE, bis jemand sie uebernimmt. Sie stehen im Code, gelten fuer alle sofort, und werden erst dann zu Daten, wenn sie gebraucht werden. Was uebernommen ist, ist ein ganz normaler Eintrag -- aenderbar, loeschbar, und von spaeteren Aenderungen an der Vorlage unberuehrt. INHALTE, fachlich begruendet: 13 Content-Ideen, jede mit AUSFORMULIERTEM Aufhaenger und Format. Die ersten ein bis drei Sekunden entscheiden ueber die Verbreitung -- "mach was Persoenliches" hilft niemandem, "Das haette ich am Anfang gern gewusst" kann man sagen. Verteilt nach 70/20/10 (Wert, Community, Eigenwerbung). 21 LIVE-Punkte in drei Abschnitten. Der mittlere ist der wichtigste und gibt es sonst nirgends: Was WAEHREND der Sendung auffaellt, ist am naechsten Tag weg. Diese Punkte sind so formuliert, dass man sie in einem Moment anklicken kann, in dem man eigentlich keine Zeit hat. Die Vorbereitung ist die laengste Liste, weil ein LIVE dort steht und faellt. Ton zuerst -- der Grund Nummer eins, warum Leute wieder gehen. "ICH BRAUCHE HILFE" wird eine AUFGABE, keine Nachricht. Eine Nachricht ist gelesen und dann weg; eine Aufgabe bleibt stehen, bis sie jemand erledigt, geht an den zustaendigen Betreuer (ohne Betreuer an die Leitung -- eine Bitte um Hilfe darf nicht ins Leere laufen), traegt hohe Prioritaet und eine Frist von drei Tagen. Ohne Frist bleibt sie liegen; das ist der Unterschied zwischen einer Aufgabe und einem Zettel. "CONTENT-PLANUNG" HEISST JETZT "CONTENT-IDEEN". "Planung" klang nach Terminen und Tabellen; was dort wirklich passiert, ist das Sammeln und Weiterentwickeln von Ideen. Der Kalender daneben plant. EIN CREATOR DARF SEINE EIGENEN EINTRAEGE AENDERN -- aber nur im Bereich Content. Wenn er sich eine Idee uebernimmt, ist das SEINE Idee; sie danach nicht umbenennen zu duerfen waere absurd. LIVE, Technik, Community und Schutz bleiben die Betreuungsakte, dort aendert er nichts. Ein erster Anlauf hatte die Ausnahme fuer alle Bereiche erlaubt -- die Pruefung pruef-bereiche-lesend hat das sofort gemeldet. DREI EIGENE FEHLER, VON DEN PRUEFUNGEN GEFUNDEN: - Der Vorlagenblock vergass nach dem Uebernehmen, was schon geholt war: Die Liste wird neu geladen, der Block neu gebaut, und die Markierung am Element war jedes Mal weg. Jetzt merkt sich das Modul die Auswahl. - Die Regel fuer eigene Eintraege war zu breit (siehe oben). - Die Marken im Vorlagenblock waren auf dem Handy 10,2 px klein. Co-Authored-By: Claude Opus 5 <[email protected]> |