I Saw What You Did There, Facebook: The Facebook chat promotion as it appears on the right-hand side of a user’s homepage. Personal tidbits obscured to protect the innocent.

Removing cues to close or abandon interaction flows is something that needs to be undertaken with great care and respect for the user’s initial intent. When used in complex, multi-part forms such as retail check-outs, removing site chrome and “links out” can help focus attention and aid in the completion of a task the user has explicitly voiced a desire to do.

But when used to sculpt the flow of traffic without the user’s say-so, you risk engendering confusion and suspicion. Hence, I typically advise clients against this sort of thing. Sure, you’ll get higher sign-up numbers, but at what cost? Many of the folks who wind up making it through the process will be doing so out of ignorance, and quite a few won’t be terribly happy about it once they arrive on the other side.

Every so often something rolls around that makes the field feel new, and for me, this is most definitely it. Moreover, I hope it marks the beginning of a renewed awareness—and embrace of—the inherent fluidity of the Web.

There’s been some great discussion on the topic of Responsive Web Design since Ethan first introduced us to it on A List Apart, and it’s been reminding me about our history. We arrived at the current, relatively rigid state of Web design out of a desire to impose order on a medium that began life as chaotic and wildly inarticulate (from a designer’s perspective). The Web was fluid by nature, but the tools were desperately primitive. The only way to keep the limitations and randomness from impeding your content was to lock down one side of the equation. We couldn’t control the browsers, so we bolted down the designs.

But the game has changed. Browsers have gotten, dare I say, pretty damn good. And a whole host of robust tools and devices have arrived that allow users to passively view, actively consume, or deliberately repurpose as they see fit. The fantasy we once coveted, of a perfectly reproducible canvas painted in pixels, has given way to a breathing reality mitigated by circumstance and conditions we will not be able to anticipate.

And this book points the way.

Today I’m officially launching a little utility I’ve been tinkering with for awhile. Meet Gridulator. As you may have guessed, it’s got something to do with grids.

Tell Gridulator your layout width and the number of columns you want, and it’ll spit back all the possible grids that have nice, round integers. Just the thing for pixel-based designfolk. There are inline previews, courtesy of the canvas element, and when you’re all set Gridulator can crank out full-size PNGs for you, ready for use in your CSS, Photoshop docs, or what have you. And there’s full keyboard control for you snazzy power users.

An Audience of One

I built Gridulator because I wasn’t finding any solutions well-suited to the way I work with grids in my design projects. Most of the existing desktop grid calculators are geared heavily towards print. (Widths like 58.766666666 aren’t exactly helpful to a Web designer.) And Photoshop still lacks robust tools for choosing, building, and editing grids in projects (as others have covered with due eloquence and care).

I can’t change Photoshop, but what I can do is make the act of creating a grid for Web projects a little less tasking—enough so to allow for quick and care-free experimentation. I wanted something that would make the act of creating a grid so easy as to make the output nearly disposable. No more cringing at the thought of rearranging umpteen gazillion guides in Photoshop. And no more fretting the math wouldn’t add up in PixelLand.

The result is an app that’s intended to do a very specific thing in a very specific way, and to do it as fast as possible. In fact, it’s so specific that I originally only built it for myself. But as things took shape I thought others might have use for it as well. (One designer I know actually punched me in the shoulder after seeing a working copy and hearing that I hadn’t built a public version. It’s okay, I forgive them.)

I hope you like it too. Now go forth and gridulate!

Stuntbox, my sometimes hobbyhorse, is now Stuntbox, LLC. I am officially in the design consulting business.

It started about two years ago, as a faint but undeniable itch, somewhere in the far back of my mind. “You have to do this,” it kept telling me. I kept putting it aside. Halfway through a stint running the interactive design department of one of the most (insert standard PR department superlative here) business publications in the world, it’s easy to distract yourself with the minutiae of daily humdrum, ignoring what better instincts are shouting. “Yeah, yeah,” I thought, “Someday. I know. I really should. I know! Now let me jam out this memo before the 2pm shows up.”

Fortunately for me, I caught a lucky break. I got laid off.

Yeah, I know what you might be thinking. Cognitive dissonance, lemons, lemonade, and some such blah blah. But in my case, believe me when I say the only genuine adversity was holding back the goofball grin during that most special of HR sessions. I’d known for a long time what the next step should be for me, personally and professionally. And I was being handed a corporate subsidy to get busy doing exactly that. The certain and unshakable notion that found purchase in my brain all those months before was being tossed the keys to the family hot rod, no questions asked, no curfew. So let’s get going, shall we?

For now, I’ll be sticking to what I do best, design and creative direction for the Web, with a bit of client-side code thrown in to keep things zesty. Have a need for something like that? Drop me a line, I’d love to hear from you. We might be the perfect fit for each other.

We now pause for a brief moment of design reflection.

Consider the following screenshots. The first of the BusinessWeek.com reader comment navigation as I originally designed it (eons ago, it now seems)…

