Brian Crescimanno

Jonathan Snook recently posted an interesting article titled Old Browsers: Do they still exist that explores the often hotly-debated topic of when it's ok to pretend a legacy browser no longer exists.

My pragmatism comes into play, like that little devil and angel on my shoulders telling me each side of the story. The fact is, these are old browsers. Why haven't these people upgraded? Why are all these people still using Firefox 2? So what if it's a little (or a lot) broken for them. They should upgrade.

I think most of us as designers and developers would agree with that sentiment; they should upgrade!

The problem, as is often the case, comes from outside the design and engineering teams responsible for building these sites.  It comes from business folks and QA teams that truly believe that "support" means 100% equivalency across browsers.  Any designer or developer will tell you it's a pipe dream and inevitably some concessions are made--but I'd be very interested to hear how much money is spent every year in this industry on trying to come as close as possible to identical cross-browser experiences.  This problem can be defined simply as a lack of consensus on the definition of "support."

My classic argument has always been:

Cross-browser consistency is nice--but in no way critical.  The vast majority of any audience is only ever going to see your site in one browser so let's instead of striving for identical experience let's strive for working experience.

The core of the problem is that we, as stakeholders in our projects, are by definition not users.  As a stakeholder, we open the site in multiple browsers to test, we know the expeirence we want to deliver--and it's easy to become frustrated when one browser behaves differently.

But to focus on the differences across browser is to ingore the truth: Your users aren't going to see your site in every browser.   Users will experience your site in their chosen browser and any feature that is inaccessible in that browser will simply not exist in their eyes.  It's called Progressive Enhancement, and its not a revolutionary concept.

It is, however, what can allow us to deliver a consistently working and functional experience to all users while still providing the "bells and whistles" to those who stay up to date.

Macro-level Support, that is, support for a site, is not about cross-browser consistency--it's about cross-browser functionality.  It's an important distinction.

Technorati: design webdesign browsers

Yesterday I was evaluating early design comps for a new project just getting underway here at AutoTrader.com and I fell into the trap of what I call Designing for Requirements, Not Objectives.

Neil and I were discussing the new versions of the comps that have surfaced since we returned from San Francisco and the improvements around them--at least, some of them.  With one comp in particular, Neil began to repeat the phrase "yeah, but it's not poppin' off!"  and the only argument I seemed to be able to formulate in reply was "True, but it's doing this to meet business requirement x."  After a few minutes of this, I was forced to concede the point that Neil was right and I was arguing from a hollow perspective.  Ask anyone who knows both of us and they'll tell you that Neil has taken to using me as affirmation--as in, "Oh you know I must be right if Crescimanno is agreeing with me!"  Long story short, we disagree often--if only as an exercise to keep the other thinking on the right path.

I'd fallen into the trap of seeing the design purely as a function of meeting the business requirements that have been defined for the project and failed to evaluate it based on the stated project objectives.  While the design presented did a fantastic job of meeting all of the business rules and requirements that had been created around it, the design completely fails to accomplish the primary goal of the project.  When there are many, many forces pulling projects in many, many directions, it's easy to get lost in things like business requirements, advertising specs, reporting, and other measures and to lose sight of the reason the project exists in the first place. It happened to me here; it's happened to many others in the past, and it will likely happen to others in the future.

In design, we often have to cater to multiple, often very disparate groups.  That's certainly the case in this project, and while this design caters to one group quite well--it doesn't serve the other at all.

Remember, when designing anything:

1. Take into account all of your audiences and do your best to serve all of them (recognizing that no one perfect solution for all of them at once exists)
2. Always keep the primary objectives of the project at the forefront of the design--and fit the business requirements within that framework.

At the end of the day, you can satisfy every business requirement in the specs--but if your design fails to meet it's objectives, it won't be successful.

Technorati: Design