Category Archives: Design

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.

My name is Stephen, and I’m a generalist

This week I had something akin to an existential crisis. The whole thing was solely in my head, and alarming in intensity. If you ask me what triggered it, I couldn’t tell you. Though it might have been that potential client that needs to learn about how to deal with potential contractors, but that’s another post entirely.

Part of this mental hurricane was me questioning what it is that I actually do. What is my job, exactly? I’ll spare you the worries about how this question might tie in to age discrimination and how I must remain my own boss in order to continue working. No. I can hear you thinking about it. Stop it.

In the 20 years I’ve been designing and developing for the web, I’ve considered myself a designer. A designer who can code, but still a designer. And indeed, when I started, I designed a lot. I came from print design. Design, especially typography, was what I loved to do. In the work realm, at least.

I wrote my first BASIC program when I was 12 years old. On a Commodore PET. Yes, I see you oldies nodding. We had an Apple II in a special room at school. One Apple II. Programming was like magic. Someone wrote code and made these computers do amazing things!

I was fairly good at math(s), roughly two years ahead of my fellow students, but I’m also easily bored. So after advanced trig, I kind of lost interest in both math(s) and programming. I liked it well enough, but I encountered a dull patch. Other things, like art and theatre, grabbed my interest.

Programming never did let me go. I came to realize that some things are simply more effectively done in code, and that there was space in my brain for both the technical and the creative. But people seem to fight against that particular brand of collaboration between the different parts of the mind. We’re told to specialize. You can’t just specialize in JavaScript; you must specialize in a particular aspect of JavaScript, such as performance. Or a particular library (good luck with that). You also can’t be a “designer”, because what exactly does that entail? Do you do interaction design? Visual design? Or as ambiguous as they come, user experience design?

If I put 10 people in a room and asked them to describe user experience design, I’d get 10 different answers. 11 if it’s a really creative group. While speaking recently at UXLx, I encountered UX designers who don’t draw. “I only do research”. Others design the user experience of websites without venturing into the browser. Graphing software is enough; after all, they’re UX designers, not UI designers. (Oops there’s another one for you.) Some UX designers did more visual design. Confusion ensued.

Not that these disciplines are bad or unnecessary. On the contrary. Nor is the fact that we might soon need a complex table to map out the various types of design we’ve created and their relationships to one another. But where we can complicate things, we tend to complicate things. And when specialization means money, we’re quick to specialize.

And now we’re entering a period in which the spectrum of specialists is just a bit too large for some projects. Like a feature film, all the disciplines need a lot of overhead to work together smoothly. And we look to the generalists. We might call them “product designers” or “full-stack [insert title here]”. Proficient in many areas, expert in one or two. For me, I’m an art director at heart with a lot of experience in graphic(visual) design, interaction, design processes and dealing with large-org project politics. And I can code.

When people ask me for a portfolio of recent design work, I’m shocked to discover that I really don’t have a clear one. The work I’ve done since going freelance five years ago is mostly front-end development combined with design and interaction work. Which all, believe it or not, is part the user experience. Thus, I’ve done front-end design and development consulting work. Accessibility work. Speaking. Writing a book. Co-organizing conferences.

Holy hypertext, Batman, I’m a generalist.

The thing that’s both scary and exciting at the same time is that no generalist is the same. This week I came to realize that I have no clue how to market myself effectively. (No that is not an invitation.) I’m an expert in a few things, and proficient in several more. But for every project, emphasis shifts within those areas.

This week, a friend told me that he doesn’t know what to call himself. Then he said, in his typical manner of a man who believes that every workday is just a holiday that starts with a “W”:

“Embrace the chaos.”

I like code. I like design. I like the place where design and technology meet. Where art and technology meet. It’s a special place. It exists and we should embrace it.

Conditional multi-column sublists

Some designers are able to operate in that universe where anything goes, where the practicalities of implementation don’t exist. This can actually be a good thing at the beginning of the creative process; without this no-limit thinking, the design process might yield less creativity. Then again, many designers are fantastic at working within constraints.

At some point, though, either designers are confronted with constraints and must accommodate them, or this is implicitly tasked to developers. The latter is often the case, unfortunately. This almost always leads to a series of little development puzzles. “How might I implement this?”

We can do a lot with CSS, but sometimes we need a little help from JavaScript. I consider myself a designer who codes, which, to be clear, means “not a programmer”. Lucky for me, I have programmer friends, and I read a lot.

So while working on a recent project, I encountered a design comp that called for a few adjacent lists of “filters” (read: tags or categories). Each list had a heading above it.

(Note that the following examples are not indicative of the visual design. Note also that they no sense on narrow screens, where the lists could simply flow vertically.)

Lists.

Being as creative as the designer in the sense that I didn’t burden myself with such practicalities as browser support (yet), I figured I could mock this up with Flexbox. Each section containing a header and a list becomes a flex item, and let’s let those wrap if they need to wrap. Easy enough.

Lists with Flexbox applied (CSS).

Lists with Flexbox applied (output).

In the design, some lists were longer than others. Lists with many items were to be split into multiple columns. Flexbox was taking care of the necessary flexibility of the main lists, but what to do about the sublists that are too long? And can we have any flexibility in determining what “too long” means?

A simple solution for splitting a list into multiple columns is CSS Multi-Column Layout. Implementations aren’t totally consistent, and I wrote some time ago about some of those inconsistencies, but the very basics are pretty usable right now as a progressive enhancement to normal content. Lack of multi-column simply yields a one-column list.

If one were to set a specific height to the containing element, multi-column would do it’s thing automatically. But I didn’t like the idea of setting a specific height on anything. A more content-centric approach would be to determine how many items a list may have before it was split into columns.

I’m fairly sure that determining the number of columns as a condition of the number of children is not currently possible with CSS. So in this case, it’s JavaScript to the rescue.

I needed a function that takes whatever element I’m using as a list, plus a maximum number of list items per column, as parameters. It should look at each list, count the number of items in it, and if the maximum number of list items is exceeded, it should add a class to that list. The class allows application of the correct number of columns via CSS.

Here’s the function, after too many iterations, a beer, and another pair of eyes:

Here is the function.

And here’s the result:

Here is the result.

This is not completely bulletproof, but it does allow for some flexibility (“let’s allow 10 items per column instead of five”).

This was a fairly simple problem to solve (though I won’t be competing in the Array.prototype Olympics anytime soon). But I’d like to say this: designers and developers should think about these types of implementation issues together, and that should happen during the design process. Not afterward, when stakeholders have fallen in love with the design comps. This would allow for consensus on the baseline experience (stakeholders tend to see design comps as the baseline). Quick mockups in browser-based tools such as JSBin (which I used for this example) or CodePen could help solidify these types of design decisions, and allow both designers and developers to experience these decisions on actual devices and to design for contingencies as well.

Special thanks to Jake and Heydon for being kind enough to review my example.