diff --git a/IDEAS.md b/IDEAS.md index ced472e..99ad6d7 100644 --- a/IDEAS.md +++ b/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 -zwei Stück ist das keine Frage; ab vier oder fünf schon, und in der HoneyBar -zuerst — dort ist der Platz am knappsten und die Reihenfolge entscheidet, was -man am Handy noch sieht. +Heute stehen die Apps so, wie sie eingetragen wurden. Ab vier, fünf Stück ist +das eine Frage — in der HoneyBar zuerst, weil dort der Platz am knappsten ist +und die Reihenfolge entscheidet, was man am Handy ohne Wischen 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 | -|---|---|---| -| 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 | +**Pfeile statt Ziehen**, im Programm-Editor je Zeile ein ▲▼: -→ **Vorschlag: von Hand sortieren**, dieselbe Reihenfolge auf Schreibtisch und -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 -dazukommt**, nicht vorher. +| | Aufwand | am Handy | Tastatur/Vorlesen | +|---|---|---|---| +| **Pfeile** | ~40 Zeilen | sofort | ja | +| 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 — `
` 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 `` — 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 - Kopien. Es zeigt, was die Apps hergeben, und hört da auf. +- **HoneyOS speichert nichts aus den Apps.** Keine Dateien, keine Notizen, + 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.