Summarized using AI

Mobile Rage - What causes it & how to fix it.

Lori M Olson • April 23, 2012 • Austin, TX • Talk

The video titled 'Mobile Rage - What causes it & how to fix it,' presented by Lori Olson at Rails Conf 2012, delves into the frustrations that users experience when accessing web applications on mobile devices, a phenomenon termed 'Mobile Rage.' Olson begins by explaining the growth of mobile usage and how traditional web development practices often fail to address mobile needs, leading to user frustration. The key topics discussed include:

  • Definition of Mobile Rage: This intense frustration arises when mobile applications do not perform as expected. Its prevalence is growing among smartphone and tablet users as their expected standards for performance increase.

  • User Experience Issues: Olson outlines the top areas causing 'Mobile Rage,' such as:

    • Slow Loading Times: An alarming statistic reveals that 74% of users abandon a mobile site that takes over five seconds to load. Loading JavaScript and bloated CSS are major culprits.
    • Website Structure: Older websites often lack mobile optimization, resulting in dead ends or poor user navigation due to outdated frameworks like Flash.
    • Advertising: Ads can disrupt user experience, especially if they are not designed for mobile environments. Olson advises against intrusive pop-ups that complicate navigation.
    • Navigation: Usability is crucial; links and buttons need appropriate sizes and spacing to be easily clickable.
    • Forms: Poorly designed forms can deter user engagement, with many sites neglecting to utilize mobile-friendly input types, creating frustrating experiences.
  • Strategies for Improvement: Olson advises developers to adopt a 'mobile-first' approach and embrace responsive design. This involves optimizing JavaScript loading, utilizing appropriate CSS structures, and ensuring forms are user-friendly by making use of custom keyboards for each input type.

  • Conclusion: There is an urgent need to address mobile optimization in web development to avoid losing users. Making simple updates can alleviate much of the frustration users experience. By improving mobile usability, developers can enhance customer satisfaction and, ultimately, business outcomes.

Mobile Rage - What causes it & how to fix it.
Lori M Olson • April 23, 2012 • Austin, TX • Talk

Most of us have been there. That website you want to use, from your mobile device, that just refuses to cooperate. From the Flash-only, to the can't f**king log in, to the redirect-to-mobile-and-stay-there sites, there's more than enough websites out there to invoke Mobile Rage.

Although we all know that the best mobile development strategy is "mobile-first", we also all know how many sites and applications out there were designed and built by people who didn't imagine how fast mobile would take over.

Come learn about the common mistakes most people make for mobile, and some of the simple solutions you can use to help reduce Mobile Rage, without having to do a complete rewrite.

RailsConf 2012

