T Incorporated: Latest blog entries

Creating a Polaroid wall

Tom Watson — Mon, 29 Dec 2008 17:11:10 -0800

Last week, with the snow storm in Seattle I was able to slip out to the art supply store down the street and picked up some stuff to fix my polaroid wall I put up back in May. It was quick and easy, just some plastic flashing and some spray adhesive, but after the warm summer and the weight from the Polaroids the flashing started to peel away from the wall. I’d been wanting to replace it with something else but just didn’t have the time, or any ideas on what to put up there in its place. I loved the flexibility to be able to put up and replace whatever photos I wanted or recently taken, but obviously the current setup wasn’t working. I thought about following Mark Bixby’s lead and doing something with scrap steel and magnets, but I didn’t really like the little magnet dots and didn’t have any scrap steel lying around.

Luckily, a few months ago my crafty neighbor and architect stopped by and had an idea using some bass wood and some push pins. I loved the idea, but of course work and life got in the way. Fortunately, the snow left me no excuse but to just sit down and do it. I ended up modifying his concept a bit, and am more than happy with the results. I wanted to make sure and document it here just in case someone else is looking for to do something similar. In the end it only took me a few hours it get it all setup, which included about an hour’s worth of scrubbing my walls to get rid of the spray adhesive I’d used on my first failed attempt.

What you’ll need

X 1/16 in. x 1 in. Bass wood
X 1/16 in. x 1/8 in. Bass wood
1 pack of 1/2 in. Wire nails
Glue (I used Sobo craft glue but I’m pretty sure any glue that works on wood would work fine)
Polaroids

Since the bass wood lengths and number of them don’t matter the actual number of strips you’ll need is flexible. The ones I found at the art supply store down the street were 24 in. in length.

Directions

Measure 5/8 in. down from the top of the 1 in. strip and mark each side. This gives makes the visible portion of the polaroid an almost exactly square frame but leaves just a little extra white space to be visually pleasing. It also gives the polaroid enough support so it doesn’t flop forward. Apply the glue to the 1/8 in. strip (I just used my finger) and line up each end to the marks on the 1 in. strip. I just eyeballed keeping this straight but you could mark a line down the back of the piece of wood. Let dry.

Fig. 1 Polaroid wall cross section

When attaching them to the wall just hammer the wire nails through both the 1/8 in. and the 1 in. piece of wood and then the wall. See fig. 1 to see how it all lines up. The first few I did I ended up going a bit to close to the end and they split the 1/8 in. strip a bit as you can see in the photo they still work fine, just but be a bit careful.

They’ve held up great, there’s no messy adhesive on my walls and the photos aren’t bowed out like they were on my previous version.

Design for Now

Tom Watson — Mon, 15 Sep 2008 21:52:07 -0800

When I’m reading through business requirement documents, creative briefs, or high level explanations about what a site should do there’s one line this is almost always there:

“We want the design to be flexible for the future.”

It’s by far my least favorite thing to see. My beef is not that I think sites shouldn’t be flexible for the future (they should!), it’s just that the expectations surrounding this one single line vary so greatly.

There’s no doubt that thinking about the future is vitally important to a business. But I’ve seen countless conversations (about navigation structures, page description diagrams, wireframes, and visual design) get derailed because “we need to think about what might happen in the future”. This should never, ever happen. We should base our discussions on what you know, for certain, today.

Similarly, brainstorming about the future should happen before we start doing design. Otherwise, we run into trouble and the design you end up with will be less effective.

When I read the flexibility line, I can’t help but think the client is trying to cut design costs because they don’t want to have to do a large redesign again in just a few years. This makes some sense (you should be able to add features and tweak the site). But if down the road you want big changes, you’ll need to have another designer take a look at each proposed addition on a case-by-case basis, to figure out how they’ll best work with the overall design.

The bottom line is this: Designing with an eye toward flexibility and the future can be done one of two ways. Either you build a house and leave out a few bricks and some roof tiles, or you build a complete, smaller, starter house that is perfect for your needs now (but which you can build upon later.) In the latter case, you’ve thought briefly about the future, but you’re focused on building the best house for today.

