Tech Talk: How scale.at built: "TimeSloth" mit Lara Aigmüller & Felix Hessenberger

• Tech-Stories

• Tech Talk

Stellt euch kurz vor

Hi, mein Name ist Lara. Ich bin selbstständige Web Front End Entwicklerin mit Liebe zu UI und UX Design.

Ich bin Felix und entwickle Web- und Mobile-Apps mit Fokus auf Skalierbarkeit. Daher der Name „scale – your web solutions“. Mittlerweile sind wir ein Team aus drei EntwicklerInnen, die individuell, oder auch gemeinsam spannende Projekte machen.

Ein Projekt, das mehr oder weniger in unserer Freizeit entstanden ist und inzwischen schon zu einem Unternehmen angewachsen ist, ist TimeSloth (dt. „das Zeitfaultier“).

Dieses Projekt werden wir euch heute vorstellen.

Warum habt ihr das gebaut?

Eine befreundete Unternehmerin hat mit einem Kunden deren Besuchermanagement digitalisieren wollen. Die haben das anfangs so gemacht, dass wirklich für jeden einzelnen Besucher ein Termin im Outlook Kalender erstellt wurde. Jede Buchung war ein Termin und irgendwann hat sich das so dermaßen überfüllt, dass sich niemand mehr ausgekannt hat.

Somit war das Ziel und die ersten Requirements:

• die Möglichkeit, wiederholende Events zu erstellen
• für die BesucherInnen, die Möglichkeit, das Ganze über einen Online Shop zu buchen
• direkt vor Ort bei der Veranstaltung die Möglichkeit zu haben, die BesucherInnen auch einzuchecken

Und somit wurde TimeSloth geboren!

Wie habt ihr das gebaut?

Wie unser Brandname „scale“ bereits sagt, geht es bei den Dingen die wir bauen um Skalierbarkeit. Bei TimeSloth war es natürlich von Anfang an klar, dass das Produkt viele BesucherInnen managen können muss und auch für zukünftige Anpassungen flexibel bleiben muss. Wenn wir nämlich Eines in unserer Entwicklerkarriere bis jetzt gelernt haben, dann zwar, dass sich Anforderungen IMMER ändern, auch wenn man das am Anfang gar nicht gedacht hätte.

TimeSloth sind eigentlich drei ineinander greifende Produkte. Es gibt zwei Web-Apps, nämlich den Manager und den Shop, sowie eine mobile App, die TimeSloth Scan heißt. Nachdem der Contextswitch für uns Entwickler immer ein großes Thema ist, haben wir geschaut, dass die Produkte alle einen ungefähr gleichen Techstack haben. Also alle drei Produkte inklusive Serverungebung verwenden TypeScript, die Benutzeroberflächen sind React/React Native und End-to-End getestet wird das Ganze dann mit cypress.

Aus Erfahrung können wir sagen, dass das Entwickeln von eigenen Design-Systemen ein ganzer Haufen Arbeit ist. Gerade bei einem kleinen Entwicklerteam macht es hier auch Sinn auf bereits Bestehendes zurückzugreifen. Wir haben uns bei TimeSloth für Material UI entschieden, das kommt bereits mit einer großen Palette an bestehenden Komponenten und Funktionalitäten und bietet dann auch die Möglichkeit mit Theme-Overrides das ganze an die eignen Bedürfnisse anzupassen und so dem Produkt trotzdem einen eigenen Look und Feel zu verleihen.

Und weil wir neben dem ganzen Entwickeln auch noch viele andere Sachen machen müssen – zum Beispiel Videodrehs, TechTalks und Blogposts ;) – freuen wir uns natürlich, wenn wir jemanden haben, der sich etwas besser auskennt, die ganzen Server und alles wartet für uns. Deswegen setzen wir stark auf gemanagte Plattformen wie Google Firebase und Heroku. Die kosten zwar etwas mehr, aber eigentlich spart man sich viel.

