Incredibly impressive work from the CodePen team—you can now edit entire projects in your web browser …and then deploy them to a live site!
This ties in nicely with the new talk I’m doing on evaluating technology. Zell proposes a five-step process:
- Figure out what [insert tool] does.
- Figure out what sucks right now
- Determine if it’s worth the investment
- Learn it (if it’s worth it)
- Differentiate opinions from facts
Surprisingly, it helps clients understand the HTML content prototype better. They now clearly see the difference and the relationship between content and design. In general it helps me explain the content-first process better and it helps them make more sense of it.
David picks up on one of the closing themes of Resilient Web Design—how we choose our tools. This has been on my mind a lot; it’s what I’ll be talking about at conferences this year.
That’s part of my job to ease processes and reduce frictions. That’s part of my job to take into account from the early beginning of a product its lasting qualities.
There’s a very good point here about when and how we decide to remove the things we’ve added to our projects:
We spend our time adding features without considering at the same pace the removal of useless ones. And still the true resilience (or is it perfection Antoine?) is when there is nothing more to take away. What are you removing on Monday to make our Web more resilient?
I’ve been thinking a lot lately about how we evaluate technologies (it will be the subject of my next talk). Tim is thinking along the same lines. I like his list of four questions to ask when weighing up the pros and cons of any web tool:
- Who benefits from the use of this tool and how?
- Who suffers and how?
- How does it fail?
- Does the abstraction feed the core?
PPK reads a Hacker News thread so you don’t have to.
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.
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.
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.
I think the distinction between ‘how it works’ and ‘how it looks’ is blurrier than we think.
A walkthrough on using the iOS app Workflow to huffduff audio files from just about any app.
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.
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.
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.
Des is right, y’know.
Scope grows in minutes, not months. Look after the minutes, and the months take care of themselves.
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.
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.