Steve Grunwell

Open-source contributor, speaker, and coffee snob

Notes from Build Responsively Workshop

The other week I attended the Build Responsively workshop, presented by Sparkbox out of Dayton, Ohio. The workshop was two full days of responsive web design evangelism and techniques. If you get a chance to attend a #BRWorkshop (they’re coming to Cleveland, Pittsburgh, and Grand Rapids in the next two months), I’d highly recommend it – while it certainly skews on the programming side, there were a lot of important business cases presented for why an agency might recommend responsive design to a client.

Being a geek in a room full of other geeks, I thought it would be cool to write my notes in Markdown, then put them in a gist so I could easily share them while updating them between sessions.

Responsive Design 101

Semantic grid system: http://semantic.gs/

They’d love to see an analytics script to track how often people are resizing the browser

  • add resize listener to the window, send GA event
  • git://gist.github.com/3076998.git

Subtractive vs. Additive styles

Subtractive styles – start large, remove items as the screen gets smaller

Additive styles (aka “mobile first”)

Responsive Planning and Design

  1. Priority guide (mobile-sized content prototype wireframe thingy)
    • Wireframes for small-screen to help determine content hierarchy and priorities
    • Cuts out a step of designer sketching/designing for mobile first
    • Dev gets direction on both desktop and smallest mobile
    • More visual decisions left to designer, not devs
  2. Style prototype
  3. Large resolution design
  4. Code responsive templates
  5. Content, design, and dev team members must review and collaborate regularly at every stage of the process (step 0)
    • We can’t “throw it over the wall” anymore…at least not if we want our sites to be excellent. There are too many moving parts.

Client Deliverables

Awesome clients (who trust you) are more likely to be receptive to these practices.

Getting a good start

