t-minus

In April of 2003, UPS released what has since become a very hotly debated brand update. Summarily, UPS retired Paul Rand’s iconic 1961 package-and-shield logo and replaced it with “a two-tone, 3-D-look shield topped with a quasi-swoosh [and a wordmark] set in a customized version of [the common logo font] FF Dax…” (Source*)

* As evidence of how positively engaging this identity redesign was, the discussion on this article received its first comment April 7, 2003 and got its last one on November 9, 2007!

The great UPS logo debacle of 2003

The responses to this re-branding varied from declaiming FutureBrand, the New York-based designers of the new logo as glorified Paul Gaskills to flat-out declamation that “the new logo is better,” and subsequently that, “you typography/graphic/illustrator bullies need to relax.” (Ibid).

A couple of more gems from this really swell discussion, for your consideration:

The old one was stale, but it reminds us of a time when quirkiness and personality were still allowed into the world of commerce. The new one expresses absolutely nothing, and quite well. It’s the perfect emblem of this age.

The old one always reminded me of a face, and the package was like a hat with a little bow in front. It said “straitlaced efficient guys in uniforms delivering stuff.” The new one reminds me of a kid with the haircut I had in my skateboarding days. Coupled with the brass-badge look, it gives off a strange mix of incompetence and official self-importance.

However, for my money, the situation was best summed up preemptively (you heard me) by Susan Kare, most widely known as the designer of the Windows 3.0 iconography as well as for the infamous “smiling Mac” and MacPaint icons. In a 1999 issue of Fast Company magazine, she opines, “[a]t one point, some years ago, it seemed as if all the logos that had any personality - such as the winged horse of Mobil gas stations - were being replaced by death-star shapes that supposedly looked high-tech. UPS didn’t need to make that kind of update.”

Well it turned out some three and a half years later that they made it, rendering the question of whether they needed it or not immaterial.

Signal to Noise

Or so it would seem. As it turns out, UPS has provided the design culture with a rallying point against what I believe have become endemic behaviors on both sides of the design equation: Both designers and their corporate benefactors, when charged with the identity (re-)development process, too often take the “safe” road, phoning-in the de facto message-less identity (see above) instead of taking the opportunity to do some mental unpacking and come up with a better solution. What we lose in this situation is what Paul Rand stood for, the human parts of the design. What we get instead is assembly-line brands - brands with a very low risk of catastrophic failure, but also with an equally infinitesimal possibility of “standing out from the crowd”.

I believe this phenomenon to have flatly negative consequences for corporations, and I’m going to evidence that belief [quickly] with an appeal to information theory, and specifically with an appeal to the information theory formulation of the concept of redundancy.

Redundancy in information theory is the number of bits used to transmit a message minus the number of bits of actual information in the message. Informally, it is the amount of wasted “space” used to transmit certain data.

Gradients, lens flares, faux-3D elements, and overused fonts can, as a result of their relative overabundance in our design ecosystem, officially be classified as noise. This means that about 90% of the new UPS logo is “wasted space.” Whereas, with the Rand logo (and in this way, like much of his identity work), it’s all signal, baby.

December is gift-giving time, and if you’re not very organized indeed, late November/early December threatens to be characterized not by a pleasant anticipation of quality-time-to-come and a much-needed respite from work and research, but instead by a certain existential dread, or at least a rather more ontic version, most often directed at visions of the mall parking lot.

Being the vigilant (and vigilante) designers we are, Go flight! organized in November under the auspices of creating some generative art for the holidays. We especially liked Jer Thorp’s idea of using letterforms as elements in a snowflake, but we wanted to personalize the results. In what even now we have to admit was a brilliant intuitive leap, we thought, “why not use the names of our loved ones? Then we can give them to our loved ones instead of going to the mall.”

Once we knew we were making these as gifts, we decided we would digitally fabricate ornaments from our designs. This threw a structural requirement on top of the aesthetic one, but, remembering the mall, we plunged bravely forward.

A detail from a generated snowflake.

Check it out for yourself or continue reading for…

Some ideas for your snowflake

So you’ve typed the names of your family, friends, co-workers, favorite baseball team, or whoever else into the snowflake generator, at which point you immediately realized that an email probably doesn’t constitute a gift in the traditional sense, and you’re ready to take it to the next level. Here’s some ideas we had to help you with that:

Images (Really easy)

Take a screen capture (Shift, PrtScn) and paste the image into your favorite program. Some suggestions:

• Make Christmas cards.
• Make a “family tree” with snowflakes for everyone in your extended family. Print it out and bring it to decorate your holiday party.

Masks/Vectors (Still pretty easy)

