Category Archives: Web

Put the “designers should code” debate to rest

Note (September 14, 2015): this post has also been translated into Chinese.

My acting coach in college used to say something to the effect of, “Be. Don’t show.” It was frustrating. He wanted us not to do the things that symbolized what was supposed to be happening in the scene; he wanted us to live the scene. A good example is acting like a drunk person. We see drunk people, and a natural tendency when doing a scene as a drunk person is to act the way you’ve seen drunk people act. But in many cases, that comes across as fake and obvious. Because people who are drunk often try to act sober.

I worked in an art gallery when I was in college, and once a year we would put on an exhibition of children’s art. One thing you notice when hanging hundreds of paintings and drawing by kids, especially the younger ones, is that many tend to draw symbols of what they see. The don’t draw the sun, they draw a circle with lines around it. Or squiggles. Mountains are triangles. Basic forms are used as symbolic depictions of objects.

This often continues into adulthood, unless one learns to draw at least at a basic level. And while perhaps repeated once too often, it is true to an extent that learning to draw realistically is learning to see. Learning to look carefully at what’s really there. What’s really happening. Circles on a wine glass become ellipses. The hard lines of the sun become gradations of color. Are you unable to draw, and don’t think you can? Grab an image, turn it upside-down, and draw what you see exactly. Don’t symbolize the image by thinking about the subject of it. Draw what’s actually there. For those inexperienced with drawing, it will be one of the best drawings you’ve ever made up to that point.

As designers for the web, depending on what type of designer you are, you are researching, structuring, adapting, testing, laying out, wireframing, setting type for, composing, and [fill in the blank]ing something that people will read, interact with, love, hate, tell others about, and perhaps take with them everywhere they go. And the medium is right in front of you, every day, so you as a designer for this medium have the opportunity to use it to prototype what you’re designing.

I’ve gotten my share of criticism for being one of those people to publicly state that it might be a good idea for web designers to learn some code. It took me several years to come to that opinion and it hasn’t changed much, but it wasn’t the coding that was important. It was the movement away from symbolic representations of that which we were designing. It was about not using flat images as a poor proxy for something that’s different for different people on different devices in different browsers. When I wrote Responsive Design Workflow, which describes a content and prototype-based approach to responsive design, people either loved it or hated it. Those who hated it did so because it was outside of their comfort zones, and because it involved learning basic HTML and CSS and getting into the browser as quickly as possible.

You can’t give me a wireframe, detailed as it may be, and tell me that you’ve designed the interaction of a particular product. You’ve just drawn a circle with squiggly lines around it, and you hope that reality will match. Good luck with that. Visual design influences interaction. Typography influences interaction. Content influences interaction. You either work together, as a team, or your bubble will burst at some point. You want to influence interaction? Get the thing into a browser and interact with it. Sculpt it. Shape it. Tweak it. Be, don’t show.

That’s what it’s about. Not about coding for the sake of coding. During the period of time leading up to my book’s publication, a lot of the tools we have available today to get into the browser quickly didn’t exist. I advocated code because I literally could not find tools that would get me to useful and realistic prototypes as quickly as code would. I had to use JavaScript and the command line to automate screenshots. We have tools that do that today. They do the same thing I did in the past, but they do it behind the scenes. There are now tools all over the place that can help get you get your product into the browser quickly. Even two years ago, we didn’t have many of those tools. That’s why many of us advocated learning to code.

Every so often there are articles and tweets about whether designers should learn to code. I think very little of it is constructive anymore; arguments swirl down into sewers of discussions on semantics, like whether coding is a profession or a trade, or whether HTML and CSS can actually be considered coding. It doesn’t matter.

Must designers learn to code? No. Would it benefit them in some ways? Yes. Is the code needed for much of prototyping more difficult than learning something like Photoshop? No. Can it become more difficult than Photoshop if I decide to dive deep? Yes. Are there ways to prototype effectively without learning to code? There are now. Can you still keep using Photoshop (or Sketch, or whatever) even if you learn some code? Absolutely.

It’s not about the code. It’s not even about the tools. Prototyping is about asking reality for feedback.

On diverse speaker lineups at conferences

There’s been a lot of discussion on Twitter about diversity in speaker lineups at web conferences.

Lea Verou wrote about the blindness of blind reviews, and while she was looking at the process of anonymized reviews in general, some tweets in and around this conversation debate whether anonymizing the speaker selection process eliminates bias. Zach Leatherman tweeted:

I don’t believe an anonymous conference speaker selection process eliminates bias any more than “not seeing race” eliminates racism.

I think Zach makes a good point. Not only does an anonymous selection not eliminate bias, but the only thing it guarantees is that the curators don’t know who they’ve selected.

This does not guarantee a diverse speaker lineup.

What anonymizing does is put a responsibility-absolving blindfold on biases, so one can inadvertently end up with a totally non-diverse lineup and then can say, “Hey, it was a fair selection because we anonymized.”

That’s a weak position, in my opinion. And yes, I know that some people “de-anonymize” in round 2 of their selection process. Kudos. For now, we (the team I work with) prefer invite-only for events with a small lineup, but that’s a post for another time.

We all have biases. But when it comes to biases regarding people, it’s what we do with them that counts. One approach could be to face those biases and consciously act against them in order to get the type of speaker lineup we want. What lineup that is might be different for everyone. You want an all-female lineup? Great. 50/50 split? Also great. Choose what you want and take responsibility for it. Own the selection process rather than hiding behind it.