00:00:24.859 Okay, let's get started! Welcome to Mobile Rage. My name is Lori Olson, and my company is The Windex Group. I'm an independent contractor, and I've been using Rails since 2005, around version 0.3. It's definitely not surprising that most of the work I've been doing is in the oil and gas area, as I'm from Calgary.
00:01:12.140 When we talk about mobile, I’d like to share a bit of my mobile gadget history. I’ve been using mobile gadgets since the days of Windows CE. If any of you remember that, I had a NEC Mobile Pro; it was such a cool little device when it came out. After that, I progressed through Palm devices, the Treo smartphones, and then, of course, I moved on to iPhones and iPads.
00:01:21.320 So, what exactly is Mobile Rage? We’re going to cover these topics today to ensure everyone has a shared understanding. What is Mobile Rage? Who experiences it? Why has it become such a serious problem? And I’ll provide some strategies, techniques, and pieces of code that will help alleviate some of this rage.
00:02:01.070 Mobile Rage is that feeling of intense frustration that you get when you're trying to use a web application on your mobile device, and it just doesn't work the way you expect it to. Some people might call it mobile frustration or annoyance, but I like to call it Mobile Rage.
00:02:08.570 So who experiences Mobile Rage? Yes, it's smartphone and tablet users, and yes, it is the fastest growing segment of the web consumer market. I'm not talking about the dumb phone users; T9 predictive text is its own source of rage, but now the number of smartphones being sold has exceeded the number of desktop and laptop computers combined. The mobile market is growing exponentially.
00:03:42.849 In Canada, overall smartphone ownership has increased by 13% in the last six months, meaning more than one-third of Canadians own smartphones now. I don't know if that's a direct parallel to the States, but it’s probably close—definitely a market you can't afford to ignore. So, why are things so bad? Think about how long the web has been around. I built my first website in late 1994. There are many websites that have been around for many years because they work.
00:05:00.189 Rails applications have been developed for eight years now, but mobile was barely on people’s radar back then. The iPhone didn’t even exist in 2005, and concepts like the iPad were unknown to most. So how did we get to the point where mobile causes such rage?
00:06:00.940 I think the answer for us Rails developers is pretty simple. Rails developers primarily work on new, greenfield projects. Those of you who have been developing Rails for several years cannot tell me you don’t have to support older applications. How many of you support a Rails application that was written more than three years ago? Yeah, about half. It is straightforward for greenfield applications. Mobile-first designs are now the best practice; design apps for mobile first, then worry about the desktop version.
00:07:03.519 We have responsive design, which creates a perfect world where one app magically transforms according to the device you’re using. But let's be honest; it’s not all rainbows and unicorns because otherwise, we wouldn’t have so many people experiencing Mobile Rage. Let's talk about the standard problem areas that lead to Mobile Rage. I've classified these areas as: landing pages, advertising, navigation, and forms.
00:09:55.560 When users land on a site, their primary complaint is that it's slow to load. Over the past couple of years, the percentage of users expecting applications to load just as quickly on mobile devices as on desktops has increased dramatically. For example, the percentage of users who will abandon a site after waiting five seconds for it to load has risen from 20% two years ago to 74% last year. That’s a scary statistic. I’m certainly in that 74%; if a page takes too long to load, I'm often tempted to just give up.
00:10:28.801 This graphic highlighting user reactions to slow load times is eye-opening. Among those users, 23% will curse at their phone, 11% will scream at it, and 4% might even throw their phone. It’s alarming to realize that almost 40% of people are reacting with real measurable rage towards slow-loading pages.
00:12:09.130 So what causes slow load times? A prime culprit is JavaScript loading, especially libraries like jQuery. If you design with mobile in mind, consider using micro frameworks as alternatives to jQuery. Another significant factor contributing to slow load times is how JavaScript is loaded on the page. It is now best practice to load JavaScript at the very bottom of the body element so that some visual content can render while the rest loads. Then, users perceive that your site is faster, even if it technically isn’t.
00:13:39.049 Bloated CSS files can also slow down load times. Often, CSS files from years ago may have evolved due to developers adding to them without regard for the original structure. This can cause significant bloat over time. Additionally, image loading is another area that is becoming increasingly problematic, especially as higher resolution images, such as those optimized for retina displays, become more common.
00:14:21.840 Fortunately, Rails has solutions for these issues through the asset pipeline introduced in Rails 3.1. However, if you're still running pre-Rails 3.1 applications, you may want to consider upgrading to benefit from these enhancements.
00:15:31.609 Beyond slow load times, we need to address poor landing strategies. Flash-only websites, for instance, have become obsolete, as flash is no longer supported on mobile devices. Websites built entirely in Flash can’t function on mobile, leading to frustration. Users may be greeted with screens that provide no useful information or offer misleading instructions, further aggravating their experience.
00:17:01.690 Instead, a simply designed landing page that provides at least some usability or a relevant message will keep users from getting too frustrated. The full site option can sometimes be sufficient if it loads well; however, many still use JavaScript to redirect mobile users to a limited-function mobile site, causing confusion and annoyance. If this mobile detection fails, users can end up in a mobile site that doesn’t function properly, which can lead to even more frustration.
00:19:25.117 Next, consider whether it’s necessary to ignore mobile entirely. Many sites create apps that users are expected to download for every single site they visit. This leads to even more frustration, as users may not wish to install numerous apps for sites they visit infrequently. We need to rethink our strategies here.
00:20:23.740 Another area where we encounter Mobile Rage is advertising. While ads are a source of revenue for developers, they often annoy users. We need to incorporate ads in a way that doesn’t irritate users or take them away from their intended content. For example, popups or light boxes can be especially infuriating on mobile, as links can be too small to click, leading to accidental navigation away from the desired content.
00:21:58.399 Navigation is another crucial area where size matters. The size of buttons and links is crucial to mobile usability. Small targets can frustrate users; ample spacing can help ensure users don’t accidentally click on the wrong link.
00:23:15.460 Lastly, forms are often a major source of frustration on mobile devices. Common tasks such as signing in or signing up are often poorly optimized for mobile. Many apps fail to use mobile-friendly features like the proper keyboard for email inputs or auto-correction features that can render a form nearly unusable based on the keyboard’s behavior.
00:24:49.520 These issues can cause customers to abandon the signup process before completion. Simple fixes, like using proper input types for fields, can greatly enhance usability. There are plenty of small adjustments we can make that will keep users from leaving due to frustration.
00:25:50.630 For user profile editing, the same applies. Autocomplete and the right keyboard types should be standardized to improve user experience. The lack of proper mobile input types for numerical entries is another area where improvements can be made.
00:27:20.560 In retrospect, there will be more and more mobile users than desktop users sooner than we think. If we don’t address these older applications that fail to function correctly on mobile, or if existing applications aren’t designed with mobile in mind, it can lead to significant rage among users.
00:28:20.540 In conclusion, applications that induce Mobile Rage will ultimately harm your bottom line. We must prioritize mobile and implement responsive designs. If a complete rewrite isn’t viable, addressing smaller issues can still delight users and enhance usability.
00:29:10.360 By focusing on these relatively easy fixes, we can make users happier, which benefits everyone in the long run.
00:30:12.410 Thank you for your attention. Remember, we can significantly reduce Mobile Rage by simply thinking about mobile-first designs and listening to user input.
Explore all talks recorded at RailsConf 2012
+65