“Why don’t you name your layers?”, asks Designer A, looking in disgust at her coworker’s latest instance of Artboard Copy 05. Designer B shrugs. Designer A visibly shakes, in the throes of obsessive compulsions.

Kittens are dying.

While I understand Designer A—after all, I wrote a book about a particular way of working—I often tend to side with Designer B. Here’s why.

Imagine two Sketch files. Both yield the exact same static image. In our example, stakeholders don’t see the Sketch file. Developers don’t see the Sketch file. They don’t see the layers; they don’t have to deal with the layers. In this case, it doesn’t matter how the layers are named.

Now imagine a relatively small design change. One designer makes a high fidelity mockup in Sketch with full spec. It takes an hour. Another designer opens the page in the browser, open the browser’s developer tools, makes some changes, and screenshots or saves the change and the dev tools CSS. It takes 10 minutes. Both communicate the same thing clearly, one takes less time.

Or a high-fidelity mockup where a super-quick Invision Freehand sketch and a couple of notes will suffice. Or a hand-drawn sketch on a sheet of paper and a 5-minute sit-down with a dev.

As designers, we’re good at asking critical questions. But often, we forget to do the same when it comes to our personal preferences regarding work tools and processes. Some of these questions will help provide direction about things such as naming conventions:

• How can I communicate this clearly, through the most effective application of my time and effort?
• Is this an artifact or a deliverable?
• Will others need to use it in non-exported form?
• Will this need to be reusable? To what degree?

The end result of a design effort, not including a product itself, is the communication of intent to those realising the production. Developers, for example. And usually non-technical stakeholders. This communication of intent, in whatever form, is your deliverable. All other side-effects leading to that deliverable are, arguably, artifacts. You could, in many cases, destroy them when you’re finished—without consequence.

How many of your Sketch files are really reused by other designers? How many are ever opened again? Do you work in a deeply data-informed environment, where myriads of A/B tests mean you’ll have to rework parts of a previous mockup that are irrelevant to your design changes? Is it quicker to take a screenshot of a current screen, and overlay changes? Are you putting effort into ways of working that make you feel good, but are irrelevant to communicating your intent?

It can be helpful for designers to ask themselves questions about the communication of intent. The following are in order. If you answer no to the first, then you ask yourself the next:

1. Will a [quick] conversation suffice?
2. Will a [quick] sketch suffice?
3. Will a screenshot with annotations suffice?
4. Will a low-fi mockup suffice?
5. Will a hi-fi mockup suffice?
6. Any combination of the above?
7. I need a prototype. At what level of fidelity?

Of course, ideally you’d come up with questions that fit your own circumstances. These are just examples.

I get it. I do. Emacs vs vim. Gulp vs Grunt. React vs Vue. Sass vs LESS. Spaces vs tabs. (The answer is spaces.) Everybody has preferences, ways of working that are effective for them. But think critically about whether you’re solving the right problem. Those particularities of your own working style might not add much to your actual goal.

Sometimes we present ourselves with the illusion that we’re doing something important. But the biggest waste of time is doing that which need not be done at all.

Since I switched my OS to Ubuntu a while back, I haven’t had a need for InDesign. Really, the only thing I ever used it for was for making badges. That doesn’t justify the cost to me, not only financially, but also in disk space. :-) So I’ve set out to make these badges in one of my favorite drawing tools: Inkscape. Since Inkscape is an SVG drawing program, and SVGs are text, I figured there might be some flexibility there.

That flexibility and freedom have a price, though. Instead of doing everything in one GUI app, a few different programs are involved. The workflow involves using the command line. It’s not a perfect process, but it works fairly quickly and well for me. That said, feel free to laugh at my awkward process. Open your copy of InDesign now. By the time you’ve finished reading this, InDesign should be open and ready to go.

Note that I’m not doing book design here; my use case is fairly simple. If print design were still my profession, I would most likely use the best software for the job.

My biggest problem with this workflow is that I kept forgetting what I did the previous time. That’s the main reason for me writing this, and for a couple of people who requested it. It’s essentially documentation for me, so I don’t forget again. That said, someone else somewhere might find it useful. This is for informational purposes only, and may not work on your system. I am unable to provide any support. It’s probably best not to follow along at all if you’re not somewhat comfortable in the command line.

I mainly work on a Linux machine, and this description is written from that point-of-view. Anyone following along on other systems might have to work out discrepancies or weirdness in their own environment.