That’s the right way to build out flexibility for the future.

This article was originally posted to the Blue Flavor blog, so please direct your comments and discussion over there and we’ll talk.

Information Architecture Deliverables: Page Description Diagrams

Tom Watson — Fri, 29 Aug 2008 15:42:28 -0800

In the second installment of my Information Architecture Deliverables series, I’m going to talk about one of my favorite (and one of the most tricky) deliverables: the page description diagram. In case you’re not familiar, a page description diagram is a text-based list that explains the importance of content that appears on various pages of a website. Here’s a sample of what one looks like.

One of the main reasons why I love pdd’s is that they effectively remove visual design and layout-based discussions (which should be reserved for the visual design phase of the work) from the IA process. Presenting and discussing only content forces a client to focus on choosing what is and isn’t really important on a given page, helping to communicate their core message.

That said, I’ve found that there are two scenarios in which Page Description Diagrams might not be the best choice. The first occurs with clients who really don’t want to get involved with anything unless it’s visual. For instance, I recently worked with an architecture firm who told me up front that their group was very visual, and that text-only deliverables weren’t going to enable them to provide valuable feedback. For this client, I chose a more visual-based deliverable.

The second scenario occurs when we’re working with web applications or more interactive-type sites, where discussing interactions is key. Interactions are more difficult to portray textually, so Page Description Diagrams often leave important questions unanswered and aren’t the most appropriate for these types of projects.

Aside from these two examples, Page Description Diagrams are an ideal deliverable—especially for content-heavy sites. They’re a great way for the information architect to focus in on the content and its overall importance per page, rather than visual design and layout only.

If you’re not architecting a site with heavy interactivity, I’d highly recommend them as a great way of getting everyone involved and on the same page during the site building process.

This article was originally posted to the Blue Flavor blog, so please direct your comments and discussion over there and we’ll talk.

Information Architecture Deliverables: Site/Navigation Structure

Tom Watson — Tue, 29 Jul 2008 14:47:14 -0800

When I talk about Information Architecture, I don’t want to talk about deliverables. I want to talk about getting people on the same page about what is going to be built or designed. The gist of my job is getting “consensus” (and I don’t mean designing functionality by committee; I mean ensuring that that everyone understands what is going to be built before the development and design happens). Yes, there will always be changes, and yes, agile development can be a great thing. But without some sort of initial blueprint to guide you, the project will flounder around in a visual design and feature development tennis match—on a court without lines or a net. In short, you need a solid plan or you’ll end up with a mess.

So, you need a process for getting people on the same page. In a perfect world a napkin sketch, phone call, and thirty minutes on a write board would be sufficient to give everyone on your project a clear understanding of what’s going to be built, and you’d be ready to move on. But this is a fairy tale. Clearly documenting everything, getting all your stakeholders in the room at once, making time for client feedback, and discussing your work with clients so they see how the site is developing take a lot of time. A whole lot.

Unlike visual design and development, information architecture has a whole slew of deliverables to choose from. Every project has different requirements, so you’ll need a slightly different set of IA deliverables for each one. Whether you’re working with a web application or a more traditional content driven website, for instance, makes a huge difference. And of course, you also have to consider budget and the type of client you’re working with. The problem is that it’s not always clear which deliverables are going to best facilitate getting everyone on the same page. As well, it’s easy to forget that deliverables themselves don’t matter much — it’s understanding that you’re looking for.

I’m going to be writing a series of posts about the deliverables I use and explain why I use them. I’ll begin with one of the most common deliverables, and one I almost always start projects with: the Site/Navigation Structure document.

Traditional content-driven sites and Site/Navigation structures

