It is so easy to love a certain effect and want to use that everywhere. Not all projects need to have the selections sitting on a perfectly lit wooden bookshelf. On one hand we want to be creative and make something that is appealing and can sell the product. On the other side we have to question the cost of that approach on the experience itself and balance style and function with purpose.

link

As a Typekit user, you’ll have access to our library of high-quality fonts. Just add a line of JavaScript to your markup, tell us what fonts you want to use, and then craft your pages the way you always have. Except now you’ll be able to use real fonts. This really is going to change web design.

Also worth checking out, Jeff posted a preview of the Typekit home page yesterday. Looking forward to how this will change typography and design for the web. link

While all these things are what the designers at Netflix work hard on every day, they go unmentioned by their customers. It's not because these aspects aren't important. It's because the designers have done their job really well: they've made them invisible.

link

Personally, I welcome this competition. Seeing the work of other developers whose work I respect and admire acts as an inspiration. Looking at how other developers tackle a problem domain often adds insight into solving similar issues with my own code. In other cases, it shows me how I don’t want to implement a feature (without the need to prototype.) In short, competition will make Twitterrific better.

link

The more we learn about people, and how our brains process information, the more we learn the truth of that phrase: form and function aren’t separate items. If we believe that style somehow exists independent of functionality, that we can treat aesthetics and function as two separate pieces, then we ignore the evidence that beauty is much more than decoration. Our brains can’t help but agree.

Can’t say that I agree with all the examples he used. But important points that stand on their own, nonetheless. link

Fast text replacement with canvas and VML – no Flash or images required.

Oooh. Must experiment with this soon. (via @hicksdesign)link

Yesterday was my first day @twitter.

Yes, it’s true. After reading a bit of speculation over the past few weeks, I’ll confirm here that I am, indeed, joining Twitter. I don’t remember ever being as eager or excited to start a new job as I’ve been with this one. (Thus, why I only took one week off between jobs.)

Over the past year, I spoke with several organizations about coming on board to lead a design team. But Twitter felt the like most natural fit from the very start of my talks with the team. It’s still early in Twitter’s history. The company is small. Its user base is growing rapidly. And I see lots of potential to directly impact and to help shape the Twitter brand.

Add to that the fact that I know, understand, and respect the company’s leadership. And they know and respect my work, capabilities, and philosophy. (Several of us worked together on the redesign of Blogger in 2004.) A better fit is hard to find.

As Creative Director, I’ll have a few obvious responsibilities. Like building and shaping a design team, overseeing an evolving set of design challenges for a growing list of features and uses, and contributing to the company’s overall design strategy. Other responsibilities will include taking advantage of Twitter (and other means) to collect feedback and ideas about new features, implementations, or general UI changes.

I recognize the task before us is not small nor easy. Twitter means different things for different people and organizations, and it gets used in so many different ways. Maintaining the simplicity of the service is critical. At the same time, so is supporting an expanding set of features that enable new ways for users to connect with real-time information from sources that interest them.

Despite the changes ahead, I don’t regret my decision. Sure, I left a 20,000-person company with billions of dollars in revenue to join a startup with just over 30 employees and venture capital in the bank. The shift means I need to adjust to the pace at which we move, the scope of responsibility for each employee, and expectations for available resources. It means significant changes to how we, as a company, approach problems and propose solutions. And it also means more time for me back in San Francisco. In fact, from my desk, I can look out at the old Wired building where I got my start on the web thirteen years ago. I welcome changes like this with open arms.

Here’s to new challenges and new opportunities. Even when they’re taken on, one hundred and forty characters at a time.

Update: Here’s Twitter’s announcement on the blog.

Today is my last day at Google.

I started working in-house at Google almost three years ago. I built a team from scratch. I was fortunate to hire a team of a very talented designers. We introduced Visual Design as a discipline to Google. And we produced amazing work together. I’m very proud of my team, and I wish them well. They have a lot of challenging work ahead. But for me, it’s time to move on.

Do I have something else lined up? Yes. That will be covered in Part 2. So I’m not leaving just to leave. But I’m not going to sugarcoat the reasons for my departure either. The scale at which Google operates was an early attractor for me. Potential to impact millions of people? Where do I sign? Unfortunately for me, there was one small problem I didn’t see back then.

