Saturday, March 28, 2015

Browser Input Events: Can We Do Better Than The Click?

Responding to user input is arguably the core of what we do as interface developers. In order to build responsive web products, understanding how touch, mouse, pointer and keyboard actions and the browser work together is key. You have likely experienced the 300-millisecond delay in mobile browsers or wrestled with touchmove versus scrolling.
In this article we will introduce the event cascade and use this knowledge to implement a demo of a tap event that supports the many input methods while not breaking in proxy browsers such as Opera Mini.


Three primary input methods are used to interact with the web today: digital cursors (mouse), tactile (direct touch or stylus) and keyboards. We have access to these in JavaScript through touch events, mouse events, pointer events and keyboard events. In this article we are primarily concerned with touch- and mouse-based interactions, although some events have standard keyboard-based interactions, such as the click and submit events.
You have very likely already been implementing event handlers for touch and mouse events. There was a time in our not too distant pass when the recommended method was something akin to this:
$('a', ('ontouchstart' in window) ? 'touchend' : 'click', handler);
Microsoft has led the charge to create a better, future-facing event model with the “Pointer Events” specification. Pointer events are an abstract input mechanism that is now a W3C recommendation. Pointer events give the user agent (UA) flexibility to house numerous input mechanisms under one event system. Mouse, touch and stylus are all examples that easily come to mind today, although implementations extending to Myo or Ring are imaginable. While web developers seem to be really excited about this, not all browser engineers have felt the same. Namely, Apple and Google have decided not to implement pointer events at this time.
Google’s decision is not necessarily final, but there is no active work being done on pointer events. Our input and usage of pointer events through polyfills and alternative solutions will be part of the equation that could eventually tip the scale the other way. Apple made its statement against pointer events in 2012, and I am unaware of any more public response from Safari’s engineers.

The Event Cascade

When a user taps an element on a mobile device, the browser fires a slew of events. This action typically fires a series of events such as the following: touchstarttouchendmouseovermousemovemousedownmouseupclick.
This is due to backwards compatibility with the web. Pointer events take an alternative approach, firing compatibility events inline: mousemovepointerovermouseoverpointerdownmousedowngotpointercapturepointerupmouseuplostpointercapturepointeroutmouseoutfocusclick.
The event specification allows for UAs to differ in their implementation of compatibility events. Patrick Lauke and Peter-Paul Koch maintain extensive reference material on this topic, which is linked to in the resources section at the bottom of this article.
The following graphics show the event cascade for the following actions:
  1. an initial tap on an element,
  2. a second tap on an element,
  3. tapping off the element.
Please note: This event stack intentionally ignores where focus and blur events fit into this stack.

Applying the Event Cascade

Most websites built today for the desktop web “just work” because of the efforts of browser engineers. Despite the cascade looking gnarly, the conservative approach of building for mouse events as we previously have will generally work.
Of course, there is a catch. The infamous 300-millisecond delay is the most famous, but the interplay between scrolling, touchmove and pointermove events, and browser painting are additional issues. Avoiding the 300-millisecond delay is easy if:
  • we optimize only for modern Chrome for Android and desktop, which use heuristics such as <meta name="viewport" content="width=device-width"> to disable the delay;
  • we optimize only for iOS, and the user does a clear press, but not a quick tap and not a long tap — just a good, normal, clear press of an element (oh, it also depends on whether it’s in a UIWebView or a WKWebView — read FastClick’s issue on the topic for a good cry).
If our goal is to build web products that compete with native platforms in user experience and polish, then we need to decrease interaction response latency. To accomplish this, we need to be building on the primitive events (down, move and up) and creating our own composite events (click, double-click). Of course, we still need to include fallback handlers for the native events for broad support and accessibility.
Doing this requires no small amount of code or knowledge. To avoid the 300-millisecond (or any length of) delay across browsers, we need to handle the full interaction lifecycle ourselves. For a given {type}down event, we will need to bind all events that will be necessary to complete that action. When the interaction is completed, we will then need to clean up after ourselves by unbinding all but the starting event.
You, the website developer, are the only one to know whether the page should zoom or has another double-tap event it must wait for. If — and only if — you require the callback to be delayed should you allow a delay for the intended action.
In the following link, you will find a small, dependency-free tap demo to illustrate the effort required to create a multi-input, low-latency tap event. Polymer-gestures is a production-ready implementation of the tap and other events. Despite its name, it is not tied to the Polymer library in any way and can easily be used in isolation.
To be clear, implementing this from scratch is a bad idea. The following is for educational purposes only and should not be used in production. Production-ready solutions exist, such as FastClick, polymer-gestures and Hammer.js.

