hostmonster-Host Unlimited Domains on 1 Account   coolhandle offering reliable webhosting since 2001
Unlimited Hosting Space - FREE Site Builder   Smart Website Solutions for Your Small Business=

How To Poison The Mobile User

How To Poison The Mobile User

One of the most popular children’s television heroes here in the Czech Republic is The Little Mole1, an innocent, speechless and cheerful creature who helps other animals in the forest.

TV heroes often fight against people who destroy their natural environment. When watching The Little Mole with my kids, I sometimes picture him as a mobile website user. Do you want to know why?

We, as web designers, often treat our users the same way the “bad guys” treat The Little Mole, especially on mobile websites.

One episode of the series is particularly dramatic. An old man tries to get rid of the mole in the garden by any means and eventually tries to poison him. Web designers do the same thing when they make it difficult to use the mobile version of a website and try to “poison” the user, eventually making them leave the website.

So let’s be a little sarcastic today and try to poison the mobile user. How does that sound? Just follow my instructions.

Let’s make a slow website, disable zooming, hide the navigation and fill up the page with fixed-positioned elements. I’ll bet the poor mobile user won’t be able to survive this.

1. Make The Website Load Slowly Link

Making the website load slowly is the best weapon against the mobile user. Can the visitor go to and return from the post office before the website has finished loading? Then you’re doing a great job! You are poisoning the mobile user effectively.

Now, let’s be serious. The transmission speed of mobile networks is slow, and even though speeds are increasing to 3G and 4G, the networks aren’t everywhere2, and they just can’t compete with wired ones.

Various test and surveys show that the website speed has a significant impact3 on conversions and a website’s overall effectiveness. The user shouldn’t have to wait more than a couple of seconds for a website to render, even when using an EDGE connection.

Moreover, don’t forget that website speed is one of the criteria4 that Google considers for search results and AdWords campaigns. Therefore, it affects not only conversions but also whether users will land on your website at all.

The solution is quite simple: Think about speed when you are developing a website’s concept. Start with a performance budget5.

Optimizing speed is not that complicated. Let me share with you some best practices from Google6:

Don’t have time to read this now? I completely understand. Save the text for later. Fortunately, tools are available to tell you what is wrong with your website. First, test your website with PageSpeed Insights16, and then continue to WebPagetest17.

The user will never come back.

It is true that various studies on carousels do not explicitly say they are inappropriate. However, carousels are complicated both in implementation and for the user experience. So, using them is risky.

image alt text18
Nike’s carousel (left) does not make it clear that the content continues to the right. Best Buy’s (right) does it better: Subsequent items are visible, and therefore it is evident you can scroll to the right. (View large version19)

It is highly probable that, by using carousels, you will be hiding some content, instead of promoting it. According to some surveys, the vast majority of users see only the first image20, and banner-based carousels are usually just ignored because of “banner blindness.”

If you plan to use a mobile carousel21, make sure it meets the following criteria:

  • Don’t use the carousel just as eye candy or to hide unnecessary content.
    Carousels are great at advertising secondary content that is related to the main content.
  • Use the first slide to announce the other slides.
    The main purpose of that first slide is entice the user to view the second and third slides.
  • Make the navigation usable on small phones.
    Those small dots used as navigation on the desktop do not count as “usable” on mobile phones!
  • Make sure custom gestures don’t conflict with default browser gestures.
    Are you using the swipe gesture? Make sure it does not conflict with a built-in browser gesture.
  • Don’t slow down the website.
    This has to do primarily with data demand and implementation of the carousel.
image alt text22
Newegg’s carousel (left) represents a conventional approach. BH’s (right) is a good example, saving vertical space and enticing the user to browse additional slides by showing the next one. (View large version23)

3. Hide The Menu Under A Hamburger Icon Link

Make the navigation easily accessible? Come on, get serious! You could end up with thousands of users.