With the disclaimer out of the way, let’s look at the process. This might seem a bit complex, but from my perspective the process is simple, and the following things are true:

1. I draw my artwork in Inkscape.
2. I have a CSV with attendee data.
3. I type one command to generate a file for each badge.
4. I type one command to combine those files into a single PDF.
5. I send the PDF to the printer.

Note that in a GUI, instead of typing a command, I would probably choose various commands from one or more menus. So, to be clear, from my perpective, this is not more work than doing this all in a GUI program. I will concede to the fact that there is more complexity in the tools I use, as you have to install three, and they might not work the same on every OS. This process assumes a Linux-like OS, and enough knowledge on your part to recognize things you might need to change to get them to work on you particular OS. Instead of InDesign (and a tool to convert a UTF-8 CSV into UTF-16), I need three tools, which I’ll describe below. These tools are freely available and don’t take up much space. The time it takes to generate the badges is not longer (and often shorter) than doing the same with commercial tools.

Badges are made in Inkscape, and data from CSV is merged using a Ruby gem called inkscape merge. It’s not ideal, but it works fairly well in that Inkscape can be used and I’m not locked in to a specific software vendor’s software and workflow. The process outlined here is simple and has kinks, but lots of things could be scripted to do more complex stuff, like customizing visual differences between speaker badges and attendee badges, etc.

2 Creating the Inkscape and CSV files

Badges are made in Inkscape any way you want. You’ll have to have a separate file for each side of the badge, unless both sides will be identical.

I draw my own crop marks for the printer in my document, put them in their own Inkscape layer, and lock it. Then I draw the rest. You can also do this after the artwork, but I like to get it out of the way at the beginning. If I want to show my colleagues what a badge will look like, I’ll make a selection of the printed area and use Inkscape’s “Export bitmap” function to make a PNG of it to show. Obviously, I’ve already consulted with the printer about what they need to receive from me before I even start. I’ve worked with printers for whom InDesign was literally the only option. We like our current printer.

Text that is to be replaced by CSV data should be indicated like so: %VAR_csvColumnName%, where csvColumnName corresponds to a column in the CSV. The CSV might look like this:

name,company,twitter,
Stephen,Zero Interface,@stephenhay,
PPK,Quirksmode,@ppk,
Krijn,Qontent,@krijnhoetmer,
Martijn,,@Martijnvduuren,

This is essentially the following structure:

name	company	twitter
Stephen	Zero Interface	@stephenhay
PPK	Quirksmode	@ppk
Krijn	Qontent	@krijnhoetmer
Martijn		@Martijnvduuren

If I were to have a bit of text in my Inkscape SVG file with %VAR_name%, then when I run inkscape_merge with the above CSV file, that variable would be replaced with “Stephen”, “PPK”, “Krijn”, and “Martijn”, each in their own file.

The CSV file should be UTF-8 encoded.

inkscape_merge --csv_col_sep='|' -f badge.svg -d data.csv -o batch/badge_%d.pdf
/var/lib/gems/1.9.1/gems/inkscape_merge-0.1.3/bin/inkscape_merge:33:in `block (2 levels) in <top (required)>': undefined method `csv_options' for #<OptionParser:0x00000002322088> (NoMethodError)
        from /usr/lib/ruby/1.9.1/optparse.rb:1360:in `call'
        from /usr/lib/ruby/1.9.1/optparse.rb:1360:in `block in parse_in_order'
        from /usr/lib/ruby/1.9.1/optparse.rb:1347:in `catch'
        from /usr/lib/ruby/1.9.1/optparse.rb:1347:in `parse_in_order'
        from /usr/lib/ruby/1.9.1/optparse.rb:1341:in `order!'
        from /usr/lib/ruby/1.9.1/optparse.rb:1432:in `permute!'
        from /usr/lib/ruby/1.9.1/optparse.rb:1453:in `parse!'
        from /var/lib/gems/1.9.1/gems/inkscape_merge-0.1.3/bin/inkscape_merge:11:in `<top (required)>'
        from /usr/local/bin/inkscape_merge:23:in `load'
        from /usr/local/bin/inkscape_merge:23:in `<main>'

inkscape_merge -f sourcefile.svg -d datafile.csv -o batch/badge_%d.pdf

inkscape --without-gui --export-pdf=outputfile.pdf --export-dpi=300 sourcefile.svg

