@Mathias Bynens,

“Obviously, you’re talking about minor changes, not fundamental modifications to the original design — let alone, starting a new design from scratch.”

— Of course, new creative concepts take more time, but even these never need me to change HTML. Changes to layout are simple and mean only working in CSS.

“I can see why the only changes clients request to your designs are tiny ones, but this doesn’t mean this is the case for every designer and for every project.”

— No, I often go back to the drawing board. I’ve been known to throw away designs even AFTER the client had signed them off, because I wasn’t happy with the direction.

“This workflow might work for your projects, but this doesn’t mean it’ll work for any web design + development project. ”

— Did I infer that it would?

“Again — I think the situation in which there’s both a designer as well as a (front-end) developer is much more common than just one double- or triple-talented bastard doing all the work.”

— I don’t do all the work. I have enormously talented chaps to work with, including Owen Gregory (the best partner I have ever worked with) . Oh, and web designers should learn markup and CSS. Otherwise they aren’t web designers.

“There’s no way the front-end developer is gonna start working before the design is final (i.e. fully approved by the client). It’s called “working for free”.”

— Where I live, it’s called “tripe” — and that argument is full of it and based on generations old preconceptions about what designing, prototyping and developing is.

“This article is, sadly, a fairy tale to most people.”

— Damn. I knew I had forgotten to mention something. I should have said that Mike loved the web site only after drinking a special potion (I slipped it into his tea). I also turned Sam into a frog (or was it a stone) when she brought up IE6.

Excellent read Andy! I love how you communicated your message in a story format. I completely agree with you. Most people that will go to your website will only do so with 1 browser, unless they are like me who use a MAC at work and a PC at home.

Short and sweet. Favourite 24ways 2009 article so far, Andy!

True. Some websites that I use daily on different browsers render differently in each of them. And I, an experienced user of the Web, don’t notice the difference in most of them, because, as a user, I’m focusing on the task at hand.

It depresses me knowing that so many man-hours are put into creating a pixel-perfect website for IE6 when they could be used for making websites move a bit further instead.

Ok, maybe I am confused here. Was the site optimized on the iPhone because webkit supports most of CSS3 (thus giving her the ‘prettier’ layout), or does CSS3 provide for some kind of float type behavior for columns on smaller screens?

(Yes, I still have not started incorporating CSS3 – I’m bad)

This is foolproof way for dodging the cross-browser mine field up front… now if I could only convince my boss to dive into the markup BEFORE the design is approved… I’ll give it a shot.

Yeah, we do iPhone compatible versions of all of our sites.

I think this is a great idea as long as the client is satisfied with your design. The only drawback is if the client wants to move several design elements around or other major changes.

In Photoshop or Fireworks this could be accomplished much quicker than it would re-styling/coding the mockup again.

I’ve often done something similar with IE such as giving rounded corners/drop shadows to non-IE browsers while giving IE users a less glitzy website.

Nicely done… In our client approval process we tend to save a lot of time showing .jpg mockups before we write any code, but this is a really well played scenario. I might have to rethink the ol’ workflow, or at least put in some extra time educating clients about CSS3 & browser compatibility.

@AdamA – Consider the difference using a mobile device to view a site with images used for e.g. all the rounded corners, compared to the same site using border-radius.

The CSS3 approach is likely to work far better as the site will either display the rounded corners or fall back to square ones. What won’t happen is the browser won’t have to download a bunch of extra images and then try and render them in the right places – using unnecessary bandwidth, and potentially prone to error.

The CSS3 approach is faster, using less bandwidth and is less prone to failing badly in browsers you’re not testing in.

Thanks Andy, the more people that talk about this the sooner people will start thinking like this.

@Drew McLellan

Ahh, that makes sense. Thanks for the clarification.

Great article, Andy.

Designing in the browser isn’t widely understood, even at the web agency I work at. I just recently completed a design in HTML/CSS and had a coworker keep asking for the “original design files,” and they had a hard time getting their heads around the links to the HTML files I kept sending them.

so what happens when Mike says to Sam, “I just love the rounded corners on the ‘submit your story’ button. It looks so elegant.” and then Sam replies, “what rounded corners?” and then they start comparing, and realize that the website looks different to each of them. and then they go back to you, the designer, and ask, “why can’t EVERYONE see these lovely rounded buttons??!!?!!” then what do you do?

In a perfect world we could build the design once and have it be done. But as other commenters have pointed out, the design process is full of revisions, which can take longer to implement in code than to edit in a program such as Photoshop (especially big changes).

…also some clients check multiple browsers at or before launch to see, and often report it all back to you in an email not always with kind words… so it’s best to let them know up front either that their will be differences and what they are, or just try your best to get them to match (which is painful)

I’ve tried designing in the browser. I really, really have. And I just can’t seem to be productive enough at it.

Using Photoshop, to me, is like playing a musical instrument. I whip through several iterations of a single element or group of elements in seconds with a few artful strokes of the keyboard. I’ve got my headphones on and I’m composing along with what I’m hearing. The design “blooms” in front of my eyes.

I just can’t replicate that bouncing back and forth from the IDE to the browser. Not yet, at least.

Thanks, Andy! The bit about clients not opening all the different browsers to check their site is a good dose of reality for some of us web designers who naturally are inclined to do such things.

I’m curious though, do you ever address the cross-browser issue with the client during a project? I think some designers feel like they’d be hiding something from the client if they didn’t mention it at all. It sounds like your view is that it would needlessly burden the client to raise the issue. If I’m reading that right, I’d have to agree. Clients can often be a panicky bunch, and it’s easier for a client to say no than to try and fully grasp the issue at hand.

The first couple of points that sprang to mind after reading this – which have both been mentioned by lots of people already – are the time spent coding up a design that a client may or may not like, and the issue of presenting different aesthetics to different users, depending on what browser they choose to use (or have to use in their place of work).

If a PhotoShop/Fireworks mockup is created by somebody who understands designing for the web, then no false expectations will be created – body text will have no anti-aliasing and will be in a generic, web safe font, and so on.

I think ultimately, this kind of exercise is fine for articles on sites like 24ways.org, but on a day-to-day basis, in the average web shop, I really don’t think it’s practical – or even appropriate.

If web designers don’t want to be restricted by current browser standards, they should go and design for print instead.

Brilliant story, Andy. You pointed out something I’ve always known, but never thought about. Thank you for opening my eyes!

I don’t have the time to be coding up every design comp for initial presentation. Designing a site in PS then building it then showing it to the client is not a route I’d want to go. I explain it to them straight up—show them the comp then explain why and what may be a little different in various browsers then answer any questions they have while explaining the benefits of progressive css.

Its an interesting read, but I dont know any agencies who would actually build a demo of the website before a design mockup is approved. Almost all of our clients request several concepts, iterations and lots of changes.

Ah, Sir Andy (yes, I’ve just knighted you), this is indeed one of the better 24ways yet this year (and that’s saying something b/c it’s been a good year). Your article couldn’t have been more timely for me, as I was just today wrangling with the notion of wanting to use a few of the more progressive CSS methods in a new project.

I’m just not entirely on board with the “need-to-know only” approach you’ve put forth here…

How would you handle the issue, should it come up, if Mike and Sam were to compare their impressions of the site during their review, realize the differences between the browser renderings, and then confront you about it?

Personally, I’d prefer to avoid that potential for client confusion and complaint. (Yes, I hate confrontation.) In my experience, it is better to be completely upfront on expectations – so sell the client on the idea of progressive enhancement and all browsers not needing to have exactly the same rendering of the design, and do this at design inception rather than when they complain later.

This does of course all speak to the idea of prototyping with CSS, which I am a huge proponent of, particularly if you use an iterative design process. It can be much more rapid to design and revise UI embellishments like rounded corners etc via a few lines of code as opposed to opening up an image editor, reslicing, etc each time. In fact, I do nearly all my design mockups in html/css and only use photoshop for specific one-off graphic elements when needed.

Which brings me respectfully to Neal – your point about accommodating design changes being faster in a graphics editing program (photoshop or fireworks) as compared to recoding html/css mockups is entirely subject to the designer’s skills and comfort level. Again, for me, I would find recoding much faster, regardless if it were just a minor tweak or entire layout changes. To each his own…

very nice Andy,

I’ve been trying to move towards less reliance on the concept design phase (i.e. Photoshop) and more real design implementation in the HTML/CSS build phase at work recently. It’s a hard balance sometimes and it goes without saying you need designers who are really comfortable with HTML/CSS (which all web designers should be of course).

In part it’s a battle with the old way of doing things and what is quicker (since time is money). Traditionally Photoshop has been seen as a quicker mock-up tool but I think with the advances in CSS it’s making it easier and easier to design directly in the browser.

While this all makes sense, it doesn’t mean you don’t need to think about supporting all browsers. Its fine if a site looks different on various browsers, but you still need to make sure it is functionally the same across all of them.

When I read this post, I was surprised with a solution to show the client not a design sketch (I mean as a picture), but real browser overview.
So, if the client surfs the Internet in IE, designer should provide his sketch overview like IE displays. But, if the client works in Safari, the sketch should look like Safari displays, shouldn’t it? And so on…

