Home / Mobile Commerce: Responsive, Dynamic or Hybrid Design?

Mobile Commerce: Responsive, Dynamic or Hybrid Design?

It’s clear that mobile matters, and mobile-friendly websites are table stakes. But what is the best approach for mobile commerce?

Death of m.dot
In the early days of mobile-targeted web design – circa 2009, mobile domains (m.dot or .mobi sites) were the norm. Home pages were nothing more than a list of menu links. Some sites, like Best Buy, offered only search tools and store locators with no browse navigation, product photos or checkout functionality. Mobile platform vendors like Usablenet, mPoria, and Digby powered over 80 percent of these early m-commerce sites, while the remainder were built in-house.

We’ve come a long way since then, and m.dot sites are all but dead. A recent survey of the Internet Retailer 500 found use of m-dot sites for ecommerce has dropped from 79 percent in 2013 to 59 percent in 2014, with dynamic serving and responsive sites increasing 12 percent and 15 percent, respectively.

Despite the appeal of responsive design, dynamic serving is trending higher in 2015 than responsive among m-commerce sites, expected to pass 20 percent this year.

Responsive vs. Dynamic
Responsive design uses a combination of flexible grids and layouts, images, and CSS media queries to serve the best fit of design and content to a device’s size and specs.

One of the biggest advantages of responsive design is that it works off one set of URLs and HTML code. Rather than maintaining a separate m.dot (or t.dot) site, updates can be made universally through a single CMS, simplifying maintenance and ensuring real-time consistency of content.

One set of URLs is also better for SEO. Google prefers to only need to crawl one domain, eliminating duplicate content, and websites benefit from consolidated backlinks, rather than having some links point to the desktop and others the mobile domain.

Designers have the flexibility to modify and reduce content delivered to mobile screens, giving some control over experience optimization. However, with all this code in a single HTML file, the page load can slow significantly – a factor that’s bad for both user experience and SEO.

The dynamic (also called adaptive) approach uses predefined layouts based on screen resolution combined with CSS and JavaScript. The right layout to serve can be detected by the server or by the client (device). Like responsive sites, dynamic sites can also keep a single URL structure (not having to use a m.dot domain), and generally load faster than responsive sites because they don’t require one set of HTML.

Dynamic sites also allow for device-specific targeting and experiences. For example, iOS devices currently use a less-than-optimal multi-option selection tool by default.

To make it more user friendly, a designer might target Apple devices with a checkbox/button grid or custom selection tool. Custom layouts also accommodate radically different mobile experiences (vs. desktop) if desired.

Both responsive and adaptive must design and test for the most common screen resolutions. Both are time consuming and expensive in that regard, but for smaller sites, the responsive approach may be more cost-effective, especially considering the variety of device sizes. Smartphones have been trending larger, tablets smaller, and the distinction between is more blurry. Each year even the most popular devices release new dimensions, and it takes work to keep up with these changes.

The big advantage to adaptive is faster load time, which has tremendous impact on user experience and bounce rates, conversion rates and revenue. This may be the reason it’s most popular among top online retailers despite the increased cost and maintenance.

Hybrid Responsive Web Design
HRWD – Hybrid Responsive Web Design, also referred to as RESS (responsive with server-side components) is an alternative approach where the server detects the device class (e.g. mobile) and delivers the optimized layout from a single set of URLs and code. Rather than the user’s client having to load all the HTML, the server can detect and select only the scripts, markup, and stylesheets that are required for the device. The flexible property of responsive design handles the scaling of images and other design elements to ensure everything looks good (vs. the adaptive requirement of multiple resolution layouts).

For example, an ecommerce site might wish to serve an app-like experience with major navigation controls appearing pinned at the bottom of the page as the user scrolls up and down, vs the desktop’s layout of across the top header.

The downsides to HRWD are complexity, which may be above and beyond what your solution requires and what your development team can deliver, and cost. As an emerging solution, it doesn’t yet fill all the gaps left by responsive and adaptive solutions.

Which to choose?
There’s no cut-and-dried method to follow. Your choice will depend on your budget, internal resources, experience goals, and trade-offs between the pros and cons of each.

However, responsive, adaptive, and hybrid are all more desirable than stand-alone m.dot sites for more efficient scale and maintenance.

Comments

Posted on by Shayla Price (not verified).

I've found that companies are using the adaptive approach. For the reasons you stated, it makes a huge difference on the UX. Consumers don't want to wait for a page to load.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.