The Important Bits

Binding your initial event handlers is where it all begins. The following pattern is considered the bulletproof way to handle multi-device input.
 * If there are pointer events, let the platform handle the input 
 * mechanism abstraction. If not, then it’s on you to handle 
 * between mouse and touch events.

if (hasPointer) {
  tappable.addEventListener(POINTER_DOWN, tapStart, false);
  clickable.addEventListener(POINTER_DOWN, clickStart, false);

else {
  tappable.addEventListener('mousedown', tapStart, false);
  clickable.addEventListener('mousedown', clickStart, false);

  if (hasTouch) {
    tappable.addEventListener('touchstart', tapStart, false);
    clickable.addEventListener('touchstart', clickStart, false);

clickable.addEventListener('click', clickEnd, false);
Binding touch event handlers could compromise rendering performance, even if they don’t do anything. To decrease this impact, binding tracking events in the starting event’s handler is often recommended. Don’t forget to clean up after yourself and unbind the tracking events in your action-completed handlers.
 * On tapStart we want to bind our move and end events to detect 
 * whether this is a “tap” action.
 * @param {Event} event the browser event object

function tapStart(event) {
  // bind tracking events. “bindEventsFor” is a helper that automatically 
  // binds the appropriate pointer, touch or mouse events based on our 
  // current event type. Additionally, it saves the event target to give 
  // us similar behavior to pointer events’ “setPointerCapture” method.

  if (typeof event.setPointerCapture === 'function') {

  // prevent the cascade
  // start our profiler to track time between events
  set(event, 'tapStart',;

 * tapEnd. Our work here is done. Let’s clean up our tracking events.
 * @param {Element} target the html element
 * @param {Event} event the browser event object

function tapEnd(target, event) {
  unbindEventsFor(event.type, target);
  var _id = idFor(event);
  log('Tap', diff(get(_id, 'tapStart'),;
  setTimeout(function() {
    delete events[_id];
The rest of the code should be pretty self-explanatory. In truth, it’s a lot of bookkeeping. Implementing custom gestures requires you to work closely with the browser event system. To save yourself the pain and heartache, don’t do this à la carte throughout your code base; rather, build or use a strong abstraction, such as Hammer.js, the Pointer Events jQuery polyfill or polymer-gestures.


Certain events that used to be very clear are now filled with ambiguity. The click event used to mean one thing and one thing only, but touchscreens have complicated it by needing to discern whether the action is a double-click, scroll, event or some other OS-level gesture.
The good news is that we now understand much better the event cascade and the interplay between a user’s action and the browser’s response. By understanding the primitives at work, we are able to make better decisions in our projects, for our users and for the future of the web.
What unexpected problems have you run into when building multi-device websites? What approaches have you taken to solve for the numerous interaction models we have on the web?

Additional Resources

Friday, March 27, 2015

Help Your Content Go Anywhere With A Mobile Content Strategy

You’ve put a lot of thought, time and effort into creating great content, and you want users to have a great experience with your content. While you might have created the best content in the world, you don’t get to choose how users access it. That’s why it’s important to make sure your content works beautifully on every platform and device, desktop, mobile or something else entirely.
Before you panic, I’m not advocating that you create individual content strategies for each device or network that your content is published to. That would be crazy, and it wouldn’t necessarily work better for your users.
It’s not because you wouldn’t do a good job — it’s because it would be impossible to plan and keep up with special content strategies for every device that exists now (not to mention ones that haven’t been invented yet).
While there’s no magic bullet to make sure your content is publishable and useful on every device, you can change the way you think about, plan for and create content so that it can go anywhere it needs to go.
Developing a mobile content strategy isn’t just about making content look as good on phones and tablets as it does on the desktop. As Sara Wachter-Boettcher writes in her book, “Content Everywhere“, It’s about creating portable, flexible content structures that go wherever your users are, without sacrificing quality. It’s an intimidating task, but not impossible. We’ll start with an example, then cover some of the things you can do to make your content more flexible and accessible.

First, An Example: How NPR Learned To COPE

National Public Radio’s (NPR) core product has long been high-quality audio journalism. But because audiences don’t solely rely on their radio for news, NPR needed a content strategy that would allow it to reach a larger audience by publishing stories to multiple platforms. It needed a way to expand its radio stories with photos, videos, audio and text and get them to readers, no matter what devices they were using. They also needed to be efficient and cost-effective and make it easy for journalists to publish their stories. So, it developed a content strategy that would ensure that its stories would work well on every device without their having to create new publishing platforms for each type of device or having to duplicate every story for each platform.
The key to the strategy was to create “display-agnostic” content structures that allow journalists to COPE — create once, publish everywhere. In NPR’s new strategy, journalists file their stories once to a CMS. Each story published to the CMS has common elements — titles, categories, tags, captions, etc. — that can be shown or hidden depending on the device and that is distributed via an API. This way, NPR’s designers can change the content’s presentation for each platform without sacrificing quality or requiring the editorial team to publish stories multiple times.
Here’s a small example of how it works. Check out one story about Downton Abbey from NPR’s Monkey See blog. The story was written, edited and then published to NPR’s CMS. But because of NPR’s COPE model and APIs, it displays a little differently on different screen sizes.

Looks good, right? Let’s break it down by the elements in the desktop excerpt:
  • categorization (of the Monkey See section)
  • headline
  • excerpt
  • a few links to related tags (to the right)
  • image
  • image caption (hidden behind that blue button)
  • image credits (also hidden behind the blue button)
  • You’ll notice it’s pretty much the same, but with a few small differences:
  • While the category is still there, the related tags aren’t used.
  • The image credit is visible right below the image, while the caption is still hidden behind the button.
So, the journalist published the story once, and the same content is presented, but some of its elements are left out or rearranged to accommodate for the smaller screen.
In order to create a content strategy that works for you and that goes wherever your users are, you have to stop thinking about devices. Instead, start working to create content that has structure, even as it takes on different forms.

Content Modeling: A Difficult, Time-Consuming And Incredibly Necessary Process

Before you can build an effective content strategy, mobile or otherwise, you have to know exactly what you’re working with. That’s where content models come in — they’re a way to give your content an organizational structure without defining its form, and they’re very important to your strategy’s success.
Trust me, content modeling is something you want — no, need — to do, not because it’s a fun time necessarily, but because doing it early has the potential to save you a ton of time, money and heartache later. Doing content modeling early, before you get into the design and development process, is much better.
Raise your hand if your design team has ever spent weeks or months on a really lovely design for desktop and mobile, only to show it to the client for review and realize that you haven’t accounted for content types that need images or video or some other crucial element. That’s the worst, right? By spending a little time on content modeling, you’re reducing the risk of that happening, while also making your designers and developers’ lives easier. Content modeling isn’t difficult, but it takes some time and effort.
Let’s say you’re working on a website geared to home cooks. Your team is ready to start working on a new mobile content strategy. Before diving into your strategy, though, you need to get your team together for a content modeling session.
A content modeling session is easy to set up. You’ll just need to get a few key stakeholders together around a whiteboard for an hour or two (though, don’t be surprised if it takes longer). There’s no limit to how many people you should invite to the content modelling session, but don’t let it get too big. Include a few of the people who will be creating the content — they’re the ones who will be dealing with the content the most — as well as anyone charged with setting standards, goals and direction for the brand.
Start by looking at the website’s existing content types. What kinds of stories, blog posts or other content types are being created? List each content type and the elements it includes, like photos, captions, body copy, headlines, etc. Don’t forget to include things like newsletters, podcasts, listings and events — the point here isn’t to do this quickly, but to be thorough. For our cooking website, two of the website’s content types might be recipes and ingredients.
Once you’ve got a list of content types, break them down by element. You’ve established that two of the content types are recipes and ingredients. These two content types are related (recipes consist of ingredients, and ingredients can be tied to specific recipes), but each includes its own unique set of elements.

After you’ve listed each existing content type and its elements, think about what content types you’d like to be able to create in future. For example, do you want to go beyond recipes and ingredients and create sets of seasonal dishes? Or is your business model shifting to include notable chefs or contributors, who will need to be featured. Nothing is off limits — think about your business goals, editorial goals and audience’s needs.

Once You’ve Got Models, Start Building Them Out in the CMS

Once you’ve got your content model in place, start setting up a CMS that will help you COPE.
Every CMS is a little different, but in most cases you won’t need to create an entirely custom CMS to support your new content strategy. In most cases, you can bend your existing CMS to your will by creating page types, post types, custom fields and field sets that make it easier to create and display content. You can tie field sets to page and post types, which will make it easier for your content creators to add all of the necessary information.
For example, you might set up a page type in your CMS for each recipe and include these fields:
  • ingredients list (linking each ingredient to its ingredient page);
  • cooking time;
  • categories (like season or course — think appetizers, desserts, etc.);
  • introductory copy about the recipe;
  • recipe instructions;
  • tags;
  • author (which could possibly include fields for the author’s name, a head shot and a short bio).
Once you know which elements make up each content type and have accounted for them in your CMS, you’ll be able to COPE. You’ll have a flexible content structure that allows you to publish each recipe or ingredient once, even though it might be presented differently on each platform. You can then work with your designers and developers to figure out which elements should appear when.

Understand How Your Content Will Be Used

Ultimately, we don’t get to choose when someone decides to use the content we create or which platform they use it on (but, oh, the world would be a much simpler, if less interesting place, if we did). So, why think about use cases? Because our job is to make our content accessible and useful to all users, no matter when or where it’s being used.
Super-smart content strategist Karen McGrane puts it this way:
People use every device in every location, in every context. They use mobile handsets in restaurants and on the sofa. They use tablets with a focused determination in meetings and in a lazy Sunday morning haze in bed. They use laptops with fat pipes of employer-provided connectivity and with a thin trickle of data siphoned through expensive hotel Wi-Fi. They use desktop workstations on the beach—okay, they really only use traditional desktop machines at desks. You’ve got me on that one.
Going back to the recipe website, it has a ton of possible use cases. You may have users who:
  • spend time browsing the website for recipes on their desktops and planning their menu before going to the grocery store;
  • pick up an interesting ingredient at the store and pull up your website on their phone to learn more about it and to see what recipes it could be used in;
  • call on Google Glass to find a recipe on their way to the store;
  • prop their tablets up in the kitchen like a cookbook;
  • ask an audio interface to read a recipe to them step by step.
What do all of these users have in common? Each one of them deserves to have a great, complete experience with your content.
“But wait!” you might say. “We’ve got a ton of data showing that our users use our website in this particular way on this particular device.” That may be mostly true, but you can’t always be absolutely positive. That’s why the best solution is to make all of your content available and easily accessible across all platforms.
Such accessibility doesn’t mean sacrificing the user experience, though, nor does it mean that the presentation of your content must be identical on phones, desktops and tablets.
Each device has its own considerations for design and user experience that your content can work within. Let’s consider some examples.
  • You might choose to highlight specific content elements on different platforms, while placing others behind a menu.
  • Or you could opt for a more visual presentation on large screens, using larger images that might not work as well on smaller screens. (For example, you might hide each section of a recipe behind a tappable button on a phone, so that users can quickly see and access the information they need.)
  • On desktop displays, you might choose to immediately show more photos of recipes associated with an ingredient to encourage further browsing.
The point is that while your content’s presentation may change, users should be able to access the same amount and quality of content from any platform.

Adapt Your Editorial Process To Your Strategy

Once you’ve done the hard work of modeling your content and thinking about use cases, you should have a pretty good idea of the content you’re working with and where it needs to go.
Before running off and firing up your CMS, you need to consider one more thing: the editorial process. Remember that content strategy is not just about structuring content for the reader, but also about making the process of creating content efficient, thoughtful and sensitive to the content’s mobility.
Your editorial team and its process are crucial to implementing your new content strategy. Your content creators are the ones who will be dealing with the new structure the most, so it’s important to understand their existing processes, any pain points they may have and any changes they’d like to see. Even if you feel pretty good about the editorial process, this is a good time to check in with the content creators to see whether they need anything to make their work easier.
Creating and implementing a flexible content strategy could also mean making some changes to the way your content is published. In a perfect world, it’ll make things easier. When you don’t have to worry about publishing each piece of content to its own platform, you’ll probably be able to streamline the editorial process. Instead of content creators having to create content in more than one place and editors having to edit for each platform, a COPE model allows the editors to edit each piece only once.
During content modeling, you may have added a few new content types or elements to the content’s structure. Don’t forget that these new pieces will need to be brought into your editorial policy. Here are a few things to consider:
  • Who is responsible for creating each piece of content? The writer, the editor or someone else?
  • Who publishes the content once it has been edited? Does the editor publish it, or do they inform the writer that it’s ready to go?
  • Who is responsible for categorizing and tagging content? Will your writers do that or your editors?
  • How will the content be created? Will the writers create content directly in the CMS, copy and paste from a document, or submit a document to an editor for publication? Given that many CMS’ allow writers to save unpublished drafts, asking your writers to create their stories in the CMS instead of in a document might not be a bad idea. This will reduce the number of steps each story goes through and will make formatting and editing easier.
Additionally, the new content structure could require changes to your editorial standards. You’ll likely have to put new guidelines in place for any new content elements you have added. This is also a good time to review existing editorial guidelines to make sure they still make sense. Think about things like the following:
  • Who will choose the photos that go with posts? Who will write the captions? Do photos have to have captions?
  • If you’ve added any new content types (for example, “chefs”), who is responsible for creating those new pieces?
  • How many categories and tags should be assigned to each piece of content? Does the writer or editor choose them? Also, who determines when it’s time to add a new post category or tag? (Personally, I recommend that editors set them in order to keep things consistent and to make sure you’re not doubling up on tags. This is especially important in content structures such as in the recipe example, which require posts to be in certain categories in order to be found.)
Before implementing your new device-agnostic content strategy, you may need to revisit your guidelines to account for things that might display differently on small screens. Headline lengths may have to be adjusted so that they don’t completely take over small screens. Also, you might have to change the guidelines on image sizes to make sure that a photo attached to a story looks just as good on large monitors as it does on tablets.
Finally, even if you feel pretty good about the editorial process, this is a good time to check in with the editorial team to see whether they need anything or whether you could implement new processes as part of your strategy to make content creation easier. To dig deeper, I highly recommend reading Sara Wachter-Boettcher’s book, “Content Everywhere“.

Final Thoughts

Remember that any new strategy is partly a learning process. And content is messy — it’s human and it’s vital, and ensuring that its creation, distribution and use go smoothly requires a lot of time, effort and coordination. As long as you’re working to make sure that every user has a great experience with your content, you’re fighting the good fight.
Use content models to understand each type of content you’re publishing and the elements it includes. Then, use post types, page types and custom fields to account for each element in your CMS. Study your users to learn how they interact with your content. Try to address their most common needs while making sure the content works well across all platforms. Adapt the process of creating content to your new strategy. Train your content creators to use the new content structures you’ve created, and put editorial guidelines and practices in place to ensure that the strategy will be implemented.
By taking the time to create content structures that can go anywhere, as well as considering use cases and tightening up your editorial strategy, you’ll be confident that the content will work, no matter who’s using it or where.
If you’ve got stories about creating mobile or device-agnostic content strategies that you’d like to share, please leave them in the comments.

Assessing Mobile Usability With Google Webmaster Tools

Back in 2013, Google officially announced that it would begin to penalize websites that provide a faulty user experience on mobile devices. Specific examples included redirecting inner URLs to a home page when viewed in a mobile version of a website, as well as showing 404 errors to people attempting to access pages on mobile.
 Toward the end of 2014, a Google spokesperson hinted that the mobile user experience would become a ranking factor. In January 2015, a number of website owners received messages warning about mobile usability issues on their websites, linking to a section of Webmaster Tools where they could review the problems.
 In this article, we’ll review how to flag mobile issues in Webmaster Tools, explain the most common issues and learn how to assess mobile usability problems on your website based on these flags. Because mobile usability has become a greater priority in Google’s ranking algorithm, ensuring an optimal mobile experience on every website has become more important than ever. See the search results below, where Google has marked a dedicated mobile website (DP Review) and a responsive website (CNET) as being mobile-friendly. The result for PC Magazine lacks this label.
 Taking a look at each URL shows us clear reasons why DP Review and CNET earned mobile-friendly labels and why PC Magazine did not and ranks below the others. Not only does the PC Mag link not go to the proper mobile version of the website (which does exist), but it also delivers a popup promotion with a tiny close button that’s awkward to tap on mobile.

Setting aside the legitimate mobile issues, not only will people drop off of your website after a poor experience, but also your organic search traffic might decline because rankings can suffer in mobile search results. On the flip side, when you do improve a problematic website, you could see a vast improvement in organic search traffic, as we’ll see in the following example.
My agency built a new website to replace one that had many of the mobile problems we’ll review in this article. The original website contained a number of Flash elements, lacked any viewport configuration, and contained tiny text and touch elements when viewed on a mobile screen. The new website was built in a responsive format, eliminating these issues. Within two months of relaunching, the website saw a 44% increase in new users from organic Google searches on mobile devices, twice the increase seen on desktop. While a number of other factors certainly played a role, such as content refinement, the fact that mobile showed such a significant increase reflects the value Google ascribes to mobile usability.

Finding Mobile Problems In Webmaster Tools

In order to review mobile issues flagged on your website, you’ll first need to install Google Webmaster Tools. While many websites already run Webmaster Tools, some do not, and so here are brief instructions to set up. Navigate to the Webmaster Tools page, and log in with your Google account. You’ll see a field to enter your URL. Then, select “Add a Site.”
Next, you’ll need to verify the website. Webmaster Tools will show the various methods of doing so, including uploading an HTML file to your website, adding a meta tag or signing into your domain name’s provider. You can also verify via Google Analytics or Google Tag Manager if either code is in place on your website and you have access to the account. If you’re running a WordPress website, a plugin such as Yoast’s WordPress SEO will allow you to verify Webmaster Tools easily by copying and pasting a number from the meta tag into a field in the plugin.
After setting up Webmaster Tools on your website, you might not see any data in the interface for a few days. Submitting a site map could speed up the process of crawling and indexing your website.
You’ll find the “Mobile Usability” section under “Search Traffic” in the left navigation bar. This will show you what errors, if any, have been found on your website. Click any of the error categories to see specific URLs flagged for each.

Google shows mobile issues in six main categories:
  • Flash usage,
  • viewport not configured,
  • fixed-width viewport,
  • content not sized to viewport,
  • small font size,
  • touch elements too close.
To fix these issues, look at the flagged URLs and determine what edits need to be made.
Regarding “Flash usage,” any Flash elements will not render properly on most mobile devices. For example, when I try to access We Choose the Moon from an iPhone, it prompts me to download Flash to experience the website. Well, I obviously can’t install Flash on my iPhone, so I can’t experience this website at all on mobile.

Fixing this problem simply means restructuring the website to not include any Flash when served on a mobile device.
“Viewport not configured” means that the website is not scaling properly to the device’s size. See the website below, parts of which are cut off in small browsers.

Use the meta viewport tag to ensure that the height and width of the website change based on the size of the phone or tablet’s screen. Inserting the following code into the head of the website will cause it to resize and rearrange elements to fit various screen sizes.
<meta name="viewport" content="width=device-width, initial-scale=1">
In this code, width=device-width will automatically size the width of the website to the size of the window in which it is being viewed. And initial-scale=1 will set the zoom level of the website to 100%, scaling the website to fill the window regardless of the screen’s size. With this attribute in place, content will reflow when the phone or tablet is flipped from vertical to horizontal orientation.
“Fixed-width viewport” refers to pages that are set up to show at a specific pixel width. This is problematic when a website does not properly scale to an unexpected screen size. So, utilizing device-width in the viewport meta tag, as in the previous example, will enable the website to scale based on any device’s screen size.

For instance, note how the navigation cuts off on the right side of Anthem’s website, shown in the screenshot above. This website includes the viewport meta tag but uses it to define a specific width.
<meta name="viewport" content="width=1100" />
Replacing width=1100 with device-width would cause the website to scale to the width of the browser, fixing the issue. Of course, the developer would likely want to address issues with how elements on the website adapt to changes in size, as well.
“Content not sized to viewport” indicates that the users with small browsers need to scroll from side to side to view elements (as in both the fitness and Anthem examples). This can prove annoying, especially on a phone. Replacing absolute positioning with relative positioning in the CSS would likely help to fix this problem. For example, note how elements in the website below are side by side in a larger browser but stack on top of each other when the browser is smaller.
 “Small font size” flags text too small to easily read on a page. This can occur both from fonts that are too small as well as from insufficient vertical spacing between text. To avoid this, Google recommends starting with a base size of 16 CSS pixels and modifying up or down from there.
 “Touch elements too close” indicates that a user might have trouble tapping a specific button, navigation element or form field if it’s too small and jammed next to other clickable elements. This problem can cause frustration because a user might select a different button than intended. For example, see how several links in the following image are stacked close together, making it difficult to select a particular one on a phone.

To fix this problem, put enough space between buttons and links so that even on the smallest devices users will not have trouble selecting one. Adequate spacing is least at least 7 millimeters or 48 CSS pixels for these elements. Tweak this spacing to ensure that users do not encounter annoyances on a mobile device. In addition, think about what elements you will actually need to show phone users. In the example shown above, these users likely wouldn’t need to see all of the links and could have a much simpler experience with a few important links.

Beware Of False Flags

In the example shown earlier, I took a closer look at URLs flagged for “Flash usage.” I found that several of these pages include blog posts with embedded YouTube videos, whose content is served within an iframe (via the default embedding code). While these videos do show up as Flash at times, such as when viewed on a desktop page, they appear in HTML5 format on phones, playing with no problem. Ironically, even though it owns YouTube, Google has not picked up on the fact that YouTube changes the format of videos served when embedded on websites, depending on the device.
So, be sure to actually check the flagged pages to see whether issues are indeed legitimate. Keep in mind that Google’s automated crawling might not always show 100% accurate results. Although you can’t keep warnings about these pages from showing up, you could select an issue and choose to recheck the live version. Over time, Google will likely refine its methods for testing to filter out false flags.

Don’t Rely Completely On Google

On the other hand, don’t expect Google to pick up all potential problems with mobile usability. Just because you don’t see any errors, your website might not necessarily appear perfectly on all mobile devices. Test your website thoroughly across multiple devices and browsers to ensure a positive experience with website speed, appearance and interactivity.
Keep an eye on mobile metrics in Google Analytics to find potential usability issues. A key report to watch is found in “Audience” → “Mobile” → “Overview,” showing data for mobile, tablet and desktop traffic and engagement. For example, watch to see whether a high percentage of users on mobile devices are bouncing, especially if this number is much higher than for the desktop. Also, look at the average session duration for mobile devices to see whether the experience seems abnormally short or long. Overly brief or lengthy time spent on a website could indicate that people are either leaving right away out of frustration or are confused, taking too long to find what they wanted.
In addition, use heatmapping tools such as CrazyEgg and HotJar to analyze website usage beyond what Google’s tools can tell you. All of these tools show how users interact with mobile specifically, including data such as where they click and how far they scroll. This data could reveal problems, such as users not scrolling all the way to the bottom on a long mobile page or not clicking buttons that appear too small on a mobile device.
For instance, based on heatmap data, we discovered that few users on phones were scrolling down to a form on a particular landing page. We then added functionality to allow users to tap a button at the top, causing the page to immediately scroll to the form. Afterward, we experienced an increase in form submissions.
Google Webmaster Tools is a helpful starting point for analyzing mobile issues on your website. If you receive warnings, don’t ignore them. Take time to look at the problems and identify opportunities to improve your website’s mobile usability. Ultimately, your goal is to make the website the best experience possible for mobile users, not just to obsess over your rankings in Google. However, Google will reward positive user experiences.

Final Notes

Wednesday, March 25, 2015

How To Keep Framework Development Simple And Bug-Free

It’s just like that for your product, too: people rely on our products to work. Bugs erode trust, which in turn loses customers. So when we began updating Foundation, a responsive CSS framework, we wanted to ensure everything worked. Thoroughly. We know that many people rely on our software for their work, and maintaining that trust is paramount.
In this article you’ll learn our methodology for testing responsively, not just on a case by case, page-from-PSD comp. See, we’ve developed a certain system to make sure that nothing’s broken at launch on different devices.
Firstly, how do we define “broken”? There are degrees of problems. Parse errors are clearly bugs. But other issues were more difficult to classify. For example, we once had a download button on a busy page that no one seemed to find. We defined this as “broken user feedback,” and treated it as a bug, even though the button worked fine.
It’s not enough to look for blatant bugs. You have to be thorough: in execution, in accountability, and in direction.

Test Ideas From The Start — Even Before Code

Long before we reach a more organized review process, we work closely with our customers to test ideas before coding them out. They’re involved from day one in a project, contributing ideas and feedback as we decide how best to solve a problem.
Remember that “broken” isn’t just about parse errors. Bad ideas and broken user flows kill a project just as much as users reporting error messages. So we start with our favorite tools: Sharpie markers and Copic shaders.
We love sketching. It’s not unusual for a designer to sketch a few hundred ideas for each user flow or view, and visit a client with 30–50 pages in hand. They’re both easy to make and to throw away. Five minutes with a marker on an idea that doesn’t work is preferable to an hour on that same idea in Photoshop.
Sharpie sketches are surprisingly useful to help us prevent problems at a high level. Especially with responsive web design, each page must have different configurations for various screen sizes, device capabilities, or other factors. A few quick drawings show:
  • What appears (or doesn’t) on each page per configuration
  • How those elements are arranged
  • Our favorite hero pic will get sized down how small on mobile devices…?
Sketching the same site at different sizes gives us a rundown of design problems before they happen, at least in the broad strokes.

Use A Visual Checklist

As designers, we’re visual people. Our engineers are also known to sketch their ideas to communicate with others. And when we create responsive designs, we tend to sketch desktop-first — it’s visual, clients get a better grasp of the structure and style, and we’ve been designing for wide screens for much longer than mobile devices. We just feel more comfortable with the process this way.
Yet mobile matters, so we found a visual way you can stay accountable to yourself: with a visual checklist. Here’s how it works.
  1. If you’re working digitally, print your work. Nothing beats a hard copy for quick, disposable edits.
  2. Circle the point of the page: A call to action, a _____, or a _____.
  3. Cross out every element — except those that paint a direct path to that circled element. For example, on a marketing site we might keep a hero image, a paragraph of descriptive text, and… that’s about it. Kill the sidebar, zap the footer, and even the navigation bar. Show no mercy. It’s only a bit of paper.
Everything that’s left are the essential elements. The core of the page.
  1. Sketch out — yes, we recommend going analog with detail-defeating Sharpie and paper — a mobile version of the page with only the essential elements you defined earlier. Lay it out with the same considerations you’d use with any design.
  2. Once you have those elements roughed out, add back the elements you previously eliminated — but support the entire site. Navigation, for example, or the link-laden footer.
The visual checklist approach is tricky to learn, and worth the effort when paring down a website for mobile devices. But it’s just the beginning. After you code up your work, it’s time to test.

Test The Execution In Real-World Conditions… Or Else

In terms of responsive web design, simply resizing your browser window doesn’t cut it beyond a quick check. To be fair, it’s a rare day when we don’t play with our browsers’ window sizes for brief glances into responsive design. But we also we test on real devices. Our design thinking process involves quick iterations with lots of feedback. Soon after we begin to code, we begin to test.

This is especially true as we work on new versions of the framework. We know that we need to support about a dozen different devices to catch the majority of use cases. While we don’t have a full-on device lab, we do test upcoming versions on about 16 devices, both iOS and Android, plus the major modern desktop browsers. Services like Litmus also play a role in our testing, though they don’t always provide that necessary hands-on experience. Pun intended.
Speaking of hardware, we also learned to test servers the hard way. Another framework we developed, Foundation for Apps, uses a command line tool for installation and updates. During development, the code worked fine in every test — well, maybe not every test, but that’s the development cycle for you.
Still, it improved. And with refinement, installing the framework became so reliable that we didn’t question it. The code just worked. Which is why, on the eve of launching it, we were shocked to discover it failed to load on our production server.
A minor difference between our development system and the live one would have spelled disaster at the last minute… except that we applied our test methodology to our products even as they move to different servers. Since then our best practice includes testing our work on live servers, but before deploying it — and certainly before announcing it.

Use A Spreadsheet Tracking System

Solving technical and design problems is hard enough without overhead, so we rely on a plain ol’ shared Google spreadsheet to keep track of what works and what doesn’t. Specifically, we track everything that can be clicked per page or view. The rules are deceptively simple.

Colored backgrounds indicate:
  • What works
  • What fails
  • What partially works
  • And what hasn’t been tested.
Every cell in the spreadsheet starts out default white. Then we color green every function that passes muster or — we admit — often red and yellow, which mean broken and questionable, respectively.
Each column describes a page or view per state — or circumstances under which each page is loaded. For example, administrators and users may see the same dashboard, but with different controls. Those are two different columns.
The spreadsheet is a great overview, but our developers use GitHub to track issues and report success. So we include GitHub issue numbers in the spreadsheet’s comments: every cell that indicates a code problem also links to the issue in GitHub. Thus our engineers, who refer to the same spreadsheet as our designers, can stay on top of issues and mark items green as they’re solved.
Over time, the spreadsheet steadily loses its red and yellow boxes in favor of green as we fix bugs. Of course, we also discover new problems, and sometimes invent new things that must be tested. Everything gets added to the spreadsheet.
Not only do we use this for client projects, but we also test upcoming Foundation versions this way. Each component and their functions have expected behavior. Each gets a column in the spreadsheet. Does it work under Internet Explorer for Windows 7? How about Chrome for Mac OS X 10.10? And so on.
For example, we provide many free starter templates to use with the framework. Every one of them failed in Firefox — a long red streak along our troubleshooting spreadsheet. We had accidentally pushed out code without first running its CSS through the Autoprefixer. The issue was easily resolved, but underscored to everyone here the importance of testing, testing… and testing again.

Going Forward (And Sliding Sideways)

When released off-canvas navigation component to make sliding menus a snap on any modern browser, ran into a number of unexpected issues. Obviously when it comes to complex components, you wouldn’t just list Internet Explorer, but you would list all the versions supported in the spreadsheet. That’s what we did, too.
It was a good thing, too, because to our surprise the initial off-canvas animations didn’t work in IE9. Instead, the panel just sat on top of the page, obscuring a good chunk of the layout and refusing to get out of the way. We had to rethink certain CSS techniques and — after ensuring it worked in our supported versions of Internet Explorer — ran it through the QA gamut again to be certain that solving for one browser didn’t break another.
Half of developing a tool isn’t the creative work — it’s the time taken to make sure the creative work works. We address different degrees of “broken,” from ill-considered ideas to implementing the good ones; testing under a variety of circumstances; and ensuring that we cover as many bases as we can. It doesn’t take complex tools to stay accountable. Our spreadsheet approach works because it’s simple and accessible.
Is it perfect? No. But when problems arise, our hands-on system makes solving problems relatively quick. The result is a solid foundation that many designers have come to rely on.