Archives filed under "design process"

Web designers who are interested in providing an optimal experience for viewports of widely-varying width—I’m looking at you, traditional computers, iPhone & iPad—will be very interested in responsive web design.

A term coined by Ethan Marcotte in a revolutionary article (and compelling read), responsive web design takes together a number of elements that have been rattling around recently—CSS3 media queries, fluid grids, flexible images, in particular—and Marcotte showed how they can interact with one another to provide a powerful web presence across widely varying viewports. Since then, he’s expanded upon the subject by publishing a book. It’s the single best place to go in order to get up-to-speed on the subject—although, like all “A Book Apart” titles, it’s woefully small & at best a very general introduction to the subject.

I’ve just completed the process of converting a site I’ve been working on to a responsive design. This site is an ideal candidate for a responsive web design approach in that it’s an academic site & the participants, the prime candidates to access its content, are all around the world. The site provides information about upcoming workshops, meaning that the target viewers (participants in the academic project) are very likely to access the site’s content while using handheld devices such as the iPhone or iPad. As such, I received a nice introduction into the subject, particularly with the real-world repercussions.

Janus Cascade

One thing that I didn’t notice in Marcotte’s article or book is that by wrapping our designs in media queries, a style’s cascade is now two-facing. There are massive implications with this approach, and if you take a pixel-based approach, as opposed to the percentage-based approach Marcotte takes, all hell breaks loose. Here’s an example to show what I mean:

Say you have a DIV & when the viewport is a desktop size, you want it to be 100 pixels & float left; but on an iPad’s portrait mode, you want it to remain the same size & float right; and finally, on an iPhone portrait mode, you want it to be 300 pixels & display as a block. Here’s how you might go about that:

  @media screen and (min-width: 1040px) { /* For Traditional Computers */
    div { width: 800px; float: left; }
  }

  @media screen and (min-width: 810px) { /* For iPad: Portrait Mode */
    div { float: right; }
  }

  @media screen and (min-width: 320px) { /* For iPhone: Portrait mode */
    div { width: 300px; display: block; }
  }

If you looked at the page with the DIV in question in your various viewports, everything would seem to be OK. But for the sake of experimentation, on your desktop machine, resize your browser window.

You’d be in for a shock if you resized your browser window. When the browser’s wide, then the DIV is big & floats left. Shrink the window & the DIV floats right. What happens when you make the browser really small? Well, actually, it’ll still float right because you haven’t overridden the iPad portrait mode declaration. Now refresh your tiny browser window & you’ll see that the DIV now displays as a block. That’s because it’s not cascading the iPad portrait mode’s float declarations, because that condition hasn’t been met in your refresh. As Keanu Reeves would say: Whoah!

Now start resizing the window from that tiny width. You’ll notice that your floats aren’t floating, but displaying as a block; and furthermore, your box has not jumped to 1000 pixels in width, but has remained at 300 pixels. Again, it’s because you’re inheriting the display: block from the iPhone portrait mode declaration. See? Cascades now work two ways, depending upon how you resize. Double whoah! The solution here is to explicitly state in your iPad portrait mode that you want the div at 800px & also declare in each case where you want the DIV to float & how it’s to be displayed in the document flow.

Go With Percentages, Not Pixels

The other implication that I’ve only grazed above: working in pixels is a bad, bad idea. This is the reason why Marcotte exclusively refers to items in percentages: it’s a more elastic approach & won’t fall apart quite as thoroughly as pixel-based approaches. And in my experience, when I switched from pixels to percentages, the site coalesced really quickly.

Go Forth Warily

Freaky deaky responsive web design: you probably have a lot more testing to do now. And for Internet Explorer (prior to version 9, which is very good), you’ll need some help for reading media queries.

Make no mistake: responsive design is the future of web design & with the explosion of handheld devices, it’s very much worth it: no longer will you have to design multiple sites for different classes of devices. In fact, the first non-personal site, the Boston Globe, has just launched as a responsive site, and the power of this unified approach is self-evident.

