Mobile Web Problems and How to Avoid Them
Two years ago Jen Simmons (@jensimmons) and I made a site called WTF Mobile Web, a Tumblr which highlights the frustrations mobile web users regularly experience. While the site is a bit cheeky, the goal isn’t to cut anybody down, but rather demonstrate the challenges web creators are faced with when delivering their experiences to the plethora of desknots now accessing the Web.
So without further ado, here’s two years of the most common mobile web problems and what you can do about them.
- Denying Access
- URL Redirects
- Performance
- Making contextual assumptions
- App Doorslams
- Confusing Sites and Apps
- Design
Denying Access
The Problem
Being denied access to an experience is easily the biggest problem mobile web users face. They come to websites on their mobile devices looking for information, looking to solve problems, looking to complete tasks, looking for answers. And they don’t get it. That’s a huge issue.
There are many flavors of denying access to mobile users:
Coming soon!
“Mobile version coming soon!” “Almost there!” and other nonsense phrases litter these experiences. Offering these empty words doesn’t do much to help a user who is unable to achieve their immediate goals.
Screen size
Oh you have a small screen? Too bad! Denying users an experience because of the size of their screen or the orientation in which they hold their device is a bizarrely bad idea.
Browser support
“Looks like you’re using an unsupported browser, even though you’re on a perfectly capable Android browser.” In an age of UA sniffing gone wild, mobile browsers often catch the short end of the stick.
Flash
Yes, Flash objects are still causing issues for mobile browsers, especially with regards to video content.
Digital Rights Management
DRM is still a thing. I especially love how YouTube blames their users for the company’s decision to not make videos containing copyrighted songs available on mobile devices.
A whole bunch more
Cookies, unsupported formats, advanced functionality, and a whole lot more contribute to mobile web users’ collective frustration.
The Solution
The solution is to achieve content parity. Give people what they want regardless of how they access the Web. Take Stephen Hay’s advice:
Just make quality, relevant content with appropriate tasks, and offer all of these to all users, […] then make it easy for the user to decide what it is they want to do.
- Don’t make content assumptions based on device or context. Don’t assume that mobile users only want “on the go” content. Mobile users will do anything and everything a desktop user will do, provided it’s presented in a usable way.
- Desktop-only content is better than no content at all—Don’t have all your content optimized for mobile? That’s OK. No need to apologize for it, and certainly no need to deprive users your content to tell them that the content isn’t mobile-optimized. Users can pinch-and-zoom or awkwardly scroll back and forth, and while that’s not as good as having an optimized experience, you’ll end up with less complaints so long as users can get what they came to the site to do.
- Ditch Flash—This shouldn’t be too shocking, but you should probably be weening yourself off of Flash.
- Don’t penalize users for screen size, device capabilities, settings, resolution, etc—Use sound progressive enhancement techniques to support as many environments as possible while still optimizing for the most capable.
- Plant a flag in the sand. It’s understandable to not have all of your content mobile optimized right this second. Things take time. But it’s important to have a long-term strategy for making all of your content accessible on the whole slew of present and future web-enabled gizmos.
Further Reading
- Content Parity
- Great Works of Fiction Presents: The Mobile Context
- Mobile > Local
- Content Strategy for Mobile
URL Redirect Fails
The Problem
Until recently, the most common mobile web strategy was to create a separate mobile-only website (or m. site). Having two separate sites means having to point the right device classes to the right experience. In theory, that sounds manageable. In practice, however, it’s a nightmare that barely anyone gets right.
URL redirect fails come in a few different awful flavors:
m. Links on Desktop
This happens all the time. Step 1: Someone shares a URL from their mobile device. Step 2: Someone sees that link and clicks on it. Step 3: they see a mobile site rendered on their desktop browser. This obviously shouldn’t happen, but even massive sites like Wikipedia and Youtube are guilty of this.
Redirect to Homepage
It’s awful when you’re trying to find some crucial information only to be redirected to the mobile site’s homepage.
The Solution
There are a few solutions to URL redirect issues.
- Maintain a single codebase. One of the more invisible advantages of responsive design is that you don’t have to jump through all these URL-redirect nightmare hoops.
- Canonical URLs. Sites like Buzzfeed serve a separate mobile template, but the URL stays consistent (so no m. preceding the URL). This ensures that all that link juice stays under the same roof.
- Initiate a future-friendly device strategy. Yes, it’s currently possible to keep up with the flood of web-enabled gizmos in a device database. But these solutions are quickly becoming untenable. Start to plan for a more maintainable web strategy that doesn’t involve updating a database every time Samsung craps out a new device (which happens about every 30 seconds).
Further Reading
- Common Mistakes in Smartphone Sites (Faulty Redirects)
- W3C Mobile Web Best Practices: Thematic Consistency of Resource Identified by a URI
- URL Design
Performance
The Problem
Performance matters. A lot. But it’s often neglected. One of the main reasons I feel performance is neglected is because performance is invisible. That’s why there aren’t very many performance-related screenshots on WTF Mobile Web. But we’ve all felt the pain of slow performance on our mobile browsers. And huge websites not only test our patience, they’re also extremely expensive for users on data plans.
The Solution
I’ve previously written about how to prioritize performance for responsive designs, so in a nutshell we should treat performance as design, set performance budgets (and stick to them), lazy/conditionally load content, test often and follow sound performance best practices.
Further Reading
- Performance As Design
- Prioritizing Performance in Responsive Design
- Performance is money, part 1: the end-user’s wallet
- Improving UX Through Front-End Performance
- Setting a Performance Budget
- What are Responsive Websites made of?
Making contextual assumptions
The Problem
Bad things can happen when we make assumptions about users’ browser, screen size, environment, settings, orientation, etc. Web experiences are extremely fluid and are viewed in many different settings and scenarios.
The Solution
Don’t make assumptions. Avoid instructions like “tap the menu button in the upper right corner of your browser” because you simply don’t know what browser or app the user is visiting the website from. Yes, it’s frustrating to accept that we can’t control our users’ environment, but once we come to terms with that fact we’re able to create stronger, more agnostic solutions.
App Doorslams
The Problem
This problem is extremely obvious. Instead of taking users to the content they’re after, organizations slap an interstitial ad or popup for their native app, hoping to increase their app downloads and justify the hefty price they paid to make said native app.
There are many issues with this strategy. First of all, it’s annoying as hell. But going the app route is tremendously inefficient. With the Web, there are simply two steps:
- Select link
- View content
Whereas going the app route goes something like this:
- Select link
- Select interstitial to download app
- Open app store app
- Select ‘Install app’
- Enter password
- Wait for app to install
- Open app
- Learn new interface, look for search bar
- Search for the original content from link
- Select link from search results
- View content
I’ve begun this process before only to eventually forget what I was trying to check out in the first place.
The Solution
Don’t do this. Google will punish you. Instead, think of more subtle ways to promote your app. Less intrusive banners across the top or bottom don’t hit users over the head with marketing and can be easily skimmed over. For iOS, consider looking into Smart Banners, which provide a more native way of handling app promotion.
Further Reading
- I Don’t Want Your Fucking App
- Lots of appblock examples on WTF Mobile Web
- The User’s Choice?
- Linking Mobile Web & Native App Experiences
- Common mistakes in smartphone sites (App download interstitials)
Confusing Sites and Apps
The Problem
I have a problem with app lust. App lust is when organizations salivate over apps, so when they finally have a chance to do something for mobile, they immediately think “WE GOTTA HAVE AN APP!” They typically look something like this guy:
The result of this thinking applied to the Web is often disastrous. I feel like I see more spinners on my phone’s browser than in this music video.
The best example of a site trying to be an app is Fast Company’s staggeringly bizarre mobile web experience. Enjoy:
All that just to put some words on a page.
The Solution
The Web isn’t a native app, and just because a Web experience can be viewed on mobile devices doesn’t mean that it needs to be app-like. Embrace the Web for the unique medium it is instead of trying to create a poor man’s native experience.
Further Reading
Design
The Problem
Lots of design decisions can influence the usability of a mobile web experience. Here are just a few examples:
Fixed Positioning
Fixed positioning can wreak havoc on mobile browsers. Support is shaky, even on the latest versions of the most popular mobile platforms. But space is already a premium on small mobile screens, and by fixing elements to the page you’re losing valuable real estate that should be reserved for core content. It’s also worth noting that apps and browsers add their own (often multi-level) chrome to the experience, eating away at your content’s real estate.
Overlays
Overlays are annoying. They also tend to have positioning issues, which cause for some very undesirable results. Do you really want to risk users not being able to close an overlay and get to your real content?
And more
Text legibility, indecipherable images, and just straight up gross design all impact the effectiveness of a design.
The Solution
- Avoid fixed positioning for a cleaner, more stable experience.
- Avoid popups and overlays. Your users will thank you for it. Not only are they bullshit, but they also introduce potential usability issues where users are unable to close the overlays.
- Simple is usable. Think twice before adding bells and whistles to your Web experiences. I’m not saying there isn’t room to make things beautiful, rich and complex. But all of these examples demonstrate that the effectiveness of a mobile Web experience has so much to do with basic accessibility and usability than it does about bells, whistles and purely aesthetic decisions.
Further Reading
Less WTF, More FTW
This post has been a long time coming. I started it in spring of 2012. It took Google publishing their thoughts to kick me into high gear and finish it.
The good news is that we’re seeing progress. Of course there are still problems and there always will be, but combing through 2 years of posts, we’re seeing less hideous mainstream mobile web experiences.
Again, I want to stress again that the point of WTF Mobile Web isn’t to be a jerk and make fun of mobile websites, but rather to highlight the problems we’re all facing as creators for this new medium. We need to know what problems we’re facing in order to get better.
It’s been great watching mobile web design transform from a complete afterthought to the center of everyone’s Web strategy. That’s nothing but a good thing. Here’s to progress!
38 Comments