SELECTED PROJECTS
Event registration tool
Role: Developer
Screenshot of the Event registration tool

Project details

Project name:
New event registration database
Project owner:
Nordic Council
Project start:
May 2020
Launch date:
N/A - Shelved
Technologies:
Django, Python, MySQL, Jupyter notebooks, REST API, JWT, HTML/SCSS/JS, React, Redux, Docker
My role in project:
Technical adviser, developer and maintainer

Background

Each year the Nordic Council has political meetings, the Nordic Session being the largest event. The Nordic Session is an annual event usually taken place in the beginning of November. It's an event where all the members of the Nordic Council comes together and make nordic politics happen.

The registration system is a important part of managing all the participants in these events and meetings. The first registration tool was built in 2013 as a prototype (which is still used today). Still it demands that all participants are registered via forms by a coordinator.

Discussions were made with the Council secretariat and if time allowed I would build a new registration tool for the Nordic Council. A system that would be flexible enough to handle any type of event and integrate with the OAS organisation system. By doing this registration of participants would become very effecient.

Choice of technology

With a good track record, the backend was made in Python/Django. Since the backend should only be used as a webservice, authentication was setup using Javascript Web Tokens (JWT). Since the registration tool should be able to work on both desktop and mobile I decided to make the frontend in React/Redux along with the CSS framework MaterializeCSS.

Project and development cycle

The development of the project started in June 2020. At the time it looked there was a lot of available time to spend on the product.

During the summer and autumn a great deal of progress were made. A JWT authentication cross-over solution was deployed, so authenticated users also were authenticated to pull data from OAS. The adminstration part to setup new registrations were made in the React frontend and the possibility to create custom registration forms via modules were finalized. The integration with OAS was made, so lists of politicans could easily be presented for the registrant. And with a click on a button, a person would be registrated for the event.

In the beginning of 2021, my work focus was forced elsewhere, this meant the time for the new registration system suffered. When nearing the summer 2021 I flagged that the project should be parked. Which is a shame since a lot of good work had been put into the project. However it's all about prioritization of the most business critical parts.

The solution more in depth

In order to build a flexible solution the registration model was built up in three different blocks:

  • An event registration
  • Registration tracks
  • Registration modules

Event registration

Is the main event, where the name, location, date/time is specified. An event can also have a different sub-events that visitors can chose to participate in. Every main event has a number of tracks that is aimed for a specific visitor type.

Registration track

A registration track is a group of modules that is tailor made for a specific visitor. A visitor could be a full member of the Nordic Council, guest or another visitor type. These visitor types need to provide different and unique details in order to complete the registration. A registration track can be used across different registrations at the same time.

Registration module

A registration module is the smallest building block in the registration, but very flexible. It consists of JSON data that describes it functionality. The functionality could be to create a part of a form, it can also be responsible fetch data from an API. All of the registration modules can be reused and used across different registrations at the same time.

My role in the project

In this project I have been working mostly independent with designing the data models, integrations and development of the full solution. The project would have demanded a full time focus in order to succeed or two developers. The decision to shelve the project was the correct one at the time.