As someone whose users are almost exclusively in emerging markets and remote and underserved locations. This doesn’t even touch the surface. I’ve been in some places with a proper broadband connection in an enterprise environment and been completely unable to load lots of common web sites.
Not only that, we’re constantly developing for whatever the latest version of android and iOS, windows. A lot of the world is just getting away from Android 4.4 to be honest.
Just the same with laptops. There are a lot of 1024x768 laptops roaming around out there still, users who skip big updates because they just plain take too long to download or are impossible to download on a flaky or expensive connection. When you see those charts showing the breakdown of the market of how many people are using a specific version of an OS. A certain chunk of those people who are still running Old, insecure, feature-lacking versions that you give a chuckle or tsk tsk to, literally can’t upgrade.
People are climbing to the tops of hills near their villages to try and get enough signal to make a phone call still, we have situations where someone has to travel around weekly from town to town to sync data from users phones because the cell coverage and data have been too flaky.
Another thing to remember is that you might be costing these people real money. You will not find cheap 2gb monthly data plans in some of these places. A lot of people are using the cheapest top up cards. So when your web site eats through their data plan by serving umpteen js files and making a billion calls to external services, serving bloated Ajax payloads, tracking calls, etc… just to load your home page, you’re actually using up a finite resource for a user as they may have to travel to another town or wait ages to be able to afford another top up.
This scales out though to all aspects of a digitally connected existence. Overly designed emails loading external image assets. That png image that you never compressed properly because hey, 1mb images aren’t that bad on your fibre connection. Compression ratios for video streams, ads that stream audio on page load, ads themselves, persistent connections constantly passing data back and forth, etc…
Pages that fall apart when one of the assets times out downloading though the page is sitting there on screen.
I’m not saying that we should strip all of the good stuff we’ve managed to create, or that we should go back to the geo cities ages. Or even that we should always build for the least least least common denominator all the time, but if you’re a content producer or web app or desktop/mobile app that wants to be usable by everyone, everywhere you need to exercise a bit of common sense. If you’ve got a successful app that’s failing to pick up in some key target locales that you wanted to serve, or you have no traffic from for instance countries in the African continent then it might be worth investigating what your product operates like in those regions.
The other half of this is that our innate ability to understand the internet and how it works isn’t the norm for everyone. In the west and developed countries, we have an almost innate immediate understanding of how a piece of software or a web site works from years of exposure to software and technology. We know how a button should look, what a select field does, how urls work.
For some populations, even email is still a foreign concept. I had a user who just assumed that his first and last name @gmail.com would belong to him and he could access it because that’s how email works right?
Or had users who fill out a form and show legitimate fear about pushing the submit or save button on screen because it feels very final and they don’t know what will happen when they do it. It’s a scary door and you don’t know what’s on the other side. It’s all still very much magic.
We have so many people who don’t have email addresses themselves that we started just making up email addresses on our domain (not real accounts). A lot of users put it in as their login having no idea why that funny @ symbol is in their username.
Sorry, rant over. Just this is something that over the years has been a constant driver in the back of my head and informs a lot of my design and development patterns. And it’s more complicated than just needing to minify and gzip your stuff.
Problem is it’s really really hard to develop software to solve problems you didn’t even know existed. I’d love to make software that works for everyone but I don’t know how everyone uses their devices. I don’t know how a colorblind person sees or how a person in africa understands how to use email. And I certainly don’t have the money to visit all these people and ask them. The best I can do is build it to cover all the use cases I understand and people can send me an email or open a bug report if I missed something thats really important to them.
I’m not saying that you should build your software to meet every conceivable combination of personal IT experience, connectivity requirements, etc… far from it as that’s pretty much not feasible even for a lot of large teams. In my case, my target users are these groups specifically and I’ve seen the frustration first-hand where people have been asked for instance to install an app on their phone and because all the person has is an android 4.4 phone, the app doesn’t exist for them. Or we’ve had a user call up because their data plan is depleted and the only thing they did was browse some news sites and blogs so we have to top up their sim cards constantly.
I’m just saying, if you’ve got an app, application, web app, mobile app or whatever, and you look and see that you have a high rate of abandonment, or no installs whatsoever in a region and you’d like to have uptake in that region, you need to think about how your product would operate under those circumstances. Even large-scale enterprises are guilty of this from what I’ve seen, so it’s not just a young developer not knowing any better situation. I’ve had big corps pitch their well-developed software solutions for some of our situations and their applications fall flat on their face in the meeting because they just couldn’t deal with the network health in our locations.
If you’re happy to never address the segment of the market then don’t worry about it, but if you want a bigger piece of the pie, you don’t have to travel to Africa to identify potential problems, turn on throttling in chrome dev tools and throttle down to a 3g or lesser connection, Use a connection throttler to test how your mobile app or desktop acts when you run it. Rename your largest JS dependency to something else and see what happens to your page when you try to load it (basic simulate a timeout on a resource). Look at chromes network tab and tally up how much data actually comes into your app when you load the page. Simple stuff, basic common sense stuff.
There was another article on here a few days ago about someone who provides a service that allows people to use WhatsApp on lower-end phones through a browser and people went nuts for it. If you can work around it, you can achieve some great growth.
And I don’t just mean the African continent either, there are plenty of people in rural UK, America, Canada, South America, Europe and the Pacific that are surviving on 3g modems, tethering their cell phones, etc… I can see a major town from my house, but I can’t get any better than a dial-up connection speed on my broadband and some days I have to resort to using a 3g modem to get any kind of internet at all, I have to walk out of the house and up the road a bit to get a good cell phone signal. I can literally pull out my driveway and people have fiber to their property. There are swathes of developed countries populations which don’t have access like you would in a metropolitan environment still.
If addressing these people isn’t a concern, then don’t worry about it, well, maybe have a little common sense with using compression, clear out deprecated and unnecessary code, style assets, etc… (which does go a long way) and carry on with your life. But if you want to grow globally outside of your current market, you’ll need to adjust your thinking a little bit, set some constraints on how big you’ll allow your application to be, don’t import an entire date library just to format dates, give yourself a delay time before adopting newer things like flex-box, etc…
I remember a story from Youtube: They saw bad loading times in their stats and went on to optimize that by making Youtube more lightweight. After the optimizations the stats got even worse! However, the usage went up. A lot more people, for whom Youtube timed out, were now able to use it.
Unfortunately, Google cannot find me the original story. I believe it was some Google blog.
Even a little bit like that goes a long way, long wait times are basically standard on loading a page for some people, so when a page does actually load it’s great.
A weird instance we had once was a user that was using a 3g dongle for their data, and they were requesting a long-running process in one of the earlier versions of our system, the process would run, and they would sit there waiting for it to complete. For this user (and a few similar cases until we changed how the long-running process was called) their view of it was that it was still running hours later even though the job had finished ages before. Took forever to figure out that over his 3g dongle, the connection was getting swapped on the telecom side, when the app responded with the result, the user wasn’t there anymore even though they never lost their actual connection to the internet. The problem was there was nothing in between the user and our servers to report to the user that the request had failed because of a weird time out implemented on the telecoms side. Swapping to a hardline or office wifi and the process completed and worked fine.
I did a personal “mission” in India where having a smart phone saved my bacon. I got 2G speeds and spotty connection (in a big metropolis). Google maps and Uber mostly worked. Maps failed gracefully while Uber was a little brittle. Indian banking apps however failed miserably.
It’s clear that to have a usable system in most of the world, you must work heavily in the reliability department - doing lots of handshakes and being forgiving: if you time out a client do store your state and the client should store its state, ready to pickup where you left off even minutes after initiating a transaction.
I think the banking apps were failing because they were timing out too easily. Perhaps this is a security issue, but I’m sure you can work with that.
How fast is fast and how fast is fast enough? Terrible internet causes me acute pain all the time while traveling, but I have no idea what numbers to shoot for when developing.
A good starting point is being faster than your competitors. Depending on your industry/market that may set the bar very low or extremely high though, so YMMV.
Generally, for sites my team works on, I set targets at a minimum of Speed Index < 5000 on Slow 3G, < 3000 on Cable/DSL – using https://www.webpagetest.org/ to verify and taking the median of 5+ runs.
If you want to test a site on Slow 3G on Slow Android phone to see what a painful experience would look like, you can use https://www.webpagetest.org/easy
You can also use the Audit panel in Google Chrome’s developer tools, this integrates Lighthouse (https://developers.google.com/web/tools/lighthouse/) which includes metrics like “Time to Interactive”, “Time to First Contentful Paint” etc which are useful for determining what the experience will be for your users.
I’d just like to point out that from a business point of view, if you pay developers and product managers to think about these problematics, if they won’t help at all the growth of your product/company, then it’s “normal” and obvious that it won’t be done.
When your building a company, and aim at a market, you design things for this market (and if people could at least focus enough to do that, that would be great…). You don’t do it and you cannot do it for the whole world, that’s the hard truth.
As someone whose users are almost exclusively in emerging markets and remote and underserved locations. This doesn’t even touch the surface. I’ve been in some places with a proper broadband connection in an enterprise environment and been completely unable to load lots of common web sites.
Not only that, we’re constantly developing for whatever the latest version of android and iOS, windows. A lot of the world is just getting away from Android 4.4 to be honest.
Just the same with laptops. There are a lot of 1024x768 laptops roaming around out there still, users who skip big updates because they just plain take too long to download or are impossible to download on a flaky or expensive connection. When you see those charts showing the breakdown of the market of how many people are using a specific version of an OS. A certain chunk of those people who are still running Old, insecure, feature-lacking versions that you give a chuckle or tsk tsk to, literally can’t upgrade.
People are climbing to the tops of hills near their villages to try and get enough signal to make a phone call still, we have situations where someone has to travel around weekly from town to town to sync data from users phones because the cell coverage and data have been too flaky.
Another thing to remember is that you might be costing these people real money. You will not find cheap 2gb monthly data plans in some of these places. A lot of people are using the cheapest top up cards. So when your web site eats through their data plan by serving umpteen js files and making a billion calls to external services, serving bloated Ajax payloads, tracking calls, etc… just to load your home page, you’re actually using up a finite resource for a user as they may have to travel to another town or wait ages to be able to afford another top up.
This scales out though to all aspects of a digitally connected existence. Overly designed emails loading external image assets. That png image that you never compressed properly because hey, 1mb images aren’t that bad on your fibre connection. Compression ratios for video streams, ads that stream audio on page load, ads themselves, persistent connections constantly passing data back and forth, etc…
Pages that fall apart when one of the assets times out downloading though the page is sitting there on screen.
I’m not saying that we should strip all of the good stuff we’ve managed to create, or that we should go back to the geo cities ages. Or even that we should always build for the least least least common denominator all the time, but if you’re a content producer or web app or desktop/mobile app that wants to be usable by everyone, everywhere you need to exercise a bit of common sense. If you’ve got a successful app that’s failing to pick up in some key target locales that you wanted to serve, or you have no traffic from for instance countries in the African continent then it might be worth investigating what your product operates like in those regions.
The other half of this is that our innate ability to understand the internet and how it works isn’t the norm for everyone. In the west and developed countries, we have an almost innate immediate understanding of how a piece of software or a web site works from years of exposure to software and technology. We know how a button should look, what a select field does, how urls work.
For some populations, even email is still a foreign concept. I had a user who just assumed that his first and last name @gmail.com would belong to him and he could access it because that’s how email works right?
Or had users who fill out a form and show legitimate fear about pushing the submit or save button on screen because it feels very final and they don’t know what will happen when they do it. It’s a scary door and you don’t know what’s on the other side. It’s all still very much magic.
We have so many people who don’t have email addresses themselves that we started just making up email addresses on our domain (not real accounts). A lot of users put it in as their login having no idea why that funny @ symbol is in their username.
Sorry, rant over. Just this is something that over the years has been a constant driver in the back of my head and informs a lot of my design and development patterns. And it’s more complicated than just needing to minify and gzip your stuff.
Problem is it’s really really hard to develop software to solve problems you didn’t even know existed. I’d love to make software that works for everyone but I don’t know how everyone uses their devices. I don’t know how a colorblind person sees or how a person in africa understands how to use email. And I certainly don’t have the money to visit all these people and ask them. The best I can do is build it to cover all the use cases I understand and people can send me an email or open a bug report if I missed something thats really important to them.
RE colorblindness it’s pretty easy to test it yourself without needing a colorblind person:
I’m not saying that you should build your software to meet every conceivable combination of personal IT experience, connectivity requirements, etc… far from it as that’s pretty much not feasible even for a lot of large teams. In my case, my target users are these groups specifically and I’ve seen the frustration first-hand where people have been asked for instance to install an app on their phone and because all the person has is an android 4.4 phone, the app doesn’t exist for them. Or we’ve had a user call up because their data plan is depleted and the only thing they did was browse some news sites and blogs so we have to top up their sim cards constantly.
I’m just saying, if you’ve got an app, application, web app, mobile app or whatever, and you look and see that you have a high rate of abandonment, or no installs whatsoever in a region and you’d like to have uptake in that region, you need to think about how your product would operate under those circumstances. Even large-scale enterprises are guilty of this from what I’ve seen, so it’s not just a young developer not knowing any better situation. I’ve had big corps pitch their well-developed software solutions for some of our situations and their applications fall flat on their face in the meeting because they just couldn’t deal with the network health in our locations.
If you’re happy to never address the segment of the market then don’t worry about it, but if you want a bigger piece of the pie, you don’t have to travel to Africa to identify potential problems, turn on throttling in chrome dev tools and throttle down to a 3g or lesser connection, Use a connection throttler to test how your mobile app or desktop acts when you run it. Rename your largest JS dependency to something else and see what happens to your page when you try to load it (basic simulate a timeout on a resource). Look at chromes network tab and tally up how much data actually comes into your app when you load the page. Simple stuff, basic common sense stuff.
There was another article on here a few days ago about someone who provides a service that allows people to use WhatsApp on lower-end phones through a browser and people went nuts for it. If you can work around it, you can achieve some great growth.
And I don’t just mean the African continent either, there are plenty of people in rural UK, America, Canada, South America, Europe and the Pacific that are surviving on 3g modems, tethering their cell phones, etc… I can see a major town from my house, but I can’t get any better than a dial-up connection speed on my broadband and some days I have to resort to using a 3g modem to get any kind of internet at all, I have to walk out of the house and up the road a bit to get a good cell phone signal. I can literally pull out my driveway and people have fiber to their property. There are swathes of developed countries populations which don’t have access like you would in a metropolitan environment still.
If addressing these people isn’t a concern, then don’t worry about it, well, maybe have a little common sense with using compression, clear out deprecated and unnecessary code, style assets, etc… (which does go a long way) and carry on with your life. But if you want to grow globally outside of your current market, you’ll need to adjust your thinking a little bit, set some constraints on how big you’ll allow your application to be, don’t import an entire date library just to format dates, give yourself a delay time before adopting newer things like flex-box, etc…
I remember a story from Youtube: They saw bad loading times in their stats and went on to optimize that by making Youtube more lightweight. After the optimizations the stats got even worse! However, the usage went up. A lot more people, for whom Youtube timed out, were now able to use it.
Unfortunately, Google cannot find me the original story. I believe it was some Google blog.
Even a little bit like that goes a long way, long wait times are basically standard on loading a page for some people, so when a page does actually load it’s great.
A weird instance we had once was a user that was using a 3g dongle for their data, and they were requesting a long-running process in one of the earlier versions of our system, the process would run, and they would sit there waiting for it to complete. For this user (and a few similar cases until we changed how the long-running process was called) their view of it was that it was still running hours later even though the job had finished ages before. Took forever to figure out that over his 3g dongle, the connection was getting swapped on the telecom side, when the app responded with the result, the user wasn’t there anymore even though they never lost their actual connection to the internet. The problem was there was nothing in between the user and our servers to report to the user that the request had failed because of a weird time out implemented on the telecoms side. Swapping to a hardline or office wifi and the process completed and worked fine.
I did a personal “mission” in India where having a smart phone saved my bacon. I got 2G speeds and spotty connection (in a big metropolis). Google maps and Uber mostly worked. Maps failed gracefully while Uber was a little brittle. Indian banking apps however failed miserably.
It’s clear that to have a usable system in most of the world, you must work heavily in the reliability department - doing lots of handshakes and being forgiving: if you time out a client do store your state and the client should store its state, ready to pickup where you left off even minutes after initiating a transaction.
I think the banking apps were failing because they were timing out too easily. Perhaps this is a security issue, but I’m sure you can work with that.
How fast is fast and how fast is fast enough? Terrible internet causes me acute pain all the time while traveling, but I have no idea what numbers to shoot for when developing.
A good starting point is being faster than your competitors. Depending on your industry/market that may set the bar very low or extremely high though, so YMMV.
Generally, for sites my team works on, I set targets at a minimum of Speed Index < 5000 on Slow 3G, < 3000 on Cable/DSL – using https://www.webpagetest.org/ to verify and taking the median of 5+ runs.
If you want to test a site on Slow 3G on Slow Android phone to see what a painful experience would look like, you can use https://www.webpagetest.org/easy
You can also use the Audit panel in Google Chrome’s developer tools, this integrates Lighthouse (https://developers.google.com/web/tools/lighthouse/) which includes metrics like “Time to Interactive”, “Time to First Contentful Paint” etc which are useful for determining what the experience will be for your users.
I’d just like to point out that from a business point of view, if you pay developers and product managers to think about these problematics, if they won’t help at all the growth of your product/company, then it’s “normal” and obvious that it won’t be done. When your building a company, and aim at a market, you design things for this market (and if people could at least focus enough to do that, that would be great…). You don’t do it and you cannot do it for the whole world, that’s the hard truth.