communiCamp – Die Barcamp und OpenSpace Web-App

Das Thema OpenSpace App möchten wir gerne zweiseitig betrachten: Wie die Idee und die Anforderungen zustande gekommen sind und wie sie dann in einer App umgesetzt wurden.

Die Idee dazu, mit einer App die inhaltliche Organisation des OpenSpaces zu digitalisieren und damit zu vereinfachen, entstand selbst in einer OpenSpace-Session. Darin wurde das Meteor-Framework

vorgestellt, ein JavaScript Technologie Stack welcher das Erstellen von Web, Mobile und Desktop Apps über eine gemeinsame Code-Basis ermöglicht. Meteor Apps sind von Haus aus reaktiv und UI-Optimistisch. Zudem unterstützt die Meteor Plattform, unter anderem durch die zahlreichen Packages, rapides Prototyping. Die Überlegung ob es für dieses Framework nicht auch direkt ein sinnvolles Projekt gäbe, führte dazu, dass die OpenSpace-App ins Leben gerufen wurde.

Was soll die App denn überhaupt können?

Bevor es mit dem Programmieren losgehen konnte, kam, wie es sich gehört, die Frage nach den User-Stories auf. Wer soll aus welchem Grund was mit der App tun können? Die wichtigsten Funktionen waren schnell gefunden.

Die Benutzer der Anwendung sind zunächst alle communicoder. Die App sollte den Benutzern ermöglichen, jeder Zeit Themenvorschläge mit einer kurzen Beschreibung erstellen und einsehen zu können. Über eine Übersichtsseite sollten die eingereichten Themenvorschläge für alle Benutzer sichtbar sein. Jeder Benutzer hat pro OpenSpace Session die Möglichkeit drei Themen als „interessant“ und ein Thema als „wichtig“ zu markieren.

Zunächst einmal soll die App den analogen Prozess möglichst gut und einfach widerspiegeln.

Sobald alle Themen eingereicht und mit Votum versehen sind, soll den Organisatoren ermöglicht werden, die Themen mit den meisten Stimmen einfach auf Time-Slots zu verteilen. Die Räume in denen die Sessions zu den Themen stattfinden werden, sind ebenfalls abgebildet.

Vergangene OpenSpaces und Themen die nicht ausreichend viele Stimmen erhalten haben, sollen archiviert, bzw. im „Offene Themen“-Pool verbleiben.

Was verbessert sich?

Im OpenSpace Anfang Februar 18 hatte die App ihre Jungfernfahrt und wir konnten direkt Verbesserungen feststellen. Kein Rumgewusel zum Flipchart zum Votieren (Es gab ein komplexes System aus Kreuzen und Strichen mit Filzstift für mögliche und definitive Teilnahme), kein Geschreibe auf Post-It’s und vor allem waren während des gesamten OpenSpaces alle darüber im Bilde, welche Session wann und in welchem Raum beginnt. Natürlich finden auch weiterhin Verbesserungen an der App statt, aber bereits die erste Version hat die Organisation des OpenSpaces sehr erleichtert.

Stellt sich als nächstes die Frage:

Wie wurde all das in Meteor umgesetzt?

Zunächst galt es das Projekt grundlegend aufzusetzen und dazu sollte man sich im vorhinein Gedanken zu einer angemessenen Projekt-Struktur machen. Meteor ist ein full stack JavaScript Framework und unterscheidet sich von anderen Frameworks maßgeblich z.B. dadurch, dass ein und der selbe Code sowohl auf dem Server, als auch auf dem Client laufen kann. Das Meteor Build System bietet eine „default file load order“, wodurch eine grundlegende Strukturierung gegeben ist, die Details müssen allerdings im Team ausgearbeitet und festgelegt werden. Die technische Umsetzung erfolgt dann mittels der durch ES2015 gegebenen Import und Export Funktionen.

In der Praxis hat sich gezeigt, dass die von MDG (Meteor Development Group) vorgeschlagene Strukturierung eine gute und sinnvolle Basis bietet, somit haben auch wir unser Projekt an diese Struktur angelehnt:

Nachdem das Projekt Setup steht kann es an die Entwicklung gehen. Zunächst haben wir die beiden „fast-prototyping“ Packages auto-publish & insecure entfernt. Auto-publish sorgt dafür, dass sämtliche Daten der Serverdatenbank auch in die Clientdatenbank geladen werden. Dieses Package hebelt also ein grundlegendes Konzept (publications & subscriptions) von Meteor aus und kann demnach wirklich nur für das schnelle Prototyping verwendet werden. Insecure wiederum sorgt dafür, dass Daten direkt vom Client aus in die Serverdatenbank geschrieben werden können. Dieses Package ist natürlich auch lediglich für schnelles Prototyping geeignet („wenn man mal eben was zeigen will“). In diesem Projekt wollten wir bewusst den Schritt des Prototypings überspringen und direkt mit Methods und publications & subscriptions durchstarten.

