Should web designers know how to code?

I have asked and have been asked this question numerous times over my career. I have very good friends who disagree with me completely on my opinion, and I’m on the cusp of teaching a web design class to unsuspecting, pliable minds and I need to decide – soon – what exactly I’m going to teach them and how. This blog post is my way of working it out for myself. I hope you find it helpful.

When I was in school, I held a digital printing job. This means that it wasn’t traditional offset printing, but more like your typical Kinko’s, quick-print type place. I learned a lot about what you could and couldn’t do to get the highest quality print for your client. You can’t design to the edges. You have to leave enough room around the fold. You have to take into account color shifts. You have to embed your fonts correctly. When I lost this job and found myself without work for a few months between Halloween 1998 and January of 1999 (when I got my first web design job), I did something that felt natural to me, and it turned out to be something I would do every time I found myself without work: I learned something new. Something technical. I taught myself HTML (ok, GoLive CyberStudio helped).

Graphic design has always contained a technical component. There have always been tools that designers use to put their ideas together. For the old timers, these tools included Letraset, Rapidographs, offset printing, choosing the right kind of paper, worrying about dot gain (and many other things I’m unqualified to even list out). For print designers today, these tools have moved to the computer, but knowledge of the output is always required when creating something. Is it a magazine ad? A stand-alone print piece? A newspaper ad? All of these media have different constraints and strengths. Knowing these strengths and constraints isn’t a luxury, it’s not an extra thing, it’s a requirement. You can’t do your job without knowing them.

As a young student who was interested in web design, the language of the web was a natural progression for me to learn. If I wanted to design for the web, it just simply made sense for me to learn HTML. I never wanted to be a web developer, I wanted to be a web designer. Maybe I was just a misguided student, but learning HTML didn’t seem like an extra thing, or a luxury, it felt like a requirement.

I think I still feel like it is today.

Your first instinctual reaction (as mine would be), is of course going to be that learning HTML is not learning web design. And of course – of course – that’s true. Just because you know Flash or HTML does not mean you’re a designer. I would never be brain-dead enough to suggest such a thing. The visual and strategic aspects of design are always more important than the technical ones – it’s just that the technical skills should exist alongside all of that to effectively uphold your decisions. This has been true of design as a discipline for decades.

But if you’re a web designer, think about it. Think about who you admire most. Dan Cederholm? Neven MrganJason Santa Maria? Jason Fried? Shaun Inman? Jeffrey Zeldman? These people all know code, even if they don’t do it on a daily basis. They all understand the importance of designers understanding what it is that makes their designs real. I’ve never been comfortable with what I create being dependent on someone else to become fully-realized. I’ve never been comfortable spending my time dreaming in design-land where my ideas are the only important thing, and making them work in the real world is the least of my worries. That feels irresponsible and arrogant to me.

My friends who disagree with me say at this point that if they’re spending time worrying about the implementation, then they’re not spending time worrying about solving the problem. Which again, I just don’t understand. You can spend all the time in the world on wireframing to get the right flow down. You can spend a million hours pushing pixels in Photoshop to get the client happy and to get sign off. But when that’s where design work ends and where development begins, I have always found that the end-result is unimpressive and not exactly what I had in mind. Just because a Photoshop file exists somewhere in the ether of your hard drive doesn’t mean that the real thing – the thing your users are going to use – is just as perfect. If you leave that translation up to someone else, almost 100% of the time, it’s not going to be nearly as perfect as your precious PSD. And then your work has been for what?

The next step in the conversation usually requires me to say this: No, you shouldn’t have to code everything all the time. Maybe you don’t need to learn PHP or Objective-C or Ruby on Rails or SQL or anything that runs on a server or gets compiled. Although I can tell you that I do know these things, and even when I don’t write them for what I’m working on, I always make use of that knowledge when designing to make use of them. Overlapping skills on a team is obviously a positive thing. You don’t have to write all of the code for your web project to be able to leverage that knowledge to your advantage. How can more knowledge about your field be a bad thing?

Maybe it’s just me. Maybe I’m weird for enjoying the coding of my interfaces. Maybe I’m a freak for starting my work by writing HTML and doing an amalgam of Photoshop, PHP, HTML, CSS and Javascript – all at the same time – to get my work to a place I want it to be. I’m lucky enough to work on products that I’ve been able to define as I see fit. But I do know that every single position I’ve ever been hired for was easier to get because I could code – and I have never once held a job that defined my role as “developer.” The job that inarguably launched my career was a lowly Production Artist job at Spiremedia in late 1999. I wasn’t even a designer there yet, and I didn’t care. I quickly rose the ranks, but never stopped coding my own work for long and learned that iterating a design with code is an order of magnitude faster (and hell, more fun) than iterating with layers in Photoshop.

