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

Transcript

1. Responsive eCommerce PART TWO Brendan Falkowski April 10, 2013 Magento Imagine Conference Las Vegas, Nevada
2. Brendan Falkowski Founder Gravity Department Falkowski Good morning. I’m Brendan Falkowski.
3. GravityDept.com I founded a small web strategy and design studio called Gravity Department.
4. Design Consulting For My work is split 50/50 between client services for companies like Skinny Ties and Angry Birds.
5. 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.
6. And MageFrontend: a responsive design toolkit for Magento Enterprise.
7. Magento Certification Advisory Board Member I’m also a member of Magento’s Advisory Board for certifying developers.
8. A day in the life Everything I do these days is multi-device in nature.
9. Responsive eCommerce Part One This talk is part two. I gave part one last year right here.
10. In 230 slides it covered: • Why mobile matters • Small screen methodologies
11. 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
12. 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.
13. State of Mobile & Commerce: 2013 Edition Let’s look at the state of mobile devices and commerce in 2013.
14. 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.
15. 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%.
16. Devices owned by US Adults http://pewinternet.org/Commentary/2012/February/Pew-Internet-Mobile.aspx These are the devices US adults own today.
17. 31% own tablet January 2013 31% have a tablet. That’s up from just 12% last year.
18. 87% own cell phone December 2012 87% have a cell phone.
19. 45% own smart phone December 2012 45% own a smartphone. That’s over half of all phones.
20. 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.
21. 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.
22. Responsive Commerce in the Wild Since last year, responsive design has started to take foot in eCommerce.
23. skinnyties.com We're still in the early days of figuring this out, but the early indications are promising.
24. indochino.com
25. nuts.com
26. currys.co.uk
27. unitedpixelworkers.com
28. oneillclothing.com
29. Content First Does this sound familiar?
30. “If our design was more modern, we’d have better sales.”
31. “Making our site mobile- friendly would be huge.” ~ D. Trump
32. 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.
33. Most problems are content problems. But, especially in responsive projects, they act like blinders that hide deep-rooted problems in your content.
34. Responsive web design is not all the devices + prettiness. Responsive design is not: all the devices plus prettiness. That’s the seduction.
35. 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.
36. Case Study: SkinnyTies.com Skinny Ties is client of mine.
37. 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.
38. 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:
39. Information Architecture We studied how users shopped for ties
40. and saw they look for black ties,
41. or silk ties,
42. sometimes one and a half inch ties with stripes.
43. Limited Navigation Options And when we compared that to the primary navigation it was obviously one-dimensional and inadequate.
44. 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.
45. 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.
46. New product schemas: • Descriptive • Consistent • Keyword infused We used that research to model new product schemas that were descriptive, consistent, and keyword- infused.
47. 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.
48. “Responsive design is Google’s recommended configuration.” ~ Google http://googlewebmastercentral.blogspot.com/2012/06/recommendations-for- building-smartphone.html And since Google prefers responsive design it’s a win/ win.
49. Product Photography Good photography sells.
50. 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.
51. In the new site, consistent bold photography is central to their content strategy and composition was tightly controlled.
52. We created comprehensive style guides for shooting and editing that defined standards for scale, orientation, angularity, white space, ambient brightness, and light hardness.
53. The results are stunning, especially on high definition tablets.
54. Knowledge Leadership Discoverability and photography only goes so far though. You still need to build trust and for Skinny Ties that meant demonstrating expertise.
55. It’s not enough to simply list product specs. By interpreting them we help customers with stylistic and practical advice:
56. How skinny should I go?
57. What’s the right fabric for winter?
58. Is it long enough?
59. Which knot is best for this width? And how do I tie that?
60. 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.
61. RWD was not the silver bullet. The point here is that responsive design as a technology was not the silver bullet.
62. 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.
63. 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.
64. 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.
65. Performance Responsive design is often criticized for having as much, if not more, bulk as desktop sites.
66. “What’s another pound to an elephant?” twitter.com/snookca/status/296746082837344256 Jonathan Snook wrote a great summary of why sites are slow:
67. This image is the perfect visualization of what’s happening with performance today. If content is the battle, then performance is certainly the war.
68. 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.
69. 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.
70. 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.
71. 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.
72. “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:
73. 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.
74. 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.
75. How do we improve performance? How do we improve performance? Ignore the backend.
76. 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:
77. 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.
78. Steve Souders literally wrote the book on high performance websites. He led performance engineering for Yahoo and is now at Google.
79. 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.
80. “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.
81. 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.
82. 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.
83. You cannot let sites swell unchecked. If you add something, you have to stay honest and take something away.
84. How do we measure performance? How do we measure performance?
85. 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.
86. Waterfall Charts For debugging, waterfall graphs in browser tools like Web Inspector and Firebug are invaluable when isolating specific scripts.
87. 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.
88. 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.
89. 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.
90. 1. Reduce HTTP requests. Use image sprites or icon fonts, and bundle dependent scripts together.
91. 2. Use DNS pre-fetching. Tells the browser to perform a DNS lookup before encountering assets at that domain.
92. 3. Use cookie-less domains for static assets. Prevent cookies from sending with non-dynamic requests.
93. 4. Use two domains for static assets. Modern browsers will download multiple assets in parallel.
94. 5. Put JS at the bottom. When the browser sees a script tag it waits until the entire asset downloads before it proceeds.
95. 6. Use asynchronous JS loading. The async attribute tells modern browsers they don't have to wait for the asset to load before continuing.
96. 7. Use one CSS file. The browser won’t start rendering until all CSS is downloaded and parsed.
97. 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.
98. 9. Use a Content Delivery Network. CDNs duplicate your content around the world, so it’s physically closer to users which reduces latency.
99. 10. Minify all CSS and JS. Minifying removes comments and whitespace to make files smaller.
100. 11. Use gzip compression. gzip crunches files up to 70% before transmitting.
101. 12. Optimize images. Use the right format and bit-depth for the content. Vary compression for quality or speed.
102. 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.
103. 14. Use conditional loading. Postpone delivering heavy assets like images or scripts until the moment the user needs them.
104. Further Resources speakerdeck.com/keithpitt/keith-and-marios-guide-to-fast-websites
105. 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.
106. 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.
107. 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?
108. 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.
109. 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.
110. 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.
111. 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.
112. 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.
113. 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/
114. 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.
115. 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
116. 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.
117. 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
118. 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
119. 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.
120. 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.
121. “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.
122. 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.
123. 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.
124. 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.
125. 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.
126. 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.
127. 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.
128. 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.
129. 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.
130. 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.
131. 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.
132. 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.
133. 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.
134. 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.
135. 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.
136. 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.
137. 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.
138. “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.
139. 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.
140. 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.
141. 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.
142. Touch Events in JS Multi-touch events can be used to make web interfaces feel more like native apps, but they can be tricky.
143. touchstart touchmove touchend They fire independently of one another with three basic events: touchStart, touchMove, and touchEnd.
144. 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.
145. 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.
146. Touch libraries https://github.com/dotmaster/Touchable-jQuery-Plugin https://github.com/cheeaun/tappable https://github.com/jonpacker/jquery.tap https://github.com/EightMedia/hammer.js But the simplest way is using a small library to detect taps:
147. 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.
148. 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.
149. Form Structures When I implement responsive forms there are two patterns I use:
150. 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.
151. 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.
152. When there isn't enough horizontal space for a scaffold form, it simply converts to a stack form.
153. 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.
154. Your user’s eyes should not do this. But it's inefficient and confusing because the eye needs to criss-cross between elements.
155. 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.
156. 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.
157. <input type="email" /> The email type adds "@" symbol to the alphabetic keyboard.
158. <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.
159. <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.
160. <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.
161. 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.
162. 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.
163. 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.
164. 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.
165. 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.
166. 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.
167. 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.
168. 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.
169. 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.
170. Social Widgets Social widgets are on almost every site today, and they’re some of the worst usability and performance offenders.
171. • 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.
172. 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.
173. 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.
174. I cannot jump the distance, you’ll have to toss me. So I usually get rid of those.
175. 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.
176. The Cost of Share Links 0 HTTP Requests <1 KB of data Zero extra HTTP requests and zero extra bandwidth with sprites.
177. http://socialitejs.com https://github.com/filamentgroup/SocialCount Missing social counters? One downside: no social counters. Of course there are plugins for that
178. 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.
179. 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.
180. 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.
181. 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.
182. 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
183. http://baymard.com http://uxdesign.smashingmagazine.com/tag/e-commerce/ Checkout Best Practices The Baymard Institute and Smashing Magazine are fantastic resources for checkout design best practices.
184. 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.
185. 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.
186. 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.
187. Woven Checkout We can do better than that, but it requires modifying Magento’s checkout significantly. I call it “woven checkout”.
188. 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.
189. Billing Address Shipping Method Payment Method Review + Submit Shipping Address Step Summary
190. Billing Address Shipping Method Payment Method Review + Submit Shipping Address Step Summary Step Summary
191. Billing Address Shipping Method Payment Method Review + Submit Shipping Address Step Summary Step Summary Step Summary
192. Billing Address Shipping Method Payment Method Review + Submit Shipping Address Step Summary Step Summary Step Summary Step Summary
193. 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.
194. 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.
195. Show Me The Money All that tech and design stuff is great. I love it. But it means nothing without driving business goals forward.
196. 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.
197. 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%.
198. 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.
199. 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.
200. Questions I regret to inform you this is the end. Questions?
201. GravityDept.com Falkowski