Projektbericht »Synico« Raumbuchungssystem

Was macht »Synico«? 

Die Anzeige-Displays werden direkt vor den Besprechungsräumen installiert und liefern Informationen über aktuelle und zukünftige Reservierungen für den jeweiligen Raum. Durch unsere Anwendung erkennen Mitarbeitende auf einen Blick, ob ein Raum verfügbar oder belegt ist und haben zudem die Möglichkeit, verfügbare Räume vor Ort zu buchen.

Wie fühlt es sich an, an einem Produkt zu arbeiten, das später wirklich im Büro genutzt wird?

Dass unser Projekt später tatsächlich seinen Platz im Fusonic Büro haben wird, ist ein surreales, aber dennoch erfüllendes Gefühl. Ein wenig Druck ist natürlich ebenfalls damit verbunden, dadurch holen wir jedoch das Beste aus unserer Anwendung heraus und sind schon sehr gespannt darauf, unser Produkt in Aktion zu sehen.

Wie seid ihr an das Thema herangegangen? Wer hat was im Team übernommen?

Direkt zu Beginn organisierte Sophia als Projektleiterin die Grundzüge des Projekts, verteilte die Aufgaben und hielt das Projekt über die gesamte Laufzeit mit hybridem Projektmanagement organisiert und übersichtlich. 

Zoe, unsere Designerin, verschaffte mit ihrem Mood-Board die ersten Eindrücke in den Charakter unseres Projekts und begann anschließend mit dem Branding und den Wireframes.

Die Entwicklerinnen, Patricia und Elisa, unser Dreh- und Angelpunkt in der Umsetzung, befassten sich vor dem Programmierstart intensiv mit der Recherche und Beschaffung der richtigen Hardware-Komponenten und entschieden sich hierbei für das E-Paper E-Ink-Display, sowie einen Raspberry Pi Pico Controller und planten ebenfalls Magnet-Streifen für das zukünftige Gehäuse unseres finalen Geräts ein.
 

Was waren die wichtigsten Anforderungen an das System? 

Die wichtigsten Anforderungen umfassen die Anzeige über die Verfügbarkeit der Räume, eine Verwaltungsoberfläche für das Organisieren von Räumen und Geräten und, eine Besonderheit unserer Hardware-Komponente, eine Akku-Laufzeit von etwa einem Jahr.

Wie habt ihr entschieden, welche Funktionen unbedingt in die erste Version (MVP) mussten?

Gleich nach dem Projekt-Kickoff wurde das Pflichtenheft, sowie User-Stories definiert. Gemeinsam warfen wir einen Blick auf die wichtigsten Anforderungen (»Säulen«) des Projekts und hielten die drei wichtigsten Punkte als MVP-User-Stories schlussendlich in unserem Product-Backlog fest.

Wie sieht das Design aus und worauf musstet ihr besonders achten?

Im Design wurde unser Branding in den letzten Monaten von Zoe ausgeklügelt und verfeinert. Hierbei muss zwischen zwei Komponenten unterschieden werden – der Verwaltungsansicht am Desktop und der Anzeige am Display.

Das Design der Desktop-Ansicht erfüllt seinen Zweck als organisiertes Verwaltungstool, denn es ist schlicht und ordentlich gehalten, die Primärfarbe ist hierbei ein eher mattes Blau, welches sich in wichtigen Elementen wie zum Beispiel der Nav-Bar widerspiegelt. Durch unsere Akzentfarbe, ein schlichtes Gelb, werden unter anderem die Hover-Effekte gekennzeichnet. Zoe hat bewusst auf grelle und strahlende Farben verzichtet, denn ihr Ziel war es, eine professionelle Ansicht zu gestalten, welche sich durch ein schlichtes, aber dennoch effektives Design kennzeichnet.

Im Gegensatz zur Verwaltungsansicht gibt es beim E-Paper-Display nur zwei Farben – Schwarz und Weiß. Hierbei war es die größte Herausforderung, das Layout so zu gestalten, dass alle notwendigen Informationen gut unterteilt und vor allem lesbar dargestellt werden. Wegen der eher schlechteren Auflösung des Displays musste Zoe speziell auf das Logo achtgeben, da dieses simple, aber dennoch wiedererkennbar sein sollte und ebenfalls mit dem Design der Verwaltungsansicht harmonieren musste.

