It Doesn’t Matter

Theresa Neil posted some slides rounding up some navigation patterns for retail mobile sites. Theresa made the amazing Mobile Design Pattern Gallery, which is a fantastic resource and was insanely helpful for me when I started making the responsive pattern library. But I was a bit bummed when I saw this in the slides:

However, this does not mean that responsive is the right strategy for the retail space. Mobile Optimized sites and/or Native apps are a better solution.

First of all, some numbers are coming back on responsive retail sites and they’re looking pretty damn good. 42.4% conversion rate increases. Over 400% (!) conversion rate increases for Android. Also, native vs web is a totally different conversation. But that’s what we’re here to talk about.

This is a sentiment I hear time and time again whenever we start talking about responsive design: “Yeah, but we’re not the Boston Globe.” or “Responsive design works well for publication sites, but I work in the ecommerce-enterprise-startup-brand-app-highered-corporate-B2B space, so…”

It doesn’t matter.

We aren’t in the retail business. We’re not in the higher education business. We aren’t in the publication business. We aren’t in the enterprise business. We’re in the interface business.

Sure, the content and functionality of our respective “spaces” (I’ve always hated that word) will influence how an interface gets realized, but our job is to make interfaces that function and look great. That now requires making interfaces that look and work great on a whole host of connected devices.

Gradient of Adaptation

Adaptive interface techniques sit on a gradient. Some interfaces consist of elements that don’t have a lot of moving parts, while others require more thought and care.

  • Translation – There are quite a few patterns that translate well to any environment with minimum effort. Words on a page. Accordions can stretch quite nicely. Many (but not all) images. Form fields. The list goes on.
  • Transformation – Patterns like adaptive maps, conditional lightboxes, many responsive table solutions and more are examples of interface elements that require more thought than a simple 1:1 translation to work across all environments. But these patterns end up working well by applying some good ol’ fashioned consideration and progressive enhancement.
  • RESS – Sometimes transformation requires more than client-side help, which is where RESS can step in to help. There might be several areas of an interface that might be too complex to transform and as a result require different treatments . Or maybe RESS is used to address a five year old Flash module that you can’t get rid of just yet.
  • Separate Device Experiences – I’m increasingly having a hard time thinking of technical reasons for creating entirely separate experiences (though there sure are plenty of organizational reasons). I’m not denying they don’t have their advantages (catered experience, don’t have to worry about translating the interface to large screens, potentially faster experiences), but they don’t offset the disadvantages (URL redirect issues, content parity issues, content governance and more).

    But I do talk to people who are working on really immersive Google Street View-esque panaramic experiences, and people whose entire product relies on extremely robust interactive data tables. I’d say they’re justified in created a separate experience do deal with the level of complexity of their products.

Separate device experiences give us an out. They stop the bleeding and solve an immediate need. But they simply don’t scale.

Just because something is hard doesn’t mean it’s not worth pursuing. Sooner or later, your ecommerce-enterprise-startup-brand-app-highered-corporate-B2B site will need to address the reality of our multi-device world and all the problems that come with it. And it’s our job to solve those problems. After all, we’re in the interface business.

