Jason Santa Maria - A Real Web Design Application

Prominent webdesigner Jason Santa Maria wrote an interesting article the other day about the pro’s & cons of current webdesign tools (such as Photoshop, Fireworks, etc…) and what a true webdesign application (if it were created today) would need. It’s an interesting read, so check it out at:

http://jasonsantamaria.com/articles/a-real-web-design-application/

The author raises a lot of valid points, notably the huge disconnect between designing static pixels in Photoshop & co. and the crafting of HTML markup, CSS styles and how to resolve cross-browser inconsistencies. Jeffrey Zeldman wrote a similar article a while back and makes the point that hand-coding HTML/CSS isn’t going anywhere anytime soon. I’m of a similar opinion.

In my current workflow, I use a myriad of different tools when designing for the web.

Some of my favourite webdesign tools

After wireframing I’d hop into Photoshop, design all the pages (keeping browser capabilities/limitations at the back of my mind at all times) and then use Layer Comps to review the flow of the site through all the different pages. Some web-designers have begun skipping Photoshop altogether and designing straight in the browser, but I’ve found that a hybrid solution is still the best option for getting the most out of your designs.

Once the client is satisfied with the static comps I fire up Coda, write the markup to be as efficient and semantically valid as possible. With the markup done I hop into CSS, boot up all the virtual machines and alternative browsers I’d like to support and then I’m off for several hours of writing a few lines of CSS, Cmd/Ctrl-S, and then tabbing between browsers while pressing F5 to make sure my layout works.

This is a hugely time-consuming process and is usually the cause of great frustration among beginning web-designers (or designers used to the consistency of the Flash platform) – but for all its faults, it’s still the best option. All the WYSIWYG (What You See Is What You Get) tools out there either sacrifice flexibility, browser compatibility or cleanliness of the markup. Or, in the worst case, all 3.

Writing semantic, search-able markup is one of the most difficult and multifaceted jobs out there. Most hand-coders even find this to be a difficult task, weighing the different semantic options, and choosing between either making alterations to the original design, or sacrificing markup brevity to stay true to the design’s visual complexity (i.e. adding more divs). For a machine to be able to do this, it would need not only to understand the different design elements, but the content you’re designing for as well.

If I was designing such a piece of software, I’d make it work as a block-based design tool: in the design phase, you just drag & drop all the different “boxes” onto a canvas. The design remains mostly static until you come to the export phase. Then your task would be to go through each block, assign a type to it (be it a div, section, header, footer, aside, whatever), give it an id or a class-name and then change the nesting order of the tags (within reason) while the rendering engine attempts to refactor the page’s CSS to work with the changed markup.

Of course, taking browser inconsistencies into account this becomes an almost mind-bogglingly complex task for a computer to handle. With HTML/CSS, to achieve any kind of style or effect there are as many options and techniques available as there are webdesigners and webbrowsers.

To create a simple header some would use 3 divs and an h1, where others could use just a single div, an h2 and a nested span tag. And that’s just the markup, adding the myriad of possibilities CSS offers the potential amount of ways you can go about to achieve a certain style or look become infinite. Any webdesigner worth his salt will know at least 3 or 5 different ways to accomplish something in CSS. He’ll try one way first, finds it works in most browsers except in one instance, and then tries the two other coding techniques until he finds something that yields the most predictable cross-browser results.

Because of the cascading nature of CSS, almost every single situation is unique and there is almost no way of knowing beforehand which technique will yield the best results, except maybe years and years of experience. Software could never be a full substitute for something like that.

As long as our markup is critical to our client’s business needs (S.E.O. is 80% about having good, clean markup), and web-browsers continue to display subtle (or not so subtle) differences we can never in good conscience use WYSIWIG editors. Perhaps one day, when all rendering engines adhere to the same strict webstandards (or a single engine gains such market dominance and quality that all others would strive to emulate its behaviour) such a design tool could become a reality, but until then you’re still better off learning to code by hand.

Clever coders should be able to easily expand this code to allow for more cheatcodes to be detected (“iddqd” or “idkfa” anyone?)

Enjoy!

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.

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.

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 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.

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*

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!

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.

Flash Catalyst presents itself as being a third step in the current Flash development pipeline. Today, the usual workflow consists of 2 steps:

1. The designer creates a mockup in Photoshop/Fireworks/Illustrator.
2. The front-end developer builds that mockup in Flash and scripts it in Flex (or FlashDevelop).

This workflow means that the interaction design (determining how the site/application works/behaves) is all in the hands of the front-end developer. It also implies that unless you have excellent communication between your designer and developer, certain things in the design might end up being “lost in translation”, as it were.

Flash Catalyst aims to fix this by providing a third step in the process:

1. Mockup created by the designer in his/her tool of choice.
2. The interaction designer (which should ideally be the same person who made the design) takes the static comps into Flash Catalyst, and creates a working version, with state transitions, skinned components, etc… yet without any real front-end (or backend) logic attached.
3. The developer then takes this FC file into Flex, and hooks up the interactions to the necesary logic and webservices.

We’ve been given a Beta version of FC and the latest version of Flex Builder (codenamed “Gumbo”) at MAX, and so naturally I’ve been playing around with it a bit. So far, the transition between design and interactive front-end still seems very rough around the edges. Imported Photoshop documents that rely on custom blendmodes, pattern-overlays or clipping masks don’t accurately import yet, and the interface feels slow and awkward.

There’s also no support for importing from Fireworks just yet.

Adobe currently recommends using Illustrator for creating Flash Catalyst designs, as its vector-based designs should import with the highest fidelity compared to the other, pixel-based design tools. As I’m more of a Photoshop person, I’ve yet to try this out, but the reasoning behind it seems sound. Flash is vector based after all.

But seeing as it’s still in Beta, I expect a lot of these issues to be fixed in the final release.

However, the thing that I’m worried most about is what or any merit this new workflow might have over our current way of doing things here at Proximity (and a lot of other interactive design agencies I suspect). I personally feel this Catalyst to Flex workflow is aimed more at creating Flex-based Rich Internet Applications (RIA’s) or Web- and AIR-applications, rather the heavily customized Interactive Experiences that we try to create for our clients. Also, the added overhead of the entire Flex Framework might be a bit overkill for a lot of the micro- and minisites we make here.

It also seems that FC is geared towards making rather traditional website layout, with buttons, states, pages and the like – but in my mind the whole point of the flash platform is that you can make unconventional interactive websites. If you want a traditional website, you might as well stick with HTML and CSS in my mind.

But speaking from experience, the current way of skinning Flex applications is a real pain in the ass, so it looks that at least in that respect Flash Catalyst will provide a markable improvement over the current situation, where a myriad of faux-CSS files and hacked MXML components could be replaced by single FXG file. So I think that, in time, Flash Catalyst could earn its place in the natural order of things.