Wollt ihr uns das mal zeigen?

Natürlich zeigen wir euch das jetzt. Wir starten mal gleich auf der Marketing Website, welche auf timesloth.io erreichbar ist. Über den Login Button kommt man mit einem Account in den TimeSloth Manager. Das ist diese berühmte Kalender-Ansicht, wo man die ganzen nächsten Veranstaltungen sieht, inklusive der eingegangenen Buchungen. Wenn ein Termin ausgebucht ist, hat man auch eine Markierung, damit man das nicht übersieht.

Für unseren Faultier Zoo werden wir zu Demonstrationszwecken eine Veranstaltung anlegen. Und zwar eine Faultier Fütterung. Ich lege eine neue Veranstaltung an, der name ist „Faultier Fütterung“. Das ganze dauert – sagen wir – 30 Minuten. Es können 30 Leute zuschauen.

Mehr muss man eigentlich schon nicht mehr anzeigen, eventuell kann man noch sagen man braucht keine Telefonnummer für die Buchung. Bei den Preisen stellen wir noch ein, dass wir Erwachsenen- und Kindertickets haben. Ein Erwachsener zahlt 10€, Kinder zahlen 5€.

Speichern wir das mal. Man sieht jetzt noch nichts, weil wir noch nicht definiert haben, wann diese Veranstaltung stattfinden soll.

Das kann man bei TimeSloth über Regeln machen. Wir sagen, dass diese Faultierfütterung täglich stattfindet, um 10 Uhr. Auch das wird gespeichert.

Wenn man zurück in den Kalender geht, dann sieht man jeden Tag um 10 Uhr eine Faultierfütterung.

Ganz einfach eine Veranstaltung angelegt, man sieht sie jeden Tag um 10 Uhr im Kalender. Jetzt kann man auch sagen, uns ruft jemand an, der sagt, er möchte die Faultierfütterung am Samstag sehen. Der heißt Felix und kommt mit zwei Erwachsenen. Speichern, dann hat man die Buchung da und man kann jederzeit nachsehen wer gebucht hat.

Das Event ist auch im Shop sichtbar – wechseln wir kurz in den Shop. Hier sehen wir die Faultierfütterung. Wenn man hier draufklickt, hat man die Möglichkeit, einen Termin zu wählen. Ich möchte am Sonntag zur Faultierfütterung um 10 Uhr, ich sehe es sind noch Plätze frei, ich komme mit zwei Erwachsenen und zwei Kindern zur Fütterung. Und ich reserviere meine Tickets.

Ich kann mir mein Ticket herunterladen, das bekomme ich auch als Mail zugesandt.

Und wenn ich jetzt wieder zurück in den Manager wechsle, dann sehe ich hier in Echtzeit die Buchung der vier Personen, die gerade über den Shop getätigt wurde.

So funktioniert TimeSloth als Nutzer, jetzt schauen wir uns noch etwas den Code an.

Wechseln wir in die IDE – ich verwende IntelliJ und Lara verwendet WebStorm, ist aber im Prinzip das Gleiche. Wir haben ein Mono-Repo. Das heißt, unser Git Repository umfasst fast alle unserer Codebases innerhalb von einem Yarn-Workspace. Yarn – eine Package Manager Alternative zu NPM – unterstützt das, dass man mehrere Packes in einem Workspace zusammenfasst. Bei uns sind das sieben Workspaces, welche alle ihre jeweilige Aufgabe haben, alle ihren eigenen Code haben, sie können jedoch untereinander geshared. Zum Beispiel werden diese vier Packages innerhalb von allen anderen Packages nach Belieben geshared. Man hat auch gewisse Zusatzfunktionen, die zeige ich schnell in einem Terminal. Ich will meinen Core-Workspace bauen, dann kann ich das schnell über die Abkürzung „yw“ („Yarn Workspace“) problemlos machen.

