Prominent webdesigner Jason Santa Maria wrote an interesting article the other day about the pro’s & cons of current webdesign tools (such as Photoshop, Fireworks, etc…) and what a true webdesign application (if it were created today) would need. It’s an interesting read, so check it out at:
The author raises a lot of valid points, notably the huge disconnect between designing static pixels in Photoshop & co. and the crafting of HTML markup, CSS styles and how to resolve cross-browser inconsistencies. Jeffrey Zeldman wrote a similar article a while back and makes the point that hand-coding HTML/CSS isn’t going anywhere anytime soon. I’m of a similar opinion.
In my current workflow, I use a myriad of different tools when designing for the web.
After wireframing I’d hop into Photoshop, design all the pages (keeping browser capabilities/limitations at the back of my mind at all times) and then use Layer Comps to review the flow of the site through all the different pages. Some web-designers have begun skipping Photoshop altogether and designing straight in the browser, but I’ve found that a hybrid solution is still the best option for getting the most out of your designs.
Once the client is satisfied with the static comps I fire up Coda, write the markup to be as efficient and semantically valid as possible. With the markup done I hop into CSS, boot up all the virtual machines and alternative browsers I’d like to support and then I’m off for several hours of writing a few lines of CSS, Cmd/Ctrl-S, and then tabbing between browsers while pressing F5 to make sure my layout works.
This is a hugely time-consuming process and is usually the cause of great frustration among beginning web-designers (or designers used to the consistency of the Flash platform) – but for all its faults, it’s still the best option. All the WYSIWYG (What You See Is What You Get) tools out there either sacrifice flexibility, browser compatibility or cleanliness of the markup. Or, in the worst case, all 3.
Writing semantic, search-able markup is one of the most difficult and multifaceted jobs out there. Most hand-coders even find this to be a difficult task, weighing the different semantic options, and choosing between either making alterations to the original design, or sacrificing markup brevity to stay true to the design’s visual complexity (i.e. adding more divs). For a machine to be able to do this, it would need not only to understand the different design elements, but the content you’re designing for as well.
If I was designing such a piece of software, I’d make it work as a block-based design tool: in the design phase, you just drag & drop all the different “boxes” onto a canvas. The design remains mostly static until you come to the export phase. Then your task would be to go through each block, assign a type to it (be it a div, section, header, footer, aside, whatever), give it an id or a class-name and then change the nesting order of the tags (within reason) while the rendering engine attempts to refactor the page’s CSS to work with the changed markup.
Of course, taking browser inconsistencies into account this becomes an almost mind-bogglingly complex task for a computer to handle. With HTML/CSS, to achieve any kind of style or effect there are as many options and techniques available as there are webdesigners and webbrowsers.
To create a simple header some would use 3 divs and an h1, where others could use just a single div, an h2 and a nested span tag. And that’s just the markup, adding the myriad of possibilities CSS offers the potential amount of ways you can go about to achieve a certain style or look become infinite. Any webdesigner worth his salt will know at least 3 or 5 different ways to accomplish something in CSS. He’ll try one way first, finds it works in most browsers except in one instance, and then tries the two other coding techniques until he finds something that yields the most predictable cross-browser results.
Because of the cascading nature of CSS, almost every single situation is unique and there is almost no way of knowing beforehand which technique will yield the best results, except maybe years and years of experience. Software could never be a full substitute for something like that.
As long as our markup is critical to our client’s business needs (S.E.O. is 80% about having good, clean markup), and web-browsers continue to display subtle (or not so subtle) differences we can never in good conscience use WYSIWIG editors. Perhaps one day, when all rendering engines adhere to the same strict webstandards (or a single engine gains such market dominance and quality that all others would strive to emulate its behaviour) such a design tool could become a reality, but until then you’re still better off learning to code by hand.