I think, it’s a great idea to show our clients the true result, not just a picture. By this way clients would respect us for more, because of our transparency and honestly. And they love to work with honest guys!

However, there’s an important question about sketches preparation: if a web designer works on some variations of designs and would like to show a number of sketches (as it usually happen) to the client, how he should prepare them?
Not just a picture, but sliced HTML and CSS?!

Great article, Andy!

I do, however, have some questions:

When I first presented my designs to Mike and Sam, I showed them a Web page made with HTML and CSS in their respective browsers and not a picture of a Web page. By showing neither a static image of my design, I set none of the false expectations that, by definition, a static Photoshop or Fireworks visual would have established.

Yeah, but doesn’t that mean you also have more work when — hypothetically — the client decides he doesn’t like the design and wants you to create another one? You’ll have to a) redesign AND b) translate your new design in HTML and CSS.
What if the client asks for three different designs beforehand? Are you gonna code these as well, knowing that you won’t be able to use two of them in the end?
In this specific case, would it really be worth it to work the way you do?

“How would you handle the issue, should it come up, if Mike and Sam were to compare their impressions of the site during their review, realize the differences between the browser renderings, and then confront you about it?”

+1

This is the real issue, and one Andy always avoids providing a proper answer for. Why should the client care that you don’t want to make a dozen rounded corner images so their site looks the same on IE? And really, what is the point of CSS gradients when for an extra 500 bytes you can improve the design for another 60-90% of your site audience?

Short and sweet – well done Andy.

Awesome article! I will definitely use that! Thx for sharing! ;)

I only wish it were this simple … I have so many clients that will not approve a layout unless it looks exactly the same in each browser.

True story …

“Elma comes to me for a brand new site because hers is a template from 2000 … she browses the web often but still doesn’t even realize that her computer at home is running a different browser than her computer at work.”

I present her with a design that she LOVES … (and kept the documentation to show it to her later).

I then go ahead and code the site with html and css validation in all major browsers and then “tweak” the css so that it is compatible with earlier browsers.

We get the site live. She starts showing it around to all of her friends and referencing parts of the site that she “loves.”

Then she goes home and pulls up the site to show her husband … (This computer is running IE6 and some of the design element had to be tweaked because IE6 SUCKS!).

Immediately I get an urgent, frantic phone call saying that the site is “MESSED UP.” I explain to her that the web is not like printed material and that it can be rendered differently across different browsers/platforms and that this is something that we had discussed previously and she had approved.

Completely frustrated that her design would not look exactly the same in EVERY browser she had me take the site down completely and put her site from 2000 back up for her. (Thank goodness I made a back up!)”

Unfortunately, in my experience if browsers aren’t rendering a site in at least an EXTREMELY similar way I have been unable to get a client approval.

If I was to show the example here to my clients there is no way they would be satisfied with the major differences in the layout.

So how would you tackle that kinda of situation? I’ve tried “teaching” clients about the differences, tried showing them slight modifications, and even in extreme cases had to refer clients to other people because they were so difficult to please that I was losing money on their projects.

Advice?

so what happens when Mike says to Sam, “I just love the rounded corners on the ‘submit your story’ button. It looks so elegant.” and then Sam replies, “what rounded corners?” and then they start comparing

In my experience, Mike tells Sam to download Firefox/Safari/Chrome. Sam does and doesn’t go back. Over the years we’ve had this in our offices with new, non-tech staff who are only used to IE. Just educating them to the fact there are better options is usually enough, the benefits become clear soon enough.

Woah, too many comments to reply to, so I’ll paraphrase three. Also, tomorrow’s article will…

1. “If these people are as happy and proud as the story says they are, they are bound to talk about it to others. The design differences will come up and there will be a lot of explaining to be done.”

— It usually goes like this.

(Mike:)“I saw the design on Sam’s IE7 today and she doesn’t see the rounded corners or shadows. Can IE not ‘do’ those?”

(Me:) No. IE uses very old technology. I can hack the site to use lots of images and other things, but that will likely slow the site down for everyone. Plus it means that I will tie the HTML to the visual layout, making the site less flexible (and expensive) to update in the future.

It’s your choice, you’re paying. You can either spend my time and your money on hacks for a diminishing return, or we can spend it on making more cool functionality. What’s it to be?”

(Mike:) “Let’s do the cool stuff.”

2. “Its an interesting read, but I dont know any agencies who would actually build a demo of the website before a design mockup is approved. Almost all of our clients request several concepts, iterations and lots of changes.”

— Of course it depends on the HTML/CSS skills of an individual, but spending an hour or two making an actual web page to show a client (hell, use a framework if you must) will save you hours, sometimes days later on. The client wants changes or even a complete new look? That will be simpler and faster in HTML and CSS than it could ever be in Photoshop. Not that fast in CSS? Get faster.

3. “I’m curious though, do you ever address the cross-browser issue with the client during a project? I think some designers feel like they’d be hiding something from the client if they didn’t mention it at all.”

— Rarely. And it’s not hiding. I don’t want to know or need to know about how my suit is made, just that it fits and I look sharp. When the issue does come up, explain the facts of life in simple terms to clients, managers, brand execs or anyone. Tell them, browsers are different, the web is not a static canvas, anything can be done, but everything must be paid for and sometimes something has to give. Given the choice between better functionality or cross-browser perfection, most will go for functionality can helps them make money — every time.

Yay! We are now absolved from all responsibilities regarding cross-browser compatibility. Not really, but I do appreciate a fresh point of view towards this often-painful aspect of our work. I think the attitude you’re promoting is healthy, and I support it. However, It’s important to make sure we don’t forget to supply our clients/audience/users with high-quality and accessible websites and web applications.

For all of you getting stuck on “design process,” think about it for a minute. Designing with html/css allows you to create flexible wireframes that the client can interact with from the beginning. Is it really faster to make a content block float right instead of left in Photoshop or Fireworks, than in CSS?

Not to mention, am I the only one that starts sketching up wireframes and interaction on paper first? Huge time saver and you can often solve many of the major problem without even firing up an app at all.

Great article Andy.

Great article, I agree with pretty much everything in it. Shame though that my boss and his clients have a different opinion most of the time, which is a problem most of us will face I’m afraid… I tried introducing HTML mockups instead of endless Photoshopping, but didn’t succeed :(

I just can’t understand why people expect a browser which is almost 5 (or even 10 in the case of IE6) years old to behave and have the same features as a brandnew browser. You don’t expect your 10-year old tv to have the same results as a brandnew HD 40” flatscreen, so why do you expect a 10 year old browser to correctly support features which weren’t even INVENTED yet?!

Good article. My own problem is I find i’m more creative in Photoshop that when designing in browser so for me personally the process isn’t something I think I could adopt, but this is just my preference or level of ability.

However if you do design in browser it’s certainly an excellent solution for managing the expectations of a client.

Say it with me now! ‘Education, Education, Education’ – That’s the key here!

If you educate your clients to the fact that browsers are different, and that IE6 is like playing football in the pub sunday league, compared to Safari/FF’s Champions League football … they usually understand where you’re coming from … and from my experience … they will appreciate, that you’ve took time to explain to them the differences between browsers.

This is a lovely read, as expected from the Clarke.

It’s nice to read something that isn’t just a well-written rant for once ;)

Great article.

We are flirting with agile methods of design/development – almost all of our sites are application based – and are moving towards an iterated prototype model, rather than a very print design based approach of showing 3x visuals with greek text in them, almagamating elements of said visuals and then figuring out how to code them.

Designing in browser, for me, is indicative of a broader problem-solving approach that hinges around addressing the content, the purpose and the environment of the design, rather than just the look of the design.

Loved the ending .

And ya ! Doen’t showing them how the site looks in HTML/CSS mean more work ??

Applause and cheers… get’s 2 big thumbs up from me.

I love using CSS3 for “progressive enhancement/graceful degradation”. It makes so much sense.

I explain to the client why we take this approach and usually they except the differences in browsers (if they even look/notice) and are very happy. Just be open.

I just wish that W3c would validate CSS3 code!

Dear folks who are missing the point: First off, Andy’s talking about designing in the browser, so for those asking if it’s worth all the extra time to “code” major design changes/revisions every time the client asks, well, that’s part of Andy’s message: design in the browser and you don’t need to code your design—it’s already done.

As for how to handle clients, that part of Andy’s message really has nothing to do with technology, software, or workflow: it has to do with the relationship you establish with clients from day one, and how you manage that throughout a project.

We must all remember that making clients happy is not our job—our responsibility is to focus on producing the best product for them. This can be difficult for people to grasp, and the mentality of “everything the client asks for/wants/expects is always right and we should please them no matter what level of frustration or extra work we must endure as a result“—which is primarily the fault of traditional agencies—doesn’t help in the least, but that doesn’t mean we should all just keep doing things the way they’ve always been done.

What Andy’s saying is that it’s time to take control over the end result, and that requires managing the client and their expectations as much as your own approach to creating the work. To those who have stories like Michael’s — rolling over and giving in to the client’s complaints about something you already received approval for just hurts the industry. Quit it.