…and the latter of how it appeared the other day when my boss tweeted about a story that’s garnered a whopping 3,000 comments and counting.

Ouch.

As originally envisioned, the design accommodated about 200 or so comments before Very Bad Things started floating the user’s way. There was a time—hefty traffic reports in hand—when that was above and beyond. Pants with two extra inches at the waist.

Clearly we’ve packed on some pounds since then.

Bend Me, Shape Me

How your designs scale with use is one of those things you need to diligently revisit and tweak as products mature. You can’t realistically account for all eventualities at the outset. That brand of clairvoyance eludes even the best of us. But you can plot out probable outcomes and leave hooks behind for those rainy design days somewhere on down the line. (And obviously some of those hooks need tugging on in this case.)

But remember, you need to return again and again, to ensure yesterday’s spacious accommodations haven’t turned into today’s teeming flophouse.

Actually, if you’ve done it right, you never left in the first place.

If you’ve been to BusinessWeek.com lately, you may have noticed our article pages sporting some nifty new functionality. One of the first fruits of our partnership with LinkedIn, we’ve officially taken the wraps off the LinkedIn Company Insider tool.

Now a quick click inside our articles tells you if you’re connected to folks at companies in the news. Reading a BusinessWeek story about Ford’s effort to sell Jaguar? Click. Pop. Look, Ma! Turns out you’re connected to 8 people at Ford—through folks you already know on LinkedIn.

I’m jazzed about this not just because it showcases the mighty network effect of LinkedIn right where our users benefit the most from it, but also because it’s an article tool that’s gloriously contextual. The results you get spring directly from the specific news you’re reading.

The Usual Suspects

Let’s face it, tons of news sites out there sport a box, zone, region or seeming jimjam somewhere on their articles that’s chock full of “article tools”. It’s pretty much obligatory. These are the links that “do something” with what you’re reading. But the options haven’t shown much in the way of new thinking for years—to say nothing of being truly compelling. A link to print. A link to e-mail. A link to share on the Web 2.0 flavor of the month. Zzzzzzzz…

It’s not that these items don’t serve a purpose. It just bothers me intensely that these tools typically don’t affect or interact with the content in terribly meaningful ways.

Well, consider this our little effort to shake off some of that dogmatic dust and get folks thinking about these tools again.

Savoir Faire, Everywhere

The tool itself is added via the DOM, which is worth noting for those of you out there that are (or aren’t yet) hip to Web Standards. When it came time to to do the deed and flip the big switch, all that was needed was a change to a single script file to add this feature to thousands of articles on BusinessWeek.com—past, present, and future. And by “thousands” I mean, “all of them.”

That’s huge. No Maalox moments charting CMS changes. No heinous text grinds. And no compromising on showing new features on some pages and not others. All this equals time and money saved (and made), in more ways than one. If you’re not clueful yet, do yourself a favor and spend a little quality time with folks that can help you out. If this exercise proves one thing, it’s that Web Standards are far more than a hobbyist’s pursuit—they’re a competitive business edge.

But that’s enough talk for now. Go check out the new tool and have some fun with your soon-to-be-expanding network!

I’m a big fan of the phrase, “eat your own cooking”.

As a Web designer you should be doing exactly that—using the things you make. (This of course applies to just about any creative endeavor, from bridge building to cake baking.) It speaks volumes about the quality and relevance of a product if its producers are also enthusiastic consumers.

Cognitive dissonance is equally revealing. You wouldn’t trust a four star chef that serves Cheez Whiz at his home table. You wouldn’t listen to an addiction counselor who sneaks out to score smack. So why, oh why, would you deal with a “tech company” that has a train wreck for an intranet?

Standard(s) Complaint

The vast majority of the company intranets I’ve seen in my travels have ranged in quality from the affably feeble to the criminally negligent. None has ever approached anything a sane person would call excellent. Not even on a good day.

They have been used as a pliable excuse to perpetrate all manner of horrid, insipid, flat-out unprofessional web work. Bereft both of standards awareness and common courtesy for the poor souls forced to inhabit them. They are clumsy oafs built on two left feet, stumbling about, making a mockery of accessibility and usable design while they smash the china and wreck the furniture.

Enough, I say.

Standard(s) Argument

The enabling phrase for all this folly typically sounds something like, “but this is for an intranet,” and it’s usually whipped out in the thick of some misguided conversation about Web Standards. The speaker assumes that because Company X has “standardized” on Browser Y, they can conveniently toss Web Standards out the window. Let’s all chug some company Kool Aid and call it a day!

Not so fast there, Sparky. I’ve got news for you: It’s a convenient theory, but it falls to pieces in practice.

Given a large enough ecosystem (ie, more than one user), you will never be able to predict your audience with 100% certainty, let alone control them. Single browser environments are both unworkable and, more importantly, illusory. Really. Even within company walls. And the bigger the audience (ie, the company) the more that 100% figure will seem like a distant dream. Give that number a nice, warm hug then kiss it goodbye—you’ll never see it again.

