Hello, everybody. Welcome. Good morning. Good afternoon. Wherever you are, we are all so happy and grateful to be speaking here among such incredible women.We are a group of engineers from wallop and we will talk for the next 40 minutes about backend driven U I or as we like to call it now, you can blame the back the back end for once. We hope you, you find it interesting and now I will give the word to my colleague, Rebecca.

Awesome. Thanks Anna. Hello, everybody in today's session. We will dedicate a few minutes to explain who we are and what's wall a pop. What's the service we are presenting today? The transaction tracking screen, which problems we needed to solve from the previous service and what's back, end driven U I then back end, front end and Q A will give their inputs. Uh later, we will dedicate a few minutes to discuss the pros and cons of this approach. And finally, we will share the conclusions we obtained uh after the development was complete and now Nes will explain us. What's what

about? Thank you, Rebecca and hi everyone. We are so happy to be here with you today. So let's start with who we are. Um We are six engineers currently working at Wallop representing the Ban chapter. We have just Viviana and myself on the front end web. Uh We have Aaya and as a Q A engineers, we have Anna and Rebecca. And now another big question is what is wallop? Wallop is a scale up company based in Barcelona? But we like to think about it as a community where millions of people buy and sell products they no longer want or need to give them a second chance by the premise. If you don't use it, just sell it. We encourage people not only to make some profit on things they they no longer need but also to live in a more sustainable way. Again. Nice to meet you all and Rebecca is going to explain a little bit more about Hot Guap pop works.

Thanks News Wall AOP. It works as a meeting point between buyers and sellers where they can communicate with each other directly through the app to buy and sell pro app products. In this presentation, we will talk about the future to track the shipment of the purchase through the app. Originally, the shipping method was one specific journey with one unique carrier and the journey was the office drop off. So sellers needed to go to the office carriers to deliver the package and then the shipment was starting for that service. We had a feature to track all the shipment in a way of a timeline. Users were tracking the whole journey in a single page when we wanted to evolve the shipping offers and implement the home pickup service. So the carrier company were going to the seller's address to pick up the parcel and the shipment was starting. We started encountering many difficulties for development. At this point, the shipping service was only available in Spain. So the second part of the challenge came when Wall AOP was getting ready to launch in Italy and it was time to think in a different feature to track the shipments.

We needed a feature much more scalable, that was simple and quick to interact with and that the carriers API S would be stored in backend. Additionally, we wanted to simplify the transaction interaction with the user and provide them with only the needed information in each step of the journey. And this is how the new transaction tracking screen was born. And now Viviana will share with us more details about the transaction tracking screen.

Ok, thanks Rebecca. Hi everyone. So let's see what is the tracking screen? So as Rebecca mentioned before, uh we have many different uh shipping shipment options. So when you put when you make a purchase, if you decide to receive the package at your address or uh some post office, you will see this page and here you can, you can follow the the instructions to to make the shipment to, you will see different uh information about the shipment and perform.

You can perform some actions. So for example, you can cancel the shipment or follow an instruction to deliver the package or if you have some problems, uh, you can open a dispute. Uh This is a page that uh as you can find today in wallop's application or in the web. But uh we will see during this presentation that we had some challenges and uh the approach that we took to resolve them. So in the next slide chas is going to explain to us a little more about these challenges.

So as Viviana was saying, uh this hasn't always looked like this. So let's see which problems led us to uh developing, developing this transactional tracking screen. As we mentioned before. Wallop is an ecommerce platform that support shipping. This in combination with the car and internationalization of the company is translated in the need of associating with different carriers, each one with the specific needs and the possibility of changing in the future. At this point, we had a one on one mapping in mobile to shipment status, which created a coupling between more apps and more business logic, making it mandatory to have mobile releases for every change or for shipping that cycle. In the same way, we also have a big coupling in terms of available carriers where apps stored all the logic, making the addition of new cars really complex. And uh this was vital Ford or quota international expansion. So having this uh we are going to see the three major problems that appeared. First of all, uh the app needed to iterate the screens very quickly. But our release time isn't allowing that. Uh Right now, our mobile release process takes two weeks, which includes uh the development of each stock which are front and back in a mobile. As you might know. Also, we need the regression testing made by Q A engineers. And finally, uh sending the app to the stores.

