Tags: workflow

70

sparkline

Reluctant Gatekeeping: The Problem With Full Stack | HeydonWorks

The value you want form a CSS expert is their CSS, not their JavaScript, so it’s absurd to make JavaScript a requirement.

Absolutely spot on! And it cuts both ways:

Put CSS in JS and anyone who wishes to write CSS now has to know JavaScript. Not just JavaScript, but —most likely—the specific ‘flavor’ of JavaScript called React. That’s gatekeeping, first of all, but the worst part is the JavaScript aficionado didn’t want CSS on their plate in the first place.

Front-end development is not a problem to be solved | CSS-Tricks

The sentiment is that front-end development is a problem to be solved: “if we just have the right tools and frameworks, then we might never have to write another line of HTML or CSS ever again!” And oh boy what a dream that would be, right?

Well, no, actually. I certainly don’t think that front-end development is a problem at all.

What Robin said.

I reckon HTML and CSS deserve better than to be processed, compiled, and spat out into the browser, whether that’s through some build process, app export, or gigantic framework library of stuff that we half understand. HTML and CSS are two languages that deserve our care and attention to detail. Writing them is a skill.

When your design system fails — HeyDesigner

You could create components that strike the perfect balance between reuse and context sensitivity. But defining the components of your design system is just the first step. It has to make its way into the product. If it doesn’t, a design system is like a language with no extant literature or seminal texts.

Marissa Christy outlines the reasons why your design system might struggle:

  1. The redesign isn’t prioritized
  2. The tech stack is changing
  3. Maintenance takes discipline

But she also offers advice for counteracting these forces:

  1. Get buy-in from the whole team
  2. Prioritize a lightweight re-skin on older parts of the product
  3. Treat a design system like any other product project: start small
  4. Don’t wait for others. Lead by example.
  5. Finally, don’t compare yourself to others on the internet

Designing With Code

How mucking about in HTML and CSS can lead to some happy accidents.

‘Sfunny, people often mention the constraints and limitations of “designing in the browser”, but don’t recognise that every tool—including Sketch and Photoshop—comes with constraints and limitations. It’s just that those are constraints and limitations that we’ve internalised; we no longer even realise they’re there.

How can designers get better at learning from their mistakes?

Jon has seven answers:

  1. Build a culture to learn from mistakes
  2. Embrace healthy critique
  3. Fail little and often
  4. Listen to users
  5. Design. Learn. Repeat
  6. Create a shared understanding
  7. Always be accountable

It’s gratifying to see how much of this was informed by the culture of critique at Clearleft.

“Designer + Developer Workflow,” an article by Dan Mall

Dan compares the relationship between a designer and developer in the web world to the relationship between an art director and a copywriter in the ad world. He and Brad made a video to demonstrate how they collaborate.

What walls are for – disambiguity

Digital things look ‘finished’ too soon. When something is a work in progress on a wall, it looks unfinished, so you keep working on it. moving things around, reshaping things, connecting things, erasing things, and making them again. Walls make it easier to iterate. Iteration, in my opinion, is massively correlated with quality.

Should I try to use the IE version of Grid Layout? Revisited for 2018

Rachel follows up on my recent post about CSS grid in old IE with her thoughts.

As Jeremy notes, the usefulness of a tool like Autoprefixer is diminishing, which is a good thing. It is becoming far easier to code in a way that supports all browsers, where support means usable in an appropriate way for the technology the user has in front of them. Embrace that, and be glad for the fact that we can reduce complexity based on the increasing interoperability of CSS in our browsers.

Accessibility for Teams

I really, really like the way that this straightforward accessibility guide is subdivided by discipline. As Maya wrote in the blog post announcing its launch:

Each person on a team, whether you’re a manager, designer, or developer, has a role to play. Your responsibilities are different depending on your role. So that’s how we structured the guide, with a separate section for each of five roles:

  • Product management
  • Content design
  • UX design
  • Visual design
  • Front-end development

The three lessons that changed how I think about design systems

  1. Know where you stand before starting the journey
  2. Make sure everyone is speaking the same language
  3. Integrate the right tools into your team’s workflow

