A nice summation by Dan of when it makes sense to use a graphic design tool like Photoshop and when it makes sense to use a web browser.
The transcript of Malarkey’s recent talk. Good thoughtful stuff.
Yaili is documenting the process of retrofitting ubuntu.com to be responsive. I’ll be avidly reading each post in this series.
Mike writes about what it was like being a client for a change. After working with him on the Code for America project, I can personally vouch for him as a dream client:
Clearleft’s pattern deliverables are the special-special that made the final work so strong. Jon Aizlewood’s introduction to the concept convinced me to contact Clearleft. Jeremy Keith’s interest in design systems kicked off the process, and Anna Debenham’s fucking rock star delivery brought it all home.
Some great thoughts in here about web development workflow and communication between designers and developers.
I believe that the solution is made up of a variety of tools that encourage conversation and improve our shared lexicon. Tools such as styleguides, pattern libraries, elemental and modular systems that encourage access not only by developers, but by designers, shareholders and editors as well.
A great write-up of the design process behind The Guardian’s responsive site. It’s really gratifying to see UX designers talking about performance.
Words of wisdom from Seb when it comes to personal projects: finish what you start.
Most people don’t finish their projects so simply by getting it done, you’re way ahead of the crowd.
Like Drew, I’ve noticed some real hostility to the idea of progressive enhancement recently. Like Drew, I don’t really understand where this attitude comes from. It’s not like progressive enhancement prevents you from doing anything you would do otherwise: it’s just another way of approaching the way you build for the web.
I hope I’m wrong, but I suspect that some developers are letting their tools dictate their principles—the tail wagging the dog (where the tail is Angular, Ember, etc.).
Des is right, y’know.
Scope grows in minutes, not months. Look after the minutes, and the months take care of themselves.
Craig recently had a piece published in the New Yorker called Goodbye, Cameras. It’s good …but this follow-on piece on his own site is truly wonderful.
Read. Absorb. Ponder.
Being close to the network does not mean being on Facebook, thought it can mean that, too. It does not mean pushing low-res images to Instagram, although there’s nothing wrong with that. What the network represents, in my mind, is a sort of ledger of humanity. The great shared mind. An image’s distance to it is the difference between contributing or not contributing to that shared ledger.
This looks interesting: a CSS postprocessor that polyfills support for perfectly cromulent styles.
Here’s a heartwarming tale. It starts out as a description of processing.js project for Code Club (which is already a great story) and then morphs into a description of how anyone can contribute to make a codebase better …resulting in a lovely pull request on Github.
John shares his concerns about the increasing complexity involved in developing for the web.
The transcript of Mark’s talk from last week’s Handheld conference in Cardiff.
There are mountains.
This is the talk I gave at the border:none event in Nuremberg last month. I really enjoyed it. This was a chance to gather together some thoughts I’ve been mulling over for a while about how we approach front-end development today …and tomorrow.
Warning: it does get quite ranty towards the end.
Also: it is only now that the video is released that I see I spent the entire talk looking like a dork with a loop of wire sticking out of the back of my head.
Alex starts with a bit of a rant about the phrase “semantic HTML”, which should really just be “well-written HTML, but there then follows some excellent thoughts on the emergence of meaning and the process of standardising on vocabularies.
Empathy is for everyone:
No matter how many times I go through this journey, it never stops surprising me how easy it is to lose perspective in the heat of a project and forget that there is no difference between a user, a client and a designer. It shouldn’t be so hard to remember that no matter the title, we’re all just people trying to get things done.
A nice reminder from Viv.
A call for developers to let standards bodies know what we want:
It is important that we as developers focus on the right things again. If you encounter a bug, you should not only fix it for your site; you should reach out to browser vendors and web standards people to fix this in a long-term solution. It might cost you a few minutes, but brings a lot of improvement to the whole developer community.
Dr Harry Halpin writing in the Guardian about the crucial crossroads that we have reached with the very real possibility of DRM mechanisms becoming encoded within HTML:
Most of us are simply happy to launch our browsers and surf the web without a second thought as to how the standards like HTML are created. These standards are in the hands of a fairly small set of standards bodies that have in general acted as responsible stewards for the last few years. The issue of DRM in HTML may be the turning point where all sorts of organisations and users are going to stop taking the open web for granted.
A terrific case study in progressive enhancement: starting with a good ol’ form that works for everybody and then adding on features like Ajax, SVG, the History API …the sky’s the limit.
An intriguing initiative to tighten up the loop between standards development and implementation.
Jon gives some insight into how and why we use pattern portfolios as deliverables at Clearleft.
Trent hammers home the point that the kind of compartmentalisation that’s traditionally been part and parcel of the web dev workflow just won’t cut it anymore.
Dave talks about the kind of deliverables that get handed over in a responsive project. Sounds a lot like what we do at Clearleft.
Responsive deliverables should look a lot like fully-functioning Twitter Bootstrap-style systems custom tailored for your clients’ needs.
Some cautionary tales of over-engineering solutions before doing some quick user-testing to establish what the real problems are.
It’s a pleasant delusion to believe that all our problems require hard solutions.
A terrific, in-depth round-up and recollection of the Responsive Day Out by Laura that ties all of the strands together.
Anna documents her tea-making process.
Everything old is new again. Ross noticed that many of the themes recurring at the Responsive Day Out hark back to best practices from over a decade ago: progressive enhancement, performance, good ol’ information architecture…
Some thoughts and soul-searching prompted by talks at the Responsive Day Out.
Some nice recollections from the Responsive Day Out.
A nice write-up of the Responsive Day Out with all the right take-aways.
This was the crux of Elliot’s excellent talk at the Responsive Day Out. I heartily concur with this:
Once you overcome that initial struggle of adapting to a new process, designing and building responsive sites needn’t take any longer, or cost any more money. The real obstacle is designers and developers being set in their ways.
I really like Dan’s take on using Photoshop (or Fireworks) as part of today’s web design process. The problem is not with the tool; the problem is with the expectations set by showing comps to clients.
By default, presenting a full comp says to your client, “This is how everyone will see your site.” In our multi-device world, we’re quickly moving towards, “This is how some people will see your site,” but we’re not doing a great job of communicating that.
James’s notes from the most recent Hack Farm show that, even without a finished product, there were a lot of benefits.
Gorgeous colour-processed images from NASA probes. I could stare at the fountains of Enceladus all day.
Beauteous and true.
Real design is political.
I really like these thoughts on the importance of design systems for the web. It’s not about providing a few perfect deliverables that won’t survive once they go live; it’s about designing for the unexpected, the unpredictable:
Design for every state, not the best state.
Here’s a really useful case study for anyone who wants to do “guerrilla” responsive design: when you’re handed a fixed-width mockup but you know that responsive is the way to go:
I started by styling up every element, without layout. The result was a fully elastic layout that effectively served as a mobile, or small screen, layout, which just needed some tweaking of horizontal spacing.
Bingo! And this approach had knock-on benefits as it “supported writing component-based, or modular, CSS”.
Another responsive design case study. This one’s got numbers too.
I love seeing the process behind responsive projects. This one is particularly nice.
A really terrific piece about wireframing for responsive designs. Again, it’s all about the prototypes.
Less wireframing, more prototyping.
Mark gets to the heart of the issue with making responsive designs work with legacy Content Management Systems …or, more accurately, Web Publishing Tools. There’s a difference. A very important difference.
A peak behind the scenes at the responsive design and development workflow at Bearded. It makes a lot of sense.
Does Zed Shaw look like a bitch to you?
I said does Zed Shaw look like a bitch to you?
A nice look at some possible ways to approach workflow on a responsive project.
A lovely bit of hypertext.
It might seem like an obvious point, but what Tim is talking about here happens over and over again: a technique is dismissed based on bad implementation.
Amen, Lyza, Amen. Instead of treating web development for the multitude of devices out there as an overwhelming nigh-on-impossible task, let’s accept the fact that there are certain things that are beyond our control. And that’s okay.
Let’s build on the commonality core to the web where we can. To do this, I think we need to let go of a few things, to lay down our burdens.
Related: do websites need to look the same in every browser? NO!
Nishant gives a great overview of the responsive redesign of the Microsoft home page, ably abetted by the Paravel gang.
Andy’s talk from the Smashing Conference in Freiburg.
A nice round-up of some of the themes that emerged at Smashing Conference. As with An Event Apart, there was a definite focus on process.
Bruce writes about a worrying trend in standards work:
Tossing a specification that you’ve written in-house, in secret and already implemented onto a table at W3C, saying “here, standardise this” as you saunter past isn’t a Get Out of Jail Free card for proprietary misdemeanours. And it isn’t standardisation.
Some more thoughts on how our workflow needs to adapt to the current ever-changing device landscape.
An in-depth look behind the scenes of the responsive relaunch of People Magazine’s mobile site that Josh, Karen, and Ethan were involved in. I love it when people share their process and build stories like this.
I don’t agree with everything in this presentation—there’s a nostalgic bias to the non-existent “good ol’ days”—but this is still very engaging and thought-provoking.
Everything Frances has written here resonates with me.
I don’t really want a label. I hate labels. I loathe the term “user experience designer”, because I still believe that “user experience” is just a fundamental to what you’re doing, and shouldn’t need stating. There is nothing but user experience design if you’re building products for people.
A great talk on the nature of the web that Paul gave in Copenhagen recently.
Andy remarks on the same synchronicity I talked about at An Event Apart Austin:
Every An Event Apart conference feels special, but at this one the (unplanned) recurring themes were spooky.
Leisa nails it. The real stumbling block with trying to change the waterfall-esque nature of agency work (of which Clearleft has certainly been guilty) can be summed up in two words: sign off.
And from a client’s perspective, this emphasis on sign-off is completely understandable.
It takes a special kind of client to take the risk and develop the level of trust and integration required to work the way that Mr Popoff-Walker any many, many other inhabitants of agency world would like to work.
This resonates a lot with me. It also hits very close to home: at Clearleft, we’ve definitely been guilty of taking the wrong approach as described here.
A great article on the importance of sketching for mobile-first responsive designs, complete with practical ideas for workshopping.
Jake demonstrates his technique for preprocessor-generated stylesheets for older versions of Internet Explorer (while other browsers get the same styles within media queries).
This is an excellent idea from Jake: use a preprocessor to automatically spit out a stylesheet for older versions of IE that includes desktop styles (garnered from the declarations within media queries).
If you’re a dab hand with Ruby and you’d like to see this in SASS, you can help.
One developer shares how his workflow has changed thanks to responsive design. It’s insightful.
Paul interviews the team behind Kiwibank’s responsive homepage. There are some great insights into their process here, like the way that copywriters worked side by side with developers.
A well thought-out evaluation on responsive images from Bridget.
This seems like an eminently sensible thing to do when building responsive sites: ditch mock-ups entirely. The reasons and the workflow outlined here make a lot of sense.
I had a chat with the guys from Pingdom about performance’n’stuff. If I sound incoherent, that’s because this is a direct transcription of a Skype call, where, like, apparently I don’t, y’know, talk in complete sentences and yeah.
A great set of design principles for gov.uk — I’ve added them to http://principles.adactio.com/
How designing in the browser works for rapid iteration.
I like Cennydd’s thoughts on the fundamental difference between skill and process:
Skilled people without a process will always find a way to get things done. Skill begets process. But process doesn’t beget skill.
Using Keynote as a web design tool? Why not? It makes as much sense as Photoshop or Fireworks, perhaps more.
Samantha does an excellent job of explaining how useful style tiles can be for visual design and iteration.
An in-depth look at naming patterns for classes to help streamline CSS.
Samantha put together this handy one-page site to explain Style Tiles as part of her South by Southwest presentation.
Jeff documents some of the techniques he’s using to tackle responsive design, with some tips specifically for SASS.
Elliot jots down some of the issues discussed at the responsive summit.
Mark talks about the tools web designers use and the tools web designers want. The upshot: use whatever you’re most comfortable with.
Josh goes through the talking points from the recent Responsive Summit he attended. Sounds like it was a great get-together.
Man, I love Trent’s honesty! This had me nodding my head vigorously — yes, responsive design means fundamentally approaching the way we build for the web …that’s what makes it so exciting!
I suspect that some naysayers of responsive design, were they to do some soul-searching, would find themselves relating to Trent’s initial scepticism.
A great behind-the-scenes look at the process behind the responsive Boston Globe site, with a particular emphasis on the visual and interactive design challenges.
Steven Johnson describes the beautifully chaotic way that ideas collide and coalesce. Oh, and this bit…
Listening to Cerf talk about the origins of the Internet — and thinking about the book project — made me wonder who had actually come up with the original idea for a decentralized network. So that day, I tweeted out that question, and instantly got several replies. One of those Twitter replies pointed to a Wired interview from a decade ago with Paul Baran, the RAND researcher who was partially responsible for the decentralized design.
Documentation of an ongoing project to create a mobile-first responsive MediaWiki theme.
If you use Sass, this could be a really handy technique for handling IE<9 support with mobile-first responsive designs.
The process behind the mobile-first responsive design of audiovroom.com.
Mark continues to hammer home the most important thing to keep in mind when creating responsive designs: design from the content out, not the canvas in.
Rob documents how he approached his first responsive design.
An insight into Elliot’s current design process which highlights the advantages of designing in the browser when you take a content-first approach.
The process behind a responsive realignment …and the end result is very nice indeed.
A visual representation of the design process.
Jonathan has encapsulated his CSS methodology into a short online book. He isn’t presenting this as the “right” way to do things: he’s simply documenting what he does in the hope that it will help others.
Samantha gives the rundown of a hands-on use of Style Tiles.
This is your one-stop shop for envelope-pushing in the browser:
A thoughtful post on how to approach responsive web design. In short, it’s going to be different for every project.
A wonderful post by Trent Walton on the thinking and workflows we can employ with responsive design. So many opportunities!
Web designers will have to look beyond the layout in front of them to envision how its elements will reflow & lockup at various widths while maintaining form & hierarchy. Media queries can be used to do more than patch broken layouts: with proper planning, we can begin to choreograph content proportional to screen size, serving the best possible experience at any width.
I’m getting behind Oli’s proposal to allow non-quoted footers within blockquotes in HTML. Here’s where I quote the design principles to support his case.
On the two-year anniversary of his arrival at Clearleft, Paul takes a look at where the craft of web design is today and where it’s heading tomorrow.
This dovetails nicely with my recent post about the spirit of distributed collaboration. Here’s a great little bit of near-history spelunking from Paul, all about styling new HTML5 elements in pesky older versions of Internet Explorer.