If you’re not familiar with the Site/Navigation structure document, here’s the gist: It’s basically a set of boxes that outline the general categories, sections, or main navigational items for a site (It is traditionally called a site map). The Site/Navigation structure document is not particularly sexy, but it’s a great way to get people to think in terms of general site navigation and site priorities. It also prompts them to consider the content they have, want and need. I usually try to included the secondary levels of navigation as well (boxes underneath the main navigational boxes) to help provide even more context. I avoid getting into too much cross linking of content, as that tends to get a little more detailed than I want early on in the discussion. In the early stages, I like to focus on main navigational elements and try not to get too bogged down with the details.

One, possibly two rounds of revisions are usually all that’s needed with this deliverable. The beauty of this document is that it’s usually fairly easy to create (although a lot of time is spent looking through content, site, or any additional documents your client has provided) and it’s quick to change. I spend a good amount of time writing up my justification for the site structure with this as well. It’s not a very visual document, so I find it really helps to outline out what I’m thinking in a Basecamp post when I send it over. Depending on the client, I then spend some time either on the phone or reading through their feedback. Then I move on. It’s important not to get too bogged down because remember, it’s a process and these are just being used to document design decisions.

Web applications and Site/Navigation structures

Web applications are a bit trickier when it comes to producing a more page-driven site/navigation structure. I usually try to stick with a similar layout, with larger boxes representing the main navigational elements on the page and smaller boxes underneath representing sub pages. Often, I’ll add in a bit more detail to help show some of the process or interaction happening on some of the interior pages. Without more detail up front here, I find it’s just too general for all that needs to be explained. It’s a bit risky to spend so much time creating and revising initial deliverable like this, but I’ve found that without it, the feedback can be a bit lacking and general.

Overall, the Site/Navigation Structure documents (when done correctly) are a great way to get the conversation going, and of putting a quick but nice-looking deliverable in front of the client. This deliverable also helps make sure that everyone is, for the most part, on the same page before you move on to more specific IA deliverables.

Next up: Page Descriptions Diagrams.

This article was originally posted to the Blue Flavor blog, so please direct your comments and discussion over there and we’ll talk.

Categories vs. Tags

Tom Watson — Tue, 15 Jul 2008 09:42:47 -0800

It might as well be paper or plastic. You step up to the cash register and the checker looks up and asks, “Paper or Plastic?”. If you’re like me, you start over-thinking the question. I’d like to avoid using petroleum products so I should go with paper, but those actually take more energy to produce, but I can use them for my recycling later… Meh, I should just buy some reusable bags and get it over with.

The same types of questions pop into my head when people ask if they should use tags or categories. Tags are easy and quick to add, but they lack the structure and navigability that categories provide. But then, it’s tough to decide which category certain content types belong in.

After far too much internal debate, waffling, and discussion, I know there isn’t one solution I can say is best. But there are a few solid rules you can defer to when thinking about tags and categories, and there’s one solution that I like to use for most of the sites I design.

First, the basics:

Tags are metadata about a post. They’re added keywords or a way to add a little bit more description to a piece of content.
Categories, on the other hand, are more structural and usually used more for navigation. You put a piece of content into a category. You add a tag to a piece of content.

Over the years, I’ve seen these two types of classification systems used interchangeably, often with one masquerading as the other. People want to put a piece of content in multiple categories to help alleviate some of the problems the rigid structure provides, but the biggest issue I notice with these two is not in the set-up phase — it happens in the day-to-day maintenance of content.

For instance, it’s hard to know what category a piece of content should be placed in. You usually have to go and review the list of categories already on the site, decide if it’s worth putting it in one of those, or maybe even decide to add a new category. If the content is being managed by a multitude of people and there isn’t an agreed upon rule set, things can quickly get out of hand—then you’re left with on-the-fly category creation and a serious navigation problem with your site down the road.

Tags have different problems. They’re easy to add, so you’re not stuck with a lot of mental load while writing or trying to add a piece of content, but they’re not very good at providing navigational structure. There’s no thought that goes into all that attached metadata and the typical way of displaying these tags (a tag cloud) is a messy form of navigation.

So what to do?