inkscape_merge -f sourcefile.svg --format png -d datafile.csv -o batch/badge_%d.png

4 Combining the batch files into a single PDF

Printers generally want PDFs, so whether our batch consists of PDFs or PNGs, we’re combining them into a PDF.

Make sure you’re in the batch directory first.

4.1 Combining multiple PDFs into a single PDF

To do this with PDFs, we use ghostscript:

gs -sDEVICE=pdfwrite \
    -dNOPAUSE -dBATCH -dSAFER \
    -sOutputFile=combined.pdf \
    `ls`

For more info and variations, see https://www.linuxjournal.com/content/tech-tip-using-ghostscript-convert-and-combine-files.

The `ls` turns the output of the ls command into input for the gs command. You could also use * or $(ls) instead, in this case. If you’re in the batch directory, the output of ls is a list of all the files that we generated before.

4.2 Combining multiple PNGs into a single PDF

For PNGs, we’ll use ImageMagick’s convert command:

convert -limit memory 2MB `ls` combined.pdf

We’re limiting memory usage to 2MB here, because otherwise with many files, sometimes the system will kill the process because it’s using too much memory.

Finally…

That’s it! This is how we’ve been making most of our conferences badges for over a year now (except for one which involved HTML, CSS and PHP). The above process is pretty painless once you’ve run through it a few times, and generating a file with about 300 badges only takes a few minutes. Since SVGs are text, and inkscape_merge variables can replace any text in the SVG, you can customize colors per badge or practically anything else. You could potentially do any kind of scripting you like. And of course, you could wrap all of this in a tidy bash script for easy execution.

I’m in the process of making a demo video of this workflow, in which I also demonstrate using variables for colors. This should be done in a day or two, and I’ll post a link here when it’s done!

Reality is messy.

Some people are fortunate enough not to have to deal with this reality on a daily basis. There are people who work for browser-makers. Their projects are not most projects. There are people who work for large-scale and popular “startups”, who have the luxury of focusing on a limited number of components. Their projects are not most projects. Although we can (and do) learn a lot from posts on Medium about month-long experiments in link underlining, many of us have pressing deadlines. Processes can be messy because they involve other people and limited resources, tight budgets, difficult stakeholders and ridiculous time constraints.

Outside of the product world, many of us work in creative and/or technical services. Our job is to help our clients. These clients have concerns during the design and development process that we need to address. Sometimes, we can’t do everything exactly as we would like. Client needs trump our own.

I’ll give you an example: a project I worked on where my job was to help take an existing desktop-centric design and make it responsive. My task was to determine exactly how everything would work responsively. My deliverable was a series of more than 20 design comps built with HTML and CSS. The comps were themselves responsive, so stakeholders and the developers knew what the end result should be.

Here’s the thing: there were extreme time constraints. We basically had two months to get this fairly complex website responsive. In order to do this, the developer would change as little HTML as possible, as this would mean rewriting components all over the place. Yes, we wanted to see that happen, but it wasn’t feasible. So I used the existing HTML whenever possible, and I cringed while doing it, because holy shit, this HTML (with all due respect to the developers; you know CMSes). But it was practical and allowed the developer to reuse a lot of my CSS. Which was a lot more CSS than I would have had to write if I were able to rewrite the HTML.

Could I have said no? Sure, but I wouldn’t have been helping anyone, least of all myself, by doing so. This client has interesting challenges, and I wasn’t willing to just say no to four months of work with them because of a tight deadline.

Another issue I had to deal with was working in weekly (!) sprints. Coming up with responsive strategies for each component of certain screen types and then prototyping them in one week was not easy. In order to do it without creating conflicts and still get things done on time, I had to namespace each logical group of components, like this:

.product {
  /* Styles, including media queries, here. */
}

.account {
  /* Same idea, different logical group */
}

While doing this for each round of logical prototype groups allowed me to avoid conflicts with prototypes I had done or those I would do in future sprints, it made me repeat myself across those blocks, since I had literally no time to constantly refactor. And it was not my job to create the front-end code, though I knew the developer was using and altering snippets from my CSS to save time. Result: my comps had way too much CSS.

Could I have an approach like BEM? Yes, I could have. But since some CSS methodologies eschew inheritance, I lose a huge time benefit. And remember, HTML changes were required to be minimal, and that’s not feasible when choosing a CSS approach that involves moving the dirty work into class attributes.