When I joined Google as its first visual designer, the company was already seven years old. Seven years is a long time to run a company without a classically trained designer. Google had plenty of designers on staff then, but most of them had backgrounds in CS or HCI. And none of them were in high-up, respected leadership positions. Without a person at (or near) the helm who thoroughly understands the principles and elements of Design, a company eventually runs out of reasons for design decisions. With every new design decision, critics cry foul. Without conviction, doubt creeps in. Instincts fail. “Is this the right move?” When a company is filled with engineers, it turns to engineering to solve problems. Reduce each decision to a simple logic problem. Remove all subjectivity and just look at the data. Data in your favor? Ok, launch it. Data shows negative effects? Back to the drawing board. And that data eventually becomes a crutch for every decision, paralyzing the company and preventing it from making any daring design decisions.

Yes, it’s true that a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. I can’t operate in an environment like that. I’ve grown tired of debating such minuscule design decisions. There are more exciting design problems in this world to tackle.

I can’t fault Google for this reliance on data. And I can’t exactly point to financial failure or a shrinking number of users to prove it has done anything wrong. Billions of shareholder dollars are at stake. The company has millions of users around the world to please. That’s no easy task. Google has momentum, and its leadership found a path that works very well. When I joined, I thought there was potential to help the company change course in its design direction. But I learned that Google had set its course long before I arrived. Google was a massive aircraft carrier, and I was just a small dinghy trying to push it a few degrees North.

I’m thankful for the opportunity I had to work at Google. I learned more than I thought I would. I’ll miss the free food. I’ll miss the occasional massage. I’ll miss the authors, politicians, and celebrities that come to speak or perform. I’ll miss early chances to play with cool toys before they’re released to the public. Most of all, I’ll miss working with the incredibly smart and talented people I got to know there. But I won’t miss a design philosophy that lives or dies strictly by the sword of data.

You need to take control of the design process. Its your site and you should get the design you want. The role of the designer is to implement your idea. Do not allow him to drag you down into endless discussions about ‘users needs’, ‘accessibility’ and ‘usability’. These are all distractions from the primary aim – to impress your boss and earn that next promotion.

Ok, I’ll admit, it took me reading past the first point to calm down and avoid jumping through the screen to grab Paul’s throat. link

I thought it would be interesting to provide a portion of the background on our buttons here, and discuss some of the iterations we’ve been through so far to get to the current state.

Background

Today’s web apps allow increasingly complex interactions. Users can view, create, manage, and manipulate all kinds of data, from email messages to feeds to photos to blog posts, or even choosing what their DVR records on any given night. We’re at the point where these apps need something beyond standard HTML form controls and basic hypertext links to represent the actions a user can take.

A basic <input type="submit"> could be used for single actions, a <select> element could be used for a compact menu of actions, and <input type="radio"> could be used for selecting mutually exclusive options. But we’re left with no way to represent other interactions common in desktop apps. Such as a checkbox that represents more than just on or off. Or the use of auto-complete to refine or narrow the options in a drop-down menu. On top of this, the controls we can render have significantly different appearances across browsers and platforms. Even within a single browser, buttons and select menus have quite different designs.

Enter: the concept of custom buttons.

The first iteration

Not long after I started at Google, I remember seeing mockups for a new product that eventually become Google Spreadsheets. The mockups I saw used simple buttons that looked similar to default HTML buttons in certain browsers. But they were subtly different than any default buttons I had ever seen before. The giveaway was seeing three buttons sandwiched together to make a pill button:

At first, I thought they were just generic browser-agnostic representations — and wishful thinking for the appearance — of actual HTML buttons. But once we started using an internal-only version of the product, I realized this button design actually got built into the product. That was fine. But I cringed when I realized how the buttons had been implemented. Each button was set up with a nine-cell table so they could place each corner image, and still allow the button to expand in all four directions according to the width and height of the text inside:

Eliminating the table and corner images

I knew there had to be a better way to render these buttons than using tables, and especially nine-cell tables just for the tiny little corners. So I tried creating a few prototypes to improve our button code. My first button attempt, which I named Custom Buttons 2.0, (version 1.0 would be the nine-cell tabled version done by one of our engineers) used a similar trick that I used for event chips in Google Calendar: the top border was one element with 1px left and right margins, the middle of the button was another element with left and right borders, and the bottom border recycled the styles of the top border with 1px left and right margins. This created a one-pixel notch in each of the four corners, giving the subtle illusion of a small rounded corner.

That 2.0 attempt was fine, and worked pretty well (as I expected) in almost all browsers. But it required that each button as a whole either be floated or positioned absolutely with a width. I wanted a set of buttons that could be treated as inline elements, and that would take up as much horizontal space as the text inside each button needed.