And this is just a lot of work for a simply a different state of a shipping process or perhaps adding a new screen. And this is also an extra cost in terms of human resources. Uh Following this, uh This uh makes the possibility of introducing a new B in some critical page. Uh Meaning that uh our mobile users will have to deal with them in that version of the application unless we open it a hot fix or something similar. And let's be honest, uh The users don't like to keep updating their apps every single day. Uh Finally, we needed to have all the logic duplicated for the front end in all the clients, Android I OS and web. And sometimes this development time was very expensive for both the backend and the clients. And this led to a lot of discussions since we are natural enemies. So let's hear. Now how we solved this problem from Laa.

OK, thank you so much. So, hello everyone. Um Now we are going to talk about how we, so the problem that just previously mentioned, so to manage the logic uh from a unique source of truth and the co the logic uh from the clients, we decided uh back in Raven U I and nowadays, uh the backend returns both the HTML on one side and the actions in another one from the three clients.

I think it's very important to mention that also back end is the one that is returning the ins to implement. Um They must be the clients who decide uh the way the reforms, uh the actions that were also returned by backing and implement them. And, and yeah, we have uh here uh a drawing where we can see uh that back. And now uh all the server is providing us the information. So basically, we don't have uh the problem of duplicate um all the uh same implementation in all the stacks. Now I pass it on to also my natural enemies, also known as W engineers.

OK. Thank you, Lia. Now we'll see how all this works from the back end point of view. First of all, uh let's take a look at the shipment timelines, legacy implementation. The screen was the only information that the user had available to get informed about the payment and shipment process that Rebecca explained before. As you can see, it was composed by a section at the top with a delivery tracking code, a timeline with the different blocks ordered chronologically that shows all the phases of the shipment process. And finally at the end, a button to go to the chat, this implementation had several problems that I'll cover. Now, first one being the usability issues, we discovered that the screen was quite difficult for the user to understand because it cost a high contact rate for customer support to get information about the purchase that they should be getting from the screen. But an implementation was quite complex since there was a table for every one of the different events from the timeline. Then as the events were being published, the information was saved in the corresponding table.

At the end, we ended up uh with um around 30 tables for the buyer and the same amount for the seller making it very hard to maintain. And also due to the amount of queries that we needed to be to the to do sorry. Every time the screen had to be rendered, it was not very well performing. Finally, it was also complex for the clients. Um The events weren't following the same structure. And as you can see in the example, Jason response where two of the events return are now highlighted, um they have different fields without any clear criteria. So it means that the clients had to handle a lot of logic to know how to print the information and how to build the timeline front end also needed to know which was the next event that would be published to show it great as a preview for the user. So once again, more logic and on top of all of that, one of the main reasons that led us to resign the whole screen was that we needed from 2 to 3 springs. That means around six weeks to build a new state. That is a huge amount of time for a change that shouldn't be so big. And as Rebecca and just explained before we were in a rush.

So now if we can see the new look for the TT S where we show the information divided into three screens, I think it's important to mention at this point that uh the new implementation was not only for apps since web still didn't have the shipment service on the right. You can see the main info screen where users can see the payment and shipment status and the shipment tracking code in the middle. You can see the detail screen where the user can see more information about each element in the purchase, the item, the buyer, seller, the shipment, et cetera. Finally, on the right the instruction screen, uh where the user can see any action that can be performed in its case depending on the step they currently are in the process we defined a contract for each, for each screen. Uh This means the clients call an endpoint and in the response back and send the components to be rendered in which order and all the data that they need. Uh This way, the logic was simplified and the clients don't have to distinguish between seller and buyer. They just need to call the end point corresponding to the screen they want to render. And all the business logic and control of what is going to be shown remains in the backend. And let's be honest, backends. Just love control.

Now we will go into more detail about how the main Infra screen is built.

Sentinels. OK. Uh Let's talk about how we start the process of building this screen. Applying backend drive nu I, as we mentioned before with backend drive nu I, the server is responsible for providing the data and the components to Uran. So um this is the, we can see here the the tracking screen. This is the screen that we saw before where the user can check the the shipment status, check the delivery updates and perform some actions. So um first of all, we have to analyze this screen and we define we with mobile and the UX team, how we could split them into generic components that we could reuse to build other screens. So for this screen, we have uh three sections first, uh we have the top action and on the right side you can see the API response, this is the response that the backend provide to, to the clients to web Android and I OS. So for this uh top action, it is a top navigation bar we can have here uh a title and some action. In this case, uh the action is a deep link. So the back end provides the URL where the user will be redirect. When when you click on it, then uh the middle, we have uh other section we call this shipping status. And here we can have an animation and some description related to the, to the shipment status. And we here we can, we can define uh some actions.