Brilliant article – it has to be one of my favourites this year. Not because it taught me anything new (I’m a big fan of using the tools available to me in progressive browsers), but because of the last sentence and moral of the story – “That was on the house” – genius.

‘Tis the tale of our age. Well told! Thank you for constantly carrying this important message to all of us, and for doing it with wit and brevity (which is the soul of same). I’ve seen you present this notion to audiences as well. You do it brilliantly. Keep on keeping on. This is our recommendation in DWWS3e as well. The age of pixel-perfect sameness across multiple (generations of) browsers may not be dead yet, but it sure smells bad, and great little narratives like this one will help kill it faster.

Good article, and I agree with PETE the key is to explain VERY carefully to the client/staff beforehand. Ignorance is the basic problem. Welcome to the future!

Great article, really well written.

I will certainly be using some CSS3 on my new projects in the new year.

Perfect article Andy. At first I thought that this would be some crazed controversial rant but instead the only crazed part is some of the comments from readers who don’t get it.
The vast majority of clients don’t check in multiple browsers because most don’t know what a browser is, let alone that are different ones. Then it us up to US to educate our clients on the ways if the web, IF, and it is a big if, they comeback to comment/complain. After all they hired us because we know the web.
There should be more design like this, and we should be pushing the boundaries with HTML5 and CSS3 because this will encourage all browsers to implement faster. If we just sit back with “what is mainstream now” then that’s where we will stay.
Bravo Andy. More power to you.

Great article/story Andy, but its does seem like you are keeping them in the dark regarding cross browser issues.

Personally, when I first present a design (as HTML) to a client I present it to them using Firefox. I then educate them about certain cross browser issues and rendering differences, namely with IE. When I code, I initially code for a standards compliant browser, for me that’s the latest Firefox. I explain that the site has not yet been ‘hacked’ for IE6,7, etc, but that it is one of the final stages of development.

I then ensure that they install the latest Firefox (keep it on a thumb drive), and that they are not getting the ‘true’ design at this stage using any other browser. This is usually enough to convert the most ardent IE user towards Firefox during the weeks of the development cycle and ensures that I dont get any “wheres the rounded corners in IE?” questions during development.

By the time I have altered any CSS or scripts for a smooth ride in IE, the client is a disciple of Mozilla.

Wow, this is sooo cool – I will defo use these ideas in my next blog redesign/brothers lama farm website. THX so much!

Just one small question though – surely designs NEED to look the same in all browsers – I bought a book and have read loads of blog posts which tell me this and feel unable to move past these and adopt any new practices.

As far as I’m concerned, CSS3 may as well not exist until IE6 fully supports every module – only then will I feel safe enough to start implementing it fully on my designs.

Lastly, I have one last question – what is the difference between designing in the browsers and designing in PS? What is PS? Is it an updated version of Paint I haven’t seen? I personally design on paper -> Paint -> IE.

I hate IE5 on the Mac! Death to IE5!

Ok, enough silly talk.

Basically people, you just need to start communicated with your clients and educate them about browser inconsistencies – remember that content is king and the design is there to supplement this, not to be the one thing seen when a user visits a site. Communicate and educate, don’t just take the easy line and get stuck in existing habits.

If you love your job, you’ll want to learn and move forward. If you don’t want to learn, maybe your hearts not in it any-more.

@Dan Rubin:

Dear folks who are missing the point: First off, Andy’s talking about designing in the browser, so for those asking if it’s worth all the extra time to “code” major design changes/revisions every time the client asks, well, that’s part of Andy’s message: design in the browser and you don’t need to code your design—it’s already done.

Aren’t you missing the point here? In most cases, the designer and the web developer are two different people — in that case, designing (from scratch) in the browser is not an option.

It never fails to amaze me just how few people even understand the concept of ‘a browser’, let alone that they might be somehow different or that they render web pages differently. Most folk seem to consider the web-browser akin to the software found on their various set-to-boxes; i.e., they’re immutable things that they just don’t notice or care about.

If I get into a conversation about browser choice (and I usually try to avoid it if at all possible), it usually goes something like this:

“Have you tried Firefox? Google Chrome is nice too.”

What are they?

“They’re web browsers. You know, improved alternatives to Internet Explorer.”

What’s Internet Explorer?

“That thing you view the web on.”

Why would I want a different one? The web works fine for me.

“They’re faster, and some websites look better, and you can install extensions and stuff”

Alriiiight, how do I use them?

“Well you download and install them onto your computer…”

What does ‘download and install’ mean?

“You know what – never mind.”

So I can totally understand why users – including clients – on inferior browsers will never notice the difference. They’re just not that into computers. They are, however, into the content, and so long as they can get at that, and aren’t annoyed by not being able to do what they set out to do, all will be well.

Great article, Andy. However I’m going to disagree with you. And agree with you. All at the same time.

I really do think that there is a lot of grey here and not one way is correct. The project dictates the approach to a degree, as does the client.

Let’s take that age-old comparison for building websites – an architect. Would you expect an architect to build you a house out of bricks and then walk you through the design? No, you’d maybe want her to build you a prototype or model to show the relative dimensions and scale of a building. But you wouldn’t expect to be shown a completed building. But some clients would be happy with viewing a design on plan, others would be happy with a sketch on the back of a napkin.

For me, this isn’t a question of right or wrong, but of a scale of fidelity that has to change depending on the client, the project and the designer doing the work.

If you’re a designer working for 37signals, rapidly iterating on a piece of new functionality for Basecamp, you’re not going to work in Photoshop. If you’re designing a website or application that has a shed-load of ajax, then you should work in the browser, OR you should work in the browser to indicate that functionality at the level of comfort for you and your client. So you can show the interaction rather than explain it. However – and I go back to my fidelity example here – you should do that to the level of fidelity required for the client to understand, if that means designing in the browser with production-ready HTML and CSS, then great. But it could also be paper prototypes and some sketching.

Also, one thing to watch out for when designing in the browser and working with in-house teams that will integrate those templates into a system, is to ensure that if that’s the case, that the HTML and CSS is of production quality. Again, it requires a little step up the fidelity curve.

I guess my point is this: The level of fidelity has to be appropriate to the project, and appropriate to the client, so that the design can be understood in the intended medium. Personally, combining various tools (Photoshop, Sketching, Paper Prototyping, Lo Fi HTML prototyping) works well for me.

Good article.

The biggest thing that it communicates to me is that Mike and Sam are good clients :)

Couple of quick points:

I judge the time to jump into HTML by the nature of a project:

1) Some sites deal with brand considerations – or require an approach – that is quite minimal and typographical, which lends itself well to designing within the HTML environment, although …

2) Often, I work on projects which need quite a lot of graphical design work, where I can be more productive, and feel it is more cost effective, to work in a mixture of Photoshop and Illustrator, and then layout a design in Fireworks.

There will always be a point when it is right to jump into HTML – could be straight away, could be when some intensive graphical considerations have been resolved and signed-off.

I agree on how you approach experience variations per browser. I, like most, take into consideration the time it will take for me to ‘patch thinks up’ in older browsers when coming up with costs for a project, so – If the client is happy with my quote – I will do all I can to try and get things working and displaying “as close as possible” in the likes of IE6/7 and the like.

My sites, at this stage, are not heavily reliant enough on advanced CSS3 (through choice) to mean massive problems in finding appropriate alternative methods and solutions in older browsers. But, at the same time, I refuse to allow older browsers to stop me adopting new methods – which it seems many people are. Onwards and upwards!

The key thing here (IMHO) is client education. If the client understands the issues, either because they are enlightened or we have educated them properly, then the argument above works. If the client refuses to ‘get it’, then the issue becomes problematic.

We recently launched a site using CSS3 for rounded corner boxes amongst other things. The design was so fluid due to editorial developments it was the only way to respond quickly. All but one of the client team pointed out that IE was getting square boxes instead of rounded. Once we explained the issues they totally understood.

But we have other clients who believe firmly that IE is everything and won’t be swayed. They want their money spent on making IE look as good as possible. No matter how much we try and educate them their views are fixed. In those situations if we want to do CSS3 ‘cool stuff’ it would be out of our spare time.

No easy answers to this debate yet, but good to have the debate I believe.

I can see arguments for and against; it’s certainly not black and white.

But here’s the main thing as far as I’m concerned. Designing in the browser locks you very quickly into technical realities, so right from the off you’re constraining the possibilities. Yes constraints are indeed a good thing within design per se, but when you’re trying to make new things, working within the limitations of what’s technically possible now just limits my imagination too much.

There’s always ways to make things work. For me it’s starting out with a big idea, no matter how detached from reality and then working out how the hell to make it work. Personally designing in the browser right from the off can sometimes be too limiting.

But then I guess I’m not a big fan of reality anyway.

I don’t think that the market share of IE6 and 7 is so small that we can go down the route of not telling clients there will be differences. From a purely business-sense point of view, if you don’t mention it and then the client sees the differences on another computer (as commenters have pointed out), you will then need to explain yourself and it will look like you are making excuses.

I advise our design agency clients as follows:

In the spec simply explain that there are browsers around today that are very old technology-wise. They don’t support some of the interesting things that we can use in designs (opacity is often a good one to mention as clients understand it).