Going inline

My 3.0 attempt relied on treating the buttons and everything inside them as inline elements. The top/bottom borders still needed to be rendered separately from the left/right borders to get 1px-notched corners. The left/right borders were rendered on the outer element. The top/bottom borders were rendered on the inner element. Because borders don’t compound and add to the width or height of an inline element, we get the 1px notches in each corner. I ran into a lot of frustration with this inline approach until I remembered display: inline-block. That seemed to solve everything at once.

A demo page for Custom Buttons 3.0 shows my progress to this point. As you can see there, I built in affordances for changing the border color on hover, and for reversing the gradient direction for the active/click state to make it feel like the button is actually pressable. I also attempted to show how we could sandwich multiple buttons together to form a pill button. The pill button wasn’t perfect — I didn’t want gaps in the top/bottom borders between each button. But it was a start.

The magical inline-block solved everything, except in IE. That’s where the genius of Google engineers came in. They knew how to get tricks working in all browsers, and this technique interested a couple of them enough that they dedicated the time to make it work.

So 3.0 buttons were fine. After some modifications by our engineers, they made it into live production code. I believe 3.0 buttons are currently still in use for edit buttons in Google Sites, and in editor modes for Google Docs. (As of this writing. Expect those to change in the near future to buttons described below.) But I was still bothered by the requirement of a background gradient image. Not only was this an extra request to the server, but if anyone wanted to change the colors of a button, they’d be required to create a new gradient image. This wasn’t flexible enough, in my opinion, and I thought we could push further.

Eliminating the gradient image

Instead of rendering the gradient with an image, I thought we might be able to simulate a gradient with a few bands of color. With a few light grays laid beside each other that were close enough in value, we’d get something that looked like a gradient. With only two bands of color, I got a glossy-looking button with a sharp division between the two bands of color. Not what I wanted. Adding a third band of color between the first two colors blended each color together better. So three color bands it had to be.

To get that band of color and fake the gradient, I had to insert one more element in the button code. I chose <b> because it was short, and semantically, it didn’t mean anything. That element was absolutely positioned, so it could live inside the button and behind the text without affecting anything else. For the button itself, I used the almost-white #f9f9f9. For the <b> element I used #e3e3e3. The <b> element was absolutely positioned to the bottom of the button, and given a height of 40%. To get the middle band of color, I added a top border of #eee to the <b> element.

Another demo page for Custom Buttons 3.1 shows my attempt at getting this pseudo-gradient to work. It works in Firefox and Safari, and probably a few other modern browsers. But not everywhere. It was never perfect, and I don’t recommend using it in production code. Again, I couldn’t get this working right in IE. Google eng to the rescue again. To see the final code we ended up using in Gmail and Reader, you’ll have to reverse engineer the button code in one of those products.

Sweating the details

If we were going to undertake the task of recreating basic HTML form controls, we knew there were a lot of details that need to be accounted for and thought through. Like all the possible states of a button: resting, hover, focus, active, toggled-on, and disabled. There are also the accessibility ramifications of creating non-standard controls. I’m sure we haven’t factored in or solved every access issue yet. But engineers are working on that. Here’s a glimpse of the many states and types of buttons, along with the visual specs we had to think about and create if we were really going to replace default buttons and menus:

Major credit

I certainly didn’t create the concept of custom buttons at Google. Nor did I write the final code that made it into production. I merely initiated a couple steps to improve the methods we use to render custom buttons. My portion of the iteration is what’s documented here. There were many other steps in making these buttons a reality.

These buttons never would have made it into production code without the help of several Google engineers. One of the primary aids, Emil Eklund, helped fix a lot of my code for these custom buttons, and got it working in the browsers Gmail supports. He just posted an entry on the Official Gmail Blog yesterday about the label and folder-like functionality behind the new buttons in Gmail. Two developers (no longer at Google) also contributed heavily to the original button code: Ryan Carver and Greg Veen. They deserve huge props too.

Even more credit for the launch of these buttons in Gmail goes to one of the Gmail designers, Michael Leggett, who dreamed up all the fancy new functionality and interactions behind applying labels. Michael gave me lots of feedback and suggestions as we were building the original specs for 3.0 and 3.1 buttons. He also created countless iterations of the button interactions for Gmail, and endured numerous reviews and feedback cycles to finally get them launched in the product. If you like the new labeling menus in Gmail, Michael is the one to thank. The menus are especially slick if you use the new v and l keyboard shortcuts, along with auto-complete to apply labels (and even archive at the same time) without ever touching your mouse.