Fostering a Web Performance Culture - José M. Pérez

Six steps to kickstart a web performance culture:

  1. Your dev environment is not your user’s environment
  2. It’s better to learn the fundamentals than the library
  3. Get the time to experiment and validate
  4. Educate your colleagues
  5. Share and celebrate success (and failure) stories
  6. Make performance part of your workflow

Acephalic Agile—worse than Waterfall? - Oliver Wyman Labs: Technical

Agile itself provides us with the ability and opportunity to correct course, it allows us to steer, but it does nothing as such to help us steer correctly.

This observation about (some) agile projects is worryingly familiar:

I was suddenly seized by a horrible thought: what if this new-found agility was used, not teleologically to approach the right outcome over the course of a project, but simply to enshrine the right of middle management to change their minds, to provide a methodological license for arbitrary management? At least under a Waterfall regime they had to apologise when they departed from the plan. With Agile they are allowed, in principle, to make as many changes of direction as they like. But what if Agile was used merely as a license to justify keeping the team in the office night after night in a never-ending saga of rapidly accumulating requirements and dizzying changes of direction? And what if the talk of developer ‘agility’ was just a way of softening up developers for a life of methodologically sanctioned pliability? In short, what if Agile turned out to be worse than Waterfall?

You are not your tools

The technologies you use, the tools you build with, are just that: tools. Learn to use them, and learn to use them well. But always remember that those tools are there to serve you, you are not there to serve your tools.

Interface Lovers

Interviews with designers, where they talk about their backgrounds, tools, workflows, and day-to-day experiences.

I finally made sense of front end build tools. You can, too.

I still find the landscape of build tools completely overwhelming, but I found this distinction to be a useful way of categorising the different kinds of build tools:

Build tools do two things:

  1. Install things
  2. Do things

So bower, npm and yarn install things, whereas grunt, gulp, and webpack do things.

I think.

Everything Easy is Hard Again – Frank Chimero

I wonder if I have twenty years of experience making websites, or if it is really five years of experience, repeated four times.

I saw Frank give this talk at Mirror Conf last year and it resonated with me so so much. I’ve been looking forward to him publishing the transcript ever since. If you’re anything like me, this will read as though it’s coming from directly inside your head.

In one way, it is easier to be inexperienced: you don’t have to learn what is no longer relevant. Experience, on the other hand, creates two distinct struggles: the first is to identify and unlearn what is no longer necessary (that’s work, too). The second is to remain open-minded, patient, and willing to engage with what’s new, even if it resembles a new take on something you decided against a long time ago.

I could just keep quoting the whole thing, because it’s all brilliant, but I’ll stop with one more bit about the increasing complexity of build processes and the decreasing availability of a simple view source:

Illegibility comes from complexity without clarity. I believe that the legibility of the source is one of the most important properties of the web. It’s the main thing that keeps the door open to independent, unmediated contributions to the network. If you can write markup, you don’t need Medium or Twitter or Instagram (though they’re nice to have). And the best way to help someone write markup is to make sure they can read markup.

Sketching in the Browser – SEEK blog – Medium

A step-by-step account of trying to find a way to keep Sketch files in sync with the code in a pattern library. The solution came from HTML Sketchapp, a more agnostic spiritual successor to AirBnB’s React Sketchapp.

The contract was incredibly straightforward—as long as you generated HTML, you could import it into Sketch.

After some tinkering, Mark Dalgleish came up with a command line tool to automate the creation of Sketch libraries from HTML elements with data-sketch- attributes.

Saving Your Web Workflows with Prototyping · Matthias Ott – User Experience Designer

A well-written (and beautifully designed) article on the nature of the web, and what that means for those of us who build upon it. Matthias builds on the idea of material honestly and concludes that designing through prototypes—rather than making pictures of websites—results in a truer product.

A prototyping mindset means cultivating transparency and showing your work early to your team, to users – and to clients as well, which can spark excited conversations. A prototyping mindset also means valuing learning over fast results. And it means involving everyone from the beginning and closely working together as a team to dissolve the separation of linear workflows.

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.