One of our clients, a large media group in Latin America, came to us with a mobile project. Their online television division wanted to ensure viewers could watch their favorite programs at any time, anywhere. After the successful launch of their iPhone app, we were brought in to build an Android application with video-on-demand.
As the iPhone application was already available, it was important that the Android mobile experience looked and felt the same. This was essential to keep their brand consistent and the user experience seamless across all mobile platforms. It wasn’t easy, but we pulled through! In two days, we had the app running on CI, inside Maven and updated on every commit that was always available for beta users. The Android application was completed within 16 weeks. Within one month of launch, the application had 42,000 downloads.
The project was a major step in the field of mobile for us. It was our first local Android project and we left no stone unturned to ensure we did the best. The app itself proved to be successful, as it represented the client’s image in the market. But there were four important lessons we learned, and we want to share those:
The client had done a lot of research to create the iPhone app. We were roped in to reproduce the same on Android. This was quite a challenge, given that Android would require a different approach. It took us quite a while to convince the client that an Android UX was different, as are the users. Merely replicating the iOS gestures on an Android platform would be the wrong way of doing it, as it would harm the user experience considerably. Android and iOS platforms are different, and we need to ensure that user experience does not get compromised while trying to build an identical app. We got working and deployed a poly-skilled team on the job. We began to build the native application from the ground up, while staying as aligned to the user experience of the iPhone app as we could.
We had daily releases, so User Experience and Continuous Delivery were key skills in this project. We constantly got the Product Owner to test the stories, as they got ready, so we could ensure a seamless UI across both platforms. We would constantly work on feedback and adjustments and this gave us the much-needed boost in completing the project well.
If we could go back and do this again, we’d want to include a wider pool of testers. We were using TestFlight as our testing tool, which would give us great and immediate feedback. However, we had to keep the project under wraps till it was officially launched, and so had to pick our beta testers from the stakeholder pool.
Since mobile hardware is limited compared to a regular computer, we learnt how to build an app that makes the best use of the resources available. We learned how to recycle elements on the page, instead of just creating them and letting the garbage collector take care of their removal. Although this is something the Android platform supports, developers sometimes forget to use it because it is completely different from a desktop development.
Secondly, network connectivity is limited in Brazil, where 3G is far from being stable in some areas. We learnt to build an app that can be optimized for low bandwidth with minimal download of large images. Images would be downloaded in the background, in a separate process, so the app would not get “stuck” when the network was unstable. The user could then have the entire structure of the page (buttons, text, the actual place for the image without it) ready and responsive while the images were being downloaded.
User behavior is our best tool to understand how we should build an app. This was also one of our biggest challenges, because the user research available to us was for the iOS platforms.
Different phones have gestures that users are familiar with, and we leveraged these while working on the app. Coming from the world of web applications, the screen seems smaller and buttons seem fewer. But keenly observing user behavior and interaction helped us design an app that people find intuitive.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.