In this case, we have a button with a view instruction label. And uh again here, the, the buttons provide the URL where the user will be uh redirect when click in this button. Then um finally, we have the, the last section. This is the transaction status info. Uh We define here uh a list of rows and for each row, we can have an and some description uh for the description, the backing is injecting with html, the styles to be applied. So uh with this, uh we, we can see the components that we define and the response that the vacuum will provide to the clients and the bottoms and other interactive pieces are managed by actions and we will see this action in the next slide. So for example, uh for a button, we can define a title. This is just uh the visual test for the button. Then uh we define the style contain online or just a simple text. This is for define if the button uh have a border or, or a background. And, and then we define the state enabled or disabled depending if the user can click uh the button or not. And then we have the actions, we can have many different types of actions. And depending on the type of the action, uh we define the payload. So for example, uh we can have a di a ding uh for this uh component in the contract, we define just a URL. Then uh we can have a dialogue to require the user to, to take a decision.

And uh here we can have a title, a description uh in case uh the user can confirm uh again. Uh Here we can define all action and then we have the a po component. And for this, we define the name and the name of the resource and the parameters to call it. And here again, in, in case of success, we can define other action. So in this way, we are uh concatenating actions and we define the navigation through the app. So with this uh components, uh the backend provides the data and the components to, to be rendered. And uh the clients uh only have the responsibility to render these components. So we will see uh in the Nexus line. And chas is going to explain to us how we build all the screen with this component.

Following that uh we can see here the transaction tracking details. In this case, this is not a screen but a light. And as you might appreciate, this is another example of a contract that composes the front end row by row. By defining the content. You can see an app example at right and uh detailed one at left. If we take a look at it in detail, we can see that each transaction tracking details element is composed uh by the definition that the app gives. Uh And we can see for example, that product contains uh eaten price and uh sorry. Product contains it title and eaten icon. After that, uh We can see that price con contains it m price with the amount and the currency and the same applies for the other rows. Uh Also each actionable element like product or buyer receives an action that must be performed on click. This action is defined in the icon which is composed with the URL uh to obtain the image that must be displayed the style that it must apply and an action if it applies or not. And the description this composition of rose is very, very dynamic and it allows us to add or remove any neither one. But uh as you might appreciate the style is static.

And it only allows us to compose rose with that mm that composition of uh image that left a small title, a small description. And following this, uh we can see that uh with this architecture, we can um compose uh different screens, we can see three here. And with this modernized definition of components, uh we composed these three screens where we changed the icon, the information and related actions that were contained in the buttons. You can see here that buttons uh as your instructions uh will open a previous mentioned screen, that was uh the transaction instructions screen. And this means that with this process, we can combine uh different status and related actions, but al always using the same components.

And from our perspective, this is very powerful in those screens are the same for the front end web Android and I OS and only it is need to be done uh small adjustments that we are going to see and this is all for the vacuum perspective. And now let's see the front end implementation with our colleague Laa.

OK. Thank you so much. So now we are going to talk a little bit how we decided to front in, in in web. OK. So first of all, uh we decided to group the different sections of the page that my colleagues previously mentioned. This is basically what we saw but uh in a responsive design. So that's uh why the U I changes A little bit. So yeah, we decided to split the code as much as possible. We create a different components. Um The for the top section, for example, we have one that we um have uh represented on the drawing, we have another one for the middle section and another one for the um top rows that are in, in an orange color. So another decision we made is to wrap the action in an isolated component. And I will explain that in a few minutes. So um as you can see on the screen, we have some rows at the bottom, the orange one that I was talking about. And this is information related to the package. So each of the roles can bring uh us or not an an associated action and to manage it, we created a component to show the information and to study it a little bit. And if it's needed, we are going to um add the action selector and if the backend is not returning us and actually we are not going to to implement it.

