Pattern Library by ion2s

Sebastian und Marek haben mit Oloid ihre eigene Produktidee bei ion2s entwickelt und umgesetzt. Sie möchten mit ihrem Open-Source-Package die Kluft zwischen Designern und Entwicklern schließen.

Oloid ist eine Pattern-Library für das PHP-Framework Laravel, die mit lokalen Projekten und Repositories kommunizieren kann, um die angelegten Komponenten und Patterns in einer WebApp anzuzeigen. Dort können Teammitglieder Code anzeigen, sich Feedback erbitten und schnell und einfach mit Dummy-Inhalten testen, ob das Gebaute den tatsächlichen Ansprüchen gerecht wird.Wie die beiden zu dieser Idee kamen und warum sie damit den Alltag vieler Designer und Entwickler beeinflussen könnten, erfahrt ihr in unserem Interview.

Stellt euch doch einmal kurz vor — Wer seid ihr und was macht ihr bei ion2s?

Sebastian: Ich bin Sebastian und seit sieben Jahren als Softwareentwickler bei ion2s. Neben der Backend-Entwicklung mit PHP und Java, betreue ich auch die Server-Infrastruktur für unsere Produkte. Gemeinsam mit Marek bin ich jetzt seit fünf Jahren in der Produktentwicklung tätig.Marek: Hey, ich bin der Marek. Ich arbeite seit mittlerweile fünf Jahren für ion2s als UI/UX Designer & Frontender. Ich bin ebenso wie Sebastian neben meinen regulären Aufgaben in der Produktentwicklung tätig.

Was ist Oloid genau und wie seid ihr überhaupt erst auf die Idee gekommen?

Marek: Oloid ist unser Versuch, die Entwicklung von allseits gehypten Designsystemen mit der Entwicklung der eigentlichen Anwendung zu verheiraten. Es ist leider immer noch so, dass die Pflege eines Designsystems oder auch einer Patternlib eher ein zusätzliches Doing darstellt, das gerne mal vergessen wird.Das wollen wir mit Oloid ändern und nebenbei die interdisziplinäre Kollaboration zwischen Designern und Entwicklern aber auch Stakeholdern vereinfachen.Auf die Idee sind wir — wie so häufig — gekommen, weil wir gemerkt haben, dass uns bei gängigen Lösungen immer etwas gefehlt hat und unsere eigentlichen Probleme nicht wirklich gelöst wurden. Beispielsweise denken die Leute, dass sich der Aufwand ein Designsystem zu entwickeln nur bei mega großen und komplexen Anwendungen lohnt, beziehungsweise es zu aufwendig für kleinere Projekte ist.Das möchten wir aushebeln. Gleichzeitig möchten wir nicht haufenweise JS-Frameworks in die Entwicklung einer simplen Webseite schaufeln, was zahlreiche zum Beispiel auf React oder ähnlichem basierende Lösungen für uns ausschließt. Außerdem sind wir der Meinung, dass die eigentliche Power von einem Designsystem in der Kollaboration liegen sollte. Das kommt häufig viel zu kurz.

Was sind die Vorteile von Oloid? Was macht es so besonders gegenüber diesen anderen Lösungen?

Marek: Ganz klar das nahtlose Verzahnen von der Entwicklung des Designsystems parallel zur Entwicklung des eigentlichen Projekts. Gängige Patternlibs sind häufig einfach nur eine Dokumentation, jedoch kein Arbeitswerkzeug.Ich denke wir fahren einen recht spannenden Ansatz damit, dass wir sagen: „Hey, wir wollen nicht entwickeln und dann wenn mal Zeit ist dokumentieren.“Bislang haben wir ein über Composer installierbares Package für jedermanns Laravel-Projekt released. Das ist Open Source und bleibt es auch. Damit kann man lokal bereits erste Features von Oloid bei der Entwicklung nutzen, wie zum Beispiel das Anpassen des Front-Matter Status über die GUI und das Dokumentieren von den im Projekt tatsächlich verwendeten Patterns.Das Dashboard informiert mich als Entwickler darüber, ob es Patterns gibt, die zu reviewen sind oder gar abgelehnt wurden. Oloid warnt mich auch davor, ein nicht freigegebenes Snippet zu verwenden und unter Umständen sogar zu deployen.Natürlich haben wir auch noch eine Menge weitere Ideen, die wir noch umsetzen möchten und hoffentlich auch werden. Darüber hinaus planen wir neben Laravel noch weitere Frameworks zu unterstützen.Sebastian: Letztlich ist unsere Vision, es dem Entwickler einfacher und effizienter zu machen, ein Frontend zu entwickeln. Er spürt den Aufwand das Designsystem zu erstellen gar nicht, weil er es nebenbei macht. Da wir selbst Entwickler sind, wissen wir aus eigener Erfahrung welche Kleinigkeiten den Entwicklungsprozess noch runder machen. Seid gespannt was noch kommt.

