Project Nimbus — From the concept to the App Store
It was 2020 and you could count on the fingers of one hand the apps that were still using a hamburger menu. Wallapop was one of those few. That kind of navigation had been solving our needs until then (even though replacing it with more modern navigation had been on the table for some years).
But as the app kept growing, adopting more user-friendly navigation became a must. In April 2020, the decision was finally made. Wallapop started the Nimbus project, a project that would bring a tab bar into the app!
How did it start?
Adding a new feature to the app was getting messy as the only place to add it was the hamburger menu. As a result, we were mixing too many concepts in the same single place. Also, adding the entry point into a feature from the hamburger menu resulted in the user losing the context from the entry point when closing it.
The first step was research. We started by gathering all the features of our app and organizing them more logically. In this way, we were able to test the new app’s information architecture with some users.
This new information architecture grouped the features into a similar scheme as the one seen in Figure 1. Some screens contained a limited number of options, other ones had an unlimited number of options and some were a single screen.
To have a better user experience, we decided that when the list of options was short, we would use horizontal navigation through the options. If the list was large, a vertical list of items would be used.
So this was the point where developers got involved in this project, once the product team had created the new information architecture and applied it in the current app design.
How did we implement it? (iOS)
If you are expecting a technical article, this is not for you. We are going to talk about our experience; what was easy, what was difficult, some curiosities, etc. So it was September 2020, and we got our hands dirty!
The first step was to add a tab bar to the project and create the second-level navigation component that can be seen in Figure 3.
The Wallapop iOS project is in a process of refactoring to split the app into modules. Why do we say this? Because the screens that have already been moved into modules were easy to move into the recently created tab bar. They were already isolated from any dependencies.
Once the easy screens had been adapted for the tab bar, it was time for the tough screens to be added into the fancy new navigation. Then we started the work of analyzing what kind of problems existed to estimate the delivery date. This is the list of the issues we had to face to finish the work:
- Dependencies: Some of the legacy screens had too many dependencies, which caused difficulties when presenting them from another point. This was mainly because the old architecture relied upon the wireframe pattern to navigate through screens. To start having more isolated and independent screens, we started migrating into the coordinator pattern.
- A/B test: This navigation change had to be tested and the result of the change measured. So the old navigation was maintained and some views were duplicated to have both options available and to avoid too many weird flags.
- Customized navigation bar: In some legacy screens, the native navigation bar was hidden, a customized one was used instead. When we added the second level of navigation into these screens, there was no need for the navigation bar to be displayed. So, all of those screens had to be reviewed.
- View lifecycle: For example, the app tracking was done in the lifecycle event “viewDidLoad”. With the tab bar, that was happening before the screen was displayed. In some cases and not tracking more than once, even if the user entered that screen more than once.
- Rely on a screen as the entry point: In some parts of the project, it was assumed that the root controller was a certain controller. With the tab bar, the root controller was another one. For example, this issue appeared during presenting deep links when trying to cast to a certain type.
The result of the investigation was that a lot of refactoring had to be done to all the non-isolated screens. Unfortunately, we had a deadline. The project needed to be finished by the end of 2020. Consequently, some tradeoffs had to be made. The decisions we took were:
- Only refactor completely those parts that weren’t a screen itself because they were part from another screen.
- Try to replace the wireframes for a coordinator with less responsibility whenever possible.
- Add boolean values into customized navigation bars, because the baseline should continue seeing that view.
- Check all the calls made into lifecycle events, now data consistency could be harder to keep, so move the required calls from “viewDidLoad” into “viewDidAppear”.
- Create a container screen where multiple child screens can be added and controlled using the second level navigation.
Results of the A/B test (iOS)
Now that we presented our simple solution, we are going to show some A/B test results. A little spoiler here, the user engagement with the app has increased a lot with tabs other than the “Wall” screen:
- +43 % Favorites tab
- +23 % Saved Searches tab
- +20 % Favorite Profiles tab
- +3 % Upload tab
Before saying goodbye
Developing this kind of breaking changes into such a big app may be dangerous. Before we started with these changes, a lot of investigation and testing was done.
Even though there were no locking points, we had to assume some tradeoffs to finish on time. This kind of change, even if they are difficult to implement, can lead to huge improvements in usage. As the ones are seen in the Wallapop app.
Adding a tab bar to the project gave us some project status insights. For example, we learned that having every screen isolated from the presenting point, allows us to be faster modifying the flow. A requirement in Wallapop’s philosophy is to test continuously the app and see the results, which is a must for the company.