One possible approach

I don’t have all the answers, but I’ve been a part of conference organizations for many years and maybe the approach we used for two editions of dsgnday and this year’s CSS Day could be useful to some. Again, I’m not saying “we did it right”. I’m just saying that we owned our process and got the lineups we wanted, and someone out there might benefit from our approach. It might not fit with your idea of the right approach. That’s fine. Anonymized curation is okay; I simply have reasons for not preferring it. Please read that again. Also, note that our team consists of four men. This is purely coincidental, something we’re acutely aware of, and is part of the reason we’re thinking so much about these issues.

We started with the goal of the conference itself, of course, which is a range of topics on web design in a broad sense of the word, since the day is meant to be something of a counterweight to the larger number of developer conferences we have here in the Netherlands. However, that doesn’t mean “no code”, so we have a huge base of speakers to pull from, including non-technical speakers.

Right away, our longlist included people we knew would be a good fit for the conference. Krijn, PPK, Martijn, and I kept a simple text file in a Dropbox that any of us could add to at any time when we thought of someone we thought would fit. (Disclaimer: I’m speaking at the event, and while I hope my talk is well-received, that’s in part a financial move since it’s not the most-attended conference in Europe and paying for speakers and their travel is very expensive.)

Setting the goals

While some conferences have a primary or secondary goal of creating a platform for new or less experienced speakers, we currently do not. It’s perfectly valid to require a certain level of speaking ability or experience for an event. There are plenty of calls for papers and other platforms for willing new speakers at other events.

We had also set a specific gender diversity goal for this conference: at least a 50%/50% male/female split. An uneven split in favor of female would have been fine as well. Note that this is a goal, not a quota.

I have to admit that several years ago, I would have found this approach to be ridiculous. I’ve even openly opposed this type of thing. But years in the industry and hearing more viewpoints and a bunch of other factors led to me completely changing my mind. If I just say to myself, “Write out a list of potential speakers”, mostly men come to mind. That’s not a bad thing, but it’s a true thing. Call it a built-in bias. I might just happen to know more male speakers. But it is a fact, at least right now. And to get the lineup we want, we have to consciously combat that tendency. Setting the goal is the first step.

Battling built-in bias

So while I had a couple of people I really wanted to speak (not only men, BTW), I left them on the longlist and did the following thinking exercise:

What if the entire world only consisted of women? Who would I like to have come and speak at this conference?

Names came easily, because we had consciously removed our natural bias by way of a simple thinking exercise. And no one can say that these are “token” (I hate that term) female speakers designed to fill a quota, because they were the people we honestly thought would do a great job and fit the subjects we wanted handled at the conference. Note that it’s getting easier and easier to think of female speakers without resorting to bias-removal thinking exercises. This is partly due to us knowing more female speakers, and also because when you consciously and consistently work to remove bias, it slowly starts to go away. At least, that’s how I experience it.

Anyway, we had several names, and we curated the final lineup based on the quality of each speaker’s work and presentation abilities, and how their varied expertise would combine into a day-long program.

This process might not be great, and the conference is not a big one, but we are really proud of the three lineups of fantastic, qualified women and men we’ve put together so far (we love you, speakers!). And there is no way we could have guaranteed this result with an anonymized process. Without taking responsibility and making conscious choices.

It’s hard to do. That’s why they call it work. :-)

Update from The Haystack

Well, hello there!

A lot has been going on around here, and the most important thing is arguably the fact that my book is now available. Responsive Design Workflow is now available through various booksellers, also via The book, which is quicker and easier to read than it was to write, explains the whys and hows of my basic responsive web design workflow, which I have presented about these past couple of years. It was my privilege to work with some great people behind the scenes, including Mr. Responsive Ethan Marcotte (who wrote the foreword), Jake Archibald (who was kind enough to be my tech editor), and Ana Nelson (author of Dexy, the document automation tool I currently use in my work).

The book site/page, which I’m scrambling to complete, will contain errata (my publisher explained that everyone makes mistakes, not just me, so I’ve stopped torturing myself, kind of) and code examples. In fact, I’ve already put the code examples on GitHub so readers don’t have to be the victim of my insane calendar.

Krijn, PPK and I just finished the Mobilism conference, which according to PPK might just have been the last Mobilism ever. We’ll have to see how that works out. It was a fantastic event nevertheless. I presented about web-based mockups, which are an important part of the responsive workflow.

Coming up in several weeks is CSS Day, a one-day event with eight speakers, each of which will be presenting about a specific CSS module. It might not come as a surprise that I’ll be handling Flexbox, as the layout specs have been my favorite CSS topic since I first presented about them in 2009.

I’ll also be speaking at Generate in London, Breaking Development in Nashville, plus a couple of other worthwhile, yet to be announced events. Also in the works: Responsive Design Workflow workshops! Stay tuned.

As for writing, I’ve obviously found time to write everywhere but here: the book, a feature on style guides (with a tutorial on one method of creating and automating them) for .net Magazine, and I’m now a (generally) bi-monthly columnist for the Dutch industry magazine Webdesigner.

In parallel with the above, I’m still doing client work, although the amount of projects I can do is limited since I started working independently two-and-a-half years ago, which even now still takes some getting used to. I have difficulty with saying “no”, but a heavy workload is good training for that.

There’s a family life in there somewhere. Social life is on the to-do list. :)