1.3b geplant, Notizzettel-Widget notiert

Reihenfolge: Pfeile statt Ziehen (HTML5-Drag loest am Handy nicht aus),
dazu ein A-Z-Knopf. Die eigene Reihenfolge je Nutzer waere rein additiv —
sie braucht die gemeinsame als Rueckfall und haengt an derselben
Bedingung wie persoenliche Apps: zweiter Nutzer oder eine Domain.

Dazu Marcs Zettel-Widget, mit der Abgrenzung zu InkNote als Kernpunkt.
Und die Regel 'speichert keine Inhalte' praezisiert: Sie meint keine
Zweitkopie aus den Apps, nicht das, was der Schreibtisch selbst
hervorbringt.

IDEAS.md

@@ -90,26 +90,71 @@ Kacheln und beantwortet genau die Frage, die ein generisches Symbol offenlässt.
 Hochladen (siehe „Eigene App-Logos" in Teil 2). Sie hängen an derselben Ablage
 wie das Bild-Widget und gehören deshalb dorthin, nicht mehr ins Fundament.
 
-### 1.3b Reihenfolge der Apps
+### 1.3b Reihenfolge der Apps — geplant (29.08.2026)
 
-Heute stehen die Apps in der Reihenfolge, in der sie eingetragen wurden. Bei
+Heute stehen die Apps so, wie sie eingetragen wurden. Ab vier, fünf Stück ist
-zwei Stück ist das keine Frage; ab vier oder fünf schon, und in der HoneyBar
+das eine Frage — in der HoneyBar zuerst, weil dort der Platz am knappsten ist
-zuerst — dort ist der Platz am knappsten und die Reihenfolge entscheidet, was
+und die Reihenfolge entscheidet, was man am Handy ohne Wischen sieht.
-man am Handy noch sieht.
 
-Möglichkeiten:
+**Die halbe Arbeit ist schon getan:** Die App-Liste ist ein Array, und dessen
+Reihenfolge *ist* die Reihenfolge — Streifen, Schublade, Kacheln,
+Schreibtischsymbole und Startmenü zeichnen alle daraus. Es fehlt nur eine
+Möglichkeit, das Array umzustellen. Kein neues Feld, kein neuer Endpunkt.
 
-| | Aufwand | taugt für |
+**Pfeile statt Ziehen**, im Programm-Editor je Zeile ein ▲▼:
-|---|---|---|
-| von Hand sortieren (ziehen oder Pfeile) | klein | wenige Apps, feste Meinung |
-| alphabetisch | fast keiner | wenn die Namen gut gewählt sind |
-| nach Häufigkeit der Nutzung | mittel, braucht Zählung | viele Apps |
-| feste Reihenfolge + Rest alphabetisch | mittel | Mischung |
 
-→ **Vorschlag: von Hand sortieren**, dieselbe Reihenfolge auf Schreibtisch und
+| | Aufwand | am Handy | Tastatur/Vorlesen |
-HoneyBar. Zählen, wie oft etwas benutzt wird, heißt Nutzungsdaten speichern —
+|---|---|---|---|
-dafür ist der Nutzen hier zu klein. **Zu entscheiden, sobald die vierte App
+| **Pfeile** | ~40 Zeilen | sofort | ja |
-dazukommt**, nicht vorher.
+| HTML5-Ziehen | ~30 Zeilen | **löst bei Berührung nicht aus** | nein |
+| Ziehen über Zeigerereignisse | ~120 Zeilen | ja | nur mit Zusatzarbeit |
+
+Man sortiert vier bis sechs Apps einmal, in einer Liste aus aufklappbaren
+Zeilen — `<details>` und Ziehen vertragen sich ohnehin schlecht. Die
+Zeigerereignis-Variante lohnt erst, wenn sie mehrfach gebraucht wird, und genau
+das kommt: „Widgets verschieben" braucht sie zwingend. Wird sie dort gebaut,
+kann die App-Liste sie später erben.
+
+Dazu ein Knopf **A–Z**: einmal alphabetisch sortieren, danach ist es wieder
+Handarbeit. Kein dauerhafter Modus, keine Einstellung, keine zwei
+Sortierzustände im Kopf.
+
+Beim Bauen zu beachten:
+
+- Der Klick auf einen Pfeil sitzt in einem `<summary>` — ohne `preventDefault`
+  klappt jeder Sortierklick die Zeile auf.
+- Beim Neuzeichnen müssen offene Zeilen offen bleiben.
+- Gespeichert wird wie bisher die ganze Liste auf einmal: Man kann probieren,
+  ohne dass sofort alles umspringt.
+- **Die Zifferntasten wandern nicht mit.** Die stehen je App fest; sonst startet
+  `2` morgen etwas anderes als heute.
+
+#### Und eine eigene Reihenfolge je Nutzer? — später, aber der Weg bleibt offen
+
+Marcs Frage vom 29.08.2026. **Das ist kein Entweder-oder:** Eine persönliche
+Reihenfolge braucht die gemeinsame als Rückfall. Sie sähe so aus —
+
+```
+apps:                  [aether, inknote, status, pdf]   ← die Liste, für alle
+users[marc].appOrder:  "pdf,aether,inknote"             ← nur IDs, nur seine Sicht
+```
+
+— unbekannte IDs ignorieren, fehlende hinten anhängen. Das passt **ohne
+Datenmodell-Änderung** in die bestehenden Einstellungen (`map[string]string`).
+Was jetzt gebaut wird, wird davon also nicht falsch.
+
+Zwei Gründe, trotzdem mit der gemeinsamen anzufangen:
+
+1. **Es gibt einen Nutzer.** „Meine Reihenfolge" und „die Reihenfolge" sind
+   heute dasselbe — der Unterschied wäre nicht erlebbar, der Code müsste ihn
+   für immer tragen.
+2. **Die HoneyBar in fremden Apps erkennt den Nutzer nicht.** Sie weist sich mit
+   dem Schlüssel aus, nicht mit einer Sitzung, und bekäme die Reihenfolge des
+   Standardnutzers, während der Schreibtisch die eigene zeigt — derselbe Bruch
+   wie heute bei den Farben.
+
+→ **Zusammen mit „Persönliche Apps je Nutzer" zu bauen, und beides hängt an
+derselben Bedingung: ein zweiter Nutzer oder alles unter einer Domain.**
 
 ### 1.4 HoneyOS selbst als PWA
 
@@ -285,6 +330,35 @@ Zu klären, wenn es soweit ist:
 - Passt zum Aufnehmen eigener App-Logos (1.3): dieselbe Ablage, dasselbe
   Ausliefern. Zusammen bauen spart die Hälfte.
 
+### Notizzettel-Widget — Marcs Idee (29.08.2026)
+
+Ein Zettel auf dem Schreibtisch: hineintippen, fertig. Serverseitig je Nutzer,
+also auf jedem Gerät derselbe Text.
+
+**Die Abgrenzung ist hier wichtiger als die Technik:** InkNote gibt es schon.
+Der Zettel darf **keine zweite Notiz-App** werden — kein Titel, keine Liste,
+keine Ordner, keine Suche, keine Formatierung. Genau *ein* Textfeld, das man
+im Vorbeigehen benutzt: Einkaufszettel, eine Nummer, ein Gedanke. Alles, was
+länger lebt als ein Tag, gehört nach InkNote — ein Knopf „nach InkNote"
+(einfach ein Link) wäre die ehrlichere Antwort als ein zweites Feld.
+
+Reizvoll ist es aus demselben Grund wie das Bild-Widget: Es *ist* etwas, statt
+etwas anzuzeigen. Und es braucht keine der Voraussetzungen, an denen die
+anderen Widgets hingen.
+
+Zu klären, wenn es soweit ist:
+
+- **Wann wird gespeichert?** Nicht bei jedem Tastendruck — verzögert wie die
+  Einstellungen, plus beim Verlassen des Feldes. Sonst schreibt jede Taste die
+  JSON-Datei neu.
+- **Länge begrenzen.** Ein Zettel, kein Dokument; ein paar tausend Zeichen
+  reichen, und der Server muss die Grenze durchsetzen, nicht das Formular.
+- **Zwei offene Geräte überschreiben einander.** Ohne Konfliktbehandlung
+  gewinnt das zuletzt gespeicherte. Für einen Zettel ist das vertretbar — man
+  sollte es nur wissen und nicht später „Datenverlust" nennen.
+- **In der HoneyBar?** Nur lesend, und auch das erst, wenn alles unter einer
+  Domain liegt — schreiben kann sie von einer fremden Site aus nicht.
+
 ### Eigene App-Logos — verschoben aus 1.3 (29.08.2026)
 
 **Beschlossen als Planung (25.08.2026), aber nicht als Nächstes.** Je App ein
@@ -537,7 +611,12 @@ Damit es nicht alle paar Monate neu diskutiert wird:
   und eine Cookie-Sitzung für InkNote. Beides ist nicht mehr gewollt — der Weg
   über den HoneyBar-Proxy zeigt HoneyOS in den Apps, statt die Apps in HoneyOS
   nachzubauen.
-- **HoneyOS speichert keine Inhalte.** Keine Dateien, keine Notizen, keine
+- **HoneyOS speichert nichts aus den Apps.** Keine Dateien, keine Notizen,
-  Kopien. Es zeigt, was die Apps hergeben, und hört da auf.
+  keine Kopien — es zeigt, was die Apps hergeben, und hört da auf. **Was der
+  Schreibtisch selbst hervorbringt, ist etwas anderes** (präzisiert 29.08.2026,
+  als Bild- und Zettel-Widget dazukamen): ein hochgeladenes Bild, ein Zettel,
+  ein App-Logo. Die Grenze verläuft nicht bei „Inhalt", sondern bei
+  **Zweitkopie**: Nichts, was in einer App lebt, darf hier ein zweites Zuhause
+  bekommen.
 - **Keine Rechteverwaltung.** Die App-Liste gilt für alle Angemeldeten. Für eine
   Handvoll eigene Konten gewollt; wäre es je mehr, müsste das neu gedacht werden.