As a web developer, I have the pleasure of working with a lot of different designers. There has been a lot of industry discussion of late about designers and developers, focusing on how different we sometimes are and how the interface between our respective phases of a project (that is to say moving from a design phase into production) can sometimes become a battleground.
I don’t believe it has to be a battleground. It’s actually more like being a dance partner – our steps are different, but as long as we know our own part and have a little knowledge of our partner’s steps, it all goes together to form a cohesive dance. Albeit with less spandex and fewer sequins (although that may depend on the project in question).
As the process usually flows from design towards development, it’s most important that designers have a little knowledge of how the site is going to be built. At the specialist web development agency I’m part of, we find that designs that have been well considered from a technical perspective help to keep the project on track and on budget.
Based on that experience, I’ve put together my checklist of things that designers should consider before handing their work over to a developer to build.
Layout
One rookie mistake made by traditionally trained designers transferring to the web is to forget a web browser is not a fixed medium. Unlike designing a magazine layout or a piece of packaging, there are lots of available options to consider. Should the layout be fluid and resize with the window, or should it be set to a fixed width? If it’s fluid, which parts expand and which not? If it’s fixed, should it sit in the middle of the window or to one side?
If any part of the layout is going to be flexible (get wider and narrower as required), consider how any graphics are affected. Images don’t usually look good if displayed at anything other that their original size, so should they behave? If a column is going to get wider than it’s shown in the Photoshop comp, it may be necessary to provide separate wider versions of any background images.
Text size and content volume
A related issue is considering how the layout behaves with both different sizes of text and different volumes of content. Whilst text zooming rather than text resizing is becoming more commonplace as the default behaviour in browsers, it’s still a fundamentally important principal of web design that we are suggesting and not dictating how something should look. Designs must allow for a little give and take in the text size, and how this affects the design needs to be taken into consideration.
Keep in mind that the same font can display differently in different places and platforms. Something as simple as Times will display wider on a Mac than on Windows. However, the main impact of text resizing is the change in how much vertical space copy takes up. This is particularly important where space is limited by the design (making text bigger causes many more problems than making text smaller). Each element from headings to box-outs to navigation items and buttons needs to be able to expand at least vertically, if not horizontally as well. This may require some thought about how elements on the page may wrap onto new lines, as well as again making sure to provide extended versions of any graphical elements.
Similarly, it’s rare theses days to know exactly what content you’re working with when a site is designed. Many, if not most sites are designed as a series of templates for some kind of content management system, and so designs cannot be tweaked around any specific item of content. Designs must be able to cope with both much greater and much lesser volumes of content that might be thrown in at the lorem ipsum phase.
Particular things to watch out for are things like headings (how do they wrap onto multiple lines) and any user-generated items like usernames. It can be very easy to forget that whilst you might expect something like a username to be 8-12 characters, if the systems powering your site allow for 255 characters they’ll always be someone who’ll go there. Expect them to do so.
Again, if your site is content managed or not, consider the possibility that the structure might be expanded in the future. Consider how additional items might be added to each level of navigation. Whilst it’s rarely desirable to make significant changes without revisiting the site’s information architecture more thoroughly, it’s an inevitable fact of life that the structure needs a little bit of flexibility to change over time.
Interactions with and without JavaScript
A great number of sites now make good use of JavaScript to streamline the user interface and make everything just that touch more usable. Remember, though, that any developer worth their salt will start by building the interface without JavaScript, get it all working, and then layer that JavaScript on top. This is to allow for users viewing the site without JavaScript available or enabled in their browser.
Designers need to consider both states of any feature they’re designing – how it looks and functions with and without JavaScript. If the feature does something fancy with Ajax, consider how the same can be achieved with basic HTML forms, links and intermediary pages. These all need to be designed, because this is how some of your users will interact with the site.
Logged in and logged out states
When designing any type of web application or site that has a membership system – that is to say users can create an account and log into the site – the design will need to consider how any element is presented in both logged in and logged out states. For some items there’ll be no difference, whereas for others there may be considerable differences.
Should an item be hidden completely not logged out users? Should it look different in some way? Perhaps it should look the same, but prompt the user to log in when they interact with it. If so, what form should that prompt take on and how does the user progress through the authentication process to arrive back at the task they were originally trying to complete?
Couple logged in and logged out states with the possible absence of JavaScript, and every feature needs to be designed in four different states:
- Logged out with JavaScript available
- Logged in with JavaScript available
- Logged out without JavaScript available
- Logged in without JavaScript available
Fonts
There are three main causes of war in this world; religions, politics and fonts. I’ve said publicly before that I believe the responsibility for this falls squarely at the feet of Adobe Photoshop. Photoshop, like a mistress at a brothel, parades a vast array of ropey, yet strangely enticing typefaces past the eyes of weak, lily-livered designers, who can’t help but crumble to their curvy charms.
Yet, on the web, we have to be a little more restrained in our choice of typefaces. The purest solution is always to make the best use of the available fonts, but this isn’t always the most desirable solution from a design point of view. There are several technical solutions such as techniques that utilise Flash (like sIFR), dynamically generated images and even canvas in newer browsers. Discuss the best approach with your developer, as every different technique has different trade-offs, and this may impact the design in other ways.
Messaging
Any site that has interactive elements, from a simple contact form through to fully featured online software application, involves some kind of user messaging. By this I mean the error messages when something goes wrong and the success and thank-you messages when something goes right. These typically appear as the result of an interaction, so are easy to forget and miss off a Photoshop comp.
For every form, consider what gets displayed to the user if they make a mistake or miss something out, and also what gets displayed back when the interaction is successful. What do they see and where do the go next?
With Ajax interactions, the user doesn’t get any visual feedback of the site waiting for a response from the server unless you design it that way. Consider using a ‘waiting’ or ‘in progress’ spinner to give the user some visual feedback of any background processes. How should these look? How do they animate?
Similarly, also consider the big error pages like a 404. With luck, these won’t often be seen, but it’s at the point that they are when careful design matters the most.
Form fields
Depending on the visual style of your site, the look of a browser’s default form fields and buttons can sometimes jar. It’s understandable that many a designer wants to change the way they look. Depending on the browser in question, various things can be done to style form fields and their buttons (although it’s not as flexible as most would like).
A common request is to replace the default buttons with a graphical button. This is usually achievable in most cases, although it’s not easy to get a consistent result across all browsers – particularly when it comes to vertical positioning and the space surrounding the button. If the layout is very precise, or if space is at a premium, it’s always best to try and live with the browser’s default form controls.
Whichever way you go, it’s important to remember that in general, each form field should have a label, and each form should have a submit button. If you find that your form breaks either of those rules, you should double check.
Practical tips for handing files over
There are a couple of basic steps that a design can carry out to make sure that the developer has the best chance of implementing the design exactly as envisioned.
If working with Photoshop of Fireworks or similar comping tool, it helps to group and label layers to make it easy for a developer to see which need to be turned on and off to get to isolate parts of the page and different states of the design. Also, if you don’t work in the same office as your developer (and so they can’t quickly check with you), provide a PDF of each page and state so that your developer can see how each page should look aside from any confusion with quick layers are switched on or off. These also act as a handy quick reference that can be used without firing up Photoshop (which can kill both productivity and your machine).
Finally, provide a colour reference showing the RGB values of all the key colours used throughout the design. Without this, the developer will end up colour-picking from the comps, and could potentially end up with different colours to those you intended. Remember, for a lot of developers, working in a tool like Photoshop is like presenting a designer with an SSH terminal into a web server. It’s unfamiliar ground and easy to get things wrong. Be the expert of your own domain and help your colleagues out when they’re out of their comfort zone. That goes both ways.
In conclusion
When asked the question of how to smooth hand-over between design and development, almost everyone who has experienced this situation could come up with their own list. This one is mine, based on some of the more common experiences we have at edgeofmyseat.com. So in bullet point form, here’s my checklist for handing a design over.
- Is the layout fixed, or fluid?
- Does each element cope with expanding for larger text and more content?
- Are all the graphics large enough to cope with an area expanding?
- Does each interactive element have a state for with and without JavaScript?
- Does each element have a state for logged in and logged out users?
- How are any custom fonts being displayed? (and does the developer have the font to use?)
- Does each interactive element have error and success messages designed?
- Do all form fields have a label and each form a submit button?
- Is your Photoshop comp document well organised?
- Have you provided flat PDFs of each state?
- Have you provided a colour reference?
- Are we having fun yet?
Comments
Got something to add? You can just leave a comment.
01/12/2008
Just wanted to give a big thumbs up on the design. Very original! That said – and this is by no means a bad thing – it reminds me of the early “CSS demos” from – cripes – 8-9 years ago? The overlaying text, etc :) Still, this looks very modern and I love the way you can flip through the years. Good work.
01/12/2008
I think this new design is unique and very well thought-out. Kudos.
01/12/2008
Great Redesign. Props for the new navigation.
About the article: The bulleted list in the conclusion should be sticked in every Web development agency’s board. Not the case, unfortunately.
It’s been a long long year waiting for this to come ;).
01/12/2008
This is a valuable reference for responsible and thorough design. Great opening to the new series and seems particularly apt with the beautiful new design, which is obviously conceived with the development process very close to mind.
01/12/2008
Nice new design and a good article… I was waiting for this first day of December since long time.
—A happy man
01/12/2008
Love the design for this year. Good starting article as well. I must say, with all the discussion about designer and developer interaction lately I feel truly blessed to work with a design team that is considerate of the web as a medium and receptive to feedback.
01/12/2008
Fantastic article too :) Looking forward to the rest.
01/12/2008
Ok first off wow… Great design! I just love the time-lines on the top and left side. What great way to fashion the navigation for this site it works great.
On Drew’s post: I take a project from design to development. Guess I’m dancing with myself then. That dance admittedly becomes quite a violent footsie sometimes.
Tthis as a superb post! I’ve got a lot of talking to do with myself in the near future.
Can’t wait for tomorrow’s one
01/12/2008
Sweet design. I like it. Simple, clean, different. Nice work.
01/12/2008
Great article. I’d include a typographic summary in the handover package too. Even if when using web safe fonts I find it useful to to tell the developers specs on font size, line height, letter spacing and colour for p, h tags an other specific classes.
01/12/2008
Well the site looks great but you have no comments about the article so I feel compelled to give you positive feedback.
This article is great and I am happy that someone has sat down and actually put all this down in writing. I am going to use this at my office and although some things may not apply I have to admit that it is a very practical set of rules to go by. The check list at the end is especially brilliant and can be modified as a heads up from the developers to designers.
Thanks again this was a great read.
Cheers!
01/12/2008
Yay! And here we go for another year! Great design, and article to start with! :)
01/12/2008
Wise words indeed. Pity they weren’t heeded by the team responsible for the 24ways.org redesign. Did anyone user test the site with Javascript disabled, to see how it “looks and functions with and without Javascript”? And Opera?
The article text is present in the markup, but styled {display:none} in the CSS, until the Gods of JQuery come and sprinkle their fairy dust on it to make it readable. FOR THE PAGE CONTENT.
Sure, for some bleeding edge tech site, but on a site advocating for best practise in web design, whose first article is on using Javascript responsibly…
Epic Fail.
01/12/2008
Love the new design.
24Ways is one of my favorite Christmas-time things! Great stuff as always, and looking forward to the next 24 days.
01/12/2008
In addition to Drews checklist I think that the communication itself is very important.
If the developer does only take the design as it is but understands the goals behind it, he can often suggest better solutions (better user experience and/or less work), the designer might even not think about, because he doesn’t know whats possible.
Nice to see that 24ways ist back! The new design is not only unique, but also very inspiring in regard of whats possible with CSS and HTML. Thanks a lot for that!
01/12/2008
“Remember, though, that any developer worth their salt will start by building the interface without JavaScript, get it all working, and then layer that JavaScript on top.”
Euh, yeah, right, sure thing, like…
01/12/2008
Wow at the design, looks fresh and original, keep it up guys.
Also, love how on time you guys are =P
01/12/2008
Fantastic design this year. Just wanted to mention that the title permalink 404’s from the article page itself. Looking forward to the next 24. =)
01/12/2008
Nice article. Just one note about your sentence, “Designers need to consider both states of any feature they’re designing – how it looks and functions with and without JavaScript.” I use the “No Script” Firefox extension, and your site did not show me the article until I enabled javascript :)
01/12/2008
Agreed – loving the ‘bigness’ of the new design and focus on geometry and numbers/chronology.
01/12/2008
Drew-
Thanks for banging this out. I’ve had to convey all or parts of this at some point, but never got down to business to put it all together in one concise piece. Good one.
01/12/2008
Thrilled to see you’re back for yet another year.
01/12/2008
Don’t worry, we are of course aware that we’re not quite done with the redesign yet. We’ll be fixin’ her up over the next few days (and we have some more features to add too).
We’re fully aware and are getting it fixed.
01/12/2008
I am very glad, that there is a fantastic advent calendar, again… what else should we do until christmas? ;-)
thank you and your team for all the very interesting articles over the years – keep up the good work!
01/12/2008
Irregardless of your implementation of JavaScript, what you’ve done with not losing your focus is awesome! It’s not the same everywhere one may hover, however this is a great example of best practices and looking good. Cheers!
01/12/2008
Nice start to the next 23 days. A good recap of best practice. You’re probably already aware but the article contains multiple instances of the same ID on the page. Do I win a prize?
01/12/2008
Awesome design. I think whats been pointed out in this article is all the differences between print- and webdesign. Designers who don’t know or aren’t interrested in the way the web works shouldn’t be hired for webdesign or stick to flash.
01/12/2008
I love the christmas time: Good articles and a really good redesign! Thank you for that and for the next 23 days….
01/12/2008
Love the clean, crisp redesign. Nice work.
A lot of the designers I work with in the office (I’m primarily a front-end web developer) come from a print background, and are sometimes guilty of making the mistakes listed in this article.
This will be a great article to forward on to them.
01/12/2008
Good article, and a good checklist for any designer.
Can I bring up one pet peeve regarding fonts that has become very fashionable lately?
Helvetica Neue makes text almost ilegible in alaised text on windows platform browsers.
If it is meant to appeal to the designer crowd, then a lot of designers use PC’s and will have the font installed — it will look awful in their web browser.
01/12/2008
simple, clear, effective. can i translate it in italian an distribute among colleagues?
01/12/2008
First off: awesome job with the redesign! The navigation is just original, for one. Plus all the opacity chaos just comes all together great. Do your best to fix whatever issues are still lingering around though :)
My most favorite sentence in the entire article. Although, shouldn’t that be religion?
I’ve never worked with anybody else on my web designs before, but nevertheless this article still contains lots of meaningful tips that I should consider in all my future design endeavors.
01/12/2008
I’ve been regretting my comment above since I hit submit this morning. Wasn’t terribly gracious and I came across as a bit of a tool. My apologies.
I notice the JS issue is fixed now, thanks (although it would be great if comments could also display if Javascript is disabled) .
01/12/2008
Love the new design. Great article to begin the run down to Christmas.
I’ll be checking back on a daily basis.
01/12/2008
Layer Comps are very helpful for multiple states of a comp and are greatly appreciated on hand off to developer.
01/12/2008
Great concept!
01/12/2008
Nice! Another year with 24 geek gifts ;)
But – Did you ever had a look on your new design using FF2 or IE6? I don’t think so. That’s really horrible! The redesign was no good decision, my opinion :(
But now I’ll take a look to the content.
01/12/2008
Great redesign for a great site.
Well done Drew and Tim.
01/12/2008
Yes, of course we did. We know we’re not done yet, and we’re working on it. Fear not.
01/12/2008
Love the design but one think, I keep rubbing my eyes. It’s a bit blurry for me.
01/12/2008
Excellent writeup Drew, definitely a good read for anyone having their first run in with a developer, or vise versa.
And the design is wonderful. There will always be haters ;).
p.s. you might want to specify some way that you need to hit preview for the blog to work. I know it’s stupid, but early in the morning as it is now, it took me about 5 minutes to realize that I had to hit preview before I could submit it. Though I suppose the other 39 people got it right, ha ;).
01/12/2008
Interesting stuff, although I’d love to hear more about how to be a good dance partner (the kind of advice that’s useful for both sides of the equation. This article feels more appropriate for an organisation where there is a more distinct handover from design to development. I’ve felt for some time that this approach is risky, since a lot of the issues that can arise with a design are only apparent once you start building and using the design. That said, I bridge the gap between development and design in my workplace, so a lot of people probably have a different working environment; there are still a lot of useful things to take home here.
01/12/2008
First off – lovely design. Very original. I did notice though that Google has picked out and uses the list of years as the description for site’s entry in the search results. It might be an idea to add a meaningful meta description instead or rejig the source order to improve.
01/12/2008
Thanks Ed, we’ll have a look.
01/12/2008
This was the first thing I looked at this morning. What a lovely way to start the day! I love the look of the design. It’s clean and clear. I love the navigation. I love the way the text sits. I don’t think I could come up with adequate words to compliment you fully.
Definitely looking forward to returning every day until Christmas. Thanks!
01/12/2008
Great job on getting the site live on time. Love the design and user interface. It’s innovative and it will be interesting to follow how it goes down.
Looks pretty funky in IE6 though, and considering that makes up a mere 35% of web users, its probably ‘not’ something which would impress my clients.
One for the todo list ;)
01/12/2008
This article is very useful – I’m in the middle of compiling a similar checklist for the designers I work with – but there are some other points that need to be included as you can’t assume your designers will know these basic rules.
There are lots of design agencies setting print designers the task of designing websites when they don’t have a clue about the web. These designers will create their design in illustrator, in CMYK using a grid set to mm, and then they simply convert it into PDF format to deliver to the unsuspecting developer!
My very first points then, are that designs should be created in Photoshop or Fireworks, with a grid set in pixel units (with snap to grid on), in RGB colours. I will also ask for a list of font names, text and line-height sizes, text colours and rollover/on-states. I also need an indication of whether the site is left or center aligned (which is not always clear from the design comps).
About the new 24 ways design: I agree with Peter that it reminds me of the early CSS demos and designs of that period, but that is exactly why I love this new design. A contemporary, modern take on that classic style.
01/12/2008
Useful advice there, thanks for sharing. One addition I might make would be involving developers in the primary stages of the design process, and maintaining that relationship as you fashion your design, and then afterward, when the dev work begins. This should lead to greater understanding on both sides, and hopefully a better project overall.
01/12/2008
“for a lot of developers, working in a tool like Photoshop is like presenting a designer with an SSH terminal into a web server.”
I love this line :)
01/12/2008
Label Layers. I wonder if Santa will grant my wish this year…
01/12/2008
Great work, love the redesign.
With regards to the complaints about using this site in IE6 or with JS disabled: The audience is always an important factor in considering browser/technology support. If, for instance, this site was intended to be used by non-web-savvy users I could understand why support of IE6 would be important. But seriously people, this isn’t a web site for the faint of heart. I highly doubt the audience of this web site is 35% IE6 usage! If it is, it’s probably used only to bust balls, and not honest browsing anyways.
Love this part of the site design: I can click over to the article, while still editing my comment!
Well written Drew, and looking forward to the rest of the 24ways articles! =)
01/12/2008
Love the new design. Especially the advent stuff.
I also appreciate the bigness of everything. I’m reading this over breakfast, as I’ve always done. Being able to have my laptop safely away from my bowl of cereal and still comfortably read the article was a big bonus.
Well done.
01/12/2008
Thank you for the walk through the process from your point of view. Excellent points. And having fun is a good way to end a project!
Best regards,
Cathleen
01/12/2008
This was a great way to kick-off 24ways for another year! I’m tempted to print this article and post it in my studio for the designers to read.
01/12/2008
Design: Anything with a good clear font size works for me. The articles are meant to be read and the design certainly aids that process. So it’s a winner for me…
Content: Very interesting to hear from someone who has such a clearly defined distinction in roles. As a designer/developer it makes me rethink some of my own workflow processes. I tend to get the design to a level I can start developing and then allow the coding to affect the design. Can be good but can also be a pain. Anyway, good food for thought … thanx…
Looking forward to the rest of the series…
01/12/2008
I recently worked with a very good graphic designer and then did the coding myself. This was a new experience for me, though I’ve been ‘doing’ HTML since 1996 it’s hard to keep up with everything sometimes. I’m glad the site was pretty simple, but I guess I did a pretty good job making it look right because she asked if I’d like to code for her other projects now and then. Your checklist is right on and I love the layout and concept.
01/12/2008
I thought this site was dead. I’ve had it in my feed reader for almost a year now and no new articles. I’ll second the unique design that other commenters have made.
01/12/2008
great to see you’re back,
and awesome start for this year!
01/12/2008
I really like this list, and as a developer I know my life would be a heck of a lot easier if all the designers I’d ever worked with followed even half of these tips.
I particularly like your analogy at the end about comfort zones and areas of expertise.
Another couple notes I’d like to add would be:
- Actively point out/annotate how the content should sit on the page (fixed width/resizable, left/right/center, etc)
- Make sure that if your background image isn’t a tile, then you take into account that some people have really large screens (e.g. don’t give us a background image cropped at 1024 or something, just because that’s the size you were working at).
- It can be really handy to have a list of the fonts that you used, and also “back up” font preferences, especially for system text/content.
Really looking forward to seeing the rest of this year’s 24ways!
01/12/2008
A comment on the design, not the article, sorry.
Your date format looks at though the comments are being made on January 12th, 2008, to this American.
I understand you’re based in the UK, but maybe you’d consider international date format rather than US or UK date format?
ex: 2008-12-01
01/12/2008
Good job Drew and crew. I’m sure you’ll get the other browser bugs worked out.
My thoughts: I like the article/comments tabbed feature. My initial behavior was to read down the article some (I didn’t finish) and scroll back up to the top tab to comment, but I see you have it in the bottom as well. Nice. The other aspect I like is that it is built in such a way that it is low-bandwidth and that the primary article content is parsed by line 100. Good for SEO.
@ROWEN – yeah, you did come off somewhat like a tool, but nice recourse. Haha, you’ve got to love the internet.
02/12/2008
Nice article… and nice design
02/12/2008
OK, so we know why this layout looks like a load of crap in FF2 (hello, Camino anyone?). But there also a few more bugs:
Clicking “comments” tab at the bottom of article doesnt scroll my window back to top. I stood there a moment wondering why this some one in the first (i.e. topmost) comment is replying to some nonexistent comment. Are they reverse sorted or what? It took me quite a few seconds to realize, that I could scroll the list up, and that I wasn`t at the first comment.
Why isn`t the basic navigation visible above the fold? Yeah, nice layout. good idea, but please – I can only see days 24-12 above the fold (and I`m not using 800×600). Ok, so maybe thats not important, whatever.
But I`d like to get the old layout back. Let us opt in for it, use some briliant style switcher from the past years articles. Really, please. I loved that one, and I’ll never like this one.
And comments tracking via co.mments looks like crap too. :(
02/12/2008
Wow at the design, looks fresh and original, keep it up guys.
02/12/2008
We know we’re pushing the boundaries of current browser tech here, but if we can’t do that on a site like this, where can we? If you’re still using FF2, it’s way past time to upgrade (I’d be genuinely interested to hear of a reason why you couldn’t – you get that with IE6 a lot, but not FF2).
The latest version of Camino supports RGBA – in fact that’s what I personally use to browse. Again, time to upgrade.
It should do – I made that addition about 12 hours ago. You may need to do a hard refresh.
Two reasons.
1) that’s not the basic navigation. It’s supplementary, and absolutely not required to navigate the site
2) there is no fold.
02/12/2008
May I suggest a print stylesheet where all the dispensable fluff is removed? I just wanted to print the page to read in a break, but it’s a fail.
02/12/2008
Latest stable version of Camino still runs on gecko 1.8, so theres no RGBA here.
The comments issue is fixed, that`s right.
(still – I liked the old layout more) ;-)
02/12/2008
Comment permalinks doesn`t work (how can they – comments are invisible untill tab is selected)
02/12/2008
Thanks – that’s now fixed.
The Camino ‘nightly’ releases of version 2 have been stable for months – I’d recommend upgrading. The 1.6 branch is really old.
02/12/2008
Great article.
Also, looks like there are a few design woes in Firefox 2.0 (courtesy of a few co-workers who haven’t upgraded).
02/12/2008
Great article. Thanks.
02/12/2008
Great job on the redesign! Don’t let the naysayers dampen your Christmas spirits. You’ve done something innovative, and well-deserving of applause!
(You might want to check it out in Epiphany 2.22 and Avant 11.7 though. Seriously, come on.)
03/12/2008
Fantastic redesign!
Looking forward to the next few weeks!
03/12/2008
I’m liking the new design, a little slow on the scrolling but I can deal with it.
I think I’ll be sharing this article around with my fellow designers!
03/12/2008
NIce stuff, good and interesting article. I actually learn something today from this article, that I’m on my way to try…
Thanks
04/12/2008
“it’s way past time to upgrade (I’d be genuinely interested to hear of a reason why you couldn’t – you get that with IE6 a lot, but not FF2).”
My mom is stuck with FF2 because her Mac only has OS X 10.3 on it. I really need to upgrade it to Tiger for her soon. It surprised me that she couldn’t get FF3, but then I realized that she’s 3+ years behind on the OS.
04/12/2008
Super article, thank you. Wonderful, just wonderful re-design, I want to pull it from the screen and hug it.
10/12/2008
This design is truly awesome – congrats!
I’m a bit dumbfounded though that Opera 9.6x does such a poor job of displaying the intended design. Luckily I have Opera 10 beta installed and that version displays this website just like Firefox and Safari on Windows. IE6 for once does a better job than Opera 9.6x in a “I’m doing my darndest to display this high-tech design, and it came out rather good!” kind of way.
Lots of Advent-reading, thanx ;-)
17/12/2008
Good Article. One query though. Are there any stats available regarding what percent of users have javascript turned off? Should there be time and effort spent on having alternative solutions for the same?
17/12/2008
Every site will have their own stats based on audience – but sometimes it can be as high as 15%.
However, the rules of progressive enhancement remind us that working without JavaScript isn’t an ‘alternative’ solution. It’s the primary, basic solution. On top of that we add JavaScript for where support is available.
25/12/2008
The programmer who I work with recommended me to read this article and I think that it’s fantastic. But both partners would need to know eachothers steps in this dance ;-)
When the next article??
11/01/2009
Great article! I was nodding in agreement all the way through.
I’d add a couple of things to your list:
If the designer is using a particular non-web font for some elements to match the brand font (designers often seem to do this with navigation items) and there’s therefore a requirement for the developer to create graphics with HTML image replacement – has the designer created all the states (including hover and current) for each of the nav items? Saves the developer having to delve into the photoshop file and create them all – especially if the designer has used all sorts of shading and special effects that only they can recall and recreate.
Designers often seem to forget to style up all the basic content elements. I would include the following as mandatory:
* lists (ordered and unordered)
* headers – at least h1-h3, but preferably h1-h6 in case the client goes crazy with nested headings when they do the content loading
* a standard table layout for any tabular data the client might want to include
* image treatments – eg floated left/right, dropshadows etc and how the designer sees these being used by the client when they have free-reign in the CMS content-loading stage. For example – if image treatment includes a drop-shadow, has the designer considered both portrait- and landscape-shaped images and created a drop-shadow for each – assuming they are only allowing images of specific dimensions? If they will be allowing the client to add images of any dimension the developer needs to know this so that they can style drop-shadows for images of any size – which as we know is quite a lot more work…
I would also encourage designers to work to a grid and ensure that all their edges line up. There’s nothing more annoying for this developer than having to to re-make background images because the designer hasn’t bothered to line everything up and their background boxes are a pixel or two out.
Finally, I would absolutely agree that it makes financial sense to involve the developer right from the start. We can advise on which design elements are likely to cost more than the budget will allow, and we can often come up with sensible ways of achieving the IA in design without blowing the budget once it gets to the development stage.
05/02/2009
…oh what a nice world if there was an unique moz-browser! ;)
26/02/2009
Great post.I find this blog accidentally ,I am praparing to design a new blog theme,and I think here could give me much help
05/03/2009
Yeah, kudos to the design.
I totally agree with Alison, hover and active states as well as the content elements are mandatorey for a screen designer.
But yikes! Do you really want to have a .pdf as quick reference guide?! I definitely disagree with you here.
For quick reference, I prefer .pngs with meaningful names, they come in way more handy than a .pdf would ever do, when it comes down to accurate production, at least for me.
Kind regards,
mt
26/06/2009
Great suggestion about handing over a color chart. I always used to get frustrated that developers would add their own colors on form components that were a poor match to site template. Then, as you alluded to, I discovered that just because I love photoshop for web design-storming doesn’t mean that the code-jockeys do.
I started handing over the color keys and all became right in the world.
Another technique that sometimes works (if you have open minded developers) is to allow the designers to pre-design everything including mockups of the forms and interfaces. This can be done as early as the spec creation and can be of tremendous benefit to the sales team when finalizing projects with clients. This mockup can be used through the entire life cycle.
Impress us