Top

The Web and Cuban Technology Limitations

March 21, 2016

Recently, I had the privilege of visiting family members who still reside in Cuba and got to see where my father and his family lived until the early 1960s. It was a truly eye-opening trip on a number of levels and one I am unlikely ever to forget. Though it was an incredible journey through my family and cultural history, it was also a bit of a digital nightmare. I returned to the United States with a renewed appreciation for Web development and what it means to truly consider the user’s experience.

Using the Internet in Cuba

While I was in Cuba, I kept friends and family back home abreast of what I experienced on my trip via email and Facebook. Thankfully, most of the hotels where we stayed made this relatively easy by providing a Computer Lab This was generally just a single, old computer and what I could generously describe as “Internet access.” I paid $5 for 30 minutes of access, which might sound like a decent deal, but the Internet speed felt slower than dialup. So just sending a quick update easily cost me 10 minutes of time. This was painful to say the least.

Okay, to be fair, Internet speeds in Cuba are 140 kilobits per second (Kbps), which is, technically, faster than the typical dial-up speed of 56 kilobits per second. For context, Cuba’s only connection to the global Internet is a shared 379 megabits-per-second fiber line. So the entire country is essentially sharing just a third of a single Google Fiber connection.

The average weight of Web sites has gradually increased as our Internet speeds have increased. In 2014, the average page weight increased by 15%, from 1,701 to 1,953 kilobytes. Thus, it would take 10 to 15 seconds to load the average Web page in Cuba—again, not quite dial-up speed. Globally, users start to squirm at around the three-second mark. And let’s not forget that the mobile networks available around Cuba today are mostly 2G.

JavaScript-Heavy Web Applications

Some of the tools whose daily use I take for granted in the US became a chore to use on Cuban networks. For example, I hadn’t realized just how much JavaScript Facebook deploys until I tried posting my first update. Facebook uses JavaScript to provide all kinds of cool features—for example, recognizing the names of people in posts, lazy-loading posts as we scroll, time-stamping posts, and instant notifications.

Unfortunately, such heavy, pervasive use of JavaScript meant that the computers I used in Cuba had trouble keeping up, so simply typing anything into the update text box would freeze the entire computer. As a workaround, I typed my update into the URL bar, then pasted it into the update text box, which let me bypass some of the JavaScript running on the page. I won’t even get into my inability to load images in posts on my newsfeed.

Thankfully, Facebook recently began work on an internal initiative dubbed 2G Tuesdays to raise awareness of its products in countries that have lower Internet speeds, such as India. As a test, they asked employees to voluntarily use Facebook and Facebook apps such as Messenger at 50 kilobits per second. That’s a speed that would make anyone impatient—one at which it could take two minutes to load an average Web page.

As a consequence of this testing, Facebook engineers have subsequently made remarkable improvements to accommodate the millions of Facebook users on slow Internet connections, who have previously suffered through a poor user experience. For example, they have developed a system that lets the site detect a user’s connection speed. Once the site has determined that a user’s connection speed is slow, the content it loads favors status updates and links rather than videos and photos. Plus, the site prioritizes loading content at which the user is currently looking rather than lazy loading content further down the page.

Contrast this to Gmail, which was totally on point with its user experience. Gmail’s basic HTML view was a lifesaver, letting me quickly read and write email messages with no fuss. Gmail isn’t nearly as media heavy as Facebook. I can imagine the time it would have taken to load so many images—including background images, avatars, and icons—every time I read an email message, then returned to my inbox. Just the load times would have eaten through my entire 30-minute time card!

Life-or-Death Impacts of Poorly Optimized Web Pages

Obviously, what I’ve described so far are issues of convenience, but poorly optimized Web experiences can truly have life-or-death impact. Near the end of our trip, Tropical Storm Chantal headed toward Cuba. I needed to load the National Hurricane Center’s Web site to check the progress of the storm and determine whether we should continue our trip or head home early. Thankfully, at that time, the Web site was pretty lightweight, with the exception of the images. So, while the shell of the site loaded quickly, I remember sitting in the Computer Lab praying the image shown in Figure 1, which was only about 70 KB, would load before my time ran out.

