Framing the issue through social lenses
Bruce Lawson’s presentation about the web around the world and it being our responsibility to keep in mind those people who are not in the wealthy western hemisphere where we take connections and devices for granted.
Designing apps and sites it’s not just a matter of creating a good technical framework. It’s also about knowing the culture and the people you are building the content for. This may mean a lot of research and, ideally, a visit to the country or countries that you’re building your application for.
For example, do not force users to provide a first and and last name. In southeast Asia there are people who only use one name; making them lie or make up a name just to use your service means they are not likely to use your service again, or at all.
Bandwidth is an essential consideration. When the 1GB of bandwidth cost a large part of a user’s monthly salary, it becomes very important to make the applications (native or web) as small as possible to make them affordable, not in the direct cost of the app but in the cost of the bandwidth it takes to download it.
Perhaps the most important consideration is to meet your users where they are and in the language, they speak. Using colors may be tricky if you haven’t researched their cultural significance. The table below shows how different cultures perceive different colors. You can see that the perceptions can be absolutely different.
|Sacred (the Color Saffron)||Virtue
There is a similar issue with local languages and dialects. It is not a good assumption that most of your users outside the US and Canada speak English but, even if they do, it would help them (and you) enormously if you take the time to translate your content to their language or dialect.
Yet for all the differences in languages and technologies, we are not that different. In his two-part essay in Smashing magazine Bruce Lawson addresses this.
There is a more profound commonality as well. Below are the top-10 domains that Opera Mini users in the US visited in September 2016. (These figures are from Opera’s internal reporting tools; I was Deputy CTO of Opera until November 2016. Now I have no relationship with Opera.)
The top-10 handsets used to view those websites were:
- Apple iPhone
- Apple iPad
- Samsung Galaxy S Duos 2
- Samsung Galaxy S3
- Samsung Galaxy Grand Prime
- Samsung Galaxy Grand Neo Plus
- Samsung Galaxy Grand Neo GT
- Nokia Asha 201
- Samsung Galaxy Note III
- TracFone LG 306G
The top-10 domains visited in Indonesia during the same period were:
Note the commonalities — keeping in touch with friends and family; search; video; uncensored news and information (Wikipedia) — as well as the local variations.
The top-10 handsets in Indonesia are lower-end than those used in the US:
- Nokia X201
- Nokia Asha 210
- Nokia C3-00
- Generic WAP
- Nokia Asha 205.1
- Samsung Galaxy V SM-G313HZ
- Nokia 215
- Nokia X2-02
- Samsung GTS5260 Star 2
- Nokia 5130 XpressMusic
In Nigeria last month, almost the same kinds of websites were viewed — again, with local variations; Nigeria is football-crazy, hence goal.com.
But the top-10 handsets in Nigeria are lower-end than in Indonesia.
- Nokia Asha 200
- Nokia Asha 210
- Nokia X2-01
- Nokia C3-00
- TECNO P5
- Nokia Asha 205
- Nokia Asha 201
- TECNO M3
- Infinix Hot Note X551
- Infinix Hot 2 X510
Doing some digging on the specs of these phones is eye-opening.
For example the Nokia Asha 210 (number 2 most used phone in Indonesia and Nigeria in 2016 according to the stats above):
- Display: 2.40 inches
- No Front Camera
- Resolution: 240×320 pixels
- RAM: 32MB
- Storage: 64MB
And your content has to work as well on both ends.
Design as a frame of reference
Google introduced the Next Billion Users concept as an umbrella for initiatives geared towards the next generation of Internet users.
These users will not be in North America or Western Europe. They will be un Sub Saharan Africa, Asia, and Latin America, places like Brazil, China, India, Indonesia, and Nigeria. They will be using mobile devices that, as a rule, are far less powerful than the devices we take for granted in far less reliable networks 2G and 3G networks.
For the next billion, it’s not a matter of mobile first but of mobile only. Their entire online experience is based on the devices they use.
Many of them will use proxy browsers to maximize their bandwidth usage. These browsers (like Opera Mini) create a new set of constraints for designers and developers.
Opera Mini is not the only proxy browser available. It’s the one I’ve tested with and the one I’m most familiar with.
Oper Mini has multiple settings whose names are dependent on version and Operating System. See Opera Browsers, Modes & Engines for more information on the different versions of Opera Mini, their support for standards and the rendering engine they use.
For the remainder of this section, I’ll assume that Mini is using its most aggressive data saving settings.
And the usage of proxy browsers like Opera Mini is why PWAs are well suited to emerging markets and why we should design for these lower-end devices as well as for the high-end phones and tablets that we are used to.
I won’t go into the details of how to build a PWA. There’s plenty of information online about the subject, including Progressive Web Apps training curriculum from Google available to use.
PWAs use APIs that make web applications competitive with native apps in a more equal footing.
Through service workers, PWAs provide caching mechanisms so that the content loads faster after the first visit and can intercept requests to modify or completely alter the response the user gets.
PWAs can notify the user about new information and when there is updated content for the user to see using push notifications.
Service workers can provide offline content, either a default offline page or a view of the last content stored in the cache.
Finally, service workers improve the site’s performance beyond giving you offline capabilities. Depending on how you choose to cache your content, the browser may not need to fetch content from the network and, instead, it’ll get it from the cache… a much faster experience.
And why is this important? Bruce Lawson states it succinctly:
Recently, my ex-Opera colleague Andreas Bovens and I interviewed a Nigerian and a Kenyan developer who made some of the earliest progressive web apps. Constance Okoghenun said:
Nigerians are extremely data sensitive. People side-load apps and other content from third parties [or via] Xender. With PWAs […], without the download overhead of native apps […] developers in Nigeria can now give a great and up-to-date experience to their users.
Kenyan developer Eugene Mutai said:
[PWAs] may solve problems that make the daily usage of native mobile applications in Africa a challenge; for example, the size of apps and the requirement of new downloads every time they are updated, among many others.
We are seeing the best PWAs come out of India, Nigeria, Kenya, and Indonesia. Let’s look briefly at why PWAs are particularly well suited to emerging economies.
With a PWA, all the user downloads is a manifest file, which is a small text file with JSON information. You, the develop link to the manifest file from the head element in your HTML document, and browsers that don’t understand it just ignore it and show a normal website. This is because HTML is fault-tolerant. The vital point here is that everybody gets something, and nobody gets a worse experience.
Bruce Lawson — World Wide Web, Not Wealthy Western Web (Part 1)
Server side performance ideas
From a technical standpoint, we can optimize how we serve our content to users.
Using HTTP/2 (or H/2) servers, configured with SSL, is a good first step to take to make sure that we’re serving assets without bundling. This is not ideal, Sérgio Gomes has written about why we can’t stop bundling assets yet but, if you’re not going to bundle then updating to H/2 and enabling SSL/TLS us the next best thing.
The SSL/TLS bit is not optional. Most of the APIs used for PWAs, Service Workers in particular, require secure origins because of how powerful they are and the impact of potential man in the middle attacks or other kinds of spoofing
The next reasonable step is to serve your static assets through a Content Delivery/Distribution Network (CDN) like Akamai, Cloudflare or Cloudinary for media assets. These CDNs are designed to distribute your content around multiple data centers around the world and to serve the assets from the closest data center to the user’s location.
At its core, a CDN is a network of servers linked together with the goal of delivering content as quickly, cheaply, reliably, and securely as possible. In order to improve speed and connectivity, a CDN will place servers at the exchange points between different networks. These Internet exchange points (IXPs) are the primary locations where different Internet providers connect in order to provide each other access to traffic originating on their different networks. By having a connection to this high speed and highly interconnected locations, a CDN provider is able to reduce costs and transit times in high-speed data delivery.
Because a CDN serves content from the closest server to the user’s location and caches the resources it serves, users get faster downloads and quicker interactions with the content.
We can further enhance our app or site’s performance using service workers to create client-side caches off the content the user accesses… Caching is just a starting point for what we can use service workers for.
Because we manually configure all the caching routes, we have much more control over what we cache, what data we return and when do we use the network to retrieve new or updated assets. See The Offline Cookbook and The ServiceWorker Cookbook for ideas and code on how to use service workers.
I’ve left out HTTP2 push and resource loading hints because, as Jake Archibald mentions in HTTP/2 push is tougher than I thought there are enough bugs across browser implementations (mostly Edge and Safari) that make it dicey to use them reliably.