Warning: mysql_real_escape_string(): No such file or directory in /home/anders_ux/emergingux.com/wp-content/plugins/related-articles/related-articles.php on line 792
Warning: mysql_real_escape_string(): A link to the server could not be established in /home/anders_ux/emergingux.com/wp-content/plugins/related-articles/related-articles.php on line 792
Facebook sent a team of product managers and engineers to Africa in 2013 in order to do user research and see how well the app worked. The result? Performance improvements and backend changes.
These are the problems the Facebook team detected and solved:
Start up time
- Problem: devices with one processor core queued the startup tasks, making the app take long to start.
Solution: initialize some processes after startup, or only initialize when a feature is used.
Result: reduced startup time by 50%.
- Problem: the app was using too much data. Data is extremely expensive in emerging markets, and it’s a lot of hassle to buy more data.
Solution 1: they looked at alternative image compression formats and ended up using the WebP-format.
Result 1: reduction of 25-35% of data from JPG, and 80% compared to PNG.
- Solution 2: instead of loading full size images, load only images adapted to the viewport size. If the user wants to zoom in, a bigger version of the image is downloaded.
Result 2: less initial data usage when loading the feed.
- Solution 3: attribute data usage to individual features, to make sure data is only sent/received when needed.
Result 3: 50% reduction in data usage.
- Problem: Facebook’s networking stack failed to perform in regions with intermittent networks.
Solution: modernized the backend technology for server communication.
Result: 90% drop in failed image loads.
- Problem: the application size was too big for certain phones.
Solution: set up different applications for different phones and users – some app distributions had less features.
Result: 65% reduction in application size (for certain users?).
Data usage vs high quality images/content
All these changes are really great! Not only did they improve speed and performance for emerging markets, but they did it for all markets. When they initially did their research, they burned through a monthly plan in 40 minutes. However, with around 50% less data usage the plan will still last only 1 hour and 20 minutes. Ideally they should design the app so that it lasts for a full month – but is that possible?
When I have been doing user research in countries like Nepal and Indonesia, I frequently get feedback about performance and data usage. The users know a lot about data usage. Some of the users I talked to said that they use Facebook to chat, but that they don’t use the official Facebook apps (Facebook has two apps; one for chatting, one for the feed) on feature phones because it uses too much data. The users knew that Facebook uses XML to send data, while many other chat apps uses binary formats to send data.
People with a limited, expensive data plan will choose quantity over quality. You would rather have a very limited feed displayed a couple of times every day over a month than have it load only a few times with high quality images. This is a win-win situation for both Facebook and the users; people feel updated on what’s going on and they use Facebook more frequently.
If you have a 100 Mb data plan, loading the Facebook feed is going to consume several Mb each and every time. An interesting experiment is to dramatically reduce both picture size and increase compression. If the user sees something that might be relevant, she can always just tap the picture and download it in a bigger version.
I know what you are thinking – this guy is crazy! Why would anyone view a tiny compressed image? Isn’t this going to give people an impression of Facebook being a low-quality social platform?
Based on my research, people want to be able to view low fidelity picture for the sake of saving data and viewing the feed faster (loading the full feed could take minutes on a slow, unstable network). In fact, many would like to turn off images altogether. Viewing a 1 KB image would give the use a basic impression of what the image/post is about. If they choose to tap on the post or image, they will be able to download bigger images.
Smaller images also means less use of memory.
Let the users choose!
Facebook did a lot of excellent technical improvements to their app, but they could have gone much further by redesigning their app specifically for reduced data usage.
Consider the following scenario: for certain markets, Facebook would enable a feature called “Speed mode”. The user gets a popup asking them if they want to speed up their feed. If in speed mode, the app would download much smaller images, it would be stricter about automatically loading new data and it would disable cover photos and sticker images.
The following image shows an example design. To the right you’ll see 3 versions of the feed; full image, small image, and tiny image.
As you can see, the data usage savings are now dramatically reduced, but the user can still see the content. Say that the feed was previously 0.5 – 1 Mb. In speed mode, the feed could potentially be loaded with less than 10 KB. The user can still enable and disable the speed mode at any time.
This enables users to spend more time on Facebook, and to get more frequently updated about their friend’s activity. By letting users choose a lower-quality, but faster feed – Facebook is more likely to reach out to even more people in emerging markets.