Uhh, no thanks, I’ve lost my appetite.

So, who thinks that the designers were pranking the client?

There’s a great article about designing a font over at “I Love Typography” that’s worth a thorough read.

I love, love, love articles like this: they stick you directly in the mind of the author & give you practical tips for doing something similar, if you’re interested in doing so. Even if you’re not interested in designing a font, the observations that arise from the article will help hone your vision for designing anything.

Earlier this week, I promised that I’d provide some examples of our graphic development process. This is the first in the series.

Simply put, I love logo design. Even though it’s simply the development of corporate identity—and is therefore about as commercially-oriented as anything can be—there’s something actually exciting about defining someone so precisely in a graphical medium. In logo design, your aim is to get to the essence of an organisation—to idenfity not only what it is that they do, but communicate how they do it. They may sell widgets—but are they friendly? Or are they formal? Do they do or sell one thing, or many things? In your design, how specific can you—or should you—be about their work?

The answers to these questions come through a lot of conversation with your client—you’ll pick up on a lot of how they present themselves to the outside world by how they interact with you; but you’ll also need to speak with them about how they want to consciously present themselves. And in any discussion, note that the client may not be certain about how they want to present themselves. So if you’re presenting multiple designs to them, you often want to highlight different aspects to refine how they see themselves.

When we present work to our clients, we do it online, primarily to avoid scheduling conflicts, but also so that the client can think about what we’ve done in their own time. Pursuing design work in a meeting creates groupthink, which is something you want to avoid: no one is satisfied with work designed by a committee.

But as a designer, your job doesn’t end there. Few people are equipped with the vocabulary to discuss the arts. Your clients may completely bypass elements of your design that are blindingly obvious to you. So you have to walk them through your designs.

It’s also a good idea to present “Pros” & “Cons” for your designs—and to be as honest as you can about them. Why would you need, or even want, to do this? Because every design is a compromise between competing requirements. When you’re developing your work, you might think “This’ll look great on a website, but like ass on a printed page” & you’ve got to communicate this to people who, again, don’t necessarily see it. Why can’t they? Because you’ve got more experience of the print & online worlds: they don’t. They usually just type stuff into a Word document. So, ultimately, you’ve got to guide your clients, as honestly as possible, through the implications—both physical & psychological—of any design that you create.

Case Study: WindowKing

As a way of illustrating the above points, I’ve picked some logo design out of the deep archives. This is the work for a company called WindowKing, the first job we created for a favourite client that’s still with us. Back in 2001, this client wanted to create an e-commerce website to sell windows exclusively, through a new name: WindowKing. The logo would be used primarily on the web, but probably on printed invoices as well. The windows were primarily modern designs in PVC & wood, but they had a line in more expensive, sash-based windows as well, which they wanted to eventually also sell online. At the time the client’s company was fairly small, but they were very forward-thinking: they remain one of our most sophisticated & clued-up clients to this day.

I won’t go through the development of the site, as that’s beyond the scope of this post, but also because, visually speaking, everything stems from the logo design. When you’re creating a completely new entity for a client, you’ve got a clean slate to work on. Colours, fonts & stylistic approach all cascade from the logo to any other material, be it letterhead or website.

We very soon hit upon using a little crown in the logo. In addition, the company was informal in their approach, so we wanted to reflect that. But since they also wanted to sell more expensive, classic windows, we needed to create some designs that reflected this future direction. Also, if you focus too closely on cute imagery & fonts, the result can be cheap & cheeerful—which hardly reflected the client’s products.

NB: Keep in mind that these logos were designed in 2001. The colours & fonts employed are very much of a piece with the graphic design you found on the web at the time. We don’t work in a vacuum. Also, I’ll present what I wrote to the client at the time & add commentary to that afterwards. Finally, we hadn’t yet refined our design presentation, so “Pros” & “Cons” don’t make any appearance here.

Lessons Learned

So which did the client pick? Off the bat, they picked the “Thai Trade” design: no tweaking requested. In retrospect, it’s obvious why: as I mentioned, it graphically accorded equal weight to both “window” & “king”.

