Been thinking of starting a company? Maybe started one recently? Or just have entrepreneurial tendencies in your blood? Check out Start. Friends and colleagues, Jeffrey Veen and Bryan Mason, are hosting a one-day conference in San Francisco on August 7 "for smart, talented Web people to take hold of their ideas, follow their dreams, and start their own companies."

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?...

It's rare these days that something pulls me out of the woodwork to write something here on Stopdesign. A few recent posts by Jason and David at 37signals (Why we skip Photoshop and Web designers should do their own HTML/CSS, respectively) got me thinking though. This post began as a response on an email thread at work. I'm expanding it here to a wider audience.

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:

Though I'm a little leery of the massive size of SXSW this year, I'm really looking forward to seeing and catching up with friends new and old (and meeting a few more) in Austin later this week. It's that time of year, when geeks from all over the Web physically converge in central Texas, fight for the last few available hotel rooms, and elbow their way to a choice seat at any of over 150 Interactive panels.

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.

Simply put, xScope is a back-pocket, time-saving utility for designers and developers created by designers who understand the nature of working on screen. I haven't written much about the software I use. But once in a while I come across something that's so useful, I'm compelled to spread the word a little further. And the latest update of xScope to v2.0 adds some really nice enhancements worth drawing me out of hibernation.

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.

There are so many people in Austin for SXSW Interactive. I haven't even seen some good friends who I know are here this year. Among 8-9 different tracks running at the same time during the day, and multiple parties happening every night, it's difficult to catch everyone I'd like to see. On that note...

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.

So a few of my fellow Google UXers and I will be at SXSW this year. We thought it odd that we couldn't find a calendar that aggregated all the sessions, panels, and parties of SXSW in one place, in a traditional calendar-like view. There are lists of daytime panels and evening parties, and you can add events one at a time to a personalized calendar on sxsw.com. But there was nothing that aggregated it all in one easy-to-view, all-at-once calendar (at least nothing that we knew of).

(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.

A little over a month ago, just before Web Directions North, John Allsopp asked me a few questions over email about what I've been thinking and doing lately. Digital Web Magazine was kind enough to publish the exchange between us. A few friends have emailed me, having discovered the interview by other means, asking why they never saw mention of it here. Somehow, amid preperations for the conference, then ultimately, my back injury and cancelled appearance, I never got around to mentioning the interview.

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.

Last week was supposed to be a big week for me. As John Allsopp put it, I had been lured out of a self-imposed retirement from speaking, and was scheduled to appear at Web Directions North in Vancouver. I was really looking forward to speaking again, along with seeing old friends, making new ones, and the general camaraderie experienced at events like that.

Alas, for some reason, that wasn't to be. On a fine Sunday morning before the conference, I bent over the sink to spit out some toothpaste, and felt a shock of pain go through my lower back. I instantly told myself, "oh, it's nothing. just a twinge of pain. it will go away in a minute." But it didn't.

Cam and I waited out the injury, hoping the pain would subside and magically heal itself, and I would be able to medicate enough to fly to Vancouver on Tuesday morning, and attend the conference as planned. Over the next two days, my back got progressively worse, until I could barely move or sit up in bed without excruciating pain.

Long story, short, the pain continued all last week. And I had to cancel my trip to Vancouver and plans to speak at and attend Web Directions. I tried to fight off the depression and the negative thoughts. But the disappointment I felt was huge (and still is). I was forced to miss out on the opportunity not just to speak again, but to hear so many great speakers at once, and to reconnect with friends I hadn't seen in over a year. Not to mention the snowboarding in Whistler after the conference.

This is the fourth time in the last two and a half years that I injured my back to the point of debilitation and forced rest. I have a bad disc in my lumbar region. Doctors told me after first injury that I might be forced to deal with it the rest of my life. Physical therapy helps immediately after the injury. But after the pain subsides, I tend to forget about the exercises and the stretching and the fact that my body is not perfect.

If I am to make a difference in the future health of my back and my body, I must make changes to my daily routine. The treatment I learn after each episode must be folded into the strands of my life.

I really don't want an injured back to prevent me from doing anything or going anywhere else.

Last weekend, Cam and I drove up to South Lake Tahoe for a couple days of snowboarding and escape. Tahoe is too far from us for a one-day there-and-back trip. But it's close enough (~4 hour drive, sans traffic) for a weekend getaway. It was Cam's first attempt at boarding. I say, she did remarkably well given her lack of any prior experience skateboarding or surfing. She even skated off the lift a few times without falling (no small feat, for those who haven't tried snowboarding yet.) She came home quite sore and bruised in a few places. But I think enough of the bug was caught that she'll be willing to try it again soon.

I'd just like to leave one note for anyone else planning to board or ski at Heavenly in South Lake. Do not rent your equipment from Heavenly Sports on the mountain. I repeat, do NOT do this. That is, unless you like waiting in line for up to two hours, only to get inside and deal with the chaotic process of renting from the most unorganized team of rude, clueless "equipment specialists". We made this mistake once, but we won't make it again. The equipment is old; the specialists lack any knowledge in proper adjustment of basic bindings. It's pretty bad when the instructors employed by the same resort advise all of their students to avoid the mountain rental shop at all costs. Instead, either rent locally and drive up with your gear. Or rent at any one of the small shops closer to the lake. Or get your gear from the Burton demo shop in front of the California lodge. Just don't plan on renting anything from Heavenly.

Getting back into the swing of writing regularly here never really happened in 2006. When I look back at my archives, I see I only posted 11 times the entire year. And that includes three posts (1, 2, 3) that weren't really writing-based, as much as they were simple design and code experiments.

Busyness accounts for a lot of it. 2006 brought a lot of changes for me, personally and professionally. Planning my wedding, putting Stopdesign as a business on hold to go work for Google full-time, getting married and honeymooning afterward, moving to a new place, getting a dog, and the life and responsibility that comes with all of the above. 2006 treated me very well -- I'm certainly not complaining.

Another major reason for the lull in writing was general blog burnout. I was tired of writing on my own site. With greater numbers of readers building through 2004 and 2005, I felt greater pressure to write longer article-like posts with take-away content in every entry. More nutrition in every bite. And I was tired of other blogs. Tired of keeping up with hundreds of feeds. Tired of posts that pandered for comments or held contests to gain traffic, or those that recycled another me-too meme or blabbed about the wonders of Web-2-point-whatever.

So I stopped using my feed reader completely. I let go of the pressure to keep up. I let go and just lived my life. If I wasn't working, I wasn't really on the Web. I only visited sites I liked and sites of my friends occasionally, just to keep loosely updated on their work, thinking, and lives.

Lately, my interest is piqued again. Not so much by a fear of not keeping up with the world of blogs and news and events. But by a general desire to write for the sake of writing. In my daily life, I'm exposed to design in entirely new ways that I've never experienced before. I face new challenges. I encounter new ideas, situations, and interactions. In many ways, it feels like I'm just starting out in the world.

So I look back to my first post of this blog, and think of returning to my roots. Write for my own record, not what I think others want to read. To lay out my thoughts, responses, and reactions to my industry and the events that surround my career and interests. To chronicle the bits and information around me. Short posts or long ones; on-topic or not; doesn't matter. Just write.