Explain that we can make the site essentially look the same in IE6 but it will involve potentially simplifying the design for all browsers and/or costing an additional amount to work with hacks and so on the get things to work. In addition these hacks may make changes to the site more costly in future.

Alternatively explain that we can allow the designers to fully embrace the possibilities offered by modern browsers and give IE6 a simpler – but still attractive – version of the site.

This then puts the decision into the client’s hands. Do they accept the additional costs and potential cost to the design for all users to get their same look in IE6 or do they accept a simpler design in IE6 and let the designers really design for the modern web? The decision can then be made part of the signed off spec for the work and it won’t come back on the design agency as a failure on their part.

Nice post, provocatively written, but my first thought on reading the article was that Sam will often comment that the layout etc is not bad but could it incorporate a softer look – maybe some gradients, rounded corners, that kind of thing.

You tackle that well in your reply by pointing out that you could do this for IE but that it will:

* Slow the site down
* Make the site less flexible for future development
* Give a diminishing return compared to other efforts

However, in my experience it’s rare enough that these arguments will win ‘Sam’ over.

IE is still dominant and many clients want these touches in their designs, regardless of whether they are comparing in browsers or not – they are comparing with their competitor sites who use image based rounded corners etc.

As for the speed, flexibility and diminishing returns, this kind of logic is often seen as nerd logic, and not entirely incorrectly.

What is the hit on speed for most connections these days and how will it impact the site when compared to having a ‘more attractive’ first impression of the site?

Flexibility too will come under fire – are you saying if we go for rounded corners we won’t be able to change this content or that content? We will be able to? So what’s the problem? Ah, if we want to change the design. So you’re saying we should take a hit on the design now in case we want to redesign later? Hmm. Flawed logic there perhaps…

Diminishing returns – I see what you’re saying – ok what are you offering me in place of these design elements and lets compare them when we know exactly what we’re talking about…

I guess what I’m saying is, great post, great debate, but I think you may have over simplified the argument.

There are certainly projects for which this is a valid approach, but I don’t think it will work as a blanket approach.

Then again, if this is your approach all the time, perhaps I’m wrong.

@Mathias Bynens,

Nobody is talking about backend development here. Front end design and backend functionality aren’t the same.

When I design in the browser, I hand off files to development so they can integrate into whatever platform it might be going in.

So I’m not really sure why you say this isn’t an option? Seems like a good option to me, which is why I do it.

@Mathias Bynes and @Jason O’Brien:

It all depends on ones definition of web designer and web developer. A web developer could be either front-end coder or back-end coder. A web designer could be just a designer or a front-end coder who also designs. Lots of web designers are the latter.

Also, designing from scratch in the browser is always an option. Just like designing websites using Illustrator and Photoshop, or Fireworks is an option.

Awesome article Andy!

Article = Bees Knees, or the kipper’s knickers (awesome).

Something that keeps coming in the comments seems very short-sighted and small-minded to me: The lack of ability to make this work with your clients doesn’t mean the plan is broken. It may be a marketing problem. If this is something you would like to happen in your company but doesn’t, you might be presenting yourself incorrectly.

Andy has done a terrific job of communicating that he’s an expert at progressive coding so that’s probably why people he works with are open to that path.

Don’t bash Andy’s ideas because your company looks like a hoop-de and your clients won’t have anything to do with that fancy-pants technology. That’s not his fault…

This tale rings so true. We recently did some layout designs, presented them to the client who liked them and signed them off. We Started to build the site, the said design had differences in IE and Firefox. This caused issues on so many levels from the client thinking we were incapable and deciding to test their site in every conceivable version of IE, FF, Safari & Opera, resulting with us then having to find multiple for different browsers.

If we’d taken the approach Andy describes it would have saved us all a massive headache, we would have been better placed to explain to the client why the site looks different in IE and FF. By presenting a static design we were basically asking for trouble from the off. I think client education from the start rather than letting them make their own assumptions on why things look different is an easier solution for all concerned.

Great article.

For me it’s important to tell the client that there are differences between the browsers and most of my clients understand that.

But there are always some pigheads, who want it being done their way. My best argument to convince them is money.

Just let the client decide:
“If you except the browser differences, it’s okay, let’s put the effort in styling for the modern browsers. If not, you have to invest more money to make IE show a similar layout like the modern browsers.”

I try to convince the client that investing money in a browser that will go down during the next years is no good idea. Showing some graphs like this helps to prove that. Or even better try to prove it with their own stats.

If that doesn’t help, do it as the client expects it and make sure you get paid for every single minute spent on improving hacking IE. I can live with that.

Ah, one more thing I’d like to know, Andy:

Do you completely skip the Photoshop/Fireworks process and design entirely in the browser or do you use these tools before you start HTML/CSS?

@Jason O’Brien,

Nobody is talking about backend development here.

Neither am I.

(Me:) No. IE uses very old technology. I can hack the site to use lots of images and other things, but that will likely slow the site down for everyone. Plus it means that I will tie the HTML to the visual layout, making the site less flexible (and expensive) to update in the future.

Sounds like covering up a half lie with another half lie. Apart from those few wrapper elements the site won’t be slower at all, and wrapper elements don’t have an impact on future flexibility. Again, the lack of complete honesty will likely hurt your relationship with the client later on.

Another interesting issue is how to adapt design changes in the code. Those who write css regularly know that going from design A to B will often leads to the shortest route rather than the best solution.

And finally, I also understand Mathias Bynens’ remark. I myself do only front-end coding. I don’t design. Can’t do it, never will. Sounds like a lot of overhead to present a live mockup to a client.

I agree with Rachel Andrew here. I’m not disputing Andy’s use of CSS3 and degradation to clunkier visuals in IE – this is totally the right thing to do – but clients should be educated about browser differences. Like Rachel said, you’ll end up looking like you were concealing things and then making excuses.

Someone suggested in an earlier comment that, when upgraded from (for example) IE6 to Firefox, clients would see the improvement and jump right on board. I feel sorry for anyone whose clients are that stupid. Anyone with a trace of sense will immediately ask “What percentage of users run IE6?”. You’ll give them a figure but add that many people are switching. “At what rate?” they’ll fire back. You have got to be honest.

I had to re-read the last section of the article after collecting my jaw from the floor and climbing back into my chair. Did Andy imply to the client that he had spent time specifically making the site work on mobile and then not billed for this time? That’s basically lying. The right response would be “Because of the way we design and code, the site works on mobile naturally and is future proof”.

I’m surprised nobody else has picked up on that.

I am amazed by some of the comments – I think it’s a clear and sensible article.

Excellent example and I’ll be diving knee deep into CSS3 as soon as possible.

People, you’re crazy! Too many folks come from old school work flows. This is the web! Technology is ever fluid. In your initial planning questions/documentation, make folks aware there are many different browsers. Back it up in the agreement. Then design & build for the medium. Stop trying to make the web “print.”

If you’re in an agency run by old school art directors and marketing people, yeah, you’ll bust your head open trying to implement this kind of thinking. But
your agency will be charging prices that are exhorbitant for what’s delivered, updates will be hell, and sooner or later, the client may realize how the agency f*cked them, and go to a modern web design outfit.

So, live and learn. This is the way of the future. If you like the past, stay there.

I’m surprised nobody else has picked up on that.

Well, maybe because nobody really thinks that part meant what you think it means.

—

Everyone here is so worried about deception, that they forget the main principle – progressive enhancement means farewell to pixel perfection. Design for IE looks ok, I woudn’t mind paying for it.

But ok, ok… I know exactly why you think it’s somehow wrong to do what Andy does.

You’re still in the “PSD → CSS → IE compat → client’s feedback ↩” frame of mind. I’ve been there, but it’s time to move on and get the rest of industry along.

Wanna impress your friends? Do they’ve never done before.

While I do think designing in the browser is the way forward, CSS3 basically turning the browser more and more into Photoshop, there’s a few things to keep in mind.

Right now(!), designing in the browser is both restricting and liberating at the same time. It is liberating in the sense that you just use whatever is available to you through CSS, be it 2.1 or 3, right now with progressive enhancement / enrichment in mind for less capable browsers. The client uses their own browser of choice to see the result and either sign off or tell you to change stuff which should be rather easy.

It’s also restricting in that you won’t use the stuff that you don’t have at hand because CSS doesn’t provide it (yet). This restriction becomes more apparent when comparing it to designing in Photoshop where basically anything is possible and designers, especially the ones coming from print, will use whatever they please.

The result, therefore, of designing in the browser can be a bit simple compared to something designed in Photoshop. A lot of clients in the real world, where you cannot simply assume the outcome to be anything like the nice story Andy tells here, just don’t want a less is more simple design and ask for a bells and whistles Photoshop version instead.

@Mathias Bynens — If you read my entire comment, you’ll realise I’m not talking about designing one way vs. another, but rather about managing clients’ expectations.

I don’t design in the browser, but I also don’t bend to clients’ will. The main point of Andy’s article isn’t that we should all design in the browser (though he might tell us that ;) but rather that we need to change our relationships with clients.

