All posts by Stephen

Choosing between min-width and max-width media queries

I’m often asked a variation of the following question:

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.

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