When you hide the menu on a website, people will stop using it. In a recently published study, Nielsen Norman Group found24 that hidden navigation on mobile has a negative effect on content discoverability, task completion and time spent on task.

If there is something important in the navigation, and you can display it, do it. If you can’t show the whole menu, then simplify it, or at least show the important parts of it. For this reason, I tend to recommend the “priority plus” navigation pattern25.

image alt text26
If the navigation also carries content, always display at least a few items. (View large version27)

What if you can’t show the important items? OK, then, hide it under a hamburger icon, label it “Menu”28, and make sure users can use the website without the menu.

4. Always Rely On The Swipe Gesture Link

Swipe away all users with the swipe gesture.

I regard less common gestures to be risky for a mobile UI, for two reasons29:

  • Custom gestures might conflict with the browser’s default gestures.
    If your carousel supports swipe gestures, for example, the user might accidentally perform an “edge swipe” (a gesture very similar to a regular swipe), which some mobile browsers interpret as a command to navigate the browsing history.
  • Less common gestures are unknown to many users.
    Therefore, you’ll have to teach the user. This makes sense if we are talking about daily-used apps, but not about websites.

Using a carousel does not have to be such a problem. However, I have seen news websites support swipe gesture for navigation between articles. For the user, this is unusual and confusing.

The swipe gesture is not the only problem here. Tapping the bottom part of the Safari browser on iOS will reveal a hidden menu. Therefore, if you stick navigation elements at the bottom, the user might be forced to tap twice30.

Before using any uncommon gesture, test that it doesn’t conflict with any browser’s built-in gestures.

5. Make All Tap Targets Nice And Small Link

One millimeter is good enough.

OK, let’s be serious. Are your tap targets big enough that a basketball player could easily hit them with their thumb?

In his book Designing For Touch31, Josh Clark refers to a study by Steven Hoober and Patti Shank32. The researchers found that, if placed at the center of the mobile screen, a tap target can be as small as 7 square millimeters; however, if placed at the top or bottom, it should be at least 11 square millimeters.

However, millimeters are rather impractical for web use. We use pixels, right? So, how do we deal with the variety of DPIs on mobile devices? Probably to most readers’ surprise, Josh Clark says in his book:

Nearly all mobile browsers now report a device-width that sizes virtual pixel at roughly the same pixel density: 160 DPI is the de facto standard for touchscreen web pixels.

Again, all you need to do is set the viewport meta tag correctly:

meta name="viewport" content="width=device-width, initial-scale=1"

There is one more step: Use em or rem units that best suit the responsive design. The default font size for most browsers is 16 pixels, so we can use the following conversion:

/* 7mm = 44px = 2.75rem */
.touch { height: 2.75rem; }
/* 11mm = 69px = 4.3125rem */
.touch-big { height: 4.3125rem; }

That’s it, folks. Don’t forget to provide a fallback for old browsers33. And if you are into details, I suggest you buy Josh’s book34.

6. Make It Responsive, But Only For Certain Resolutions Link

Force users to leave your website. Make them go buy a phone that has the “correct” resolution.

We are faced with an enormous variety of screen resolutions35 on mobile devices. Before, only the Android platform was affected, but now Apple devices are36, too.

image alt text37
Even if your website is not “meant” for mobile devices, there is no reason not to let mobile users get a sneak peek. Some websites don’t adapt to particular viewport sizes. What a shame! (View large version38)

We can’t assume that smartphone screens are around 320 pixels, that tablets are around 768 pixels and that desktops are over 1024 pixels. A page should seamlessly adjust to screens that are 768 pixels and lower.

So, what resolutions should we take into account? All of them, my friend.

In my development career, I have been testing responsive websites from 240 to approximately 2600 pixels wide. I admit that making all sizes look perfect is sometimes not humanly possible, but the bottom line is that the layout should not fall apart — assuming your intention is not to scare away mobile users.