The easy option is to go with both: You add tags however you see fit and then put the content in pre-set categories and go on your way. In this case, you reap the rewards of both and your bases are covered. It’s not a bad solution, but like I mentioned before it can be pretty taxing on the content management end of things. Not only are you adding metadata via tags; you’re also having to decide on categories.

For most sites I design, I use a combination of the two, but not both separately. While posting and adding content, I do the easier of the two and just add lots of tags. I then create groups of these tags and make categories based on them. I like to call these groups of tags “sections”.

This way, if I want to have a design “section”, I can add tags like grids, color, layout, painting, sketching, etc. And then all the posts that are tagged with one of those items are placed in the appropriate section. If an article that I think should be in a particular category isn’t there, I either add the tag to the article, or add the tag to the section. It’s the best of both worlds.

It’s easy and quick to add tags while writing or posting and flexible when you’re trying to categorize your content.

But why not just use both?

It’s a good question, with a fairly easy answer: maintenance. Adding more content and tags and putting content into categories can make moving things around later a daunting task. Associating the tags with categories lets you move the content items around more easily and gives your sections meta data as well (the tags that are part of that section).

Bottom line

Like I said at the start, there’s no hard and fast rule for these things. Sometimes a site can work well with either both in unison or the way I described here. In the end you have to take a hard look at how you’re hoping to use these two in both your site’s navigation and your internal content management structure.

This article was originally posted to the Blue Flavor blog, so please direct your comments and discussion over there and we’ll talk.

Grey mix

Tom Watson — Fri, 30 May 2008 16:57:59 -0800

In an attempt to keep the good weather here in Seattle to stay I’m releasing the grey mix. Inspired by Sarah’s anti-rain boots this mix is meant to be played whenever you need to bend the weather to your will and get some sunshine. We’ll see if I’m as successful as the anti-rain boots have been.

The mix is starts out with a great Radiohead cover from Damien Rice and then moves into a few older songs I’ve listened to through the years that fit perfectly with the some thick clouds and warm tea. The next few are some new songs that I’ve been listening to recently that aren’t quite as grey, maybe light grey fits better, but they’re definitely grey to me all the same. The last song by Imogen Heap is, in my mind, the perfect ending to a grey mix. Not too dark, ethereal and well, just eery.

Anyway, I hope you like it and here’s to a sunny weekend brought to you by the grey mix.

The grey mix (24.8 MB)

Creep - Damien Rice
Healing Time - Denison Witmer
Between The Bars - Elliott Smith
Sideways - Citizen Cope
The Modern Leper - Frightened Rabbit
Corpus Christi - Clinic
Hide And Seek - Imogen Heap

Personal publishing frameworks

Tom Watson — Mon, 19 May 2008 19:05:16 -0800

After a few comments and now more than a few emails asking me for my Wordpress theme for this site I figured it was high time to explain a bit about how my site works and the concepts behind it.

The idea is a simple one, but with a bit of an over-the-top solution: I just want a personal site that incorporates (go figure) everything I do online (the vast majority of it, anyway). Since new toys pop-up all the time, I want the site to be flexible enough to deal with any new service that I might fancy down the road.

Why go to such trouble?

Blogs aren’t enough. People are tweeting, posting photos to Flickr, adding events to Upcoming, bookmarking to Del.icio.us and Ma.gnolia and generally just “life streaming.” Each of these has their own community that I enjoy participating in, so I don’t want to abandon them with the hope of trying to build an entirely new audience on my own site. The solution is obvious, bring in all my distributed “stuff” from these services to my personal site.

As some of you might know I’ve got an aversion to social networks, at least ones that are all encompassing, walled garden type sites. Facebook, MySpace, they all just seem there to capitalize on my content: I just don’t want one company to represent all of me online. I love the smaller, content-specific ones. I’m a huge fan of Flickr, definitely enjoy Twitter, and Upcoming is useful for events. Each one is tailored to a specific need I have and meets that need just about perfectly.