So um for that, we create then the we create the status info component and like we can see on the right side uh if it's needed, um like I said, we are going to render the selector and if it's not needed, we are only going to use the status info to style uh the UI a little bit OK?

And in the case, for example of the of the top action that we saw uh in the previous screen. Uh No, yeah. Uh we can see the help link on the top and in this case, you can see that uh we uh painted in a blue color and that's because we already can anticipate that this will be an action to be rendered. So we don't need to implement the logic. Uh If um from 10 will we receive an action? We are going to print it and if not not because we can already anticipate it. So, um yeah, that's pretty much it. I only want to add that. Uh in this case, uh I already anticipate that uh this uh this is an action, thelin type. OK. And this is the selector that I was talking about. So um this component was created to recursively manage the action that back end was sending to us. And we know that we can receive or not actions, but we don't know which kind of action uh are we going to receive? So we needed to extract as much as possible the logic to be able to implement uh all of the actions that we have on the right side, we have like the one, the dialogue, the web view and the user action.

Um So um basically, I'm going to explain a little bit the flow that we follow since we receive uh the, the eto the data transfer object uh from when the user sees on the U I. So um when we get an action from the server, we map it to our data model and uh actions can have different parameters depending on the type of the action. So at this point, what we decided to do on web is add an attribute called uh action type. And once we have mapped the action type, we insert it in the action selector. And now our component is um I mean, uh they uh uh it's able to render by itself with kind of action uh we need to implement. And in this way, uh we have the responsibilities of each type of action separated from the others in different components. And now we have an example of one of the um types of action. Uh This one is the, the blink one and it's the same uh action type as the uh help that we saw on the first uh web um uh image. So in this case, uh we will have the content that uh comes from back in an anchor tag. And um in this type of action, we also receive uh the URL that we have to manage.

So um since the action can be uh internal and internal, uh I am referring into doing the redaction into our own uh domain, all above.com or external, uh we created a service uh to separate the responsibility of the component. And we can see it on the left side on the controller. So mm we wrap uh the content that uh backend is sending to us the HTML, we wrap it into an anchor and when the user clicks, we direct them to the server and uh to the service, sorry. And the service will manage uh the the direction type that uh needs to handle. And finally, I would only like to add that this approach is very similar in all the stacks. Uh Also, I'm referring to Android Ana S and now Rebecca is going to explain the methodologies that coa follow it. Thank you.

Nice. Thanks for all these inputs, girls. Uh Now and I myself will cover the Q outcomes of the feature. Um This feature has improved different quality dimensions such as performance, visibility or aesthetics. And as Nemo was mentioned earlier, the E A implementation uh did not have a good performance and exemplification of this enhancement in the performance dimension is that our delivery database CPU decrease from 17% to 2% within the first week. In addition to these dimensions, PNDU IC improves all the different quality aspects that we will cover in a few minutes. Also to test this feature, we applied some techniques, we will explain the benefits we obtained and how they were implemented in our ways of working. But for now and I will cover which were the pain points that we had to deliver a stable product to, to production with the previous approach.

Thank you Rebecca. As for the challenges with the previous service, there were some problems that from quality perspective, we wanted to improve. The main issue was the long time spent between finishing development until the product reached production. As my colleague just mentioned before, this is mainly because of the release train for the mobile apps where there are some steps that need to be followed before the app is 100% open in production. Like for example, manual regression checks done by the Q A team finding and fixing possible re release fixes, then sending the apps to the store and then the approval from, from apple, also the possibility of hot fixes and therefore uh for the stop of the release opening. And finally the adoption percentage which depends on the users updating the app, the pain point in the case there is a vacuum production is that all these steps make it impossible to fix the reissue right away because of the need to wait for the following release strain. And now Rebecca will follow with the quality

aspects. Awesome. Awesome. Thanks Anna as mentioned um the U I and allowed them to enhance some quality aspects such as operational and changeability, business value, resource management, and scalability from operation and changeability point of view. It's really easy to roll back um as an exemplification for this uh since we discovered the first bag, we um uh developed the fixed and we released to production it took us one hour to mitigate the impact. Then from business value standpoint, uh our delivery velocity increased by 600% as a metric to um me measure this. We uh compared how long it was taking us to deliver, to develop one of the statuses from the previous service and it was taking us trans prints. We compared this against how long it was taking us to develop the whole D DS with its independent statuses. And it took us the same amount of time, three sprints. Then from resource management point, uh we have less lines in the code in mobile apps, we have one single source of truth and having less logic in client. It allows us to need less pr s because with the previous approach, we needed four. Then from scalability side, we needed this feature to be applicable to different countries with different journeys and different carriers. With this new implementation approach, we have also improved our lead time which allows us to have a much more scalable service.

