Responsive eCommerce: Part Two

Slide 1

Slide 1 text

Responsive eCommerce PART TWO Brendan Falkowski April 10, 2013 Magento Imagine Conference Las Vegas, Nevada

Slide 2

Slide 2 text

Brendan Falkowski Founder Gravity Department Falkowski Good morning. I’m Brendan Falkowski.

Slide 3

Slide 3 text

GravityDept.com I founded a small web strategy and design studio called Gravity Department.

Slide 4

Slide 4 text

Design Consulting For My work is split 50/50 between client services for companies like Skinny Ties and Angry Birds.

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

And MageFrontend: a responsive design toolkit for Magento Enterprise.

Slide 7

Slide 7 text

Magento Certification Advisory Board Member I’m also a member of Magento’s Advisory Board for certifying developers.

Slide 8

Slide 8 text

A day in the life Everything I do these days is multi-device in nature.

Slide 9

Slide 9 text

Responsive eCommerce Part One This talk is part two. I gave part one last year right here.

Slide 10

Slide 10 text

In 230 slides it covered: • Why mobile matters • Small screen methodologies

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

State of Mobile & Commerce: 2013 Edition Let’s look at the state of mobile devices and commerce in 2013.

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

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%.

Slide 16

Slide 16 text

Devices owned by US Adults http://pewinternet.org/Commentary/2012/February/Pew-Internet-Mobile.aspx These are the devices US adults own today.

Slide 17

Slide 17 text

31% own tablet January 2013 31% have a tablet. That’s up from just 12% last year.

Slide 18

Slide 18 text

87% own cell phone December 2012 87% have a cell phone.

Slide 19

Slide 19 text

45% own smart phone December 2012 45% own a smartphone. That’s over half of all phones.

Slide 20

Slide 20 text

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.

Slide 21

Slide 21 text

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.

Slide 22

Slide 22 text

Responsive Commerce in the Wild Since last year, responsive design has started to take foot in eCommerce.

Slide 23

Slide 23 text

skinnyties.com We're still in the early days of figuring this out, but the early indications are promising.

Slide 24

Slide 24 text

indochino.com

Slide 25

Slide 25 text

nuts.com

Slide 26

Slide 26 text

currys.co.uk

Slide 27

Slide 27 text

unitedpixelworkers.com

Slide 28

Slide 28 text

oneillclothing.com

Slide 29

Slide 29 text

Content First Does this sound familiar?

Slide 30

Slide 30 text

“If our design was more modern, we’d have better sales.”

Slide 31

Slide 31 text

“Making our site mobile- friendly would be huge.” ~ D. Trump

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

Most problems are content problems. But, especially in responsive projects, they act like blinders that hide deep-rooted problems in your content.

Slide 34

Slide 34 text

Responsive web design is not all the devices + prettiness. Responsive design is not: all the devices plus prettiness. That’s the seduction.

Slide 35

Slide 35 text

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.

Slide 36

Slide 36 text

Case Study: SkinnyTies.com Skinny Ties is client of mine.

Slide 37

Slide 37 text

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.

Slide 38

Slide 38 text

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:

Slide 39

Slide 39 text

Information Architecture We studied how users shopped for ties

Slide 40

Slide 40 text

and saw they look for black ties,

Slide 41

Slide 41 text

or silk ties,

Slide 42

Slide 42 text

sometimes one and a half inch ties with stripes.

Slide 43

Slide 43 text

Limited Navigation Options And when we compared that to the primary navigation it was obviously one-dimensional and inadequate.

Slide 44

Slide 44 text

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.

Slide 45

Slide 45 text

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.

Slide 46

Slide 46 text

New product schemas: • Descriptive • Consistent • Keyword infused We used that research to model new product schemas that were descriptive, consistent, and keyword- infused.

Slide 47

Slide 47 text

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.

Slide 48

Slide 48 text

“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.

Slide 49

Slide 49 text

Product Photography Good photography sells.

Slide 50

Slide 50 text

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.

Slide 51

Slide 51 text

In the new site, consistent bold photography is central to their content strategy and composition was tightly controlled.

Slide 52

Slide 52 text

We created comprehensive style guides for shooting and editing that defined standards for scale, orientation, angularity, white space, ambient brightness, and light hardness.

Slide 53

Slide 53 text

The results are stunning, especially on high definition tablets.

Slide 54

Slide 54 text

Knowledge Leadership Discoverability and photography only goes so far though. You still need to build trust and for Skinny Ties that meant demonstrating expertise.

Slide 55

Slide 55 text

It’s not enough to simply list product specs. By interpreting them we help customers with stylistic and practical advice:

Slide 56

Slide 56 text

How skinny should I go?

Slide 57

Slide 57 text