Like most of you, I simply expand the browser window (or use the developer tools’ responsive mode) from the smallest size to full width. It is a kind of “Hay! mode”, found in the Brad Frost’s testing tool39.

Also, Don’t Change the Design When the Phone Switches from Portrait to Landscape Mode Link

I think that users expect the same, or at least a very similar, look when browsing a website, regardless of how they hold their phone. I remember one of my lecture participants telling me a story. When his company redesigned a website, a lot of people started calling the support desk. They were all complaining about a particular error: The website menu was disappearing. After a while, they discovered that these were tablet users. When they viewed the website in landscape mode, the menu was there. If the tablet was rotated into portrait mode, the menu was hidden under a “hamburger” icon.

7. Don’t Make Phone Numbers Tappable Link

Make the user angry. Prevent them from calling phone numbers directly from the website.

Contacting you can be a piece of cake for mobile users. Just set phone numbers as links that open a phone call40. It is similar to activating FaceTime, SMS and Skype on Apple devices.

We have a problem, though. People usually can’t make calls from a desktop browser41. However, instead of ignoring phone links, desktop browsers open an incomprehensible dialog box that invites the user to select an app to make the call. In most cases, no such app is available.

Dear friend, we don’t want to poison desktop users either. So, on this rare occasion, I recommend using device detection and inserting an active link for mobile users only.

In the HTML, the phone number would be inactive. We’ll just wrap it in a span tag and apply Javascript later:

Phone: span class="phone-number"123456789/span

Using jQuery and the isMobile42 detection library, we’ll replace the element with a phone-number class and a link:

if(isMobile.phone) {
  $('.phone-number').each(function() {
    $(this).replaceWith(
      $('a href="tel:' + this.innerHTML + '"' + this.innerHTML + '/a')
    );
  });
}

On smartphones, the markup looks like this:

Phone: a href="tel:123456789" class="phone-number"123456789/a

8. Disable Zooming Link

Disable the zoom if you really want to stick it to users. It’s inhumane — and very effective.

But seriously, by disabling zooming, you are not only making life a little more complicated for users with poor eyesight. Even users with good eyesight43 zoom on mobile devices, for various reasons:

  • to see an image up close,
  • to more easily select text,
  • to magnify content with low contrast.

Zooming is actually disabled on a sizeable proportion of mobile websites. Consider the importance of viewing image details in an online store. Zooming is disabled on 40% of e-commerce websites44 tested by the Baymard Institute. Mind-boggling, isn’t it?

Just as desktop users can’t do without the back button and scrolling, so too do mobile users need zooming.

The WCAG’s accessibility guidelines tell us that users must be able to increase text size by 200%.45

Sure, there are cases when you have to disable zooming — for fixed elements, for example. But zooming is sometimes disabled by accident, such as by insertion of the wrong meta viewport tag. The one below is the only correct one, whereas incorrect tags contain parameters such as maximum-scale=1 and user-scalable=no.

meta name="viewport" content="width=device-width, initial-scale=1"

9. Set * { user-select: none }, And All Is Good Link

Some users will visit your beloved website and copy all of the text. This is shocking and must be stopped.

Dear friends, setting the user-select property46 to none can be useful, but only in parts of an interface that you expect users to interact with, where selection might do no good.

Therefore, I recommend using user-select: none for the following elements only:

  • icon navigation items,
  • carousels with overlaid text,
  • control elements such as dropdowns and navigation.

Please, never ever disable the selection of static text and images.

10. Load Web Fonts Incorrectly Link

If the user lives to see the page load, kill them for good by making the font flicker or hide the content completely.

Using web fonts is not wrong, but we have to make sure they are the first elements of the website to load. Some browsers wait for web fonts to load before displaying the content. This is known as a flash of invisible text (FOIT). Other browsers (Edge and Explorer) show a system font right where you least want it, known as a flash of unstyled text (FOUT).

There is a third possibility, flash of faux text47 (FOFT). Here, content is rendered with a regular cut of the web font, and then bold and italic cuts are displayed right after that.

