Workflow

What should the client deliverables be in #rwd?

@bencallahan

Depends on the client and scope of the project. HTML prototypes are ideal because they are closest to the real thing. Mockups communicating how to site will look at different widths may be sufficient though.

@anna_debenham

Of course, it depends. That's down to the individual designer and client to figure out. But it's safe to say prototypes are very useful in the RWD era. And we should be talking about delivering design systems (modules, libraries, directions for assembly.) But I also still deliver a few comps, as representative instances of that system. Better for the client to interpolate between those than for me to waste their budget comping up every permutation. Keyframes, not wireframes.

@cennydd

We agreed it's important to move away from 'ta-da!' presentations and not be afraid to show the client the mess along the way.

@armstrong

Responsive design is not economically viable for most agency work

@finalcontext

More accurate to say agencies haven't yet found the way to present the value proposition and sales pitch around RWD. Ultimately its sustainability and audience potential give great business benefits. If an agency wants to practice RWD, it needs to figure out how to explain that value, and secure budgets that allow them to do it properly.

@cennydd

You gotta learn somewhere. Only through practice will you be able to get better/faster/more viable at RWD. Consider eating some of your time if the payoff looks worth it.

@nathan_ford

RWD definitely takes longer when you're approaching it with the traditional workflow, but agencies that are taking a more agile, iterative approach are finding that it doesn't take much longer than a static site. We just need to get the workflow right.

@armstrong

WD is not a one-size-fits-all solution, but has been promoted as such within the industry. Discuss (briefly)!

@monro

Seriously, I don't think anyone has been presenting RWD as one-size-fits-all. If they are, they don't really get it. It's a sensible option to address some of the flaws of fixed sites, but it definitely leaves many problems unsolved.

@cennydd

Rather than code techniques, examples and usage. I'm more interested in appropriate workflow for design for a varied and fluid web

@sturobson

This is one of those discussions that always ends in Agile. And rightly so. The mindset it represents is the natural destination for any RWD workflow, although Agile proponents are often far too concerned with the process minutiae.

@cennydd

I want to do more with responsive design, but I lack test devices (and the Android simulator is rubbish). What can be done?

@kapowaz

The Opera and RIM emulators are excellent.

@lewisnyman

a large list of emulators is available here http://www.mobilexweb.com/emulators

@stephanierieger

Android handsets are cheap as chips, so a web developer doesn't have an excuse for not having at least one knocking around. I've also heard of informal schemes where people pool their devices between a bunch of freelancers / agencies.

@cennydd

Someone could make a fortune selling 'testing kits' of old devices

@armstrong

Why specify something as responsive when its just proper webdesign?

@lslinnet

Like 'user experience', it's a useful phrase to reset expectations and mindsets. It's possible that will fade away with time.

@cennydd

I have tried to stop qualifying decisions and explanations with “in Responsive Web Design”. The process of making sites responsive works best when thought of as part of the whole, rather than a new technique.

@nathan_ford

I imagine in the future when RWD is ingrained in our workflow it will simply be known as web design.

@katherinecory

Mobile JQuery & Responsive Design

@zigbot

jQuery mobile is a very heavy handed framework. 24K + 30k jQuery requirement + 7kb of supporting CSS

@lewisnyman

Is #rwd the final nail in the coffin for PS/FW comps? Or still a means to an end? I think we need _all_ our tools more than ever

@kevadamson

We still need comps at certain stages in the design process. Use the right tool for the right context/conversation. Comps help us convey (and pitch) mood, look and feel and branding. Responsive wireframes/design in the browser (or whatever you choose to call it) help convey behaviour at various contexts. We tend to alternate between the two through much of the project (along with the odd 'traditional' wireframe to document data mappings etc.

@stephanierieger

Not at all. RWD means we have to rely on skill more than defined process - creating static comps is definitely a relevant skill to have, but we can't rely on it as our primary method any more. Sketching, design in the browser, prototyping all become more central to digital design thanks to RWD

@cennydd

What size screen and functions should we design towards, there are so many more than we can really design for but are there a few key sizes we could design for and the rest fit in or should we be elastic designing?

@andykinsey

I would recommend 'phone', 'tablet-like-thing' (roundabouts a 10" tablet tends to work well), then a traditional desktop size. Give it about 18 months and we'll need to consider TVs as well. Everything else can typically be handled with a the flexible in between aspects of the design (although small, 7"-ish tablets are worth giving a bit of extra thought as they sit somewhere in the middle)

@stephanierieger

How should we prioritize content at smaller screens. Maybe 90% of the stuff HAS to be there. How can we solve that?

@ndrsn

I use Page Description Diagrams a lot for this. Viewpoints have to come from the client (usually through a painful but useful meeting where you go through each element on the page), the designer, and customers through user testing etc.

@cennydd

Should pixels be abolished?

@armstrong

Not sure we'll be able to do that given that bitmap images are inherently pixel based (and you can't use SVG to replace a photo of Angelina Jolie on the red carpet!)