You can use the mask mode (press 3 on your keyboard) to output silhouette of the snowflake. This is useful for making masks or stamps/brushes in photo editing software like Photoshop.

We made a Christmas card!

It is also possible to use the Paths > Work Path tool in Photoshop to take the edges of the snowflake and turn them into a vector version.

This works, but if you need a more precise solution:

1. Download the code and run it in Processing.
2. Flip the PDF booleans on line 33 and 34 to “true”. The program will now output PDFs in the code directory.
3. Then, when you open the PDF in Illustrator, everything will come in as vectors.
4. From here, you can scale it to any size you like and the lines will still be crisp.
5. Now you can print your snowflakes on everything from gift tags all the way up to banners!

Export to other Formats (Difficulty varies from “Unbelievably, still pretty easy” to “Claes Oldenburg”)

There are all kinds of things you can do besides print out an image of your snowflake.

You can:

• make a 3d model or an animation
• a stencil for painting
• a fabric pattern
• cut out stickers using a vinyl cutter, or…
• (our favorite) make an ornament with a laser cutter

For these kinds of projects, you will probably need to generate shapes in different file formats. Luckily, the process is fairly straightforward.

We took a DXF export and used a
laser cutter to make this acrylic ornament.

1. Start with a PDF of your design. Open it in Illustrator.
2. Select everything and choose Type > Create Outlines. If you want the keep the separate letters, skip to step 6. Otherwise, to make a solid cutout, continue on.
3. Pick the snowflake, select Object > Ungroup, and delete the white border/frame around the snowflake.
4. Now, if you are sure all you have left are the letterforms, select them all, go to the Pathfinder window and apply Add to Shape Area (Boolean Add).
5. Next, click Expand in the Pathfinder. Your snowflake should be one connected solid now.
6. At this point, the next step is up to you. You can export your newly-solid shape to common formats like DWG or DXF using File > Export. From here you should be able to open it in the program you need.

Words of thanks and our pink Christmas tree

This project was inspired by some other winter-themed works we’ve come across over the years. First, by MIT’s Snowflake-a-Thon from 2005, and, second, by Jer Thorp’s aforementioned typeflakes project from 2006. As neither of them published the source code, we wanted to make it a point that the 2007 update to this geek/designer tradition would do just that.

So, from us to you: The Go flight! Snowflake Generator (source code included, pink Christmas tree sold separately).

Happy Holidays from the Go flight! team: Paul, Jon, and Nick.

Thibaut Sailly does not like the Amazon Kindle. Not the whole ebook-DRM thing (which is also broken), but the form factor itself. For example:

(Note:Edited a few words– his English is not perfect.)
“I don’t have anything against asymmetrical designs… the volume itself is ok to me. But having symmetric elements (the keyboard and the screen) that give the most visual weight to an un-centered (left aligned) element in an asymmetric shape can only result as a mess. If you choose asymmetry, stick with it. For example, don’t make a symmetric keyboard when you can do an asymmetric one. But first, don’t choose it when the purpose of the object is to display a book page that looks like it has a center line (apparently they acknowledged this fact by placing the logo centered under the screen).”

I’m inclined to agree with the guy, not only because of the clear arguments he makes with his visuals, but also because he follows a posting about the gorgeous video game Bioshock with a video about Paul Rand (“hero” tag, indeed!).

Personally, I wonder if Amazon isn’t possibly “pulling a Gameboy” here, wherein they lead with a subpar, feature-crippled design only to follow it with the design they should of come up with in the first place (i.e. Gameboy Advance to Advance SP; Gameboy DS to DS Lite).

Old Skool “Phatty” DS vs. the DS Lite

Regular folks will buy some of each, but the fanboys will buy both versions. Question is, does the Kindle already have fanboys? Suprisingly, perhaps it does.

About six months ago, Adobe launched its CS3 line of design software, the first revisions of its products since the company acquired their primary competitor, Macromedia. Inevitably, new versions mean new branding. (I mean, how else is someone going to know it’s new, right?) So what did they do that is worth blogging about?

Imagine Adobe’s task for CS3. They already have dozens of products, all centered around design. They merge with the next biggest guy in the game, which adds even more products. Macromedia’s brands have strong identities and associations of their own, and, at the time of the merger, these are more unified than Adobe’s. How does Adobe successfully assimilate these new brands?

This raises a valid question, what were Adobe’s brands, up to this point? I bet you have a hard time remembering. I don’t think they did a good job of developing or managing them. It’s difficult to remember because it wasn’t clear what their brands were supposed to represent. Moreover, each product’s brand or logo was so different from one another. It was difficult to get a sense of what was “Adobe” about them.