Intranet, Heal Thyself

The bottom line is that companies need to stop fouling their nests with these relics. There’s more than enough time and money to be saved by writing to standards to pay back the effort many times over. The sooner this is realized at all levels the sooner the corporate funds draining away towards browser “deployment and enforcement” programs can be reassigned to something more useful.

Like, say, free coffee.

“Stand in line? What are you crazy? I’m not standing in line.”

Eight hours later, I was standing in line. (Oops.)

Not so much standing as strolling, actually. Morbid curiosity got the better of me by the time I left the office for the weekend, and I found myself walking up 5th Avenue to take a gander at all the hubbub. I was pretty stunned to arrive on the scene a few hours after launch to find a less-than-five-minute line. Five minutes to queue up and charge through the double-file gauntlet of Apple Store employees cheering folks on at the door. “Oh, hey, what the heck…”

Mere moments later I reemerged, clutching my quarry in it’s slick satin finish bag, palms sweaty like a bad prom date.

I’ll spare the nitty gritty product review details. Suffice it to say it’s tremendously damn good. Like, “lives up to the hype” good. In fact, after a full weekend of usage, I’ll go so far as to declare the iPhone the best consumer electronics device I’ve ever purchased. Hands down. Full stop. (Note to Ed Colligan: Apple didn’t just walk in—they broke down the door, punched you in the face and stole your girlfriend on the way out.)

Like it or not it’s going to have a noticeable influence on the market, so affected parties would do well to come to grips with that fact sooner rather than later.

A Call to Action

And that’s precisely where the Web design and development community comes in.

There’s been no shortage of gnashing of teeth and tearing of beards over the SDK issue. Want to write a “native app” for the iPhone, some Cocoa goodness all your own? Sorry kids, it’s closed. (For now at least.) Adam Greenfield even goes so far as to comment, “you cannot make culture with this device.” He’s got a point.

But this time the closed model is hugely asymptotic: The iPhone is a full-on consumer of standards in every regard. Web Standards, networking standards, file standards, you name it. The SDK is a non-SDK: Make solid websites using acknowledged best practices and the iPhone well love them up.

So here’s our chance, Webfolk. Home court advantage is officially ours. Apple just dropped the sexiest client imaginable right in our laps, complete with oodles of free publicity the likes of which presidential candidates and washed up child actors only dream about. It’s a gift. A beautiful, beautiful gift for people who make websites. This is an opportunity that needs to be grabbed with both hands.

It’s time to get to work.

It may sound odd, but I’m really not sold on how most news sites are currently using video. At best the topic engenders me with a mild sort of ambivalence: “Meh, that’s nice.” These days my typical reaction to gee-whiz embedded video doodads in article pages is to ignore them. It’s a pathological habit caused by subtle nagging issues. I think we can, and should, do better.

What it really boils down to is a forced rate of consumption.

Force Feeding

When I’m reading a news article I can instantly and effortlessly shift from attentive reading to scanning. I can vary the rate of consumption to suit my needs, at any moment and without difficulty. Text is conducive to this. That’s paramount in news/editorial environments, where the value proposition is all about timely information exchange. As a user I can choose to be more or less engaged as the situation merits. I can choose to sacrifice depth for speed (or vice versa) whenever I darn well feel like it—and still get what I need.

I can’t do that with video. At least not in its current incarnations.

Video forces full engagement on its own terms. The time it takes to watch the video is the time it takes to watch the video. Sure, you can try speeding it up (in a rare few applications) or scrubbing around with the playhead, but both are poor analogs to scanning text. With most videos the best you can hope for is a passing idea of context, maybe a notion of tone. (Imagine jogging around your standard talking head news video. Still worse, voiceover scenes.) And both methods require too much fiddling on the user’s part anyway.

A (Few) Modest Proposal(s)

One solution might be what I call, for lack of a better term, “scanning captions”. Imagine if when you clicked on the playhead (or used a keyboard shortcut) and began scrubbing, a text overlay with a few words instantly appeared, and updated as you moved around, quickly telegraphing what’s going on in the video during that particular time span. Essentially these are just captions that activate automatically when scrubbing, but with much more abstract text. Not much—just enough to convey context.

Or you could take those same captions and place them alongside the video as segment names, highlighting the current one and letting the user jump to to any of them with a click.

These are just some off-the-cuff ideas I sketched out in a few minutes this afternoon. The point is it wouldn’t take a whole lot to offer a more genuinely useful experience to the user.

Stay Tuned

Maybe I’m splitting hairs with all of this. I hate to drag out the old cliché, but I’m definitely not advocating throwing the baby out with the bathwater. Yes, video is a useful medium in its own right. Yes, we should keep using it. But until some of these little nits are worked out it will probably never be quite as rich (and humane) a resource as we hope.