40 Commits, um drei identische Bildschirme zu erstellen: Warum unsichtbare Vereinheitlichung alles verändert

Drei Bildschirme. Aufgaben. Memos. Ereignisse. Alle drei zeigen im Wesentlichen dasselbe an: einen Titel, einen Inhalt, Personen, die darauf zugreifen können, einen zugehörigen Ordner, Erinnerungen, Tags. Und doch hatten diese drei Bildschirme in TAMSIV jeweils ihr eigenes Layout, ihre eigene Reihenfolge der Abschnitte, ihre eigene Art, dieselben Informationen anzuzeigen. 40 Commits später ähneln sie sich endlich. Hier ist, warum diese unsichtbare Vereinheitlichung alles verändert.

Warum drei Bildschirme vereinheitlichen, die bereits funktionierten?

Die Frage ist berechtigt. Wenn die drei Bildschirme bereits funktionierten, warum 40 Commits aufwenden, um sie identisch zu machen? Die Antwort liegt in einem Wort: kognitive Belastung.

Wenn du TAMSIV täglich benutzt, wechselst du manchmal in weniger als einer Minute von einer Aufgabe zu einem Memo und dann zu einem Ereignis. Wenn jeder Bildschirm dieselben Informationen in einer anderen Reihenfolge anzeigt, muss sich dein Gehirn bei jedem Übergang neu orientieren. Du suchst das Tag oben bei der Aufgabe, findest es unten beim Memo, und findest es beim Ereignis überhaupt nicht mehr. Multipliziere das mit 20 oder 30 Konsultationen pro Tag, und die unsichtbare Reibung wird irgendwann spürbar.

Umgekehrt, wenn die drei Bildschirme sich ähneln, lernt dein Gehirn nur einmal, wo sich alles befindet. Der Titel ist oben. Der Zugriffsbaum ist direkt darunter. Der übergeordnete Ordner folgt. Die Tags kommen danach. Der Hauptinhalt nimmt die Mitte ein. Erinnerungen und Verlauf sind unten. Drei Bildschirme, eine einzige mentale Karte.

Der Zugriffsbaum: zwei Zweige, keine Mehrdeutigkeit

Die kritischste Information auf einem Detailbildschirm ist "wer sieht was". Vor dem Refactoring beantwortete jeder Bildschirm diese Frage auf seine eigene Weise. Der Aufgabenbildschirm listete einen zugewiesenen Ordner mit einem Badge auf. Der Memo-Bildschirm zeigte eine flache Liste von Mitgliedern an. Der Ereignisbildschirm zeigte einen Abschnitt "Teilnehmer" getrennt vom Rest.

Die neue Komponente TaskAccessTree ersetzt diese drei Logiken durch eine Struktur mit zwei klar beschrifteten Zweigen:

• "Besitzer"-Zweig: die Person, die die Aufgabe oder das Memo erstellt hat. Minimale Anzeige, Avatar plus Name, nichts weiter.
• "Geteilte Gruppen"-Zweig: jede Gruppe, in der der Inhalt sichtbar ist, mit der Liste der betroffenen Mitglieder in Form von gestapelten Avataren. Wenn die Aufgabe in drei Gruppen geteilt wird, werden drei Unterzweige angezeigt.

Der Vorteil dieser Zwei-Zweig-Struktur ist, dass sie zwei verschiedene Fragen beantwortet, ohne sie zu vermischen. Wer ist der Besitzer: Zweig 1. Wer sieht den Inhalt zusätzlich zum Besitzer: Zweig 2. Keine Verwechslung möglich. Ein Benutzer kann auf einen Blick verstehen, wer Zugriff hat, ohne eine einzige Textzeile zu lesen.

Wenn die Breadcrumb-Hierarchie verschwindet

Ein weiteres Refactoring-Detail, unsichtbar, wenn alles gut läuft, aber schrecklich, wenn es auftaucht: die Breadcrumb-Navigation der übergeordneten Ordner. Wenn deine Aufgabe in Familie > Einkäufe > Supermarkt abgelegt ist, zeigt der Bildschirm diesen Pfad oben als Breadcrumb an. Perfekt.

