Facebook states that its mission is to make the world a more open and connected place, yet this isn’t the exclusive domain of Facebook, it’s a consequence of the open network it’s built on — the web. Whilst social networks have made it easier for people to communicate online, Facebook is attempting to go further by deeply integrating its closed, proprietary network into the fabric of the web. With products like Connect, Social Plugins and OpenGraph, Facebook has become a parasite, suffocating the platform that hosts it.

A well written and scathing polemic by Paul Robert Lloyd. I found myself agreeing with most of this, but one of the last paragraphs is perhaps just a tad much:

Now Facebook is hoovering up many of the best designers in our industry. As new features continue to encourage users to hand over more personal information, its designers have become devil’s advocates. Much like producing advertising campaigns for cigarette companies, working for Facebook has become an ethically questionable career move.

Ethics in design is a difficult topic, but I think this might be a bit of a stretch – it’s not like Facebook is killing millions of people or enslaving millions more with its highly addictive… Wait. Yeah, I guess I can see some parallels there after all. Still.

[...]The last point, rich advertising, is another artifact of the web ad glut. With sites filled with with crappy ads, advertisers pushed for attention-grabbing animated “take-overs” just as web sites started moving away from the balky browser-crashing Flash animations and toward simple, direct design that creates a connection with customers. We’ll see the crap fade away as soon as more adaptive formats are proven, the bankrupt web model is discarded, design starts favoring the users.

Couldn’t agree more. An excellent article from Roger Black in 2 parts (here’s part 1).

I was there because I just wanted to read something. Words. Black text on a white background, more-or-less. And what I saw — at a professional publication, a site with the purpose of giving people something good to read — was just about the farthest thing from readable.

I feel the exact same way: the average reading experience on the internet has gotten worse – if it wasn’t for tools like Reeder, Instapaper or Safari’s Reader mode I don’t think I’d read as much online content as I do now.

And don’t get me started on the absurdity of the myriad of “like-”, “tweet-”, “recommend-” or “google plus onesies”-buttons that we in the advertising industry somehow feel they must include in every. Single. Goddamn. Site. They’re ugly, they’re bloated[1] and above all, I don’t think they matter all that much.

Does the lack of one-click sharing buttons really make a difference to people who really want to share something? And has anyone ever been persuaded to share something they might not have shared otherwise, just by the presence of such a button?

I mean, I still share some stuff via e-mail for christ’s sake. I don’t even want to count how many steps that takes, and I still do it – whenever the content is worth it.

[1] Seriously, try inspecting a Facebook Like-button with Firebug or other developer tools: it’s an iframe, with a whole webpage behind it that loads tons of other javascript-, css- and image- files – just for one single button. 

A lot of the debate about semantic value and using the correct HTML is kept alive by people who have been around for a long time and seen browsers fail in more ways we care to remember. Valid markup and sensible structure was our only chance to reach maintainability and make sense of the things around us. This was especially important in the long long ago. I remember using Lynx to surf the web.

What follows is a brief history of webdesign and he wraps up with some advice for the pragmatic use of HTML

• If you write a document by hand, use all the semantics you can add in. This is your handwriting, your code is your poetry and people learn from looking at what you did.
• If you need to write a hard-core application and every byte is a prisoner try to play nice with the semantics but follow your end goal of delivering speed. Make sure to tell people though that your code is the end result of conversions and optimisations and not for humans to look at.
• Regardless of what you build – when you can use new technology (maybe in connection with old, like <div class="section"><section></section></div>) use it.
• Remember that the web is not your browser and computer – add fallbacks for other browsers when using bleeding edge technology. When the others catch up you won’t have to alter your code!
• The main focus of markup and web code that is not optimised for edge case apps is to make it easy for people to maintain it. If people can see in the HTML what is going on – win. If what only works with JS is generated by JS- even better.
• More markup is not a crime when it is markup that adds value. Arguments that STRONG is worse than B because it means more code and slower loading pages are irrelevant in times of gzipping on the server
• We can only escape the chicken and egg problem of new HTML when we use it. Right now, if you ask for support in browsers for new elements the answer from most vendors is that nobody uses them so why bother. And when you ask people why they don’t use them they tell you because browsers don’t support them. One of us has to start changing that.

Recommended reading for those of us walking the tightrope between semantic purity and just getting the job done.

The template > slot > ad mental model is engrained both in advertisers, planners and web sites. Providing space for ads needs to be broadened into multiple spaces for one ad concept. This requires closer collaboration between advertisers and web sites, designers and marketeers and sales teams.

Mark Boulton offers some ideas for marrying fluid, responsive webdesign with the need for fixed-width advertising banner formats.

What all of these clients have in common, is that 9 times out of 10 they’ll all be lorded over by a restrictive and overly protective IT department, who only updates their software and hardware every other decade. Which means the client will be looking at your work through the shit-tinted goggles of IE6.

But you’re used to that by now. You know all the dirty tricks and hacks in the book, so you make the site. You know the client won’t be able to see modern web stuff, so you deliberately stay away from them. No round corners, no fancy fonts, little or no Ajax-techniques and no obvious transparent PNGs.