@stephanierieger

Should we stop building websites that are unresponsive totally?

@viktorbijlenga

You'd be hard pressed to say never but unless you're building for a specific device you're going to struggle to find one width to design for.

@lewisnyman

Do you think we could ever have a 'A Real Web Design Application'

@jamesgooddesign

I don't think so. The problem with some of our current tools is that we use them to do more than one tool can reasonably accomplish. Photoshop gets a lot of stick but it was never designed to be used in web design. I think its more likely we'll see people start to tackle specific problems with niche tools that do one thing really well.

@paulmckeever

With so many moving parts (different layouts for different screens, HTML/CSS, behaviors, etc.), web design will always need to be choreographed across multiple tools, mostly in a designer’s head. I agree that we will likely see more niche tools that solve specific problems really well, rather than a Web Design App™.

@nathan_ford

responsive design: 3 PSDs instead of 1 or designing to the device?

@tmaslen

It depends on your design. Maybe your components need more than three breakpoints. Prototype interation early on can help you work out how much guidance you need from static comps.

@lewisnyman

Transitioning an enterprise to responsive design

@shaunmadams

Same way you eat an elephant: in small chunks. It'll take a long, long time because mostly it's a cultural and mindset change rather than a workflow or technical one. Show good practice, experiment, measure results, talk about successes rather than theory.

@cennydd

Responsive design != User experience. I don't think is just adjusting the layout to the device width. How can you brink the appropriate UX to specific device?

@ivanico

Enormous question that really needs a book. But we already have successful user-centred design tools at our disposal - research, sketching, prototyping, iteration all work well. Get your designs on the devices in question, and iterate, iterate, iterate.

@cennydd

Does mobile first really need to be Commandment #1, I have to entirely rebuild my design once it scales up.

@jeffscottward

Realistically, it's way easier to enhance than it is to somehow hide/replace/remove stuff you have already. That's why mobile first makes good sense if you are starting from scratch.

@stephanierieger

I think MF has been a great phrase to reset our understanding of how to design for the web. But I find it overly dogmatic. Mobile may be the right place to start, but it may not be. Leave that down to the choice of a skilled team.

@cennydd

does it cost our clients more for us to care about responsive web design

@gradualist

Realistically, yes. But, done right, the client will see business benefits.

@cennydd

We need to not only think of smaller screens in RWD but larger too - but this often seems to get left behind, particularl with "mobile-first" techniques and ideas. How can we encourage people to think about the larger picture or vision as well?

@missrachilli

I think it's a bit early right now but mobile-first isn't incompatible with larger screens if you think of it as "start with the base content and behaviour, then enhance based on features/capabilities"...screen size is obviously one of those features

@stephanierieger

Should there be a "best-practice" guide for RWD?

@missrachilli

I think Thursday showed that everyone has their own "best-practice" way of working, all were valid but unique to every designer. I think because RWD is it's infancy there are no guidelines yet because we're still figuring out the "best-practice" way to handle images, advertising etc. Eventually, I hope for a community-led document/book with the basic standards and guidelines that designers can continue to interpret into their own "best-practice" guidelines but at the moment it's too early.

@katherinecory

Should the content on a responsive site be the same as the main site or is it ok to loose items

@nickthorley

I believe core content and functionality should be the same. However, the tricky bit is figuring out what's core and what's expendable. And of course if your research and testing shows you need to take a different approach and cut things, do that rather than stick blindly to the script.

@cennydd

How come html5/css3 promotes rather than minimisez use of JS?

@meep

I don't believe that html5/css3 explicitly promotes the use of Javascript. The reality is that html5/css3 are still evolving and in order to use things that are still on the cutting edge, you need to employ some Javascript. Ideally we could lessen our dependence on it but the fact remains that if you are using Javascript to progressively enhance your designs, then you will still be in good shape when it is not available.

@jbrewer

Can you find sthg less bloatware than bootstrap?

@humbug

Zurb's foundation is a similar concept, not sure if it's lighter or not though

@armstrong

I'd love to hear more about responsive experience, i.e. this blog post by Mark Boulton

@theingrid

Please see the list of links here.

@jbrewer

Layout

Fluid grids break the link between the proportions of the content and the proportions of the grid, making fluid designs less aesthetically beautiful than fixed-width ones. How do we address that?

