Welcome!

Continuous Integration, Continuous Delivery & Continuous Testing

Tim Hinds

Subscribe to Tim Hinds: eMailAlertsEmail Alerts
Get Tim Hinds via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Blog Post

Facebook Made a Lite App | @DevOpsSummit #APM #DevOps

Should You?

It seems like Facebook is always up to something new. Well, they did something interesting from an application performance perspective a few weeks ago. On June 4, 2015, they announced a new version of their mobile app for Android called Facebook Lite. This app was designed to deliver a lightweight version of the Facebook experience to regions of the world where Internet access isn't as powerful. With nearly 1.5 billion users, Facebook is proving itself valuable in so many different ways all the time. To reach their users in parts of Asia and Africa where high-speed Internet access isn't as easy to come by, they needed something more accessible. The regular, heavy-duty app wasn't going to cut it this time.

The Facebook Lite app is fast to install, coming in at less than 1MB, and is quick to load. It's also efficient with data and designed for 2G networks and areas with limited network connectivity, making it ideal for these hard-to-reach users. What makes this recent development unique and intriguing from a performance engineering perspective is that Facebook chose to introduce an entirely new app, rather than optimize their existing mobile app.

If you've been in the software world for a while now, you know the idea of introducing a lite application isn't exactly new or uncommon. However, it's often done for different reasons. A free version can be used as a giveaway to attract new users while an easy-to-use version is perfect for novices. Likewise, single-purpose versions may be made to isolate and streamline a specific portion of functionality. It's very rare to see an app deployed specifically for performance reasons. You might be asking yourself right now, "Is lightweight performance enough of a reason to introduce an entirely new version of our application? Even if we don't have over a billion users?" Let's dive into that question.

Should You Go Lite?
The answer is "probably not" - at least, not purely for performance reasons. Recognize that Facebook is in a unique position. Not many software companies out there can point to the less developed regions of Asia and Africa as key growth markets. But if you really want to determine if you should go lite, you can take your thinking a little bit farther.

If You're Asking, Your Application is Probably Heavy
If you are asking this question in the first place, you must feel that your current application is too heavy in some way. Why? You need to get to the root cause. Is it old and bloated with lots of dead code taking up space and cycles? Is it jam-packed with so much functionality that it can't help but be enormous? Or has it gone unoptimized to the point where there are lots of opportunities to speed it up, just by applying a little focus?

Chances are, the reason why your application is heavy is because you've probably got more going on there than is needed for some segment of your users. A Lite version may be a solution to that problem, but a better place to start would be to sit down with your product owners and development teams and begin a discussion about producing better optimized code that matches the user's desired experience.

However, if it is truly a matter of different segments of users having different access patterns to the Internet, then a Lite version might be a good idea. Especially if you can easily identify different groups of users where some have easy access to high-speed and broadband networks, while others are stuck on unreliable or slower connections.

Users Access Your App Differently
If you do have a successful app, and a well-functioning development process that produces largely optimized code, you may still feel like there is an opportunity to reach more users with a Lite version. Start by taking a look at your users. Can you identify what separates the successful ones from those who struggle? Maybe it's the functionality they use? Or perhaps something related to their profession or demographic? Their location may also be a factor.

If your app is large or slow, you may have two segments of users. Some may understand how to use it very well and are willing to put up with the behavior, and some who are just learning the app and will churn much more quickly.

Gather Data and Discuss
Pull all this data together and take it to your development team and product owners. The truth is, launching a new version of an app isn't easy. It's not just the development work, but you also have to explain to your users when to use each app, a process that's often time-consuming and confusing. Remember when Facebook pulled Messenger out of its core app? That move definitely left some users annoyed and frustrated.

Ultimately, you may find that there is a good case to be made for a Lite version. However, unless you are Facebook, that case probably isn't entirely about performance. It's more likely about user experience and business opportunities. If you look closely at the reasons Facebook released their Lite version, you'll see that they clearly had business opportunity and user experience behind the decision.

Know When to Give Lite Apps the Green Light
Sure, not many companies can justify creating a lighter-weight version of an app just to reach untapped users across the globe. But we can all dream! Hopefully you'll find yourself in this position one day. Keep these tips in mind if and when you decide to go Lite and check out this post to discover how to boost your mobile testing strategy while you're at it.

Photo: Pixabay

More Stories By Tim Hinds

Tim Hinds is the Product Marketing Manager for NeoLoad at Neotys. He has a background in Agile software development, Scrum, Kanban, Continuous Integration, Continuous Delivery, and Continuous Testing practices.

Previously, Tim was Product Marketing Manager at AccuRev, a company acquired by Micro Focus, where he worked with software configuration management, issue tracking, Agile project management, continuous integration, workflow automation, and distributed version control systems.