There are numerous other designers, developers, and engineers at Google who touched these buttons at one point or another. They all deserve credit too. I’ve only given props to four of the most prolific people who made these buttons a reality.

These buttons don’t permeate the entire Gmail or Reader interfaces yet for all browsers. (e.g. Compose view is still using default buttons for older WebKit browsers.) But now that these buttons are reusable components, expect to see us using them in more places throughout Google as we find good uses for them.

Influences

The previous version of this site, designed five years ago, went stale to me a year or two after I created it. After enjoying the spotlight for a few years after the launch of Stopdesign, I slowly faded back, where I continued to watch from the sidelines and admire the work of talented peers around me. Current and recent designs from the hands of Dan, Jason, Jina, Jon, Khoi, Mark, and Shaun have all influenced and inspired this version of Stopdesign in one form or another. Be it a palette, a grid, a type treatment, or a date format… Each of these designers sweat the details, and it shows in their craft. I’m humbled to have met and exchanged ideas with each one of these people in person.

I sometimes think of him as my alter ego, but I could never be him. Malarkey gets his own paragraph, because he is to web design what all four of The Beatles were to Rock and Roll. He is cool and hip and original and compendious at once. His personality, design sensibilities, and instincts around code make him a threat I’d rather be working with than against. His thoughts on HTML5 and standard naming conventions have been taken to task on this new site, with the exceptions of a few abbreviations and shortcuts for which I opted along the way.

Heroes

• Eric Spiekermann, for FF Meta and Stop Stealing Sheep (the first book I ever read about typography). I’ve beaten Meta to death, and it still looks good no matter where I use it. For the many who have asked over the years, the Stopdesign logo is my own bastardization of Eric’s pure, immortal version of Meta.
• Paul Rand, for his infinite wisdom and bitch-slapping avoidance of mediocrity in design.
• Jeffrey Zeldman for being the Godfather of Webstandards, and Eric Meyer for being the Jedi Master of CSS.
• Arthur Counts (junior high and high school art teacher, the one that saw potential talent in me when I was 11 years old; yes, Art Counts is really his name), Eugene Harris and Michelle Shoemaker (college art professors who helped me discover Design, the perfect mix for me of art and logic), Tracy Mitsunaga & Dennis Dimos (first creative director and design director I worked for, and my first professional mentors), Barbara Kuhr & Jonathan Louie (creative and design directors at Wired, and the ones who prevented me from giving up and leaving San Francisco when I thought I couldn’t sustain a career there).

Saint

Lastly, and most importantly, I am indebted to my wife, Cam. Her love and encouragement have pulled me though tough times and lots of self-doubt over the past few years. She’s my biggest fan, and my most helpful 2am critic. She also brought our first child into this world — an event that forever will inspire me and ground my sense of priorities in life. Finally, she’s also the one to thank for allowing me to work on this site after our daughter was put to bed each night, and through every long weekend for the past month.

I owe you all.

Why now?

The new design was brought on by multiple factors. I’ve been wanting to write more. But the few times I pulled up the site last year, I felt uninspired to write, knowing the design was feeling stale and dated. I wanted a new design, but never knew when I’d have time to undertake the seemingly huge, uphill task. The past few years have been filled with major personal changes for me. Getting married, working for Google, buying a house, and our latest adventure, the birth of our first child. All of these replaced the time I spent previously on my own projects. It’s difficult to crank out a new design when I only get a few hours at night after everyone but the dog goes to sleep, or in the morning before they wake.

The kicker that finally got the new design going: my server was hacked toward the end of last year, causing Media Temple to lock down everything, including any scripts or admin access. Malicious files were spread throughout my server, in random locations. The reps at Media Temple blamed it on an old version of MovableType that I hadn’t ever taken the time to upgrade. Oops. (Here’s a plug to update any old software you’re using, if only for security reasons.)

Because there were so many files in so many locations, and not all of them could be easily found, Media Temple provisioned a brand new server for me. They asked that I not copy everything over wholesale, for fear of unintentionally copying over files that were not mine. So I had a clean slate, albeit a forced one.

Grids rule