@jonikorpi

We 1) observe the nature of fluidity, 2) challenge aspects of CSS that conflict with the nature of fluid graphic design, and 3) attempt to hack around any limitations. See: http://nicewebtype.com/x/4y

@nicewebtype

I think the most robust responsive designs are going to be a mixture of fixed and fluid elements. The main challenge seems to be keeping white space in check while not breaking the relationships between elements (i.e. the logo on the top left getting too far from the nav on the top right). Define what needs to be fixed for your site (e.g. on a blog a good reading measure is important), and use fluid elements to fill in the gaps.

@armstrong

designing for content vs. canvas - pros and cons

@champa9ne

The canvas is a lot more variable than the content, so it makes sense to design for what's most stable (content-out)

@armstrong

What's the best way of dealing with data tables in responsive layouts?

@scottmallinson

We tend to adjust them (add/remove columns fo data) on the server and therefore (hope to) serve the most appropriate data to each device rather than trying to adjust client-side. This works pretty well but we're experimenting with a few other techniques as well.

@stephanierieger

It's good to use a max-width on 1300px+ resolution?

@frabenanti

It depends, how bad does your design handle widths above 1300px?

@lewisnyman

It depends on where the relationships start to break down within the design (e.g. is the logo getting too far from the nav?). Many layouts have a maximum width - stretch them any further and the layout breaks. It's at this point that you need to consider adding a new breakpoint (and adjusting the layout, perhaps adding side columns) or scaling the layout up (by increasing the base font size, if your site is built using ems).

@armstrong

Why have desktop apps been built adaptively for years, but we’re still building websites with static dimensions?

@iamdustan

It was easier. We lacked tools to create a decent UI without images

@lewisnyman

Your thoughts on the suggestion that one should start with the mobile layout first and have it scale to desktop environments? Does starting with that limitation breed good design?

@EnzoAmata

See "Does mobile first really need to be Commandment #1".

@cennydd

Getting away from 960 grids and into fluid layouts

@jameskelway

The most important thing to remember with fluid grids is that the actual physical pixel dimensions they're designed at in Photoshop doesn't matter, because those dimensions will become percentage-based in CSS. That's why I propose the use of a 1000px grid in Photoshop to make the calculations much, much easier. More info at elliotjaystocks.com.

@elliotjaystocks

