Critiquing by Twitter Design

What we’ve been up to

We post samples of recent work on our Dribbble account. We’ve started posting photos of the studio and the team on 500px. (Some are embedded here in this post.) And, of course, we tweet too, from our team account, and all our personal accounts. Want to know more? Ask me or anyone on the team anytime. Here’s a tip: the service on which we all work makes us all easily contactable. We’re a pretty open bunch, and we’ll answer any questions as openly and honestly as we can.

A perspective on Twitter and @design

Next March, it will be four years that I’ve been working with Twitter, leading and directing the Design team. People ask me all the time if I still like it. My honest answer: I love it now more than I did when I started. Anyone I work with can confirm that.

It’s not that I don’t have fond memories of my early days at Twitter. I do — those first couple years were really good. The people I worked with then, the experiences we had together, and the challenges we faced on a regular basis as a small company were inspiring. But we have a sizable team now, and exponentially more people using the product every single day.

Design has multiple researchers who help us understand how people think about and use the product. We have prototypers and devs who help us rapidly build out and gut-check experiences. And we have a great blend of experience designers who think through and work on problems from concept through to production. We can finally get ahead of big design problems and attack them more strategically.

User Research Explained by Twitter Design

Now, more than ever, our team is really humming, and it’s finding a great groove. We’re fortunate that the team is filled with smart, funny, talented folks who care passionately about Twitter and the product experience. There’s a great, positive energy in the design studio, and it’s contagious.

We recently added Mike Davidson as our VP of Design. I’ve known and respected Mike for ten years, but I’ve never had the chance to work with him directly until now. I’m really happy he’s here to help fight for and defend great design throughout the company, and create the space for Design to push and innovate on Twitter’s experience.

Add to this the impact that Twitter has had and is having all over the world. Connecting people, some who have never met. A pulse of the news, events, and human perspective as it’s unfolding. Distributing awareness of what’s happening in the next room, the next neighborhood over, or around the other side of the world. This free exchange of information is changing the world, and I don’t state that lightly. I’m humbled that I get the opportunity to contribute to the Twitter experience on a daily basis.

We’re just getting started

Built up over the past few years, we’ve seen an incredible evolution of Twitter. It’s a service that many of us value on a daily basis. But our team’s work is not even close to being done. In many ways, we’re just getting started. While Twitter gets tons of exposure and coverage, there’s so much work to do to make it simpler, easier to understand and use right away, and a more beautiful and consistently delightful experience.

Video… That Way! by Twitter Design

Mobile First by Twitter Design

Be one of the team members in these shots. Come help us with some of the most interesting challenges a designer can face today. And contribute to a world-changing service whose impact has only just begun. Join the flock.

The redesign of Wired News in 2002 marked the first time a large, well-known, daily-content publisher had dropped tables for layout, and embraced the separation of markup and style in a rather new (at the time) approach to web design. Several prominent blogs, and niche content sites (zeldman.com, meyerweb.com, alistapart.com) had broken ground, and were already using and evangelizing a greater adoption of Web Standards.

Halfway through the redesign process, I started plotting how Wired could support the standards movement not just by publishing stories about it, but by adopting it outright. If pure, valid XHTML to mark up the content and simple CSS for layout and style was enough for other sites, it should work for Wired too. I contacted Jeffrey Zeldman and Eric Meyer to let them know what we were up to. Their excitement over the prospect of Wired jumping on board hinted that this might be a big deal. We dove in head first, and never looked back. Not long after Wired took that leap, many other large, well-known sites and companies began following suit.

I note the tenth anniversary of this redesign, not because of what it was then, but because of how far we’ve come since then, and everything that has been set in motion since. Ten years is a good chunk of time to take note of progress, large and small. Some folks say common tools like HTML and CSS haven’t evolved much. But that misses the point of everything we’ve been able to do and experience because of our use and adoption of them.

Governments, news organizations, retailers, and individuals all around the world use our inter-connectedness in dramatically different ways, compared with ten years ago. Shopping, storing, organizing, and interacting online is now second nature to a massive global population. And increasingly, we’re doing all of this with small devices that fit in a single hand or a pocket.

As I look back on the past ten years, I can easily see how the path of my career, interests, friends, and professional connections were partially shaped by a little redesign in 2002 (now insignificant by today’s standards). A cascade of events and opportunities followed that point in history for me. It was just a matter of spotting them, and jumping on a few.

Where were you ten years ago? What were you doing, and what was your craft like then? Who do you know now that you didn’t know then? What brought you to where you are today? It’s fascinating to think of the journey from the events of ten years ago, all the way up to today. Just think of the next ten years…