And now a a will cover which were the testing things

applied. Thank you, Rebecca. Um As for the testing techniques, we applied two main ones, the mapping and the pair testing for the mapping. We have mapped out all um from high level to eight level, the user journeys, which was very useful for our TT S feature since it has a lot of statuses and user journeys. This technique has allowed us to identify possible flows up from development and being able to solve them in a refining stage and also the viable experiments. Before releasing as an example, we formulated an hypothesis where we believe that if the user gets better informed through the new TT S screens, then user will have less need to contact consumer service for extra information. And the outcome of the experiment was that we saw a 5% reduction in contact rate in consumer service. As for the pair testing, uh for us, it was very effective to gather different stacks together to test the product to enhance the whole team testing. We also did several demos for the team which was very useful for improving the communication between sex and also taking into account that now any change done in the back end is also affecting front end, then the communication between back and front end NQ A needs to be high.

So all the stacks are aligned and now I will give the word to my colleagues J and Lia who will go over the pros and cons of this approach.

All right. Thank you so much for this amazing input creating. So let's see uh the pros having encounter that this is our current implementation and considering the reasons that uh leaded us to adopt this approach. So the main points in favor here are that first of all, there's no need to release any mobile app version which reduces uh or lead time and also reduces uh the cost in terms of development. Once it's implemented following this, uh it gives a native experience for users but is reactive for wall AOP. Meaning that we can act in any situation like uh introducing A B or any logistic issues such as changing carriers. One main point for back in perspective is that we have all the logic centralized, we have only one source of truth and that is very important for us. And these points also leave us two or final one back drive U I gives us consistency, consistency across all the platforms from having the same styles and screens in every client to the uh vacuum improvements such as having the same endpoints with the same logic for everyone.

So uh now let's see the cons from my colleague Lia which after implementing back in ju I is now our friend.

Yeah. OK. Thank you. Yes. So now we are going to talk about the cons. And first of all, I think uh it's important to remember that the web implementation was made a few months ago. So uh when this implementation was created, we were not there uh with uh the other clients. So the first one is the um I think that that accessibility could be improved since uh back end should return the specific T depending on, on the kind of information we are showing to the users. But nowadays we are mostly the cyber uh uh spa tax. So this could be improved. Um The second one is that some styles uh like I said, web was not there when this implementation was uh developed. Uh the first of all, so the active, the yurt styles uh are uh implemented on the web client. Um uh I think that this uh can give us a little bit of inconsistency because yeah, it's true that we have one source of truth but uh for the styles are not always like that. Um Last but not least. Uh this is a backend cons is that um since they apply uh styles in some t that they are um after sending us to show on the front end, um it's a little bit more difficult uh to style that kind of data without seeing it directly.

It's true that uh when they uh are already implemented, they can see the change uh super fast uh reflected on one of the clients. But um in time of coding, uh it's a little bit more tricky because yeah, they can see uh the results uh directly and now I pass them I to ana to talk out the conclusions.

Thank you girls. Um As for the conclusions to sum up uh one of the best use cases to apply back in NU I is when you have a static layout, but dynamic content. Furthermore, the success of our backend revenue implementation was to focus in defining reusable components that have let us build new states quickly without further changes in the client. As a consequence of the back and providing all the necessary data. It has been easy to apply experiments to test new changes with A B testing, which was something very, very difficult to apply with the old implementation last but not least, even though there are some things that could be improved and that there is room for improvement, the service is working with great with a great performance.

And the back in revenue I approach allowed us to achieve all all our main goals, we were able to iterate the product quicker. Also, as mentioned, we have now a capacity to do easy a bab testing and the possibility to escalate the product according to business needs. And this is the end of our presentation. We hope you ha you have found it interesting for contacting us. Please scan the QR code shown in the screen and many many thanks for listening to us.

Bye everybody. Thank you.

Bye

bye my trip. Thank you.