Facebook confirmed last April it has no less than 200 million users worldwide (and every indication is that number has grown since then). Roll that over for a moment.

Now consider the comments left by those lost souls on the ReadWriteWeb article who were genuinely seeking to log in to their Facebook accounts. (I say “genuinely” because there’s clearly some leg-pulling going on as the comments get out of hand.) How many comments on that page from users truly in distress? 200 or so? Okay.

So, just to keep things conservative, let’s say that only 5% of the “confused” users coming to this page actually took the time to leave a comment. A reasonable rate for a large-scale site (based on my own anecdotal experience) and well within the law of the vital few (aka, “the 80/20 rule”). What’s that make? 4,000 frustrated users. Wow, that seems like a lot. But hold on a second…

That’s 0.002% of Facebook’s confirmed user base.

A mere two thousandths of a single percent. Even if you run the tip-of-the-iceberg scenario and up the comments left to 500 while simultaneously dialing down the response rate to 1%, you only come back with 0.025%. A quarter of a hundredth of a single percent of Facebook’s community.

This is all to say—depending on how you like to run the numbers—that this may barely qualify as a statistically significant event. Act accordingly.

Anyone that’s stepped into the blast radius of a major redesign can tell you a thing or two about typical user reactions. From riding the bomb Slim Pickens-style to lab-coat-and-safety-goggles observation, I’ve weathered my share. Make a fundamental change to an existing product and reaction tends towards the swift and merciless.

Turn & Face the Strain

In every redesign I’ve ever been involved with user responses have followed a predictable pattern. You can group them into two broad categories: Negatives and Positives. (No creativity here—they’re exactly what they sound like.) Negatives tell you how much your update pulls a serious vacuum. Positives testify that you’re the bee’s knees. Both come from self-selecting users, since contact requires some kind of effort. (No matter how small—it’s what highfalutin types call a “barrier to entry”.) Kicking in the moment you pull back the curtain on your zippy new gewgaw, it looks something like this:

Quantity of positive and negative user reactions over time.

Almost instantly there’s the glut of reactionary feedback—the Who Moved My Cheese? set. Glean what you can from these comments, look for common threads, but remember not to let that five-hundredth “WTF?! Ur new design iS teh suck,” e-mail get you down. That’s the important bit. As designers, developers, and all around “Builders of the Interwebs” we pour or hearts and souls into our projects. (At least if you’re like me you do.) Even ironclad stalwarts can’t help but have their outlook dimmed a bit by that first feedback wave.

Stick it out though and—if you’ve done your job well—you’ll be through the squall, sitting pretty at the other end of the graph soon enough. Eventually the rest of the crowd chimes in. And the remaining negative comments shed their emotional edge, taking on a more constructive character.

Keep the wheat, lose the chaff. Quickly, lest you stew in it.

Something in the Blood

Earlier today I got to wondering what makes the Negatives so vocal compared to their Positive peers. Even when your audience research finds nothing but giddy users you don’t hear from them much. But even small sets of Negatives don’t have trouble making their presence known.

During an interesting chat Chris Fahey set me on the right track by pointing out something I’d overlooked: Negatives want to affect change, Positives are confirming assent. I hadn’t thought of it that way before, but he’s absolutely right, and it explains a lot about their respective behavior. Negatives have the motivation to act since they want something done. Positives stay mum because, ultimately, they want nothing done.

Dear Adobe:

Knock it off.

It’s no picnic writing software updaters for an ever sprawling empire of code. Sure. Mistakes are made. Granted. But hijacking an automatic update to install a plugin I never asked for, don’t want, and have no way of opting out of (and throwing me off my browser session to boot)? That’s software update rape.

Until I tell you otherwise, what happens in my browser is my business, not yours. Get thy plugin from out my browser, and take thy form from off my desktop.

Extradition Proceedings

If you’ve updated Acrobat and find your copy of Safari likewise commandeered, you can slap a muzzle on the interloper by chasing down the following maze: Acrobat menu > Preferences… > Internet > Web Browser Options.

Uncheck “Display PDF in browser using”. (Oh, and while we’re at it Adobe, don’t use a dropdown box when you’re only giving the user one option.)

For good measure, uncheck “Check browser settings when starting Acrobat” to keep it from nagging you to turn the plugin back on again (until Adobe sneaks in and does it themselves during the next software update, that is.)

This will get you back using the much, much faster Preview app for viewing PDFs in Safari. Unfortunately it doesn’t mean it’s going to stay that way the next time an Adobe updater comes bouncing your way. For shame.

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.

The phone is ringing again. When I pick it up, the owner of the voice in my ear is clearly at his wit’s end. He’s not just mad at his computer, he’s pissed at his computer.

Any designer could benefit from a stint in tech support. The in-the-trenches view of user behavior, along with an audience close enough to take a swing and actually connect, is priceless. Lessons meted out at the hands of Mother Experience. “No, toasters don’t make great bathtub accessories. Ask us how we know.”

Which always takes me back to this memory from an office far, far away, during a distant, earlier epoch of my life.

Gimme Input

In his office, faced with the offending machine, we begin The Assessment.

No matter where he clicks, a contextual menu is popping up. Plain old single-button mouse connected to a perfectly innocent looking Mac. Angry jabs at the mouse ensue as he demonstrates. Click—pop, a menu on the desktop. Click—pop, another menu on the desktop.

I’m standing just to the side of his desk, frozen in place, mouth hanging ever so slightly agape. Before my mind could even begin it’s customary scroll through the exotic points-of-failure checklist, the eyes had done a scan of the scene and returned back with a full report. I’m still standing where that report halted me.