Figure 1National Hurricane Center Web site, July 10, 2013
National Hurricane Center Web site, July 10, 2013

If it didn’t load in time, I’d get booted off the computer and would have to start all over again. Thankfully, the image loaded in the last five minutes of my remaining time. This was a critical piece of information—not only for me and my travel plans, but also for my family living in the area of Cuba that would have to weather the storm. Yet the one image on the page that actually mattered took several minutes to load. Thankfully, we were able to continue our trip because the storm dissipated, but the difficulty of trying to get that information was staggering.

Serving Users Despite Low Connection Speeds

As you can see from the examples I’ve discussed, every site has specific requirements to ensure users can access them on computers with low connection speeds. Facebook must load relevant content and let users post easily. Gmail needs to load email messages and let users write and send them. The National Hurricane Center must quickly load relevant data to help users make informed decisions about their safety. Each of these sites requires a unique solution to accommodate users’ needs, so there is no quick fix to the problem of slow Internet connections.

In the future, even more people will have access to the Internet in Cuba, but not necessarily a faster Internet. Pay-as-you-go Wi-Fi hotspots have popped up around the country, including in Havana, but connectivity is pricey, costing approximately 10% of an average Cuban’s monthly income for just for one hour of usage. The government is committed to increasing Internet usage from 5% to 50% over the next 5 years.

The technology industry in the US has an opportunity to help improve online services in our third-closest neighboring country, as relations between Cuba and the US continue to normalize.

But the opportunity to serve a brand-new population of users isn’t limited only to Cuba. Facebook and Google have initiatives to bring the Internet to the entire world, but for them to be effective, their sites must provide content to which these new users can actually get access in an efficient way. The lack of high-speed Internet access in a number of countries around the world means we need to be more cognizant of page-load times when developing Web sites, including limiting our use of JavaScript, optimizing images, and providing simple views of pages that load more quickly for users on slow connections. Ensuring this different form of Web accessibility for users will require greater diligence than guidelines currently suggest because—beyond serving just those with disabilities—we need to be inclusive in serving the needs of all users.

This sounds great and kind of exciting, right? There’s a new challenge we must all overcome and to which we must find smart solutions. How can we best approach this new realm of accessibility when sites differ so much and need custom solutions? Developers of particular Web sites must figure out how best to accommodate their users.

The best way to understand the specific accommodations you’ll need to make for users on your site would be to follow Facebook’s example and use a connection speed–throttle tool to demonstrate how users would experience your site. I don’t mean simply using a throttle tool when doing quality-assurance testing on the site. I mean you should use a throttle tool when actually using the site as if it were part of your daily life. Doing so would give you a much better feel for any inconsistencies in the user experience, while also allowing you to test the site’s quality in the process. Both the Chrome and Firefox browsers have throttling tools built into them, so you can easily select an appropriate connection speed and test your site’s performance. You can also use tools such as deelay.me, but having throttling built into your browser means you can use and test the site more seamlessly.

So the next time you’re planning to deploy a Web site, build some time into your development schedule for 2G days. Make sure that, if there is any chance your target demographic might be in another country—even for travel—users would have an experience that is worth their time and money. 

UX Strategist at 352 Inc.

Gainesville, Florida, USA

Michelle BrownsteinMichelle works as a UX Strategist at 352 Inc., a digital product–development agency. Even before Michelle began working in the Web industry in 2008, she applied usability principles to everything in her life—long before she learned the term user experience. Michelle has worn many digital hats over the years—from interactive design and coding to UX research, strategy, and usability. Backed by an MS in Psychology, Michelle has helped clients such as Cummins Engines, YouCaring, and Cox Automotive create lasting connections with their customers.  Read More

Other Articles on Global User Experiences

New on UXmatters