Jetzt habt ihr uns neugierig gemacht. Könnt ihr uns einen Hinweis geben, welche Erweiterungen ihr schon konkret im Kopf habt?

Marek: Ja, wie Sebastian bereits gesagt hat, haben wir noch viele Ideen für das Package, die wir noch umsetzen möchten. Zum Beispiel Dinge wie das Hin- und Herwechseln zwischen verschiedenen Instanzen eines Patterns. Das Package stellt jedoch nur einen ersten Schritt dar.Eine lokale Patternlib, die dem Entwickler bei der Arbeit hilft, ist zwar schon ganz nice, aber auch die muss eben installiert und regelmäßig geupdated werden etc. In Zukunft möchten wir dem Entwickler zusätzlich eine WebApp an die Hand geben. Das eröffnet zig Möglichkeiten um den interdisziplinären Workflow zu optimieren.So sollen auch Designer ihre Designs in der WebApp hochladen können, damit diese dann von Entwicklern umgesetzt werden. Anschließend kann die Umsetzung von den Designern, Projektmanagern und letztlich auch vom Auftraggeber zentral am gleichen Ort überprüft werden. Angedacht sind auch so Sachen wie zum Beispiel Anmerkungen im Code, Sharing des Projekts via Link, Notifications über Status und Updates und vieles mehr. Das wird super-spannend!

Welche Learnings habt ihr bei der Entwicklung von diesem oder anderen Produkten gehabt und wie helfen sie euch bei der Arbeit?

Sebastian: Learnings gab und gibt es jede Menge. Das finde ich auch das Wichtigste bei der Produktentwicklung. Bei jeder Produktumsetzung haben wir natürlich viel über die eingesetzten Technologien, aber auch über unsere Prozesse, soziale Aspekte, Erwartungen und Ansprüche gelernt. Bei der Arbeit helfen mir diese Learnings eine gesunde Balance zwischen Leidenschaft und Enthusiasmus und Realitätssinn zu bewahren. Es macht zum Beispiel keinen Sinn zu Erwarten, dass eine Produktidee über Nacht das zweite Facebook wird, über das die ganze Welt spricht. Das muss auch gar nicht sein, um motiviert und stolz auf seine Arbeit und gleichzeitig unternehmerisch erfolgreich zu sein.Marek: Uff…das waren einige. Am überraschendsten fand ich aber, dass der Großteil der Entwickler noch nicht so weit ist, seine heißgeliebten IDEs zu verlassen und im Browser zu coden. Gerade da ja auch Tools wie Codepen.io sehr beliebt sind. Aber wer weiß wie das in ein paar Jahren aussieht. Da gab es zum Beispiel super interessante Vorstöße von GitLab. Das hat mich ziemlich gewundert. Aber so Momente sind immer ganz heilsam.

Wie kommt ihr bei ion2s von der ersten Idee zum fertigen Produkt?

