I’ve always loved Jeffrey’s writing.
I love this back and forth between Brad and Jonathon. I think they’ve both got some good ideas:
- I agree with Brad that you can start marking up these kind of patterns before you’ve got visual designs.
- I agree with Jonathon that it’s often better to have a generic wrapper element to avoid making assumptions about which elements will be used.
Shamefully, I haven’t been doing one-to-ones with my front-end dev colleagues at Clearleft, but I’m planning to change that. This short list of starter questions from Lara will prove very useful indeed.
I really, really like what Ember is aiming for here:
That’s how you get the holy grail of resilience and performance:
Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.
I sincerely hope other frameworks are paying attention to this layered approach.
Oh, and I also like this observation:
There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.
Depending on how you’re currently structuring your CSS and class attributes, web components might not make all that much of a difference to your workflow.
Charlotte outlines the process she used in creating her talk at Dot York. It was a real joy to see it come together.
Jon introduces a new tool with a very interesting observation: up until now, all our graphic design tools have been imperative rather than declarative…
With our current tools we’re telling the computer how to design the vision we have in our head (by tapping on our input devices for every element on the screen); in our future tools we will tell our computers what we want to see, and let them figure out how to move elements around to get there.
Marvellous insights from Mark on how the robustness principle can and should be applied to styeguides and pattern libraries (‘sfunny—I was talking about Postel’s Law just this morning at An Event Apart in Boston).
Being liberal in accepting things into the system, and being liberal about how you go about that, ensures you don’t police the system. You collaborate on it.
So, what about the output? Remember: be ’conservative in what you do’. For a design system, this means your output of the system – guidelines, principles, design patterns, code, etc etc. – needs to be clear, unambiguous, and understandable.
There’s a lot I disagree with here. I don’t think this pattern library process is very elegant or scalable, and it certainly wouldn’t work for me.
But I’m still linking to it. Why? Because I think it’s absolutely wonderful that people share their processes like this. It doesn’t matter one whit whether or not it would work for me.
Frontend development may have gotten a lot more complicated, but the simple premise of sharing what you’ve learned hasn’t.
I couldn’t agree more!
An engaging look at the history of word processing, word processed by Josephine Livingstone.
Rachel and Drew have been beta-testing Mark’s Fractal project for organising a library of components for Perch’s interface. Sounds like it’s working out very, very well indeed!
Mark has dumped his brains!
Seriously, there is a lot of thought that has gone into this, and it’s just the beginning: Mark recounts the experience that Clearleft has had with delivering pattern libraries, laying the groundwork for releasing the library-generating tool that he has been building.
Watch this space.
Eric asked me some questions and I was only too happy to give some answers.
A look at the tools that AirBnB have made to help them in their design and development process. I hope they’ll share them.
Jon outlines his technique for keeping “the 30,000 foot” view when patterns are coalescing during a project.
See also: Andy P.’s experience of working with Jon this way.
A lovely outlook on designing with progressive enhancement:
There will always be users coming from places you didn’t expect, using devices you didn’t test for.
Myself and Batesy spent last week in Ipswich doing an intense design sprint with Suffolk Libraries. Leon has written up process from his perspective as the client—I’ll try to get a case study up on the Clearleft website soon.
This is really great write-up; it captures the sense of organised chaos:
I can’t recommend this kind of research sprint enough. We got a report, detailed technical validation of an idea, mock ups and a plan for how to proceed, while getting staff and stakeholders involved in the project — all in the space of 5 days.
Linting CSS seems like a very good idea, especially if you’re not the only one writing the CSS. This guide is going to come in very handy when I give it a try.
Well, this pretty much sums up the front-end team at Clearleft:
I’ve often said that at Clearleft, development is always in the service of design. And like Brad, I often find myself defining that work by what it isn’t:
They understand UX principles and best practices, but may not spend their time conducting research, creating flows, and planning scenarios
They have a keen eye for aesthetics, but may not spend their time pouring over font pairings, comparing color palettes, or creating illustrations and icons.
They understand the importance of backend development, but may not spend their time writing backend logic, spinning up servers, load testing, etc.
Really interesting to see how Jason, Lyza, and co. are handling the process side of responsive design by using Agile sprints. This is how we’re doing it at Clearleft too.
There’s a really good point in here about starting with small-screen sketching:
For most of the sprint, we focus on small screens. We’re often asked how things will work on wider screens early in a sprint, but we try to resist thinking about that yet.
If you’ve managed to organize your life to fit inside a New York City apartment, you’re not going to have any trouble adjusting to a big house in the suburbs. The same is true of responsive designs.
If you nail the small screen design, the larger sizes will be easy by comparison.
Bootstrap is a product of Twitter. If you want your team to work like Twitter’s team, then by all means use Bootstrap. Pick up their design language. Their tool chain. Their decisions. Don’t be surprised when it feels off every time you use it. It will.
The same goes for Material Design. Foundation. These are all products built by other teams to work for their process. Their structure.
Finding the right tool is not what I am advocating for. Making it is.
We’re about to start trying out OKRs (Objectives and Key Results) at Clearleft. It’s a terrible, jargony label, and a lot of the discussion around them is steeped in valleywank, but I think they could be a useful way of helping shared understanding within a company.
I’ll be having a read through the accompanying guide.
Brad follows up with his thoughts on Dan’s article, emphasising the importance of a developer’s role in not just slavishly recreating what’s in a static comp, but seeing through to the underlying pattern beneath:
It’s so incredibly crucial to treat development as a key part of the design process.
Two sides of a debate on progressive enhancement…
Andrey “Rarst” Savchenko wrote Progressive enhancement — JS sites that work:
Joe Hoyle disagrees:
Caspar acknowledges this:
I don’t have any problem buying into pragmatism as the main and often pressing reason for not investing into a no-JS fallback. The idealistic nature of a design directive like progressive enhancement is very clear to me, and so are typical restrictions in client projects (budgets, deadlines, processes of decision making).
But concludes that by itself that’s not enough reason to ditch such a fundamental technique for building a universal, accessible web:
Ain’t nobody got time for progressive enhancement always, maybe. But entirely ditching principle as a compass for resilient decision making won’t do.
Mikey compares a few different decision-making processes (and in the process describes the fundamental difference between the W3C and the WHATWG).
Very thoughtful and sensible thinking from Paul.
When another company achieves success, there’s a lot of pressure to investigate what they did right and apply that to our own organizations.
But we still have a chance. As long as we run brave organizations made up of even braver souls who are willing to embrace expression, trust their intuition and experiences, and stand up when everyone else is sitting down, we will survive.
This sounds like it could be a very useful tool to introduce early in projects to get a shared understanding of progressive enhancement.
The system makes the website. Don’t blame the web developer, blame the organisation. A web developer embedded in a large system isn’t the one making the websites.
To make a progressively enhanced website that performs well and loads quickly even on slow connections, you need to first make an organisation that values those qualities over others.
This article first appeared in Fast Company almost twenty years ago. It’s a fascinating look into the culture and process that created and maintained the software for the space shuttle. It’s the opposite of Silicon Valley’s “move fast and break things.”
To be this good, the on-board shuttle group has to be very different — the antithesis of the up-all-night, pizza-and-roller-hockey software coders who have captured the public imagination. To be this good, the on-board shuttle group has to be very ordinary — indistinguishable from any focused, disciplined, and methodically managed creative enterprise.
Two-thirds of the way through our 100 days project, Batesy takes stock of his journey so far.
(I should probably mention that I love each and every one of the pieces of hand lettering that he’s done …talented bastard.)
I think the distinction between ‘how it works’ and ‘how it looks’ is blurrier than we think.
I really like this idea of Jared’s. Finish up a meeting by having everyone write down the answers to these three questions in 60 seconds:
- What was the big idea? (What was the most important thing you heard at the meeting?)
- What was your big surprise? (What was the thing you saw or heard that surprised you the most?)
- What’s your big question? (What’s the biggest unanswered question you have at this time?)
I can certainly relate to these findings:
We find that it’s not unusual to discover that different people in the room had just attended completely different meetings. People are surprised by things that other people take as a matter of course. People take away a different emphasis about what was discussed. People’s fears and concerns are reflected in their outstanding questions.
SmashingConf Oxford 2015: Richard Rutter on Don’t Give Them What They Want, Give Them What They Need
A great case study from Richard, walking through the process of redesigning the website for the Royal Borough of Kensington and Chelsea.
Superb. Absolutely superb.
A magnificent tour-de-force by Frank on the web’s edgelessness.
Read. Absorb. Read again. This is the essence of responsive web design, distilled.
Always worth bearing in mind when some perspective is needed.
If it is possible that our future species will go on to create simulations of our civilisation forerunners (us), then it is far more likely that we are currently in such a simulation than not.
When I look around, I see our community spending a lot of time coming up with new tools and techniques to make our jobs easier. To ship faster. And it’s not that I’m against efficiency, but I think we need to consider the implications of our decisions. And if one of those implications is making our users suffer—or potentially suffer—in order to make our lives easier, I think we need to consider their needs above our own.
Sensible words from Christian.
Web applications don’t follow new rules.
And frameworks will not help:
A lot of them are not really fixing fundamental problems of the web. What they do is add developer convenience. … This would be totally OK, if we were honest about it.
We hired Charlotte, our first junior developer at Clearleft recently, and my job has taken on more of a teaching role. I’m really enjoying it, but I have no idea what I’m doing, and I worry that I’m doing all the wrong things.
This article looks like it has some good, sensible advice …although I should probably check to see if Charlotte agrees.
The difference between back-enders and front-enders is that the first work in only one environment, while the second have to work with myriad of environments that may hold unpleasant surprises.
An important clarification from Stephen:
You don’t actually design in the browser
When I speak of designing in the browser, I mean creating browser-based design mockups/comps (I use the terms interchangeably), as opposed to static comps (like the PSDs we’re all used to). So it’s not the design. It’s the visualization of the design—the one you present to stakeholders.
Personally, I think it’s as crazy to start in the browser as it is to start with Photoshop—both have worldviews and constraints that will affect your thinking. Start with paper.
Good advice from Chris, particularly if you’re the one who has to live with the CSS you write.
As Obi-Wan Kenobi once said, “You must do what you feel is right, of course.”
This isn’t a scientific data sample, but Jonathan’s anecdotal evidence seems to suggest that most web designers and developers are still thinking with a desktop-first mentality. Which is crazy.
I don’t tend to be a “magic pill” kind of believer, but I can honestly say that embracing progressive enhancement can radically change your business for the better. And I’m glad to see Google agrees with me.
This was a fun podcast—myself and Cyd from Code For America talk to Karen and Ethan about how we worked together. Good times.
The audio is available for your huffduffing pleasure.
Patty Toland — Design Consistency For The Responsive Web (Smashing Conference Freiburg 2014) on Vimeo
Patty’s excellent talk on responsive design and progressive enhancement. Stick around for question-and-answer session at the end, wherein I attempt to play hardball, but actually can’t conceal my admiration and the fact that I agree with every single word she said.
My name is Jeremy and I am a boring front-end developer.
A look behind the scenes of gov.uk. I like their attitude to Photoshop comps:
We don’t want a culture of designs being “thrown over a wall” to a dev team. We don’t make “high fidelity mock ups” or “high fidelity wireframes”. We’re making a Thing, not pictures of a Thing.
We don’t have a UX Team. If the problem with your service is that the servers are slow and the UX Team can’t change that, then they aren’t in control of the user experience and they shouldn’t be called the user experience team.
The first in a series of posts looking at the process behind builfing this “quantified self” site:
As with most decisions in my life, I asked myself: What would Tony Stark do?
Today, a basic HTML/CSS site seems almost passé. But why? Is it because our new tools are so significantly better, or because we’ve gone overboard complicating simple things?
He’s right, y’know.
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.
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.
Ben Buchanan has a nice round-up of some of the options available when you’re switching over to HTML5.
An excellent design technique from Samantha that allows you to nail down a visual vocabulary without using something as wishy-washy as a mood board or as rigid as a fully-blown comp. Brilliant!
The style tile is not a literal translation of what the website is going to be, but a starting point for the designer and the client to have a conversation and establish a common visual language.
Aaaaaand once again, the Riegers show us the way. This time it’s Stephanie’s presentation at Breaking Development in Dallas. Bloody brilliant.
Paul gives an excellent and thorough explanation of why systems thinking is important in web design.
An excellent overview of the evolution of the St. Paul's School website from David Smith, noting an increasing emphasis on mobile usage.
Ethan shares his thoughts on the role of the reference design in the responsive workflow.
Colly shows the results of his dConstruct workshop: great stuff!
Yes, yes, yes: "A PSD is a painting of a website.” We don’t spend weeks or months understanding a client’s complex needs and issues to make them paintings.
The companion website to Kevin Hoffman's IA Summit talk, this is a hugely valuable resource for an often-overlooked part of the design process: the kick-off meeting.
Purely for my own benefit because I keep needing this URL, here are the current outstanding issues registered at the W3C for HTML5.
Good points, well made.
A nice collection of design tools and methodologies.
Brendan Dawes pointed me to this wonderfully playful creation. It's Flash-free, believe it or not.
Dave has been experimenting with processing and documenting the results here.
A very pretty little Twitter canvas experiment accompanied by music delivered via the audio element. View this in a capable browser.
Andy's excellent presentation from An Event Apart in Boston and @media in London. Required reading/viewing.
Michael Smethurst runs through the process used in his bit of the BBC. It's all good.
Bean is a free word processor for OS X. Looks nice and simple.
Richard Feynman and The Connection Machine.
Infrastructure just got even cheaper. Between this and Amazon's EC2/S3, the barrier to entry to getting an app up and running is getting lower and lower.
Charmr is a design concept for diabetes management devices proposed by Adaptive Path following a process of research and iteration.
Here's a simple little way to blow off steam with some micro-updates. You can even do it from Twitter. Nice.
Great post by Leisa on the real reasons for using personas (they might not be the reasons you think).
Leisa's slides from the IA Summit in Vegas. Looks like it was an excellent presentation, channelling the spirit of Kelly Goto and Jeff Veen.
John Allsopp has created this flowchart of the research and development involved in the creation of a new microformat. It looks kind of like the workflow of any good iterative development.
Behind the scenes at Flickr.