Tags: process

227

sparkline

Monday, May 22nd, 2017

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.

Tuesday, May 2nd, 2017

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.

Thursday, April 27th, 2017

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.

Wednesday, April 26th, 2017

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.

Thursday, April 20th, 2017

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.

Wednesday, April 19th, 2017

Designing the Patterns Day site

Patterns Day is not one of Clearleft’s slick’n’smooth conferences like dConstruct or UX London. It’s more of a spit’n’sawdust affair, like Responsive Day Out.

You can probably tell from looking at the Patterns Day website that it wasn’t made by a crack team of designers and developers—it’s something I threw together over the course of a few days. I had a lot of fun doing it.

I like designing in the browser. That’s how I ended up designing Resilient Web Design, The Session, and Huffduffer back in the day. But there’s always the initial problem of the blank page. I mean, I had content to work with (the information about the event), but I had no design direction.

My designery colleagues at Clearleft were all busy on client projects so I couldn’t ask any of them to design a website, but I thought perhaps they’d enjoy a little time-limited side exercise in producing ideas for a design direction. Initially I was thinking they could all get together for a couple of hours, lock themselves in a room, and bash out some ideas as though it were a mini hack farm. Coordinating calendars proved too tricky for that. So Jon came up with an alternative: a baton relay.

Remember Layer Tennis? I once did the commentary for a Layer Tennis match and it was a riot—simultaneously terrifying and rewarding.

Anyway, Jon suggested something kind of like that, but instead of a file being batted back and forth between two designers, the file would passed along from designer to designer. Each designer gets one art board in a Sketch file. You get to see what the previous designers have done, leaving you to either riff on that or strike off in a new direction.

The only material I supplied was an early draft of text for the website, some photos of the first confirmed speakers, and some photos I took of repeating tiles when I was in Porto (patterns, see?). I made it clear that I wasn’t looking for pages or layouts—I was interested in colour, typography, texture and “feel.” Style tiles, yes; comps, no.

Jon

Jon’s art board.

Jon kicks things off and immediately sets the tone with bright, vibrant colours. You can already see some elements that made it into the final site like the tiling background image of shapes, and the green-bordered text block. There are some interesting logo ideas in there too, some of them riffing on LEGO, others riffing on illustrations from Christopher Alexander’s book, A Pattern Language. Then there’s the typeface: Avenir Next. I like it.

James G

James G’s art board.

Jimmy G is up next. He concentrates on the tiles idea. You can see some of the original photos from Porto in the art board, alongside his abstracted versions. I think they look great, and I tried really hard to incorporate them into the site, but I couldn’t quite get them to sit with the other design elements. Looking at them now, I still want to get them into the site …maybe I’ll tinker with the speaker portraits to get something more like what James shows here.

Ed

Ed’s art board.

Ed picks up the baton and immediately iterates through a bunch of logo ideas. There’s something about the overlapping text that I like, but I’m not sure it fits for this particular site. I really like the effect of the multiple borders though. With a bit more time, I’d like to work this into the site.

James B

Batesy’s art board.

Batesy is the final participant. He has some other nice ideas in there, like the really subtle tiling background that also made its way into the final site (but I’ll pass on the completely illegible text on the block of bright green). James works through two very different ideas for the logo. One of them feels a bit too busy and chaotic for me, but the other one …I like it a lot.

I immediately start thinking “Hmm …how could I make this work in a responsive way?” This is exactly the impetus I needed. At this point I start diving into CSS. Not only did I have some design direction, I’m champing at the bit to play with some of these ideas. The exercise was a success!

Feel free to poke around the Patterns Day site. And while you’re there, pick up a ticket for the event too.

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.