Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Responsive eCommerce: Part Two

Responsive eCommerce: Part Two

Last year I made the case for responsive, many-device eCommerce websites: http://gravitydept.com/blog/responsive-ecommerce/

I demonstrated why it was important, what approaches could be taken, why it hadn’t been done, and how to form a convincing strategy to get it done.

This year I showed how the many-device landscape continues to explode and change user behavior, review concrete examples of companies that have embraced this and the financial benefits, and pinpoint the key problem areas when building responsive eCommerce applications with insights/examples from my experiences doing so on the front lines.

More info: http://gravitydept.com/blog/responsive-ecommerce-part-two/

Conference: Magento Imagine 2013
Speaker: Brendan Falkowski @ http://gravitydept.com
Location: Las Vegas, USA
Date: April 10, 2013

Brendan Falkowski

April 10, 2013

More Decks by Brendan Falkowski

Other Decks in Design


  1. Design Consulting For My work is split 50/50 between client

    services for companies like Skinny Ties and Angry Birds.
  2. Acumen Theme • Used by 1200+ stores • 3 years

    of updates • Ready-to-launch frontend • Made for customization gravitydept.com/to/acumen-magento And product development like Acumen, a best-selling ready-to-launch Magento theme.
  3. Magento Certification Advisory Board Member I’m also a member of

    Magento’s Advisory Board for certifying developers.
  4. Responsive eCommerce Part One This talk is part two. I

    gave part one last year right here.
  5. 1. Why mobile matters 2. Small screen methodologies 3. What

    you can build 4. Best practices for MF/RWD 5. How to define and execute a strategy • What can you build • Best practices for mobile first / responsive design • How to define and execute a strategy
  6. gravitydept.com/blog/responsive-ecommerce/ If you haven’t seen it, you can watch and

    read all my notes here: But I’m not going to rehash anything today. Part Two is about what I learned from responsive commerce this past year, and how you can springboard from that.
  7. State of Mobile & Commerce: 2013 Edition Let’s look at

    the state of mobile devices and commerce in 2013.
  8. seekingalpha.com/article/1120151-reviewing-the-mobile-revenue-of-major-internet-companies $0B $125B $250B $375B $500B 2010 2011 2012 2013

    2014 Desktop Mobile Revenue from eCommerce in US + Europe In the US and Europe, eCommerce revenue grew to 370 billion dollars in 2012, and is projected to reach 439 billion by 2014. But if we look at the subset of just mobile revenue, we see it’s driving the majority of growth.
  9. seekingalpha.com/article/1120151-reviewing-the-mobile-revenue-of-major-internet-companies 0% 8% 15% 23% 30% 2009 2010 2011 2012

    2013 2014 2.2% 4.9% 10.0% 17.0% 23.0% Mobile Percentage of Total eCommerce Revenue Two years ago, it was only 2.2% of eCommerce. And two years from now, it will be 23%.
  10. 17% use phone as primary device for web access April

    2012 For 17% of cell phone owners, that is their primary access to the web.
  11. 40–50% are mobile only in: • 18–29 year olds •

    African American and Hispanic • Income under $30k / year December 2012 In certain demographics, 40 to 50% rely on their phone for web access. Mobile devices aren’t a second screen to a significant portion of the population. It’s the only screen, and your web strategy has to reflect that.
  12. skinnyties.com We're still in the early days of figuring this

    out, but the early indications are promising.
  13. Companies think in design and technology problems. I hear that

    — a lot. Companies think in design and technology problems. And those things are great because they’re surface-level. Everyone can see value in them.
  14. Most problems are content problems. But, especially in responsive projects,

    they act like blinders that hide deep-rooted problems in your content.
  15. Responsive web design is not all the devices + prettiness.

    Responsive design is not: all the devices plus prettiness. That’s the seduction.
  16. RWD is planning for your content to go everywhere. Here’s

    the reality: responsive design is planning for your content to go everywhere. Content audits are not sexy, but that’s where it starts.
  17. skinnyties.com They’re a small, family-run company operating in a very

    narrow and competitive niche. I worked with them for eight months to re-imagine their business and technology strategies, and responsive design was at the core.
  18. Content problems: • Information architecture • Product photography • Knowledge

    leadership Aesthetically it was a big step forward and it works brilliantly across devices, but mobile wasn’t the only problem Skinny Ties was facing:
  19. Limited Navigation Options And when we compared that to the

    primary navigation it was obviously one-dimensional and inadequate.
  20. Every product spec needs a standardized set of values. Every

    specification that could relate ties became a configurable attribute. Descriptors like color, width, fabric, and pattern were documented across the entire catalog, and they were a mess.
  21. lime green olive green sea foam green true green turquoise

    2.5 inches 2.5” 2 1/2” 2 1/2 inches Two inches avocado green forest green green hunter green kelly green We found 8 different shades of green, and five ways to define tie widths.
  22. New product schemas: • Descriptive • Consistent • Keyword infused

    We used that research to model new product schemas that were descriptive, consistent, and keyword- infused.
  23. Refined content schemas = Great SEO If this sounds an

    awful lot like search engine optimization it should. Refined, multi-dimensional content is great for SEO.
  24. Their first incarnation was limited to the boxes imposed by

    the CMS. Their photo asset production was based around filling those boxes rather than showing their products in the best light.
  25. In the new site, consistent bold photography is central to

    their content strategy and composition was tightly controlled.
  26. We created comprehensive style guides for shooting and editing that

    defined standards for scale, orientation, angularity, white space, ambient brightness, and light hardness.
  27. Knowledge Leadership Discoverability and photography only goes so far though.

    You still need to build trust and for Skinny Ties that meant demonstrating expertise.
  28. It’s not enough to simply list product specs. By interpreting

    them we help customers with stylistic and practical advice:
  29. Beautiful design without useful content lacks authority. That knowledge is

    associated with their products and brand. Without meaningful content the most beautiful design will still lack credibility.
  30. RWD was not the silver bullet. The point here is

    that responsive design as a technology was not the silver bullet.
  31. Content assumptions affect all devices. If we hadn’t stepped back

    to rethink assumptions about Skinny Ties’ content, all those problems would be endemic across every device the responsive site serves.
  32. Designing content-first led to success. Having considered those issues though,

    we created a rock-solid framework of needs and goals to approach the aesthetic and technological challenges facing Skinny Ties. When we started designing responsively, our content-first approach led to success.
  33. netmagazine.com/features/top-25-responsive-sites-2012 Net Magazine: Top 25 Responsive Sites of 2012 When

    Net Magazine picked the top 25 responsive sites from 2012, among some very large brands Skinny Ties was on the list for good reason.
  34. This image is the perfect visualization of what’s happening with

    performance today. If content is the battle, then performance is certainly the war.
  35. Performance is a design constraint. Designers need to acknowledge that

    every addition of content is a subtraction from performance, and possibly a negative impact on user experience.
  36. Technology is losing the performance fight. There’s a perpetual myth

    that faster browsers and better networks have beaten this problem. Fact: delivery technologies are getting faster, but the weight we’re cramming into websites is more than outpacing those gains.
  37. Median Load Time from Alexa Retail 2000 seekingalpha.com/article/1120151-reviewing-the-mobile-revenue-of-major- internet-companies 5.94s

    Dec. 2011 7.25s Dec. 2012 ~9s Dec. 2013 Among sites in the Alexa Retail 2000, the median load time is up 22% since last year, and will be over 9 seconds by this holiday season.
  38. The business case needs to be made for performance. The

    business case needs to be made for performance. We have to quantify how much it hurts to change behavior.
  39. “We are not the fastest retail site on the internet

    today.” Walmart is talking about this in a humble way: 8 of their 10 biggest competitors were faster. After putting a performance and business analyst together here’s what they found:
  40. webperformancetoday.com/2012/02/28/4-awesome-slides-showing-how-page-speed-correlates-to-business- metrics-at-walmart-com/ This graph shows Walmart’s conversion rate versus page

    load time. The blue bars show the percentage of users experiencing different load times, and the red line is conversion rate. What do you see? There is a sharp conversion decline from 0 to 3 seconds. A 4 second load converts almost as well as 14 seconds. And the majority of users are in this flat low-conversion tail.
  41. Walmart Business Metrics for Performance webperformancetoday.com/2012/02/28/4-awesome-slides-showing-how-page- speed-correlates-to-business-metrics-at-walmart-com/ 1s faster +2%

    conversions 0.1s faster +1% Revenue And when they put business metrics on top of this data, they found some incentivizing results.
  42. Ignore the backend. (gasp) That’s going to sound crazy if

    you’ve heard any Magento performance talk in the last three years. They usually champion these things:
  43. Tune the server! Full-page caching! EC2 ELB Varnish cloud magic!

    This is great advice for scalability. But it’s only solving a fraction of the performance problem.
  44. Steve Souders literally wrote the book on high performance websites.

    He led performance engineering for Yahoo and is now at Google.
  45. stevesouders.com/blog/2012/02/10/the-performance-golden-rule/ Load time of 50,000 sites Frontend Backend 13% 87%

    He scanned 50,000 sites and found just 13% of load time was from the backend, and 87% was the frontend.
  46. “80–90% of the end user response time is spent on

    the frontend. Start there.” stevesouders.com/blog/2012/02/10/the-performance-golden-rule/ This became the Performance Golden Rule. The frontend makes your users wait 4x longer than the backend.
  47. A bad frontend undermines the perfect backend. It almost doesn’t

    matter how good your backend is. A sloppy frontend will easily undermine all your effort.
  48. Your frontend needs a steward. Your frontend needs a steward.

    They are responsible for balancing the business versus performance needs of the site, and holding the fort.
  49. You cannot let sites swell unchecked. If you add something,

    you have to stay honest and take something away.
  50. YSlow developer.yahoo.com/yslow/ Google PageSpeed developers.google.com/speed/pagespeed/ WebPageTest webpagetest.org/ Report Cards There

    are three excellent tools for generating a “performance score”. They evaluate dozens of metrics and generate a report.
  51. Waterfall Charts For debugging, waterfall graphs in browser tools like

    Web Inspector and Firebug are invaluable when isolating specific scripts.
  52. Some mobile devices lack profiling tools. Hacking your way around

    it: stevesouders.com/blog/2013/03/26/mobile-waterfalls/ But these are not as easy to generate on some mobile devices which lack profiling tools. You can hack around them though.
  53. Measured Speed vs. Perceived Speed And keep in mind there’s

    a difference between measured speed and perceived speed. A page that starts rendering first, but takes longer to finish actually feels faster. What your brain sees and what’s actually happening can be totally different.
  54. 14 Small Ways to Speed Up the Frontend The good

    news is, you can improve frontend speed significantly with a lot of very small and relatively simple tweaks.
  55. 1. Reduce HTTP requests. Use image sprites or icon fonts,

    and bundle dependent scripts together.
  56. 2. Use DNS pre-fetching. Tells the browser to perform a

    DNS lookup before encountering assets at that domain.
  57. 4. Use two domains for static assets. Modern browsers will

    download multiple assets in parallel.
  58. 5. Put JS at the bottom. When the browser sees

    a script tag it waits until the entire asset downloads before it proceeds.
  59. 6. Use asynchronous JS loading. The async attribute tells modern

    browsers they don't have to wait for the asset to load before continuing.
  60. 7. Use one CSS file. The browser won’t start rendering

    until all CSS is downloaded and parsed.
  61. 8. Link CSS from the site domain. This breaks tips

    3 and 4, but the page starts rendering faster without the extra DNS lookup and HTTP request.
  62. 9. Use a Content Delivery Network. CDNs duplicate your content

    around the world, so it’s physically closer to users which reduces latency.
  63. 12. Optimize images. Use the right format and bit-depth for

    the content. Vary compression for quality or speed.
  64. 13. Use caching and far-future expires headers. More info: youtube.com/watch?v=HKNZ-tQQnSY

    Prevents browsers from re-downloading content that hasn’t changed.
  65. 14. Use conditional loading. Postpone delivering heavy assets like images

    or scripts until the moment the user needs them.
  66. Pitfalls in Responsive Commerce If you’ve been building for the

    desktop or separately for mobile, responsive best practices can be hard fought. I’m going to run through things specific to eCommerce and Magento that snagged me, but which you can avoid.
  67. Markup Markup is the weakest link in responsive design. Magento

    is an extremely powerful platform, but it's designed to be desktop-centric. So there are some practices you'll need to undo and rewrite with patterns that are more adaptable to a mobile-first development process.
  68. One column Two columns left Two columns right Three columns

    For example, Magento ships with four page templates: But column layouts are inherently non-semantic. They infer decisions about where content belongs relative to this desktop-centric viewport. But what if the left and right sidebars should swap positions, or one appears above the main content, or both below it?
  69. Markup Order Matters Because markup order matters when you're reflowing

    containers you don't have the flexibility needed when working with these generic columnar layouts.
  70. One Column template for: • Home • Login / Register

    • Informational CMS Pages And that's why the only page template I find useful for responsive design is: One Column It makes no assumptions about my content, and I can derive the exact markup and proportions my content demands.
  71. Custom Templates for: • Catalog > List • Catalog >

    Product • Checkout > OnePage • Customer > Dashboard This might seem odd because they have similar columnar groupings, but having a specific template file for each scenario lets you bind the markup and CSS to that module's content as appropriately as possible.
  72. Flexible and Maintainble Then you don't have to rewrite the

    XML references across multiple modules. You can simply move the getChildHtml() method to render the left, right, or content blocks wherever makes sense.
  73. Generic columnar layouts don’t work when content changes shape/size. As

    you're designing each section you can define the proportions and breakpoints that make sense for catalog lists and layered navigation separately from checkout steps and the progress indicator. You can't do that using generic containers for everything.
  74. CSS3 Flexbox is very powerful, but not well supported yet.

    zomigi.com/blog/future-css-layout-fowd/ css-tricks.com/old-flexbox-and-new-flexbox/
  75. Responsive Images Handling images is the most ambiguous challenge facing

    multiple-device design. What we need is for the browser to automatically request the most appropriate asset depending on min/max viewport size, the screen’s density, and the network’s quality. None of that is possible today, but we can get close.
  76. 1. Image Replacement 1. Image replacement. Load the smallest asset

    on all devices. Use JS to check if the screen is larger or HiDPI, and replace the image source. Pros: lightweight initially Cons: can more than double bandwidth usage
  77. 2. Over Sizing @2x or @1.5x 2. Over sizing. Load

    the HiDPI asset first and let the browser scale it down. Pros: no double-download penalty, HiDPI laptops and external displays are coming fast Cons: hurts users on slow connections or non-Retina screens Can also serve @1.5x assets as a middle ground. Looks decent on HiDPI screens and less bandwidth for low-res. Sometimes that’s a good compromise.
  78. 3. Super Sizing @5x 3. Super sizing. You load a

    huge JPG, 5 times larger than needed, but it’s compressed with very low quality like 25% instead of 80%. When scaled in the browser to 1/5 it's actual size, the compression artifacts aren't noticeable. Pros: file sizes like 1 to 1.5x assets Cons: rendering takes performance hit, need hi-res assets
  79. 4. PictureFill https://github.com/scottjehl/picturefill 4. PictureFill. This is a JS polyfill

    for the proposed <picture> element. Pros: full control over asset loading, requires JS but has <noscript> fallback Cons: complicated syntax
  80. 5. Sechna.io Src docs.sencha.io/current/index.html#!/guide/src 5. Sencha.io Src. Creating multiple assets

    by hand is impractical. You’ll need a web service like SenchaSrc that accepts an image URL and parameters which resizes, caches, and serves assets on the fly. Magento has a method like this, but it’s only useful for assets in the file system. In either case you still need to detect which asset is appropriate before requesting it, so something like PictureFill is a necessity.
  81. 8 Guidelines and 1 Rule for Responsive Images Jason Grigsby

    came up with eight guidelines for a responsive images dream scenario and one rule, which is what I want to share.
  82. “Plan for the fact that whatever you implement will be

    deprecated.” blog.cloudfour.com/8-guidelines-and-1-rule-for-responsive-images/ “Plan for the fact that whatever you implement will be deprecated.” This reminds us that we’re still figuring this out.
  83. Bandwidth and latency still can’t reliably be detected. For example,

    there’s still no reliable way to detect bandwidth or latency. It can change mid- request.
  84. Users that pay for bandwidth per MB may want lo-res

    images. Users might not want HiDPI assets even if their device is capable because they pay for bandwidth per megabyte. A smart configuration might offer the option to enable HiDPI assets.
  85. A Balancing Act for Skinny Ties There isn't a silver

    bullet for responsive images. It has to be a balancing act between the device capabilities, your quality standards, and the other pieces of your infrastructure affecting performance. For Skinny Ties, we handled images three different ways.
  86. Images @1x Images @1x. For small, low priority images it’s

    fine to serve only the @1x asset. There are only a few instances of this. All icons are served as image sprites with the appropriate pixel density.
  87. Images @1.5x The majority of images are loaded @1.5x. This

    includes the navigation thumbnails, featured content on the home page, and category lists. The increase in bandwidth is actually very small because the isolated-on-white art direction plays well with JPG compression. We don’t have to overthink how images scale and it ensures images always look decent.
  88. Image replacement On product pages we serve the @1x asset

    to all devices. This is effectively the @2x asset on phones so there’s no double download. If we detect the screen is large and HiDPI, the full-resolution asset @2x is loaded. On a HiDPI screen like the iPad, you can still pinch/zoom to about 150% without losing quality in the same logic that @1.5x assets scale decently on @2x hardware.
  89. Sprite Icons Sprite Icons. All icons in the site are

    combined into sprite images @1x and @2x pixel densities. The stretching effect of HiDPI displays is most pronounced on line art such as icons. On small screens where icons often act in lieu of navigation it’s extra important to make the sharp and clear.
  90. Tailor your approach to the content at hand. For every

    project this is going to shake out differently. Remember it’s most important to optimize for your content not a blanket approach.
  91. Sass + Compass Sass and Compass are essential tools today

    for writing maintainable, multi-device CSS. I don't know anyone who writes vanilla CSS anymore.
  92. Sass sass-lang.com Compass compass-style.org Sass is a pre-processor for CSS

    that extends that language's capabilities with variables, functions, mixins, and placeholders. Compass is a library for Sass that adds hundreds of useful mixins and functions: everything from color blending to sprite generation.
  93. maddesigns.de/sass-compass-introduction/ The basics are very easy to learn, but this

    can have a tremendous impact on how extensible, maintainable, and effective your CSS is. For a complex responsive project not using pre- processed CSS is suicide.
  94. Grunt developer.yahoo.com/yslow/ CodeKit incident57.com/codekit/ Hammer hammerformac.com Build Tools for Sass/Compass

    Scout mhs.github.com/scout-app/ You can compile them from the command line, but most teams integrate in a build process like Grunt. If you’re working locally or solo then apps like CodeKit, Hammer, or Scout can be useful.
  95. Left: hierarchy of Sass partials Right: loader of Sass partials

    Sass + Compass Structure Architecting a design system with Sass is a whole topic unto itself. I can’t dive into it now. So here are two screenshots of a typical project folder and associated loader of the Sass partials that you can inspect later to get some ideas.
  96. Frontend Frameworks and Prototyping I have to mention frameworks Bootstrap

    and Foundation because I know somebody will ask about them. They’re super-sized pattern libraries with extensive documentation.
  97. Bootstrap twitter.github.io/bootstrap/ Foundation foundation.zurb.com The purpose of these frameworks is

    to rapidly prototype new interfaces for design testing, and for that they are brilliant. A blank-slate app could turn that into production code, but Magento has deep-rooted patterns and frontend practices of its own. Ignoring these traits and replacing them with a framework is redundant and will create compatibility issues with extensions.
  98. Build a lean pattern library for each project. It's a

    lot smarter to borrow ideas and snippets from frameworks and integrate them as needed to build your own pattern library for each project. You’ll have fewer dependencies and less to maintain in the long run.
  99. “Mini Bootstraps” are the modern design deliverable. daverupert.com/2013/04/responsive-deliverables/ This is

    how I’ve been working lately, and it makes a lot of sense. Dave Rupert from Paravel calls them “mini Bootstraps” and suggested this is the modern deliverable for responsive design. I tend to agree.
  100. JS Behavior and Media Queries Media queries are part of

    the CSS spec, but sometimes you need to change JS behavior in response to a media query also.
  101. if (window.matchMedia("(min-width: 400px)").matches) { // Do something } developer.mozilla.org/en-US/docs/DOM/window.matchMedia Newer

    browsers support the window.matchMedia object to detect if a media query applies via JavaScript. This is great for one-off cases, but usually you need something a little more powerful.
  102. Harvey github.com/harvesthq/harvey Enquire github.com/WickyNilliams/enquire.js At different breakpoints, your frontend might

    need to setup, register, or de-register JS code to avoid overlapping events. Harvey and Enquire are state managers for media queries that listen for viewport changes and execute callbacks. This prevents devices from executing code that doesn't apply to them, and helps coordinate application logic separately but in parallel with layout.
  103. Touch Events in JS Multi-touch events can be used to

    make web interfaces feel more like native apps, but they can be tricky.
  104. touchstart touchmove touchend They fire independently of one another with

    three basic events: touchStart, touchMove, and touchEnd.
  105. touchstart event fires click event fires 300ms delay After the

    touch start event, there is a 300ms delay before the click event fires. The purpose of this delay is so the device's browser can determine if the user is tapping, long-tapping, or double-tapping. But the downside is it makes the interface feel slow and un-attentive.
  106. Workarounds for click delays You could get around this by

    triggering an action with touchStart and preventing the event from bubbling, but then you would also inadvertently trigger the event if the user swipes to scroll. A better option is using the touchEnd event and measuring whether the touch's position changed to rule out scrolling.
  107. Here be dragons Some Android versions randomly drop the touchEnd

    event though and others will cancel the current touch event if another touch event starts, so it is critical to test on real devices. Depending on your interactions and feature support requirements you may not be able to harness touch events reliably.
  108. https://developers.google.com/mobile/articles/fast_buttons http://www.html5rocks.com/en/mobile/touch/ Further Resources Some Android versions randomly drop the

    touchEnd event though and others will cancel the current touch event if another touch event starts, so it is critical to test on real devices. Depending on your interactions and feature support requirements you may not be able to harness touch events reliably.
  109. Stack Forms Stack forms are completely linear. Labels are above

    inputs which are above contextual notes or errors. This pattern works well on small screens when you can't see more than one input at a time because of the on-screen keyboard.
  110. Scaffold Forms Scaffold forms place the label and input adjacent.

    This pattern can make a longer form feel more compact. Fieldsets with headings can also help make longer scaffold forms feel shorter by bundling inputs into smaller chunks.
  111. Adjacent fields are hard to use. I never put two

    inputs adjacent to one another. By default Magento does this in the billing and shipping address forms.
  112. Your user’s eyes should not do this. But it's inefficient

    and confusing because the eye needs to criss-cross between elements.
  113. Make forms flow in only one direction. It's always a

    usability plus to design a form's flow consistently and sequentially. This is a great example of how designing mobile first helps you prevent overcomplicating the large screen experience.
  114. HTML5 Input Types HTML5 input types can help mobile users

    complete forms significantly faster by changing their on-screen keyboard to suit the data being captured.
  115. <input type="tel" /> The tel type uses the telephone dialing

    keypad, but usually you don’t want’s users entering hash/star symbols since they’re not actually dialing.
  116. <input type="number" /> So you might try the number type,

    which brings up the correct numeric keypad. But some desktop browsers like Chrome will render custom controls, which are too tiny to be useful. This can be confusing to users for values that would never be incremented like their phone number or credit card.
  117. <input type="text" pattern="[0-9]*" /> So instead use a regular text

    input with the pattern attribute. This will prompt on-screen keyboards to use the numeric keypad without the hash/star signs. It makes entering things like credit cards numbers much easier on phones, and on the desktop it behaves like a normal text input.
  118. Custom Quantity Widget Providing incrementation controls isn’t a bad idea

    though for inputs like quantity. If you make the button targets larger, you should implement a custom UI patterns so it's easy for users to increment, decrement, or manually adjust the quantity.
  119. Sisyphus.js github.com/simsalabim/sisyphus Those things help users complete forms faster, but

    if you leave checkout and re-enter later — all your input is lost. You have to start over. Sisyphus is JS component that monitors forms and saves un-submitted data in HTML5 LocalStorage. Then when you return to the form it pre-fills those values so you can pick-up where you left off. This can save a lot of time on mobile devices.
  120. Tables Tables and responsive design are like oil and water.

    There isn't an easy way to view large, granular datasets on small screens. Thankfully in eCommerce, table use can be limited to a few scenarios that are manageable. There are five patterns I use depending on the content.
  121. 1. No Tables Don't assume tables were the right format

    in the first place. For example, the catalog list's grid mode should not be a table because the markup can't adapt to reflow the number of items per row for different viewports. Tables don't work there. It's a better idea to rewrite the content as an ordered list and use nth-child to define the number of list items per row for each breakpoint. This gives you more freedom and none of the headaches.
  122. 2. Simple Tables Simple tables sometimes don't need any special

    transformations. With two to four columns you might be able to compress them from large to small screens if their contents wrap in a usable way. Some tables contain too much data though. They simply can't be scaled down to fit on a phone without changing the content or structure.
  123. 3. Priority Tables Priority tables are also 100% flexible, but

    you add/drop columns for different viewports. This pattern is only recommended for summaries. You should not remove access to content. Example: Order History List. It's not necessary to see all the order details to identify an order. Users can probably find their order with just date, ID, and price — then click through to view order details.
  124. 4. Linearized Tables Linearized tables dissolve the table's structure entirely.

    All the cells become block or inline and might be positioned absolutely with the table row. Because you lose table headings some data might need supplemental labels or completely different formatting to be understandable or logically grouped. But with that extra work you can make the content much more usable. For example, separating summaries and interactions in the cart helps minimize the interface on small screens. Some tables are beyond transformation though, especially those with column spans or conditional columns. This makes any change to table structure a Herculean effort because tons of edge cases come into play.
  125. 5. Scroll Tables Scroll tables are the last resort. When

    you can't significantly modify the table structure because of the generation code or the data complexity, you have no choice but to render the full table with some content off-screen. The overflowed content is accessible by scrolling but you can only see a small portion of the table at once. It's hard to visualize the whole table without exploring its edges. UX-wise this is not great, but it works as a concession.
  126. css-tricks.com/responsive-data-table-roundup/ Further Resources These are by no means all the

    patterns for transforming tabular data across devices, but they're most applicable to eCommerce.
  127. Social Widgets Social widgets are on almost every site today,

    and they’re some of the worst usability and performance offenders.
  128. • Not designed for small screens. • Inconsistent sizes, layouts,

    margins, and style. • Every major mobile platform has sharing built into the OS. • Internet Explorer + Safari do too. • Dozens of extensions for Firefox + Chrome. I fight really hard against implementing for these reasons: Not designed for use on small screens. Hard to use. Inconsistent sizes, layouts, margins, and style. Clunky to design for. Every major mobile platform has sharing built into the operating system. Safari and Internet Explorer have this on the desktop too. Hundreds of extensions for Firefox and Chrome. Mobile devices have native apps. Users probably are not logged in via the mobile web on them.
  129. Facebook + Twitter + Google Plus Share Widgets 19 HTTP

    Requests 247 KB of data But the biggest reason is performance. If you embed Facebook, Twitter, and Google Plus buttons on your site that's going to add 19 HTTP requests and 247 KB. Over WiFi that's 2.3 seconds. Over 3G that's 11.5 seconds just for share buttons. That's completely unacceptable.
  130. The Cost of Social Widgets +2.3s Over WiFi +11.5s Over

    3G But the biggest reason is performance. If you embed Facebook, Twitter, and Google Plus buttons on your site that's going to add 19 HTTP requests and 247 KB. Over WiFi that's 2.3 seconds. Over 3G that's 11.5 seconds just for share buttons. That's completely unacceptable.
  131. Share links are way better • Every social site has

    them • Plain old HTML • Full styling control • Sharing interface is almost identical • Instantly recognizable • Tap friendly There is a simple, fast alternative: links. Links are awesome, but they’re rarely used. Every social site has them. You have full styling control. The sharing interface is almost identical. They're instantly recognizable and very tap friendly.
  132. The Cost of Share Links 0 HTTP Requests <1 KB

    of data Zero extra HTTP requests and zero extra bandwidth with sprites.
  133. Extensions Third-party extensions can crush you. Even if you build

    the perfect responsive, lean frontend I’ll bet dollars to pesos the third-party extensions and components integrated in your desktop site aren’t.
  134. Be prepared to audit all your extensions. Most stores have

    a significant number of partners, vendors, and integrations that add critical functionality. But you can’t simply leave them as-is. Every third-party component that renders on the frontend needs to be brought up to responsive standards.
  135. 1. Request vendors update their code. 2. Remove the vendor’s

    styling, but keep the interaction. 3. Fork and maintain your own version. Coping with Extensions This plays out in three ways: Request the vendors modernize or change their platform / infrastructure. Remove the vendor’s styling, but keep the interaction. Fork and maintain your own version.
  136. Checkout There seems to be an idea that checkout is

    really hard to do well on small screens. And I disagree with that. A good checkout flows naturally. It's not distracting. You focus on one thing at a time. And a small screen actually forces you to do those things. It's the big screens where people do stupid things.
  137. 1. Eliminate unnecessary steps. 2. Pre-fill data whenever possible. 3.

    Use appropriate inputs so typing is easier. Making checkout faster Don't worry that you need 15 inputs from a user. People are really good at completing sequential tasks. Just don’t get in the way. • Eliminate the unnecessary (like fax numbers) • Pre-fill data whenever possible • Use appropriate inputs so typing is easier
  138. Billing Address Shipping Address Shipping Method Payment Method Review +

    Submit Progress Lets break down Magento’s one page checkout. You have the accordion of steps and the progress sidebar.
  139. Billing Address Shipping Address Shipping Method Payment Method Review +

    Submit Progress Billing Address Shipping Address Shipping Method Payment Method Review + Submit Progress But if you compress this for smaller screens, the progress block has nowhere to go. You can't put it before the accordion because it’s way off screen. And you can't put it after because that's below the “Place Order” action.
  140. Billing Address Shipping Address Shipping Method Payment Method Review +

    Submit Progress The least invasive option is to duplicate the progress block inside the review step. This way user has a final chance to check their order info before submitting.
  141. Woven Checkout We can do better than that, but it

    requires modifying Magento’s checkout significantly. I call it “woven checkout”.
  142. Billing Address Shipping Method Payment Method Review + Submit Shipping

    Address Instead of bundling all the progress together, each step collapses to its summary when completed.
  143. Billing Address Shipping Method Payment Method Review + Submit Shipping

    Address Step Summary Step Summary Step Summary
  144. Billing Address Shipping Method Payment Method Review + Submit Shipping

    Address Step Summary Step Summary Step Summary Step Summary
  145. 1. Natural Hierarchy 2. Proximity 3. Device Friendly This would

    be ideal for three reasons: Natural hierarchy. The editing interface erodes as the progress interface forms. It's a logical tide exchanging input for feedback. Proximity. There's no interface gap between input, reviewing, and editing. For each step each interaction mode occupies the same physical space. Device friendly. This would work brilliantly across devices. It doesn't require drastic layout transformations, and on small screens you can rapidly swipe up to review before submitting. If you study checkout flows in native apps this pattern is gaining traction. It's another great example of mobile first thinking making the desktop interface smarter.
  146. Again, extensions I'd love to see Magento offer one page

    checkout with something more flexible like this. It really needs to be a supported core feature though because third-parties that integrate with checkout need a standardized architecture and callback pattern to extend.
  147. Show Me The Money All that tech and design stuff

    is great. I love it. But it means nothing without driving business goals forward.
  148. Quantity 78.0% Average Order Value 20.8% Transactions 57.8% Revenue –

    iPad 224% Revenue – iPhone 473% Revenue – Android 187% YOY Impact of Responsive Design for Skinny Ties I spoke about this in much greater detail yesterday in the marketing track. Year over year, Skinny Ties saw 90.6% revenue growth across all devices including 211.6% from mobile devices. The SEO benefit of responsive design yielded 79.8% more visits from organic search. It’s completely transformed the way they do business.
  149. Transactions On Mobile 382% Responsive + O’Neill Clothing http://electricpulp.com/notes/you-like-apples/ http://electricpulp.com/notes/more-on-apples-mobile-optimization-in-ecommerce/

    Revenue On Mobile 370% Electric Pulp has also shared some data on their responsive work for O'Neill Clothing that paints an equally sunny picture. Transactions on mobile are up 382% and revenue up 370%.
  150. I hope to hear more stories like this from you.

    Sharing this data shows merchants what kind of opportunity building a responsive frontend can have on a business' bottom line. It’s a fantastic investment to move from a weakness to a strength. I hope to see a lot more similar stories throughout the year from people like you.
  151. Thanks It’s a great privilege to be here and I

    want to thank Magento for inviting me back. This is my third time speaking at Imagine, there are a lot of friends in the audience and even more new faces. I don't know half of you half as well as I should like; and I like less than half of you half as well as you deserve.