Das Rad neu erfinden muss man heutzutage nur noch selten und somit gehört zum Projekt Setup auch die Überlegung: Welche Funktionalitäten können durch bestehende Lösungen abgedeckt werden? Folgende Packages haben den Weg in die OpenSpaceApp gefunden:

• accounts-password
• accounts-ui
• alanning:roles
• Flow-Router
• Materialize
• cunneen:accounts-admin-materializecss

Accounts-password ist das offizielle Package um das sichere Einloggen mit Passwort in Meteor Apps zu ermöglichen. Da wir ein Passwort basierten Login geplant hatten, war dieses Package quasi gesetzt. Auch war von Anfang an klar, dass es verschiedene Rollen geben wird, wie zum Beispiel den Admin Benutzer, welcher die Berechtigung haben soll andere Benutzer und OpenSpaces zu verwalten. Das Package meteor-roles von alanning

erfüllt unsere Anforderungen und ist gänzlich kompatibel mit Meteor´s account-system.

Accounts-ui liefert ein rudimentäres Frontend für das Registrieren eines Benutzers, den Login, den Logout und die„Passwort-vergessen-Funktion“. Auch wenn klar war, dass wir eine eigene Login Seite und ein eigenes Formular zum Registrieren entwickeln werden, bietet dieses Package einen riesen Vorteil, gerade zum Start eines neuen Projektes. Und zwar wird lediglich durch das Hinzufügen von accounts-password und account-ui unmittelbar das Registrieren neuer Benutzer und deren Einloggen ermöglicht. Somit gibt es gleich zu Beginn einen vollwertigen User-Context.

Flow-Router ist der momentan empfohlene Router für Meteor. Da er genau das tut was er soll und wir hinlänglich Erfahrung mit ihm haben, viel die Wahl auf den FlowRouter von kadirahq.

Da das Team für die OpenSpaceApp hauptsächlich aus Entwicklern bestand, die sich eher im Backend zuhause fühlen, kam schnell die Frage nach einem Frontend-Framework auf. Die Anforderungen an das Frontend-Framework waren überschaubar, es sollte nicht all zu kompliziert, schlank und mobile ready sein. Die Wahl viel letztendlich auf materializecss

Nach dem das Projekt Setup stand und der initiale Commit in unser internes Git-Repository gepushed war, haben wir nahtlos mit der Feature Entwicklung begonnen. Die Entwicklung fand zunächst hauptsächlich direkt während des OpenSpaces statt, schließlich hat das Ganze mit einer Session im OpenSpace begonnen. Das Entwicklungsteam umfasste 4 Entwickler, wovon 2 komplett neu im Meteor Universum waren. Es war wohl die OpenSpace Session, in der Meteor vorgestellt wurde, die ihr Interesse geweckt hatte. Diese beiden Kollegen wurden also zunächst an die Hand genommen und „angelernt“. Nach kurzer Zeit, die Lernkurve bei Meteor ist ja bekanntlich sehr steil, konnten sie selbstständig Stories implementieren. Der gelebte GIT-Flow bei communiocode, den wir natürlich auch in diesem Projekt von Anfang an integriert haben, sorgt auch hier für die gewünschte Qualität.

In einem agilen Projekt kann es durch aus vorkommen, dass „plötzlich“ neue Anforderungen auftauchen. So ist es auch bei dem OpenSpaceApp Projekt passiert. communicode veranstaltet jährlich das „communiversity camp“, ein Barcamp das einige Ähnlichkeiten zum OpenSpace aufweist. Mehr dazu in diesem Blog Beitrag