What’s the right fabric for winter?

Slide 58

Slide 58 text

Is it long enough?

Slide 59

Slide 59 text

Which knot is best for this width? And how do I tie that?

Slide 60

Slide 60 text

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.

Slide 61

Slide 61 text

RWD was not the silver bullet. The point here is that responsive design as a technology was not the silver bullet.

Slide 62

Slide 62 text

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.

Slide 63

Slide 63 text

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.

Slide 64

Slide 64 text

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.

Slide 65

Slide 65 text

Performance Responsive design is often criticized for having as much, if not more, bulk as desktop sites.

Slide 66

Slide 66 text

“What’s another pound to an elephant?” twitter.com/snookca/status/296746082837344256 Jonathan Snook wrote a great summary of why sites are slow:

Slide 67

Slide 67 text

This image is the perfect visualization of what’s happening with performance today. If content is the battle, then performance is certainly the war.

Slide 68

Slide 68 text

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.

Slide 69

Slide 69 text

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.

Slide 70

Slide 70 text

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.

Slide 71

Slide 71 text

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.

Slide 72

Slide 72 text

“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:

Slide 73

Slide 73 text

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.

Slide 74

Slide 74 text

Walmart Business Metrics for Performance webperformancetoday.com/2012/02/28/4-awesome-slides-showing-how-pagespeed-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.

Slide 75

Slide 75 text

How do we improve performance? How do we improve performance? Ignore the backend.

Slide 76

Slide 76 text

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:

Slide 77

Slide 77 text

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.

Slide 78

Slide 78 text

Steve Souders literally wrote the book on high performance websites. He led performance engineering for Yahoo and is now at Google.

Slide 79

Slide 79 text

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.

Slide 80

Slide 80 text

“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.

Slide 81

Slide 81 text

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.

Slide 82

Slide 82 text

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.

Slide 83

Slide 83 text

You cannot let sites swell unchecked. If you add something, you have to stay honest and take something away.

Slide 84

Slide 84 text

How do we measure performance? How do we measure performance?

Slide 85

Slide 85 text

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.

Slide 86

Slide 86 text

Waterfall Charts For debugging, waterfall graphs in browser tools like Web Inspector and Firebug are invaluable when isolating specific scripts.

Slide 87

Slide 87 text

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.

Slide 88

Slide 88 text

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.

Slide 89

Slide 89 text

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.

Slide 90

Slide 90 text

1. Reduce HTTP requests. Use image sprites or icon fonts, and bundle dependent scripts together.

Slide 91

Slide 91 text

2. Use DNS pre-fetching. Tells the browser to perform a DNS lookup before encountering assets at that domain.

Slide 92

Slide 92 text

3. Use cookie-less domains for static assets. Prevent cookies from sending with non-dynamic requests.

Slide 93

Slide 93 text

4. Use two domains for static assets. Modern browsers will download multiple assets in parallel.

Slide 94

Slide 94 text

5. Put JS at the bottom. When the browser sees a script tag it waits until the entire asset downloads before it proceeds.

Slide 95

Slide 95 text

6. Use asynchronous JS loading. The async attribute tells modern browsers they don't have to wait for the asset to load before continuing.

Slide 96

Slide 96 text

7. Use one CSS file. The browser won’t start rendering until all CSS is downloaded and parsed.

Slide 97

Slide 97 text

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.

Slide 98

Slide 98 text

9. Use a Content Delivery Network. CDNs duplicate your content around the world, so it’s physically closer to users which reduces latency.

Slide 99

Slide 99 text

10. Minify all CSS and JS. Minifying removes comments and whitespace to make files smaller.

Slide 100

Slide 100 text

11. Use gzip compression. gzip crunches files up to 70% before transmitting.

Slide 101

Slide 101 text

12. Optimize images. Use the right format and bit-depth for the content. Vary compression for quality or speed.

Slide 102

Slide 102 text

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.

Slide 103

Slide 103 text

14. Use conditional loading. Postpone delivering heavy assets like images or scripts until the moment the user needs them.

Slide 104

Slide 104 text

Further Resources speakerdeck.com/keithpitt/keith-and-marios-guide-to-fast-websites

Slide 105

Slide 105 text

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.

Slide 106

Slide 106 text

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.

Slide 107

Slide 107 text

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?

Slide 108

Slide 108 text

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.

Slide 109

Slide 109 text

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.

Slide 110

Slide 110 text

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.

Slide 111

Slide 111 text

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.

Slide 112

Slide 112 text

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.

Slide 113

Slide 113 text

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/

Slide 114

Slide 114 text

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.

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

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.

Slide 117

Slide 117 text

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

Slide 118

Slide 118 text

