stefan-abramowski.jpg

Stefan Abramowski

We would like to look at the topic of OpenSpace App from two sides: How the idea and the requirements came about and how they were then implemented in an app. 

The idea of ​​using an app to digitize and thus simplify the content organization of the OpenSpace itself came up in an OpenSpace session. That became that 
<a href="https://www.meteor.com" target="_blank" rel="nofollow">Meteor Framework</a> 

presented a JavaScript technology stack that enables the creation of web, mobile and desktop apps via a common code base. Meteor apps are inherently responsive and UI-optimistic. In addition, the Meteor platform supports rapid prototyping, among other things through the numerous packages. The consideration of whether there was a meaningful project for this framework led to the OpenSpace app being launched. 

## What is the app supposed to be able to do anyway? 
Before we could start programming, the question of the user stories came up, as it should be. Who should be able to do what with the app and for what reason? The most important functions were found quickly. 

The users of the application are initially all communicoder. The app should allow users to create and view topic suggestions with a short description at any time. The submitted topic suggestions should be visible to all users via an overview page. Each user can mark three topics as "interesting" and one topic as "important" per OpenSpace session. 
First of all, the app should reflect the analogue process as well and simply as possible. 
As soon as all topics have been submitted and voted on, the organizers should be able to easily distribute the topics with the most votes to time slots. The rooms in which the sessions on the topics will take place are also shown. 

Past OpenSpaces and topics that did not receive enough votes should be archived or remain in the "Open Topics" pool. 

## What is improving? 
The app had its maiden voyage in OpenSpace at the beginning of February 18 and we could immediately see improvements. No scurrying around to the flipchart to vote (there was a complex system of crosses and dashes with a felt-tip pen for possible and definite participation), no writing on Post-It's and, above all, throughout the OpenSpace everyone was aware of which session was when and in which one space begins. Of course, improvements are still being made to the app, but even the first version made organizing the OpenSpace a lot easier. 

Next comes the question: 

## How was all of this implemented in Meteor? 
First of all, the project had to be set up fundamentally and an appropriate project structure should be thought about in advance. Meteor is a full stack JavaScript framework and differs significantly from other frameworks, e.g. in that one and the same code can run on both the server and the client. The Meteor Build System offers a default file load order, which provides basic structure, but the details need to be worked out and defined as a team. The technical implementation then takes place using the import and export functions provided by ES2015. 

Practice has shown that the structure proposed by MDG (Meteor Development Group) offers a good and sensible basis, so we based our project on this structure: 

After the project setup is complete, development can begin. First we removed the two "fast-prototyping" packages auto-publish & insecure. Auto-publish ensures that all data from the server database is also loaded into the client database. So this package undermines a fundamental concept (publications & subscriptions) of Meteor and can therefore really only be used for fast prototyping. Insecure, in turn, ensures that data can be written directly from the client to the server database. Of course, this package is only suitable for quick prototyping (“if you just want to show something”). In this project, we deliberately wanted to skip the prototyping step and start directly with methods and publications & subscriptions. 

You rarely have to reinvent the wheel these days, so the project setup also includes the consideration: Which functionalities can be covered by existing solutions? The following packages have found their way into the OpenSpaceApp: 

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

Accounts-password is the official package to enable secure password login in Meteor Apps. Since we had planned a password-based login, this package was set. It was also clear from the start that there would be different roles, such as the admin user, who should have the right to manage other users and OpenSpaces. The <a href="https://github.com/Meteor-Community-Packages/meteor-roles" target="_blank" rel="nofollow">meteor-roles package by alanning</a> meets our needs and is fully compatible with Meteor's account system. 

Accounts-ui provides a rudimentary frontend for registering a user, login, logout and the "forgot password" function. Even though it was clear that we would develop our own login page and registration form, this package offers a huge advantage, especially when starting a new project. Namely, just by adding accounts-password and account-ui, new users can be registered and logged in immediately. Thus, there is a fully-fledged user context right at the beginning. 

Flow router is currently the recommended router for Meteor. Since it does exactly what it is supposed to do and we have plenty of experience with it, we chose the <a href="https://github.com/kadirahq/flow-router" target="_blank" rel="nofollow" >FlowRouter by kadirahq</a>. 

Since the team for the OpenSpaceApp consisted mainly of developers who felt more at home in the backend, the question of a frontend framework quickly arose. The requirements for the frontend framework were manageable, it shouldn't be overly complicated, lean and mobile-ready. The election finally came up 