I’m seeing lots of other folks building out their own archive. And lots of them are using the WordPress solution I wrote about. So in the interest of providing a rough starting point, I’m making the WP theme files for my tweet archive available here (under a CC license) for anyone who wants them as a base. Download tweets.zip (39 KB).

One followup note… Andy Graulund (@graulund) is building a similar tweet archive that is much more robust and more awesome than my original. His is a PHP-based solution (no WordPress required) with embedded media, permalinks back to Twitter, graphs showing tweet activity, and more. I believe he’s planning on releasing his source soon. Keep an eye out for that.

—

WordPress-based browsable, searchable archive of tweets by Douglas Bowman is licensed under a Creative Commons Attribution 3.0 Unported License.

One year later, I’m just as eager and excited to head into work today as I was then. More so. Because I know even more about this growing company, the amazing people who work for it, the humbling principles under which it operates, and the myriad of purpose it serves. I’m thrilled with what we’ve accomplished in Design, and with the designers we’ve hired to do the accomplishing. We’ve pushed out some “good” and a fair amount of “awesome” so far. But we still have much work to do.

It’s cliché, but still true. Time flies when you’re having fun. And what fun we’ve been having. Here’s to looking back at a fantastic year, and forward to another that puts last year to shame.

I know there are a few apps or scripts that create backups and much more for you. But I wanted a database and simple UI completely within my own control. One that wouldn’t go away if the developer abandoned it. So one Saturday a few weeks ago, in a little over an hour, I had my own, free, browsable, searchable tweet archive. Now I can easily browse back to my very first tweet, or search for those quotes by Paul Rand I tweeted last year. This isn’t anything entirely new. I’m just writing it up what works for me in case it helps fit some pieces together.

How to set up your own tweet archive with WordPress

1. Assuming you have a collection of past tweets, the first step is to collect them in one place. TweetBackup.com provides an easy way to do this. It uses OAuth, so there’s no need to enter your username or password as long as you’re already signed into twitter.com. Give them an email address, and your tweets start backing up immediately. (See their FAQ about a possible limitation of 3200 tweets.)
2. Once TweetBackup is done grabbing all your tweets (it took about 2 minutes for my ~1,400 tweets), go to the Export tab, and save the RSS format to your local drive
3. Install a fresh copy of WordPress somewhere on your server if you don’t want tweets intermingled with other WP content. In the Tools section of WordPress, use the built-in RSS importer to import the file you saved from TweetBackup.
4. Assuming you want WordPress to automatically grab each tweet from this point forward, install the Twitter Tools plugin, enter your Twitter credentials in its settings screen, and configure it to create a blog post for each of your tweets. (Turn off the option to tweet when a post is created from this blog so the universe doesn’t explode in some endless loop of repeating tweets and blog posts.)
5. Update: I made the WP theme files for my tweet archive available for download for anyone who’d like to use them wholesale or as a base for their own archive.
6. That’s it.

A few extra steps, if you’re up for them

1. Twitter Tools will handle future tweets correctly. But the format of each tweet from TweetBackup starts with a prefix of your Twitter username, followed by a space and a colon, like this: “stop: Clicking through the new design of…”. I used the Search Regex plugin to search for and eliminate that prefix.
2. Past tweets from TweetBackup won’t have linked URLs. The Autolink URI plugin can do this for you automatically.
3. If you’re good enough with regular expressions, you can also use the Search Regex plugin to link up any @mentions and #hashtags in your tweets. I suck at regex, so I cheated and used some of the patterns from David Walsh within the Search Regex search/replace UI. Technically, you could probably use David’s first pattern to link up URLs too.
4. A few WP plugins can enhance the built-in search functionality of WordPress. I’m using Search Everything.
5. WP Super Cache will keep server resources to a minimum and help load pages quickly once they’re cached.
6. If you’re really up for it, you can customize the templates and design as I did. Anything is possible if you’re familiar with PHP and WordPress templates. For instance, you could try using the Similar Posts plugin to suggest possibly related tweets on the permalink page.

Now, every tweet you’ve written and will write can be duplicated and backed up in your own MYSQL database, accessible via a WordPress front end. Technically, you could probably use any blogging platform or CMS to do this. (It doesn’t require WordPress.) You’ll just need a means to import old tweets and automatically grab new tweets.

Another similar photo compares packaging for the 12" iBook purchased in 2006 next to the box for the current 13" white MacBook purchased in 2009.

In both cases, the newer notebook is larger than the older notebook, yet still uses a much smaller box.

After recent Unboxings™ of the MB and MBP, I noted there’s no less “stuff” in the box as far as hardware, adapters, install discs, and printed material. The new packaging designs just forgo the thick molded styrofoam padding of the old boxes.

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.

