The Atlas Outline

Die Naming-Lösung für Design- & Entwickler-Teams

Wie das Flow-Screen-State-Section-Framework das Chaos bei Design-zu-Entwicklung-Handoffs löst.

Seien wir ehrlich: Die meisten Projekte haben keine echte Namenskonvention; sie haben eine Ansammlung unzureichender Benennungsgewohnheiten, die im Chaos enden. Die Atlas Outline ist das Framework, das diese schlechten Angewohnheiten durch eine klare Landkarte und eine eindeutige Adresse für jeden einzelnen Screen ersetzt.

Jeder hat seine eigene Logik bei der Organisation von Dateien. Das funktioniert perfekt – bis man einem Team beitritt. Plötzlich erfordert dieses „offensichtliche“ System langwierige Erklärungen, und das Projekt versinkt in einem Durcheinander aus langen Dateipfaden, verwirrenden Namen und verschwendeter Zeit. Dies ist das unausgesprochene Chaos im Zentrum vieler Design-zu-Entwickler-Workflows – ein Problem, das textbasierte Namen und komplexe Ordnerstrukturen nicht lösen konnten.

Aber was wäre, wenn es ein Framework gäbe, das fast selbsterklärend ist? Deshalb habe ich die Atlas Outline ins Leben gerufen. Dies ist keine bloße Theorie; es ist ein praxiserprobtes System, das ich über viele Jahre verfeinert habe, von den frühen Tagen der Informationsarchitektur bis hin zu modernen Workflows in Figma. Es ist eine einfache, leistungsstarke Lösung, die dauerhafte Ordnung in Ihre Projekte bringt, indem sie jeder Ansicht eine einzigartige und einprägsame Adresse gibt.

Das Framework basiert auf vier Begriffen: Flow, Screen, State und Section. In diesem Artikel werde ich die einfachen Regeln hinter jeder Komponente erläutern. Am Ende verspreche ich Ihnen, dass Sie das System verinnerlicht haben, seine Vorteile verstehen und bereit sind, es in Ihrem nächsten Projekt einzusetzen.

Die Leitprinzipien einer guten Namenskonvention

Bevor wir in die Lösung eintauchen, lassen Sie uns klären, was eine erfolgreiche Namenskonvention leisten muss. Im Laufe der Jahre habe ich festgestellt, dass jedes System, das Bestand haben soll, auf vier Schlüsselprinzipien basieren muss. Es reicht nicht aus, dass ein System organisiert ist; es muss robust, intuitiv und zukunftssicher sein.

Hier sind die Prinzipien, die eine temporäre Notlösung von einer dauerhaften Lösung unterscheiden:

Was muss eine großartige Namenskonvention liefern?

Klarheit:

Ist es sofort verständlich?

Skalierbarkeit:

Funktioniert es für 10 Screens genauso wie für 500?

Stabilität:

Bricht es zusammen, wenn sich das UI ändert?

Eindeutigkeit:

Kann jede einzelne Ansicht eindeutig identifiziert werden?

Klarheit: Ist es sofort verständlich?

Ein gutes System benötigt keinen Decoden. Ein neues Teammitglied, egal ob Designer, Entwickler oder Projektmanager, sollte in der Lage sein, den Namen eines Screens zu betrachten und dessen Kontext und Zweck mit minimaler Erklärung zu verstehen. Klarheit ist die Grundlage effizienter Kommunikation.
Skalierbarkeit: Funktioniert es für 10 Screens und 500?

Der größte Fehler der meisten Ad-hoc-Systeme ist, dass sie unter Druck zusammenbrechen. Eine Konvention muss für ein einfaches MVP genauso gut funktionieren wie für eine komplexe, plattformübergreifende Anwendung. Sie sollte mit wachsendem Projektumfang nicht verwirrender werden.
Stabilität: Bricht es zusammen, wenn sich das UI ändert?