<a href="http://materializecss.com" target="_blank" rel="nofollow">materializecss</a> 

After the project was set up and the initial commit was pushed into our internal Git repository, we started the feature development seamlessly. Initially, the development mainly took place directly during the OpenSpace, after all the whole thing started with a session in the OpenSpace. The development team consisted of 4 developers, 2 of which were completely new to the Meteor universe. It was probably the OpenSpace session introducing Meteor that piqued their interest. So these two colleagues were first taken by the hand and "trained". After a short time, the learning curve at Meteor is known to be very steep, they were able to implement stories independently. The lived GIT flow at communiocode, which we of course also integrated into this project from the beginning, also ensures the desired quality here. 

In an agile project it can happen that new requirements “suddenly” appear. That's what happened with the OpenSpaceApp project. communicode organizes the "communiversity camp" every year, a bar camp that has some similarities to OpenSpace. 

<a href="https://communicode.dev/blog/insights/multilayered-knowledge-exchange-naehrboden-fuer-special-synergies" target="_blank" rel="nofollow">More on this in this blog post</a> 

For more than 2 years communicode has held a monthly open space for all employees. For the internal exchange of knowledge, all interested parties meet on the first Friday of every month to present and discuss topics together. So far, the topics for the individual sessions have always been collected in a very analog way – with sticky notes on a flipchart. Of course, as a digital agency, you can't let that sit on you.)). After the first reviews of the OpenSpaceApp, it became clear that it would meet all the requirements to take over the organization of the communiversity camp. Submitting topics, voting on topics and organizing timeslots; all of these are key features of the OpenSpaceApp. So it was clear: We also want to organize the topics of the next communiversity camp digitally via the app. However, we needed a quick solution. It would have been desirable to be able to create an extra topic pool in the existing app, so that any number of “occasions” each with its own topic pool could be created in one app instance. But more on that later in the outlook. Due to the short time until the next communiversity camp, we have decided to start up a second instance of the app with its own database and thus its own topic pool. 
 
This decision meant that the source code had to be able to spit out at least two apps that differed at least rudimentarily. The most important differences are probably the app name, title, logo and fav icon. We were able to solve all these small differences relatively elegantly. the 

<a href="https://github.com/communicode/communiCamp" target="_blank" rel="nofollow">Source code is publicly available on GitHub</a>. 

For more than 2 years communicode has held a monthly open space for all employees. For the internal exchange of knowledge, all interested parties meet on the first Friday of every month to present and discuss topics together. So far, the topics for the individual sessions have always been collected in a very analog way – with sticky notes on a flipchart. Of course, as a digital agency, you can't let that sit on you. 

The app was previously only available for use in the OpenSpace via the company network. The app should be publicly accessible via TLS for the communiversity camp at the latest. At least now, however, it had to be ensured that not just any Internet user could log in. We have therefore expanded the role concept so that registration is always possible, but logging in is only possible once the user has been activated by an admin. Now all requirements were met and nothing stood in the way of the communiversity camp. 

## Outlook: 
### Multiple topic pools in one app instance 
As we have noticed, there is definitely a need for different topic pools. The solution to simply provide one instance of the app per event is functional, but still leaves something to be desired. For example, users have to register with each instance, which not only can be confusing, but is downright annoying! It would be desirable to be able to organize different events in one instance. Each occasion should have its own topic pool - a topic is therefore always assigned to an occasion. Roles could also be used to regulate which users take part in which events or who can see which topics. 

### OpenSpace as a Service: Companies register as an organization and create teams 
If we are already in the process of facilitating various occasions, why not go one level higher in abstraction? In short: Users are assigned to one or more teams, a team can create events and, as mentioned above, topics are always assigned to an event. A fairly simple hierarchy that offers maximum flexibility and overview. 

### Uploading the app to the app stores 
A milestone of this project that should not be underestimated is the upload to the Google Play Store and the Apple App Store. Meteor offers the possibility to build Cordova apps, which can be easily uploaded to the app stores. Quite a few smartphone users find typing a URL in the address line of the browser too tedious. Opening an app, on the other hand, shouldn't be too much to ask of anyone? 

We have put together videos from our knowledge forum communiversity on our YouTube channel.

Videos on the communiversity

Our app development with Meteor makes planning our OpenSpace and Communiversity themes easier. 

Blog

live and dev

communicode Author

Stefan Abramowski

Articles to the keywords

Article

communiCamp - The Barcamp and OpenSpace web app