Instead, I wanted a place that’s my spot on the web, a personal site. No, not something I had to update in addition to all the other services I use, but something that’s updated whenever I update them. I couldn’t handle the limitations of countless javascript widgets either. I realize it’s a decent solution for a lot of people, but to me it’s sort of the half assed attempt to get the stuff in one spot. The widget is the band-aid to this problem: it’s enough to stop the bleeding, but doesn’t really fix the problem.

Django to the rescue

I want true separation of presentation and content, and in order to do that API’s were the way to go. Luckily, my new office-mate, Jeff, was working at the time on just such a system in Django and it was perfect. Before working with Jeff I hadn’t spent more than a few weeks with Django tinkering, but after a few explanations and tutorials I was sold. The entire framework was designed for publishing content, in particular, structured data. And that’s just what all this “stuff” I want to collect is: structured data. My photos, links, status updates, and upcoming events are all being stored out there by these services in nice, organized groups, accessible via API’s. Huzzah!

But why should you care about structured data?

I know, it doesn’t sound appealing: structured data. I doubt it gets many dates, but it’s hot. It’s the same reason many of us care, or at least used to care about web standards: the separation of content and presentation. Poorly structured data hog-ties you to a specific presentation, whereas well-structured data leaves you free to mix-and-match ‘til your heart’s content.

Why not X?

Because I’m tired of hacking. I’ve hacked countless content management systems trying to do what I want, but always only getting “almost there.” I wanted something that’s designed from the ground up to pull in all this data. I didn’t want another blog engine hack, or a tumble log that’s geared towards just tossing the content up as quickly as possible.

Instead, I consider what’s powering this site now to be a personal publishing framework. Not another CMS, but a framework, geared towards the specific purpose of pulling in content from any number of services out there and storing that data locally, in a structured format, so I can display it anyway I see fit. It’s the best of both worlds, community services I can use and participate in, getting all the benefits of their reliability and expertise in handling various content types, but then getting to display and represent the data here on my site to express the myself how I see fit. After all it’s my content.

The future

Honestly, I think this is how all personal sites will eventually end being. Some sort of personal publishing framework that allows you to pull in all your content from a wide array of web services. This site took quite a bit of technical jiggering and a lot of help from Jeff to get it all working, but I see many more tools coming to make this concept a lot easier.

Anyone out there hacking something together to create some sort of personal publishing framework in the interim?

Apple iPhone headphone request

Tom Watson — Fri, 09 May 2008 11:20:34 -0800

Since the iPod’s release people having been bitching about the headphones that have shipped with them. At first, people were stoked for the white and wore them because it was a status thing. I even remember hearing about people getting mugged because people saw the white and knew they had an iPod. Shortly after though people realized they didn’t sound that great, or they simply fell out of their ears because of their “superior” ergonomic qualities.

I understand people’s issues with them, but they’ve always worked great for me. They fit perfectly in my ears, sound good enough, they’re free, and I like the white. Having something fit, out of the box, is such a pleasant surprise. I’m never the default, except when it comes to my ear canal shape apparently.

My only complaint is that they don’t hold up that well. They get dirty, the cords wear easily and I’ve blown out a pair or two running. I’m guessing people don’t talk about this much since they usually just tossed into a drawer shortly after the iPod/iPhone purchase. So, I’m asking, anyone who’s immediately (ear wax is sort of a personal thing) replaced their iPhone headphones with a third party option and wouldn’t mind donating them to me I’d happily take them off your hands. If you’re not local I’ll happily pay for the shipping. I’m just looking for a pair or two so I’ve got a backup.

White buds rule.

Green mix

Tom Watson — Tue, 22 Apr 2008 19:19:11 -0800

Apparently it’s spring. You wouldn’t know it from looking out the window here in Seattle, but that’s not going to stop me from posting the Green mix. I’ll bend the weather to my will I tell you! A bit of green, a bit of spring was the theme. I can’t help but think of budding plants, green grass and if you’re here in the northwest a bit of moss still clinging to the trees.

It starts off with a little song from Simon & Garfunkel during their concert in central park and ends with a great cover Prince cover of Crap Craft Dinner by Hot Chip. This collection is probably my favorite so far, and for those of you following along The National did make a repeat appearance this time around. Green Gloves just worked too well.