How can you know that fancy interaction design you’ve storyboarded in Illustrator is the right one and feels right to use unless you create an interactive prototype to test it out? Why wait for someone else to do it for you? Why not just learn how to do it yourself? Because it’s hard? Because it doesn’t feel like doing design? Because you just don’t feel like learning how?

Those all feel like flimsy arguments to me, and they feel like a willful ignorance to the medium of the 21st century. Web designers should know how to code, even if they don’t do it all the time, because not intimately understanding the medium in which you work makes your job harder and slower. Designers have always had to have technical skills to get their jobs done, and in my mind, at least HTML, CSS and Javascript should be considered part of every web designer’s toolbox in the 21st century.

The Infauxgraphic Epidemic

As has been pointed out frequently lately, there’s a strong groundswell of designers taking it upon themselves to create data visualizations that at first blush appear to be legitimate but upon further review simply reveal nothing more than the designer’s desire to impress you with their ability to create splashy graphics that include data in some way.

Graphic Design vs. Information Design

I recently spoke up on a lengthy Flickr comment thread on an image posted by another designer who is fed up with the noise being produced in the name of infographics, and it’s on this thread that I posited the term “infauxgraphics” to describe the latest spate of work that purports to display data in a meaningful way but eschews the key points of data visualization.

In this thread, a popular opinion by another commenter was expressed that it’s the mingling and conflation of graphic design and information design that’s to blame here. I took offense to this idea that graphic designers are to blame and spent much too long on writing a Flickr comment to explain that frustration. My full comment is excerpted here:

[I’d argue] that it’s a confused generation of designers who believe that graphic design is just the pursuit of beauty that’s the problem. One of art’s pursuits is beauty, but design in any form should always be primarily about solving a communication problem. If the communication method is beautiful, then all the better.

Designers who think all they need to do is make something easy to look at are designers who miss the mark in understanding that design is about making something understandable, and this translates to graphic design, user interface design and information design.

Anyone, designer or otherwise, who wades into information design without knowing the ground rules and when to break them is embarking on a failed expedition, to mix my metaphors a bit.

Graphic design has never been, and never will be about “making things beautiful.” If you believe that, then you have much to learn. The person who made the iPad graphic suffered from a misguided mindset that they can copy the look of something, and recreate its impact.

The popularity of so many useless infographics – the ones lampooned in this Flickr post – is indicative of just how many people feel design is simply the art of making something beautiful.

This is some basic, first-semester design school stuff. The key difference in my mind between graphic design and information design is simply the existence of a data-set that needs to be represented. All of the other tenets of graphic design apply equally to information design. The use of negative space, the use of visual hierarchy, the necessity of choosing the correct color combinations and not least of all, selecting which items to leave out – these are all just as important in information design as they are in graphic design. Visualizing data effectively requires a superset of design skills to be sure, and the best visualizations out there probably also included an entirely separate person acting as a statistician, but that isn’t to say that just because you’re a graphic or interaction designer, you can’t learn information design. Of course you can, you just need to pay attention to what information design really requires of you and not forget the skills you already know. Recognize that just making it pretty isn’t doing your job as a designer to dig deeper into the meaning of the data.

Fetishizing Data Visualization

One of the first problems with designers creating infographics is that a lot of us have started to fetishize data visualization on the whole. We read blogs dedicated to the subject and our pulses increase whenever we see something that contains a lot of criss-crossing lines and circles and (even better) large numbers next to small labels. There’s a visceral reaction here and it is extremely difficult to spend time critiquing something that affects us this way. But critique we must, because there’s a good chance the person who drew this wonderful-looking visualization either willfully ignored  – or was blissfully ignorant of – some really solid ground rules when they embarked on their journey of creating the graphic you’re sitting there salivating over.

Beauty is Not Skin Deep

The main dig against the latest round of infauxgraphics is that they make heavy use of  big numbers with tiny labels below them. I blame Nick Felton for the proliferation of this (well, ok, not him personally, but people copying his style). I have to admit, I love this treatment and I’ve used it in a lot of places to great effect. But when you’re putting together an all-encompassing piece, make damn sure your giant type treatments aren’t just doing the work of a simple data table while masquerading as more. This is not information design, this is typesetting.

Custom Visualization or Standard Chart?

