June 1, 2015
  |   Blog, WEM / WCM

3 Common Problems with Desktop Breakpoints

Today is the day, you’ve finished developing your brand new responsive roll-out with perfected, market researched breakpoints, at 480px, 768px, and 1024px. Only, you’re getting reports back from your testing team warning that the site isn’t performing as expected on tablets.  Which breakpoint do you look at?
The answer is, all of them.  Recently we covered why thinking about specific breakpoints as tablet or phone is wrong.  To review why, let’s use some real world examples.  Several 7” tablets, like the Visual Land Prestige (one of the more popular low-cost tablets), have a 480px resolution in portrait mode.  Others, like the Samsung Galaxy Tab 3, have a 600px resolution in portrait mode.  Then you have larger tablets with higher resolutions than some desktops, like the Kindle Fire HDX 8’9” which has a 1600px resolution in portrait mode.
Say we have one of these large resolution tablets; we’re going to hit the so-called desktop breakpoint.  Let’s look at some of the problems you may face and some potential solutions.
Problem 1: Cannot access submenus of navigation menu
On many sites at the widest breakpoint, there is a navigation menu bar at the top of the page and when the user hovers over the links, submenus appear.
Usually there’s some javascript for the menu like the following:
$(".menu-item").on("mouseover", function () { //show submenu });
Great!  Except…as shown previously, some of our touch devices are going to hit the highest breakpoint.  Problematic because expectations of touch-friendly behavior don’t change when the breakpoint changes.  Users still expect the submenu will open when the Digital Solutions link is clicked.  In reality, what often happens is the user is taken to the Digital Solutions page instead of seeing a submenu.
Solution 1.1: Remove all hover states
At all breakpoints we have a touch-friendly menu.  Clicking on Digital Solutions at desktop expands the submenu instead of taking you to a Digital Solutions page.
Solution 1.2: Detect touch device
There are many ways to do this: runtime libraries, remote services, web server modules.  For our purposes, we’re writing a simple but effective Javascript function to detect if a user is on a touch device.  I’ve included a sample way to do this:
isPageOnTouch : function(){
  return hasTouchUserAgent || hasTouchEvents;
}
hasTouchUserAgent : function() {
  return /Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini/i.test(navigator.userAgent);
}
hasTouchEvents : function() {
  var el = document.createElement('div');
  el.setAttribute('ongesturestart', 'return;');
  el.setAttribute('ontouchstart', 'return;');
  return typeof el.ongesturestart === "function" || typeof el.ontouchstart === "function";
}
Now you can change the functionality of links or other elements on your page specifically for touch devices.
if (Util.isPageOnTouch()) {
 $navigation.find('menu-item').removeClass('desktop-hover').attr('href', 'javascript:void(0)').addClass('mobile-tap');
}
Problem 2: Cannot open Tooltips
Commonly, tooltips are set up to open on hover only and contain information not present elsewhere in the content.  We still want tablet and phone users to be able to access this information.
Solution 2.1: Remove tooltips
Obvious solution, but not flexible.
Solution 2.2: Make tooltip indicator a toggleable link and close tooltip when clicking elsewhere
Clicking on the tooltip text “Tooltip” opens the tooltip, clicking outside the tooltip closes it.  If the tooltip previously also acted as a hyperlink, it no longer does so.  Tooltip still appears on hover for desktop users.
Solution 2.3: Detect touch using Util function and add touch-friendly UI
if (Util.isPageOnTouch()) {
 $(this).find('tooltip-link').addClass('tooltip-icon');
 $(this).find('tooltip-box').addClass('tooltip-close');
}

This allows for the tooltip text to remain a hyperlink if desired and provides a better indication of how to close the tooltip on touch devices.
Problem 3: Some images still look blurry on higher resolution devices
Actual                                                                  Nice To Have
Solution 3.1: Deliver a different image and css using media queries
Previously we covered how device pixel ratios greater than 1 indicate that we have more physical pixels available to us than our viewport indicates.  With media queries, you can tell the browser to load a higher resolution image, even if the logical resolution used by your other media queries is small.  We use multiple media queries here to ensure browser compatibility.
@media  only screen and (-webkit-min-device-pixel-ratio: 1.5),
only screen and (   min--moz-device-pixel-ratio: 1.5),
only screen and (     -o-min-device-pixel-ratio: 3/2),
only screen and (        min-device-pixel-ratio: 1.5),
only screen and (min-resolution: 192dpi) {
   .img-div {
      background-image: url('img/higherres.png');
   }
}
Solution 3.2: Deliver a different image using picture element or image srcset attribute
These tags can ask the browser to decide which image to load based on resolution, estimated image size, and device pixel ratio.  However, be aware that only the newest browsers support these tags and no version of Internet Explorer supports them at all.
With these problems solved, you should be well on your way to making a highly usable mobile experience.  Even without these specific problems, the determinants described here should enable you to better shape your mobile experience across all breakpoints and devices.  Do yourself a favor, keep the pain points out of your breakpoints.
New to responsive design or evaluating your mobile strategy?  Contact us to learn more about how we equip our clients to deliver a world-class experience on all platforms.

Subscribe to Our Newsletter

Get the latest insights from Blue Acorn iCi

Let's build something together.