[wpietri]

And thank goodness. If anybody knows where the grave is, I'd like to go piss on it.

As somebody who long ago did print design, I totally get why designers would want pixel-perfect control. It is awesome, but you get that in print because you are physically manufacturing an object and sending it to people. The web was device independent from the get-go. It wasn't your paper anymore; it was their screens. There were a couple of designers I came close to beating to death with their own Pantone books because they refused to get that.

Sadly, the desire for pixel perfection led to trying to force every single user on the planet to conform to the designers' weaknesses and fetish for control. For example, every Flash intro in the world. Or all of the goddamn fixed-width "experiences" that were either too wide for what users wanted their window to be or so narrow that acres of space were wasted. An approach that surely looked fine in presentation to executives, but much less well for actual users.

The great improvements in CSS have definitely helped. But I think the major changes have been the the explosion of form factors (small laptops, giant desktop monitors, tablets, phones) and the rise of a generation of designers for whom the web is a native medium. The old paradigm got harder to force at the same time there were plenty of people who were thinking in a new way.

Planck wrote, "A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it." Design, like science, proceeds one funeral at a time. So goodbye, PSD2HTML, and let's quietly put a stake through its heart so it never returns.

[reneherse]

Great writing. But as someone who also came from a different design field, I'm not sure it's obvious to new designers where and what they should start learning. It would have been great if the author had identified tools for a replacement workflow (though I'm sure Treehouse must get more into that elsewhere on their site).

I came into the world of UX and UI design by way of architecture, and it was quite a while until I found tools that really made a sensible workflow:

• Dot grid paper, index cards, pencil, and scanner for sketching & wireframing or paper prototyping (white boards too of course)

• Fireworks, Photoshop, and/or Sketch for creating graphic assets or the occasional mockup

• HAML for generating HTML

• SASS & COMPASS for creating CSS

• Foundation as a CSS framework for prototyping

• Sublime Text with Emmet(Zen Coding)

• Live Reload running on browsers in another monitor

• Git & Github to get things on the development server

My web developer partner and I sometimes refer to this as the "designer's stack".

[Edited for clarity]

[grey-area]

The tools don't really matter; it's the process which is important.

The prototype should be just that - a prototype to be thrown away after starting the product - it should not be used to translate to another medium, or as a final spec sheet which is frozen and cannot be modified during implementation. What you use to prototype doesn't matter - it could be on paper, grid paper, photoshop, HTML, whatever gets it done quickest for you and keeps the client happy. I find sketching on paper then HTML pretty good for prototyping, but whatever works.

Directly translating a static image to HTML leads to a couple of big problems - it encourages an artificial separation between design (which should be how it works, not just how it looks) and development, and it encourages the designer to imagine that their styles will survive contact with the medium and the content (they won't without modification).

[wpietri]

Yes! I have a beef with the notion of "design" as a role. It's a thinker/doer split, which is inherently problematic. Software creation is almost entirely design activity; it's just enough different sorts of design that we need a team to be able to do them all well.

For me, design artifacts are a way to communicate and a way to prime the pump so that you can start iterating in the real medium and getting real-world feedback. For both uses I'm alway seeking the minimum amount of investment in design artifacts, because as soon as the real product is live and in use, the artifacts are all candidates for recycling.

[dpeck]

Minor thing, but if you like HAML check out Slim. Very similar and does some things a little nicer.

[reneherse]

Thanks for the tip! The syntax seems quite a bit cleaner.

[cpher]

Before the casket is closed, I'd like to throw 'spacer.gif' in there with it. I don't think even the Pope can absolve me of that sin.

[troels]

You'll have to pry that from Outlooks cold dead hands ..

[eponeponepon]

Hear, hear. I'm ashamed to admit I built one or two websites this way - but then I got a job wrangling XML into EPUB, and oh my word am I sorry for my sins now.

And this:

>It wasn't your paper anymore; it was their screens.

...is something the publishing industry needs to, but seems to be pathologically unable to, appreciate.

[wpietri]

Don't feel bad; we all did. The flip side of my rant is that the early web was as ugly as sin. The desire to use it to make something beautiful was a good one, and we had to try a lot of approaches toward that. My problem wasn't that fixed-width, device-hostile designs were tried, it's that they became the dominant approach without anybody understanding what had been lost.

[Pxtl]

Ironically I think the worst culprit for the fixed-width revolution was early CSS. There was a lot more variable-width scaling pages back when everything was tables, but IE-compatible CSS made that nigh-impossible.

[wonderyak]

I wish I could work with people with your mindset. Have you considered writing on the subject? There are so many people that could benefit from your experience.

[nickpettit]

Amen. This is a wonderfully eloquent summary.

[tethis]

Let me know when you find that grave, because I'll join you after eating a huge bowl of chilli.

[theorique]

Nice image. Thanks.

(upvote nonetheless)