Seven years ago, Zola Electric welcomed its first Android application into the world. It was designed to support our sales and service staff as they went throughout Tanzania introducing solar energy to folks. It served us well.
Since then we’ve grown as a company and our needs have expanded as well. This led us to focus on developing a new Android application which met the following requirements:
- Resilient to unstable network conditions
- Worked seamlessly offline
- Used the latest Android best practices
- Incorporated User Experience principles
And so about three years we got to work! The sunsetting of our application proved more time-consuming than we originally imagined. I’ll talk more about some of the challenges we faced later. For now, here’s the process we followed:
- Notifying users
- Celebrating 🎉
In order to sunset our application, we needed to ensure that we were thoroughly familiar with the existing functionality. This proved to be a challenge because the developers handling the deprecation were not the ones who created the original app. And like many apps, there were few tests, little documentation, and no analytics.
This meant we had to go through each feature of the original application and document what the UI looked like as well as the API interactions. Once we had a certain feature documented then we could hand it over to the UX Designer to review.
After doing research, a new set of designs would be created. Whenever possible the designers would create prototypes in MarvelApp and send them to a few users to validate the changes. This often led to more streamlined, user-friendly flows.
Once we had a new design in place, we could get to work on the APIs and implementation. But which feature to tackle first? For us, our app is the means by which our sales/service colleagues earn commission. We didn’t want to jeopardize that. So we selected low traffic features to vet the architecture.
For example, we wanted to show potential customers presentations to help them understand the advantage of solar energy. We also wanted to collect basic information about where they currently get their power. This feature was not connected to commissions; thus we started there.
Over time, we began to implement more and more features from the existing application. As we did, we would break the original code into modular components, write unit tests, and incorporate user analytics.
One of the major challenges in our company is making sure that everyone is notified of process changes in their own language. We currently support four different languages.
Instead of relying on word-of-mouth to get out the news around functionality that would be available in the new app, we would add notifications to the old app about the enhancements.
This gave users the opportunity to gradually switch to using the new application as the features would become available. And whenever all users were trained on the new functionality, we would release a different variation of the notification that would inform them of the need to use the new app.
The final part of a good app sunsetting is the celebration. Although, we were very proud of what our new app had to offer, we wanted to make sure that everyone involved in the development of the previous application felt appreciated. We dedicated an entire All Hands Meeting to doing just that.
I created a trivia game to remind people of what went into developing the original application, as well as cover what went into developing the new one. I even created special certificates for everyone on the team who was involved with the deprecation process.
It was a long road, and we faced many challenges:
- Migrating to using GraphQL APIs from REST
- Moving Java code to Kotlin
- Transforming a monolithic app to a modular one
- And so on…
I’m very proud of the entire team! I’m especially proud to have been able to see this deprecation to its completion.
If you’re interested in learning more about the architecture of our application, check out this talk I gave with Moyin a few years ago…