
PSD to HTML is Dead - nickpettit
http://blog.teamtreehouse.com/psd-to-html-is-dead
======
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.

------
reuven
It drives me totally batty to work on projects in which the designer assumes
that their only responsibility is to provide a PSD file, which the developers
will then turn into HTML and CSS.

I want to work not just with designers, but with _Web_ designers, who
intimately understand the workings of HTML, CSS, some JavaScript, and the
implications for different browser sizes and versions. Web designers speak
HTML/CSS natively, taking these limitations and issues into account when
they're creating their designs. And if something needs to change, they can
change the HTML/CSS that was created. If the designer only knows how to work
with Photoshop, every change to the site requires a great deal of additional
work and communication.

I've sometimes remarked that a designer who uses Photoshop, but who doesn't
know HTML and CSS, is like a photographer who refuses to actually touch the
camera, and instead tells someone else how to aim, focus, and shoot. (And yes,
I'm aware that TV and movies work this way; the analogy is far from perfect.)
I want to work with someone who lives and breathes Web technologies, not who
sees them as just another type of output. I'm glad that this blogger made this
point, and has indicated that while Photoshop might once have been acceptable,
it no longer is.

~~~
crazygringo
As someone who's done a huge amount of front-end development, I disagree
completely, at least when we're talking about graphic design (as opposed to
interface design, and even then it depends).

The job of a good designer is to come up with a "look" for a page that feels a
certain way, that communicates certain ideas, with careful consideration of
clarity and emphasis. Their skillset is emotion and communication. Knowing the
technology beneath it helps them exactly zero in this, except in just a few
instances of knowing what is and is not technically possible in the browser.

In fact, I have found it _more_ difficult to work with designers who have
learned some HTML/CSS, because it's a case of 'a little knowledge is a
dangerous thing' \-- writing HTML/CSS for a blog is a totally different thing
from creating a clean, extensible front-end architecture for a large site, and
you're constantly having to explain to them that, yes, you can do that on your
blog, but it's not that simple to implement on our site, because this
component is used in multiple ways in different places, and no you may NOT
edit our source code directly, because changing the <h1> on that page will
change it on the whole site, which is not what you're intending. Or it breaks
the object-oriented CSS model we're using.

The only thing I ask from designers who provide PSD files, is that they
remember to draw hover states as well, and explicitly indicate what happens to
text that will inevitably outgrow the area they've given it -- should there be
ellipses, should it expand downwards, should there be a character limit, or
what. And to stick around afterwards so I can ask them about if
inconsistencies in their design, like close-but-not-exact font sizes or
spacings, are actually intended. Really, that's about it.

And the analogy of a designer who uses Photoshop but doesn't know HTML/CSS is
like a photographer who doesn't use a camera is just plain silly. Photoshop
_is_ their "camera". The end result is just pixels in a browser anyways, it's
not like they're giving us webpages on oil canvases. And guess what -- print
designers don't know how to run printing-press machinery either. Because
Photoshop/Illustrator/etc. are _their_ "cameras" as well.

~~~
sgustard
There's lots of middle ground. Designers knowing what are web-safe fonts, or
how big most users' screens are, are fundamentals that I've still seen
lacking.

------
tomatohs
This article should be titled "the slice tool is dead."

The slice tool represents the direct transformation of raster image to
website. We all know that this isn't possible anymore because of mobile,
retina, etc.

But Photoshop and image editors still provide tremendous value to the web
development process for mockups, image assets, colors, etc.

What this article is trying to say is that the process of turning a design
into a website has become much more difficult. A PSD is no longer a final
deliverable but the beginning of a conversation.

Now design needs to be functional. Instead of taking the static image you get
from a PSD, you need to ask "What does this look like on mobile? What about
huge resolutions? What if we don't have that content?"

The article suggests that this process will be improved by designing in the
browser thanks to CSS3.

The truth is that the browser has just barely hit the minimum requirements to
be able to make design decisions. Have you seen the Chrome color picker? It's
alright for choosing a border color but final design work can not be done
entirely in the browser just yet.