As always, let me know what songs scream green to you. I’m always looking for new tunes.

The green mix (32.4 MB)

America - Simon & Garfunkel
Punk as Fuck - American Analog Set
Satellite - Guster
The Great Salt Lake - Band Of Horses
Skinny Love - Bon Iver
Green Gloves - The National
Sweet Marie - The Anniversary
Crap Kraft Dinner - Hot Chip

The Adobe rut

Tom Watson — Thu, 17 Apr 2008 11:55:42 -0800

A few days ago when the the Blue Flavor crew was out having lunch, we started discussing Expression Web and why there’s practically no interest in it at all. None of us have spent much time with EW’s suite of products, but there are good reasons why. The lack of interest can be boiled down to three main obstacles that anyone trying to carve out some space on Adobe Mountain will have to overcome.

1. Inertia

Learning new tools as complicated as Photoshop or Illustrator takes a whole lot of time that, technically speaking, we should not bill to clients. We’re paid to come up with design solutions and to demonstrate our creative problem-solving skills — our tools are merely vehicles that allow us to express those skills in a productive, profitable way.

As well, most seasoned designers are comfortable with their trusty tools and aren’t willing to invest the ten or more hours it takes to produce a design in a new application. If I were fighting this battle, I’d target the new products at younger designers who don’t have years of Adobe keyboard shortcuts under their belts.

2. There’s not a compelling reason why it’s better than the current tools

I’ve seen mile-long feature lists for new products, but I haven’t heard a single designer talk about being able to express his or her ideas more quickly or effectively as a result of using it. The features may be cool, but I want to see the results.

3. Designers are inherently brand whores

This is a big one. Designers create brands, so they’re naturally hyper-sensitive to subtleties of a particular brand’s attributes and reputation. Why else would there an odd obsession with Apple products within the community? I’m as guilty as the next designer, but I’ve accepted this as strictly a part of the web culture.

Take Microsoft, for instance. In my mind, Microsoft’s brand is forever tarnished, in much the same way that Pontiac’s is. Think about it — it doesn’t matter how many cool cars Pontiac produces, they’re still Pontiacs. If I were Microsoft, I’d make a spin-off division with a completely new brand marketed directly at designers. It worked for Xbox, and it might just work for the design community.

Introducing new tools into a saturated market is an uphill battle, but it’s not as if there’s no room at all. I’ve been impressed with a lot of tools built off Apple’s core image that have recently emerged, but I’ve yet to see a product that overcomes all the obstacles I’ve listed here.

It’s rare that a day goes by where I don’t hear someone cursing an Adobe product; and given Adobe’s acquisition of Macromedia, they could really use the competition.

This article was originally posted to the Blue Flavor blog, so please direct your comments and discussion over there and we’ll talk.

Feed adjustment

Tom Watson — Tue, 15 Apr 2008 22:26:33 -0800

I’ve gone ahead and cleaned up and added a few new feeds to T Incorporated. There are now feeds for just about everything, and well, everything that happens on T Incorporated. You can subscribe just to the main blog posts as before, but I’ve also added a links and blog posts combined feed. I’ve also gone through and updated the older feeds for blog posts, links, photos, favorite photos as well as the stream, or everything, feed. I know it can be a bit of a wait between postings but I usually post 3-5 links each day along with commentary if you’re wanting a bit more T Incorporated in your life. You can also comment on my all of my links as well.

There may be a few hiccups, but I think everything is all fixed at this point. I had to change the URLs so if you’re already a subscriber, my apologies, but please do me a favor and unsubscribe and re-subscribe. And if you haven’t subscribed already, what are you waiting for?

Fugly five

Tom Watson — Tue, 08 Apr 2008 17:33:25 -0800