What’s your goal?

In the project above, the thing that kept me sane was focusing on the specific reason I was asked to join the project: to decide how everything should look and work responsively, and to visualize this for stakeholders and the developers, in such a way that they could actually experience it on actual devices so that it is clear what needs to be done.

That had to be my focus.

We finished the work in two months with just a few people. And a phase two was planned to go in and refactor, to improve lots of things, including performance. That’s the right time for optimizing HTML and CSS, and improving things like performance. Ideal? Certainly not. Realistic based on the needs of the client? Absolutely. This particular client sees their website (100% of their revenue comes from the website) as a process rather than a product. I think that’s a healthy way of looking at things. It means they have a responsive site, built within two months time, that customers could enjoy right away. That site, even with sub-optimal HTML and CSS, performed twice as well as the previous desktop version. Customers don’t care about what the source looks like, and phase two, almost underway, is intended for code optimization and other quality improvements.

Messy, isn’t it? It certainly is. But really, it’s often the reality of a service business. It’s natural to try and find processes or approaches that work for every project, but you won’t. And they don’t. Embracing this fact is one step toward pleasing clients, and also helps deal with the frustration that we can’t always make everything as perfect as we’d like it to be. Of course, that shouldn’t keep us from trying.

I start every project with a lofty goal of achieving perfection. I’ve never reached it. I make mistakes all the time. I look back and immediately see things I would have done differently. I try to learn from those mistakes. I try to remember that making those mistakes and dealing with the messy reality of the work, while still trying to do my best work, puts me on a path of constant improvement.

We need to give ourselves a break. I hope I’m learning more and becoming just slightly better every day. I hope you are, too. In our line of work, where everything moves so quickly, that’s something to be happy about.

Here’s to a better imperfect year than the last one.

Should I use min-width or max-width media queries?

The obvious answer is, of course, “yes”. But you know what they’re asking: which of the two is better?

Those for whom responsive design has become second nature might find it an odd question, and will know that the answer is, “it depends”. But having seen lots of responsive design implementations, it’s clear to me that many designers and developers aren’t quite sure. And I’m happy to share my own opinion of what “it depends” means regarding this particular question.

Desktop first and max-width

There’s a decent number of designers/developers that still think of “the desktop” as their primary design manifestation, with other (generally smaller) sizes as secondary; often these appear as afterthoughts, since there can be significant visual clues as to the amount of effort that has gone into these other screen sizes when compared to their desktop counterparts. Often, when one examines the CSS of these sites, `max-width` is the media feature of choice.

This makes sense. If a design is built desktop-first, then all the CSS for the desktop-ish version of the design has been written, and must be overridden with more CSS for any other breakpoints. If a given desktop-ish width is our baseline and we are unwilling or unable to refactor our CSS, then it seems logical to override what is now our base CSS for all viewport widths with those we only want to apply to smaller widths.

This can lead to a situation I’ve often joked about: writing styles only to undo them later. This is an example I often use (assume .related takes the form of a sidebar):

.content {
  width: 60%;
}

.related {
  width: 40%;
}

@media screen and (max-width: 37.4em) {
  .content,
  .related {
    width: 100%;
  }
}

The above example omits a lot, but I’m sure you get the idea. This approach, when used over a bunch of components, can greatly increase the amount of CSS needed to complete the project. But the main problem is how illogical it is, because when embracing the fact the block-level elements are 100% of their parent by default, then the following makes much more sense:

@media screen and (min-width: 37.5em) {
  .content {
    width: 60%;
  }

  .related {
    width: 40%;
  }
}

Here, we’re making use of the default state of block-level elements, and overriding them when they need to change from the default. Again, it might seem clear to some readers, but it doesn’t take looking at the source of many websites before you understand why I’m clarifying it here.

Using max-width against your better judgement

There are a couple of reasons why, even when you know better, you might deliberately choose to use an approach similar to max-width approach above:

1. You’re a developer and you received desktop-only, desktop-first, or other-sizes-as-an-afterthought comps from the designer. How can you know? If you’ve only designed or received designs for desktop-ish widths, this is what you’re dealing with. If you’ve got nice detailed desktop-ish designs with a few “mobile” or “tablet” examples thrown in there, this is what you’re dealing with. In these cases, may the max-width be with you, unless you have a budget and/or schedule that allows you to refactor during development.
2. You’re making an existing website responsive, and the existing CSS is design baggage you’ve inherited and cannot change, for whatever reason.
3. You’re compensating for the fact that we don’t currently have element queries, and you’re handling this with CSS instead of using a JavaScript polyfill for a non-existent spec.