~~~
eropple
I get where you're going with this, but I personally find a grid framework and
CodeKit auto-reload to be a better way to do mockups in most cases. It's
nicest with two monitors; I make changes on my screen and we can both look
together at the changes in the browser.

I don't really care about having a nice color picker when punching in a value
into Less is so easy (and if I really want something visual I use either
[http://colourco.de](http://colourco.de) or
[http://colorschemedesigner.com/](http://colorschemedesigner.com/) . I don't
care about shapes because I'm working in the grid. I get what I need, faster
and cleaner, than screwing around in Photoshop.

------
Trufa
I'm a little bit confused of the workflow they are suggesting.

I'm a web developer with "good design taste" but I definitely can't design
myself, I always pair up with a designer that does the PSD.

But of course this doesn't mean that when I see a navbar that has a gradient I
copy a paste the image of the navbar in my website with a <img>, my job is
porting this images to HTML, CSS and JS.

If you're actually putting images from the PSD, you're definitely doing it
wrong, but in my case, I still need a highly detailed design that I can make a
website, otherwise I have to design it myself, wireframes only get you that
far.

When I'm working with a good designer, that knows about how the web works, I
feel it's a great workflow.

~~~
yogo
You're doing it the right way. The PSD is a blueprint for what the end result
should look like. You implement it the best way possible for use in the
browser (gradients, border-radius, etc.). For responsive, either the designer
puts together comps for the various breakpoints or there is a discussion about
how the main comp will change at various resolutions.

The point about bootstap made in the article I only see as relevant where your
goal is to have something that looks standard or use a theme for bootstrap,
for anything unique or visually appealing it's often faster to play with
certain concepts in photoshop before building it out.

None of these things are really a problem if the designer is really a _web_
designer. You can be backed into a corner real fast when you have print
designers designing for the web.

------
rwhitman
I swear I feel like I've read a version this article once a year since the
advent of CSS. This is a naively utopian vision of the future. The
designer/developer is a very rare breed outside of the HN community. Most
designers can't / won't write markup or CSS, and most developers are piss poor
designers. The design->planning->building segmented workflow will always
exist, as it has in all engineering disciplines since the dawn of human
civilization.

~~~
muglug
As much as the idealist in me would love to disagree, this is the fundamental
problem.

As stated elsewhere in this thread, agency clients are used to a diet of
static Photoshop mockups, and I can't see that expectation changing anytime
soon.

What _might_ change are the tools - it's in designers' interests to save time,
and tools that allow designers to create mockups for different screen sizes
whilst still maintaining the flexibility of Photoshop are beginning to emerge.
But it'll take a few years, at least, for those tools to reach maturity and
enjoy widespread usage.

------
bbx
I'm currently redesigning a backend interface, and it's the 1st time since
I've started my Front-End career (7 years ago) that I'm not using Photoshop
_at all_. I'm just using Bootstrap, Sublime Text, and Chrome.

For many projects of course, it won't be sufficient: clients want (and
probably need) a stunning Photoshop mockup to provide feedback and boost their
self-assurance.

But if you combine a simple CSS framework (even if it's just for a grid
system), Chrome's inspector, a selection of Google Fonts, and some sense of
"flat" aesthetics, you can come up with a more than decent, and sometimes
amazing, design. Plus, it takes 70% less time, especially considering it's
usable _right now_.

37signals mentioned this "skipping Photoshop" attitude in 2008 [1], but I
never quite managed to put it into practice until recently.

[1] [http://37signals.com/svn/posts/1061-why-we-skip-
photoshop](http://37signals.com/svn/posts/1061-why-we-skip-photoshop)

------
elorant
As a developer I hope that CSS would share a similar fate sometime in the not
too distant future. It’s freaking hideous, doesn’t work as it should and in
order to build any decent modern site you end up writing something like 5,000
LoC. Nine out of ten times I want to do something with CSS I prefer doing it
with JavaScript.

~~~
minimaxir
When you have modern CSS frameworks like Bootstrap and Foundation available,
the CSS aspect of a website is arguably one of the least complicated aspects
of front-end development. (and better for the users instead of using
JavaScript)

Even animations are easier to do in CSS due to CSS3 animation libraries.

~~~
sp332
Bootstrap _is_ javascript.

~~~
minimaxir
No it isn't. The majority of the Bootstrap framework is CSS. (there's an
_optional_ JavaScript component for advanced functionality)

~~~
ptx
Maybe he's using Netscape 4, in which case CSS would also be JavaScript, more
or less.
[http://www.netmechanic.com/news/vol4/css_no17.htm](http://www.netmechanic.com/news/vol4/css_no17.htm)

------
efsavage
I disagree. In the hands of a competent web designer, photoshop is still the
most expressive tool available. I've been bouncing PSDs with a designer for
the past couple of weeks and I want him being creative and making something
beautiful, not constantly worrying about how the images are going to get
sliced up or sprited or what's svg and what's not. That's my job. So long as
there is in iterative process in place where I can keep him within the bounds
of reality, it all works out very well in the end.

~~~
colmvp
Finally someone who gets it.

I first started out with Photoshop, then learned a bit of Rails and front-end
code. Now I use both.

Photoshop makes it super easy to design things quickly and iterate different
concepts. It's also great for storyboarding effects before trying to finesse
them.

And then when it comes to coding it up, that's when I get more particular
about element positioning.

~~~
randomdata
I'm with you. Photoshop is just a rapid visualization tool to make sure the
concepts in my head are sane. Often they don't quite work out as I picture
them, so Photoshop makes it easy to quickly iterate on alternative forms. Once
I'm confident in the direction I'm going, I'll switch to actual
implementation, often not even finishing what I was working on in Photoshop.

Using Photoshop to slice images up into pieces and reassemble them again in
HTML is dead, but I think that process has been dead for more than a decade
now. Photoshop itself is still quite useful though and many of its features
map quite well to CSS.

------
tn13
Thanks goodness. My life was hell when I was working for an Indian outsourcing
giant where they made web application like an assembly line.

The designer were hired from school which taught only print media design. They
made PSD mockups which arrived at frontend developers who would then make HTML
out of it with dummy data.

For example say you are designing a charting app for a banking company, They
would create pie chart in PSD and then ask the frontend devs to convert into
HTML. So these people use to put those charts as image. When it arrived with
us the backend team, we use to realize that this graph needs to be dynamic. If
we use any other charting library it use to look ugly with overall design.

Not to mention if the webpage does not look pixel perfect in FF and IE it
would go as a bug. Countless human hours were wasted in making corners round
in IE.

The real interesting part was that, the baking giant did not give a shit about
the design in first place neither about the browser compatibility. It was
meant for their say 30-40 employees who could simply switch to FF if they did
not like sharp edges in IE.

In the battle of egos between the designer and testers we were screwed.

------
danboarder
Photoshop may be dead as a starting point, but not quite dead as an
intermediate step for customized template design. A workflow that works today
for quick site turnaround in commercial web design is to screenshot a
Wordpress or other CMS responsive template, bring that into Photoshop, drop in
branding, color changes, and replace content to produce a comp for
presentation to clients. It is still quicker to make design changes in this
Photoshop intermediate phase. Once the design is signed off, it's fairly easy
to customize the CSS in the original template and arrive at a branded site the
client is happy with.

------
callmevlad
The pain of the PSD->HTML workflow, especially around responsive design, is
one of the reasons we're working on Webflow
([https://webflow.com](https://webflow.com)). While Photoshop will have a
critical role in web design for a long time to come, having to deal with
multi-resolution elements is extremely tedious.

Also, Photoshop layer styles are way behind what's actually possible with CSS3
these days (multiple shadows, multiple background images, etc), so designers
who have to implement a website end up doing their work twice. With a tool
like Webflow, implementation work is part of the designer's workflow, so once
something looks good on screen, it's actually ready to ship.

Granted, designers have to learn the base concepts of how content flows in a
website (the box model), but I think that's a small price to pay for designing
directly in the intended medium.

------
tomkin
I don't know what the author at Treehouse is doing, but I use the PSD as a
visual representation of what I will end up creating as CSS/HTML/JS. Who was
still seriously drawing grids and cutting out PNGs/JPGs?

The take away for many reading this article is going to be: Photoshop is not
the way to design a website. The article does attempt to address this is not
the case, near the bottom.

In the end, the author admits that you _do_ need some design reference point
(Photoshop, Illustrator, paper, etc). I do remember the days of cropping out
many images, backgrounds, etc., but that was at least 6-7 years ago.

------
discordian
He may wish it was dead, but I can assure you there is probably more PSD to
HTML work going on now than ever before.

First of all, it seems the author is not even opposed to the idea of mocking
up a design in PSD. He just thinks that responsive design and advances in CSS
have altered the process somewhat. OK, point taken, but this doesn't make the
overall concept of PSD to HTML obsolete by any stretch of the imagination. The
majority of designers will always favor mocking up their intended design in a
program like Photoshop, and using that as a starting point for the development
process. Responsive design just adds an additional layer of complexity, which
may call for additional mockups.

I've heard people advocate prototyping concepts directly with HTML/CSS, but
this is ultimately a rather inefficient way to work if you are a detail-
oriented designer.

As far as the actual workflow changing and becoming more iterative, it
completely depends on the context. Not everyone works at a company like
Treehouse that has a team of in house developers and designers. Many website
projects - the majority even - are the result of small businesses
subcontracting the process out to various companies. It's not always possible
for the designer and the developer to be in the same room. So as an ideal -
sure, the designer should be involved throughout the process, but this doesn't
always match the reality.

------
anthemcg
I am not here to say that web designers should create PSDs and just throw them
over the fence.

But, I don't think most web designers really agree with this. I think this
philosophy really tries to downplay visual style to practical problem solving
and I believe they are both essential.

I can write competent HTML/CSS/JS, Frameworks etc. At least, I know enough to
work with engineers and work effectively in my projects. For me using
Photoshop isn't just about what browsers can and can not do. Its certainly,
not just about pixel perfection or making a design ready to code.

Working with HTML is just clunky. Working with paper is too loose. I can think
about how to build a design, plan it on paper but exploring visually is
actually quite constrained by trying to do it with markup or just
paper/wireframes. Photoshop represents an open environment where I can create
anything I need from an illustration to a button and its powerfully close to
what it will really look like. To some people that might sound like a clunky
or wasteful step but I think it really helps.

For sure, I think Nick makes some great and valid points here. I agree, there
are problems with the PSD process but direct prototyping and CSS frameworks
just don't solve those problems.

I don't know, I feel like if in reality everyone used HTML to design,
everything would look like Bootstrap and that would be acceptable.

------
sandGorgon
This whole post, and comments, sound extremely unrealistic. In an ideal world,
things work as you would say - but in the real world, things don't work like
this.

I'm not sure if any of you guys have seen the inside of a psd2html place - it
is highly optimized with a hive mind around browser compatibility. I would say
that best of the breed slicers leverage bootstrap, sass/less, etc and
incorporate their experience inside it.

I would argue that the missing piece is not some new, magical way of doing
things - but rather the interchange formats. For example designers don't use
PSD grids that account for fluid layouts (FYI - I'm not even opening the can
of worms that is responsive design). This makes it hard for slicers to deliver
fluid layouts.

The search for the mythical designer + SASS engineer is very hard and very
likely futile. In fact, my opinion is that you are starting the process
incorrectly. I suggest to find a best of breed slicer, START the design
process with them as opposed to a designer (get their recommended grids, etc)
- then give the designer a set of constraints to work with. This should ensure
your downstream workflows are smooth.

------
ilaksh
I agree that PSD to HTML is generally now a bad idea that will make the task
more difficult.

However, I believe that the idea of having an interactive design tool should
not be abandoned so easily.

I believe that we should create interactive GUI design tools that support the
back-end encoding.

I know that doesn't meld well with hand-coded and maintained approaches.

I believe that we can create design tools that output acceptable markup. But I
don't think we have to.

I think that the business of writing code in order to layout a user interface
is ludicrous. I do it, because thats the way most everyone does it these days.
Most everyone also drives massive 5 passenger vehicles as the sole occupant
that waste huge amounts of energy driving to and from work every day. Point
being, just because that is the way people do things, doesn't mean it makes
sense.

Programmers by definition write code. If you're not writing code, you're not a
programmer. The problem is the definition of programming needs to be updated,
since we now can create very sophisticated programming tools that have
friendly user interfaces.

------
ChikkaChiChi
We don't live in a world where every web user is part of a majority of three
monitor resolutions and web design has changed to accommodate that. Web sites
need to scale properly and that cannot be done with raster graphics.

If you are using a raster program for anything other than mockups before you
head into real design, you are doing yourself, your clients, and their
customers a disservice.

------
at-fates-hands
I actually stopped working in Photoshop about two years ago when I realized
you can prototype faster just by building a design from scratch in the actual
browser.

It's so much faster than having a designer painstakingly mock something up in
PS, then have me build it and realize a myriad of things that weren't apparent
because we weren't looking at it in an actual browser.

------
IgorPartola
Rant to follow:

So I have done a fair share of PSD to HTML, PSD to WordPress theme, PSD to
application web GUI, etc. rewrites. I generally have no problem with the
concept of this, and got quite good at this. However, there are some real pet
peeves that keep coming up in this workflow, that are really driving me crazy.
If you are a designer working with a developer, and you happen to read this,
at least please consider it the next time you produce a PSD:

First, PSD's that assume text length. For example, if you have three call-out
boxes with a title and some text to follow, don't assume that the title will
always be one line and the text will always be the same length. Instead,
figure out what this will all look like when you do have very uneven amounts
of text. Do we center it vertically? Do we abbreviate it?

Second, PSD's that don't assume a responsive design. Sure, working directly in
the medium (HTML/CSS) would solve this, but you can still provide some
direction here. Tell me how the columns should be laid out. Which parts of the
site should expand/collapse with size, which parts can be hidden, etc.

Third, and this goes without saying, but clean up the PSD layer names and
groupings. Layer 1, Layer 2, etc. is not a great convention for this.

Fourth, show me the unusual cases. I know the clients always want to focus on
the prominent pages, like the home page, the product listing, etc. Those are
important, give me those. But also give me what a form submission error looks
like. Or what a 404 page looks like. Or an empty shopping cart. Or pagination.
Or a table that's wider than the viewport would normally allow.

Fifth, consistency. It sucks for the developer, and I'd argue it sucks for the
user, to have every page use a slightly different set of CSS rules for
headers, paragraphs, lists, etc. Best case scenario here is to give me a style
guide I can trust. I know it's two different documents you now need to
maintain, but honestly this is the biggest help you can give me.

Sixth, show or describe to me the interactions and workflows. A simple
shopping cart can become a giant minefield of interpretations of what the
design is supposed to convey.

Seventh, and this is a bit meta, but don't walk away from the design before a
single line of HTML/CSS is written. This is bad because there will be
questions about interactions, etc. If first I have to email your boss's boss
to try to see I can ask you a simple question, the process is broken and I
will not recommend working with you again.

Eighth, if you do promise to deliver sample HTML/CSS, for the love of good, do
this well. I have recently had the misfortune of having HTML/CSS/JavaScript
delivered to me for a large site redesign by a big name web design agency. I
was very excited about this, especially since these guys said they would use
Bootstrap as the foundation for this so that we would have all the benefits of
that framework built right in. I got the files, opened them and OMG. It did
include Bootstrap, but in name only. After that declaration, it instead
included a completely custom column system that was just slightly incompatible
in sizes with Bootstrap's. It also used none of the same class names even
where it made sense, etc. Needless to say, I had to re-write all of their CSS
from scratch, and re-adjust lots of the Bootstrap variables to accommodate
their column system.

</rant>

Great designers are worth their weight in gold. The above highlights that the
waterfall process of design -> develop does not work. Instead it should be
design -> develop/design/develop. If you cannot step outside of Photoshop
that's fine, but if you want to be efficient, you must know the final medium,
which is the web.

~~~
debt
Is there a known method for documenting an interaction in a design mockup?

~~~
wonderyak
Using HTML and JS works great and provides exactly the same interaction you'd
see on the final product. I think trying to do anything else (unless you're
extremely good at video processing) is insane.

~~~
debt
I hear Framer([http://www.framerjs.com/](http://www.framerjs.com/)) is pretty
sweet.

------
seivan
PSD to iOS as well. I just wish companies would stop wasting resources on
photoshop goons and let the engineers who work with the platform & SDK design.

~~~
telecuda
I'm not sold here on this one. Since we know the specific small set of
resolutions on iOS devices, I'd rather have a designer/UX lay down exactly how
it should look, then have devs execute on that. If dev provides a valid reason
why a design component would be a royal pain, then design can go back and
adjust.

Just had this argument 20 minutes ago on using a native control versus
designing our own and adding a few listeners - which has a better look and
experience.

Background: taught a PSD to HTML college course; stopped doing PSD-HTML myself
about two years ago; still favor PSD-iOS

~~~
seivan
Why waste time doing it on a photoshop canvas when a developer could easily
and quickly get an overview with Cocoa and auto layout through storyboard?

Background: none.

~~~
jawngee
Because stock iOS (iOS 7 changes this a little bit, but not much) only gets
you so far. Things like pixate get you a little further, but ultimately some
sort of visual design process comes into play, typically with a tool that's
been used in that process since time itself began.

Background: 20 years as a creative technologist currently doing iOS based
experiential retailing for huge brands where the interactivity and visual
appeal simply doesn't exist in stock iOS. And I also wrote an app publishing
tool that works similarly to Adobe DPS (build informational apps in Photoshop,
see
[http://www.youtube.com/watch?v=YXlHFhbqzHU](http://www.youtube.com/watch?v=YXlHFhbqzHU)).

------
atomicfiredoll
"Everyone’s workflow is different and nobody knows how to make the perfect
website. You should always do whatever is most effective for you and your
colleagues."

Not to say that there aren't some valid points brought up, but this feels like
dramatically titled click bait with a weak conclusion.

When I click a title like this, it's because there is an implication that a
better process exists--I want to know what that process is! At best, it's only
hinted at here.

I know teams that are using processes similar to the PSD oriented ones
outlined in the article very successfully. I suppose that means that it's not
dead for them, as it's effective.

------
jbeja
And would be glad if people stop making icons and UI sets in PSD, and start
using a more portable format like Svg.

~~~
wandsworth
+1

------
wwweston
Well, as long as we're making controversial statements (those in the "____ is
dead" usually are)....

I think Photoshop as a design/layout tool may have done more damage to front-
end design/development productivity than Internet Explorer. And this article
is just an indicator that there's a growing awareness of how.

Photoshop is an amazing raster image manipulation tool. But the dominant
mechanics have always been about composing a series of fixed-dimension
bitmapped layers (outside some shoehorned not-quite-layers-but-actually-layers
there's really no _other_ kind of entity to work with). For that reason
there's always going to be an impedance mismatch between the tool and the web.

------
tlogan
What is the best HTML page design tool? I.e., designing CSS and HTML with
_minimum_ coding?

~~~
callmevlad
Webflow ([https://webflow.com](https://webflow.com)) is made precisely for
this. To get a feel for what it's like, have a look at the playground:
[http://playground.webflow.com/](http://playground.webflow.com/) (I'm one of
the founders.)

------
grimmdude
When I first read this article I didn't really agree with it, but after
reading some of the comments on here I can understand where it's coming from.

I think the main issue is that the designer understand that it's more of a
guideline on how the site should look. When they start getting nitty gritty
about exact line breaks and page by page style changes is where it gets hairy
and falls apart.

I don't think moving away from mockups is the answer if that's what the
article is implying. Just a greater understanding of modern web abilities and
standards is all that's needed from the designer.

------
martianspy
I would like some constructive advice. I currently use sliced PSDs as part of
page content workflow to get a one page flyer from InDesign onto the web.

I start with a one page PDF which was generated in InDesign for print. This
one page flyer needs to be linked to products on an ecommerce site. The flyer
changes weekly.

Currently I open the PDF in Photoshop, slice it, add the links and upload it
into an iframe. It takes about 15-30 minutes to get if from PDF to live.

What would be a more efficient way for me to convert this PDF to clickable web
content? I don't want to spend more time than I currently do on it.

------
ctrl
+1 all these replies. As a designer first, I taught myself to code, Just as I
taught myself how print medium works. These details are integral to the end
product.

A web designer that doesn't understand code != a web designer.

I think Photoshop should be replaced with Illustrator. for the initial design
phases. 1) You can do wireframes in Illustrator, then build directly on top of
that for design. 2) Multiple artboards lets you layout multiple screen
sizes/breakpoints. 3) Resizing elements and keeping crisp edges is much
faster.

------
mratzloff
tl;dr Most browsers support modern CSS techniques that remove the need for
image-based techniques, and mockup tools like OmniGraffle and Balsamiq make it
easy to create layout drafts.

------
wil421
Tell that to people I work with, this is something I just did last week. I
dislike doing it and I dont really agree with the camp that slices their page
into images.

------
joeblau
If you're looking for a fast way to extract images from your Photoshop file by
layers/visibly/etc I highly recommend this software:
[http://getenigma64.com/](http://getenigma64.com/)

And if you're trying to extract gradients from Photoshop into CSS, SCSS, SASS:
[http://csshat.com/](http://csshat.com/)

------
lstamour
I'm surprised no one here's mentioned Photoshop CC's Generate function yet,
especially given that it was written in Node.js:
[http://blogs.adobe.com/photoshopdotcom/2013/09/introducing-a...](http://blogs.adobe.com/photoshopdotcom/2013/09/introducing-
adobe-generator-for-photoshop-cc.html)

------
Bahamut
As a frontend developer, I like having designers figure out the look of a
page, and implement the look in a way that doesn't break what I've
implemented. If they need help, I don't mind helping - in fact, I have a bit
of design experience as well. However, it is not a good use of my time, so I
don't do too much of the css.

------
SkyMarshal
Well it should be dead, but like COBOL it'll be around a long time simply
because there are tons of expert Photoshop designers who are much more
productive with that tool than raw html/css and need their designs converted.
I'm working with one right now, don't see it going away anytime soon.

------
zx2c4
The work flow might be dead but... psd.js lives on!

[http://git.zx2c4.com/psd.js/about/](http://git.zx2c4.com/psd.js/about/)

    
    
        git clone git://git.zx2c4.com/psd.js
    

This is a neat project from `meltingice`.

------
d0m
The concern is also about needing to hire two different people all the time.
It slows down the workflow so much.. it's way easier to have one person in
charge of it and being able to design, hack and tweak it as the projects
evolve.

------
mgkimsal
Yay. I'm surprised it was ever a thing, really. Maybe not surprised, but
pissed off. We've all got our horror stories - I got a PSD with > 200 layers
(4 layers for 4 rounded corners on a button - WTF). It was just crazy.

------
workhere-io
"X is dead" is dead. Just because you don't use X doesn't mean others don't
use it.

A very large number of people who do web design for a living are much better
at making their visions a reality using PhotoShop than HTML/CSS.

------
dredmorbius
As a mostly back-end guy (systems, network, databases) who's dabbled in HTML
and CSS, somewhat increasingly over the past few months (latest results
below), I've taken a highly pragmatic approach to how I prefer sites styled:

⚫ Consider the screen as a sheet of paper on which you can 1) communicate your
message 2) provide a UI, and 3) apply your branding. _Modest_ amounts of logo
/ artwork, color palette, and styling touches go a long way. Other than that,
it's a rubber sheet. There are no fixed dimensions.

⚫ Start with a basic HTML5 framework. body, header, article, aside, footer.

⚫ Put minimal elements above the fold. Your header, logo, and some basic
navigation. Emphasize body text and / or UI.

⚫ You almost always want to design around the text. That's your payload. For
interactive tools, controls layout should be clear, consistent, logical, and
most of all _provide enough space to meaningfully navigate options_. For that
last: size-constrained modal dialogs or their equivalents (pop-up menus, etc.)
are strongly deprecated. Unless the user needs to see other content while
performing input, that dialog should be front, center, and the principle
screen element.

⚫ CSS gives you a whole slew of tools: special selectors, including :hover,
:active, :first-child, :last-child, :nth-child, :nth-of-type, shadows,
columns, and more. No, MSIE legacy doesn't support many of these. Fuck'em.

⚫ Stick to light backgrounds and dark fonts, with few exceptions.
[http://www.contrastrebellion.com/](http://www.contrastrebellion.com/) is
strongly recommended.

⚫ Think of your page in either ems or percentages, and almost certainly ems
(scaled to your principle body font).

⚫ Provide a minimum page margin of around 2ems for desktops. For mobile,
enough to keep text from flush with the edge of the screen, 0.25em typically.
Don't crowd your text. I accomplish this by setting a max width (usually
45-60ems depending on context), and a 2em left/right internal padding. This
provides a comfortable reading width but preserves margins in narrow displays.

⚫ Scale fonts in pt, or use relative/absolute sizing based on the user's
preferences. I recommend "medium" for body text.

⚫ Other than image elements and logos, avoid use of px. _Never_ mix px and ems
(say, for line heights).

⚫ Rather than a traditional sidebar, use CSS column elements for your asides,
which are then full-screen width. @media queries can toggle between 3, 2, and
1 column views.

⚫ If you've got to float elements, float right of text rather than left. This
is less disruptive to reading. 0.5 - 1em padding or margins is usually
appropriate.

⚫ For long lists, I'm growing increasingly partial to "li { display: inline;}
or inline-block (the latter allows trick such as ":first-letter" but fails for
wrapping.

⚫ Make modest use of dynamic elements. I'm generally _not_ a fan of flyouts,
automatically opening menus, etc., and they're among the first elements I nuke
when modifying sites. Color shifts to indicate links and other dynamic
elements, however, can be useful. Google's "Grid" is a notable exception to
this rule.

⚫ Don't fuck with scrollbars. Allow the user environment defaults. Yes,
Google+, I'm talking to you.

⚫ _DO NOT USE FIXED HEADERS OR FOOTERS._ Far too many displays are height-
constrained, and robbing another 10-25% of the display with elements which
cannot be scrolled offscreen is an insult. If you've _got_ to fix something,
put it in a margin. Do not fix _ANYTHING_ for mobile displays.

CSS modification: Metafilter lite
[http://www.reddit.com/r/dredmorbius/comments/1v8fl5/css_adve...](http://www.reddit.com/r/dredmorbius/comments/1v8fl5/css_adventures_metafilterlite/))

------
j_s
Here is the direction designers should be heading:

[http://www.sketchingwithcss.com/](http://www.sketchingwithcss.com/)

------
mtangle
But picture is a good start to show what kind design you want And yes in many
accessions some designers are tooooooo pitchy about their psd.

------
leishulang
with tools like edge reflow, the human part of PSD to html is going to be
dead. HTML/CSS/JS will become the assembly of the web that no one is directly
programming with. Designers will keep working on psd and use edge-like tools
to export html/js files, and coders will be using
clojurescript/fay/coffeescript etc.

------
supercanuck
So what is the replacement?

------
bluemnmtattoo
stone and chisel is dead

------
thomasfoster96
Hurrah!

------
goggles99
Link bait warning. Author even admits in the comments that what he means is
"Going directly from a PSD to an HTML file is dead".

Link bait may get you more traffic in the short turn, but will likely just
hurt you in the long run. Especially since lots of people think that he an
idiot now.

Why? Who would have thought... Modern day web dev needs to be rendered to
different sized screens and we have CSS3, more skills, and better tooling now.

Who does not know this already. I was baited and now he is hated (JK)...

PSD is still used quite commonly for conceptual purposes. Of course no one
expects anymore (did they ever?) that it will be pixel perfect across devices
ETC.

~~~
welly
> Of course no one expects anymore (did they ever?) that it will be pixel
> perfect across devices ETC.

Yes, yes they do and did. Clients are those who expect it to be pixel perfect.

I won't go into the numerous times over the years I've had a screenshot pasted
into a Word document from a client saying "this is two pixels too high".

------
Sssnake
Now perhaps in 10 years idiots in suits will finally stop demanding ridiculous
pixel perfect control over website designs.