20 Comments

  1. Word!

  2. The gradients of adaption concept is brilliant. It is concise and can easily be shared with other developers when explaining why one approach might be used in certain situations over others.

    I also like how you touch on disadvantages of a separate website. With all of the articles today on the benefits of separate mobile websites, I think that it is easy for some to overlook that there are disadvantages to separate mobile sites as well.

    I think it’s important to remember there multiple solutions for creating cross-device experiences. It is up to us to be knowledgeable of the solutions and know what tool is best for the job at hand.

  3. I love it when you coin new terms!

    The “gradient of adaptation” + tweakpoints, enables us to start making fixed sites more adaptive by optimizing individual elements (starting small with the quick win translation patterns). Reminds me of your “Planting the Seed for a Responsive Future” post but now for parts of the actual site.

  4. I’m not sure you’ve fully explained here why folks should not build a separate mobile site. Not disagreeing with you but exactly what are those URL redirect issues? If the mobile site and the desktop site share a common McGrane-style CMS and database, what are the content issues?

    • Why not build a separate mobile site has been talked about ad nauseum elsewhere. I did a comparison of Romney and Obama’s mobile web sites (and talk) and discussed URL redirect issues there.

      What you’re saying about having a single CMS that serves up content to both mobile and desktop sites sounds simple and is theoretically possible. You can achieve content parity with separate templates, but in my long experience witnessing this stuff I’ve literally never seen full content parity with separate templates.

  5. Hey Brad,

    I enjoyed this post and actually enjoyed Theresa’s slides as well. I’m interested to see what large retailers are using responsive well. I haven’t really found good examples…

    How do you feel about 1-800 Flowers approach where they have a separate mobile site, many different landing pages etc focused on certain shopping scenarios?

    They even removed tracking shipments from mobile because they saw no data to support that people used that feature at all…

    I’m now helping a very large retailer in their mobile strategy and we have a fairly clean slate to work with which is exciting. Internally, many people are talking about responsive design and misunderstand what it means (totally an education gap) and see no proof that it’s a good solution for retail…

    What are your thoughts on large scale retailers adopting responsive?

    • I’d say Curry’s is the biggest responsive retailer I know of.

      They even removed tracking shipments from mobile because they saw no data to support that people used that feature at all…

      These are the kind of assumptions you want to avoid. For far too long, too many people have said “but mobile users won’t do that.” Bullshit. Mobile users will do anything and everything desktop users will do, provided it’s presented in a usable way. For more info, I highly recommend reading Stephen Hay’s Myth of the Mobile Context post. I address prioritization in the comments.

  6. Stuart McCoy

    Brad,

    Those are issues of implementation and server access, not specific problems endemic to mobile sites only. If they are too lazy or busy to build out the mobile site, what makes you think they will be able or willing to build out the responsive site? While I have yet to build a site with mobile/desktop templates, I have tested the theory and it can be done.

  7. Stuart: The issue is that people (and I’m looking at developers here, agencies) will use the separate implementation as a secondary project. The discussion always comes down to which is the “main” view and what is the “secondary” view. Then, once that differentiation is made, priorities are assigned to it. Rightly or wrongly the main view, usually the PC desktop view, gets a lot of work done on it, lots of bells and whistles. The secondary view doesn’t, it just gets “done”.

    The same happened when people talked about needing HTML versions of Flash websites for accessibility reasons. Sure, people made the HTML versions, but they were barely functional and certainly didn’t attempt to recreate the depth of the flash version.

    Clients don’t necessarily know better, and unfortunately I see differing implementations of the same site in different contexts to be something that most of those developing use to try and generate maximum income for minimum effort…

    “Oh yeah, we’ll do you a mobile site. We won’t bother going responsive on the PC, and we’ll do a bootstrap layout for mobile. Why put the full functionality on mobile when some contact details, an about us, and a link to the full (unresponsive) desktop site will do?”.

  8. I kinda disagree with this statement:

    “our job is to make interfaces that function and look great.”

    I don’t really think that’s our job as designers. I think that’s maybe what we want as designers, but really our job is to bring back a greater return (revenue, customers) then was invested on hiring us. If I don’t do that, what’s the point of hiring me?

  9. Stuart McCoy

    Lee: RWD isn’t free of development time. Creating media queried and what happens when the break points are met isn’t something that automagically happens either. I can just as easily charge more for RWD (and you should). The point is, I can create a mobile site from the EXACT same content and have it updated once by the client and deliver optimized graphics and styled content by using a CMS.

    I’m not saying RWD is bad but let’s not believe it’s some magical form if web design come to cure all the problems developrs face. The ONLY benefit I see is that I can more easily design for the multi-platform world we’re heading towards but at the expense of tighter design control.

  10. Harold

    You nailed it, the experience of the interface MATTERS! If the UI sucks why would I want to dive in? I may be a fossil but you had better pay attention to the interface, engagement begins at the UI. Thx for the post!

  11. I think it’s important to recognize that most mobile-optimized retail sites come from turnkey solutions and were never really *designed*.

    In my opinion, whether you build multiple versions of a retail site or just one responsive version depends on the degree to which your site was designed as a web app.

    I’m writing a UX handbook and just finished a rough draft on a chapter about this very subject. I’d love to get some feedback and see if fellow designers agree:

    http://mobile.bazaarvoice.com/uxdd_staging/handbook.php?article=website-versioning

  12. Thanks for the mention Brad!

    I’m obviously a big proponent of responsive design from an interface continuity and content availability perspective, but mostly as the baseline for a tenable long-term strategy. I’m excited to see more data proving this is the right business decision.

    Sidebar: the 42.4% figure from Skinny Ties was for revenue growth.

  13. timster

    This very web page looks like I’m viewing a mobile layout on my desktop. The type is huge, these input fields are very large, and the whole thing makes me want to click the back button because I have to scroll and scroll just to read these comments. So here we have someone pretending to know a lot about responsive design and yet the experience right here on your own domain uses none of these implements. Seriously, if people can’t demonstrate their gospel I really wish they’d just shut up.

  14. ^ has a case of the Mondays.

  15. DEMONSTRATE YOUR GOSPEL BRAD YOU PHONY

    (Also, very brownish? Can I complain about that?)

  16. Yeah brad, sort your shit out. Next you’ll be saying that RWD hasn’t sucked the soul out of web design…

    I’ve been part of a build that delivers a www. and m. website from the same assets with a different templates applied to them. The CMS was awesome and had like for like URL redirects across every single url. It was even extended further and we included /en /de /es language contexts which provided translations for the same content (all using the same assets in the CMS)

    The content was nearly all the same, depending on what you considered content…
    – we made a conscious decision to use a shorter name in the mobile navigation, so something like “Navigation Patterns” was changed to “Nav Patterns”.
    – we shortened up the footer navigation by replacing a tonne of links to a few with a link to a site map
    – we also shortened the amount of additional content offered, so it there were 10 related articles on the desktop we only pulled through 3 for the mobile.

    Right or wrong they were conscious decisions made and at launch we had no issues in running the same main content.

    Well I say no issues. The inline content for the pages were all the same, so if you included a 600px wide iframe in the middle of the content, you got the same thing on the mobile. If you included a mobile sized/optimised image in the content, that’s what you got on the desktop. There was no picture fill options around when we did this (we weren’t aware of them anyway) and it was before the beloved RWD ALA book so that was never considered.

    After launch things started to fall apart. The content rules that were set up were not followed and both the mobile and desktop sites suffered in one way or another.

    Had the rules been adhered to it might have been alright, but if I were to approach it again I know which way I would go (although I am somewhat biased).

    The build time to get everything sorted wasn’t that much far off going responsive, there was more work involved around the system admin team handling the redirections that wouldn’t be required on a RWD site. The biggest time saver would have been moving forward with the content editing of the site. If we built it to handle the content as it is in it’s full form all the time then there would be less work for the content editors and less mistakes in the workflow.

  17. A few days ago, a friend sent me a youtube link in my inbox in facebook. It was from her mobile, and when I pressed it (I was on my notebook), it brought me to youtube mobile site. I ended up not even bothering looking up the what she sent in the end.
    -Just thought I throw this in the brew ^^

  18. Hey Brad – great post.

    We at Everguide created a dedicated mobile website a few years ago, right on the cusp of the responsive design movement. http://everguide.com.au and http://m.everguide.com.au (Australia).

    At the time, we felt that the amount of content our desktop users would want differed greatly from the mobile usage, and there was no deep resources out there to guide us when trying to switch to a ‘mobile first’ approach, or successfully and meaningfully scale down a desktop site, and keep it lightweight.

    How old is that slide deck above? Looks like it was posted on Feb 23 this year. Was it created before that, like conceptualised mid last year?

    If so, I think we can all agree a lots happend since then, and users’ growth has increased too. Users expect a lot more now, and ‘get’ responsive, especially with Google, Youtube and the like pushing so hard.

    Its a tricky case, but I think we as responsive designers need to keep our chins up and give it time!

    I truly believe deep down that the ‘right’ web is one that we’re campaigning for – as F.Chimero says – this is the world Im imagining. Its one where sites have robust data and content bases, and then really intelligent and flexible sites tap in using great plugins and frameworks and display the right content at the right time.

    Keep up the good work mate.