In his RWD workshop this last weekend at GiantConf 2014 Brad Frost plowed through the history, current state, best practices and possible futures of the RWD philosophy/approach. Here are my notes from his talk.
June 14, 2014
His experience: web on mobile for 4+
- Responsive Design Patterns
- ThisIsResponsive.com website and github (http://bradfrostweb.com/blog/web/this-is-responsive/ & http://bradfrost.github.io/this-is-responsive/index.html)
- (older site) – Mobile web best practices
- WTF Mobile Web (what not to do)
- Cosigner of Future Friendly Manifesto
- Worked for R/GA at one point…showed the company logo slide to illustrate that no one knows what they’re doing.
General Landscape
- i6bb mobile subscriptions
- in america, 91% of americans have a mobile… 56% of those are smart phones.
- 1.5 mm android activations a day
- 1/3 americans have an ereader/tablet
- 20% of ALL internet traffic is mobile
- 68% of americans access the web via phone
- 33% of those ONLY use the mobile web
- Mobile web pictogram –
- 157mm users ONLY use FB from their mobile
- What are we sharing from mobile on social? (text photos videos and LINKS)
- 51% of referral traffic to media sites came from FB mobile
- blog.cloudfour.com – good status on mobile – a comprehensive guide
Approach – Options
- Do nothing. (rant: cultivating a nation of slide swiping screen surfing zombies)
- Make an APP!
- App glut
- Links don’t open apps
- pros and cons of course
- Separate Design Experiences (Nielsen’s advice, to build two sites and cross-linking to make it work.)
- more dedicated, optimized, catered experience
- no need to adapt
- potential to be more performant
- url redirection (getting a mobile version of a site on your desktop due to a link given to you)
- content parity
- content governance
- device database
- SEO issues (better to keep your links under the same single site)
- Continuity issues
- The Space Between (kindle fire, etc.)
Strategy
- Build a barebones mobile responsive site, and grow it over time.
- Responsive retrofitting a site
- j spool’s ‘escalator of acquired knowledge’ (people hate when you completely tear down and rebuilt their beloved sites)
- Mobile First (progressively enhanced, future friendly, awesome)
- Piecemeal approach: “our responsive header is almost done”
- seen on really huge sites in recent times. footer, header, module by module
- acclimatizes the user
- he’s only seen it in large companies, but he thinks it could work very well for small
companies/sites/teams, perhaps more so.
-
eventually kill the old clunky desktop site
Foundations
- Ethan Marcotte @2010 in ALA
- Fluid Grids, Media Queries, Flexible images
- the Fluid grid should do most of the heavy lifting! (don’t go crazy with media queries!)
- Context is needed
- Adaptive is a bigger container than responsive, and itself contains responsive
- There are other parts, but RWD is what stuck.
- Feature Detection
- Server side components*
- interdevice communication
- performance, etc.
Principles of Adaptive design
- ubiquity (this is for everyone, for anyone, for us all
- diversity is not a bug, it’s an opportunity) – step reiger
- mobile users will do everything desktop users do, if it’s accessible.
- Content parity
- Context
- Quantitative
- Qualitative
- flexibility
- embrace the squishiness
- performance
- 71% of mobile users expect mobile sites to load as fast or faster than desktop sites
- you have 5 seconds of someones time…
- Future friendly – Invest in your content. -> Make APIs, not war
Frameworks
- Bootstrap, Foundation by Zurb, etc.
- Jetstrap/Bootkit
- these are all well and good, but lead to look alike issues
- One-size-fits-all
- Potential for bloat/unneeded stuff
- might not do what you need
- integration issues
- have to subscribe to someone else’s decisions
- Tiny Bootstraps, for every client. – Dave Rupert
- Front end style guides
- promotes consistency cohesion
- easier to test
- better workflow*
- creates a shared vocabulary
- useful reference
- Lots of front end style guides coming out (started with starbucks. starbucks.com/static/reference/styleguide)
- problems with these:
- Time consuming to create
- treated as an auxiliary project
- often too abstract
- often seen only as a designer/development tool
- created after a project launches
- often incomplete, only serving present use cases
- often lack a clear methodology
Atomic Design
- josh duck’s periodic table of html elements
- @dmolsen
- Abstract ————————-> Concrete
- Creators ————————-> Clients
- Atoms, Molecules, Organisms, Templates, Pages
- Reference, Build, Build, Build, Reference
the pattern
- ATOMS (input field)
- Molecules (search module)
- Organism (site header)
- Templates (site header bundled into a whole page template) -focus on content structure (reference to mark boulton.co.uk – content strucure first, not required to have content first)
- Pages (the pouring in of real & true representative content to see if it all works)
- validate or invalidate the atomic design thus far
- you test variations of the template at this point (still the same template though!)
- does it scale? (content length, list item length, etc.)
pattern lab
- @dmolsen Dave Oldsen and Brad created it
- Open source project
- What is it?
- It’s a design system BUILDER
- designed to help you execute a design system
- a custom component library
- a pattern starter kit
- a practical viewport resizer
- an annotation tool
It’s NOT:
- a UI framework
- Language, library, or style dependent
- Incredibly rigid
- “just” a pattern library, but also not a prod ready static site generator
- ..like Jekyl
moving parts
- builder
-
mustache for templating the guts
JSON for piping in real content
- ish (gives you a different value every time (small button gives you a smallISH value)
- Lets you rapidly preview random and different layout scenarios
- displays the size of the display currently in view.. as px and ems. Annotations
- his issues with wireframes in general… long assed annotations, iXds are working in a layer of abstraction
- The annotation tool couples numbers with an overlaid layer of annotated description
- Annotations with JSON
- Lineage
- Shows off what components make up a particular component, and where its applied.
- ‘X pattern contains the following patterns’
- ‘x pattern is included in the following patterns’
Other stuff
- code view
- pattern status
- auto refresh
- page follow
- Future: plugins
- idea of checking your performance budget whilst developing with Pattern Lab
What’s the hardest aspect of responsive web design?
- design/dev or people/process (overwhelmingly process/people)
- Entertainment Weekly
- you have to sell people that RWD is the right thing
- using data (showing conversions, improvement metrics – hockey sticks)
- SHOWING not TELLING is a lot easier to sell through to clients
- talk about the simplicity of the 3 pillars (flex grid, resp images, media queries)
- why RWD matters, selling to Tiffany in his R/GA days:
- He took a representative page from their site… (their desktop site), and demoed how it COULD be if set up properly
- It took him half a day…
- they then took a crapload of devices and spread them out on a long table… two tabs open on each device one for now vs possible Set Expectations
- Don’t sell websites like a painting. Instead, sell easy and sexy access to content, agnostic of device, screen etc.
- Kill the waterfall! IA->VISUAL->DEV = no good Interface Inventory
- He took a representative page from their site… (their desktop site), and demoed how it COULD be if set up properly
- Much like a content inventory, but more specific
- pick out, cluster, and inventory the buttons, inputs etc. – this illustrates the differences, similarities, the scope of the current interface situation
- This helps you gauge LOE on a redesign!
- Document your interface
- Promote consistency
- Establish which elements will be challenging to translate into RWD
- lays groundwork for future style guide/pattern library
- Evernote for Interface Inventories – Aaron Gustafson
Establish Direction
- before too long, you can design for the content structure you KNOW will exist
- use of style tiles for visual direction – more specific than a mood board, but not getting too far down into the weeds
- use of Typecast for brainstorming and playing with potential typographic treatments
Rolling up your sleeves
- build out basic patterns based on design sketches
- moving into element collages (still not full comps)
- often start with header and footer
- often end up with odd states.. ie a finished header and footer but very rough main content well – this requires frequent communication with client so they know how the process is flowing
- A traditional comp might not happen until nearly the end of design process …and might be a coded comp vs a photoshop comp
Responsive Patterns
- he collected design patterns, in b&w & very barebones. (thisisresponsive.com)
created to avoid re-explaining patterns again and again Layout
Grids
- Which grid system should i use? (he doesn’t care 😉
- Css tricks.com don’t overthink it grids
- Future of CSS Layout
- Grid Layout
- Flexbox (see solvedbyflexbox.com)
Media Queries
- avoid desktop-first styles (don’t set defaults only to have to overwrite them!)
- mobile first styles start from the perspective of small (using min-width vs max-width)
- the absence of support for media queries is in fact the first media query. – Bryan Rieger
- Let CONTENT, not screen size, determine breakpoints
- Start with the small screen first, then expand until it looks like shit. Time for a breakpoint! – stephen hay
- HAY mode in Ish (in hay’s honor)
- use of EMs in media queries – no longer a strict best practice, but a matter of preference
- Still recommend using relative units (he has no pixel values in his styles)
- Use major AND minor breakpoints (minor being a component level breakpoint or page level breakpoint)
- don’t overdo it
- ??? about localization and media query usage (german text is longer….)
- option 1: use the longest localization by default (his recommendation)
- option 2: apply a differentiator (addl class on the body tag etc.) and add/modify german specific styles Multi-Device Layout Patterns
Mostly Fluid patterns
- The Column Drop
- be careful that the stuff in the sidebars isn’t necessarily related to the main content (due to content hierarchy concerns)
- The Layout Shifter (brad voids these if possible, preferring simplicity)
- ie a complex, unique layout that really changes across breakpoints
- Tiny Tweaks – ie very little changes..
- minor font size or margin changes
- The Off Canvas (jason weaver – jasonweaver.name/lab/offcampus)
- stuff hangs out off screen until needed
- Content Choreography
- content folding (ie folding ads in between articles)
- could use flexbox (jordanm.co.uk/lab/content)
- could use AppendAround: a responsive Markup Pattern
- from Filament Group
- Don’t use this all the time, but it could help solve certain issues
Layout considerations
- When users scroll on mobile we are moving backward through time
- moving through a list
- deep dive into content
- All these instances are scrolling through a singular content type
- don’t mix up your content types when you put stuff into a single column with RWD.
Conditional loading:
- given the % of sites that push the same heavy content to mobile as desktop…
- Aggressive enhancement (nice term)
- The Thing (a) beside and above NOT The Thing
- Instead, include links to the “not the thing”s by fragmenting out that content
- put these fragments behind a lazy load and a user opt-in (via accordion for example)
- old browsers treat as links to different pages
- newer stuff fetches via ajax and drops it into the expanded module
- Larger format views display the whole thing by default
- (24ways.org/2011/conditional loading for responsive designs)
- Boston Globe does this with their weather widget
- either drives to a different page OR
- displays inline via async call How to do this?
- Matchmedia.js (has polyfills too)
- enquire.js
- Conditional CSS (adactio)
- Progressive disclosure as a term http://en.wikipedia.org/wiki/Progressive_disclosure
- Scanability vs capability is a balance
- It’s ok for different users to get a different experience as long as functionality remains accessible
- Screen size is just ONE variable.. (touch capability, etc. are others)
- Large screens do not always mean fast connection !!
- you can generalize somewhat
- you can TRY to detect bandwidth but it’s complex
- things like Boomerang test bandwidth by pinging all the time (hard on batteries ouch)
- Just design a fast experience!
- be mindful of the # of http requests
- look into server-side optimization
RESS ala Responsive Design + Server Side Components
- lukew.com ‘s article
- described as a scalpel
- if on a mobile device, don’t load (this annoying thing)
- if on desktop, DO load (this crazy thing)
Touch (ala accommodate for meat sticks)
- hybrid devices make things complex (windows tablets, Chrome Pixel, etc.)
- assumptions around touch targets, margins must be questioned
- keep everything touch friendly by default
- same issues on phablets (save for tests for touch etc.) Touch considerations
- don’t rely on hover states (don’t put important stuff there)
- if the info isn’t important, defer it (ie to a product detail page)
- or have it toggle display via touch.. BUT
- touch implies intent, so you can run into trouble here
- touch to toggle content is anticlimactic if users were trying to DO or GET something vs just exposing content
- Patrick Lauky – good source for touch related experimentation
- Look for opportunities to provide enhancements for touch devices, such as swipe gestures
- but be careful. careless touch input can result in unwanted effects or false positives.
Navigation
- Navigation should be like a good friend… there when you need them, but cool enough to give you your space.
- don’t make users scroll through lots of nav to get to content Tactics
- Do nothing (leave nav as is)
- doesn’t scale for larger navigations
- Footer Anchor
- nav clicks drive user to footer via named anchor (no js used)
- somewhat disorienting (might be a good baseline pattern to be enhanced further)
- The Select Menu (ie. the drop down menu)
- good for non-primary navigation
- The Toggle (the current go to best practice)
- Content slides down and exposes navigation
- elegant
- keeps users in place
- relies on javascript
- The overlay (variation on the Toggle)
- does not drop content down
- unwanted link navigation on older devices (ie click goes to lower stacked element anchors)
- unwieldy (he tries to keep things on one plane)
- The nav flyout
- pro & con: Able to display LOTS of nav items
- the go to for content-heavy sites
- consider content inventory/strategy if you’re having to deal with a super long flyout menu
- The Priority + considerations approach
- Partial exposure of nav based on priority, with ‘…more’ link to expose the entire nav
- not a fan, but considers it worth exploring
- The HIDE and CRY
- no nav on mobile (ack) that comes close to desktop experience
- muy mal “mobile users don’t do/need that…” Complex Navigation
- The Multi-Toggle
- ie. nested accordions ad infinitum
- behavior variations with touch devices.. (primary nav no longer can drive to a page, but must expand the subnav as only choice)
- Solution: add another item “all x products” effectively acts as the click through for touch that desktop had.
- Right to Left (nav panes slide left or right based on clicking nav arrows in nav)
- follows nav convention of drilling in/out
- right = deeper, left = shallower
- sony did this, but is no longer using it
- Skip the Subnav
- on small screens, just drive to the nav item’s landing page and then expose the sub navigation
- the main downside (but not a huge one) is you are forcing a full page refresh to get to desired destination
Navigation considerations
- Find the balance between nav access and obtrusiveness
- Test!
- Be explicit about the nav icon (as much as you can)
IMAGES
- avg 1.78mb page load —- 1.12mb of that are images. Images are a huge issue.
- various screen sizes
- growth of high res screens
- varying bandwidth
- need for art direction ie diff crops, etc.
background images
- these work as advertised, ie they behave properly in media queries
- ie multiple backgrounds aren’t downloaded
- use mobile first background images
- don’t include large by default, introduce them in a media query block
- Icons
- many times they don’t look good on hi-res screens
- use of ICON fonts is growing, and becoming a best practice
- IcoMoon – quickly choose or build your own libraries and generate your own iconFont
- Web Fonts (including Icon fonts) are NOT supported in a couple key browsers
- Opera MINI – a proxy browser preloaded on many feature phones and smart phones
- (proxy browsers end up taking very little bandwidth)
- Older Windows Phone devices don’t support them.
- Grumpicon converts images or svgs as data
- can also use png image fallbacks
- Grunticon output
- important stuff -> All icons inline in the css as vector svg data urls (better support)
- all icons inline in the css as PNG data urls
- All of the icons referenced externally as png images, which are automatically generated from the source SVG and placed in a directory alongside the CSS files
Image Considerations
- Vectorize all you can
- use HTML special chars
- use icon fonts, but with fallbacks (SVG)
- If you use sprites, consider making a hi res sprite sheet
- Semantically important images
- preserve aspect ratio (brucelawson.co.uk preserving aspect ratio)
- Avoid text as images!!! (duh)
- Responsive image considerations
- Ensure content is legible on small screens
- Larger dimensions, higher compression rate (blog.netvlies.n/design-interactive/retina-revolution/)
- Looks great on hi res screens and regular screens
- repainting the canvas is expensive performance wise (affects any fluid image)
- still doesn’t’ provide art direction (example: obama at car factory – crop needed for mobile view)
- only make 1 image request per asset
- load the small image asset by default
- consider server-side detection
- WHATEVER you do, make sure it’s easy to swap out. It WILL be deprecated 🙂
- Art Direction
- Focal point cropping: – designshack.net/articles/css….
- HTML5 Picture element is solidifying (finally)
- uses Jehl’s picture fill as a fallback?:
- accessible text
- SizerSoze.org (what is the cost of your non-responsive images?)
- calculates the savings if you were to use the above solution in your site
- SRC SET:
<.img src="small.jpg" srcset="large.jpg 1024w, medium.jpg 640w, small.jpg 320w" sizes="(min-width: 36em) 33.3vw", 100vw" alt="a rad wolf" />
- One beef was that it wasn’t using media queries (at one time)
- but it’s a nice quick easy way to explain multiple sizes of an image
- check out Coyier’s article on SrcSet vs Picture element
Video
- Srcset
- fitvidsjs.com (by coyier)
- some sites have good examples how..
- vimeo, etc
- embedresposively.com
Maps
- brad’s adaptive-maps badfrostweb.com/blog/post/adaptive-maps
- apps hijacking the user’s attempt to browse for a navigation (not a bad thing, actually)
- using Google’s maps API via a link from the page’s representation of the map
- if screen scan accommodate the EMBEDDED map, instead just load the embedded map (example, min-width: 700px )
Lightboxes
- example of a non-scaling pattern on Mashable
- not all desktop patterns scale to the small screen
- example of FB’s ‘create event’ dialogue on mobile/vs desktop
- Conditional Lightbox
- link to the raw image or chunk of content
- detect screen size
- ensure content is legible on small screens
- if screen is big, inject the lightbox functionality
- Magnific Popup – free responsive jquery lightbox plugin (also works with Zepto)
Data Tables
- Table to name/value pairs
- Table to List
- Priority Columns (the important data persists, others get pushed into a ‘display more’ collapsed state)
- Horizontal overflow (locked column approach)
- Test lots! (some android devices don’t support this)
- Consider using combinations of these to meet needs
- Considerations for tables
- What the data is like matters
- how closely linked is the data’s display format to its semantic value?
“Modules”
Carousels
- make sure you actually need one
- runyon found that the % of folks that make it to panel #2 (of interactive carousels) is less than 5%
- shouldiuseacarousel.com (rounds up the numbers on usage and effectiveness)
- cycle through items that are similar (vs disparate item types)
- only load what you actually need
- be CLEAR about your carousel’s functionality ( “…” is not enough)
- suggest more content to users
- provide gestural hints (content overhang off screen)
- opera mini; doesn’t support touch events
- by default, provide fallback navigation (and replace it if touch is supported)
- Types of Carousels
- The Reveal (as screen space goes up, they expose more products in the carousel)
- takes great advantage of larger screens, avoids the ‘stark & empty’ effect
Accordions
- Tabs to Accordian: codepen.io/sturobson/full/xgfel (converts tabs to an accordian)
- Accordion to Full: each section/subsection becomes an accordion section (ie collapses)
- when there’s enough room, it displays in full
Forms
- Label alignment shifts (top labels for small screens, left for full screen)
- he prefers keeping them in the same place
- Float Label – animated floated label that kicks in when default text is overwritten by user input
- Float Label Form Interaction on Dribble
- Internal labels: pros and cons
- the field itself becomes a button/field.
- saves lots of vert real estate
- not so good accessibility
- you lose field context when you enter text (since you’re overwriting)
Form Considerations
- subtract as much as possible
- use proper input types
- chunk stuff up (multiple input phases allowing users to save progress (ie 1/4… 2 of 4, etc.))
- use input types (number, email, url, tel) – this is the lowest hanging fruit here
- they all fall back to text if not supported
- Provide hinting
- be careful with inline labels
- validation but not too aggressive
- Opting out of RWD
- css-tricks.com/user-opt-out-responsive design
- don’t use fixed positioning
- very buggy on older browsers
- just really goofy
- burns up valuable real estate
- Position: Fixed considerations
- If it must be used, fixed headers are more reliable as they degrade more gracefully
- avoid JS solutions
- be mindful of orientation change. use media queries to disable fixed for landscape orientation
- conditionally introduce fixed positioning when screen space becomes available
Development
- Viewport metatag – tells browser to ignore its zoomed out state
- viewport in CSS
- @0webkit0-viewport {width: device-width} — etc.
- don’t disable the user’s ability to pinch and zoom
- only introduce the viewport meta tag when you’re sure the content is mobile-optimized
- CSS
- Border:
- SASS
- plain css is inefficient
- nesting is awesome in SASS
- variables are amazing
- putting media queries into SASS vars is a fav of his
- Nesting media queries
- changed his life forever
- .module { margin: 0 0 1em; padding: 1em; @media all and (min-width: 50em) { float: left; width: 50%; }
- Getting Sass to help with legacy IE -> nicolasgallagher.com
- respond.js by Scott Jehl
Device Support
- what should i support?
- iOS
- Android
- repulsive yet relevant
- ie mobile, blackberry, silk, nokia etc.
- There is a difference between SUPPORT and OPTIMIZATION – focus on accessibility
- Redux: Ubiquity
- our responsibility to make content accessible across the world, across economic and social spectrum
Testing
- remote testing tools (browserstack)
- viewport resizing tools
- Test on actual devices
- truly test a design’s performance
- Device capabilities
- Form factor
- Pixel Density
- Impact of the network
- Device Criteria
- your traffic, form factors etc. budget
- test w/o breaking the bank – brad’s post from bradfrostweb.com
- OpenDeviceLab.com