image alt text48
FOUT in practice: Showing system fonts is better than showing a blank screen while the web fonts load. (View large version49)

My projects are usually content-based websites, so I prefer to display the content as quickly as possible using a system font (FOUT). This is when I like Microsoft browsers. I also use a small library named Font Face Observer50. Let’s look at the code. First, the JavaScript:

var font = new FontFaceObserver('Webfont family');
font.load().then(function () {
  document.documentElement.className += ' webfont-loaded';
});

And here is the CSS:

body {
  font-family: sans-serif;
}

.webfont-loaded body {
  font-family: Webfont Family;
}

Every website requires something different. Refer to Zach Leatherman’s “Comprehensive Guide to Font-Loading Strategies51.”

11. Clutter The Page With Social Media Buttons Link

If you can’t poison them with your own concoction, use your neighbor’s.

Facebook, Twitter and Google buttons are uncomfortable for mobile users, for two reasons:

  • They download a huge amount of data and slow the loading and rendering of websites.
    Tests show that when the official social sharing buttons are used, visitors will download 300 KB more over more than 20 requests.
  • They are usually useless. Social sharing is often integrated in the operating system.
    A Moovweb study carried over the course of one year across 61 million mobile sessions showed that only 0.2% of mobile users do any social sharing.

The vast majority of social buttons are useless, even on desktop. Sharing is particularly useless in an online store, because a low sharing count is demotivating52 for the buyer. But let’s not go there. We are trying to poison the mobile beast.

If you don’t want to poison the mobile user but you need social sharing buttons, try using social sharing URLs53 or a plugin such as Social Likes54, which implements them with less impact on loading speed.

12. Faulty Redirection From Desktop To Mobile Link

A “killer” developer who has an m-dot version of a website has one more way to poison the user. Hooray!

We see faulty redirects55 on practically every other website with an m-dot version.

The correct implementation looks something like this:

  1. If a mobile visitor goes to www.example.com/example, the server detects their device and redirects them to m.example.com/example (not to m.example.com). The same happens on a mobile version accessed from a desktop.
  2. If that URL does not exist, then leaving the user on the desktop version is better than redirecting them to the m-dot home page.
  3. Let search engines know about the two versions of the website by using link rel="alternate" or by indicating it in the sitemap.xml file. A detailed guide56 is in Google’s help section for webmasters.

The ideal solution is a responsive website that serves the same URLs to all devices. An m-dot version of a website increases development and maintenance costs. Also, it is not the only type of website that can be optimized for a strong smartphone UX or for mobile network speed.

Read what Karen McGrane says in her book Going Responsive57, referring to a study by Doug Sillars58, the technical lead for performance in ATT’s Developer Program:

It’s a myth that the only way to make a fast-loading site on mobile is an m-dot. Good coding and decision-making practices can serve up responsive sites that are every bit as fast as any other method.

Now, the only thing left to do is hide what is not necessary — the content, for example.

13. Hide The Content Well Link

Hide content from the mobile user. They don’t need it anyway.

Whether you like it or not, people visit websites to see the content. Yes, we are forced to live among such spiteful creatures.

image alt text59
The user seeks content. Give it to them as quickly as possible. Then, you can force them to download an app or submit their contact details. (View large version60)

Unfortunately, a lot of websites hide content, for reasons I don’t understand. Perhaps the content is not worthwhile, but I find that hard to believe. Numerous elements can cause content to be hidden:

  • Cookie bar
    Some European websites are obliged to show the unfortunate cookie consent61 notification. And we can do nothing about it. However, this doesn’t mean that a cookie bar should be fixed and take up half the screen.
  • Online chat window or newsletter subscription ad
    Positioning elements as fixed is very unfortunate on mobile devices. You are hiding content that the user came to see and are displaying content that they are not interested in. Using these elements is OK, but avoid fixing their position on mobile devices.
  • App-download interstitials
    These are painful. Some websites invite you to install the accompanying app, instead of showing you the content. But users came to see the website! Instead, use smart app banners62 on iOS or native app install banners63 on Android to advertise your native app.

