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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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?
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)
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.
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.
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™.
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.
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.
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.
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?
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
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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
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.
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.
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"
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 :)
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?
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.
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?
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)
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?
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.
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.
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)
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?
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.
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
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? :)