After having worked in financial information design, I can say first-hand how attractive the idea of creating a completely custom data visualization is over using a “standard,” tried and true chart. The reality however is that standard charts come with a set of well-worn rules and best practices that can help install the constraints you need to create a truly captivating and useful infographic. Diving deeply into each of them is beyond the scope of this meager blog post, but an incomplete list includes bar charts, line charts, histograms, scatterplots (oh man, I love me some scatterplots), box plots, pie charts (ONLY for comparing parts of a whole, and generally a waste of space… we’ll talk about pie charts in a minute). I’m sure I’ve forgotten some, but you get the point.

The main idea here is to study these and their best practices, chances are you can use one right off the bat, or can modify one to meet your needs fairly easily. Unless you have data that requires a completely new way of thinking about things (or you’re Ben Fry or Golan Levin), you’re gonna be able to find a visualization that’s reaaally close to fitting your data set.

Look at the silly pie chart to the right. This made the rounds a few days ago, primarily because it’s the first set of iPad and iPad app data to become available, and it was visualized in a way that on the surface didn’t look half bad. But the designer took extreme liberty with this pie chart, because you are intended to view the entire circle as the median iPad app purchase price ($4.99) and compare the median iPhone app purchase price ($1.99) to the whole circle. Comparing the size of two values is a bar chart’s job, not a pie chart’s, and these two values in no way, shape or form add up to a whole or 100% of something.

Seriously, stay the fuck away from pie charts. And for the love of god, if you have to use one, use only one. I’m guilty of this very transgression and I’m in the process of switching all my pie charts to something else because pie charts are really, really, really useless, almost all of the time. The main things people like about pie charts are:

  1. They are circles, and everyone loves a circle. Circular things look like important things. This is not enough of a reason to use one.
  2. They can contain artfully segmented pieces inside of them, and designers like to break things up into segments. This is a valuable skill, but it’s being misused when it’s a pie chart.
  3. We like to shove too many things into a pie chart. If you have more than about 5 slices, use something else. If the things in the pie chart are not part of a whole that equal 100%, do not use a pie chart.
  4. We like the look of a lot of pie charts on one page together, but one pie chart is completely incomparable to another one. Humans just can’t perceive the differences between circles, whether they’re sized differently or include differently segmented pies, we simply can’t detect the differences between similar items very well. Bars work so much better.

So, yeah.

I’m not really sure how to conclude this other than to recap that just because you’re a graphic or interaction designer doesn’t mean you can’t also be an information designer, it’s just that you shouldn’t fetishize the data visualization. Learn the ropes first, because the good things about good visualization can’t be copied at a superficial level just because you think they look neat, there needs to be a purpose behind every decision you make, just like when you’re doing your other design work. Don’t throw out your graphic design expertise either though, as it’s important to create something people want to actually look at. Just make sure you’re not making something with the primary goal of making people impressed with your skills. Those things fail when put under the microscope of having to understand what the data is trying to say.

A decade of blogging

On March 18, 2010, this blog will be 10 years old. I haven’t been the best blogger, and I haven’t written this site alone, but over the years, it’s always been a place I wouldn’t feel right about not having on the web. This graphic is a testament to all the work I’ve put in with various people to keep things going. Here’s to 10 more years.

Some images weren’t available in the Wayback Machine, so that’s why there are a few broken images in there. View full size on Flickr.

Gmail Prototype

UPDATE – Macromedia’s Developer Edition of the Flex Server has apparently expired on my iBook, for the link below isn’t exactly, well, working. I’ll compile it here on our real version at work and re-upload it.

You wanted it, you got it: A compiled version of my SXSW presentation. By “compiled,” I mean that it’s not actually drawing in live data and images the way an MXML file would, but it gets the point across. You can step through it the way I did on the panel:

1) Select the conversation with “Tai Kahn, Me” by clicking on that row. Click “View Conversation.”

2) When viewing the conversation, click the “Show Quoted Text” link under the text to see the text I’d sent Tai that he automatically quoted. Click the button again to see it hide.

3) Click on “Browse By Picture” under the “Contacts” panel to see a list of all of my contacts in photo form. Use the slider at the bottom of the picture pane to resize the images in an iPhoto-ish way. Mouse-over the photos to see them fade in and get a Tooltip showing each contact’s name.

4) Drag Tai’s picture from the conversation into the Photo pane and watch him get added to the contacts list. Click on “Browse By Name” and see that his name has been added to the list.

5) All attachments would automatically get added to an Attachments panel below the Contacts Panel. Use the slide to get the same zoomy effect as the contacts images.

6) Drag the star icon from the top menu bar and drop it anywhere onto the conversation. Watch how the conversation gets “starred.” Click the star that shows up in the right-hand corner of the conversation to un-star it.