So, what’s the best to use?

Here’s my clarification of “it depends” for this particular question. And remember it’s just my own opinion based on my own experiences: look at default display of a given element. If you have to override this default for smaller screens, use max-width. If the default is usable on small screens, use min-width, and only when the element needs to deviate from the default. And of course, I recommend letting the content determine where that happens.

A good example of using max-width to override an element’s default display so that it works better on smaller screens is when using tables. Imagine a table that contains too much content to display in its default form on small screens. One approach might be:

@media only screen and (max-width: 30em) {
  .big-table tr,
  .big-table td {
    display: block;
  }
}

This turns each row (and cell) into a block on narrow screens. The table can become quite long vertically and more styling is usually required, but it’s often better than the back-and-forth horizontal scrolling that would otherwise be required to read the content.

In this case, it makes all the sense in the world to leave the table in default form, except for in browsers that understand the media query and where the screen is no larger than, in this case, 30em.

Other elements (I would venture to say most other elements) that have defaults that work fine on smaller screens, only need changing when necessary on larger screens; using min-width is then a solid choice.

In short: let element defaults help determine which media feature to use in your media queries.

Thanks to Brad Frost for reviewing this. He also has a post with related topics.

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.

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. :-)

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.

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.

I’m not implying that all interaction designers work this way, nor that all design firms work this way. But it is absolutely a common practice, especially in larger, waterfall-style organizations and teams.

The assembly line workflow is a death punch to effective interaction. The reason this is so: you simply can’t separate visual design from interaction design. The visual designer (boy, do I dislike that term) likely has a background in graphic design, a legitimate and non-trivial field of study. Graphic designers are trained to solve problems, and a primary goal of the designer is to communicate something. The goal of the interaction designer is to find the most effective ways that people can interact with the thing we’re designing. Interaction designers and visual designers should either have both of these roles combined, or they should work together. A lot.

Many visual designs are built upon the foundation of complex wireframes. Why not the other way around? Arguably, the interaction designer’s insight might be best utilized as part of the visual design process with the most valuable insights occurring on a completed visual design comp, based on real content and in a browser, when the actual thing can be interacted with, as opposed to a black-and-white, hopeful proxy.

The fact is that when an interaction designer creates a wireframe, they’re inevitably making visual design choices. When these wireframes are used as client deliverables, clients can’t “unsee” these decisions. Similarly, visual designers make decisions that can heavily influence interaction, no matter what the interaction designer theorized. So, we’ve got two disciplines, possibly trained differently, making decisions for one another instead of with one another.

The influence of the visual

I’d like to offer a simple illustration on how visual design can influence interaction. Seth Godin wrote a great little post entitled The First Rule of Web Design, which he says is “tell me where to click”. (Regardless of whether this is or should be the first rule of web design, I do take issue with the word “click”. Godin’s later clarification, “What do you want me to do now?” is much more effective.)

Seth illustrated his point with two images. Please go and read his post to understand the context. Both are examples of how visual design can heavily influence how the user interacts with the sites in question, and how either clarity or confusion is created by design choices.

If you examine the first image, a screenshot of part of the process to get a refund, the conscious choice to present the most important thing relating to the purpose of this component as a simple link (text), which has to compete with huge (size) green and gray buttons (color). These buttons are placed where one would normally expect to act on the preceding text (placement/layout). These design choices make for stunted interaction. This is either inappropriate design, or someone did a nice job of making it slightly harder to get a refund.

The problem with the second example is not so much related to color as it is to the choices as to what should be a form element and what should not. The word “Next” offers an action to continue the current process, and should at the very least be structurally and visually closer to the input field. In my opinion, “Regenerate Token” could either be a link, or a less competing color and placed where the “Next” button is currently.

In both examples, wireframes could have, but would not have necessarily anticipated or solved the interaction problems created here. Wireframes or not: once we have these things in the browser, it’s time to go and revisit the interaction after visual design has either helped it or hurt it.

As one of those crazies who doesn’t use an image editor (like Photoshop) to create design comps, I’m often lumped into the design-in-the-browser category. So let’s clear things up a bit with my take on this approach.

You don’t actually design in the browser