This design is way overdue. The last big redesign here was in 2004, a time when many of us were still designing for 800×600 resolutions. Time to move forward with a cleaner, simpler design, a wider width, more white space, and an obsessive attention to small details that most people will never notice. Like using a baseline grid (more on that in a future entry). The layout is based on a fixed-unit 12-column elastic grid, sized in ems. It creates just enough restraint, but still provides flexibility for today’s simple layout configurations, plus a few more future variations. I can check the grid on any page by simply adding ?g=1 to the URL, like so.

My type

I’ve always liked Helvetica as a typeface, and chose to use it for everything (with exception of the logo). The restraint of one typeface, along with a limited selection of type sizes, placed extra burden on spacing and arrangement to convey hierarchy. I tried to stick to the absolute minimum amount of content and navigation necessary to find one’s way around. More could be added later, but I liked the stripped down nature for most of the templates.

All colors, together as one

Never content with a single color throughout the site, I modified a few headers to give each section a slightly different feel. I’ve done this for the last few versions of Stopdesign, and I wasn’t about to skip that for this one. I get different headers simply by hooking on to already-existing body ids with a few additional CSS rules.

Technical nerdery

Some who read the footer will notice I switched to WordPress. This wasn’t so much prompted by the MovableType exploit of my previous server, as much as it was due to the difficulty and frustrations I had trying to upgrade MT after the compromise. Plus, I started using WordPress a little over a year ago for another personal site at dougandcam.com. In fact, if you visit that site, you’ll see a lot of design and content similarities to this one. This design was a chance to elaborate on what I had done at D&C D&C was the proving ground for WordPress, and where I learned how its template system and syntax works. Ultimately, I switched to WordPress because I was familiar with it, and had lost all my familiarity with MovableType. With no offense to my friends at Six Apart, development on WordPress seems to be happening at a faster pace. And it just fits more in line with what I want to do for now.

The particulars of which CMS I use aside, it was a lot of work to start over from scratch, rather than just modifying existing templates. So not only did I create a new design, I also completely switched template languages, plugin capabilities, and even a bit of my site structure. Previous versions of this site already relied on PHP extensively. So it was a welcome change to be able to interact directly with WordPress via PHP. (I never tried MovableType’s PHP templates–seemed like too much work at the time.)

IE6: the new Netscape4

This version of the site is also my first opportunity to give IE6 the proverbial finger. It was liberating to develop this site without checking my work in IE. Time for everyone to say I dropped IE6. Hello :before and :after pseudo-selectors, attribute selectors, adjacent-sibling selectors, and all kinds of other simple selector tricks that should have worked years ago in every browser.

I didn’t even check any version of IE until last night, when I figured I should at least take a peek to see how gloriously IE6 barfed all over a 10-year old CSS2 specification. Impressive, it was. For now, I’m using conditional comments to serve a custom stylesheet for IE6 just to turn off most of the styles. This seemed like the lesser evil, and at least ensures the poor souls still using IE6 can at least read my content. IE6 gets a stripped down, single-column view that will get no more attention of love after this. I’ll be able to yank those conditional comments and the entire stylesheet anytime I want. I noticed IE7 had one major problem with a negative margin, so IE7 gets its own little stylesheet too.

Getting personal

I mentioned above that I wanted a more personal feel to the site. Since I’m working in-house at Google, I’m not hustling contract work, so there’s no need to market Stopdesign like an agency or firm right now. Because of that, I decided to focus much more on the text of the site, downplay most of the imagery, and go with a very subdued, minimal presence. I chose to display recent Twitter status messages, Flickr images, and my current reading list on the home page to make the site even more personal. Forgive me if you’re not into baby pics–my daughter occupies the majority of my non-working and waking hours, so she’s the subject of almost all photos for the time being. That will change over time. Just ignore the cuteness in the sidebar if babies aren’t your bag.

Watch for sharp edges

Some of you may have already seen the new design a few nights ago when a slight gaffe of my own doing broadcast the new server’s IP address in a feed aggregated by Hot Links. That’ll teach me not to change Feedburner settings before I’m actually ready to pull the trigger.

I haven’t had time to polish every last little detail. But if I keep worrying about that, I’ll never get this design out there. There are still a few glitches in the site here and there. And there may be a few broken links or some missing pages now and then. I’ve done my best to prevent link rot by being diligent with mod_rewrite rules. But you may encounter some oddities or inconsistencies, especially if you dig back through older entry and archive pages.

I’ll do more explaining in future entries. I already have 5 drafts started.

So here’s to a new year. To our new President and the hope he brings. To many more ideas to share. And to a brand new design.