According to Ethan Marcotte, Responsive Design is all about fluid layouts that continuously adapt to resolution changes. What about fixed-width layouts (i.e. Joni Korpi's Frameless Grid)?

@joaotiago

Fixed-width layouts have their place, although these tend to be referred to as 'adaptive' layouts rather than fully responsive. In my mind, though, they're definitely still part of the general responsive approach to web design; using a combination might sometimes be appropriate. The key thing to remember with fixed grids, though, is that they're not as future-proof as fluid grids, which don't require specific breakpoints most of the time. As always, use the appropriate tool for the job.

@elliotjaystocks

Height & it's effects... For instance, fluid paragraph content that overflows to a column to the right when the window height is reduced. This is especially helpful for horizontal scrolling websites. :]

@kingsomniac

If you have an interface element that is dependent on a certain height then it's definately worth using a height media query.

@lewisnyman

Responsive tables for tabular data

@krisbulman

One possible approach: Leave the table at a comfortable width, and fix the position of the headers. Would take a bit of CSS trickery, but would allow cells on a small screen to have space to be readable and keep their context.

@nathan_ford

What is best practice for responsive comment systems?

@missrachilli

Disqus seems to be leading the way, as the platform is already responsive.

@katherinecory

How to deal with mobile phones with higher resolution than desktops

@ramono

If you're talking about higher resolution in terms of pixel density, loading the desktop-sized full-width image and then having the browser squish that down to fit the mobile will — in the case of the current iPhone Retina Display, anyway — have the desired effect of making the image appear crisp. I do that on my blog. Worth bearing in mind that images are still unnecessarily large, even for the Retina Display, though.

@elliotjaystocks

baseline grid / vertical rhythm in responsive web design

@santaji

No solid answers yet, but @nicewebtype has been doing some nice thinking regarding 'Molten Leading'.

@armstrong

The transition of large Mega Menus to be responsive. What are the best options and how should we approach this task.

@aswadcharles

I am of the opinion that "mega menus" are usually not a great way to present navigation and help people find their way. Aside from my personal opinion, you should check out this post from Brad Frost about some of the emerging approaches to handling navigation for responsive sites.'.

Text Column Support

@carljspencer

Works well in every browser, except not at all in any version of IE (as far as I know). Neat trick: to keep elements, such as articles, from breaking across columns, set their display to “table” in your CSS.

@nathan_ford

Sensors

What's the best approaches to handle different bandwith speed now and how can we handle it in the future?

@justmarkup

W3C spec and Mozilla's work.

@lewisnyman

You could try this script I developed called Pngy to get an approximation of bandwidth right now.

@nathan_ford

What do you guys think of sites responding to the input method available to the user? E.g. touch device=chunky tabs/big hit area. pointer device (blackberry bold/curve) has smaller tabs (smaller hit area) and thus makes use of the limited screen estate

@danscotton

Assuming a small screen = touch and a large screen is not is dangerous. Modernizr can detect touch so we can load a touch.css but we should have a media query.

@lewisnyman

A fine idea in theory, but detection isn't reliable enough yet, and there will always be new technologies that spoof others or fall outside previously-defined categories. Most of my current design work now assumes a touchscreen by default. This means generous targets, which are still beneficial for other input devices as per Fitts's Law and generally make for a clean, uncluttered look. If client feedback or user testing suggests we need something denser, there's flexibility to do that.

@cennydd

How do we design around "break points" for future-proofing against new screen sizes?

@joshlong

Design around content breakpoints not current device widths.

@lewisnyman

Design around content breakpoints but optimize around most common devices accessing your site and/or most popular devices in the market place. In other words, make sure it's fully flexible with no major hiccups in between breakpoints but don't spend precious resources fixing tiny problems that may not map to any common (for your specific problem) screen size. And be sure to test on real mobile browsers. Most problems on responsive sites have little to do with (often cosmetic) screen size issues and far more to do with overall legibility, manipulation and functionality (e.g. JavaScript) incompatibilities

@stephanierieger

What if the "next big device" isn't rectangular?

@alexandtheweb

That's why content needs to be the priority rather than chrome. Whatever this device is, it will presumably be able to render a stream of content. Content is key, chrome is a 'nice to have'

@stephanierieger/cite>

How do we educate that 'responsive' is not just layout. (Content being responsive to the user. E.g, sitting on a train you wont want upcoming events when looking at a restaurant site)

@goo

Responsive is more than layout but trying to guess what the user will want based on context is (in my opinion) fools gold.

@stephanierieger

I'm with Stephanie - data-inferred context is the deadest of ends. Primary research and design ethnography are far more valuable, IMO.

@cennydd

what needs to become part of the HTML5 spec?

@m_lorek

HTML Media Queries

@armstrong

Delivering different content based on network connection. Is this possible and how?

@martzoukos

See "What's the best approaches to handle different bandwith speed now and how can we handle it in the future?"

@lewisnyman

How long will it take until we can use device APIs to get real information about a device’s connection speed.

@yatil

See "What's the best approaches to handle different bandwith speed now and how can we handle it in the future?" Also it will take as long as browser vendors to implement. Developers should pressure them to increase priority.

@lewisnyman

I appreciate the value of APIs such as these but I think this may also be a case of "careful what we wish for". If we work up tomorrow and suddenly had these APIs, what would we realistically use them for? If knowing "you have bandwidth" is simply an excuse to keep loading sites (ie. users) up with heavy content is this really the best solution for the ecosystem? Some of this stuff will take years to resolve and may still remain incredibly messy, even with APIs. I think we need more holistic thinking about the overall problem of "reasonable, default, fit for purpose page weight"

@stephanierieger

How does (or should) responsive pages affect the scripts attached to the page?

@kevdog

It's not should you or shouldn't you load certain scripts at certain breakpoints, its much more about the network connection. One of the big things that came from this discussion was that having a simple way to get a good sense of the type of connection a person has could go a long way toward us knowing when to go ahead and load certain things (scripts/images/videos/etc) while always giving the user an override to go ahead and download that thing even if it takes 60 seconds :)

@jbrewer

What's the definitive approach for responsive images, detecting resolution, retina, bandwidth etc?

@dannyt

All Webkit devices are incapable of detecting ppi right now but you can detect retina by using device-pixel-ratio

@lewisnyman

Best practices for keeping download sizes to absolute minimum for mobile devices (I.e. can mediaqueries prevent desktop stylesheets from being downloaded when on mobile?) OR should we detect bandwidth speed and be responsive to that too?

@dannyt

Let the user choose and serve lightweight content to everyone regardless

@stephanierieger

Advertising

How to deal with third party ad networks with fixed size units.

@stuartgibson

One way is to retain a fixed-width column in your grid, and allow for fluidity in your other columns instead.

@cennydd

