DynamicRow was a project born out of the COVID-19 crisis in Italy, with the mission of providing tools to support the re-opening of the country. DynamicRow is a solution to manages the flow of people in public and private spaces. The project was one of the 43 winners of the EuVsVirus hackathon in which more than 2100 projects have participated.
Dario, one of the co-founders of DynamicRow reached me when he was looking for a Lead Developer to bring forward the project. At the time, the team consisted of around 3 people working on the business and legal aspects and two junior front-end developers. This was a newly formed team had come together during the hackathon. The two junior developers had full-time jobs, and could not contribute much time on the project. The project had a deadline, they had to build a demo in around 2 weeks, and do a presentation for the Demo Day. My role was to build this idea into a demo that it could be presented for the Demo Day.
When I joined the team, my first job was to try understand the product and requirements for the Demo Day. I realized, that Dario had several ideas for what to build, but it was not entirely clear for the team what this product was exactly. I suggested Dario to write a series of User Stories. The User Stories document was simply a word document shared on Google Drive. The team went through the list of User Stories few times, and iterated over it. This process made the development team more clear on what was necessary to build, and also for Dario to get feedback on what made sense to build and what was not necessary. We conducted our meetings via Skype, as our team was split in different locations in Europe, and me in China.
The User Stories made the team understand the requirements and scope of the product, however we could not all see what the end product would look like. My next step for the development process was to draw a wireframe of the app using Figma. We picked Figma because it was easy to draw wireframes and easy to collaborate. I basically went through the list of User Stories, and converted those stories into mobile app screens. I did not focus on the UI design, but focused on making the navigation and content of the screen logically correct and user friendly. We iterated over the Figma wireframe several times, until we had a complete picture of all the user journeys through the app. We were also fortunate to have later a freelance designer help us with the project, she worked on the UI by converting those wireframe screens into beautiful screens.
The next step before starting to code was to split our work among the 3 developers. We used Trello to create tasks, by implementing a Kanban Board. The Kanban Board had the following boards: Backlog, Todo, Doing, Testing, Done.
- Backlog: Tasks that needed to be done, but not now
- Todo: Tasks that are ready to be worked on. This list is ordered by priority
- Doing: Tasks that are currently actively being worked on
- Testing: Tasks where development was done, but needs to be verified
- Done: Tasks that have been verified and are ready to ship
Having those boards, we made sure that: The most important tasks were being worked on first, and that we knew what other people were working on, so two people would not work on the same task.
We tried to have daily meetings on Skype to update each other on our progress. Development was done with Github and pull requests.
When I joined the team, the team had an Ionic/Angular project that was built during the hackathon. The project was mostly mock pages without real data. We had a discussion with the team for which technology we should use to proceed. I was mostly experienced with React, React Native, so we discussed whether we should keep using Ionic/Angular or switch to React Native. In the end we decided to go with Ionic/Angular, because:
- We already had some code in Ionic/Angular
- The other front-end developers were more familiar with Ionic/Angular rather than React.
- The project was envisioned to work on the browser as as Web App as well
We decided this thinking that I could work more on the backend, while the front-end developers would use the stack they were more familiar with.
For the backend, we decided to use Firebase, as it is one of the most mature solution for building applications in Europe. Because we had a very small team, we wanted a solution that was stable and managed, so that we did not need to put resources for managing servers ourselves.
I have been satisfied with working with Ionic/Angular and Firebase. Ionic/Angular was fine for a small project, the Dependency Injection in Angular is a core concept which takes time to get used to it. I am however still much more comfortable with React, and would definitively choose React for a new project.
I found Firebase very convenient in some aspects but also very limiting in other aspects. I have used the Firestore database which is a document database. I have not used any of the real-time functionality as it was not required for our project. The Firestore emulator enabled me to run unit tests locally, and I used it a lot during development. Firestore has limitations like:
- Cannot combine certain query filters
- Cannot do a count query
- Cannot edit the email confirmation content (Anti-span / content moderation policy)
Those limitations had to be overcome by using Firestore Events (onCreate, onDelete, etc...) through Firebase Functions, and storing this data during every-change instead of querying it every-time.
We used Firebase Functions for all our APIs, and had a few Scheduled Functions (cron jobs). The service was what I would expect from a Serverless Functions solution, and it has been straightforward for us to integrate it with Firebase Auth that we were using in the client side.
We used Typescript extensively throughout both the frontend and backend.
There were mainly 2 phases of development. The first phase had a duration of 2 weeks in order to create a limited version of the app for Demo Day. The second phase was around 3 weeks, and it consisted in creating a MVP to be tested by real users and to do demo for organizations.
The main features for the first phase were: Onboarding/Registration, Map feature, QR Code and Check In/Check Out logic. We primary focused on building an Android version. We have encountered some problems with the QR Code Scanner in Ionic, but we were able to solve it.
During the second phase, we added advanced features such as the scheduling of rooms, and the option to checkin multiple people. We deploy application for iOS, built a new admin dashboard, solved existing bugs and improved the overall quality of the app. For the admin dashboard, used an existing framework ngx-admin so that we could focus on the application rather than building the framework.
We had problems with Apple, that was very slow in their review process. In order to not get stuck with the Apple review process, we published a Web App version using Vercel, so that beta testers with iPhones could also use the application.
I am proud of what we have achieved in those 5 weeks:
- A cross-platform mobile application to manage flow of people of public and private spaces that works on iOS, Android, Store, Web
- A web admin dashboard, for organization to manage their resources
Dario has been talking to many people on the business side
- Started testing the application in his own University
- Started testing the application with a few small groups
- Conducted meetings with several organization about the adoption of the product
The application is far from complete, and the current adoption is very limited. The onboarding user experience for first-time users should be improved. The error messages, and a few user flows could also be improved.
Once the projects manages to get more adoption and interest from organization that are willing to pay, we will have another round of development to better satisfy those users.
The part of this project that I am most proud of is the Scheduling and Check In logic I have built in the backend. The proper logic for this feature gets sophisticated:
- There are two modes of Check In: Realtime and Schedule
- You have option to Pre Check In before doing the Realtime Check In
- The system needs to keep track which and how many people are in which room
- A user can Check In for multiple people
- A user can schedule one or more slots, and for every slot the system needs to keep track of the capacity of the slot and whether the room is accessible at the particular time
I have written around 140 unit tests in order to be sure that the logic would be correct and that there would not be bugs in the future with new features or feature changes.
I am really happy to have met Dario and have become friends with him. Working around the clock during the COVID-19 days when everyday counted created a sense of mission in our collaboration. This has been an early phase Dynamic Row, and I hope it will continue to serve users for the post-COVID phase as well.
You can follow me on Twitter @han4wluc to get updated about my stories. Feel free to contact me if you have a software project.
Find more about DynamicRow.