Google has decided64 that, effective January 2017, overlapping content on mobile websites will be penalized:

[Content that is visually obscured by an interstitial] can frustrate users because they are unable to easily access the content that they were expecting when they tapped on the search result.

Pages that show intrusive interstitials impair the user experience more than pages whose content is immediately accessible.

For the record, Google will not penalize websites that show interstitials, such as cookie bars or age confirmations on adult websites.

How Many Mobile Users Have You Poisoned Today? Link

That’s about it. Now, let’s be serious. There wasn’t anything “new” above, was there?

All the more reason to be sorry that the vast majority of responsive websites poison the mobile user.

Let’s summarize the critical information in a short checklist:

  • Does your website render quickly enough on mobile?
    Do less important elements block more important ones? Have you chosen the optimal strategy to render web fonts? Are third-party plugins (such as for social media) slowing down the website?
  • Are you hiding content?
    Are fixed elements getting in the way? Are you hiding content for particular resolutions or in landscape or portrait mode?
  • Is the UI mobile-friendly?
    Are the tap targets large enough? Are complex UI elements such as carousels implemented correctly on mobile? Are phone numbers clickable? Does content selection remain enabled? Do you make navigation visible wherever possible?
  • Do you respect the native browser?
    Have you disabled zooming by accident? Do you support gestures that conflict with browser defaults?
  • Is your redirection implemented correctly (if you’re using an m-dot version)?

Be kind to mobile users. Do not be the wicked old man who tries to get rid of The Little Mole in his yard. Do you want to know how the fairy tale ends? The Little Mole survives, laughs at the old man and moves to another garden.

(da, yk, al, il)