Adobe Shadow (http://labs.adobe.com/technologies/shadow/) allows you to sync your sites across multiple devices and, more importantly, helps you debug CSS on devices!

Sparkbox recommends BrowserStack (http://www.browserstack.com/) for cross-browser testing. Allows you to work on localhost?!

Man, I really need to start using SCSS/SASS.

I’d love to see more people using Paul Irish’s conditional-comment <html> technique – it’s been a real lifesaver lately. That + modernizr = bliss.

Writing a backup for jQuery is always a good idea. I used to think it was silly…right until I had to give a client demo in a bar without wifi. http://css-tricks.com/snippets/jquery/fallback-for-cdn-hosted-jquery/

Lunch

Tacos + churros (sp?). Yum.

The Nitty Gritty

“Fluid presentation makes the separation of style from content critical”

Multiple <h1>s by using <article> and <section> elements? That’s pretty sweet, but this article from Smashing Magazine warns that current assistive technologies may not pick up on it:http://coding.smashingmagazine.com/2011/08/16/html5-and-the-document-outlining-algorithm/

Always remember: IE lte 8 don’t support media queries. Since first-gen Windows Phone 7 browsers use a version of IE7, you may need to use the IEMobile conditional comment: http://css-tricks.com/iemobile-conditional-comment/

CSS box-sizing property extremely helpful in simplifying responsive styling.

Should learn more about @media only all and (…) { } media queries – connected to pixel-ratio?

http://caniuse.com – compatibility tables for HTML5, CSS, SVG, etc. across browsers

High praise for* { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; } –http://paulirish.com/2012/box-sizing-border-box-ftw/

Responsive Challenges

Images

Apparent lack of bullet-proof solutions for responsive images (particularly not serving huge images to small screens) shouldn’t be considered a reason to not go responsive – until we find one, the user will still be getting the large images.

Idea:

It won’t help on request #1, but we could technically set a cookie client-side and access it server-side. We’d obviously need to listen for changes in the window size to update the cookie, but when we consider that most users aren’t frequently resizing browser windows it may help give the server some idea of the client viewport.

Complex Navigation

Some people take a more icon-based approach, some build accordion-style menus for more complicated navs (https://www.msj.edu/)

Process

More political than anything else. Somebody will lose prominent real estate.

There’s a lot that mobile devices can do better than the desktop (geolocation, etc.), so the mobile experience should be enhanced, not neutered.

More challenges

  • Ads
  • Big Tables

#AskEthan – Q/A with Ethan Marcotte (@beep)

@brworkshop: Do you design small and work up or design large and work down?

@beep: Both (as necessary), but teams should use whichever approach works best for them

@brworkshop: When building from scratch, do you use em-based or pixel-based media queries

@beep: Recently started with em-based (more future-proof), but the breakpoints should be tied to the design, not to arbitrary numbers

@brworkshop: Do you pronounce it [G]if or [J]if?

@beep: Gif FTW

@brworkshop: What techniques do you use to sell responsive design?

@beep: Demonstrate what responsive design is – resize the browser and let them see the changes (you can’t beat first-hand experience)

@brworkshop: How do you handle large data tables in responsive design?

@beep: An example: Semantically-rich table, media queries to disable particular columns by default, then let the user reveal additional columns as necessary

@brworkshop: What’s next in web design?

@beep: ::shrugs:: We’re not looking at different devices as different platforms, just different methods of access. We need to focus on and be more nimble with our content structure. We don’t have a good web design application yet – Photoshop isn’t everything we need.

// Focusing more on the answers than the questions:

  • We don’t have a reliable way to detect bandwidth yet, so rather than make assumptions try to to provide the user with the most performant version first and then let the user choose to have a high(er) fidelity experience if they have the bandwidth to support it
  • Primarily works in Textmate, but dabbles with Sublime Text 2 (“because it’s sexy”)

Emerging Patterns

Good examples (esp for tables) can be found here: http://www.zurb.com/playground

Navigation

Be careful with <select> menu navigation on smaller screens – if you didn’t use js to create that menu, you need to take extra steps to make sure that a small screen without js can still use it (submit the form)

[Data] Tables

Examples:

Images

  • Picturefill – Polyfill that mimics the behavior of the proposed <picture> element
  • Sencha.io – Proxy server that detects the image size, determines the appropriate size, and loads the proper image from your server through theirs.
  • Adaptive Images – Similar concept as Sencha.io but self-hosted

“…performance is important, but access is more important. Mobile later is better than mobile never” – Kristofer Layon

em-based media queries

http://cloudfour.com – uses em-based media queries – try increasing the font-size and refreshing.

Responsive Retrofitting

It’s rare that you’ll get the opportunity to start from scratch on legacy sites, so it’s important to take steps where you can

Something is better than nothing

Large Resolution First

Add media queries to your existing stylesheets

@media ( max-width: 650px ) { /* Adjust things for screens <= 650px */ }

Con: Subtractive CSS

Small resolution first (capped)

if ( Modernizr.mq( &#39;(min-width: 0px&#39;) ) { $(&#39;html&#39;).removeClass( &#39;no-mediaquery&#39; ).addClass( &#39;mediaquery&#39;); }

.no-mediaquery { @import main.css }

Then use media queries in your CSS for children of html.mediaquery until you get to the original resolution of the site (at which point you’d serve the legacy CSS via @import statements.

Cons

  • Larger stylesheets
  • Users without javascript that are using a modern browser will only get the original experience (which they’re used to anyway)

Responsive Javascript

Support for position:fixed on mobile browsers is spotty at best.

FitText – Automatically resize text on window resize

Scott Jehl apparently wants to fix the internet:

  • respond.js – A polyfill for media-queries in IE 6-8
  • cSSesntial – Only load the CSS files that we need for the current window

Jasmine seems to be a popular choice for javascript testing. According to Rob, it has a lot of momentum, a nice syntax, and no barriers to start using it (see http://try-jasmine.heroku.com/)

“I’ve actually been writing less code and [writing it] more efficiently” – @robtarr on TDD

The Future of #rwd

Modernizr

So totally awesome. Select the tests you need to keep the overhead down, then enjoy!

General SASS workflow

  1. Include our smallest CSS file
  2. Progressively load CSS files for higher resolutions using media queries
  3. Since IE8 and below will only see smallest.css, use a conditional comment to target IE8 and below (except IEMobile) and load those larger-resolution stylesheets in a ie.css

Moving forward

Four stages of learning:

  1. Unconscious incompetence
  2. Conscious incompetence
  3. Conscious competence
  4. Unconscious competence

The Responsive Dip by Ben Callahan

“The truly responsive design web designer wasn’t born until after the launch of the iPhone. We haven’t seen his or her work yet” – Andy Clarke

Things we need to embrace

  • Mobile first process
  • Performance as a feature
  • The server is our friend
  • Modular content systems
    • A single system that can manage content across multiple channels – no more “this is where we manage our social, this is where we manage our main site, this is our microsite, etc.”

Previous

Welcome to the new SteveGrunwell.com blog!

Next

200Columbus: The Bicentennial

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Be excellent to each other.