Problem: Einige Aufgaben sind in keinem Ordner abgelegt. Sie befinden sich im Stammverzeichnis. Die Breadcrumb zeigte dann einen leeren Bereich, dann einen Pfeil, dann nichts, dann den Titel. Ein visuelles Artefakt, das den Eindruck erweckte, der Bildschirm sei falsch geladen.

Der Fix ist trivial, wenn man darüber nachdenkt: Wenn die Liste der übergeordneten Elemente leer ist, wird die Komponente nicht gerendert. Zwei Codezeilen, ein visueller Fehler weniger, und der Bildschirm atmet. Das ist typischerweise die Art von Feinschliff, die kein Benutzer bewusst bemerken wird, aber jeder unbewusst als "diese App ist gepflegt" empfinden wird.

Tags mit Hashtags versehen

Tags wurden ohne Präfix oder Überschrift angezeigt. Eine flache Liste von Wörtern unter dem Inhalt. Visuell vermischten sie sich mit dem Haupttext und wurden nicht sofort als Tags identifiziert.

Die neue Darstellung fügt zwei einfache Dinge hinzu:

1. Eine Überschrift "Tags" über der Liste, damit das Auge sofort weiß, worum es geht.
2. Ein Präfix # vor jedem Tag, eine Konvention, die aus sozialen Netzwerken stammt und die jeder kennt.

Das Ergebnis ist sofort sichtbar: Eine Aufgabe mit fünf Tags zeigt jetzt eine klare Zeile wie #dringend #einkäufe #wochenende #familie #essen an, die unmöglich mit normalem Text verwechselt werden kann.

Dieselbe Reihenfolge der Abschnitte auf allen drei Bildschirmen

Auf jedem Bildschirm folgen die Abschnitte nun dieser Reihenfolge:

