docs(ideen): eigene Logos je App, auch in der Leiste, und die Frage der Reihenfolge

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

IDEAS.md

@@ -60,8 +60,56 @@ wird es eng, am Handy sofort.
   Flexibler, aber: Speicher, Größenbegrenzungen, Auslieferung, und der
   Retro-Look bekommt bunte Fremdkörper.
 
-→ **Empfehlung: Pixelglyphen teilen.** Bilder später nachrüsten, falls je eine
-App dabei ist, für die kein Symbol passt.
+→ **Empfehlung: Pixelglyphen teilen** — als Erstes, weil es sofort trägt.
+
+**Beschlossen als Planung (25.08.2026): eigene Logos hochladen.** Je App ein
+Bild in HoneyOS hinterlegen, statt nur aus den eingebauten Glyphen zu wählen.
+Nicht als Ersatz für die Pixelglyphen, sondern daneben: Glyphe als Rückfall,
+wenn kein Bild da ist.
+
+**Das Logo gehört ausdrücklich auch in die Leiste**, nicht nur auf den
+Schreibtisch — dort ist die Unterscheidung am nötigsten, weil die Knöpfe klein
+sind und nebeneinanderstehen. Damit ist die geteilte Symbolquelle aus 1.3
+Voraussetzung: Beide Seiten müssen dasselbe Bild bekommen, sonst pflegt man es
+zweimal.
+
+Was daran zu bauen ist, in dieser Reihenfolge:
+
+1. **Hochladen und ablegen** — HoneyOS speichert heute nur eine JSON-Datei.
+   Bilder heißt: ein Ordner unter `/data`, eine Größenbegrenzung, erlaubte
+   Typen (PNG, SVG, WebP), und SVG ist heikel — es kann Skripte enthalten und
+   darf deshalb nicht einfach durchgereicht werden.
+2. **Ausliefern** — unter einer Adresse je App, mit einem Versionsanteil, damit
+   ein Austausch nicht im Cache hängen bleibt (Aether macht das beim Logo
+   schon so).
+3. **In der Leiste anzeigen** — über die Site-Grenze hinweg ein `<img>` von
+   HoneyOS. Das geht ohne Sitzung, Bilder unterliegen der CORS-Regel nicht.
+
+**Vorher zu klären:** Sollen Bilder in den Retro-Look eingepasst werden
+(auf wenige Farben reduziert, hart gerastert) oder bunt bleiben? Ein
+Original-Logo mit Farbverlauf neben Pixelglyphen sieht schnell nach Fremdkörper
+aus. Ein Filter in der Leiste wäre billig zu haben und ließe sich abschalten.
+
+### 1.3b Reihenfolge der Apps
+
+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 Leiste
+zuerst — dort ist der Platz am knappsten und die Reihenfolge entscheidet, was
+man am Handy noch sieht.
+
+Möglichkeiten:
+
+| | 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 |
+
+→ **Vorschlag: von Hand sortieren**, dieselbe Reihenfolge auf Schreibtisch und
+Leiste. 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.
 
 ### 1.4 CORS in Aether