Gilles Vandenoostende

Indulge me, if you will, in a little hypothetical.

Consider the following scenario: you’re asked to design and develop a website for a big client. It’s a large company, with probably thousands of employees. A bank, for example, or a large pharmaceutical company. Or maybe it’s a government contract, or a big public sector player, like public transport or the electric or gas company.

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.

Artikel in de Gentenaar 7/11/2009

Dit weekend stond het volgende artikel in de Gentenaar, ook nog te lezen online op de sites van het Nieuwsblad en de Standaard (members only).

Terwijl het een zeer mooi geschreven (en uitermate ego-strelend) artikel is, zou het intellectueel oneerlijk zijn als ik geen rechtzetting zou doen: Jan Algoed & mezelf waren natuurlijk niet de enige mensen die Pepsi Max-it mogelijk maakten, wat we ook aan de journalist verteld hebben tijdens het telefonisch interview. Maar gezien de lokale aard van de krant vond die het blijkbaar interessanter om enkel het verhaal van de 2 Gentenaren naar voren te schuiven.

Daarom zou ik graag de credits van de Pepsi Max-it campagne (as far as I know) willen posten:

Jan Algoed : Concept
Jeroen De Pelsmaeker : .NET Developer
Arnout Everaert : Digital Project Manager
Brecht Hauspie : Account Executive
Geert Leysen : Hardware
Pieter Michels : R&D
Bart Muskala : Concept
Bert Vermeire : .NET Developer
Jan Verstreken : Hardware
& Yours truly : Design, 3D visuals & Front-End

A.K.A, het Proximity BBDO team.

As fervent followers of my twitterings & facebookings might know by now, Pepsi Max-it, the project my colleagues & me poured our blood, sweat & tears into a couple of months ago has been nominated for an award at the Adobe MAX 2009 conference in Los Angeles. More specifically in the Advertising & Branding category.

Myself, along with Jan Algoed – our Adnerd junior – will be jetting across the pond at the end of the week for 4 days of conferencing & networking, hopefully bringing back a shiny new award in the process – although, looking at the competition we’re facing, I’d wager we have the snowball’s chance in Hell to actually win it.

But don’t let that dissuade you in the least! If you haven’t done so already, please vote for us (”Pepsi Max-it by Proximity BBDO”) on this page here:

http://max.adobe.com/awards/finalists/

(Shhht, don’t tell anyone, but you can vote more than once!)

More will definately follow once I get to L.A. Follow my twitter for up-to-the-minute updates.

1. Show us all your pretty Microsoft Certifications! They’re like official and stuff and require you to sit through a written exam and everything! This one here says I can use MS Office, and this one says I’m an Microsoft Certified Webservice Developer! Just because I’ve never actually ever written a webservice doesn’t mean the certificate’s meaningless right?
2. Who wants to write code when you can drag & drop? It’s so easy! What do you mean, it breaks the designer’s perfectly valid, cross-browser html layout and makes the site slow down to a crawl? Fuck you, I wanna be home by 5′o clock!
3. Develop for IE6 first, then hack for FF/Safari/etc… Hey! It comes standard with windows, that’s the only standard you need right?
4. Only have experience developing intranet applications. It’s not easy making buggy web-interfaces that are only marginally more usable than hand-writing SQL statements.
5. Don’t ever actually spend any time on the internet. Who reads blogs when you’ve got sports & sitcoms on TV? Also never google for .NET related questions. If you don’t know how to do something, it’s impossible and can’t be done, ever. What do you mean, you just did?
6. CSS? That’s just 1337-speak for using divs instead of tables. Inline styles FTW!
7. Learn any language other than C# (or even VB.NET). Where’s my Visual Studio at? PHP is for filthy hackers anyway.
8. Don’t use open source software. It’s free, so there’s got to be a catch right (like AIDS!)? I’ll just stick to Microsoft sanctioned libraries or expensive third-party components that are IE-only, thank you very much.
9. Design patterns? I’m a developer, not some pansy-ass designer! Excuse me while I code the entire business logic in this single VB file.
10. Ajax? SiFR? DOM scripting? Stop speaking gibberish you ape. I only care about things if they start with “Microsoft” and have a year in the title somewhere.

Do these sound familiar to you? Then by all means, please don’t go to http://www.proximity.bbdo.be/jobs .

MCSE is to computers as McDonalds Certified Chef is to fine cuisine
http://www.bash.org/?8695

We in the online advertising industry make banners. A lot of banners. They’re a necessary evil of online advertising and annoy us all on a regular basis, but they get results, and that’s all that matters in the long run.

We don’t publish these banners ourselves, instead relying on various Media Centrals to deploy and distribute our ads to the various publishers and eventually across your favourite websites on the intertubes.

Contrary to what you might think, most banner ads aren’t just randomly cobbled together pieces of Flash animation, engineered only to aggravate. There are strict rules and regulations that enforce a level of quality and police the potential disruptiveness of banners.

You can’t, for example, open pop-ups willy-nilly, or start playing sound without user interaction. The Media Centrals enforce these rules and guidelines by decompiling every banner and checking the code for malicious scripts and the presence of certain required snippets of code for the banner to work as it’s supposed to (Well, most of them do anyway. There are a couple of shady Media Centrals out there who’ll publish anything really, but we don’t use them).

Most of the time, this all works without a problem. Aside from a few annoyances that stem from the lack of a standardized “clicktag”, the Centrals don’t needlessly scrutinize our banners. Until a few days ago, that is.