Designs sind niemals statisch. Navigationsmenüs werden neu gestaltet, Sektionen neu geordnet und Funktionen verschoben. Eine wirklich stabile Namenskonvention ist an die Funktion eines Screens gebunden, nicht an seine temporäre Position in der Sitemap. Dies stellt sicher, dass ein Redesign Sie nicht dazu zwingt, hunderte von Dateien umzubenennen und jede Referenz in Ihrer Dokumentation zu zerstören.
Eindeutigkeit: Kann jede einzelne Ansicht eindeutig identifiziert werden?

Dies ist der ultimative Test. Es muss einen Weg geben, eine eindeutige, unmissverständliche Adresse für jeden Screen zu erstellen, einschließlich all seiner möglichen Variationen – Pop-ups, Fehlermeldungen, Ladeanimationen und deaktivierte Zustände. Wenn zwei verschiedene Zustände denselben Namen haben, ist Verwirrung vorprogrammiert.

Jedes System, das auch nur an einem dieser Prinzipien scheitert, wird unweigerlich im Chaos enden. Schauen wir uns nun ein Framework an, das von Grund auf darauf ausgelegt ist, in allen vier Punkten zu glänzen: Die Atlas Outline.

Die Atlas Outline im Detail: Die vier Kernkomponenten

Die Atlas Outline gibt jedem Screen eine eindeutige, logische Adresse über eine einfache vierteilige Struktur. Sie ist so konzipiert, dass sie wie Koordinaten gelesen werden kann – von der groben User Journey bis hin zum feinsten Detail des Interfaces.

Das Format ist: [Flow]-[Screen]-[State]-[Section]

Lassen Sie uns jede Komponente aufschlüsseln.

A. [Flow]: Das Ziel oder die Journey des Nutzers

Der [Flow] ist der Identifikator auf höchster Ebene. Er repräsentiert keine einzelne Seite, sondern eine vollständige User Journey oder ein Kernfeature Ihrer Anwendung. Betrachten Sie ihn als ein wichtiges Kapitel in der Geschichte Ihres Produkts.

Die Goldene Regel:

Ein Flow ist an das Ziel eines Nutzers gebunden, nicht an dessen Position im Navigationsmenü. Dies stellt sicher, dass das System auch bei kompletten Redesigns stabil bleibt.

Der spezielle A- Flow:

Bei der Entwicklung einer Software oder Web-App ist Ihre erste Aufgabe wahrscheinlich das Design der Application Shell. Das ist alles, was permanent auf dem Screen sichtbar ist oder von jedem Screen aus erreicht werden kann, wie die Navigationsleiste oder Panels.

Beispiel:

A-01-00: Haupt-Navigationsleiste (Standardzustand).
A-02-02: Globales Benachrichtigungssystem (Aktiver Zustand, zeigt eine Nachricht).

Der spezielle 0- Flow:

Wir reservieren 0- für alle Aufgaben „vor der Anwendung“. Bei einer Web-App deckt dies die gesamte Authentifizierungsstrecke ab (Login, Registrierung, Passwort vergessen). Bei installierbarer Software repräsentiert es alle Screens des Installationsprozesses. Das eigentliche Nutzererlebnis beginnt dann mit dem 1- Flow.

Beispiele: Login, Registrierung, Passwort zurücksetzen, Software-Installation oder eine initiale Onboarding-Tour.

Beispiel-Flows:

A- Application Shell (Menüs, Panels, Nachrichten)
0- Onboarding & Authentifizierung
1- Produktentdeckung (Homepage, Kategorien, Suche etc.)
2- Checkout-Prozess
3- Account-Management (Profil, Bestellhistorie, Einstellungen)

Regelsatz #1: Flows

Die Goldene Regel: Ein Flow ist an das Ziel des Nutzers gebunden, nicht an seine Position im Menü. Das sorgt für Stabilität bei Redesigns.
Der spezielle A- Flow: Die Application Shell umfasst alles, was permanent verfügbar oder von überall erreichbar ist (Navigation, Panels).
Der spezielle 0- Flow: Reserviert für „Pre-Application“-Aufgaben wie Login oder Installation. Das Kern-Erlebnis startet mit Flow 1-.

