Trying To Fix What Isn’t Broken
How did we ‘fix’ a 5-star app?
The Learn app is a free resource that teaches you pretty much anything you need to know about investing in the stock market by giving simple and straightforward advice on investing.
The original Learn app was built approximately two years ago by an external software development company. At the time, the MyWallSt team only consisted of 5 people so we didn’t have the resources to build this app internally.
During its lifetime, the Learn 1.0 app was close to bug-free, got consistently good reviews, and had a high number of monthly active users. The Learn app’s free content continues to be read and loved by users all across the world.
In those two years, however, the Learn app had undergone hardly any change: it worked well, our users were happy with it, and our primary focus was on our other app—MyWallSt.
So, after working hard on implementing major changes to the subscription model in the MyWallSt App earlier this year, we decided it was now time to get our hands dirty and give our Learn app a big spring cleaning.
With April being Financial Literacy month in the US, what better time to give Learn a huge makeover?
Kicking off Learn 2.0
In the lead up to the actual development of Learn 2.0, various people and teams had had brainstorming sessions about the content and scope of Learn 2.0. We did SWOT analyses, reviewed feedback from our users, and tried to roughly estimate how much time we had against how much time we needed.
We decided that the scope of Learn 2.0 would be about the same as the current version, plus including several major feature requests from our users.
It was an exciting time and the office was buzzing. We knew we were taking a slight risk by completely redesigning and rebuilding a product that was already loved by users, but we were confident we would make our most used and appreciated app even better than it was.
The team was looking forward to start working again on this product that we’re very proud of!
The Design Phase
The design team had started to work on the app several weeks before the development team started and had prepared roughly 80% of all the designs what were needed during the development phase.
Although that approach is not fully in line with the Agile Scrum methodology that we use here at MyWallSt, we thought that this was the best way to go. We estimated that the development of the main features would only take about 4 weeks, so it made sense to have the designs ready before the development starts. Otherwise, it would only create unnecessary dependencies between the design team and the tech team.
The design of Learn 2.0 was done using in-house style colours and branding, but overall was rather greenfield. We let go of the design of the original Learn app and completely redesigned it in order to make it align more closely to our MyWallSt app.
Several assumptions were made while designing features and flows. We had analytics in Learn 1.0, but they were often inconclusive as to how people use our app.
An example of this was the concept of linearity in the sections. Would we allow users to proceed to a next section if they haven’t completely finished the sections before that, or would we disable that in order to push users to read the content in a linear way?
We also wanted Learn 2.0 to be released fast and thus we didn’t want to spend a lot of time (initially) on usability testing. We agreed that we would assume some things and verify them once the apps were live.
If our assumptions were wrong, the apps would be changed.
The Development Phase
The kickoff of the development Sprints started with a joint session where we went through the designs prepared by the UX team and the documentation of the backend APIs.
The release was scheduled to be before National Financial Literacy month in the U.S., so we had given ourselves 3 internal deadlines:
- 2 weeks for building the major components (like the home screen and lesson content screens).
- 2 weeks for building the minor components (like store offline audio storage).
- 2 weeks for fixing bugs found by our tester and colleagues in the office.
Part of the kickoff sessions involved a Sprint Refinement session. This is a get-together to discuss the contents of features so that everyone has a common understanding of what a feature should do. Most features are trivial, but some need a discussion between team members.
The refinement session mostly consists of discussing edge-case scenarios. For example, what should happen if the user starts downloading an audio file and they lose internet connectivity? The apps could retry the download in the background, but implementing this feature would be challenging on Android due to the way the OS is designed. We could just leave it to the user to retry the download manually, but in that case we need to inform them that the download failed.
Refinement sessions like this really help to align different parts of the team on edge-case and detailed functionalities.
The Coding Begins
Technologies change fast and, in regular development cycles, it’s difficult to incorporate refactoring work.
Refactoring means time spent on re-implementing existing functionality with the purpose of updating technologies used, making it more readable and concise, making it more bug-free, etc. These are all non-functional changes: the functionality of the app isn’t changed, just the way those functionalities are implemented.
Since we decided to build Learn 2.0 completely from scratch, we could throw all current and outdated technologies out the window and use the latest and newest libraries out there.
Yay!
We debated whether to use an entirely new architecture for Learn. MVI (Model-View-Intent), MVVM (Model-View-Viewmodel) using the Architecture Components and MVP (Model-View-Presenter) were all options.
In the end, we decided to stick to the architecture that is used in Invest because we were most experienced with that, and considering the somewhat limited timeframe, we didn’t have enough time to experiment on such a fundamental level. So MVP it was! (Hopefully, there will be a future blogpost about the app architecture we use, really soon).
The blueprint of Learn 2.0 consists of:
- Kotlin as main language
- RxJava2 for reactiveness
- Room as our database
- Retrofit2, OkHttp3 and Moshi for our networking
- Some great libraries like: Konfetti, Rx2Relay and AndroidSlidingUpPanel
The first Sprint began and covered the app’s major components, which included:
- Downloading of section and lesson texts and storing these offline (this was one of the most common customer requests that we received).
- The home screen with a moving view component that contains lists of all sections and their lessons.
- The view that shows the lesson content after clicking on one of the lessons in the lists on the home screen.
The second Sprint then covered more detailed features like:
- User’s progress as shown in the home screen, with a “Continue reading” button.
- Lesson text-appearance features: light/dark mode and font-size.
- Navigation drawer with features like “Get in touch” and “Rate the app”.
- A button at the bottom of the lesson view that take the user to the next unread lesson.
After the second Sprint, we released an internal alpha version for the Rubicoin team to test. We wrote down several use cases for people to test and encouraged them to try out as many things as they can think of.
Testing
Generally we advise our testers: “don’t be kind, try to break the app.”
When testing software, people tend to stick to happy flows. This is even more the case when developers test their own software, as people generally don’t enjoy breaking things they built.
‘In the wild’, however, weird things will happen to the app and it’s impossible to think of all the edge-cases that can occur while designing and implementing software. So the more our testers try to ‘break’ our app, the more we can make our apps bug-free before releasing them to our customers.
When we had finished trying to break the app, we entered into the last Sprint, which consisted of implementing the audio features (download audio and audio playback) and fixing bugs found during the alpha test phase.
Now, we were ready to release!
All aboard the release train
Our QA colleague does release tests prior to every release. These tests include flows that describe major and the most frequent use cases of our app. Testing these flows assures us that we aren’t introducing major bugs into our app.
Every individual feature that we implement, bug that we solve, or component that we refactor is tested separately. This is done by our tester at the time of development: right after developers are done with the implementation part and hand it over to the tester for verification.
All of these separate features, bugs and refactored components end up in a release (releases usually include 30–40 separate issues). It wouldn’t be unheard of that changing something in one part of the app makes unexpected and unintentional changes in other parts of the app that might go unnoticed. “Release testing” is about testing the combination of all of those individual issues, and is done to increase our release confidence.
After our entire team went through the final version of the app as well and no problems were found, we decided it was green light for the app to be released. Release notes were written, Play Store assets were updated, and the app was rolled out to 10% of our users.
We do this limited release to avoid all of our users being affected by any unnoticed critical bugs. We give a small set of our user base the new version of the app, and if no major issues are found, we increase the rollout percentage so that more users will receive the app update.
The rollout percentage is usually incremented from 10% to 50% to 100%.
And the results?
Since the 2.0 version has been live, a few minor bugs have been found and fixed.
The app’s reviews have been great and we’ve gotten a lot of positive feedback on the changes that we made!