Hey Andy, Great article. I’m definitely going to have to echo Zeldman’s thoughts. I appreciate how succinct and clear your point is. This is definitely a compelling idea which I’m excited to try and put into practive.

I have been considering for some time now showing the first round of designs to a client as an actual functional website but I have to say I am fearful of that being the tweaks and adjustments most clients ask for are easier to play-around with in the design of the static jpeg representation of the site…

This is something I feel strongly about. Designing the best design for the best browser, and then slowly degrade for the crappy browsers, until when someone is using IE6 a warning just pops up telling them, they are scum and since so they have no right to look at the work you have done, until they redeem themselves by getting a life and a better browser, Now SORT IT!

Design should be the best it can possibly be. It’s like imagine having a Blu-Ray that plays the best in the best equipment, but if you had a DVD player it worked in there too, but at a lesser quality. If the person bitched about their crapper beta-max style quality at the end of the line, and you said, hey you can get a great new Blu-Ray player FOR FREE!!! They would love you, tell them to upgrade satan’s browser and you get the huff’s and puff’s of disaproval. In that case, then look at the CRAPPY VERSION!!
lol – Sorry, I have issues at work and people using IE6 – :(

Anyway, great article, thanks again Andy. Have a biscuit on me! ;)

Thanks for the tips Andy – sounds like a great plan to me.

Photoshop is amazing, but it’s a pretty silly tool for building a website.

Most print designers use quark or indesign the way Andy promotes web designers use the web browser. It makes sense. Use the right tool for the job at hand.

“Web designers have no balls.”

Thanks for the awesome post Andy. About time we look at things from this new perspective, and the more designers follow this method of development, the more quickly the non-techie world would notice the “consistently appearing differences” across different browsers thus getting rid of – “but so many sites look the same at work and at home… why not my own?”. It is recommended to educate the clients or at least notify them about the differences, and i loved the way you put it on your site too –

we’ll ask you whether you want us to spend our time and your money on workarounds for outdated web browsers such as Internet Explorer 6 or on features that will benefit your business and improve the success of your site

Yes! Thanks Andy.

I think the whole idea of “if we design in the browser… we can’t design in Photoshop/Illustrator/Fireworks/WhatHaveYou… ”

Just design quickly and be creative in your software, then get your ideas down in your head, then put it into code real fast, then it can easily bend to your will for changes.

And to paraphrase Andy… not quick with CSS? Get quicker.

Don’t stagnate people.. . this is a young, evolving field.

I enjoyed the post Andy, but I do disagree to an extent.

Firstly, that ‘ignorance is bliss’ – you’re assuming that the client doesn’t care what’s going into the product you’re delivering for them. Isn’t part of our job educating the client on what we do – and why do it? True, only to a certain level, but I don’t believe explaining why users of different browsers will view/interact with the site in a different ways exceeds that level. We’re not magicians (though Arthur C. Clarke may disagree), and assuming the client doesn’t need to know tells me that we’re no longer developing the site for them; We’re developing for ourselves so we can get pats on our backs from the community for using CSS rounded corners, drop shadows and gradients.

Secondly, this approach has the capacity to neglect your target audience. These effects are nice, but what if over half your audience are using IE6/7 (a project I worked on not too long ago)? These were not people in developing countries, or those using cracked copies of Windows and couldn’t upgrade. Office workers, schools, my Mum! (sorry Mum…)

Do we diminish their experience because it makes our job easier?

I’m all for ‘progressive enhancement’ – but not at a cost for the core audience. If I need to put in the work to realize the creative vision for the majority audience, that’s what I’ll do. Will it be enjoyable? Probably not. Does it matter? It absolutely does.

Finally, ‘designing within the browser’. From my experience, there is capacity for this to work. But it is limited. It requires a client that has faith in what you’re delivering and isn’t going to request multiple directions and multiple iterations – otherwise the initial ease and flexibility of working within the browser is simply negated. I also agree with Bren – working with your tool simply limits your vision. It’s natural – your tools are already laid out in front of you, so to speak. You already have mental and technical limitations, despite the blank canvas. I have the pleasure of working with highly talented designers on a daily basis, and it would be easy for me to point out aspects of their designs that are technically challenging – or ridiculous. They come from a different mind-set, and though they may have knowledge of development, they’re not constrained by the same experiences we are. But that ‘ridiculous’ is what pushes us further than we believe we can go.

The design is better for it, the result is better for it. Ignorance is bliss? Ignorance is what we help the client overcome. In fact, it might be just as rewarding as delivering the site itself.

“I am fearful of that being the tweaks and adjustments most clients ask for are easier to play-around with in the design of the static jpeg representation of the site”

At first, especially considering designers who are a bit uncomfortable working with CSS (I work with a few), this seems like a logical option.

But, have you ever been in the experience of working on a large brand site, where there’s well in excess of 15 basic templates (for a CMS like Joomla or Drupal), and multiple pages having variations of functionality and layout?

A “simple tweak” in a JPG becomes a WEEK LONG onslaught of digging through 15+ PSD files making the changes to all the “Rounded corner” buttons, and changing that “baby-poop” green. Then delivering the site in a stack of JPGs (that auto shrink) in their email client, causing them to call back and complain about font size, and having concerns about where the fold is…

Or, while the client is on the phone saying “Hang on just a min…”

Put them on hold, change a few selectors in the CSS. Save -> Upload and say “Okay, refresh and look now”

I think it really has to do with education.

1. Us educating our clients.
2. Designers learning to design in the medium.

I don’t think that necessarily means NOT using photoshop, but I think it means, not showing the client JPGs. I would use photoshop strictly for assets, backgrounds and major design elements, and drop them in.

I don’t think using CSS leads to boxy designs, I think uncreative designers who are used to the Photoshop only method can’t bridge the gap from Photoshop -> CSS. It just takes time and practice to adapt to that workflow. And you’ll make some kick-ass work much faster that way.

@Joseph S. – I am not entirely following why you describe designers as being stagnated by laying out design work in PSD/AI format rather than in HTML/CSS. Please correct me if I am getting the wrong end of the stick, I am known to do so.

I read a very good book recently by 24ways author Elliot Jay-Stocks on producing sexy web design. In this he describes some fantastic ways to use Photoshop tools such as layer comps and other very nice bits ‘n bobs that PS has to offer. This is just another method, another set of tools and another way to go about web design. I would be shocked to hear this approach be described as stagnated. In fact, using layer comps and smart objects and well maintained layers, designs can be very quick. Quicker than producing design work and then writing HTML/CSS for some designers.

Not that fast in Photoshop, Illustrator and other graphics packages? Get faster.

I like how this is a marmite post with a lot of agreeing and disagreeing. It is healthy to have different tools for different occassions.

“This also helps to avoid the backwards and forwards process of trial and error in client approval. Clients love this process because they feel more a part of it.”

I just have to second that. I’ve been doing that quite a lot, but remotely. While talking to the client about some changes over IM or voice chat I actually do the changes and then just ask them to reload their browser to see the changes.

At least for me, this is of course only for smaller design changes but I usually do the overall layout in wireframes which don’t really hold any graphical design etc.

It depends on the client. If they own a boutique or a music store – sure give er!

If they’re corporate or government client, and the budget for the site is in the ten’s of 000’s – well then no. There needs to be a development process, if for nothing else the client to see the work being done over time – not simply “oh here’s a website, there you go!” ;)

In the end – the client doesn’t care what our process is or which technology is used as longs the final product looks good, is usable and achieves the end goal. Whether you use PS or go straight to HTML – the point is to show something. A picture (or mark up) speaks a thousand words.

I’ve been designing like this since I first started designing websites for clients. But I don’t really design any sites larger than 10 pages.

To me though, the beauty of a website is more about the experience and not so much about what the site looks like (I may be generalizing that a bit too much, because I do love a beautiful “looking” site).

If only every client was satisfied with seeing a working version of the concept versus a screenshot/PSD. Not sure how most creatives would be able to avoid this route when it would take far more time to create several working xhtml/css comps if the first one wasn’t sufficient enough.

Seems like more work than usual if you don’t have that great client that lets you work freely with your own ideas and won’t give you too many revisions.

When it comes to not “worrying” about how the code is rendered per browser is a great concept if it can degrade nicely without straying too far from the original concept. I prefer this over completely ignoring a browser although… well, nevermind, I tend to ignore some :P

(Gah. Typed this in on my iPhone and can’t edit the whole thing. Please excuse the typos!)

Good stuff that makes solid sense if you set proper expectations with your clients. That’s the important part here.

I do design work in Photoshop. And on paper, in OmniGraffle, and in HTML/CSS (although I don’t code all that much any more.)

That’s what works for me.

Andy makes some sensible points about design process. I like to get into HTML as soon as I can as changes are easier and faster. So +1 to that.

As far as the rest? It’s all about education and building relationships with your clients. I agree that clients shouldn’t expect the same pixel-perfect version in every browse and it’s the designers job to belay those concerns if they have them.

Not sure what the controversy is.

As ever ( and I don’t mean just on here, or just the web but in life generally) people assume that what one person is proposing is the only way of doing something.
It’s not. Andy puts forward a way of working that works for him (and presumably all or most of his clients).
If it works for you, in full or in part, then great. If it doesn’t – right now – then it may in the future.
The web is constant evolving, let us do the same.
Let’s be creative about the possibilities that exist and work with them.