Really? Another quick glance, just to be sure. Yes… really.

An awkward moment passes.

I lean forward, and with both hands gingerly pick up the book that’s sitting on the edge of his keyboard—plunked directly on top of the Control key.

These programs like to waste my time—or at least that’s what it feels like.

I’ve been using the new Adobe CS3 applications full-time for a little over a week now, at home and the office. The change to fast, stable Universal Binaries is a welcome one, as are several of the more subtle tool refinements. But there’s one new addition that punches me in the eye every time I see it.

That damn fade.

Cue Transition

For those of you already using a CS3 app, you know what I’m talking about. When you make one of the new applications active the entire program UI fades into view over the course of a quarter of a second or so.

Someone thought this was slick. Someone thought this was pretty. Someone was fairly misguided.

Pause for Effect(s): Photoshop makes its dramatic entrance.

Ill-considered UI fluff like this makes me want to run for my copy of The Humane Interface and wave it about wildly. It’s not a question of aesthetics. It’s a question of perceived performance.

All this fade does is increase the time I have to wait for the application to become active, and therefore usable. Sure it only takes a quarter of a second, but users in heavy production environments (arguably Adobe’s core) switch back and forth between these apps hundreds, maybe thousands, of times a day. What starts out as an annoying stutter compounds to steal minutes out of every day. It doesn’t matter if the applications are screaming speed demons chockablock with fastidiously optimized code—they built a speed bump right outside the front door.

The subconscious is being trained to fold its arms and tap its foot every time you click, tab or otherwise stumble your way into Adobeland. Somewhere a neuron is saying, “Damn it, I was in the middle of a flow there.”

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.

You’re joking, right?

Any attempt to hit refresh, type in a new URL, or use the browser’s back button in Safari summons forth this little nugget of pure JavaScript evil. (You won’t see this at all in Mac Firefox because, well, the site simply doesn’t load in that joint.)

Let me say this loud and clear: Never, ever do this. Ever.

I seriously had to go back to the article and check that this was indeed a “new” site, because for a second there you could have easily fooled me into thinking we were partying like it’s 1999.

Scan down the site a little farther and you’ll find this other precious bit of “Was it good for you?” neediness.

Sorry Soapbox, but I’ve had better.

Let’s be honest. As designers most of us would prefer it if ads just went away. It’s okay, you can admit it. They’re the unwanted stepchildren of the web design world and we all know it.

But for those of us that work on sites that depend at least in part on advertising for a chunk of their revenue, sites like BusinessWeek, ads are a sober reality. Get used to it. Ads put food on the table and staff in your chairs. It may not be all sunshine and lollipops sometimes, but it behooves you to learn how to design with them in mind.

Don’t Be a Slumlord

As we’ve been updating our design I’ve made a point of thinking of our ads like real estate. No one wants to buy a timeshare in the ghetto.

Keeping that metaphor in mind and discussing it openly we were able to do the unthinkable with the new homepage and story page designs—remove ad positions. By axing cluttered ads not only were we able to trade up to larger sizes (more dollars), we also increased the overall value of our “neighborhood”. Not cramming an ad into every crevice of whitespace gives you the opportunity to lay each one out appropriately and ensure it hews to the visual rhythm of the site. Just like your content elements. Advertisers notice their ads aren’t locked in mortal combat with each other, competing for the user’s attention, and they appreciate it. People feel a lot better about forking over their bucks for property in the good part of town.

Just as important, being able to discuss ads internally using these kinds of terms kept us from falling into the classic “us-versus-them” trap. (You know the one I’m talking about. It goes something like this: “All you suits do is screw up the site!” “You artsy types don’t know how to run a business!” And so on.) We were all just folks in a room trying to figure out how to improve our community.

Out Here in the Fields

Then there’s the small matter of implementation. Basically, ads make their way onto the site through good old-fashioned JavaScript calls scattered throughout the markup. The actual content pulled in by these calls is created by a variety of third parties and their sundry partners. And partners of partners. And partners of partners of partners. You get the idea. All this makes for a pretty wide variety of code quality. Another fact of life that there’s just no getting around. Some ads are just dandy, and some are… well…

Some suck. Hard.

What’s a DOM maven to do when every include and their brother calls window.onload?

Consult the Rhino

First off, Simon Willison’s excellent addLoadEvent is out the window. Because the ad calls happen late in the markup, after our own DOM scripts have been called in the head, any ad that stakes a claim to window.onload obliterates addLoadEvent. All that’s left is smoke and ashes. Too bad. We needed some kind of event listener.

And then sweet serendipity struck.

Just as I was getting ready to hunker down for a long night of pounding out a listener from scratch the fifth edition of David Flanagan’s seminal JavaScript: The Definitive Guide dropped.

If you’re still knocking around with a trusty dog-eared fourth edition do yourself a favor and pick up the refresh. It’s worth it. Besides smartly consolidating the different client-side reference sections it adds a handy helping of new goodness. Example? A robust onload event listener. Standing there in the bookstore I pretty much randomly flipped to Flanagan’s runOnLoad (page 434, example 17-7) and there was the answer winking up at me. Thank you, Mr. Flanagan. So far its handled everything we’ve thrown at it on BusinessWeek.com without complaint.

As of late there’s been some fresh discussion about cracking the window.onload nut in new ways. It’s clear this is anything but a done deal and that’s a Good Thing. The upshot? Even when you’re serving up all manner of thorny, unpredictable ads and partner content you can still be hip to Web Standards and the DOM. Even the biggest, craziest commercial sites no longer have any excuse.

You can have your design, ads and DOM, and eat them too.