7) Click the “New Mail” icon in the menu bar and get taken to the new mail screen. In the Browse By Name pane of the Contacts panel, select all of the contacts (including Tai) and drag and drop them onto the recipients input box.

8) Notice that I’m using a ComboBox for the search so that searches can be saved, easily recalled and edited and re-searched. In a real version of this, both this input control as well as the Recipients control could auto-complete as you type.

A FEW THINGS TO NOTE:
1) This is in no way, shape or form condoned by Google. I have zero permission from them to show this, nor is it endorsed by them in any way.

2) IT’S A PROTOTYPE! Yes, there are bugs, and yes, it could have been architected better. I wanted to show some of the things Flash could do to enhance Gmail from a user’s perspective. I didn’t spend an awful lot of time to re-architect Gmail. I had some ideas, I typed them out, bada-bing. This is not meant as any kind of proof-of-concept or “Flash is TOTALLY better than HTML man, OMG LOLOL.” I was asked to do a presentation for SXSW and so I did. If you follow the instructions above, you’ll get exactly what I showed the attendants of our panel. If you click around, I can’t guarantee your experience, as this is hardly complete.

3) For those who care: Yes, this is a Flex application. No, you are not seeing the MXML file being rendered live by the Flex server. This is a compiled SWF file that contains all of the necessary elements in order to VIEW it, not in order to CHANGE it. I cannot edit the CSS that styles this screen, nor the XML that supplies data to it on this server and have it change. I’d install the Flex developer server on this machine but seriously, I don’t have the 100mb of free space required.

So. There you go. Let me know what you think.

SXSW Trip Log

SXSW was a total blast. Austin’s fun and the sheer number of choices on things to do outside the conference are staggering. Check out Flickr photos tagged as SXSW 2005, the few I have are here. Here’s a rundown of what I’ve done so far:

Friday Evening: Arrive in Austin. Jane and I share a cab with someone whose panel is to interview Bram Cohen, the inventor of BitTorrent. Meet Jason Fried for the first time in person on our way out to dinner.

Friday Night: Head out with Jane for thai food and then on to Tantek’s birthday party. You may have heard of Tantek, he wrote the Mac IE 5 rendering engine. Not that I have any love for that engine these days, but in its time, a great browser. See Ze Frank on the street outside. Afterwards, we walk over to Break Bread with Brad. Watch how the entire open-air back part of the bar goes nearly silent as Malcolm Gladwell walks in.

Saturday Morning: Oversleep and wake up with a hangover and bad stomach issues. Shouldn’t have had only beer the night before. Wander around looking for Pepto-Bismol. Find it and register for my badge. Mine happens to take forever.

Saturday Afternoon: Jason Fried shows up to get his badge and we all head out to lunch. After lunch, I walk back to the hotel and start to finish my panel project. Start to hear that the other team has done some great stuff, so I put more effort into my interface in order to make it as badass as I can. Meet Chris Wetherell who works at Google, and Dunstan Orchard, both of whom are on the other team. Boo!

Saturday Evening: Meet with my team for the first time in the Green Room. Jaxon’s looking as metro-sexual as ever, and Vera’s pleasant. We all look over our projects and start to think we might actually win this thing.

Saturday Night: Go to Milkshake Media’s party with Jaxon, Jane, Chris and others. After a few free drinks and Cheetos, we go to frogdesign’s party. I get shit on by one of the awful fucking birds here and make my way to the bar. Nice exotic-ish dancers all around and a salsa band playing. Ridiculously packed, and I exit many times just to keep a lid on the claustrophobia starting to well up inside me. After that we walk a few blocks to a super cool bar and I proceed to drink myself silly. I may have a Flickr album up of all the people Jane hugs at this party.

Sunday Morning: Wake up with suprisingly not much of a hangover. Yay for top-shelf alcohol. Decide to go see the BitTorrent guy’s interview, because I’m interested in what he has to say about the future of content distribution and copyright. Unfortunately, he’s not interested in these things and quite an awkward nerd, so I don’t stay long.

Sunday Afternoon: Have mediocre tex-mex with Jane, Jaxon, Jason, Eris and Chris. Discuss the death of the browser. Go back to the hotel and work on my presentation for another solid 5 hours. Meet Jay Allen of Six Apart (makers of Movable Type) outside the hotel.

Sunday Night: Go to the Hotel Sane Jose with Lane, Danah, Jane, another Kevin and Jeff Veen. Find out that Kevin is an attorney for theEFF, defending PowerPage and AppleInsider from Apple’s litigation. I figure out the meaning behind his supposedly non-sensical “storm trooper from starwars drawn as Che Guevara” shirt and earn some street cred. Find yet another mediocre-to-not-so-bad mexican restaurant and discuss the Apple case some more. Smoke way too many cigarettes for my own good, grab some ice cream and go to bed after meeting Halcyon, Doug Bowman and Anil Dash.