That’s not to say you’re making a bad site, on the contrary. Some of the best design is done within tight constraints, and a little restraint never hurt anyone. Also, most of these clients have pretty restrictive corporate identities and styleguides anyway. So you design your site, slightly boring, but ultimately functional and usable. Something, maybe like this:

A plain-jane website

The client approves the comps, and the finalized website is online soon afterwards. The client tests the site on their internal, locked-down network and sees exactly what he was promised in the comps, being rendered in IE6. The client also notes that the site feels snappy and loads quickly, even on their outdated hardware. A direct result of the site’s design being restrained and sober.

The client then drives home, and, feeling a little bit proud of the work he’s helped to achieve, decides to whip out his personal laptop and opens up the site in a more modern browser (Google Chrome, Safari or Firefox, perchance), so he can show his wife what he’s been doing all these weeks. At first, a shock.

Wait, what's all this then?

This site looks a lot better than it did a few hours ago in the office! What happened here? There’s subtle animations, tasteful rounded corners and the odd drop shadow here and there. The headings are rendered in a slick custom font that he never recalled installing and the entire site just oozes quality.

“Did I pay for this?”, the client wonders, “Who ordered these upgrades?”

First thing next morning he calls you, and asks where those upgrades came from, and why they’re suddenly gone again, now that he’s looking at the site back on his office machine sporting IE6.

“Well,” you start, “have you heard of ‘progressive enhancement’?”

Progressive Enhancement?

Progressive Enhancement is a web-design methodology that aims to provide the best user experience to as many types of browsers and users as possible. It does this by building the site for the oldest browsers, making sure it works great for them, and then adding enhancements for modern browsers on top of that framework, so people get a more enhanced experience, the more modern, or progressed, their browser is.

Some of the techniques you might use to enhance the site.

It is closely related to another methodology called Graceful Degradation. This works the other way around, where you build a website that has all the bells and whistles you can imagine (AJAX, CSS3, etc…) and then either hacking those to work with the older browsers, or making sure that those browsers fail “gracefully”, in other words, so that the site remains usable when certain features simply don’t work.

The advantage of PE over GD is that with PE, you’re always certain that most of your users wile have a great experience, and that their experience will only improve in time as they upgrade their browsers. With GD, you only hope that people stuck with older browsers won’t be freaked out too much, and that future browsers won’t choke on your ancient hacks.

For new, let’s go back to the hypothetical client. You’ve just given him the gist of what Progressive Enhancement is all about, but as I’m sure you can imagine, several different outcomes to this conversation are possible.

Best case scenario, the client “gets” it, and is thrilled to know that you’ve covertly built him a future proof website that scales beautifully, from the ancient, turn-of-the-century browsing dinosaurs to the latest CSS3-, HTML5-sporting Web 3.0 browsers.

Worst case scenario is that the client demands those same enhancements be recreated for IE6. But now you’ve got an arsenal of valid counter-arguments, such as:

• It’ll take a lot of extra time and money to get that kind of visual fidelity in older browsers.
• Updating or upgrading the site later on will take longer and thus will be more expensive.
• The site won’t run as fast as it does now, both on IE as well as on modern browsers.
• Etc…

So, unless your client is Satan himself and/or completely immune to reason or logic, you’ll have saved yourself a mountain of extra work, and earned yourself a contented, loyal new customer, one with a better understanding of what designing for the web entails.

And all it took, was a little

Managing expectations

We designers have a tendency to pull out all the stops when we’re mocking up a  website. We know what’s theoretically possible in all browsers, so we don’t skimp on the frivolous details. Technically, rounded corners and drop shadows and the like are all possible on IE6. They just require a lot of hacking, extra markup, extra images… all of them slowing down the rest of the site for everyone. So, what to do?

Well, it just requires adding just one extra step to your existing process.

First you design your site like you always do, pulling out all the graphical & typographical stops as you see fit. Then, when you’re happy with it – STOP. Don’t send it to the client just yet. Instead, duplicate your file and tone it down. Take out everything you know is difficult to do in IE6. Better yet, ask the guy who’ll be writing the CSS to do that for you. After removing all the frivolous eye-candy, give the comp a final spit & polish to make sure the design still *pops* and only then send it to the client.

After the usual bout of back&forth, and you finally get client approval for the “restrained” comp, build that, re-adding some or even all of the eye-candy by way of targeted CSS3 and AJAX, so those with modern browsers get the enhanced “special edition”.

It’s a difficult balancing act, sure, and it requires an intimate working knowledge of CSS and browser capabilities, as well as a keen eye for design, but the rewards for dealing with these “conservative” clients in this way are legion, and you’ll end up with:

• Smoother & quicker development cycles, as there’s little or nothing to hack.
• A site that just works and has no IE overhead.
• A client who might feel as though they got more than they bargained for.
• Happy users, regardless of what browser they’re using.

Now wouldn’t that be nice?

Addendum:
The example given is a mock-site for a mock-client. It was quickly thrown together as an example of what’s possible with progressive enhancement.