[...] In fact, in most cases, the things we considered best practices were leading to the bad outcomes we sought to avoid. I realized (unpopular though it might be), that we couldn’t make it work out well by trying harder. Each time we start a new project, we think “this time, I’m going to keep the code clean. This time the project will be a shining example of what can be done with CSS.” And without fail, over time, as more content and features are added to the site, the code becomes a spaghetti tangle of duplication and unpredictability.

I was linked to this in the comments of my previous post and a lot of the points in this article rang true to me.

Web (front-end) developers are constantly trying to walk a tight-rope between semantic purity, standards compliance, writing flexible, maintainable code and just getting the job done in time.

Naturally, this didn’t work. Many influential webdesigners have already slammed the app’s many shortcomings – both technical and conceptual, so I won’t bother to repeat their perfectly valid criticisms. Suffice to say, I wouldn’t recommend it.

As far as I’m concerned, Muse’s biggest shortcoming is the absolutely attrocious quality of the HTML code it generates. But even if Adobe fixed that, by for example switching to a better layout framework and reduced the amount of code by 80%, it would still be a poor substitute for a skillful webdesigner and a text-editor. The reason for this? Semantics.

Jeffrey Zeldman wrote a post last year entitled “An indesign for HTML and CSS”:

But Nack’s “constructive” suggestion for Adobe, quoting Michael Slade, is to create “the modern day equivalent of Illustrator and PageMaker for CSS, HTML5 and JavaScript.”

Nack acknowledges that this will be difficult. I propose that it will be impossible. Says Nack:

As I noted the other day, “Almost no one would look inside, say, an EPS file and harrumph, ‘Well, that’s not how I’d write PostScript’–but they absolutely do that with HTML.”

Well, there is a reason they absolutely do that with HTML. PostScript is a programming language designed to describe page layouts and text shapes in a world of known, fixed dimensions (the world of print), with no underlying semantics. PostScript doesn’t care whether an element is a paragraph, a headline, or a list item. It doesn’t care if a bit of content on one page cites another bit of content on a different page. PostScript is a visual plotting language. And HTML is anything but.

HTML isn’t just a collection of blocks representing pretty pictures: it describes a document, whose content is meant to be consumable by just about anything. A properly written and formatted HTML document should remain human-readable even when viewing the raw source-code. This is an incredibly vital advantage of HTML over other technologies, and to just discard this like a used hankerchief, when the semantic web is right around the corner is hugely irresponsible on Adobe’s part.

Adobe is essentially lying to untold numbers of print-designers by telling them “Yes, you could – nay, should – be making websites, even if you can’t code”. And this my friends, could only lead to calamity: can you imagine handing Muse-generated HTML off to a back-end developer to integrate? He’d laugh you out of the room! For all Adobe’s claims to the contrary they are actually widening the gap between designers and developers with every new release.

Indesign can now export Flash sites, DVD menus and those god-awful iPad magazines that are nothing but 500MB zips of “interactive” Jpegs (magazines that, by the way, will look like absolute arse when Apple decides to release a retina-display packing iPad). I’m betting the only reason they didn’t release Muse as an Indesign plugin was because Indesign isn’t included in the Web-Premium Creative Suite.

Adobe’s philosophy that (print-)designers should never have to learn anything other than graphic design is hurting every single app in the creative suite today. Every release, more and more features no professional actually uses are added to already overly complicated and bloated apps.

“Look!” they’ll say, “without a single line of code I can use inverse-kinematics in Flash!” For a sales pitch that’s a pretty compelling feature. A feature noone uses of course, because full-on character animation is rare in a webdesign workflow – and the professionals I know still do it by hand.

But the feature’s there, and it’s taking up space in your tool-palette, memory, keyboard-shortcuts and even required a rewrite of the Flash IDE which means it now consumes 3 to 10% of your CPU (depending on how fast your machine is) at all times, wether you’re doing something or not. And I’m sure you can give exampes of similarly useless features across the entire suite.

Bloat and inefficiency aren’t even the worst side-effects of these additions: it’s the fact that with every year that passes, the barrier for creative people to get into these apps gets higher and higher. Flash went from being the easiest animation-tool ever to a hugely complicated development framework spread accross three different apps, and multiple programming languages. The animation-tool is still there of course, but it’s become so bloated, so slow and so unstable that I doubt it could ever enthrall newbies like it enthralled me all those years ago.

Same thing with Dreamweaver: I learnt a great deal about webdesign and hand-coding from toying with Dreamweaver’s design-view. I didn’t realize that tables for layout was bad, but then – noone really did back then. I just drew the layout and then switched to code-view to see how it’s done. I taught myself a great deal about then-contemporary webdesign techniques, and after a while I switched to hand-coding entirely, simply because it was faster that way. I’ve been teaching myself how to code better HTML and CSS ever since.

Muse doesn’t even have a code-view.

Thanks to Photoshop, Flash and Dreamweaver I taught myself how to design, how to animate and how to code, which now means that, given a copy of the Creative Suite (or any similar tool, honestly) and time, I could single-handedly build almost anything I can think of. I fear creatives growing up in Adobe’s vision of the future will never be able to say that.

Jason Santa Maria - A Real Web Design Application

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:

http://jasonsantamaria.com/articles/a-real-web-design-application/

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.

Some of my favourite webdesign tools

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.