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 Meteor Framework
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?
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:
- Flow router
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 meteor-roles package by alanning 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 FlowRouter by kadirahq.
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 upmaterializecss
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.More on this in this blog post
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. theSource code is publicly available on GitHub
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.
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?