Book your place only £325.00
-
Birmingham, UK
April 1st, 2010
Book now
Excludes VAT.
Photo credit: © John Morrison / Subism StudiosTime to stop showing clients static design visuals
Demonstrating our designs to clients as XHTML/CSS pages rather than as static Photoshop or Fireworks has streamlined our workflow and helped us to set and manage a client’s expectations better than ever before.
The biggest headaches for web designers and developers often come not from design, or from writing meaningful markup and CSS but from browser related issues. I'll assume and hope that you are already writing markup for the maximum meaning rather than simply to achieve a visual result. I also hope that you use all of the available CSS selectors to help you avoid filling your markup with presentational elements and attributes. After-all that is the real goal of CSS 2.1 and CSS 3 selectors; to enable you to target an element for styling without needing to add a specific class or id.
Take this quotation example from my demonstration page.
<blockquote>
<p>{Quotation} Dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua enim ad minim.</p>
<ul>
<li><a href="#">{Author}</a></li>
<li><a href="#">More reviews</a></li>
</ul>
</blockquote>
For my ideal design I would like to add { border-right : 1px solid #bfbfbf; } to the first list item but not the second. Of course I could add class="last-child" to my markup and specific CSS for that class to remove the border from that list item, but that would defeat the purpose of the CSS last-child selector and help only abandoned browsers that did not implement it (Internet Explorer 6, I'm looking your way).
What is the worst that can happen for people using IE6? They see an extra border on the second list item. As this is not a critical design element I can live with that.
Moving beyond progressive enhancement
I've written a lot about how it's time to move beyond progressive enhancement (where the least capable browser in your browser support chart is your benchmark) and instead we should design for people using the best browsers first. With many parts of CSS 3 already being widely implemented and some browser makers working hard to propose and implement new features, it's a really exiting time to be a designer working with CSS.
Many of the methods that we were forced to use to achieve particular visual results are simply not there anymore. Take rounded corners. I know I'm not alone in previously adding presentational elements (or inserting them into the DOM using JavaScript) simply to create a rounded corner box. Thankfully those days are largely behind us and we can rely on border-radius to take care of things, leaving markup free from presentational elements.
.content-sub blockquote {
padding : 20px;
background-color : #f8f7f3;
border : 1px solid #bfbfbf;
border-radius : 10px;
-moz-border-radius : 10px; /* Mozilla */
-webkit-border-radius : 10px; /* Webkit */
}
By now I can almost hear you thinking But what about Internet Explorer 6, that browser didn't support last-child? What about IE and Opera that haven't implemented border-radius yet?
. You're probably also thinking that you can't use a CSS selector or property until it's been implemented in all browsers and that those that don't have faded away. Am I right?
But what is the worst that can happen for people using Internet Explorer or Opera? They see square rather than rounded corners. As this is not a critical design element I can live with that too and so can the designers of the new Twitter interface.
I've heard from many designers and developers that they really do understand that web sites need not look exactly the same in all browsers, but that clients (internal and external) still cling to this outdated notion. These clients often don't realize that designing for the web involves making designs that are more flexible and portable than it is about pixel perfect rendering across different browsers.
One of the main reasons why many people cling to the expectation that a web design should look the same across every browser is that one of the first things that designers show them is a carefully crafted static design made in Photoshop or Fireworks. Both of these are fantastic design tools, but the static JPG, PNG or TIFF files that they export are far from ideal tools for helping a client really understand how their pages will look and function when implemented in markup and CSS.
The problems with static visuals
While static visuals are useful for conveying look-and-feel, they are less than useful in conveying how a page will look and function when implemented in markup and CSS. Without a great deal of effort and perhaps multiple design files, static visuals cannot demonstrate:
- the effects of liquid layouts
- what will happen when text sizes are changed
- the font stack
- browser inconsistencies
- simple interaction such as
:hoverand:target - JavaScript behaviors or dynamic AJAX content
Worse still are the expectations that static visuals set in the minds of clients, particularly when designers use these visuals as a method to get sign-off for a design. Is the fact that so many web pages are fixed width and centered a direct result of clients signing off fixed width design visuals?
I would even go so far as to say that when you demonstrate a design as a static image you are reinforcing a mistaken notion that a web page will be a facsimile of a frozen image. And when you demonstrate a design or ask for sign-off on a frozen image, you immediately leave yourself open to the problems that so often come when you need to implement that design using markup and CSS.
So what can you do to help change client perceptions, alleviate problems and allow you to use the stripped down, minimal markup and CSS that you know you really want to? The answer is to demonstrate your designs through the medium that they will ultimately be seen through.
Stop showing clients static design visuals
I've been making and advocating markup and CSS prototypes for a long time and it was a huge part of Transcending CSS. Since I wrote that book I've taken my ideas a stage further and I few months ago I started experimenting with removing static images from my demonstration/approval process. While I still use Fireworks to create my look-and-feel designs and layouts, now more often than not these static designs stay inside the studio and the first thing that my clients see is a web page in their browser. This has had several advantages.
As I work almost as fast in markup and CSS as I do in Fireworks, I find that the overall time that I take designing and implementing that design is dramatically reduced as I am not duplicating work. It leaves me free to spend more time on fine tuning a design and I'm sure that my designs are all the better for that.
I spend less time explaining to my clients how a page or an interface will work as they can readily interact with a page in their browser, now matter how old or capable that might be.
What you see is what you sign off
And that brings me right back around to where I started. I am passionate about using as many (often referred to) modern CSS selectors as I can, both to save me from using presentational markup and to make the best design I can for people using the best browsers. By not demonstrating my designs as images I can do all these things and more. Plus, I really don't have to worry about a client not seeing border-radius generated rounded corners if they themselves use Internet Explorer or Opera, because they simply do not know that something is missing. Most importantly there are no no misconceptions. What they see first and sign off is so close to the final product as makes no difference.
There are always occasions where different people on the same client team use different browsers, or perhaps my client uses Internet Explorer at work and Firefox at home. I handle this by explaining simply that not all browsers are made by the same people and some browsers do things differently to others. I also explain that there are also differences in the fonts that people may have installed and a difference in gamma between Macs and PCs. When people see that there are many differentiating factors, they accept visual differences between browsers much more readily.
I think that the main reason why this approach has worked so effectively is that I do not set false expectations that a design should look the same across all browsers, platforms and devices. It has been approach that has worked very well for me and one that has paid real dividends. I know that these issues are not the same for everybody, but I encourage you to give it a try, perhaps with your next client or project. I'd love to hear how you fair.