Andy – what cheese did you buy at the shop?

Merry Christmas

Jay

@Andy Clarke:

I can see your point. I can attest to the fact that clients can get unrealistic expectations for older browsers. I think it’s a great idea to code up a few templates in a couple hours. I would rather take a couple hours to present the site in a better way than to take weeks of frustration. I’m sure it helps during the presentation process too. A lot less questions and a lot more oh’s and ah’s.

I’m gonna try it. Thanks again!

Ok the client wants a website, why the heck would you ever show them something in PS or even the napkin sketch, that’s a million miles from the final output, “a browser.”

Of course Scribble out the design on paper or even do this scribbling in a pixel editor ( I assumed Andy had done this – unless he is that amazing he can design in his head or in pure code!) but then really nail out the design in the right output – the browser. I am sure there is some ludicrous illustration that gets my idea over better. Probably involves a iPod and a Cinema.

I’d also rather the visitors get the content and the best way to do that is with web standards.

I was ‘hired’ to do some code as the designer was impressed with my clean and clear markup and css, the big problem was he had designed something to be pixel perfect and the client expected it to work in all browsers in exactly the same way.

You know what, I don’t want to learn to hack a bad browser, I’d rather work for other clients. I spent so much time hacking for IE and then trying to ensure W3C was ok which drove me nuts.

Why wouldn’t any web designers not want to push forward standards ? Again I am sure there is some print based illustration about having to put up with a bad printer just because of market share, talk about slow down progression and innovation.

Who knows if my comment makes any sense ! Keep it up Andy.

I was going to make a joke about Adobe making a browser but then I got the fear and stopped myself !

<p>&#8220;I part-designed Mike and Sam’s site in Fireworks… Designing using Photoshop, Fireworks, Powerpoint or pencils can be just as important a part of process as HTML and CSS.&#8221; </p>

<p>Ahah! That&#8217;s how http://forabeautifulweb.com is so beautiful — it isn&#8217;t just designing in the browser, and that totally helps with creating more beautiful (and less boring) designs, while still producing live code designs for the client. That&#8217;s how I built a particular site that a client loves. Starting off in Illustrator, I had the inspiration, took it to code — showed it as a direction to the client. The client loved it, so I continued the work in the mix of tools, and it worked out. I explained upfront — in the questionnaire and agreement — about older browsers, and the client knew what to expect. I educated the client, who isn&#8217;t part of the web tech community, so they could be more informed going forward. This is part of our responsibility. They trust us to know, to inform, to make the best possible decisions for them, with their consideration. It is our responsibility.</p>

<p>&#8220;Clients love this process because they feel more a part of it.&#8221;</p>

<p>Exactly! </p>

<p>And if you and your environment can&#8217;t go this direction — fine. Write an article for 24ways next time… or write it up in your own blog. You&#8217;ll have plenty of company.</p>

<p>This is great insight into the methodology of a designer who produces inspiring work. Take from it what you will. If it doesn&#8217;t work for you, maybe you can adapt some of it. Even if all you take is making the client part of the process, instead of charging them an arm and a leg to make the design exactly the same in every browser. </p>

<p>Perhaps this discussion will educate some large corporations. I know my friend at &#8220;aol.&#8221; would love to see the company embrace this way of thinking. </p>

<p>It would save tons of money! That alone should be a great selling point.</p>

@Andy,

When changes are needed, they take, well, MINUTES to accomplish and are often made with a client sitting next to me.

Obviously, you’re talking about minor changes, not fundamental modifications to the original design — let alone, starting a new design from scratch.

I can see why the only changes clients request to your designs are tiny ones, but this doesn’t mean this is the case for every designer and for every project.

This workflow might work for your projects, but this doesn’t mean it’ll work for any web design + development project. Again — I think the situation in which there’s both a designer as well as a (front-end) developer is much more common than just one double- or triple-talented bastard doing all the work. There’s no way the front-end developer is gonna start working before the design is final (i.e. fully approved by the client). It’s called “working for free”.

This article is, sadly, a fairy tale to most people.

Signed,

Mathias Bynens
Front-end web developer
Single-talented bastard.

All those saying designing in HTML/CSS is “limiting creativity” are being extremely shortsighted and I don’t mind flat-out saying you are wrong.

Like any tool (pen and paper, canvas, Photoshop, HTML/CSS) you are only limited by your own knowledge of the medium and your inherit creativity.

If you take the view that skipping Photoshop limits your creative freedom, you’re disproving your own argument because the Photoshop files you so creatively designed will ultimately BECOME HTML/CSS. Almost anything you can think of and create in Photoshop can be recreated in the browser (obviously).

Wake up people.

sigh another commenter, buried amongst the drivel.

I’m on the fence here.

I want to give you hi-5’s in your forward-thinking design approach… from a consulting standpoint anyways. This would work in small teams, where you’re “THE DESIGN DUDE”

However, being employed as a UI designer on a UX team, I say SHUSH to you. When working with a team of developers and project managers, I would think it to be IMPOSSIBLE to code things in advance. Not only would every developer peek under the hood to find fault, but the current software development convention of WIREFRAME => REQUIREMENT => HIGHER-FIDELITY UI COMP => BUSINESS SIGN-OFF => FRONT-END DEVELOPER => DEVELOPER works very well.

We don’t draw pretty pictures to impress PM’s. We don’t draw flattened comps to look pixel-perfect. We draw partly-sussed-out concepts to better visualize what’s to be built — so everyone can get an idea BEFORE it’s coded.

Again, I LOOOVE this idea for a small boutique shop.

Damn straight!

This is a philosophy I’ve taken with our latest project and it’s worked great!

You’re using IE6? You don’t get transparency or any of that. And guess what, chances are you’re used to that kind of treatment, and more likely, you probably don’t even notice.

Once I stopped using tons of hacks and overly complex HTML to make every browser look the same, I became happier.

I’m with Andy on this… designing in the browser is the way to go.

For those of you panicking and shouting “But I’m just not as creative in a browser as I am in Photoshop!” perhaps you need to practice more. Then you’ll be faster, and more creative.

As Andy pointed out in his reply, he didn’t mention actually designing in the browser, and started in Fireworks. I do the same, but the difference from project to project is that jump-off point from FW into the browser.

No-one’s saying work 100% one way or the other. At the earliest point you can (either to keep yourself comfortable, or to keep bosses/clients/whatever happy), jump to the browser and make all amends (design and content) there.

Anyone who says it’s easier to move page elements around in PS than HTML/CSS may want to figure out how to completely split HTML from CSS – HTML for content only, and CSS for appearance will make your life much easier in the long run.

@ Mathias ,

This article is, sadly, a fairy tale to most people.

Please don’t make generalizations. They’ll get you in trouble.

You have a limited perspective on how other people design and develop. This article may be useless to you, but I use what Andy is talking about every single day.

I’ve personally never met a single-talented web developer (notice how I didn’t say “most people aren’t single-talented”). I am a designer, but knowing how to use the tools of my craft is worth its weight in gold. My design skills are useless to me if I have no idea how to turn them into HTML and CSS, the final fruits of my labor.

That’s like an architect not knowing about building materials. Or a chef who makes a mean recipe/plate design but can’t cook worth a damn.

Scary parallells….

I’m an audio composer that does site design. When doing audio “soundscapes” for a client they dont care how I shape a chord or melody, just as long as the “emotive context” is there and says what it needs to say.

Think audio and visual composers should grab a beverage of something and compare notes…

@Mathias Bynens

If someone can’t put together HTML and CSS they probably shouldn’t be a “web designer”.

@Kevin Rapley

I didn’t say using traditional design tools is stagnation… I just said, “don’t stagnate”… more to the resistance against change of the old PSD—>approval—>CSS&HTML—>Iteration—>Approval process.

I think it would be difficult to never use traditional design tools. Most of what I was saying, is that you don’t have to show your working files to your clients, you can quickly make working comps, that, once made, can easily and quickly be massaged and reiterated via their requests… Creative Suite tools aren’t necessarily quicker/slower, they are just more comfy for most.

P.S. The comment field asks me to be friendly and use Textile, but then my “quote marks” and “apostrophes” and such go wonky…

I’m all for the “use the CSS3 goodies and IE can just see it a little differently” mentality, and I’ve been going that route for a while now. However, I personally explain to my clients I’m doing this and why (faster, easier to maintain, forwards-compatiable, etc.). I’m just not comfortable making that decision without telling them, as I’m afraid it’ll come back to bite me in the ass later. I agree that most of the time, the client is none the wiser, but for me, I’d still prefer to let them know upfront.

I think the umbrella concept is spot on though its execution is situational. It must be understood when such a “need-to-know” means of communication will function properly.

From what many have already said, it has to do with speed and ability. Simply put, you’d have to be well versed in HTML and CSS to follow this path.

When the situation does not provide accuracy or speed, the concept can still remain. We must simply crack open this black box in which we design. Don’t forget “need-to-know”, but shift the thought to understanding/expressing the “have-to-know”.

