For a small to medium sized project, this sounds like a sensible way to approach build tasks. It feels nice and close to the metal.
I’m not sure the particular use-case outlined here is going to apply much outside of AirBnB (just because the direction of code-to-Sketch feels inverted from most processes) but the underlying idea of treating visual design assets and code as two manifestations of the same process …that’s very powerful.
Ethan’s been thinking about the trends he’s noticed in the work he’s doing:
- prototypes over mockups,
- preserving patterns at scale, and
- thinking about a design’s layers.
On that last point…
The web’s evolution has never been charted along a straight line: it’s simultaneously getting slower and faster, with devices new and old coming online every day.
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!
Two new typefaces, designed to be deliberately lacking in expression.
The write-up of the making of the typefaces is as open and honest as the finished output. This insight into the design process rings very, very true:
Post rationalisation is an open secret in the design industry. Only when a project is finished can it be written up, the messy process is delineated and everything seems to follow a logical sequence up until the final thing is unveiled, spotless and perfect.
However, I suspect the process is largely irrational for most designers. There is a point where all the input has been processed, all the shit drawings, tenuous concepts and small ideas have been thrown away and you just work towards the finish, too exhausted and distracted to even know if it’s worth anything or not. And, if you’re lucky, someone or something will come along and validate the work.
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
Thinking of writing a book? Here’s some excellent advice and insights from Yaili, who only went and wrote another one.
Let me say this first: writing a book is hard work. It eats up all of your free time and mental space. It makes you feel like you are forever procrastinating and producing very little. It makes you not enjoy any free time. It’s like having a dark cloud hanging over your head at all times. At. All. Times.
An interview with Batesy that gives a nice insight into life at Clearleft.
He’s sketching mad, that one!
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.
Changing our ways of thinking and doing isn’t easy. Sometimes it’s necessary though, and the first step on this journey is to let go. Let go of our imaginary feel of control. Forget the boundaries presented by our tools and ways of thinking. Break out of the silos we’ve created.
Really good advice for anyone thinking of releasing a polyfill into the world.
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 understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.
Everything that happens to the content prototype from now on is merely progressive enhancement. Because while the prototype is in a shared git repository, microcopy sneaks in, text gets corrected by a copywriter, photos change for the better and flows shape up, meta data is added, semantics are double checked, WAI-ARIA roles get in…
Cennydd enumerates what design sprints are good for:
- generating momentum,
- highlighting the scope of the design process,
- developing the team, or
- provoking core product issues.
And also what they’re not so good for:
- reliable product design,
- proposing sophisticated user research,
- answering deep product-market fit questions, or
- getting the green light.
Riffing on an offhand comment I made about progressive enhancement being a form of “technical credit”, Chris dives deep into what exactly that means. There’s some really great thinking here.
With such a wide array of both expected and unexpected properties of the current technological revolution, building our systems in such a way to both be resilient to potential failures and benefit from unanticipated events surely is a no-brainer.
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?
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.