The general consensus in the design community is that new U.S. five is ugly. The 2,500 at the United States Bureau of Engraving and Printing got together and decided to grace our good bill with a giant purple Helvetica in the corner. And then around the same time the Royal Mint shows off their sexy new coins designed by a first time, 26-year old graphic designer named Matthew Dent. For people uninitiated into the design processes this doesn’t make any sense, but for most of us in the thick of it, it’s pretty clear. Designing by committee failed.

Now I don’t want to be too harsh on the fine folks at the Bureau of Engraving and Printing, I’m sure they spent a lot of time working through ideas and it probably took them quite a while to get the design we see today. Obviously I don’t know all that went on, but my guess is the process they went through involved many designers, numerous committees and required the approval of at least four managers. Suggestions were made at each step in the process and eventually designers were left tweaking or just implementing the decisions of others higher up in the approval food chain. It’s been my experience that this process rarely works and this is just one such example.

The other issue where I see things went terribly wrong for our trusty five was with the idea of trying to modify an iconic design. I’m not particularly attached to our old currency but it’s been ubiquitous in my life and it’s a design I’ve come to know and trust. A five, is a five, is a five. Instead of respecting that legacy someone decided, alright, we need new currency for security reasons let’s start from scratch and make something new. No, they decided to go and tack on elements to a design, far after the fact. It’s far more difficult to do this. Adding to an existing design, especially one that isn’t your own, with a large team, is incredibly challenging. Just ask people working on internal teams at large organizations, making changes to a slew of websites.

In the end we’re left with Frankenstein’s monster: one that meets new security needs but is a poor imitation of the original. They should have just started fresh, or even gone with the contest model. Maybe then we would have ended up with something as hot as those Brits.

One Mac or two?

Tom Watson — Tue, 25 Mar 2008 21:31:57 -0800

You’re out with a group of geeks. Maybe it’s SXSW, maybe it’s at a bar after Refresh, maybe it’s a few people out enjoying a baseball game on a beautiful spring day. Okay, that’s going a bit too far, I can’t remember the last time I’ve seen geeks out enjoying a sporting event that isn’t bowling. But you’re out, and you’re talking about something blasé like domestic politics or the Israeli and Palestinian conflict, but inevitably the subject turns to Apple. You start discussing MacBook Pro specs, the new MacBook Air or Cinema display screen sizes. White whine and Stuff White People Like would be so proud. Eventually this discussing leads to that sticky area, no not PCs vs. Macs, no, it’s should you have one Mac or two?

It’s been going on for a long time—people discussing their current setups. Some are enjoying an iMac and a MacBook. Some stick with a Mac Pro and now the Air, and others love the simplicity of their one computer setup of MacBook Pro throw in a Cinema display if you’ve got the extra cash. The combinations seem pretty endless, but what I’ve learned from these conversations is: there really is no “correct configuration”, but that’s never stopped a serious Mac nerd from debating it.

Over the past year and a half or so, I’ve been happy with the configuration I have: a MacBook at work, an iMac at home. I like having the solid “base machine” and the laptop is great for work and allows me to travel lightly. Then, a few months back, work bought me a beautiful 24” iMac, so I took my MacBook home, using it and my iMac there with the beautiful beast sitting on my desk at work.

The setup works just fine, but after a few months of being not quite synced up, I realize three Macs are just way too many, and after some internal debate, I’m selling the MacBook and iMac, in favor of MacBook Pro at home.

I’ve pretty much made up my mind, but I’m curious what configurations everyone else out there is running and why? What’s your setup and why do you love it?

Problems, not features

Tom Watson — Mon, 17 Mar 2008 10:18:18 -0800

Clients have proposals. They come in all sizes and shapes, from formal RFPs to an idea hastily sketched on a back of a napkin. But there is one thing they all have in common: Requirements. And each of those requirements almost always calls for a feature. Like a blog. Tagging. sIFR. Some AJAX. These days, even a site that sells toothpicks seems to need a rotating AJAX-powered image gallery.

Often times, we web pros spring into action when confronted with this dilemma. We draft estimates, outline how all these “necessary” features might fit within a client’s budget, and use our design and development skills to build something that doesn’t look like a cobbled-together mishmash.