1. Titel und Status (oder Datum für ein Ereignis)
2. Zugriffsbaum (TaskAccessTree)
3. Zugeordneter übergeordneter Ordner (mit derselben visuellen Karte überall)
4. Tags (mit Header und Präfix #)
5. Hauptinhalt (Beschreibung, Memo-Text, Ereignisdetails)
6. Erinnerungen und Wiederholung (falls zutreffend)
7. Anhänge (falls vorhanden)
8. Verlauf und Aktivität (Kommentare, Reaktionen)

Der Wechsel von einer Aufgabe zu einem Memo und dann zu einem Ereignis bietet jetzt eine vollständige visuelle Kontinuität. Du lernst einmal, wo du klicken musst, und lernst danach nichts mehr. Ein Gewinn von einigen Millisekunden pro Konsultation, der sich für einen regelmäßigen Benutzer zu Minuten pro Tag und Stunden pro Monat summiert.

Unsichtbare Features machen Apps, die man behält

Niemand wird TAMSIV morgen starten und denken: "Oh toll, der Detailbildschirm der Aufgabe ist mit dem des Memos ausgerichtet." Unsichtbare Features werden nicht angekündigt. Sie werden nicht verkauft. Sie werden gefühlt.

Dieser 3-tägige Sprint mit 40 Commits produziert keine Marketing-Screenshots. Keine neuen Schaltflächen zum Zeigen. Keine filmischen Animationen. Und doch ist es genau die Art von Arbeit, die den Unterschied macht zwischen einer App, die man installiert und vergisst, und einer App, die man behält und weiterempfiehlt.

Die 10 Tage zuvor war ein komplettes System für Transaktions-E-Mails. Die 3 Tage danach war die Vereinheitlichung der drei Detailbildschirme. Und morgen wird es etwas anderes, ebenso Unsichtbares sein. Die App wächst, aber immer im Stillen.

Was dieses Refactoring in Zukunft ermöglichen wird

Der andere Vorteil dieser Vereinheitlichung ist, dass sie den Weg für zukünftige Funktionen viel schneller ebnet. Wenn die drei Bildschirme dieselbe Struktur teilen, kann das Hinzufügen eines neuen Abschnitts (z. B. ein "automatisch übersetzter" Bereich für ein Sprachmemo in einer anderen Sprache) einmal erfolgen und überall angewendet werden.

Vor dem Refactoring hätte das Hinzufügen eines übergreifenden Abschnitts bedeutet, ihn dreimal zu codieren, mit drei Stilvarianten und drei zu verhandelnden Platzierungen. Danach ist es eine gemeinsame Komponente, die in alle Detailbildschirme injiziert wird. Die Grenzkosten für das Hinzufügen einer neuen Funktion werden um den Faktor drei reduziert.

Das ist der wahre versteckte Nutznießer dieser Woche: nicht der heutige Benutzer, der nur eine kohärentere App sehen wird, sondern der Solo-Entwickler, der die nächsten 40 Funktionen in einem Drittel der Zeit erstellen wird.

Und währenddessen, 22 alte SEO-Weiterleitungen

Parallel zur Vereinheitlichung der Bildschirme habe ich ein Umleitungsproblem auf der Website behoben. Die ersten Übersetzungsdurchläufe des Blogs hatten 22 veraltete Slugs in DE, ES, IT und PT hinterlassen, die 404-Fehler bei Google zurückgaben. Jeder veraltete Slug wird nun dauerhaft (301) auf seine aktuelle Version umgeleitet.

Die x-default-Datei der Sitemap ist ebenfalls korrigiert, damit Suchmaschinen verstehen, welche die kanonische Version jedes Artikels ist, wenn die Sprache des Benutzers nicht ermittelbar ist.

Das sind 22 Zeilen in einer Next.js-Umleitungsdatei, 22 Indexierungsfehler weniger und potenziell 22 wiedergefundene statt verlorene Besucherpfade.

Häufig gestellte Fragen

Macht die Vereinheitlichung der Detailbildschirme die App schneller?

Technisch gesehen, marginal. Die gemeinsamen Komponenten werden effizienter im Cache gerendert, und das Javascript-Bundle schrumpft um etwa 3% dank Code-Deduplizierung. Aber der wahre Gewinn ist kognitiv, nicht technisch: Der Benutzer fühlt sich schneller, weil er mit weniger mentaler Reibung navigiert.

Warum wurde diese Vereinheitlichung nicht früher vorgenommen?

Weil es verfrüht gewesen wäre, solange die drei Bildschirme sich separat entwickelten und man noch nicht wusste, welche Abschnitte sich als übergreifend herausstellen würden. Zuerst musste jeder Bildschirm seine eigenen Bedürfnisse entdecken, und dann die gemeinsamen Muster extrahieren, sobald sie stabil waren.

Welche Auswirkungen hat das für jemanden, der TAMSIV zum ersten Mal benutzt?

Ein Neuling lernt zuerst den Aufgabenbildschirm. Vor dem Refactoring musste er dann den Memo-Bildschirm und den Ereignisbildschirm neu lernen. Danach erkennt er die Elemente sofort, und seine Lernkurve geht von drei Stufen auf eine einzige zurück. Das Onboarding wird in der wahrgenommenen Zeit um den Faktor drei reduziert.

Wird ein Benutzer den Unterschied bemerken?

Wahrscheinlich nicht bewusst. Das Refactoring ist so konzipiert, dass es unsichtbar ist. Aber wenn man einen Benutzer, der die App vor und nachher benutzt hat, fragt, was sich geändert hat, wird er oft sagen: "Die App wirkt kohärenter" oder "Ich finde meine Informationen leichter", ohne genau erklären zu können, warum.

Hat das Refactoring etwas in der mobilen Version kaputt gemacht?

Nach der Bereitstellung wurde ein vollständiges Audit durchgeführt. Es wurden keine funktionalen Regressionen festgestellt. Die Übergangsanimationen zwischen den Bildschirmen wurden sogar leicht flüssiger, da die gemeinsamen Komponenten ein vorhersehbareres Rendering durch React Native ermöglichen.

Verfügbar im Play Store, 6 Monate und 780+ Commits

TAMSIV ist seit dem 2. April im Google Play Store in Produktion verfügbar. Kostenlos, 6 Sprachen, Solo-Entwickler. Die App entwickelt sich täglich weiter, größtenteils im Stillen. Es sind die unsichtbaren 80%, die dafür sorgen, dass sie installiert bleibt.