Welche Tools habt ihr fürs Design/Prototyping genutzt?

In ihrer Rolle arbeitete unsere Designerin hauptsächlich mit dem Programm Figma. Ob Wire-Frames, Low- und  High-Fidelity-Prototypen oder Usability-Testings, die Software der Wahl war klar, da wir bereits Erfahrungen in der Schule damit machen durften.

Wie läuft der Austausch zwischen Design und Entwicklung ab?

Der Austausch zwischen Design und Entwicklung resultiert zwar manchmal in einem entsetzen »WAS?!« von Patricia und einem verwirrten Blick von Seiten Elisas, doch nach einem kurzen Gruppen-Gespräch, in dem die Machbarkeit des neuen Features oder der Änderung am High-Fidelity-Prototyp besprochen wird, legt sich die Verwirrung und es ist meist schon ein Lösungsweg in Sicht. 

Welche Technologien nutzt ihr für die Software und warum habt ihr euch dafür entschieden?

Nach genauer Recherche und Absprache mit unseren Betreuern des Fusonic-Teams entschieden wir dazu, unser Projekt als Blazor-Web-App in Kombination mit der Mud-Blazor-Library umzusetzen. Im letzten Schuljahr kamen wir bereits mit Blazor in Berührung, daher verlief der Einstieg unkompliziert und es bot uns die Chance, das Wissen zu dieser Technologie zu vertiefen und die Theorie aus dem Schulunterricht praxisnah umzusetzen.

Für unsere Datenbank hinter der Verwaltungsansicht fiel die Wahl auf das Datenbankmanagementsystem PostgreSQL, da dieses bereits von vielen Unternehmen eingesetzt wird und daher eine einfachere Anbindung an unser System ermöglicht.

Um den Pico-Controller in die Gänge zu bringen, entwickelte Patricia die entsprechende Software mit der Programmiersprache MicroPython. Ihre bereits vorhandenen Python-Kenntnisse ermöglichten es ihr, sich zeitnah in die neue Materie einzuarbeiten und mit der Programmierung der Hardware-Komponente zu starten.

Für das Framework hinter der Anwendung entschieden wir uns am Kickoff des Projekts für .NET 9. Dieses Framework ist zwar nicht brandneu, ist jedoch aktuell eines der stabilsten Frameworks mit ausführlichen Dokumentationen und genau aus diesem Grund fiel unsere Wahl auf .NET 9.

Was war die größte technische Herausforderung beim Entwickeln?

Das Arbeiten mit dem Pico-Controller war zu Beginn definitiv mit den meisten Schwierigkeiten verbunden. »Was genau kann der Pico? Wie initialisiert man den Controller? Und welches Bild muss der Server bereitstellen?« Vor diesen Schwierigkeiten standen Patricia und Elisa zu Beginn des Praktikums. Apropos Server, die Bildgenerierung stellte sich ebenfalls als kompliziert heraus, da die verschiedenen Daten aus dem Google-Calendar auf das Display-Template mittels der Library Magick.NET gezeichnet werden mussten, was pixel-genaue Rechnungen mit sich zog.

Wie sieht die Zusammenarbeit mit euren Fusonic-Mentoren aus? 

Während der Zeit, welche wir mit dem Arbeiten am Projekt verbrachten, halfen uns Daniel (Head of Design) und Paul (Expert Software Developer) in ihrer Rolle als unsere Mentoren bei diversen Angelegenheiten, wie dem Produktnamen oder der besseren Lösung für das Backend – egal was, sie hatten jederzeit einen guten Ratschlag für uns übrig.

In der Zeit vor dem Praktikum trafen wir uns in regelmäßigen Abständen nach unserem Schulunterricht im Fusonic Office zum Jour Fixe und diskutierten den aktuellen Stand der Dinge.

Wie helfen euch die Jour Fixe oder Code-Reviews weiter?