Sebastian: Meistens kommt Marek mit einer neuen manchmal vagen Idee um die Ecke. Er hat einen guten Überblick über die Branche und erkennt gewisse Trends. Meisten quatschen wir morgens beim Kaffee darüber und formen die Idee etwas zurecht. Das arbeitet dann in mir und ich überlege wie man die Idee technisch umsetzen kann. Das kann auch mal ein paar Wochen dauern. Wir stürzen uns nicht blind auf jede Idee. Die meisten werden verworfen und auf die wenigsten kommen wir zurück. Wenn es eine Idee geschafft hat immer wieder zum Thema von uns beiden zu werden, dann konkretisieren wir sie und stellen sie dem Management von ion2s vor. In der Regel erhalten wir dann ein Budget um eine Marktanalyse durchzuführen. Es stellt sich die Frage, ob die Idee bereits eine Umsetzung auf dem Markt hat und wie stark die Konkurrenz ist. Je nach Idee kann es ab hier unterschiedliche teils parallele Wege nehmen: Prototyp erstellen, Pitchdeck anlegen, weitere Schärfung der Idee, Vision und Mission formulieren, Konzept erstellen etc.Marek: Ja der Sebastian hat das eigentlich genau richtig beschrieben. Die Ideen an sich können von überall kommen, teilweise aus Gesprächen mit Kollegen, die uns ihr Leid klagen, dann wieder weil man selbst frustriert ist von Workflow-Problemen oder hakeligen Tools auf die man angewiesen ist.Im Kern steht halt immer ein Problem. Auch wenn es nicht sofort offensichtlich ist. Aber es geht immer darum ein Problem zu lösen — etwas besser zu machen als es vorher gemacht wurde.Wenn wir glauben ein solches Problem entdeckt zu haben und eine Lösung dafür anbieten zu können, versuchen wir unsere Idee zu falsifizieren oder zu verifizieren. Dafür treten wir immer wieder direkt in den Kontakt mit der angepeilten Zielgruppe. In diesem Fall sind das etwaige Front-End-Kollegen, denen wir unsere Idee vorstellen und nach Feedback fragen. Wenn sich das Bild ein wenig weiter konkretisiert hat, geht es erstmal zum Chef mit der Bitte uns das Budget zum Evaluieren der technischen Machbarkeit des Ganzen freizugeben. Da sollten wir schon am besten das Potential ausgelotet haben und stichhaltig Argumentieren können.Das ist eigentlich fast eine ganz normale Pitch-Situation, wie man sie auch bei anderen externen Investoren erleben würde.

Welchen Vorteil seht ihr in der In-House Produktentwicklung neben der üblichen Agenturarbeit?

Sebastian: Das freie, technologisch ungebundene Arbeiten. Wir können dann neue Technologien ausprobieren und mal ganz neue Wege gehen, sofern sie für das Produkt Sinn machen.Marek: Ganz klar ist man bei so Themen ein klein wenig freier als bei Kundenprojekten. Gerade auch technologisch. Es gibt da ein Zitat von Tricia Wang, die mal gesagt hat: „There are companies that ARE digital and companies that are doing digital“. Sie bezog das auf einen etwas anderen Kontext, aber das ist bei mir nachhaltig im Kopf geblieben.Also es gibt Unternehmen, die halt Webseiten machen, klar, aber es gibt auch Unternehmen, die am Web arbeiten. Und ich finde es wirklich super, mit der Produktentwicklung zu der zweiten Kategorie zu gehören.

Neue Wege zu gehen, ist nicht immer leicht. Welche Schwierigkeiten erlebt ihr bei der Produktentwicklung?

Sebastian: Ich denke, dass die Produktentwicklung grundsätzlich eine schwierige Aufgabe ist. Überhaupt eine potenziell gute Idee zu haben ist schon mal eine. Und man muss Fehlschläge wegstecken könne und daraus lernen und wachsen. Das ist aber nicht immer leicht. In der Produktentwicklung brauchst du auf jeden Fall ein dickes Fell.Marek: Unzählige. Wer glaubt, dass man sich halt in sein Kämmerchen sperrt, ein paar Zeilen Code zum Besten gibt und danach die Scheine zählt ist auf dem Holzweg. Produktentwicklung bedeutet unglaublich viel Arbeit und ein ständiges über-den-Tellerrand-Schauen. Feedback ist immer wichtig, kann aber manchmal schlichtweg vernichtend sein. Es gibt so viele Variablen, die über Erfolg und Nicht-Erfolg entscheiden, die teilweise nicht mal beeinflussbar sind. Wie geht man live? Wann geht man live? Ist die Zielgruppe wirklich die richtige? Hat man zum richtigen Zeitpunkt, das richtige Produkt? Und so weiter. Da gab es schon die ein oder andere bittere Pille zu schlucken. Dann noch die Erwartungshaltung von außen, von Leuten die denken, dass ja eigentlich alles ganz einfach ist usw. Aber es macht trotzdem unglaublichen Spaß. Das eigenverantwortliche Arbeiten lässt einen schnell die Schattenseiten vergessen.

Das Wichtigste: Wo kann man Oloid herunterladen und wie kann man euch Feedback dazu geben?

Sebastian: Das Laravel Package (oloid-laravel-patternlib) wird über composer einem Laravel Projekt hinzugefügt. Das ist der bevorzugte und einfachste Weg des Herunterladens und Installierens. Feedback kann man uns am besten über GitHub-Issues geben. Das ist dann auch am transparentesten für die Open-Source-Community.Vielen Dank für eure Zeit und viel Erfolg bei der Weiterentwicklung von Oloid!