The core theme is an alteration of behavior between designers, developers and their “clients”. This alteration focus on finding solutions to specific needs of specific user groups. Added transparency between those designing and those whom we design for can be just as, if not more useful in developing a successful project.

This is golden:

By showing neither a static image of my design, I set none of the false expectations that, by definition, a static Photoshop or Fireworks visual would have established.

Helps you avoid shooting yourself on the foot.

Fantastic post Andy, I agree 100%!

Regarding comments that blame clients for making this an unrealistic approach:

I think that if a client “won’t let you” design a web site unless it displays exactly the same in every browser, then unfortunately you aren’t really the designer on the project, THEY are. You’ve just been demoted to production…better update your business cards.

As a designer you need to stand up for yourself, your design and your recommendations. Trust that you have been hired based on your expertise, and don’t let the client dictate your process or your design.

If the client complains that a site displays differently in IE, educate them…they are usually pretty receptive. And if after educating them, they still insist otherwise, don’t moan about it. Adjust your fee to compensate for the time you’ll spend browser hacking, and move on to a more open-minded client. #win.

I believe this is another step in the right direction. I get sick of reading people commenting on the fact that IE6 is here and we have to deal with it.

The more we deal with it, the longer we will have to keep dealing with it.

IE7 also, it needs to be bypassed.

If a company can’t upgrade there systems to IE8 from 6 or 7 without causing a major fuss, then what are we? Dinosaurs? It’s 2010 almost – hoverboards and power laces are just around the corner.

Time to say goodbye to IE6/7 once and for all, and it’s up to us, the designer, the developer, the creative, to push it over the edge.

“If there’s something wrong, those who have the ability to take action have the responsibility to take action.”

Sounds like covering up a half lie with another half lie. Apart from those few wrapper elements the site won’t be slower at all, and wrapper elements don’t have an impact on future flexibility.

That isn’t true at all. The images required to make those rounded corners look round add up in bandwidth for complex pages. And then the images for the gradients and the processor usage needed to tile them… Oh, and heaven help you if any of it needs to use transparent pngs and you have to add filters or javascript to make it all look nice without gray backgrounds showing through. (Just to list a few very common scenarios.)

Every single one of those things adds up and when you are dealing with a browser like IE6 that is slow as molasses to begin with — throwing images, filters and javascript at it certainly doesn’t make things move faster.

As for future flexibility, every single one of those images being used to replicate things that CSS3 can do is far more time consuming, therefore costly to a client, when they have to be swapped out because a branding, color, or “we just want to freshen things up” change has to be implemented.

It’s also restricting in that you won’t use the stuff that you don’t have at hand because CSS doesn’t provide it (yet). This restriction becomes more apparent when comparing it to designing in Photoshop where basically anything is possible and designers, especially the ones coming from print, will use whatever they please.

If CSS doesn’t provide it yet, then Photoshop/Illustrator/Fireworks/Whatever isn’t going to help you make it so. If you are designing something that a browser cannot render at all in a flat file, why are you wasting that kind of time? If you are designing something that a browser can render with some fancy footwork by the front end and/or back end developers, Photoshop wasn’t the thing that made it possible. It was the talent, knowledge, and craftsmanship of the person/people who made it work for the browser.

That isn’t true at all. The images required to make those rounded corners look round add up in bandwidth for complex pages. And then the images for the gradients and the processor usage needed to tile them… Oh, and heaven help you if any of it needs to use transparent pngs and you have to add filters or javascript to make it all look nice without gray backgrounds showing through. (Just to list a few very common scenarios.)

For users with an inferior browsers … yes. Other users (Firefox, Safari, Opera) won’t notice a single thing.

As for future flexibility, every single one of those images being used to replicate things that CSS3 can do is far more time consuming

Slippery slope there. It isn’t that much work, and before you know it you’ll start cutting corners in other fields too. No matter how you look at it, you’re dropping the quality of your product. If that’s not the case, you should question the value of the rounded corners and whatever fancy css3 you’re adding.

But more than anything I’m worried about the resulting css. The bigger the change, the messier your css will turn out. It’s extremely hard to maintain a good css using advanced selectors and css3 (and just for the record, we’re still not using css3 for rounded corners, we’re using crappy browser-specific extensions with bugs and different syntax – hooray for that) and I can’t see myself adapting a design with the client right next to me, at the same time ensuring the quality of the css. It’s okay for color tweaks and very minor adjustments, but whenever positioning is involved it will mess up your css.

Finally, Andy’s Sam & Max design does in a way show the limitations of designing in a browser (even if he didn’t hint at it). Whether you like that sort of thing is a matter of taste, but I don’t really like to see the technical limitations/background in a design.

Wow, when I first read the article I knew it would stir the pot, but not this much. I guess everyone has finished up their shopping early or is this the festivous airing of grievences?

There are some great points in the comments and a lot of just plain pissing. Most of it missing the point.

That point being to stop trying to make everything look the same in every flavor of browser. Milage will very as it’s up to you how far you push it. You can go full throttle like Andy or just short. But the days of flogging our selves to get it “perfect” are long past.

It’s time to start looking to the future and building for it. After all most people will be viewing the web from a mobile device ( such as I’m doing now) in the next decade (probably sooner) and the less junk in the code the easier transition.

Though there is the whole context thing to think about, but that probably a topic for next year.

Kevin Holesh,

You have a limited perspective on how other people design and develop. This article may be useless to you, but I use what Andy is talking about every single day.

Good for you!
Where did I say Andy’s article is useless? The article itself is brilliant, and I never said differently. I’m only having my doubts when it comes to actually applying the workflow this article describes. It might work for you, and maybe for some other web designers + developers, but it surely won’t work for out for everyone. And personally, from my own experience with clients, I’m afraid that in most situations, it won’t. Hence my comments, hence this discussion.
The people who are able to work like this are very lucky, and I truly envy them.
This is what I was trying to say by stating the “fairy tale” comment. Andy’s workflow is how it should be, for everyone — no argument there!

That’s like an architect not knowing about building materials. Or a chef who makes a mean recipe/plate design but can’t cook worth a damn.

I know a good design when I see one. I can improve a design’s usability while writing front-end code. But I possess no design skills whatsoever. Are you saying that makes me a bad front-end developer?

John Leschinski,

Mathias Bynens, If someone can’t put together HTML and CSS they probably shouldn’t be a “web designer”.

I agree wholeheartedly. (Did you think that I wouldn’t?) Web designers should at the very least have basic knowledge of HTML and CSS. Sadly, this isn’t the case. At all.

However, this doesn’t mean the designer and the front-end developer always have to be the same person (and I hope you didn’t mean to say this, as it would render the “front-end web developer” job title useless).

Andy,

“Obviously, you’re talking about minor changes, not fundamental modifications to the original design — let alone, starting a new design from scratch.”
— Of course, new creative concepts take more time, but even these never need me to change HTML. Changes to layout are simple and mean only working in CSS.

How is this relevant? It doesn’t matter if you have to change HTML, CSS or both — the point is it takes time.

“This workflow might work for your projects, but this doesn’t mean it’ll work for any web design + development project. ”
— Did I infer that it would?

Why else are you mocking my “fairy tale” comment?

Oh, and web designers should learn markup and CSS. Otherwise they aren’t web designers.

I couldn’t agree more. But again, this doesn’t mean web designers should always be the one writing the CSS to their design, right? (↑ Please see my reply to Kevin, a few paragraphs up. ↑)

“There’s no way the front-end developer is gonna start working before the design is final (i.e. fully approved by the client). It’s called “working for free”.”
— Where I live, it’s called “tripe” — and that argument is full of it and based on generations old preconceptions about what designing, prototyping and developing is.

I wish it was. Sadly, that argument is a mere summary of my own experience.

A lot of people here seem to be thinking I don’t like your article or the way you present your designs to clients or something, but that’s just not true.

I agree that, for web designers with decent knowledge of HTML and CSS, designing in the browser is how it should be done.
All I’m saying is that freelancing non-designer front-end developers (like myself) usually get hired to convert a PSD (that’s already been made) into front-end code.

There must be more people like me… Do you have any tips for us as well? For example, how do we decide which ‘features’ of a design are CSS3able, and which are required?

“Mike saw rounded corners and subtle shadows in Firefox and Safari. Sam saw something equally as nice, just a little different, in Internet Explorer.”

If the IE version is equally as nice, then why add the rounded corners and subtle shadows for Moz/Webkit in the first place? Seems to me like a waste of time.

For users with an inferior browsers … yes. Other users (Firefox, Safari, Opera) won’t notice a single thing.

Inferior browsers are still the majority share. Majority. So, the majority notices your site as slow. The minority thinks it is awesome. This will change eventually (sooner than later), so why not build for the future starting now?

Slippery slope there. It isn’t that much work, and before you know it you’ll start cutting corners in other fields too. No matter how you look at it, you’re dropping the quality of your product.

No one has suggested offering an inferior product. That has never been the premise of these articles. Faster load times and more flexible design is a good thing. As newer browsers (think IE9) start offering the same things FF and Webkit do, more people experience the CSS3 bells and whistles.