I understand why almost every client requests these intricate features. They see a site that does something they really like. They love how you can zoom in on Google maps or drag and drop things into a shopping cart, for example. It’s easy to make that leap from “they do that” to “we should do that, too.” Unfortunately, it’s also a fundamentally a flawed approach.

Designing for Features

When you’re confronted with a list of features, you immediately lose focus on the bigger picture. You try to accommodate all of this functionality without asking the most important question: Is it really necessary? So often we treat a particular feature set as our final goal. Instead, we should focus on problem solving. Focus on the problems first and the right features will follow.

Wasting Development Resources

Another unfortunate side effect of features-driven design is spending development resources in all the wrong places. Drag and drop may be cool, but “cool” doesn’t solve problems. If you haven’t spent the necessary time dealing with UI/IA design challenges you’re going to waste resources backtracking in the development phase. So draft the blueprints first, and then start building. Or inevitably you’ll end up with…

Scope Creep

Without that initial blueprint it’s far too easy to start tossing in a new feature during the project. Without the reference document, one feature becomes two, two become three, and so on—until you’re not focused on the problem at all. Instead, you’re focused entirely on (you guessed it) more features. But the cycle can easily be stopped if you stick to your initial plan and just say no.

Why Is It So Hard?

The web community loves new features and new technology. New is exciting. New is fun. New is challenging. And when clients come to you wanting something new, their enthusiasm can be really contagious. How many times can you remember hearing someone say “Oh, that’ll be fun!” when he or she learns about some new feature that “needs” to be in a site?

You want to keep your clients engaged in the work, but if they’re attached to a specific feature, convincing them they don’t really need it can be extremely difficult. Often, it feels easier to add that feature than to try to change your clients’ minds. But that’s a trap we all need to avoid.

Avoiding the Trap

Encourage clients to bring you a list of problems, not features. They’ve hired you to create this website or other web “thing”, and they’re looking for your expertise in solving problems. You were not hired as an expert in bells and whistles-building.
Listen. After all, clients know their business better then you do. But you know the web. Once you truly understand their problems, you can focus on adding features that really work.
Use the budget to your advantage. Clients always want a lot for as little as possible. Explain that by focusing on solving problems, they can accomplish their bottom-line objectives for less money and in less time. Additional features can always come later.
Treat features like a toolbox, not a roadmap. Decide what problems you want to solve, then consult your features tool kit to help you succeed.

The Bottom Line

Features aren’t bad, but being feature-centric is. As web professionals, we should tackle web work with a “problems first, features second” perspective. We’ve all learned how to keep the user at the forefront of our minds. Now we need to learn how to find the right features to solve their problems.

This article was originally posted to the Blue Flavor blog, so please direct your comments and discussion over there and we’ll talk.

Polaroid breakfast

Tom Watson — Wed, 05 Mar 2008 11:21:03 -0800

For all you polaroid geeks out there attending SXSW a few of us are going to be having a breakfast at Katzs Deli at 9:00 a.m. Saturday March 8th. It’s right on 6th street and has received 5 out of 5 golden eggs while been nominated for the best bargin breakfast in Austin by Mr. Breakfast. I’ve recently enacted a strict policy where I won’t eat anywhere that doesn’t receive 4+ golden eggs, so this place made the cut.

At this point it’s just a couple of us so we haven’t made any sort of reservations, but breakfast topics will likely include cursing Polaroid for discontinuing production of their film to why the SX-70 is so much sexier then the SLR 680 SE. Mark Bixby will also be there to tell us how he got up the nerve to permanently modify his cameras. I know it’s early for SXSW standards but most of you die hards should be up taking pictures of the sunrise anyway.

If you think you might want to attend just leave a comment below. If you can’t make it but still want to chat about the dire polaroid film situation just come up and grab me. I’ll be the tall guy with the camera.

Update: I realized after the fact that it might have sounded like you needed a polaroid camera to attend, and that wasn’t my intention at all. All you need is a good solid interest in polaroids and a working alarm clock!