B. [Screen]: Der spezifische Ort des Nutzers

Der [Screen] identifiziert eine spezifische, eindeutige Ansicht oder Seite innerhalb eines Flows. Wenn der Flow das Kapitel ist, ist der Screen die Seite. In der Atlas Outline nutzen wir eine zwei-stellige Koordinate (0-9, A-Z), um diesen Ort zu definieren.

Der 00 Screen: Der Einstiegspunkt

Die Nummer 00 ist immer für den primären Einstiegspunkt oder den „Index“-Screen eines Flows reserviert.

1-00: Die Homepage einer Website.
3-00: Das Haupt-Dashboard des Accounts.

Die Series-Sequence-Regel (Hierarchie)

Um Beziehungen darzustellen – wie bei einem List-to-Detail-Muster – nutzen wir Gruppierungen. Statt unübersichtlicher Dezimalstellen nutzen wir die erste Ziffer als Serie (die Gruppe) und die zweite Ziffer als Sequenz (den spezifischen Screen). So lässt sich das Interface in logische Bereiche unterteilen:

Die „10er“-Serie: Produktliste (1-10) und nachfolgende Produktdetails (1-11, 1-12).
Die „20er“-Serie: Hardware-Kategorie (1-20) und Unterkategorien (1-21, 1-22).
Die „30er“-Serie: Software-Kategorie (1-30) und Unterkategorien (1-31).

Skalierbarkeit: Alphanumerische Erweiterung

Die Atlas Outline ist für massives Wachstum ausgelegt. Da wir sowohl Zahlen (0-9) als auch Großbuchstaben (A-Z) verwenden, hat jede Position 36 mögliche Werte.

Gruppen: Sie haben 36 mögliche „Serien“ pro Flow (0-9, A-Z).
Screens: Sie haben 36 mögliche „Screens“ innerhalb jeder Serie.

Dies ergibt 1.296 eindeutige Screen-Adressen pro Flow – genug für komplexeste Enterprise-Software, ohne die vierteilige Struktur zu sprengen. Gehen die Zahlen (99) aus, folgen Buchstaben: A0, A1… B0, B1… usw.

Regelsatz #2: Screens

Die 00-Regel: Reservieren Sie -00 immer für den Haupteinstiegspunkt oder Index eines Flows.
Die Serien-Regel: Nutzen Sie die erste Stelle zur Gruppierung verwandter Seiten (z.B. die „20er“ für Suche).
Die Sequenz-Regel: Nutzen Sie die zweite Stelle für den spezifischen Screen innerhalb dieser Gruppe.
Die Stabilitäts-Regel: Einmal zugewiesen, bleibt die ID eines Screens gleich, auch wenn sich die Menüposition ändert.

C. [State]: Der aktuelle Zustand des Screens

Der [State] ist der Punkt, an dem die Atlas Outline wirklich glänzt. Während der Screen sagt, wo wir sind, identifiziert der State den spezifischen Zustand dieser Ansicht. Er ist der Schlüssel zur Beseitigung von Unklarheiten für Entwickler, QA und Stakeholder.

Der 00 State: Der Happy Path

Der Standardzustand ist immer 00 – das, was der Nutzer beim ersten Aufruf sieht (der „Happy Path“). Ein State kann den Zustand eines gesamten Screens, einer Komponente oder eines Schritts in einer Animation repräsentieren.

Das alphanumerische Raster: Unendliche Flexibilität

Genau wie die Screen-ID nutzt die State-ID zwei Stellen (0-9, A-Z). Das ergibt 1.296 mögliche Zustände pro Screen. Dies stellt sicher, dass selbst komplexeste formularbasierte Anwendungen niemals an Platzgrenzen stoßen.

Erstellung der State-Legende

Zustandsnummern müssen projektweit einheitlich und unveränderlich sein. Definieren Sie zu Beginn eine State-Legende als Single Source of Truth.

