• What to Plan for When Going Responsive

What to Plan for When Going Responsive

Posted by James Marshall | Well Done |

The web is continuously evolving in ways you may not even realize. Websites are adapting to suit a wide variety of touch and mobile devices. The process isn’t as simple as adding a plugin, a library or using new code; the process involves a whole new way of thinking.

As we develop for touch and mobile, we find that what was once easy to develop has become a user experience nightmare. Common navigation solutions have either fallen to the wayside or been forced to adapt. Even scarier is how unattractive and even unusable older website concepts have become.

So, what has changed about the web? First and foremost, websites have become fluid and adaptive for devices with a wide range of resolutions. We no longer have strict control over how content is laid out. We can also no longer accurately define what is “above the fold” on a website, and have very little control over widows. Certain old solutions no longer resonate, and may actually create a problem where there wasn’t one before.

Problems with user experience are not limited to layout, but also apply to navigation and functionality. Flash is not supported by mobile and touch devices, so flash elements are only available to desktop users. Java has limited support as well. Worse yet, dropdowns and sliders may function using hover events. For example, in order to access a dropdown menu, you may have to hover your mouse over a category to reveal the pages within that category. Touch devices do not have a hover state meaning mobile users would not be able to access pages within specific categories.

Considering the issues that arise within non-responsive web design, lets examine what responsive best practices you should be following.

  • Utilize a responsive framework. These have most of the grunt work completed for you, allowing you to identify how a page’s structure adapts to different breakpoints. It also enforces modular and fluid design principles.
  • Ensure styles and assets are similar across breakpoints. This is a more economic approach rather than creating a website with unique styles and images for all breakpoints, as this would take longer to code and create longer download times.
  • Account for IE8 and below. When coding for responsive, you are coding for Internet Explorer 9 and up. Be aware of the need to support additional versions of browsers.
  • Test. This is the biggest step to account for when creating a responsive site. A few helpful testing tools include Viewport Resizer and Emmet Re:View.

The web is no longer static – it is shared by users with a variety of different browsing habits and expectations. It may be intimidating to change how we approach the web, but it is to our benefit to meet the challenges brought on by new web browsing trends.

Any must-have best practices you think we missed? Comment below to keep the conversation going.