Tags: process

214

sparkline

The Burden of Precision | Daniel T. Eden, Designer

I think Dan is on to something here—design tools that offer pixel perfection at an early stage are setting us up for disappointment and frustration. Broad brushstrokes early on, followed by more precise tinkering later, feels like a more sensible approach.

With the help of a robust and comprehensive design system, I am certain that we could design in much broader strokes, and concentrate on making the finished product, rather than our design outputs, highly precise and reflective of our ideal.

Relative Requirements – CSS Wizardry

I really like this exercise by Harry. I’ve done similar kinds of grading using dot-voting in the past. It feels like an early step to establishing design principles: “this over that.”

By deciding what we value up-front, we have an agreement that we can look back on in order to help us settle these conflicts and get us back on track again.

Relative Requirements remove the personal aspect of these disagreements and instead focuses on more objective agreements that we made as a team.

Inside Design: Clearleft

A profile of Clearleft from the nice people at InVision.

Although there is this:

The Art of Comments | CSS-Tricks

Great advice on writing sensible comments in your code.

How to write a talk - Notist

Rachel describes her process of putting technical talks together:

This method of creating a talk is the one that I find gets me from blank page to finished slide deck most effectively.

She also acknowledges that many other processes are available.

If you are stuck, and your usual method isn’t working, don’t be afraid to try a different approach even if just to get the ideas moving and take you away from staring at the blank page! You might discover that some types of talk benefit from an alternate starting point. There really are no rules here, other than that you do end up with a talk before you need to walk out on that stage.

Defining design principles at EMBL | Journal | The Personal Disquiet of Mark Boulton

Mark describes the process he favours for creating (discovering?) design principles, like the ones for EMBL (I must remember to add those to the collection).

All you do is be mindful of when the team repeats design desires. This could be several members of the team say the same thing in a slightly different way, or that you keep circling around and around a problem but struggle to articulate it. By being mindful at all times to this a team can quickly pull together principles that are derived from doing the work on their particular problem rather than principles which are imposed on the work. An important difference.

The Nature of Code

A web book with interactive code examples.

How can we capture the unpredictable evolutionary and emergent properties of nature in software? How can understanding the mathematical principles behind our physical world help us to create digital worlds? This book focuses on the programming strategies and techniques behind computer simulations of natural systems using Processing.

Another Lens - News Deeply x Airbnb.Design

A series of questions to ask on any design project:

  • What are my lenses?
  • Am I just confirming my assumptions, or am I challenging them?
  • What details here are unfair? Unverified? Unused?
  • Am I holding onto something that I need to let go of?
  • What’s here that I designed for me? What’s here that I designed for other people?
  • What would the world look like if my assumptions were wrong?
  • Who might disagree with what I’m designing?
  • Who might be impacted by what I’m designing?
  • What do I believe?
  • Who’s someone I’m nervous to talk to about this?
  • Is my audience open to change?
  • What am I challenging as I create this?
  • How can I reframe a mistake in a way that helps me learn?
  • How does my approach to this problem today compare to how I might have approached this one year ago?
  • If I could learn one thing to help me on this project, what would that one thing be?
  • Do I need to slow down?

whiteink — Tech lead: an introduction

A series of posts on the decisions and trade-offs involved in being a tech lead:

I think good tech leads spend a lot of their time somewhere in between the two extremes, adjusting the balance as circumstances demand.

Coherence, Lego and how naming things is hard: Patterns Day 2017

A great blow-by-blow account of Patterns Day by Hidde.

Purists versus Pragmatists

How the IETF redefined the process of creating standards.

To some visionary pioneers, such as Ted Nelson, who had been developing a purist hypertext paradigm called Xanadu for decades, the browser represented an undesirably messy direction for the evolution of the Internet. To pragmatists, the browser represented important software evolving as it should: in a pluralistic way, embodying many contending ideas, through what the Internet Engineering Task Force (IETF) calls “rough consensus and running code.”

Victor - WordRidden

This is what Jessica has been working on for the past year—working very hard, I can attest.

This wrap-up post is a fascinating insight into the translation process.

Johannes Dachsel – Making my website work offline – a service worker module for Processwire

If you use the ProcessWire Content Management System, Johannes has written a handy plug-in that allows you to specify which files should be cached by a service worker.

Are we making the web too complicated? | Seldo.Com Blog

Laurie Voss on the trade-off between new powerful web dev tools, and the messiness that abusing those tools can bring:

Is modern web development fearsomely, intimidatingly complicated? Yes, and that’s a problem. Will we make it simpler? Definitely, but probably not as soon as you’d like. Is all this new complexity worthwhile? Absolutely.

I agree that there’s bound to be inappropriate use of technologies, but I don’t agree that we should just accept it:

Are there some people using a huge pile of JavaScript and a monstrous build chain to throw together a single-pager web site with one box that collects an email address? For sure. And that’s silly and unnecessary. But so what? The misuse of technology does not invalidate it.

I think we can raise our standards. Inappropriate use of technology might have been forgivable ten years ago, but if we want web development to be taken seriously as a discipline, I think we should endeavour to use our tools and technologies appropriately.

But we can all agree that the web is a wonderful thing:

Nobody but nobody loves the web more than I do. It’s my baby. And like a child, it’s frustrating to watch it struggle and make mistakes. But it’s amazing to watch it grow up.

Creating a pattern library in Sketch, Roobottom.com

A smart approach to creating patterns as symbols in Sketch. Sounds like diligence and vigilance is required to make it work, but then, that’s true of any pattern library.

Using NPM as a Build Tool | gablaxian.com

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.

Painting with Code : Airbnb Design

Very clever stuff here from Jon in the tradition of Bret Victor—alter Sketch files by directly manipulating code (React, in this case).

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.

The work I like. — Ethan Marcotte

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.

That’s why I’ve realized just how much I like designing in layers. I love looking at the design of a page, a pattern, whatever, and thinking about how it’ll change if, say, fonts aren’t available, or JavaScript doesn’t work, or if someone doesn’t see the design as you and I might, and is having the page read aloud to them.

CodePen Projects Is Here! - CodePen Blog

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!

Untitled Sans & Serif Design Information · Klim Type Foundry

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.