• Amazon Showcase by Aaron Forgue
  Drop in any ISBN and this plugin takes care of the rest for Amazon reading and recommendation lists.
• Live Comment Preview by Brad Touesnard
  Lots of plugins generate a real-time comment preview. This one seemed to be easy to configure and get working right away.
• Postalicious by Pablo Gomez
  This plugin automagically pulls in my Delicious links on an hourly basis, publishing an entry for each link I create. (It can also be configured to publish sets of links in a single entry too.) It’s a useful plugin for automating posting of links created elsewhere — it can also handle ma.gnolia, Google Reader, Reddit, or Yahoo Pipes. Pablo, the author, is incredibly responsive. After I emailed him a casual suggestion on a Saturday afternoon, he had a new version of the plugin (with my suggestion incorporated) in my Inbox later that same evening.
• Twitter for WordPress by Ricardo González
  Set it, and forget it.™ Once installed and configured the way I wanted it, I’ve never had to think about my tweets showing up on the site again.
• WP Super Cache by Donncha O Caoimh
  A must for speedy page-load times and to keep the server humming along, especially on high-traffic days.
• Search Unleashed by John Godley
  Does several cool tricks with search for a WordPress site, including query term highlighting and searching across every post and comment field. I’m using the plugin for the results page, itself. But I wasn’t able to use the query term highlighting on entry pages because that conflicted with pages cached with WP Super Cache, and I wasn’t able to figure out how to prevent caching of entry pages referred by a search.

A friendly reminder: some authors put in lots of time and effort into plugins that are free for us to use at will. If you can afford to, send a donation their way, especially for plugins that do any heavy lifting for your site.

I’ve been following user agent stats for the past few years. It was only three years ago (January 2006) that Internet Explorer held the dominant percentage of aggregate traffic (70%+) on Stopdesign. Back then, Firefox was just over a year old. ¹ I remember being impressed that Firefox had already gained 10–12% of traffic at that time. Apple’s Safari was just 2 ½ years old ² and was hovering around 3–4% of Stopdesign’s traffic.

So that’s where we were then. IE dominated. Firefox trailed far behind in second position. This is where Stopdesign’s traffic is now:

* Stats represent the last 5 weeks or so of traffic for Stopdesign.com. Captured with Shaun Inman’s excellent website analytics package, Mint, via his User Agent 007 Pepper.

Chrome traffic is higher than normal because of the Recreating the button entry posted two days ago. My theory: Chrome users tend to be more heavily invested in Google products, so they’re attracted to content about Google. (Note: I don’t have access to data that backs this up, nor am I speaking on behalf of Google. But it’s a logical conclusion for anyone to make.) Thus the spike in Chrome’s percentage, which had been hovering around 2% prior to posting the button entry.

For those who care to see the IE breakdown, here are those numbers:

Sources:

1. Mozilla.org: Mozilla Timeline
2. Wikipedia: Safari (web browser): History and development

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.

The lineup of speakers alone piqued my interest: Evan Williams (Blogger, Twitter), Matt Mullenweg (WordPress), Merlin Mann (43Folders), Mena Trott (Six Apart), Om Malik (Giga Om), Julie Davidson & Narendra Rocherolle (30boxes, Webshots) and more. At only $200, registration for this event is a steal.

The jokes I heard in Boston: Jeff and Bryan have the Start Conference, when will I hold a Stop Conference?…

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

If you’re coming to Austin for the conference, and you’re in town by Friday afternoon, come by our panel at 5pm on Friday entitled, “Respect!” hosted by the esteemed godfather of Web standards, Jeffrey Zeldman. Mr. Zeldman, Erin, Liz, Jason, and I will discuss the common ground of various professionals creating for the Web, and how we work together to advance our craft and the understanding of what we do. I may even get to share a few insights that come from working as an insider for the past two years at the Googleplex.

If you haven’t seen or used xScope before, I’d describe it as a simple set of mini tools or widgets that help measure, size, or align anything on-screen. Any of xScope’s little semi-transparent widgets can be invoked individually or in combination. Once visible, they remain on the surface of your screen, floating above any other currently open apps.
Included in xScope’s mini arsenal are rulers, and guides, and loupes, oh my. Rulers help measure stuff (duh), Guides help align stuff, and the Loupe blows stuff up for inspection of every little pixel. There’s even a Screen tool that will overlay available screen real estate of common browsers at different resolutions.

Those tools are all fine and dandy. They’ve been in previous versions of xScope. What piqued my interest was the new Dimensions tool. Dimensions rocks!

In normal (“Beam”) mode, move your cursor around the screen, and Dimensions displays horizontal and vertical measurements of just about anything visible, including gutters, margins, images, buttons, desktop backgrounds, and OS-level controls and UI elements.