As web professionals, we need to start accepting that all browsers are not going to display sites the same…that is likely to never happen, especially since CSS3 was created to allow for modular implementation. So why continue to try to make them all look exactly the same? Accept the differences, educate people on those differences, and move forward onto bigger and better things.

If that’s not the case, you should question the value of the rounded corners and whatever fancy css3 you’re adding.

If gradients, rounded corners and transparencies are critical elements of the design, then you have to throw more things at the inferior browsers, but you can do so while avoiding throwing those images, filters and Javascript at browsers that don’t require them.

The bigger the change, the messier your css will turn out. It’s extremely hard to maintain a good css using advanced selectors

#someIDhere {float: left;} changed to #someIDhere {float: right;} really doesn’t mess up your CSS at all. If you look at Meagan Fisher’s article from 12/24, you will see that the layout comps aren’t embellished with margins and padding at that stage. Once layout approval is given, then the additional embellishments are added to make it look less like a shell and more like a full design. And we are only doing it for ONE browser, the one being used to show these comps to the client, which would be a modern browser.

Finally, Andy’s Sam & Max design does in a way show the limitations of designing in a browser (even if he didn’t hint at it). Whether you like that sort of thing is a matter of taste, but I don’t really like to see the technical limitations/background in a design.

What limitation is that? If you are designing in Photoshop something that a browser cannot render at all, you are doing a disservice to your clients because it will never make it to the live site. No matter what tool you use to be creative, the browser can only do what the browser can do. The limits are there. Period.

Inferior browsers are still the majority share. Majority. So, the majority notices your site as slow. This will change eventually (sooner than later), so why not build for the future starting now?

In Andy’s example, part of the majority will notice the site as inferior. Just looked at the “buttoned” elements (where in modern browsers Andy used crappy rounded corners support – which is not future-proof either). I believe most of them will prefer “slower”, especially when slower means some background images popping up when the content is already there.

And adding images for rounded corners in an IE-only css is building for the future. When the browser dies, you remove the reference to the css in de html and tada!

As web professionals, we need to start accepting that all browsers are not going to display sites the same

Accepting this is different from not trying to achieve the best (design) quality in each browser. If you can’t get it right, sure, but if you can do it but won’t … well.

Once layout approval is given

Once layout approval is revoked, the mess starts. I honestly don’t believe that this work-flow results in equal quality css. Maybe if you can show me differently.

What limitation is that?

Whatever limitation invoked by css3. No graphical elements, simple fades, simple drop shadows. If css3 can’t do it, it can’t be in the design. Like I said, to each his own, but I’m not a fan. Doing a design without any use of background images sounds like limiting to me. Image designing the following in a browser:

http://www.webdesignerwall.com/tutorials/5-simple-but-useful-css-properties/

@Mathias Bynens

If they don’t know HTML and CSS then they are not web designers.

So on the money…

been battling with a client who thinks he’s a web designer. I think you all know the rest of the story…

Thanks, Andy!

Great article, better discussion!

Interesting article and discussion.
Every time I read about designing in the browser I think about how I would like a webkit based application that let me prototype dragging around divs that sticks to a custom grid and inserting text and images with ease. But I’m short of coding skills to materialize that. Anyone want to jump in the bandwagon?

This article was an absolute revelation, and is going to change the way I work, immediately. Thanks, mate. Really.

@John Leschinski: hehehe… So if “they” do not know “IE-hacks” and do not understand how msie buggy is, are not they (good) web designers too?
Pc+windows+ie is the “must have” thing for web designer (at least to make web pages “tests”). Sad, but true.

This article leaves much to the imagination, because of its story delivery. There’s a great tweet from Eric Meyer that I favorited awhile ago:

“What you assume about the motivations of others says a lot more about you than it does about the motivations of others.”

I’d apply this to actions, as well. As Andy said, he never did say “design in the browser.” And this is the one of the two more controversial thoughts (it would seem) about this article.

So, Andy, if you would, what would be the process for designing a site? Does it vary? Sometimes with ink & paper? Sometimes in Photoshop or Illustrator or Fireworks, or whatnot? Or?

Showing the client the design in the browser — that is a really important and useful point. It does alleviate a lot of misperceptions and helps to educate the clients. Everyone keeps learning throughout life, right?

About using modern css and not “wasting” time on out-dated browsers, that’s certainly a work environment issue. If you’ve ever worked in an established corporate environment where they are chained to proprietary products, including old out-dated software that is “optimized” (oxymoron) for IE6, and therefore are required to only use IE6 in the workplace (yes, these places do exist), then this idea won’t work. However, it’s a great idea, and eventually IE6 will be gone. It looks like IE9 is rumored to embrace web standards and css3 — and we can all hope that is true.

So, Andy, might you show a bit more of the story? Where does this story’s designer begin his creative process?

Are rounded buttons lovely for everyone? NO. Some customers will say: “Please remove these ugly rounded corners from buttons”.

Brilliantly short and sweet reminder. Right to the point. It’s important to always develop sites that work (and look as good as possible) in all browsers.

In principle I would agree with this, however in the example you show, the harboiled section of the page is quite different in the two browsers (paragraphs versus a column layout) which could well lead to a quite different experience for the end user, and if it happened to be a call to action, could have quite different results.

At what stage are you get sign off?.. I mean are you doing layout (PSD) and development (CSS) to get sign off on designs?

That would seem like a lot of throw away work, unless if you are a god and can get approval on the one design you come up with. It also seems like a lot more work upfront than simple communicating to the client that due to different browsers some rounded corners may not appear.

I’d love to be able to take this approach, and often do on freelance gigs, but for my day-to-day work, I’m working for a very large company as a frond-end developer, and don’t even get to see the graphic designs (created by an outside agency, who aren’t web designers at all – just graphic designers) until they have been signed off by the business. At least I’m not required to achieve pixel-perfection cross-browser, a few pixels of padding here and there doesn’t upset them – but they do expect it to ‘broadly match’ the GD.

This post brings up some new ways to approach the design acceptance process.

I think decisions can be made about progressive enhancement before the design is even underway. Most of my inquiries come through my contact form. Even when it’s a referral from another client, they are directed to contact me via my website. When I receive an inquiry, I can see what browser and OS they are using. This helps me makes decisions on what css I should stick with. If I receive an inquire from someone using IE6. I do not do business with them!

It’s a good idea to keep a list of clients and what browser/os they are running. If they notice that something looks nicer in another browser, I tell them that these are modern browsers that support better looking interfaces, and they should switch to a faster, more secure browser.

I think it really depends what your client’s target looks like. For a site that is most probably going to be seen in FF, Chrome and latest Safari, I believe you should let your imagination run wild(well, mostly). However, from my experience I can tell you that when you work for a company that has 70% of their audience on IE6, your requirements are completely different. And many executives in companies like that one will expect pixel perfect coding. To tell you the truth, while I completely loathe IE – and IE6 especially – I came to see each pixel perfect page as a victory against the execs at Microsoft, like a kick in the butt, if you will. But enough of my petty fantasies. I truly believe that we should work on the clients’/companies’ expectations. Yet clients/managers should know what to expect – or not to expect. Not telling things, crossing your fingers and hoping the client doesn’t meet IE6 ever might work for small projects. But when you have a QA team behind you that already has a set of guidelines and requirements, it is kind of impossible to do so.

couldn’t figure out how to qoute here.

The comment from Halina was:

“Are rounded buttons lovely for everyone? NO. Some customers will say: “Please remove these ugly rounded corners from buttons”. “

Which is very true. There is no right or wrong. Just opinions.

I could only speak for myself, but coming from a design background, I find that while designing a web page there is a great deal of experimentation as you develop your Photoshop mockup. A texture here, an image there, things that may not make the final comp but experiments that help you create something original. That seems to be lost or at least less intuitive, with this method. Even if I were a fast coder I feel I might lose that free thinking time and end up with a more rigid, less artistic page. Maybe that is where the difference lies between a web developer from a design background and a wed developer from a programming background.

Sometimes I dont think its all about speed, thats one thing I feel stifles the creative process. Does your process lock your creativity down once you mock it up as code?

I would think that its a benefit to educate each client, yes each client of the flexibility of a site in whatever browser you have coded for as you are certain to fill the gaps in before the client one day shows Sarah on her computer his new site and wonders why its not exactly how he sees it on his computer and maybe curses and complains that his site has gone pear shape.

Okay just thoughts, nothing impressing : )

That’s a great idea and we usually put all the good stuff in our sites like border-radius, and don’t tell the clients, because honestly, it would take a long time to explain it to them and they wouldn’t really care anyway. I consider it a technical detail. The problem comes when our clients don’t like the design and want something different and designing the page in HTML and CSS takes too much time to just throw it away and start again if they aren’t happy.

I have to disagree with this article in a way. I work with a ton of clients for whom position of their content is strategically important to the success of their website, whether it’s ads, or selling something, or seeing something in the column that it was supposed to be (whether textual, images, or sponsored messages).

I do agree that we need to move on and start using the newer better tools soon, but what do you do with the audiences that are not embracing the changes quickly, such as still using CRTs with 800×600 and IE 6 or worse…

This is absolutely the most important and relevant 24ways article this season.