Worlds Colliding

fyeahscottpilgrim:

clownetowne:

this is the shot where young neil is reading achewood isn�t it
did you guys know young neil is my ideal man

Remember when Caitlin figured out which strip he was reading
Good times

Oh shit oh shit oh shit oh shit wo…

fireland:

I was thinking today about the video for Just Like Heaven and how the drummer had this upside-down cymbal that made a very short crashy sound and I decided every drummer should have a short crashy cymbal because c�mon cymbals last way too …

Rob Baedeker: Personality Test

Rob Baedeker: Personality Test: robbaedeker:

Choose the answer that best describes you.

1. I work best
a) on my own
b) in a group
c) in the sauna
d) after smoking a little bit of pot
2. When faced with a decision, I am most likely to:
a) weig…

Because I like doing lists.

Start writing real blog post (none of this Tumblr shit)
Ooh, I should totally use a featured image.
Head off to Flickr to find an image I’ve taken that I can use.
There is no New York photoset. How do I not have a New York photoset?
Create New York p…

I don't even know what to call something like this.

Finish CSS issue X.
Rethink how the entire bit X is a part of works.
Change the entire bit X is a part of.
Introduce new display issue Y separate from issue X.
Dig through framework from top-down in order to figure out issue Y.
This takes a while, like…

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.