Monday Morning: Barely sleep, I’m so nervous about my presentation later in the afternoon and grab my first regular-schedule breakfast: a soda and a cigarette. Attend “Does design matter?,” a panel with Jeff Zeldman, Jason Santa Maria and others. Interesting, yet I can’t help but think to myself “How could design NOT matter?” Once that’s done, I attend “How to Inform Design” with Jeff Veen and others, and learn about the value of up-front user-research. Try and think of ways to include that in my company’s process. The wheels are starting to turn.

Monday Afternoon: Go to lunch with Jason Swihart for barbeque and find it terribly disappointing. Must find a better BBQ place while my short stay in Texas lasts. Try and ignore the butterflies flying around in my stomach and gather up my gear and head over to the Green Room, as Wonkette is using our panel’s room as overflow from her main-stage keynote. Wish I could hear her being interviewed, but I have too much to work on, and I just learn that the projector display we’ll be using is 800×600, and my application is designed at 900px wide. Fucking great. Fret and worry and edit code 45 minutes before my presentation to accomodate the lower-than-expected resolution. Head into the room to get set up and find that we actually can use 1024. Edit code up until 5 minutes before my presentation to get it back to 900px wide. Everything is kosher. The panel starts and all of a sudden I’m totally at ease and proceed to knock my presentation out of the park, despite our formidable opponents. Jane uses my Flash-based Applause-O-Meter to measure audience reaction to each set of presentations. HTML team wins, but only beacuse Chris Wetherell is fucking JavaScript badass. I guess he’s got to be good if Google hired him to do it, eh? Get props from Jeffrey Zeldman and notice that the people whose panels I’d wanted to see actually attend mine, which blows me away. I imagine I see Jason Kottke at our panel, but he might be in there for the next one. Try and decide if I should introduce myself but I feel like too much of a nerd to do so. Rush into the HomestarRunner presentation and laugh my ass off for the next hour. When It’s done, I head to the front to introduce myself, as my picture is directly next to Mike Chapman’s in the SXSW program booklet. He signs it like a yearbook (“Raise hell this summer!!!”) and asks me what I do. I tell him and he responds that I’m smarter than him, I reply that he’s funnier than me so it all works out. A relatively complete transcript of the panel.

Monday Evening: Go to 20×2, a show where 20 people talk for 2 minutes each about a concept. This year the concept is “What’s the word?” and Jaxon is fucking hilarious during his diatribe about grief.

Monday Night: Go to grab thai food (again) and then go to the Blogger party, which we actually miss, and find that we’re now going to the Gawker party. Drink many drinks, smoke many cigarettes and actually feel noticed and recognized by people who I don’t know. Discuss CSS vs tables with Jaxon and Chris. Find that Chris’s band, Dealership, has played with the Arcade Fire in San Francisco and that the artist who did The Shins’ album did Dealership’s artwork as well. I wish I was a rockstar.

Tuesday Morning: Wake up and rush down to Eris’ presentation on what the web might look like in 10 years. Find it’s more of a discussion than a presentation. I was hoping for bright-green spinning cubes or something and get boring talk about CSS and thin clients. Yawn. Start to write this post and decide to go get lunch.

Tuesday Afternoon: After trying to figure out how to get the hotel to charge my employer’s credit card instead of mine, I go to lunch with Jaxon and Jane and have cajun food, after which I head back to the hotel to get the billing issue further figured out.

Tuesday Night:Take a nap and when I wake up, meet Jaxon at the Red Vs. Blue panel, which we then find out actually occurred two days prior. Awesome. We head back to the hotel bar and discuss XHTML/CSS vs tables some more. We then go and grab pizza from a walk-up, hop in a cab and go to the Wired party at the American Legion. Wander around wondering what the fuck is up with this place, use my one drink ticket to get a Stoli and cranberry (bad idea), and fuck around with the tinker toys in the “fun” room upstairs. Decide that I’m feeling really sick and jump in an arriving cab back to the hotel and call it an early night.

Wedneday Morning: Wake up around 9am and find that Jane is still not in the room. Must’ve been a long night for her. Walk down to the hotel restaurant and have a filling, relaxing breakfast and read the paper. Get a call from Jane that she’s at the convention center and that my old boss is here, and that he’s moving to Mexico soon so I could see him here before he leaves. Go to the center, talk for a bit, type up the rest of this post, and go get my shit together to leave.