Career I’d like to try most if I was not an interaction designer: architect.

I first thought this during a tour of the Taliesin West, former home of the legendary Frank Lloyd Wright. Today, I’m thinking it because of this article and audio slide show about tiny houses.

Of course, I’m a bit of a junkie for constraints in design. Constraints bring the best ideas to the surface. Designing a house, that you plan to live in, that is only 750 square feet or less (possibly a lot less), means coming up with some mighty good ideas about how to maximize your space and minimize your lifestyle.

Kudos to the architects that face this challenge and find elegance in the possibilities.

Firefox:

Not good. I have to either right-click, double-click, or use a keyboard shortcut (Ctrl/Cmd+T).

Internet Explorer 7:

Terrible. I always think I’m supposed to click the hanging tab to close the current tab instead of create a new one. And when multiple tabs are open, I can’t close an inactive tab without first making it active. Select it to see the X, then click it. Why not show the X when I roll over the inactive tab?

Netvibes:

Three words: What the $%&@?

Google Personal:

Very nice, but needs work. My only real issue is that I have to click twice to “Name this tab” (once to activate the tab, once to start the renaming interaction). But I love the “Add a tab” link. Very clear. (Netvibes has this as well, but they’ve crammed all the page properties into a box that expands out from an arrow in the tab graphic. Crazy.)

Pageflakes:

Ahh … perfect. (Well, as close as I can get anyway.)

According to Manifesto for Agile Software Development, and the principles described on that site, I’ve been working in Agile (with a capital “A”) environments for several years. I may have deviated slightly in certain respects, but overall, I’ve done the Agile thing rather well.

But according to at least one or two of the people that wrote the manifesto, who shall remain nameless, and a few other practitioners of Agile Software Development, Agile seems to have a few more “rules” than are spelled out on the site. Rules that say that listening to users/customers is the only way to build something that works for them. Rules that say no one has authority over anyone else, that everyone is supposed to reach a consensus. Rules that say that if you’re not wholly embedded into the Agile team, you’re not Agile. (This also seems to make you less than human in some cases.)

Of course, I don’t buy any of it. If you’ve been reading this blog for a while, you know my reasons.

Finally, there’s an accepted perception that Agile is not the same as being agile (with a lowercase “a”). As in, trying to apply the dictionary definition of the term “agile” to Agile Software Development is to make an ass of yourself.

Of course, I know from experience that a company can be agile regardless of whether or not it’s Agile. Companies can work in 3-week iteration cycles (give or take), constantly review and revise methods to find ways to improve them (otherwise known as Kaizen, core to Lean Manufacturing), be open to last-minute changes, be nimble enough to adapt on a moment’s notice, and put out consistently great work whether it’s Agile or not. I know this because I’ve done it. Many times.

Still, there is apparently a serious difference between Agile and being agile. And according to the authors of the manifesto and some of its practitioners, it seems to be a little like the difference between John Malkovich and Being John Malkovich.

This is a only a problem, of course, because it means I can’t talk about being agile unless I’m actually Agile. But I’m still very interested in agility as it relates to software design and development, because it has the goal of putting out high-quality software using quick and effective methods.

So I think I’ve decided I want to be Nimble. Or maybe Fast and Flexible. I don’t know. I just don’t think I want to be Agile anymore. It’s too hard to be part of a club that puts all of its weight on its manifesto and then blatantly ignores the purpose for its existence.

So you’ve read the book, and now you’re wondering how to apply some of those pesky design principles to your own applications. Have no fear! I’m available for one-day training sessions.

I’ll come to your offices, to talk about your products.

Get the details on the training page.

If you’re attending SxSW 2007 in March, be sure to stop by my panel, “Why we should ignore users”.

Mark Schraad and Sarah Bloomer, both members of the Interaction Design Association, and I will be discussing the merits of performing user research during design projects in an attempt to nail down whether this classic tenet of User-Centered Design is really necessary and what we can do to make sure every user experience is good as possible.

Mark is a die-hard UCD advocate, I’m a die-hard advocate for avoiding user research, and Sarah is somewhere in between (so she’ll be moderating). It should be a very lively debate, so you’re sure to walk away with some new ideas that could significantly change your process for the better.

The panel is on Sunday, March 11th, at 10am.

I’ll be doing two book signings during the conference as well, at these times:

• Saturday, March 10th at 4:30pm at the Day Stage Cafe’
• Sunday, March 11th, at 3pm (after the panel), in the South by Book Store (hosted by Barnes & Noble)

See you there!