Seit mehr als 2 Jahren findet bei communicode monatlich ein OpenSpace für alle Mitarbeiter statt. Zum internen Wissensaustausch treffen sich am ersten Freitag jeden Monats alle Interessierten um gemeinsam Themen vorzustellen und zu diskutieren. Das Sammeln der Themen für die einzelnen Sessions hat bisher immer sehr analog stattgefunden – mit Klebezetteln auf einem Flipchart. Als Digitalagentur kann man das natürlich nicht auf sich sitzen lassen.)). Nach den ersten Reviews der OpenSpaceApp viel auf, dass sie alle Anforderungen erfüllen würde um die Themen Organisation des communiversity camps zu übernehmen. Themen einreichen, über Themen abstimmen und die Organisation der Timeslots; all das sind Key-Features der OpenSpaceApp. Somit war klar: Wir wollen die Themen des nächsten communiversity camp auch digital über die App organisieren. Allerdings brauchten wir eine schnelle Lösung. Wünschenswert wäre es gewesen, einen extra Themen Pool in der bestehenden App anlegen zu können, so dass also in einer App-Instanz beliebig viele „Anlässe“ mit jeweils eigenem Themen-Pool erstellt werden können. Dazu aber später im Ausblick mehr. Auf Grund der knappen Zeit bis zum nächstem communiversity camp, haben wir uns entschieden vorerst lediglich eine zweite Instanz der App mit eigener Datenbank und somit eigenen Themen-Pool hochzufahren.

Diese Entscheidung führte dazu, dass der Source-Code in der Lage sein musste mindestens zwei, sich zumindest rudimentär unterscheidende, Apps auszuspucken. Die wichtigsten Unterschiede sind wohl der App-Name, Titel, Logo und Fav-Icon. All diese kleinen Unterschiede konnten wir relativ elegant lösen. Der Source-Code ist öffentlich bei GitHub verfügbar.

Seit mehr als 2 Jahren findet bei communicode monatlich ein OpenSpace für alle Mitarbeiter statt. Zum internen Wissensaustausch treffen sich am ersten Freitag jeden Monats alle Interessierten um gemeinsam Themen vorzustellen und zu diskutieren. Das Sammeln der Themen für die einzelnen Sessions hat bisher immer sehr analog stattgefunden – mit Klebezetteln auf einem Flipchart. Als Digitalagentur kann man das natürlich nicht auf sich sitzen lassen.

Zur Verwendung für den OpenSpace war die App bisher nur über das Firmennetzwerk verfügbar. Spätestens für das communiversity camp sollte die App aber öffentlich über TLS erreichbar sein. Spätestens jetzt musste aber auch sichergestellt werden, dass sich nicht jeder beliebige Internet Benutzer anmelden kann. Deshalb haben wir das Rollen-Konzept erweitert, so dass eine Registrierung zwar immer möglich ist, allerdings das Anmelden (Login) erst möglich wird, sobald der Benutzer durch einen Admin freigeschaltet wurde. Jetzt waren alle Anforderungen erfüllt und dem communiversity camp stand nichts mehr im Wege.

Aussichten:

Mehrere Themen-Pools in einer App-Instanz

Wie wir gemerkt haben, besteht durchaus der Bedarf an verschiedenen Themen-Pools. Die Lösung einfach pro Anlass eine Instanz der App bereitzustellen ist zwar funktional, lässt aber trotzdem Wünsche offen. Zum Beispiel müssen sich die Benutzer bei jeder Instanz registrieren, was nicht nur verwirrend sein kann, sondern auch schlicht und ergreifend nervig ist! Wünschenswert wäre es doch in einer Instanz verschiedene Anlässe organisieren zu können. Jeder Anlass sollte dabei einen eigenen Themen-Pool haben – ein Thema ist also immer einem Anlass zugeordnet. Über Rollen könnte sich auch regeln lassen, welche Benutzer an welchen Anlässen teilnehmen oder wer welche Themen sehen darf.

OpenSpace as a Service: Firmen registrieren sich als Organisation und erstellen Teams

Wenn wir schon dabei sind verschiedene Anlässe zu ermöglichen, wieso dann nicht auch gleich noch eine Abstraktionsebene höher gehen? Kurz gesagt: Benutzer sind einem oder mehreren Teams zugeordnet, ein Team kann Anlässe anlegen und wie oben erwähnt sind Themen immer einem Anlass zugeordnet. Eine ziemlich einfache Hierarchie, die allerdings maximale Flexibilität und Übersicht bietet.

Hochladen der App in die App Stores

Als ein nicht zu unterschätzender Mile-Stone dieses Projektes, wäre der Upload in den Google Play Store und den Apple App Store zu sehen. Meteor bietet die Möglichkeit Cordova Apps zu bauen, welche einfach in die App Stores hochgeladen werden können. Nicht wenigen Smartphone Benutzern ist das Eintippen einer URL in die Adresszeile des Browsers zu mühsam. Das Öffnen einer App sollte hingegen von niemanden zu viel verlangt sein ?