Beim Scrollen über marcelrgberger.com stoße ich am Ende jeder Seite auf dasselbe Element: ein Newsletter-Formular. Eingetragen haben sich in den letzten Wochen genau null Menschen. Überrascht hat mich das nicht, eher bestätigt. Der Newsletter stammte aus einer Phase, in der ich glaubte, einen Verteiler zu brauchen. Was ich tatsächlich brauche, ist ein Erstgespräch. Also habe ich das Formular entfernt und stattdessen den Buchungskalender direkt eingebettet. Das klingt nach einem kleinen Projekt, und das war es auch. Unterwegs standen aber ein paar Entscheidungen an, die ich hier festhalten möchte.
Newsletter raus, Kalender rein: warum und wie
Auf marcelrgberger.com hatte der Newsletter nie eine echte Aufgabe. Er war ein Platzhalter für eine Inhaltsstrategie, die ich nie vollständig umgesetzt habe. Was ich stattdessen schreibe, also Wochenberichte aus der laufenden Arbeit, Fallstudien und Gedanken zur App-Architektur, erscheint auf theapparchitect.com. marcelrgberger.com ist mein Portfolio. Wer dort landet, hat meinen Namen gegoogelt oder ist über ein Projekt auf mich gestoßen. Der sinnvolle nächste Schritt für diesen Besucher lautet nicht „Tragen Sie sich in den Newsletter ein“, sondern „Buchen Sie ein Gespräch“.
Technisch war die Umstellung schnell erledigt. Die MailerLite-Einbettung flog raus, ein eingebetteter Cal.com-Kalender kam hinein. Der Termintyp heißt bei mir „talk-with-marcel“, nicht „discovery call“ und nicht „strategy session“, sondern schlicht ein Gespräch. Die Sprache gebe ich per URL-Parameter weiter, damit der Kalender auf der deutschen Seite deutsch und auf der englischen Seite englisch erscheint. Hier bin ich kurz hängen geblieben: Cal.com unterstützt Sprachparameter, die Dokumentation dazu ist aber dünn. Ich habe mit ?locale=de experimentiert, bis es zuverlässig lief.
Leicht geärgert hat mich Folgendes: Ich hatte den Termintyp zwischendurch umbenannt und musste das wieder zurücknehmen, weil sich dadurch die Einbettungs-URL geändert hatte und der Kalender auf einer Seite leer blieb. Ein kleiner Fehler, aber genau die Sorte, die bei schnellen Änderungen passiert: Man zieht an einer Stelle, ohne alle Abhängigkeiten zu prüfen. Zwei Commits hinein, einer wieder heraus. Das war mein Nebenkriegsschauplatz dieser Woche.
Die Texte, die ich gleich mit überarbeitet habe
Beim Umbau der Einbettung fielen mir auf marcelrgberger.com einige Formulierungen auf, die ich so nicht stehen lassen wollte. Der Kopfsatz und die Beitragszeile der deutschen Fassung waren zu wörtlich aus dem Englischen übertragen. Man spürte förmlich, dass jemand übersetzt hatte, statt auf Deutsch zu denken. Ich habe beide neu geschrieben. Als Commit-Message stand danach „Sinngemäß statt wörtlich“, und das trifft es gut. Deutschen Text, der nach übersetztem Englisch klingt, höre ich beim Vorlesen inzwischen sofort. Er wirkt etwas zu ordentlich, zu symmetrisch und zu wenig idiomatisch.
In der Gesamtbilanz der Woche ist das eine Kleinigkeit. Mir ist aber wichtig, dass ich die Texte auf meinen eigenen Websites genauso sorgfältig behandle wie die in Kundenprojekten. Die Seite, auf der jemand entscheidet, ob er mich mit der Entwicklung seiner App beauftragt, sollte nicht nach Übersetzung klingen.
Nebenschauplätze: Buch, security.txt, toter CSS-Block
Drei kleinere Dinge erwähne ich der Vollständigkeit halber.
Das Buch, an dem ich arbeite, „Solopreneur: The Art of Working Alone“, hat drei Commits bekommen. Inhaltlich kam nichts dazu, es ging um eine Korrektur: An zwei Stellen stand noch der alte Unternehmensname. Seit letzter Woche bin ich als DigitalFreedom Global LLC tätig, und der Buchtext sollte das korrekt wiedergeben. Außerdem habe ich zwei Passagen geglättet, die durch das Umschreiben etwas holprig geworden waren. Kein inhaltlicher Fortschritt, nur Pflege.
Für civo-cloud-manager.app habe ich eine security.txt nach RFC 9116 ergänzt. Diese kleine Datei unter /.well-known/security.txt beschreibt, wie Sicherheitsforscher Schwachstellen melden sollen. Bei einer Marketing-Website ist das nicht kritisch, gehört aber zum Handwerk, und ich hatte es bisher schlicht vergessen. Wer eine native macOS-App für die Verwaltung von Kubernetes baut, sollte das zumindest für die eigene Website richtig machen.
Auf einer weiteren Website, die ich betreue, ist parallel zum Abschied vom Newsletter auf meinen Websites ein toter CSS-Block verschwunden: übrig gebliebene MailerLite-Styles, die sich ins Stylesheet eingeschlichen hatten und dort seit Wochen unnötig Bytes belegten. Sichtbar ändert sich nichts, aber sauberer Code ist sauberer Code.
Was das für eine App-Beratung bedeutet
Ich schreibe das nicht auf, um die Woche größer erscheinen zu lassen, als sie war. Es waren sieben Commits, keine große Architekturentscheidung und kein Release. Die Entscheidung dahinter, den Newsletter durch direkte Terminbuchung zu ersetzen, ist aber genau die Art von Entscheidung, die ich auch in Kundenprojekten treffe. Was ist für den Nutzer wirklich der nächste Schritt? Was steht ihm im Weg? Was kann wegfallen?
Wenn Sie selbst überlegen, eine App entwickeln zu lassen, ist das oft die wertvollste Frage in der ersten Beratungsstunde. Sie lautet nicht „Welche Features bauen wir?“, sondern „Welchen einen Schritt soll der Nutzer als Nächstes gehen?“. Alles andere ergibt sich daraus. Wenn Sie das mit mir besprechen möchten, buchen Sie direkt auf theapparchitect.com/contact/ einen Termin, ohne Formular und ohne Newsletter.
Die Wochenübersicht zu meinen laufenden Projekten finden Sie wie immer unter Projekte.