A few years ago, I spent a few weeks driving around New Zealand’s south island. Public Wi-Fi seems mostly unavailable in the South Pacific, so I relied on a prepaid SIM card for connectivity during that trip. This shouldn’t have been particularly memorable, but, after spending hours attempting hotel bookings on sites that clearly weren’t optimized for my mobile phone, the experience is still fresh in my mind. I remember a lot of frustration, pinching and zooming to see minuscule form fields. I remember attempting to resubmit the form multiple times because I missed a field while zoomed in. I also remember this experience costing me more than just my time. We make decisions as we design and build sites. Sometimes we decide in favour of approaches that meet our needs but cause grief for our end users. Those practices need to die. Let’s talk about them.
1 SEPARATE MOBILE URLS
whether it’s m.yoursite.com, yoursite.mobi, or some other variation, having a separate URL for your mobile site is a practice that causes more harm than good. The problem is redirection. A script on your server needs to detect whether a browser is on a desktop or a mobile device. Browsers lie. (See this article: webaim.org/blog/user-agent-string-history.) When it detects a mobile device, the script kicks in and redirects to a separate URL with the same content optimized for mobile. Your search engine placement will be hurt by this. Read Google‘s article, Recommendations for building smartphone- optimized websites (netm.ag/optimised-250) and Changes in rankings of smartphone search results (netm.ag/search-250). During that redirect, any number of milliseconds will tick by as your script decides which site to direct you towards, then hands you off to the appropriate server. Longer loading times will affect your bottom line. See KISSmetrics’s infographic (blog.kissmetrics. com/loading-time). Separate URLs do enable some things that a responsive site may have a harder time accomplishing. Luke Wroblewski wrote a thoughtful article about this a few years back, titled Why separate mobile and desktop web pages? (netm.ag/ why-250). Two highlights of the article include the following points:
Smaller pages Separate mobile URLs can be an opportunity to optimize a site for mobile performance. Wroblewski mentions breaking down pages containing multiple UI components into smaller pages with a single component per page. Less content on each page means quicker load times over a slow connection. Source order with separate mobile templates, you can reorder markup to your heart’s content. Nowadays, we have other ways of reflowing source order.
You can build for smaller screens server-side with a solution like RESS (www.creativebloq.com/ responsive-web-design/getting-started-ress-5122956) or client-side with libraries like Mobify.js (www. mobifyjs.com). Ultimately, the W3C advocates its One Web philosophy of the same content at the same URL, no matter which device is used to access it. There are increasing consequences of failing to follow that approach.
02) HIGH-DENSITY AS DEFAULT
We have these new brilliantly sharp displays on our devices that make everything look amazing. So, we naturally serve the best assets we can to make our work look the best it can. Unfortunately, the increased file sizes come at a cost:
- INCREASED LOADING TIMES
Larger files take longer to load. When you consider that mobile connections are slower than desktop connections to begin with, this problem is compounded.
- HEAVIER DATA PLAN USAGE
Every country has different contract terms, but your average data plan is far from unlimited. How many web pages could you visit before reaching your cap? Now quarter that number.
- ROAMING
If a data plan’s limit is a problem, try loading a few high density images while out of the country. My roaming rates are high enough that I don’t turn on data when I travel unless I’m, say, completely lost in the middle of the night in a bad part of town.
Decide whether you’ll provide high-resolution versions on a case by case basis. Each time you create a double-size asset, you should question whether the extra quality is worth the trade-off, or whether a lower-resolution version is really that noticeable. Even better, look for places where you can save an image in vector format, or use ultra-high compression like the Retina Revolution technique.
03) DOORSLAMS
I’m certain you’ll be familiar with the effects of a doorslam. It most often happens like this: a user pulls out their phone to search for a specific term. They tap through one of the top results. Instead of seeing the information they hoped for, they’re hit with a full-screen ad for a mobile app they don’t care about. Everybody hates these. Why do they persist? This is a pretty transparent example of serving business interests over users. The business goal is getting the app on as many phones as possible. Who cares if it comes at the expense of day-to-day interaction with the site? However unintentionally, these ads send the message that you’re not confident in the experience of your mobile site. Unfortunately, we’re not always in the room when the decision is made. If you’re forced to implement a doorslam-like ad, iOS Smart App Banners (smartappbanners.com) are the least intrusive way of doing it.
04) POOR TOUCH TARGETS
Fingers are much less precise than mouse pointers, so they need bigger targets. The common recommendation for minimum size is 44px square, but that number doesn’t consider
Instead of pixels, we should be using physical dimensions to measure our targets
screen density. Mobile pixel count is all over the place. On the low end, most smartphones start at about 150dpi, and on the high end, they’re pushing past the 400dpi mark. Your 44px square measures 7.4mm on the low-DPI screen, but a tiny 2.5mm on the higher density screen. Instead of pixels, we should be using physical dimensions to measure our targets. Adult finger sizes range between 12mm and 20mm wide, but you’re able to tap targets smaller than your finger. Size and accuracy go hand in hand. The size you choose depends on how important it is to prevent errors in your users targeting. 5mm is around the size of each key on your phone’s keyboard. How often do you to rely on auto-correct to fix typing mistakes? With a three per cent error rate, 5mm seems to be the smallest size we can safely use, but error rates drop to 0.5 per cent when you scale up to 9mm. That’s probably a safer minimum for critical targets. Make sure you allow for at least 2mm between each target, especially at the smaller screen sizes. Without that minimum gap, it’s far easier to accidentally trigger the wrong target. Also consider reducing the number of targets. The size of each menu item in the first example is just a side effect of a bigger problem: trying to shove too much into a limited space. If the designers had recategorised and chosen to show fewer options, the remaining targets would have more room to breathe, and the simplified layout would reduce confusion on the part of the end user.
05) FOLLOWING WIMP CONVENTIONS
He WIMP (Windows, Icons, Menus, Pointer) user interface paradigm that Xerox pioneered decades ago has served us well, but mobile devices are really exposing its cracks. We can’t continue leaning on these tried and true UI conventions that worked so well in the past. New classes of devices demand a rethink of the basics. Multiple windows don’t make sense on a small screen. We instead use tabs as an organizational tool to present views of different content. Modern devices offer multi-tasking, but the most popular operating systems remove the need to manage windows by only ever presenting a single one at any given time. Classical pointers were on-screen symbols to represent the movement of physical devices we could control, but touchscreens have removed the need for actual devices; we have become the pointers. Mouse events have equivalents on touchscreens, but the relationships are often imprecise. For example, tapping is mostly equivalent to clicking, but double-tapping is often reserved for zooming in or out instead of opening an application. You can just forget about: hover events completely. Some upcoming CSS4 media queries will allow us to more precisely target a wider range of devices.
@media (hover)
As you may expect, the hover media query will apply a relevant style only if the device is capable of a hover event:
@media (pointer:fine)
@media (pointer:coarse)
@media (pointer:none)
The pointer query provides more information, as you’re able to distinguish between a precise pointer like a mouse, a coarse pointer like a finger, or no pointer at all like a screenreader user. Screen sizes and input devices necessarily influence another convention from the WIMP world: the menu. Web designer Brad Frost did a great job documenting some of the more common navigation patterns and how they work across screen sizes. See here: netm.ag/complex-250. But it doesn’t end at making sure the UI renders well. An implementation of a menu may have to adapt to screen real estate and input device. A great example of this is the select menu pattern, which is a popular way of shrinking down a menu with many options into a more compact space. The problem stems from how some mobile operating systems implement the select control as a half-screen overlay. Even if the item a user eventually chooses was the first one they saw, many will scroll through the entire list before making a selection. The iOS select design makes this harder to accomplish. This is only the tip of the iceberg. Our inputs and form factors are only getting more diverse, so we have to continuously rethink our existing user interface conventions.