Wenn ich aber etwas Suchen möchte, dann hat man ein kleines Problem. Sucht man nach dem Stichwort „Eventservice“ in Yarn Workspaces – und Mono-Repos generell – dann bekommt man gleich drei Vorschläge und ich muss mich erst wieder über den Pfad schlau machen, welches Suchergebnis das richtige ist. Das ist quasi ein Nachteil, wenn man den ganzen Code innerhalb eines Projektes verwaltet.

Es ist aber ein großer Vorteil, wenn man beispielsweise ein neues Feature einbaut. Dieses betrifft zum Beispiel die Packages „Manager“ und „API“. So sehe ich gleich im Commit gleich, dass diese Sachen betroffen werden und ich werde bestätigt, dass das alles Hand und Fuß hat.

Welche Herausforderungen gab es?

TimeSloth hat bereits einen bestehenden Kundenstamm, aber es kommen ja auch ständig neue dazu. Eine große Herausforderung für uns ist es dabei immer, beim Entwickeln von neuen Features, die bestehenden Kunden nicht zu verwirren und generell eine gute Balance zu finden von neuen Kunden und bestehenden Kunden.

Von den ursprünglichen drei großen Requirements sind wir inzwischen schon recht weit weg, es ist über die Zeit sehr viel dazugekommen. Schlussendlich soll aber trotzdem alles wie aus einem Guss aussehen, logisch zusammenhängen und wartbar sein. Da geht natürlich die Entwicklung von neuen Features immer mit Refactoring von bestehenden mit einher. So ist es natürlich immer schwierig Commits und Pull-Requests klein zu halten.

Der Product-Market-Fit ist TimeSloth auch nicht in die Wiege gelegt worden, wir haben eineinhalb Jahr gesucht. Gefunden haben wir dann eigentlich die Tatsache, dass der zentrale Baustein, die Ausgangsbasis von unserem UI der Kalender sein muss. Dieser zeigt die ganzen Termine an und von hier aus kommt man auf die ganzen anderen Bereiche des Produkts.

Was wir anders machen würden, wenn wir heute TimeSloth noch einmal gründen täten, dann würden wir von Anfang an sehr auf Self-Sign-On achten. Also der Benutzer findet seinen Weg selbst. Zur Zeit sind wir hier auf so einem großen Featureset, dass Dokumentation unerlässlich wird. Wenn man von Anfang an das macht und immer brav mitschreibt, dann täte man sich später auch leichter.

Aus technischer Sicht haben wir gelernt, dass Markdown ein unglaublich Schlechtes Format für formatierte Texte – für uns – ist, weil es für unsere Computer und für die unserer Kunden sehr schwierig war zu handlen. Jetzt haben wir das im Zuge einer größeren Migration auf Richtext mit Baumstruktur umgebaut – passend zum Faultier. Das funktioniert jetzt wesentlich besser.

Was ist gut gelungen?

Positives Feedback gibt es inzwischen schon von mehreren Kunden hinsichtlich der Übersichtlichkeit und Bedienbarkeit. Das bestätigt uns natürlich sehr in unseren Bemühungen zur User Experience.

Was inzwischen auch schon ganz gut funktioniert ist das Abwägen von neuen Features: welche Features verkraftet der Kunde ohne zusätzliche Einschulung, gegebenenfalls reichen wir auch die Dokumentation nach.

Was auch noch gut gelang, ist, dass wir verschiedenste Kundenanforderungen in ein Produkt gießen. Das ist zwar immer wieder eine Herausforderung, aber zur Zeit erfüllen wir zum Beispiel ohne Probleme die Bedürfnisse einer Brot-Erlebniswelt oder einer Segelschule.

Außerdem bin ich ein ziemlicher Fan von Tieren in Brandnamen: der Fisch in „scale“ und das Faultier natürlich bei „TimeSloth“. Man hat so auch immer eine Maskottchen UND man hat auch immer einen Grund, sich Tierkalender ins Büro zu hängen!