Another way is to design your minimum grid module size based on an ad unit size (or a multiple of it).

@markboulton

How long before Ad Servers will just support multiple resolutions?

@elgrom

When they can prove there's a return on investment for delivering ads in this way. I'm hoping one ad provider will start offering it, and others will follow.

@anna_debenham

The issues surrounding adverting within responsive design, how adverts should also adapt?

@glynnphillips

Ideally, the IAB would start work on some fluid ad formats. But unless providers start experimenting with that first, and find their CTRs substantially improved, I don't hold out much hope. Text ads of course present far less of a problem.

@cennydd

For web models that require a profit model (read:advertising), seems as though nobody has found the golden ticket to attractively and efficiently display responsive advertisements. What can we collectively do to work toward some ideas and answers?

@ThreeLakesWI

We agreed there was a need for someone to bite the bullet and do responsive advertising successfully, to give others the courage to try it. In the Ad agencies' defence, it's a huge risk (none of us actually know for sure whether responsive advertising would be more successful than static)

@armstrong

Images

In addition to working with the W3C for a web standards-based responsive image solution (possibly similar to the <video> spec), are there things the Apache (or Node.js) teams can do to help give us a reliable, browser-independant server-side solution?

@kevindavies

See my write-up notes at http://elliotjaystocks.com/blog/responsive-summit/

@elliotjaystocks

Image negotiation (e.g., different ad units at different width ranges). How to not display AND not load when not needed.

@wion

At the moment using background images seems to be the way to address your specific question. We talked about some things, such as, "load: none;" that many thought would help w/ this exact problem. However, this is only a subset of the larger issue around images on the web and our need for either a new format or, as is being proposed, a new <picture> element.

@jbrewer

What is the best solution for serving images of different filesizes for different devices until we have a proper HTML solution with fallbacks like video and audio tags?

@jordanmoore

Not a solution for everyone but if you don't mind using the server, there is lots you can do with server-side detection/pre-optimisation combined with real-time client-side feature detection and adaptation. No formal 'solution' however, it's very much a case of building what you need. See our Adaptation and Pragmatic Responsive Design presentations on Slide Share for more context.

@stephanierieger

A standard way to handle responsive images with a minimal (no extra) HTTP requests

@garygarside

See comment above ("What is the best solution for serving images of different filesizes for different devices?"). Using the server enables you to serve an appropriate image on initial load. No additional request required unless the user reorients the display (and the device viewport size is such that a new image is even warranted)

@stephanierieger

Is a new HTML tag/structure for responsive images the way forward or should it be much broader like responsive "areas" (div/sections etc. to be displayed at certain screen sizes)? I know, this sounds more like a server-side functionality. Feasible?

@bentographics

I'm all for HTML Media Queries. If you're making adjustments to content, or changing how it is interacted with (changing from a list of links to a drop down, for instance), then you're changing the semantics of that content and that should be reflected in the DOM. Otherwise we're using CSS for semantic information, which surely is as bad as using HTML for presentation.

@armstrong

Best practices for image size and load times

@r_weisburd

Take a look at Pngy: https://github.com/nathanford/pngy Not perfect, but it is a start.

@nathan_ford

How do we solve the responsive image resolution issue without javascript and without loading more than one image?

@markstickley

Currently, the best solution is to load the lo-res one by default and use JS to swap that out for the hi-res version if it's detected that the browser is wide enough to display it. With JS turned off, the user will still get an image; albeit the lo-res one (which is a far better fallback than the unnecessary bandwidth required to deliver the hi-res one). Full details about this method at https://github.com/joshje/responsive-enhance

@elliotjaystocks

There is a whole discussion around responsive images which lead to the proposal of a new html element (PICTURE), what's your opinion? See http://www.w3.org/community/respimg/

@regiskuckaertz

We all agreed that the proposed <picture> element was a very sensible way forward.

@elliotjaystocks

Do we need a "load: none;" CSS rule instead of "display:none;"?

@bentographics

Would be nice :-)

@stephanierieger

Personally I'd like some way to do this in HTML. If it's content, and we don't want it to appear, then that's something that should be happening on the DOM side, not the presentation layer. HTML Media Queries anyone? :)

@armstrong

How can we use responsive images in a mobile-first way? What’s are best practices?

@yatil

See our Adaptation and Pragmatic Responsive Design presentations on Slide Share.

@stephanierieger

iPhone 4 retina display not differentiating its devicePixelRatio in the user agent, which makes serving higher-res IMG SRCs difficult.

@Steve

Current no feature information is being provided in a http request. Either we ask vendors to add in more information or we are left with UA sniffing or a JS approach.

@lewisnyman