Handbuch: Meine Builds, deine Produktbibliothek

Letzten Dienstag suchte ich einen Build und konnte mich nicht erinnern, wie ich den Chat genannt hatte — „Landingpage v2“ vielleicht, oder etwas ebenso Nichtssagendes, sechs Wochen später. Genau das ist meist der Moment, in dem Meine Builds von einem netten Extra zum tatsächlich genutzten Werkzeug wird. Ab dem dritten oder vierten generierten App bist du schneller fertig, wenn du die Bibliothek durchsuchst, als eine Chat-Liste nach etwas Erstelltem zu durchscrollen, und genau für diese Lücke ist die Bibliothek gebaut. Ich tippte aus Gewohnheit zuerst „admin“ in die Suchleiste, gab dann auf und nutzte stattdessen die Filter: Typ eingegrenzt auf Web-App, Kategorie das Ganze noch weiter unterteilen, in interne Tools gegenüber kundenseitigen, und da war es – drei Karten weiter – ein Versionsbadge mit v3. Ich hatte vergessen, dass ich zweimal in diesen Chat zurückgegangen war. Die Bibliothek zeigte mir keine Duplikate, sie zeigte Abstammung. v1 und v2 waren nicht verschwunden, sie waren nur aus der Standardansicht herausgetreten, und das erwies sich etwa zehn Minuten später als wichtig, als der Kunde eines anderen Projekts eine Navigationsänderung hasste, die ich als v4 ausgeliefert hatte. Ich öffnete die alte v3-Karte, durchsuchte deren Dateibaum direkt vor Ort, holte mir die zwei relevanten Dateien und stellte erneut bereit. Kein erneutes Prompten, kein Wühlen in einem Chat-Verlauf, um zu rekonstruieren, wie das Layout früher aussah. Das ist der Teil der Kartenanatomie, der sich schon auszahlt, bevor man überhaupt etwas öffnet: ein echter Screenshot als Vorschaubild, aufgenommen nach der Verifizierung, sodass das, was man sieht, tatsächlich das ist, was gerendert wurde, statt eines Builds, der technisch fertig war, aber beim Laden einen Fehler warf. Darunter Typ- und Kategorie-Badges, eine Versionsnummer, ein relativer Zeitstempel. Genug, um ohne Klick eine erste Einschätzung zu treffen. Und klickt man doch, teilt sich die Wahl klar auf –

Vorschau öffnet den live laufenden Build direkt, ohne Download, ohne lokalen Server. Bei einer Website ist es das bereitgestellte Erlebnis; bei einem Desktop- oder Mobile-Build kommt man damit dem Ausführen ohne Installation am nächsten.
Code ist die Dateistruktur, direkt durchsuchbar. Ich nutze das ständig für einen dreißigsekündigen Bauchcheck — hat es wirklich die Bibliothek verwendet, um die ich gebeten habe — bevor ich mich zu einem Download entschließe.
Das Aktionsmenü umfasst Download, Veröffentlichen, native Installer für alles, was das unterstützt, „In Store einreichen“ dort, wo Store-tauglich, und „Als Vorlage speichern“.