When the switch to Creative Suite came, Adobe’s brands became somewhat more consistent, but it was still challenging to associate them with their products. Photoshop had an eye motif for a long time—then suddenly it became a feather or a quill or something. Illustrator’s branding was, what, Botticelli? And then for some reason, it became a flower. What do any of those symbols say about the product? Why do they keep changing so much? It appears Adobe did have a strategy, but I doubt people understood what they had in mind.

The first rule of branding is consistency; Adobe violated that rule. They showed a lack of consistency across their entire software line and within the individual brands themselves. Which brings me to the big reveal: Adobe’s new branding strategy.

As you can see, Adobe went from artistic renderings of nature to a reductionist wordmark; consistent from piece to piece. Their product line becomes a wheel—a color wheel. People are split across the noosphere on whether they like it, but I have to say that I approve.

It’s just so logical. It’s a Pantone chicklet and an abbreviation of the program name—about as minimal and informative as one can get in 16 x 16 pixels. To me, it says something about the utility of the programs for design. It says “paint” or perhaps “pixels”—elements of composition, but not compositions themselves. I get it now. Adobe literally means building blocks.

And it’s usable, too. Before, it was sometimes difficult for me to identify which Adobe program I was clicking in my taskbar, but these new icons aren’t confusing to me at all.

What they’ve done is created a system – an algorithm, one might say—for branding their products. It doesn’t get much more consistent than an algorithm. Yes, it’s not fancy or expressive, but it is understandable to people. Most of all, it is extensible. Apply it to anything and it becomes Adobe. That’s the genius.

And, folks, that is a brand.

Figuring out what a client really wants can be tricky business. Perhaps you see glaring problems, like voluminous corp-speak all over their site for children, and you may be tempted to focus on those. However, this client came to you to solve a particular set of problems and what’s most important to them may not be completely obvious to you. Nevertheless, it’s your job to get to the bottom of these needs, so you can be sure of sweet success. But how to do this?

The W

As with journalism, you need to narrow down the who, what, when, where, and why of a project. Who are your main contacts? What are the details of the project (the scope)? When will it start and finish? What physical or virtual space will it occupy? Why is the project being done in the first place? What problems does it solve? Asking a client to write out the answers to these questions can be a clarifying moment for everyone. Maybe the project is ridiculously simple, or more likely, quite a bit deeper than initially described. Maybe 15 people have to signoff at every stage, which could be a sign of lack of focus on the client side. It’s always better to know this stuff in advance, so just ask.

The Most Repeated

As you communicate with your client, you’ll likely notice they keep returning to certain themes. Addressing these themes directly, even if it isn’t exactly what the client envisioned when they first mentioned it, will make them feel like they are an active part of the process and show that you are really listening to them. If you are asking yourself, “Why do they always bring up X?” that’s the thing you should pay attention to.

Ignore recurring themes at your own peril, because no matter how much you sell them on your (obviously better) alternative, these issues will continue to resurface and they will have to be addressed somehow. The gaps between these recurring themes and your actual solution are often the largest source of disappointment for a client, even if your solution can bake brownies and cupcakes at the same time. As in, “Yeah, it does bake brownies and cupcakes at the same time, but all I ever wanted was crispy bacon.”

The Written Execution

Many times, changes get agreed to in ad hoc meetings and it can get confusing to track who said what, why they wanted it, and whether it was officially approved. After one of these sessions you need to send a follow up email to the client that says, “This is what we understand you are asking for, please give us the go-ahead and we will make these changes.”

This is good for two reasons. First, it gives you a verifiable paper trail to refer back to, so you know when each change was introduced, who introduced it, and why they introduced it.

Second, it gives you and the client a chance to consider these changes one final time before execution. Sometimes meetings spin off course and a certain aspect of the project gets far more attention than it deserves. In hindsight, the neon vampire logo might not make as much sense as it did in the heat of the moment. Give your client one more opportunity to vet these changes after a minute of reflection.

Take pause and appreciate with me a moment of enormous visual power, created “accidentally-by-design” in the convergence of flickr and lunch-in-a-box.

Further proof that a simple framework can yield astonishing visual results, and of course that the world wouldn’t start wobbling on its axis if we spent less time on kickin’ web graphics and more time designing our plates…

The always-sensible Jeremy Miller drew my attention to this discussion today. He highlights this point, from Ron Jeffries:

I think “requirements” always means approximately “what we think, right now, that we need”.

Limited Ink

To borrow a phrase from Nick, Gak!

This kind of talk actually changes the physical constants of the universe, significantly decreasing the inertial force of the agile development agenda adoption rate. You can just hear the seismic rumblings of indignation from space shuttle OS architects and the other remaining core demographics for the Big Design Upfront community.