Das tägliche »Hoi, wie loft‘s?« von Paul kündigte dann fast jeden Morgen die kurze Besprechung und Fragerunde während des Praktikums an und half uns, für Unklarheiten in der Entwicklung, wie zum Beispiel bei der Bereitstellung der Datenbank via Git-Hub, einen Lösungsansatz zu finden.

Insgesamt haben uns die regelmäßigen Jour Fixe-Besprechung und Code-Reviews oft in die richtige Richtung zum Lösungsansatz verholfen, da wir durch den Austausch mit Daniel und Paul oft einen neuen Blickwinkel auf ein Problem, bzw. die Problemlösung, erlangen konnten.

Was ist der größte Unterschied zwischen der Schule und diesem »echten« Projekt?

Der größte Unterschied ist wohl darin, dass unser Wissen aus den verschiedenen Schulstufen in ein Projekt komprimiert und auf die Probe gestellt wird, ganz anders als im regulären Schulunterricht.

Außerdem konzentrieren wir uns im Sinne des Projekts speziell auf diese eine Materie und passen alle Entscheidungen in der Entwicklung an das gewünschte Endprojekt an, wobei nicht immer nach den allgemeinen Standards vorgegangen werden kann.

Was waren eure Lektionen aus diesem Projekt?

Nicht alles lief immer ganz nach Plan, so mussten wir uns auch einer unerwarteten Herausforderung stellen, die den bisherigen Design-Prozesse ein wenig über den Haufen warf. Das Problem – alle Elemente auf dem Display, die in einer Graustufe eingefärbt waren, wurden vom E-Paper E-Ink-Display als ungerade Linien dargestellt. Dies resultierte darin, dass unsere Designerin das gesamte Layout und das Logo neu entwerfen und so anpassen musste, damit es das Display korrekt anzeigen konnte.

Unsere Backend-Entwicklerin Elisa musste während des Praktikums feststellen, dass die verwendete Google API und Google Directory API ihre Grenzen hatten und nicht alle Features sinnvoll umsetzbar waren. So zum Beispiel das Hinzufügen von Räumen direkt von der Verwaltungsoberfläche aus. Dafür hätte das Backend nämlich einen neuen Kalender für den hinzugefügten Raum direkt im Google-Workspace erstellen müssen, was zwar möglich, aber nicht sinnvoll war, da dies eine doppelte Funktionalität wäre, welche schon im Google-Workspace umgesetzt ist.

Wie ist der aktuelle Stand und worauf freut ihr euch am meisten, wenn das System offiziell live geht?

Mittlerweile sind die Grundzüge unserer Anwendung erfolgreich umgesetzt, denn unser Gerät, bestehend aus dem Pico-Controller und E-Paper E-Ink-Display, kann bereits die aktuelle Verfügbarkeit eines Meeting-Raumes zuverlässig anzeigen.

Die Desktop-Version der Verwaltungsoberfläche befindet sich zur Zeit auf der Zielgerade, denn Patricia arbeitet derzeit an den letzten Feinheiten, bevor dieser Teil unserer Anwendung abgeschlossen ist.

Für die Spontanbuchung über den QR-Code auf den Displays fehlt zum jetzigen Zeitpunkt noch die Benutzeroberfläche, die erforderlichen Funktionalitäten des Backends wurden dafür jedoch bereits vollständig implementiert.

Das schlussendlich fertige Produkt benötigt natürlich ein dementsprechendes Gehäuse. Zoe arbeitet deshalb aktuell an der Planung und 3D-Modellierung eines magnetischen Gehäuses, welches für  die Installation vor den Meetingräumen eine wichtige Rolle spielt.

Zum Schluss möchten wir ein großes Dankeschön an alle Personen aussprechen, die unser Projekt überhaupt erst möglich gemacht haben. Vielen Dank an unsere beiden Mentoren. Wir waren wirklich froh über Daniels UI/UX-Expertise und Pauls Software-Entwicklungs-Erfahrung, die Ratschläge und die nette Begleitung durch das Projekt.

Bedanken möchten wir uns aber nicht nur bei unseren zugewiesenen Mentoren, sondern bei allen, die freiwillig bei unseren Testings dabei waren, mit uns Fotos gemacht haben oder uns so offen und freundlich im Office begrüßt haben.