Even better, Dimensions has a secondary “Shrink” mode (Command-Shift-5) where you can draw a somewhat sloppy box around anything on screen, such as an icon or a block of text. xScope will shrink the box down to the smallest dimensions, leaving a frame on screen around the object you selected. The frame displays the selected object’s bounding dimensions, and enables a simple screen grab of just that frame.

To see it in action before downloading a trial, IconFactory has a demo movie of the Dimensions tool (5 MB QuickTime .mov) available to view.

The first time I saw Dimensions in action, my wheels were turning. I could imagine immediate uses. All without needing to do a Command-Control-Shift-4 to grab a portion of the screen, create a new Photoshop doc, paste it in, blow it up a few times, then carefully measure or crop it with the marquee tool. That’s at least 4 steps I can save with the dimensions tool.

With any of xScope’s tools, like Guides, I like that I can set a few on screen, then get them pixel-precise by nudging with the arrow keys. I can hide them for a while. When I need them again, enable Guides, and they’re right where I left ‘em. Even after quitting and restarting xScope days later.

Also new in 2.0, having the option to enable or disable menu bar icons is a nice touch. The default “toolbar” always felt a bit awkward to keep around. So opting to just have a few xScope icons of choice in the menu bar is an especially welcome feature.

Dimensions, alone, keeps me running xScope in the background much more than I ever did before. It’s a worthwhile set of tools to keep in your back pocket. If your pixel-precision prowess doesn’t have access to xScope, you’re only knitting with one needle.

If you’ve ever wondered what it’s like to work for and at Google, or are interested in Google products… Or if we know each other but haven’t had a chance to catch up yet here in Austin–or even if you and I don’t know each other–and you’d like to chat for a bit, just a quick note here to encourage you to come by the Google booth here at SXSW (on the trade show floor, toward the far-right side as you enter). I’m scheduled to be in the booth area from noon until about 2pm both today (Monday) and tomorrow (Tuesday).

If you’re at the top of your game, and might be interested in working for Google, coming by the booth is a good opportunity to speak with one of us casually about working in the User Experience (UX) group. We have multiple positions open in design. Specifically, I’m trying to build out the Visual Design team with talented folks who have a passion for Google products and a clean, intuitive design sensibility.

Even if you see me outside the booth hours, feel free to stop me anytime and say hi.

(Scene Left: Tantek walks in and begins expounding on the merits of microformats, informing everyone that the entire SXSWi panel page is marked up with hCalendar, and that we can all use Tails or Operator, or some other Firefox extension that could magically whisk all the event data out of that page, somehow allowing us to import the data into iCal or Sunbird or Outlook or whatever floats our fancy. Narrator responds: But what about evening events? And why should everyone need to go through that trouble to see everything at once?)

And that’s where I started thinking. Let’s suck all that SXSW Interactive event data into Google Calendar, get all the relevant details entered for as many events as we can and in the right fields, then share the calendar with each other. Or better yet, let’s just make the whole calendar publicly available to anyone who wants it. So a few of us got together and did just that. And now you can add SXSWi 07 as another calendar in Google Calendar, or subscribe to the ICAL feed or XML feed in any calendar app of your choice. Event names, times, locations, and as many details as we had are all in one place.

I know SXSW tends to be a little spontaneous as far as what I (and others) choose to attend. But there’s so much going on over the next few days. I know there are a few panels and parties many people don’t want to miss. I don’t expect anyone to keep the whole SXSWi calendar visible all the time–there’s way too many events on it for that. Rather, you could use it like I’m going to: grab a few of the panels and parties I don’t want to miss, copy them over to my personal calendar, then hide the SXSWi calendar until I need it again. Sync my personal calendar with my Treo via GooSync. Delete it at the end of SXSW.

Note: This is not in any way an official calendar provided by Google. It was just cobbled together by a few of us who happen to work here, then shared publicly in hopes it might be useful to a few SXSW attendees other than ourselves. As always, all events and details are subject to change at the whim of the organizer without notice.

Also worthy to note, the events are all (obviously) happening in Austin, TX. So they’re tied to Central Time (GMT-06:00). If you’re coming from far away, you’ll probably want to adjust your calendar’s time zone setting once you arrive, so times will all appear correctly while you’re in Austin. Just remember to switch it back to normal once you return home!

If you’ll be in Austin, see you there.

If I were to write an extended update here that covers my recent life, technology that interests me, and the issues I’ve been mulling over, it would consist of the same answers I provided to John. Thanks, John, for taking the time and interest to ask the questions. And thanks, DWM, for publishing my responses.