Empfohlene Zustandsbereiche:

Um die Atlas Outline intuitiv zu halten, empfehlen wir folgende Bereiche:

00–1Z: Allgemeine UI-Zustände
- 00: Standard / Initiale Ansicht
- 01: Hover / Focus (z.B. Button wird berührt)
- 02: Aktiv / Ausgewählt (z.B. aktiver Navigationspunkt)
- 04: Laden (z.B. Skeleton Screen oder Spinner)
- 06: Fehler (z.B. allgemeiner Seitenladefehler)
- 07: Erfolg (z.B. „Aufgabe erledigt“-Meldung)
20–4Z: Die Input-Serie (Transfer Convention)
Reserviert für Benutzereingaben, meist Schritte in einem Formular oder Wizard vor dem Absenden.
50–7Z: Die Output-Serie (Transfer Convention)
Reserviert für Systemantworten auf Eingaben, wie Suchergebnisse oder gefilterte Ansichten.
80–ZZ: Eigene / Projektspezifische Zustände
Für alles Einzigartige, wie Animationsschritte.

Regelsatz #3: GLOBAL VS. LOKAL

Eine State-ID auf Screen-Ebene (1-10-06) stellt einen globalen Zustand dar (der ganze Screen hat einen Fehler). Eine State-ID gefolgt von einer Sektion (1-10-06-04) stellt einen lokalen Zustand dar (der Screen ist ok, aber Sektion 04 hat einen Fehler).

D. [Section]: Der optionale Ankerpunkt

Die [Section] ist Ihre Geheimwaffe für komplexe Seiten. Es ist ein optionaler Identifikator, um einen spezifischen Bereich oder eine Komponente innerhalb eines Screens zu markieren.

Wichtig: Mit „Section“ meinen wir einen konzeptionellen Bereich aus der Designphase – nicht zwangsläufig das HTML-Tag <section>. Es ist eine logische Gruppierung wie „Zahlungsformular“ oder „Bestellübersicht“. Das trennt die Designlogik vom Code und hält das System stabil.

Wann man sie nutzt:

Bei langen Seiten, Dashboards oder um den Ort eines Zustands zu präzisieren (z.B. Fehlermeldung spezifisch in der Sektion „Zahlungsdetails“ im Checkout).

Die Optionalitäts-Regel:

Dies ist der einzige Teil der Adresse, der nicht zwingend erforderlich ist. Bei einfachen Screens lassen Sie ihn einfach weg, um die Benennung schlank zu halten.

Beispiel: 2-01-06 könnte bedeuten, der gesamte Screen „Versandinfo“ hat einen Fehler.
Beispiel: 2-01-06-03 bedeutet, der Fehler liegt spezifisch in der Sektion „Postleitzahl“ (03) dieses Screens.

Durch die Kombination dieser vier Komponenten schaffen Sie ein System, das klar, skalierbar und extrem stabil ist. Es erfüllt alle vier Leitprinzipien. Natürlich können Sie Labels (Namen) zur besseren Orientierung hinzufügen, aber die numerische ID bleibt das stabile Fundament. Wenn Sie den ersten Screen von „1-00 Home“ in „1-00 Start“ umbenennen, bleibt der Link durch die ID konsistent. Das Label ist nur eine Hilfe, auf die ich am Ende noch einmal eingehe.

Der Sprachcode (I18n)

Beim Design von User Interfaces ist es wichtig, die Sprache anzugeben. Wir nutzen dafür Standard-Länder- und Sprachcodes. Da die Sprache essenziell ist, wird sie direkt nach der Sektion (oder dem State) angehängt.

Variationen (Optional)

Oft experimentiert man mit verschiedenen Varianten desselben Screens. Die Atlas Outline nutzt dafür einen Unterstrich am Ende und Großbuchstaben. Ein _A oder _B markiert die Variante.

Wird eine Variante final, löschen (!) Sie den Unterstrich bei dieser, behalten ihn aber bei den anderen. So können Sie jederzeit auf alte Ideen referenzieren, ohne sie löschen zu müssen.