One of these Media Centrals, who, for diplomatic reasons, will not be named, apparently uses Google’s adwords guidelines as a reference for checking banners. Nothing wrong with that, Google is, for the most part, a trustworthy and efficient entity. If only it wasn’t for the small fact that their employees don’t understand basic concepts of Flash development.

And so, for the last 4 days we’ve been involved in a longwinded and frustrating bit of back-and-forth regarding some of our banner ads. They claimed infractions where there weren’t any, and we retorted. Most of the infractions the Central claimed our banners were guilty of were absolute drivel and we were well on our way to winning the argument, when they suddenly pulled this hidden beauty out of the Google Advertising Policies:

“Random Numbers: Your ad may not include code that generates or uses random numbers.” (source: adwords.google.com)

For the record, here is the offending piece of code that caused the problem:

TweenLite.to(mc, 1, {height: 0, delay: Math.random()*.5});

All it did was to delay a certain animation with a random amount of time to create a more natural-seeming animation. It’s a piece of code that’s used all the time to create dynamic scripted animations in Flash banners, without incident.

To claim this as a security risk is seriously demonstrating a sound lack of judgment, both on accounts of the Central AND of Google. The rest of the policies in that document are all common sense standards, but that “random” clause seems strangely out of place.

The end result is a much duller animation and a lot of time lost. We’re still sorting this out with all the involved parties, but I hope Google takes notice and removes that silly clause from an otherwise impeccable policy.

One of my New Years resolutions is to learn Ruby On Rails, the hip young web development framework popularized by sites and applications such as Basecamp or Twitter. Being on a mac, installing and running rails is dead easy, just a few terminal commands. I’d toyed around with it a few months ago, but didn’t get too far.But now, with the new 2.2 version out I decided to give it another go.I tried updating to the latest version with the terminal command:

sudo gem update –system

to get the RubyGems to update to 1.3.1. However, the command simply returned:

nothing to update

But checks revealed it was still at v.1.2, so there clearly WAS still something to update. A couple of google searches later, and I’d found the solution to properly update RubyGems to the correct version:

sudo gem install rubygems-updatesudo update_rubygems

Now, if you’ll excuse me, I’ve got a train to catch! *groan*

I encountered a strange bug in Flash player 10 today. A simple flash animation, scripted in AS3, which gave no errors inside the CS3 IDE threw the following error when run inside the browser (which was running flash player 10):

SecurityError: Error #2000: No active security context.

Now, the animation itself is completely static, no external content or links of any kind, so this error threw me off. A quick google search later, and I had tracked the bug down the the following innocuous line of code:

setTimeout(_launchTimer.start, 3000);

“_launchTimer” being a simple Timer object. The workaround, was to wrap the call to the timer’s start() function in an anonymous function, like so:

setTimeout(function():void{_launchTimer.start();}, 3000);

Very strange indeed… It seems like FP10 doesn’t like setTimout calling functions that aren’t in the same scope from where the setTimeout is being called for some reason. I’m blogging about this so that hopefully, other developers tearing their hair out at this strange bug might be helped by this.
Also, happy 2009 everybody!

Crossposted from pool.proximity.be.

As you may have seen last week, we (Matthias, Pieter and myself) have had the privilege of attending Adobe MAX in the lovely (yet very wet and cold this time of year) city of Milan, Italy.

MAX is Adobe’s yearly conference, held in North America, Europe and Japan, focused on presenting the latest technological advances made by Adobe, as well as providing education on the software currently available. The sessions are presented both by Adobe “evangelists” and members from the community.

In this first blog post, I’ll be talking about the big thing of the show this year, namely Adobe’s upcoming new entry in the front-end webdeveloper market-segment : Flash Catalyst. Read on after the jump.

Read the rest of this entry »

As you may or may not know, Belgium is a funny old country. Not satisfied with just one national language, we decided to have 3 of the buggers, namely Dutch, French and German – with English as an unofficial fourth. This means that most of us are quite gifted multi-linguists, and can read, understand and write several of the 4 languages with varying degrees of success.

The peeve I have though, is that while the majority of the Belgian population is flemish (i.e. dutch-speaking), many international websites/applications throw all of us in with the french speaking lot by automatically changing the site’s language to french, based solely on the region from which we’re surfing.This became quite apparent this morning when I was checking the Facebook app on my iPod Touch, when I noticed that it had decided to automatically assume I was a french speaking belgian, and had translated the entire app since the last update.

As far as I could tell there was no immediate way to change the language back to english, so now I’m stuck with a francophone version of Facebook. It’s not that it’s a huge inconvenience – I can understand french just fine – but I just prefer to enjoy everything in it’s original language where possible. I don’t watch dubbed movies, or read translated books unless it was originally created in a language that I don’t know. I just feel that certain semantics are always lost in translation. So that’s why I want to use the Facebook app in English, thank you very much.The website itself seems to be spared this inconvenience for now.

Now, I’m all for localization – in fact I’ve written an actionscript framework to facilitate different flash site language version – but let’s not take away the choice of language from the user shall we?

If you’re trying to make a flash site or AIR application that uses localconnection to connect to other sites, please remember to prefix your connection-name with an underscore.The reason for this, is that unless the name starts with a “_”, the flash/AIR runtime will prefix the connection-name with the name of the current domain and a colon (i.e. “domain:connectionname”), and as such, crossdomain/-sandbox connections will ultimately fail. Adding an underscore prevents this from happening, which allows you to do some cool stuff, like having a website interact with a desktop application – which is exactly what I’m trying to achieve with MultiLang.More on that later, for now, just enjoy the tip