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…
David | WebModia
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…