On starting in HTML/CSS, rather than something else… I’ve tried this several times. Starting with code is favorable in some situations. Especially when the interface is somewhat simple and the layout complexity is unlikely to change. When done similar to how Jason advocates: starting with a few paper sketches or prototypes, then moving straight to code, this can work really well.

However… I consider myself fairly competent in HTML & CSS. But even I am limited in design by starting with code before having a few design ideas fleshed out.

I have advocated in the past that HTML and even CSS are not design tools. They are tools used to implement design. There’s a big difference.

By design tools, I mean anything you can use that feels like a natural extension of your own hand. Be that physical objects like pencil/pen and paper, or software like Photoshop, Fireworks, and Illustrator. Ideally, design tools should allow complete freedom for creativity. They should also allow direct manipulation of the design, without having to think abstractly about how to render the design based on tool limitations.

Jason and his colleagues at 37signals don’t skip the design tools. They still use quick sketches on paper to start. They just don’t rely on Photoshop as a tool that they need to envision a design.

In a comment on Jason’s post, Jeff Croft asked if this no-Photoshop practice of going straight from sketch to HTML/CSS influenced 37signals design style? My answer: 100% yes, it absolutely did. I think it’s obvious when you view their apps. (Not that this is a bad thing.) This practice works well for them. But it certainly influences (and possibly limits) their design style. For them, this is acceptable and appropriate, and it may be for you too. Everyone works differently and has different goals and priorities for design.

Speaking from experience, I know there are designs I created (and coded) that would not be the way they are if I had gone straight to code. In fact, this is how and why I created several new CSS techniques back in the day — out of necessity. An idea existed in a static design somewhere, and I wanted a way to recreate that design with optimized and accessible code, without compromising the design. So I had to invent one.

If you start with code, you will be limited by what you know you can do with code. Whether you’re a code noob or a code snob. Because it’s just that, code. It’s a tool intended for implementing design, not necessarily one for creating design. If you start with a familiar design tool, you know sky’s the limit — anything you dream of, you know you can create or render without thinking about it too much. Starting in code, you’re immediately restricted by tighter bounds of possibilities.

For evidence of this, browse through the CSS Zen Garden. I can tell which contributors started with a few sketches and some form of design tool first, and which contributors started directly in code. It’s obvious after you’ve seen enough designs.

New designs, new techniques, and even additions to the W3C CSS standard would come about much less frequently if we settled just with what we knew code can do. Or what’s been done before. To foster innovation and creativity, design sometimes needs to be divorced from the restrictions of its implementation.

That said, there’s value in not sticking with design tools for the entire process. Especially for the Web, it makes sense to flip to implementation tools at a mid-point in the design process. At a certain point, more work in Photoshop or Fireworks is just fuss. And could be done more quickly and more efficiently in HTML & CSS. Just a matter of determining where that flip should occur — and it’s different for each design team.

This brings me to David’s post, “Web designers should do their own HTML/CSS“. I mostly agree with what David writes. I just wouldn’t be so dogmatic about it. As I was building a Visual Design team at Google, I wasn’t necessarily looking for designers who knew how to wield HTML & CSS like a Jedi wields a lightsaber. After all, Google has an army of engineers to write code, and a very specific way of writing it. Rather, I wanted a team of people who could design and create, first and foremost. I wanted them to have some knowledge of the web’s limitations. However, I stopped short of expecting that they could or would code any design they created. I can teach a designer HTML and CSS anytime. But I can’t teach someone how to be creative with design.

I’m not going to feel bad if I start with a tool that feels more comfortable to me during the creative process. Nor will I shame any other designer I work with for the same. Especially if other tools limit creativity. In any design medium (print, web, interior, industrial, fashion, even architectural design…), I would not be a true craftsman until I intimately understand how my design gets produced and the materials needed to do so. This most importantly includes the innovations and compromises that need to happen along the way because current production techniques can’t recreate my design.

When starting any design, choose the tool (or set of tools) that’s not only right for the job, but also right for you.

Update: Other responses to 37signals’ posts I’ve seen, that probably say it better than I did:

• Jeff Croft: Why we don’t skip Photoshop
• Jon Hicks: Graphics Editor or Text Editor
• Nicholas Rougeux: Why I use a print program for web design
• Mark Boulton: Design isn’t about tools

Permanent link to the working version of this design.

Permanent link to the working version of this design.

The more you see, the less you know
The less you find out as you go
I knew much more then, than I do now
—Bono, City of Blinding Lights

Permanent link to the working version of this design.