Für nichts davon muss die Unterhaltung erneut geöffnet werden. Ich bin an diesem Tag nur einmal in den ursprünglichen Chat zurückgegangen, und zwar um eine tatsächliche Änderung anzufordern – das Einzige, was die Bibliothek wirklich nicht kann: Änderungen brauchen Kontext, und Kontext lebt im Thread. Alles andere deckt die Bibliothek selbstständig ab, parallel zum Chat laufend statt als Abkürzung dorthin zurück. Veröffentlicht man etwas über die Karte, spiegelt der Chat das beim nächsten Öffnen des Threads wider; veröffentlicht man es im Chat, aktualisiert sich auch die Karte. Derselbe Build, zwei Türen. Später am Nachmittag bat mich ein Teamkollege um einen Link zu etwas, das ich eine Woche zuvor gebaut hatte, und mir fiel auf, dass ich sie nicht in die Unterhaltung schickte – ich schickte die Karte, und ehrlich gesagt hätte ich die veröffentlichte URL von der Karte geschickt, wenn sie schon live gewesen wäre. Niemand möchte den Chatverlauf einer fremden Person überreicht bekommen, nur um eine Datei zu finden. Hat ein Team erst mal mehr als ein, zwei Builds pro Person, teilt sich das ganz natürlich auf: Der Chat bleibt die private Werkstatt, die Bibliothek wird das, worauf andere tatsächlich zugreifen. Ich hatte auch ein Spiel aus einem Wochenendprojekt dort liegen, wodurch mir auffiel, dass die Bibliothek nicht die einzige Sicht auf dieselben Daten ist. Spiele erscheinen wie alles andere in Meine Builds, leben aber auch in Meine Spiele, gefiltert nach Spielmodus und Veröffentlichungsstatus – die bessere tägliche Ansicht, wenn Spiele den Großteil dessen ausmachen, was man baut. Dieselbe Logik gilt für Veröffentlicht, das den aktuellen Live-Status für alles mit URL oder Store-Warteschlange zeigt, und Veröffentlicht, das den Überprüfungsstatus in App-Stores oder Erweiterungs-Stores verfolgt. Unterschiedliche Fragen an dieselben Karten – „was läuft gerade live“ gegenüber „was habe ich zum Thema X gebaut“ – keine getrennten, zusammengeschraubten Systeme. Eine Sache hat mich beim ersten Mal überrascht: Das Veröffentlichen eines Builds friert ihn nicht ein. Ich ging danach in den Chat dieses Admin-Panels zurück, bat um eine Änderung, bekam ein v4 – und die live veröffentlichte Version lieferte weiterhin v3 aus, bis ich explizit erneut bereitstellte. Ergab Sinn, sobald ich darüber nachdachte. Könnte jeder beliebige Prompt gegen einen Live-Chat eine Produktionsseite kaputtmachen, würde niemand mehr einen veröffentlichten Build anfassen wollen. Das andere, was ich diese Woche fast beiläufig tat, war, das Admin-Panel als Vorlage zu speichern. Es war das dritte interne Tool, das ich mit im Grunde demselben Grundgerüst gebaut hatte – gleiches Layout, gleiches Auth-Gerüst, gleiche Tabellenkomponenten, nur andere Daten darunter. Als Vorlage speichern übernahm die Struktur und den Stil, nicht die konkreten Inhalte, und Build Nummer vier davon ausgehend zu starten, verwandelte ein Planungsgespräch, das sonst zwanzig Minuten gedauert hätte, in etwa fünf. Der Haken: Eine Vorlage ist zum Zeitpunkt des Speicherns eingefroren – meine Konventionen haben sich seither verschoben, und die alte Vorlage weiß das nicht. In Ordnung als Ausgangspunkt, von dem man ohnehin abweichen wird; will man Wiederverwendung, die tatsächlich synchron bleibt, ist es besser, Dateien projektübergreifend direkt zu referenzieren, statt sie als Vorlage zu speichern.

Nichts läuft ab. Dieses v1 von vor sechs Wochen, immer noch unter v3 in der Historie — weiterhin als Vorschau abrufbar, herunterladbar, veröffentlichbar, genauso zugänglich wie das, was ich heute Morgen gebaut habe. Keine Bereinigungsuhr, die im Hintergrund läuft. Die Bibliothek ist ein Archiv, aus dem man ausliefern kann, keine Verlaufsseite, gegen die man antritt.

Handbuch

TeilenX LinkedIn Facebook Reddit Quora WhatsApp Telegram E-Mail

← Alle Beiträge

Handbuch: Meine Builds, Ihre Produktbibliothek

Verwandte Artikel

Das BuildMidas-Handbuch: eine Karte der Plattform

Prompts schreiben, die gut bauen

Den Plan lesen (und ihn ändern)