Re: [css-d] Poor CSS work processes

[Gunlaug Sørtun]

Andrew Gregory wrote:
...


Many studies have found that the earlier bugs are found, the cheaper,
 quicker, and easier they are to fix. That applies to web design too.


And the earlier web designers include this point in their
learning-process, the quicker they'll end up with cross-browser stable
designs that won't be in need of any further debugging.

I hope more of you might consider earlier testing. I expect the 
result  would be happier web designers, and more robust cross-browser

 designs.


Amen...

Georg
(designer + engineer = happy 'web carpenter')
--
http://www.gunlaug.no
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Poor CSS work processes

[Christian Heilmann]

> Many studies have found that the earlier bugs are found, the cheaper,
> quicker, and easier they are to fix. That applies to web design too.
>
> I hope more of you might consider earlier testing. I expect the result
> would be happier web designers, and more robust cross-browser designs.

What it assumes though is that the product specs and functionality are
set in stone and known. Sadly enough web design is still considered a
final "making pretty" stage in most development cycles that I have
encountered and daily changes of the screen output are not uncommon.
Furthermore it would be great if only people who know browser and user
agent concerns would touch CSS and HTML, but it seems to be public
domain, as - in enterprise level products - you will hardly be able to
control all HTML and when clients do the maintenance you will get the
inhouse designer/developer who "knows a cool tool that generates code
/ CSS" to mess with your stuff.

During the heat of the development, with once again no contingency in
the budget or time limit things can get overlooked - sometimes even on
purpose to be able to show the client that some browsers show a bad
layout and thus trying to get a new budget / second phase cleanup
project signed off.

It is easy to say "I could fix this in two seconds and they should
have thought of that' but especially the "Front End Development" part
of the development cycle is never appreciated enough, it comes from
the same budget as design and 90% of the resources and budget were
blown in designing 20 rigid screens of the homepage.

To get were you seem to think we are now we still have to make
developers, clients and project managers aware that good web design
starts before the visuals are being produced - with proper Information
Architecture and a list of what has to be developed and for whom.

--
Chris Heilmann
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
Binaries: http://www.onlinetools.org/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] Poor CSS work processes

[Paul Novitski]

At 11:27 PM 9/22/2005, Andrew Gregory wrote:
...

The problem is the work process by
which a design is only checked in one, maybe two browsers while the
development proceeds, then when everything is "finished" it is checked in
more browsers.


It's great to see this point made, Andrew (although I'm not 
absolutely sure it's on topic for this list).


A methodology I've found helpful in cross-browser development is to 
create wireframes early on:  HTML markup with Greek text and a 
stylesheet that applies only layout positioning and just enough color 
to differentiate blocks.  This is enough of a structure to test on a 
spectrum of browsers & tweak before the final text & graphics are 
ready to pour in.


Paul 


__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/