Outsystems user group 2021 03 04 - cm app

Editor's Notes

• #8: Consult their CM/MC profile Personal data Care data Dependants Consult the Reimbursements of themselves or their dependants Payments Prestations Contact CM/MC Using FAQ mechanisme If the FAQ doesn’t provide any answers, a form is available for the end users to fill in Request CM/MC advantages The type of advantages that are available to the end users are managed by the business in a backoffice.  The user is able to request them for themselves or their dependants They can provide files or pictures (editable in the app) along with their request All that in an intuitive and UX friendly way  For the first time, the user is guided through a tutorial flow Request Yellow stickers The user is able to request them for themselves or their dependants Those stickers are used by the CM/MC to process documents automatically using the barcode that is available on those yellow stickers. Onboarding flow For new users For existing users who still needs to be verified or upgraded (light users to secure users) Verification with ItsMe/CSAM (Identity provider for belgian Identity cards) All that in an intuitive and UX friendly way  The whole verification is being guided through a tutorial flow UX friendly and secure login mechanisme Fingerprint and face recognition configurable during the tutorial in the onboarding flow or in the settings once logged in into the app Application pincode configurable during the tutorial in the onboarding flow or in the settings once logged in into the app Backoffices for the business to configure and change app information/data on the fly without the need of deploys 
• #9: Our team consists of a Product Owner, a SCRUM master and development team (Developers, UX/UI designers, Solution architect,...). Since we approach the project using the agile mindset most of those roles could be picked up or backed up by another member of the team. For example, we do not have a dedicated tester in the team. But the whole team is testing each other's implementation before it was being tested by the BU once again. For the delivery of the project we are working in sprints consisting of 2 weeks using a tool called Jira. Our project has 2 boards: Development board The board that developers follow for the deliverables in the current sprint. Analysis board The board that the Product owner and the BU follow to prepare and create deliverables for the development team.  During the sprint, a sprint refinement meeting with the whole SCRUM team is taking place, where the following subjects are being discussed: Bottlenecks in the current sprint Questions that need answers Preparation of the next sprint in terms of stories, tasks and bugs State of the current sprint Discuss the backlog At the end of 2 weeks the following meetings are being planned: Sprint review A technical demo to everyone including stakeholders with the progress of the current sprint. What has changed? What is new? What has been fixed? The Product owner also show the progress of the business tasks to the stakeholders from the Analysis board on Jira. Sprint retrospective We discuss with the whole SCRUM team how the sprint went.  What are the good things? What are the bad things? What did we learn from the previous 2 weeks? What are the action points? Sprint planning During this time we decide what the goal of the new sprint will be, and based on all the preparation made during the sprint refinements, we can quickly fill it up using the backlog items. Some estimations on stories still have to be done.(sometimes a lot have already been done during sprint refinements) 
• #10: The first phase of the mobile application has been delivered with the required functionalities all within time and scope. The mobile application has been deployed and made available in the app store/ google play store. Which was first being communicated internally.Currently a marketing campaign is going in phases to communicate the full release of the app to the public.  Development has not stopped and a new roadmap with new functionalities are being implemented while keeping the current state of the app as a base of what’s to come. 
• #13: The current architecture of the mobile app in itself is very simple. We have front-end module that consists of multiple flows based on the core modules below.
• #14: And based on each business concept we have their respective core module with their Local storage, sync and core widgets bundled together. (Will change in the future)
• #15: Then we have backoffices with screens for the BU for the creation of data and service wrapper modules that provide the data to the mobile app through exposed REST API’s. Why do we use REST API’s instead of dependencies? Some internal data are not available in Outsystems tables, but wrappers are created and new API’s are exposed with a subset of data  based on more specific use cases. One example: An internal service API returns every personal information about a member. But we don’t want to send all that information to the app to process. The app doesn’t need all that information. That’s where the MemberInfo module becomes very important. It call’s that internal service API, but creates wrappers around a subset of that data and exposes it as a new API that is available for the app or in the future for other Outsystems applications.For the data that is available in Outsystems tables (for example Advantages) we also use exposed REST api’s because the API’s will be used by other applications in the future (Outsystems or not). 
• #18: As mentioned in the previous slide, currently each of the core modules of app are bundled with the sync, local storage and the core widgets together based on BU concept. The next steps are to split it even more up into their own core module if needed.Currently we didn’t do it because the app in itself is simple. However, the app is still in development and many new features are being added. So that’s why we are currently moving to this architecture. And will be very easy/fast to do so based on our current architecture.One last thing I would like to mention is that the core widget module will also be splitted into 2 types of modules: Mobile UI core modules and Mobile core widget modules.The reason why we also might split them up like in the picture above is because the core widgets might be reused across other mobile or even reactive applications. 
• #19: As designtool we used figma. Figma is a cloudbased graphics editor and prototyping tool. One of the nice things is that we could have some discussions and the designer could change the design in real time. We used Figma to build flowcharts, create wireframes and prototypes of the app and change them to make the final design. The UX/UI team also created a prototype app that they used to do the first usertests. We could then use the feedback from these usertests to change the design/flow of our app.
• #20: As the name states the flowcharts is an overview of the flows between the different screens in the app. For this example I have used an overview of the payments of the users. The payments screen is accessible from the main dashboard of the app. On the first page the user gets an overview of all his reimbursements that he received from the cm. Inside this screen we also added a filter fow which we used the sidebar widget. When the user presses a reimbursement we also open a sidebar which has a webblock inside of it to show a full detail of the reimbursement On top of the screen the user has some buttons to move him from the reimbursements to his contributions overview which shows if he has paid his contributions to the cm. The user can also access an overview of the allowances
• #21: Here you can see the full flow of designing a screen. We start with a wireframe which is a very basic design. We use this to get a general feeling and a visual guide of the screen. We agreed that the best option for our app were to have some tiles on the dashboard of the app. This way the user has a nice overview of the main functions of the app and gives them a quick and easy way to access them. The designers then started to make some prototypes. The image that you see in the middle is just one of many prototypes. As you can see we were pretty close to the final design of the app. They just decided that they wanted a little bit of a more clean look for the app to give the users a better overview of the mail functions of the app.
• #24: First of all we used the Android back button from the forge to capture the back button click events. This way we could enable/disable all the back button triggers of the android users. This was necessary because on a lot of pages we have input parameters that need to be filled in. This couldn’t be done without this component. One of the issues we had with the android back button was that when de destionation was set to previous screen. En the page to which we would navigate was set to the default scree, which is the dashboard for our app. The app would refresh and the page wouldn’t recognise the locale of the app. We solved this problem by setting a fixed destionation on every page that would lead to our dashboard. During the user testing a lot of testers would complain about the fact that the app wouldn’t minimize when the pressed the backbutton on the dashboard. We solved this by adding a cordova plugin. On our Reimbursments screen we used 2 sidebars, one to filter and one to show details. These sidebars also capture the back button event. µ FilterTabOpen  close the filter  don’t trigger the filter DetailSidebarOpen  close the detail sidebar
• #25: For the iphone we could use the .iphonex.portrait.Header class to detect the iphone and add some padding-top of 50px to make sure the title wasn’t stuck to the notch For android and older iphones we just added a header class with a fixed height that would cover the whole notch and some space below. And we then added all the titles and action buttons on the bottom of the container with placeholder.
• #26: As you can see business wanted to have a page which had tabs inside tabs. We first tried to add 2 tabs widgets inside eachother, but outsystems would also change the bottom tab when we switched between the top tabs. Because they used the same active tab attribute. Becouse the pages of the top tabs are the same we created 2 screens with the same layout. And made the bottoms tabs out of containers with some css. When the user clicks on the top tab we just navigate to the second screen. Ans change the css to make it look like the second tab of the top tab is active. And for the lower tabs we just used the tabs widget of outSystems.
• #27: Luckely for us the app was pretty good adapted for a tablet. Which is ofcourse one of the great things about outsystems. But sometime there would be some small design issues. Like you can see in the slide all the tabs would be aligned to much to the right. There were also some small other issues. But there were all pretty minor. If you want to make a custom class for tablets you just have to put .tablet in front of your class and then change the css to that class. Then every item with that class will have the tablet css when the tablet is detected.
• #28: Slow api’s The problem we had was that the whole offline datasync took more then 10 seconds because of the complexity and legacy systems. We solved this by separating the offline datasync into smaller actions that we would call parallel. Together with our designers we created a flow that would hide performance issues form the users and gives them a more pleasant experience. When the user accesses a page that has data that he is waiting for The networkflow wasn’t optimized. There were some security components that slowed down the response times. We had a lot of meetings with the internal network team to rework this flow. This resulted in much needed performance improvements.
• #29: The app is currently only available for logged in users that are clients of CM, so a solid login mechanism these are the main challenges we faced, I’ll go over them one by one and explain a bit more on how we solved them.
• #30: One of the first challenges we faced was that we couldn’t just reuse Outsystems accounts and authentication out of the box. Existing users on the website needed to be able to log into the app seamlessly with their existing accounts. And vice versa our users would have to be able to use the website as well. The team responsable for these accounts exposed some of their api’s to be reusable by us. To avoid security issues we chose to call these api’s not directly from the app but rather from our Outsystems server wrapped in a separate application and exposed as service actions. This allows for weak dependency and allows us to add some of our own logic before using these.
• #31: When users create a new account there is some extra complexity, we need users to prove to us who they are. For this we use a government website that handles eId verification through services like “itsme”. This way we can receive the users national number so we can link this to their account. Since the government site works with whitelisting and redirects that aren’t mobile-friendly: we use a wrapper site. This also allows us to reuse this wrapper site if needed. While this seems rather complex, because we provide the user with the necessary info in the app almost all users seem to be able to complete this flow. After completing this flow the user now has a verified account by which we can identify him and retrieve information.
• #32: For technical reason we are required to store credentials client side, this is ofcourse a challenge since we need this to be done in a secure way. At first we used the keystorage plugin, this seems like a logical choice. After a while however while user testing we found that this discriminated against to many users. Users without a screenlock on their device can not use the app. This amounts to a big amount of users, in fact we were a bit surprised by how high this ratio is. These two reason led to the following decision: we need to encrypt this authorization.
• #33: Luckily we are not the first ones to need encryption with Outsystems, so we have a component ready to use and a success guide that i’ve linked here. The schematics on this slide explain the principles of how this is done, I won’t go into great detail how this happens since the guide explains this very well but there are a few things I would like to point out. First on the right you see the KEK which refers to Key Encryption Key, this is a main encryption key that encrypts all other keys. This is a principle that’s called envelope key and ensures that even if a key is compromised it is not in a useable way to decrypt data.