Tags: process

221

sparkline

Friday, March 24th, 2017

Code (p)reviews

I’m not a big fan of job titles. I’ve always had trouble defining what I do as a noun—I much prefer verbs (“I make websites” sounds fine, but “website maker” sounds kind of weird).

Mind you, the real issue is not finding the right words to describe what I do, but rather figuring out just what the heck it is that I actually do in the first place.

According to the Clearleft website, I’m a technical director. That doesn’t really say anything about what I do. To be honest, I tend to describe my work these days in terms of what I don’t do: I don’t tend to write a lot of HTML, CSS, and JavaScript on client projects (although I keep my hand in with internal projects, and of course, personal projects).

Instead, I try to make sure that the people doing the actual coding—Mark, Graham, and Danielle—are happy and have everything they need to get on with their work. From outside, it might look like my role is managerial, but I see it as the complete opposite. They’re not in service to me; I’m in service to them. If they’re not happy, I’m not doing my job.

There’s another aspect to this role of technical director, and it’s similar to the role of a creative director. Just as a creative director is responsible for the overall direction and quality of designs being produced, I have an oversight over the quality of front-end output. I don’t want to be a bottleneck in the process though, and to be honest, most of the time I don’t do much checking on the details of what’s being produced because I completely trust Mark, Graham, and Danielle to produce top quality code.

But I feel I should be doing more. Again, it’s not that I want to be a bottleneck where everything needs my approval before it gets delivered, but I hope that I could help improve everyone’s output.

Now the obvious way to do this is with code reviews. I do it a bit, but not nearly as much as I should. And even when I do, I always feel it’s a bit late to be spotting any issues. After all, the code has already been written. Also, who am I to try to review the code produced by people who are demonstrably better at coding than I am?

Instead I think it will be more useful for me to stick my oar in before a line of code has been written; to sit down with someone and talk through how they’re going to approach solving a particular problem, creating a particular pattern, or implementing a particular user story.

I suppose it’s really not that different to rubber ducking. Having someone to talk out loud with about potential solutions can be really valuable in my experience.

So I’m going to start doing more code previews. I think it will also incentivise me to do more code reviews—being involved in the initial discussion of a solution means I’m going to want to see the final result.

But I don’t think this should just apply to front-end code. I’d also like to exercise this role as technical director with the designers on a project.

All too often, decisions are made in the design phase that prove problematic in development. It usually works out okay, but it often means revisiting the designs in light of some technical considerations. I’d like to catch those issues sooner. That means sticking my nose in much earlier in the process, talking through what the designers are planning to do, and keeping an eye out for any potential issues.

So, as technical director, I won’t be giving feedback like “the colour’s not working for me” or “not sure about those type choices” (I’ll leave that to the creative director), but instead I can ask questions like “how will this work without hover?” or “what happens when the user does this?” as well as pointing out solutions that might be tricky or time-consuming to implement from a technical perspective.

What I want to avoid is the swoop’n’poop, when someone seagulls in after something has been designed or built and points out all the problems. The earlier in the process any potential issues can be spotted, the better.

And I think that’s my job.

Wednesday, March 22nd, 2017

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!

Monday, March 20th, 2017

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.

Friday, March 17th, 2017

Should you learn [insert shiny new tool]? | Zell Liew

This ties in nicely with the new talk I’m doing on evaluating technology. Zell proposes a five-step process:

  1. Figure out what [insert tool] does.
  2. Figure out what sucks right now
  3. Determine if it’s worth the investment
  4. Learn it (if it’s worth it)
  5. Differentiate opinions from facts

Most of the examples he gives are tools used before deployment—I have a feeling that different criteria should apply when weighing up technologies written directly in user-facing code (HTML, CSS, and JavaScript).

Monday, March 6th, 2017

I swore I wouldn’t write another book - Web Designer Notebook

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.

Sunday, March 5th, 2017

Sketching at Clearleft.

An interview with Batesy that gives a nice insight into life at Clearleft.

He’s sketching mad, that one!

Wednesday, March 1st, 2017

Mood boards in a content-first design process — Thomas Byttebier

How style tiles can work great in combination with content prototypes:

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.

Sunday, February 19th, 2017

On Design Tools and Processes | Viljami Salminen

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 imagi­nary feel of control. Forget the boundaries presented by our tools and ways of thinking. Break out of the silos we’ve created.

Wednesday, February 8th, 2017

Polyfills and the evolution of the web - TAG finding

Really good advice for anyone thinking of releasing a polyfill into the world.

Monday, January 30th, 2017

Resilient Web and Tools — David Larlet

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?

Tuesday, January 3rd, 2017

Kiss My Classname - Zeldman on Web & Interaction Design

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.

Friday, December 16th, 2016

The bold beauty of content prototypes — Thomas Byttebier

Designing content-first:

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…

Wednesday, December 7th, 2016

What design sprints are good for — Cennydd Bowles

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.

Friday, October 14th, 2016

Technical Credit by Chris Taylor

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.

Tuesday, October 4th, 2016

Chasing Tools - TimKadlec.com

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:

  1. Who benefits from the use of this tool and how?
  2. Who suffers and how?
  3. How does it fail?
  4. Does the abstraction feed the core?

Tuesday, August 9th, 2016

Wednesday, July 27th, 2016

A Code Review, Or Yet Another Reason to Love the Web | Brad Frost

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.

Wednesday, July 20th, 2016

Questions for our first 1:1 | Lara Hogan

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.

Tuesday, July 12th, 2016

EmberCamp London Keynote 2016 // Speaker Deck

I really, really like what Ember is aiming for here:

First, we deliver the raw content, ensuring those on slow connections or without JavaScript get they’re after as soon as possible. Next, we load the minimum set of JavaScript needed to interactivity for that page, keeping transfer time and parsing time low. Once the user has an interactive page, we can start preemptively loading other parts of the application, including frequently-accessed data.

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.

How Will Web Components Change CSS Architecture? - Snook.ca

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.