Footnotes Link

  1. 1 https://en.wikipedia.org/wiki/Mole_(Zden%C4%9Bk_Miler_character)
  2. 2 https://twitter.com/firt/status/757587453234454528
  3. 3 https://wpostats.com/
  4. 4 https://adwords.googleblog.com/2008/06/landing-page-load-time-now-affects.html
  5. 5 http://danielmall.com/articles/how-to-make-a-performance-budget/
  6. 6 https://developers.google.com/speed/docs/insights/rules
  7. 7 https://developers.google.com/speed/docs/insights/OptimizeImages
  8. 8 https://developers.google.com/speed/docs/insights/MinifyResources
  9. 9 https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery
  10. 10 https://developers.google.com/speed/docs/insights/BlockingJS
  11. 11 https://developers.google.com/speed/docs/insights/PrioritizeVisibleContent
  12. 12 https://developers.google.com/speed/docs/insights/Server
  13. 13 https://developers.google.com/speed/docs/insights/EnableCompression
  14. 14 https://developers.google.com/speed/docs/insights/LeverageBrowserCaching
  15. 15 https://developers.google.com/speed/docs/insights/AvoidRedirects
  16. 16 https://developers.google.com/speed/pagespeed/insights/
  17. 17 http://www.webpagetest.org/
  18. 18 https://www.smashingmagazine.com/wp-content/uploads/2016/09/image_0-opt.png
  19. 19 https://www.smashingmagazine.com/wp-content/uploads/2016/09/image_0-opt.png
  20. 20 https://erikrunyon.com/2013/07/carousel-interaction-stats/
  21. 21 https://www.smashingmagazine.com/2015/02/carousel-usage-exploration-on-mobile-e-commerce-websites/
  22. 22 https://www.smashingmagazine.com/wp-content/uploads/2016/09/image_1-opt.png
  23. 23 https://www.smashingmagazine.com/wp-content/uploads/2016/09/image_1-opt.png
  24. 24 https://www.nngroup.com/articles/hamburger-menus/
  25. 25 https://css-tricks.com/diy-priority-plus-nav/
  26. 26 https://www.smashingmagazine.com/wp-content/uploads/2016/09/image_2-opt.png
  27. 27 https://www.smashingmagazine.com/wp-content/uploads/2016/09/image_2-opt.png
  28. 28 http://exisweb.net/mobile-menu-abtest
  29. 29 https://medium.com/@kollinz/misused-mobile-ux-patterns-84d2b6930570#.1qxxllypd
  30. 30 https://www.eventbrite.com/engineering/mobile-safari-why/
  31. 31 https://abookapart.com/products/designing-for-touch
  32. 32 http://www.elearningguild.com/insights/index.cfm?id=174action=viewonly
  33. 33 https://github.com/robwierzbowski/grunt-pixrem
  34. 34 https://abookapart.com/products/designing-for-touch
  35. 35 http://screensiz.es/phone
  36. 36 https://twitter.com/LiquidLightUK/status/644827716739592192
  37. 37 https://www.smashingmagazine.com/wp-content/uploads/2016/09/image_3-opt.png
  38. 38 https://www.smashingmagazine.com/wp-content/uploads/2016/09/image_3-opt.png
  39. 39 http://bradfrost.com/demo/ish/
  40. 40 http://www.mobilexweb.com/blog/click-to-call-links-mobile-browsers
  41. 41 https://css-tricks.com/the-current-state-of-telephone-links/#article-header-id-1
  42. 42 https://github.com/kaimallea/isMobile
  43. 43 http://adrianroselli.com/2015/10/dont-disable-zoom.html
  44. 44 http://baymard.com/blog/mobile-image-gestures
  45. 45 https://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-scale
  46. 46 https://css-tricks.com/almanac/properties/u/user-select/
  47. 47 https://www.zachleat.com/web/foft/
  48. 48 https://www.smashingmagazine.com/wp-content/uploads/2016/09/image_4-opt.png
  49. 49 https://www.smashingmagazine.com/wp-content/uploads/2016/09/image_4-opt.png
  50. 50 https://github.com/bramstein/fontfaceobserver
  51. 51 https://www.zachleat.com/web/comprehensive-webfonts/
  52. 52 https://vwo.com/blog/removing-social-sharing-buttons-from-ecommerce-product-page-increase-conversions/
  53. 53 https://github.com/bradvin/social-share-urls#google
  54. 54 http://social-likes.js.org/
  55. 55 https://developers.google.com/webmasters/mobile-sites/mobile-seo/common-mistakes#faulty-redirects
  56. 56 https://developers.google.com/webmasters/mobile-sites/mobile-seo/separate-urls
  57. 57 https://abookapart.com/products/going-responsive
  58. 58 http://trentwalton.com/2014/07/17/m-dot-or-rwd/
  59. 59 https://www.smashingmagazine.com/wp-content/uploads/2016/09/image_5-opt.png
  60. 60 https://www.smashingmagazine.com/wp-content/uploads/2016/09/image_5-opt.png
  61. 61 https://www.cookiechoices.org/
  62. 62 https://developer.apple.com/library/ios/documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html
  63. 63 https://developers.google.com/web/updates/2015/03/increasing-engagement-with-app-install-banners-in-chrome-for-android#native
  64. 64 https://webmasters.googleblog.com/2016/08/helping-users-easily-access-content-on.html
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top

Tweet itShare on Facebook

Article source: https://www.smashingmagazine.com/2016/10/how-to-poison-the-mobile-user/

Tags:


Submit a Review




If you want a picture to show with your review, go get a Gravatar.

1&1 has shared hosting and dedicated hosting solutions for every budget and free domains with all hosting packages!  StartLogic - Affordable hosting: Free setup/domain, unlimited emails, PHP, mySQL, CGI, FrontPage. As low as $3.95/month
Cloud ecommerce platform delivers more traffic, higher conversion and unmatched performance

© Copyright 2008 Tyconia International, Inc. All Rights Reserved.