4. PictureFill https://github.com/scottjehl/picturefill 4. PictureFill. This is a JS polyfill for the proposed element. Pros: full control over asset loading, requires JS but has fallback Cons: complicated syntax

Slide 119

Slide 119 text

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.

Slide 120

Slide 120 text

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.

Slide 121

Slide 121 text

“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.

Slide 122

Slide 122 text

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.

Slide 123

Slide 123 text

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.

Slide 124

Slide 124 text

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.

Slide 125

Slide 125 text

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.

Slide 126

Slide 126 text

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.

Slide 127

Slide 127 text

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.

Slide 128

Slide 128 text

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.

Slide 129

Slide 129 text

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.

Slide 130

Slide 130 text

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.

Slide 131

Slide 131 text

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.

Slide 132

Slide 132 text

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.

Slide 133

Slide 133 text

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.

Slide 134

Slide 134 text

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.

Slide 135

Slide 135 text

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.

Slide 136

Slide 136 text

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.

Slide 137

Slide 137 text

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.

Slide 138

Slide 138 text

“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.

Slide 139

Slide 139 text

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.

Slide 140

Slide 140 text

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.

Slide 141

Slide 141 text

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.

Slide 142

Slide 142 text

Touch Events in JS Multi-touch events can be used to make web interfaces feel more like native apps, but they can be tricky.

Slide 143

Slide 143 text

touchstart touchmove touchend They fire independently of one another with three basic events: touchStart, touchMove, and touchEnd.

Slide 144

Slide 144 text

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.

Slide 145

Slide 145 text

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.

Slide 146

Slide 146 text

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:

Slide 147

Slide 147 text

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.

Slide 148

Slide 148 text

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.

Slide 149

Slide 149 text

Form Structures When I implement responsive forms there are two patterns I use:

Slide 150

Slide 150 text

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.

Slide 151

Slide 151 text

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.

Slide 152

Slide 152 text

When there isn't enough horizontal space for a scaffold form, it simply converts to a stack form.

Slide 153

Slide 153 text

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.

Slide 154

Slide 154 text

Your user’s eyes should not do this. But it's inefficient and confusing because the eye needs to criss-cross between elements.

Slide 155

Slide 155 text

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.

Slide 156

Slide 156 text

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.

Slide 157

Slide 157 text

The email type adds "@" symbol to the alphabetic keyboard.

Slide 158

Slide 158 text

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.

Slide 159

Slide 159 text

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.

Slide 160

Slide 160 text

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.

Slide 161

Slide 161 text

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.

Slide 162

Slide 162 text

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.

Slide 163

Slide 163 text

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.

Slide 164

Slide 164 text

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.

Slide 165

Slide 165 text

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.

Slide 166

Slide 166 text

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.

Slide 167

Slide 167 text

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.

Slide 168

Slide 168 text

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.

Slide 169

Slide 169 text

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.

Slide 170

Slide 170 text

Social Widgets Social widgets are on almost every site today, and they’re some of the worst usability and performance offenders.

Slide 171

Slide 171 text

• 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.

Slide 172

Slide 172 text

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.

Slide 173

Slide 173 text

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.

Slide 174

Slide 174 text

I cannot jump the distance, you’ll have to toss me. So I usually get rid of those.

Slide 175

Slide 175 text

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.

Slide 176

Slide 176 text

The Cost of Share Links 0 HTTP Requests <1 KB of data Zero extra HTTP requests and zero extra bandwidth with sprites.

Slide 177

Slide 177 text

http://socialitejs.com https://github.com/filamentgroup/SocialCount Missing social counters? One downside: no social counters. Of course there are plugins for that

Slide 178

Slide 178 text

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.

Slide 179

Slide 179 text

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.

Slide 180

Slide 180 text

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.

Slide 181

Slide 181 text

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.

Slide 182

Slide 182 text

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

Slide 183

Slide 183 text

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.

Slide 184

Slide 184 text

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.

Slide 185

Slide 185 text

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.

Slide 186

Slide 186 text

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.

Slide 187

Slide 187 text

Woven Checkout We can do better than that, but it requires modifying Magento’s checkout significantly. I call it “woven checkout”.

Slide 188

Slide 188 text

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.

Slide 189

Slide 189 text

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

Slide 190

Slide 190 text

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

Slide 191

Slide 191 text

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

Slide 192

Slide 192 text

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

Slide 193

Slide 193 text

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.

Slide 194

Slide 194 text

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.

Slide 195

Slide 195 text

Show Me The Money All that tech and design stuff is great. I love it. But it means nothing without driving business goals forward.

Slide 196

Slide 196 text

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.

Slide 197

Slide 197 text

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%.

Slide 198

Slide 198 text

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.

Slide 199

Slide 199 text

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.