.jpeg)
Being able to create something that other people will use and enjoy has always been my main attraction.
It’s kind of my DNA trying to constantly be thinking about what I could do next and accept different types of projects.
When talking about OutSystems, most of the projects are “Business to Employee” or “Business to Business” and from time to time we have the chance to put our hands in “Business to Consumer” projects.
These types of projects are usually the most challenging because we are creating something which is going to be used potentially by hundreds of different people and hundreds of different devices and situations.
When OutSystems came to us saying they need a Bingo application, I was the first one to raise my finger and say “I would love to develop the project”. I was so eager that the next day I already had a working prototype (even without the final requirements or design).
Over the next few pages, I will share the process that led us to the final result and the steps and technical decisions that helped us deliver the application with security and a good UI and experience for the users.
The Challenge
The customer (OutSystems) needed to develop a Bingo “like” application focused on the OutSystems developers. Like the bingo gaming cards.
They wanted a way to engage with the community of developers (both prospects and customers) to encourage them to interact with all of their content, demos, webinars, and events. Their goal was to introduce a fun and interactive way for developers to learn about OutSystems while being able to earn prizes.
Requirements
The requirements went from technical ones to UI ones. We had a couple of e-mail exchanges and meetings to help define all the needs.
Here follows the main ones.
It should be a PWA application
since we didn't want to be dependent on an applications store and therefore reliant on code approvals and validations and thus take longer to launch the application and its future updates.
An easy way for users to sign up and recover passwords
We wanted a quick way for developers to register. The registration took only a couple of minutes to be completed and the users only needed an e-mail address.
An easy way for developers to mark a bingo box and submit a bingo card
The idea was that after a user was capable of completing a full line in the card, he could submit the card.
Design aligned with OutSystems UI guidelines
Regarding the main colours, buttons design, language, and others. It was something important, to keep consistency inside the OutSystems ecosystem.
A simple back office
Besides OutSystems needs to be able to manage Bingo card submission dates and manage each bingo card cell text, we also delivered some extra actions like import/export data to help manage the database.
Make usage of OutSystems Systems User entities
To save some time on creating a 100% custom database, we wanted to use the “User” system entities which already have a lot of pre-build functionalities that help us save a lot of time because we can make use of the “Multi-tenant” feature.
Development Process
Naturally we wanted to follow a typical workflow to develop the application and for that very reason, we started with the planning and requirements definition phase, followed by the UX and UI design phases (respectively), followed by the development phase (with a couple of status meetings) and ended up with a phase of quality acceptance tests.
Naturally, the most significant steps are UX/UI Design and Development.
Design Process
The design phase (UX + UI) took about 1 week to complete and included tasks like creating the app flow, a simple style guide, and designing the screens.
Moodboard
One of the first things we did was the mood board which helped create the style guide and created the app logos.
We spent some time analysing other Bingo apps to understand the feeling that is past to the user when looking at a Bingo card game application.
Define Identity
After a couple of sessions, a new logo emerged from the deepest caves of the planet. We followed the “red” from OutSystems and the same typography in the “OutSystems” name.
We created the app's main image and a smaller version to be used as the logo for the mobile app.
UX
The UX design was like a guide for the UI Design to follow and for them to know what screens they should design. Wasn’t much more than the result of the requirements defined in the previous phase. It also helped OutSystems to understand our approach to how we planned on managing the user's registration and password reset.
Below you can have a “bird's eye view” of the entire flow of the application and its screens.
UI Design
In the UI design phase, we focused on defining a simple style guide and on building the screens. During the process we had a couple of meetings with OutSystems to align the design and, as a developer, I also helped my UI teammate by giving some input ideas on how to solve and improve the experience of the application.
Here follows some of the screens designed.
Naturally, during the iterations and the acceptance of the design, some ideas were left behind and others changed. Here are some cool examples.
Development Phase
After the design phase, it was time to start with the development of the application.
Architecture Definition
One of the most important things that we should do is to define the correct architecture for the application and the data model.
Regarding the architecture, we decided to go with 2 separated “end-user” applications, one for the Bingo application and another for the backoffice application and both of them would consume a core services module for a third application.
The main argument that helped us decide this decision was that by separating the two end-user applications we are promoting different life cycles for them. Technically in the end, we could achieve the same result with a single application for both modules.
The main goal was to, at least, follow the best practices of the 3 layer canvas architecture promoted by OutSystems.
In order to help us use the Users system entity, we defined the core services module as the “User Provider Module” to the other modules that uses data.
Users Management Flows
Due to the low complexity required for the application, we restricted the users management to only two flows: User Registration and Password Recovery.
We wanted simple processes regarding registering a new user (it took around 5m to register a new account) or setting a new password but at the same time, we didn’t want to set aside security.
User Registration Flow
- User opens the application and clicks on the button to create a new account. After he fills all the required fields an e-mail asking for a confirmation is sent.
For this first step, we implement a couple of security systems:
- Implemented a reCapcha validation to avoid bots creating dummy users and break the server;
- After the form is submitted, the user registry is create in the “inactive” state and only after the user click on a link in the received e-mail, the registration status is updated to “active”;
- When the user is registered in the database, we also generate a unique ID, sent in the link in the e-mail.
- The user reads the received e-mail and clicks on the link to confirm its user registration request.
- The user is redirected to a screen and the system is going to check if the unique ID exists and it’s valid and if the user associated with it is a valid user. If all it’s fine, a message is presented and the user can perform the login.
Password recovery Flow
For the password recovery flow, the process is similar.
- The user clicks in the link to recover its password and is presented with an input where to type in its e-mail address, associated with its account.
- The system creates an unique ID and sends an e-mail with a message saying something like “We received an e-mail requesting a password reset, if it wasn’t you, ignore this e-mail. If it was you, please follow this link to reset your password”.
- The user reads the received e-mail and clicks on the link to confirm its user password reset request.
- The user is redirected to a screen and the system is going to check if the unique ID exists and it’s valid and if the user associated with it is a valid user. If all it’s fine, the user can set a new password and after the form submission, the user can login using the new password.
Users Management - Multi-tenant
As it was told before, one of the requirements was to use the Service Center built-in Users entity from the system.
In order to accomplish this, we needed to use the multi-tenant capabilities of the OutSystems platform. It’s quite easy to configure the usage of multi-tenant since that by default, the Users entity is already a multi-tenant entity which means that the only configuration we need is to set our database module as “User Provider” and the consumer modules to user that database module as it’s user provider module.
From this point on, all the changes made to the Users entity in the BingoApp_Data_CS, will be associated with this module and all the queries made, will filter users only from this module. There is no need to make complex queries or anything else.
PWA Configurations
The last requirement to fulfil was to have a PWA mobile application. The main reason for this was that OutSystems didn’t want to be dependable on any app store but at the same time, allow everybody to install the application in its mobile device.
For this, when we create a mobile application with OutSystems and define it as PWA, a lot of configurations are automatically done but anyway we had the need to change some of those configurations.
The easiest way to do it is by adding a manifest code in the “Extensibility Configurations” of the module.
"PWAManifest":{
"name": "OutSystems Bingo",
"short_name": "OS Bingo",
"display": "fullscreen",
"orientation": "portrait",
"background_color": "#000000",
"theme_color": "#000000",
"lang": "en-US"
}
To explain a couple of attributes that we changed:
- “display”: we setted this attribute to “fullscreen” because we wanted to completely hide all the UI elements on the screen (device status bar included);
- “orientation”: we used the value “portrait” to lock the device orientation while using the application. This means that when the user rotates the screen, the app will always be in a vertical position;
- “background_color”: this is the colour that is visible in the background before the splash screen is visible and before its stylesheet is loaded;
- “theme_color”: this is the colour for other UI elements on our device. E.g. in Android this colour is applied to the status bar and the task switcher.
Useful Resources
If you are interested in learning more about some of the feature I talked before, I leave here some useful links:
- Complete guide for PWA apps (web.dev)
- PWA manifest configurations (developer.mozilla.org)
- Generate all icon sizes for manifest file (tools.crawlink.com/)
- Forge Multi-Tenant Managing App (Carlos Alfaro, OS Forge)
Conclusions
In conclusion, it was a lot of fun doing this project. Since I am a UI developer, I am more used to create components, deal with CSS and JavaScript and inspect Figma files but from time to time, my “programmer” and “developer” sides comes to life and these projects are perfect for me to feed them.
As I said, creating applications for a virtual infinite number of users and situations and devices is always a challenge and that is something that I love to do.
.png){kind=small}
.png){kind=small}