Okay, you can design in the browser, meaning you open up a blank HTML file in both a text editor and a browser and have at it. But why would you? Some people really mean this when they speak of designing in the browser. But in my experience, that’s often not what we’re really talking about.

When I speak of designing in the browser, I mean creating browser-based design mockups/comps (I use the terms interchangeably), as opposed to static comps (like the PSDs we’re all used to). So it’s not the design. It’s the visualization of the design—the one you present to stakeholders. It’s not the only deliverable, but it’s the one that’s most important to show in the browser. Before that, I sketch. On paper. Other people I know who “design in the browser” actually use Photoshop. For sketching. But when we say “designing in the browser”, we mean the comp is in the browser.

We sure do like our comfort zones

Creating comps like this puts many designers out of their comfort zones. Many feel they have to learn to code, or “think in HTML and CSS”. Those who know that isn’t true can still feel awkward pairing up with a developer to visualize designs. That said, I think that learning CSS can be a useful addition to a designer’s toolbox. Note that in all my talks and in my book, I’ve only ever stated my opinion that browser-based comps are preferable to Photoshop-based comps. I have never stated that code should replace Photoshop.

That said, I’m increasingly frustrated by the articles, talks and discussions defending Photoshop comps, almost all of them citing Dan Mall’s idea of “deciding in the browser” rather than “designing in the browser”. I do agree with Dan; in fact, designers should already have been “deciding in the browser”, for years, especially when doing static image comps. If you design for the browser, you decide in the browser.

So much effort is being put into stating the case for static image comps, almost as if to justify the current (which is also the past) way of working. “Let me tell you why I want to stay in my comfort zone.” “Let me tell you what you other disciplines need to do for me so that I can continue to stay in my comfort zone and do things the way I’ve always done.”

It would all be fine, if it weren’t complete bullshit. And that is partly due to the flimsy premises of the arguments given.

Flimsy arguments

I don’t mean to pick on any specific article, but I’m compelled to provide an example and this particular article really got to me. Probably because I’m sure the author is skilled and talented, and thus many folks who read the article might swallow the premises whole. But looking at the points made, I’m inclined to disclose a couple of fallacies.

1. The author states that the desire to increase the speed of design and development is the driving force behind designing in the browser. While speed may be a factor, it’s arguably not the main factor, and certainly not the only one. More important, for example, is bridging the traditional gap between what the client sees in a comp versus the end result.
2. The implication of the sentence that follows is that web-based comps help speed but reduce the quality of the design work being produced. Tell that to The Guardian.
3. The author then proceeds to make the case for Photoshop instead of code (albeit with an 80/20 split). Nothing wrong with that, but the author’s personal experience with code yielding “dull” designs does not mean that code yields dull designs. It most likely means that the author tried getting into code too soon, or skipped sketching altogether, or is simply not as comfortable in code. I would agree that might not work out well. But in that case it’s the design process at fault, not the fact that code is used at all.

Code can support the creative process

Fabulous, creative things are being done with code. Just because some of us are more comfortable with graphical tools doesn’t negate that fact. It simply means that we’re less comfortable with code because we don’t know it as well as the tools we’ve been using for years and years. Which is logical, if you haven’t learned to code yet use Photoshop daily. And if you’re in my age range, you’ll remember that we didn’t always use Photoshop to create design comps. We had to get out of our comfort zone and learn it. And learn it we did, eventually.

For every person who tries opening a text editor and typing code from scratch before claiming “FAIL”, there are scores of us who actually sketch before even touching code. And I know designers who don’t code, but team up with developers to create design comps in the browser.

If you prefer using graphical tools, that’s fine. Nothing wrong with it. No one’s attacking you. But don’t say web-based comps are about speed when they’re not, that the process is less creative when your own approach to it is the problem. Photoshop is neutral. Code is neutral. It’s what you choose do with them and how.

I think code is a valuable tool, and I think web-based comps offer a plethora of benefits to the design process, clients, and teams. But again, I said web-based comps offer benefits as compared to Photoshop comps. Not “code is better than Photoshop”. That’s a huge difference. Designers know Photoshop; not all of them know the benefits of code as a design tool. I feel it’s important to talk about that.

Nobody is going to take your copy of Photoshop away from you. So since no one’s attacking, perhaps there’s no real need to defend. With false statements at that. In fact, for every defensive article or talk or tweet against code, I think about how time could have been spent learning some.

Creativity is tool-independent.