If you catch it in just the right light though, on just the right time of day, you can see Ron’s point: No requirements are final. Next year, or ten years from now, we’re going to need a better boat. No doubt.

Under sub-optimal reading circumstances, on the other hand, this completely misses the point. Especially in a world of progressively more and more application infrastructure that seems to support an iterative approach. So, as we take an iterative design model more for granted every day (I was talking to someone who surprised me by referring to it as “canonical wisdom” last week), it’s worth repeating the old chestnut: Agile does not mean no design. Just because no requirements are divine, we still need to think out our applications all the way through before we start making them.

Luckily, it seems like the idea that you can just iterate your way through a series of bad designs is on its way out, but now more than ever, the web application universe could save itself some trouble by just co-opting a lesson the desktop folks had to learn the hard way. The “iterative” approach isn’t used to fix broken or bad features, it’s used to add features.

So, whether you want to list out specific database tables, class diagrams, or pseudocode for algorithms in your spec is, if not exactly immaterial, certainly is not the point. That kind of thing is best decided on a project basis, and is pretty dependent on your org chart and the size and project-load of the senior members of your team (aka. do the “architects” keep working on the project once its designed, or do they have to go off and specify something else?). There’s No Silver Bullet.

The return of the curse of the second system

Seems pretty sensible right? Well, unfortunately, sometimes work isn’t.

One of the arguments you hear someone make from time to time is that agile design eliminates the need for the “throw-away first system.” The throw-away first system is a venerable tradition of admitting our own impotence in the face of our technology and a classic strategy that begins with one of our greatest software writers and ends with the (::Williamsburg-style “how-apropos”-grimace::) waterfall development agenda. It comes from a time when the problems were hard, when Google couldn’t provide you with example code, and when a movie cost a nickel. Ladies and gentlemen, Mr. Fred Brooks:

Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.

This strategy addresses a problem that was significantly more prevalent in Fred’s day: What do you do when there’s no map? And I don’t mean there’s no map for the implementation details, I mean there’s no map in the sense that you’re dealing with a totally new problem. Back in the 1960’s this was often a technology problem - less and less is this the case.

So, given that we can now instantaneously call up hundreds of free classes, code snippets, arguments for this method of optimization or the other, the famous disposable first system seems less and less necessary, to the point of being quaint, a bizarre artifact from software-prehistorical times, before the “agile revolution.” And, in the vast majority of cases, it probably isn’t necessary… Sometimes, though, you’re going to get a really high-level design problem.

Limited, Inc.

“The map is not the territory.” - Alfred Korzybski

So, here’s the amazing way in which agile methods actually end up owning a canonical piece of waterfall wisdom: Imagine, please, that you’re surrounded by people who are used to being able to solve problems with certainty and you have to acknowledge that nobody really has any idea how to design for the domain of a given problem. The only way to actually see what’s going to work here is to throw it in front of users (iterative, user-driven development, right? New-skool!) But throw what?

…the throw-away first system. Only now, the question isn’t whether the implementation is the right one, it’s whether the design was answering the right question in the first place. Which you can’t know until you try. Which is why, among other things, that even at the eight-count, you should never, ever, count Fred Brooks out.

I was on campus today taking care of some business and I had occasion to indulge myself with a Red Bull. While I stood there drinking, I started to think about which direction the label was facing. I could say I did this because I’m a designer and I’m always thinking of such things, but the truth is that I was concerned with how I looked holding that can in my hand—I’m narcissistic like that. I mean, this is an expensive soft drink; movie stars drink Red Bull. So can people tell that I’m drinking it? Do I look cool?

In this case, the answer was no. The label was facing me, so people were getting an eyeful of Nutrition Facts. I thought to myself, “what a wasted opportunity”. But as I began to think about it, the problem was more complex than I’d first thought. It’s a narrow can. There’s only enough room for a label on one side. So which is more important? Having the label face the customer so it builds association from the shelf to the first drink? Or facing the label outward, to advertise to others that someone is drinking the brand? I think it’s a tough choice. Fish or cut bait, right?

As I quaffed my caffeinated corn syrup, I turned this problem over in my head, but I couldn’t come up with a solution that would satisfy both goals. Everything I thought of was too complicated. When I came back to the refrigerated case for more “research”, I stumbled upon a profound solution, Zen-like in its perfection.

Do nothing.

What I noticed, as I looked over the cans, is that the placement of the mouth is completely random. I assume this is just a quirk of the manufacturing process. On average, the label will face out half of the time and face the drinker half of the time. Pretty elegant, I must say.