Versionierung (Semantik & Datum)

Software entwickelt sich weiter, ebenso das UI. In der Entwicklung nutzen wir semantische Versionierung (z.B. v1.1). Wir wollen Änderungen tracken und alte Screens als Referenz behalten.

Für das Screen-Design nutzen wir zusätzlich ein Datums-Format: YYMMDD.

Um beides zu kombinieren, nutzen wir das Suffix (@) mit einem internen Trenner. Das hält das Format sauber und gruppiert alle Versions-Infos logisch.

Das empfohlene Format ist: @[SemanticVersion]#[DateVersion]

Das Raute-Symbol (#) ist ein idealer Trenner, da es weder in der semantischen Versionierung noch im Datum vorkommt.

So sieht es in der Praxis aus

Beispiel Passwort-Vergessen-Dialog: 1-01-02-00.

Design für ein künftiges Software-Release:

1-01-02-00@2.2.0 (Design für Version 2.2.0).

Spezifische Design-Iteration nach Datum:

1-01-02-00@250912 (Stand vom 12. September 2025).

Handhabung mehrerer Iterationen pro Tag:

Nutzen Sie kleine Buchstaben (a, b, c). @250912b ist die zweite Version des Tages.

Kombination (Beispiel-Szenario):

1-01-02-00@2.2.0#250912b

Dieser Identifikator sagt dem Team: „Dies ist die Iteration b vom 12.09.2025 für das Software-Release 2.2.0.“

Die Transfer Convention: Best Practice für Formulare

Für Anwendungen mit vielen Nutzereingaben fügen wir eine optionale Organisationsebene zur State-Legende hinzu. Diese „Transfer Convention“ reserviert Bereiche für Inputs und System-Outputs.

Dies macht die Legende projektübergreifend vertraut und standardisiert den „Dialog“ zwischen Nutzer und System.

Empfohlene Bereiche:

00-1Z: Allgemeine UI-Zustände.

Standard, Hover, Laden, allgemeiner Erfolg/Fehler etc.

20-4Z: Transfer Convention:

User Input States. Repräsentiert Zustände während der Eingabe, vor dem Absenden.

50-7Z: Transfer Convention:

System Output States. Spezifische Systemantworten, wie detaillierte Validierungsmeldungen.

80-9Z: Custom / Projektspezifisch.

Flexibler Bereich für alles Weitere.

Die Label Convention: Zahlen eine Bedeutung geben

Die Atlas Outline ID ist der stabile Anker, sollte aber immer mit einem lesbaren Label ergänzt werden. Das Label dient als kontextuelle Gedächtnisstütze.

Best Practice ist ein Label, das den gesamten Pfad beschreibt. So bleibt die Referenz auch isoliert (z.B. in einem Jira-Ticket) ohne Nachschlagen verständlich.

Gute vs. bessere Labels:

Gut (aber unvollständig):

1-03-50-01: Output-Sektion

Besser (klar & kontextuell):

1-03-50-01: Produktentdeckung – Suchseite – Fehlerzustand – Ergebnisse

Platzsparend (CamelCase):

1-03-50-01: ProdEntd-Suche-Fehler-Ergebn

Wichtig: Die numerische ID ist permanent. Das Label ist flexibel. Sie können „1-00 Home“ in „1-00 Start“ ändern, ohne den Link zur ID zu brechen.

Die vollständige einheitliche Struktur

Hier ist die finale Struktur inklusive aller optionalen Suffixe:

[Flow]-[Screen]-[State]-[Section].[I18n]_[Variation]@[VersionInfo]

Beispiel für alle Komponenten im Einsatz:

1-01-02-00.DE_A@2.2.0#250924b

1-01-02-00: Kern-ID (z.B. Passwort-Dialog, Standard).
.DE: Länder- & Sprachcode.
_A: Design-Variante A.
@2.2.0#250924b: Iteration b vom 24.09.2025 für Software-Version 2.2.0.

Dieser Ansatz erlaubt es, Metadaten strukturiert über die Kern-ID zu legen.

Die Vorteile: Warum Ihr Team die Atlas Outline nutzen sollte

Die Atlas Outline verbessert die Zusammenarbeit grundlegend. Es ist eine kleine Änderung mit großen Auswirkungen auf den gesamten Workflow.

Vier Hauptvorteile:

1. Kristallklare Kommunikation

Die Atlas Outline schafft eine universelle Sprache. Wenn alle dieselbe Nummer nutzen, entfällt das Raten. Das reduziert Missverständnisse in Meetings und Tickets drastisch.

2. Reibungslose Design-zu-Entwicklung-Handoffs

Entwickler müssen nicht mehr raten, welche Zustände sie bauen sollen. Figma-Frames wie 1-01.1-05 sind präzise Spezifikationen. Das macht Handoffs schneller und fehlerfreier.

3. Zukunftssichere und skalierbare Projekte

Da das System an Funktionen gebunden ist, bleibt es stabil. Ein Redesign bricht die Dokumentation nicht. Das erleichtert das Onboarding neuer Mitglieder und lässt das System mit dem Projekt wachsen.

4. Effizientes Projektmanagement

Tickets werden präzise: „Fehler in 2-03-06-02.“ Der Entwickler weiß sofort, wo er suchen muss: Checkout-Flow, Payment-Screen, CVV-Sektion. Das beschleunigt Zyklen und reduziert Bugs.

Fazit: Ihr Atlas wartet

Die Atlas Outline führt Sie aus dem Benennungschaos heraus. Sie bietet eine einfache Adresse für jeden Bereich und baut eine Brücke zwischen Design und Entwicklung. Ein kleiner Aufwand zu Beginn zahlt sich durch enorme Zeitersparnis und bessere Zusammenarbeit aus.

Beispiele

Hier sind einige Beispiele, die die Anwendung der Atlas Outline verdeutlichen.

Website-Beispiel

Mapping einer Standard-Unternehmenswebsite mit klarer Informationsarchitektur.

Die Navigation ist in drei Bereiche unterteilt:

1. Hauptmenü (Primäre Navigation)

Homepage
Produkte
- Hardware: Displays, Festplatten, Computer etc.
- Software: Grafiksoftware, Spiele, Business.
Services
Kontakt

2. Info-Menü (Footer)

Über uns
AGB
Datenschutz
Impressum

3. User-Menü (Account)

Login / Logout
Konto

Der wichtigste Schritt ist die Gruppierung nach User Journey (Flow), nicht nach der visuellen Position. So bleibt das System stabil bei Menü-Änderungen.

Definition der Flows

Vier logische Flows für dieses Szenario:

0- Authentifizierung: Der Login-Prozess.
1- Kern-Business: Homepage, Produkte, Services, Kontakt.
2- Info & Rechtliches: Über uns, AGB, Impressum etc.
3- Account-Management: Verwaltung der Kontodaten.

Nummerierung der Screens

Zuweisung eindeutiger Adressen (hier primär Standardzustand -00).

0- Authentifizierung

0-01-00 Login-Seite: Hauptscreen der Anmeldung.
0-01-06 Login-Seite (Fehler): Dieselbe Seite mit Fehlermeldung.

1- Kern-Business & Discovery

1-00-00 Homepage: Haupteinstiegspunkt.
1-01-00 Produkte (Hauptseite): Top-Level Produktseite.
1-01.1-00 Hardware: Unterseite von Produkte (1-01).
1-01.1-00-01 Hardware-Kategorien: Sektion auf der Hardware-Seite.
1-01.1.1-00 Computer: Unterseite von Hardware (1-01.1).
1-01.2-00 Software: Geschwisterseite zu Hardware.
1-02-00 Services: Peer-Seite zu Produkten.
1-03-00 Kontakt: Weitere Peer-Seite.

2- Info- & Rechts-Flow

2-01-00 Über uns
2-02-00 AGB
2-03-00 Datenschutz
2-04-00 Impressum

3- Account-Management

3-00-00 Account-Dashboard: Hauptseite nach dem Login.

Dieses System bleibt stabil: Würde „Kontakt“ in ein anderes Menü wandern, bliebe die Nummer (1-03-00) gleich.

5 Probleme, die die Atlas Outline löst

Vage und inkonsistente Benennung

Fehlende formale Systeme führen zu inkonsistenten Namen. Das sorgt für Chaos und Zeitverlust bei der Suche nach Ansichten.
Chaotische Handoffs

Entwickler müssen oft raten, wie Variationen (Fehler, Ladezustände) aussehen sollen. Das führt zu Fehlern und Nacharbeit.
Fragile, UI-gebundene Namen

Namen, die an sitemaps hängen, brechen bei Redesigns. Das erfordert massiven Aufwand für die Aktualisierung der Dokumentation.
Mangelnde Skalierbarkeit

Einfache Systeme versagen bei komplexen Apps mit hunderten Screens. Das System wird unzuverlässig, je größer das Projekt wird.
Ineffizientes Projektmanagement

Vage Tickets wie „Bug im Checkout“ erfordern Rückfragen. Es fehlt die Präzision, um Fehler sofort zu lokalisieren.

5 Vorteile der Atlas Outline

Kristallklare Kommunikation

Schafft eine eindeutige Sprache für das gesamte Team und dient als Single Source of Truth.
Präzise Handoffs

Designfiles werden zur Spezifikation. Figma-Frames wie 1-01.1-05 sagen exakt, was zu bauen ist.
Zukunftssichere Stabilität

Da das System an Funktionen (Flows) hängt, bleibt es stabil, auch wenn sich das visuelle UI komplett ändert.
Integrierte Skalierbarkeit

Funktioniert für MVPs genauso wie für 500-Screen-Applikationen durch das vierteilige hierarchische Format.
Optimiertes Projektmanagement

Erlaubt präzise Referenzen in Tickets („Bug in 2-03-06-02“). Das macht Bug-Reports und Management effizienter.

Häufig gestellte Fragen

Ist das System für kleine Projekte nicht zu viel?

Keineswegs. Die Stärke der Atlas Outline ist ihre Skalierbarkeit. Bei kleinen Projekten nutzt man evtl. nur Flow-Screen-State. Es legt ein Fundament, das mitwächst, damit man später nichts mühsam umorganisieren muss.

Wie nummeriere ich Modals oder Pop-ups?

Behandeln Sie jede Ansicht, die den Fokus übernimmt, als neuen Screen innerhalb des Flows. Ein Pop-up auf der Produktseite (1-01.1-00) wäre dann ein neuer Screen in der Hierarchie, z.B. 1-01.2-00.

Warum Zahlen statt beschreibender Wörter?

Drei Gründe:

Kürze: Nummern sind schneller zu referenzieren.
Sprachneutralität: 06 bedeutet für jeden Entwickler weltweit dasselbe.
Keine Debatten: Nummern eliminieren Diskussionen über Wortwahl. Die Nummer ist die ID, der Text nur das Label.

Was ist mit dynamischen Inhalten?

Hier nutzt man ein „Template“. Erstellen Sie einen generischen Screen für „User-Liste“ (z.B. 1-10-00). Die Nummer steht für die Funktionalität, nicht für den individuellen Inhalt.

Müssen Dateinamen im Code den Atlas-Nummern entsprechen?

Nicht zwingend. Es ist ein Kommunikationssystem, keine strikte Dateiregel für Code. Die ID dient als Brücke in Tickets oder Kommentaren (// Entspricht Atlas ID: 2-01-06).

Was passiert bei Menü-Umstellungen?

Nein, das ist der Clou. Die Nummern hängen an der Funktion. Verschiebt sich die Seite im Menü, bleibt die Nummer gleich. Nichts in der Dokumentation bricht zusammen.