In terms of what we learned from this exercise, it was primarily: don’t present too many designs. First of all, it might confuse the client: with so many avenues they could choose, how do they decide where to go? Second, as I’ve tried to convey in my comments above, there are a lot of non-starters.

In addition, make the advantages & disadvantages of each design very clear to the client: hence the use of “Pros” & “Cons” in our discussions these days. We go even farther than this these days: each design is presented with a title that differentiates it from the others.

I still mourn that third design, though.

Ian may claim to be doing nothing but git-work (and what an unfortunate name that is), but the fact of the matter is that we’re both eyebrow-deep in client work. This business has been running since April 1999 & we’ve never been so busy.

When you’re so busy, the last thing you want is a series of bugs that won’t seem to go away. Since most of my work is in the HTML/CSS/Rails templates realm, I’m speaking mostly of visual bugs, things that seemingly won’t budge no matter how much work you put into them. I thought I’d share two tips which have helped me squash a considerable number of visual bugs, one created by someone else & the other merely a process that I follow.

CSS Debugging Tip 1: Burn it all to the ground

First, the work supplied by someone else: Eric Meyer’s CSS Reset. If you’re unfamiliar with it, go & read up on it ASAP. For those unfamiliar with why you’d need to reset something your CSS, the answer is simple: different browsers have different default sizes for fonts, lists, buttons & a hell of a lot else. By resetting all these items via CSS, you help ensure that all your browsers—Safari, Firefox, Opera & the thorniest of them all, Internet Explorer—start from a common vantage point.

The idea is not new. For years I’ve employed a very basic, simple reset:

  html * { margin: 0; padding: 0; }

The problem is that this didn’t reset nearly enough things—and it often didn’t even reset everything it was supposed to! Eric’s reset is a total razing to the ground of all browser-specific sizing quirks & as such should be adopted by every designer. In my experience, it’s particularly useful for a project that you’re just starting up: my IE-specific stylesheets are a fraction of their former size. For pre-existing sites, however, it’s not going to be a magic bullet. You still assembled your CSS based on different assumptions & short of starting from scratch, it will be of more limited use (although still recommended in my book).

CSS Debugging Tip 2: Build it back up brick by brick

The second tip is merely a process that I’ve been following. I’m surely not the first person to do this, but since it doesn’t appear to be widely discussed I thought I’d write it up here.

I’m going to take a real-world example from a site we’re building. In this site, we’re using some Scriptaculous effects to aid in the creation of a visually compact secondary navigation for a database of imagery. The markup is simple:

    <h4>Section Heading</h4>
    <a href="subsection/1">Subsection 1</a>
    <a href="subsection/2">Subsection 2</a>
    ...

Clicking on the H4 tag will cause the subnavigation links to reveal themselves, or hide themselves if they’re already revealed.

Unless you’re viewing in Internet Explorer 7, that is—no, the problem for once isn’t IE6! In IE7, the links were invisible—they were clickable, but you couldn’t see them.

I tore out what little hair I had left, for weeks, trying to figure out this bug. I even thought it might have been Scriptaculous’ fault. It wasn’t, however & eventually I realised I was compounding the problem by adding CSS declarations instead of removing them—instead of trying to figure out what was triggering the bug, I was trying to pave over the bug. If you’re adding more declarations in order to fix a bug, you may very well be creating a shifting target, which is definitely not what you want to be doing. Particularly when you have a lot of other work to do.

The answer is simply a process & a very simple one at that: take your CSS declarations & strip them out. Add them incrementally, viewing in the target browser every time, until you trigger the bug.

In the example above, removing a declaration of a:link { display: block; } rendered the links visible again in IE7. I don’t know why—I’ve used this declaration countless times with no problems—but nevertheless the declaration wasn’t necessary & it was causing a big problem.

Again, though, it’s the process of stripping away your CSS & then re-implementing your declarations which is the key. It’s all too easy to add more & more to your declarations, but remember: you may only be making the job of fixing your problems worse.