PSD to HTML is Dead

http://blog.teamtreehouse.com/psd-to-html-is-dead

by nickpettit • 13 years ago

304 164 13 years ago

blog.teamtreehouse.com

elorant• 13 years ago

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.

thoughtpalette2• 13 years ago

"Nine out of ten times I want to do something with CSS I prefer doing it with JavaScript"

You're doing something wrong then.

debt4• 13 years ago

center a div both vertically and horizontally to the viewport; also it should stay center when resized.

jsnk• 13 years ago

Use Sass. Thank me later.

bluetidepro• 13 years ago

Or LESS! I personally prefer that over Sass.

minimaxir4• 13 years ago

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.

sp3323• 13 years ago

Bootstrap is javascript.

crimsonalucard3• 13 years ago

Err Bootstrap isn't a complete solution.

ChikkaChiChi2• 13 years ago

Can you provide any examples where using JS would be preferable to you? Maybe we can help?

SDGT• 13 years ago

I want to do something with CSS I prefer doing it with JavaScript.

So now you're you're still writing css, but in JS files instead? Not taking advantage of shorthand transitions, keyframe animations, or :before/:after stylings.

SASS/LESS helps a lot (not to mention straight up frameworks like Bootstrap or Foundation), but what you're doing is even harder to maintain than structured CSS files.

crimsonalucard3• 13 years ago

I agree that something is wrong with CSS. When you have to resort to hacks when making columns and vertically centering things... you know something is wrong.

jbeja4• 13 years ago

Maybe vendors and browser fragmentation is what you are referring to?

mratzloff• 13 years ago

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.

bluemnmtattoo• 13 years ago

stone and chisel is dead

reuven• 13 years ago

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.

atacrawl• 13 years ago

The analogy I use is a web designer who doesn't know HTML and CSS is like a fashion designer who can't sew.

FireBeyond• 13 years ago

That’s a great one. Better than what I used to say, which wasn’t even an analogy - that it’d be no different than a graphic designer supplying a hand-drawn/inked/painted sheet of paper, unscanned, for comping.

user24• 13 years ago

One I saw a while ago was that a web designer who doesn't code is like a sculptor who doesn't know anatomy.

nkuttler• 13 years ago

Love it, that's something everybody can understand. I might rephrase it as "doesn't know about sewing" though, as you don't need the practical skill itself but have to understand the limitations of different techniques.

posabsolute• 13 years ago

Yadi yada is dead..

I also think web designer should have a basic understanding of css & html,

but too many time I saw average web dev saying no to a designer because, well they did not care or did not know how to do it. If you start limiting yourself you limit what the designer can create.

Another thing is now there are tools to make PSD to HTML much faster like CSSHAT that provide you with the exact CSS for each element of your design.

Also, designing in photoshop make design iterations much faster. By the time you design directly into html&css a design I could have iterated 2 times & have a much better end product.

I'm not saying Photoshop is the tool for web design, there is place to be taken there, but tools like photoshop & sketch makes design works go much faster.

eropple2• 13 years ago

It makes bad design faster. That's the problem. You don't want "exact CSS for each element of your design", you want a coherently designed set of visual and functional elements that work throughout a site.

And don't even start on responsive CSS and PSD-baking software.

Theodores• 13 years ago

"...make design iterations much faster..." as if!

Say you want to swap over the search box with the account functions (sign in, cart, etc.) in a header on an ecommerce site. Chances are that you need only change a couple of lines of css to effect this layout change. Minutes later you can then run through the customer journey with the client and get a few people to test it. You learn quickly if this is better for usability and if it does not work you simply roll back the css to what you had before.

Compare with the PSD approach. You can spend a minor age fiddling with the umpteen layers, then you can hide/show layer groups for the homepage/category page/product page/basket page/checkout and so on, saving out some flat jpg thing along the way. Then present it to the client and ask them to imagine if it is better. If they go ahead then you hand it over to some developer that will then have to make what was signed off pixel perfect.

However, along the way you discover that the account functions are in a dynamic list, e.g. the basket shows how many items are in it, as does the wishlist, and, on some pages, e.g. checkout, there may not be all the links shown. So it changes around. Consequently the area/box that has been designed fills up or gets empty, impacting the design in ways not understood doing it with Photoshop mockups.

Note this is a simple example with no fancy responsiveness involved, just plain regular desktop view.

Put simply, Photoshop is a useless tool for any meaningful design. It results in very poor workflow. All clients have already had websites, they all know that PSD mockups don't look like that once they are implemented, and, if they do, there is a whole lot of stuff that is not accounted for. It is much better to be honest with a client and involve them in an iterative design process.

AJ007• 13 years ago

In house developer's time certainly should not be spent converting a PSD file in to a full HTML/CSS website. If the designer can't build an HTML/CSS site its likely that massive chunks of usability knowledge is missing as well.

The thing that hit me about abandoning PSD mockups (coming from a 15 year Photoshop user) is not responsive design but high DPI displays. A lot of big companies still have terrible upscaled raster images on their sites. It is bad enough for logos, even worse for the site's UI. Sticking to HTML5 & CSS (with a backwards compatible design for the few users still on XP of course) is easier to build and ends up looking a lot better.

Pxtl3• 13 years ago

I chuckle every time I see a hideous upscale raster in print.

wonderyak9• 13 years ago

This is one of the nice things about the occasional comp delivered in AI. Its so much easier to translate assets to the web that it confounds me why AI wasn't the standard from the beginning.

wpietri5• 13 years ago

Great point. Does anybody know the historical origin of the notion that there are "designers" who can be ignorant about their medium?

When I talk to, say, friends who paint, it's a very specific activity for them. They know a lot about actual paints, because they do the painting. Pre-web, I knew people who were print designers, or packaging designers, or logo designers. They too knew the details of their medium intimately.

The two theories I've been able to come with were that a) it's an artifact of the quick rise of the web, where the hunger for various design-related skills quickly pulled in a lot of people, or b) that there was a market niche for design agencies to sell a lot of "design", and so they created the pretense.

Either way, that would put the origin in the early multimedia/web era. But I'm wondering if it goes back further.

wonderyak9• 13 years ago

From my perspective a lot of it has to do with 'training' 'education' and employers. I've worked with several high end agencies and even if some of the designers know some HTML/CSS they have no idea how what they do in PS affects the next stage of the project.

Many employers have no idea about the technical debt of PSD->HTML. Its just the way they've been doing things for years. They hire a designer that can make things look pretty in PS and thats it, their job is done. Its up to the next chump to figure out how to make it work 'Thats what they get paid to do'.

Print designers had to know about processes and techniques because re-printing things is VERY EXPENSIVE. There is a hard cost involved that just doesn't exist on the web. If we make a typo or mistake in something, often we can correct that in a matter of seconds.

A lot of these print designers ended up being used for the web in agencies because they were senior designers, they knew about 'design' and had a lot of experience.

WalterSear• 13 years ago

Design as an profession is older than the web - it's older than programming. The industry as a whole is intimidated by modern technology, and appeals to non-technical people.

As a result, many of the people coming out of professional design schools, trained in the esthetics of flat, non-interactive design see themselves as 'above' all that 'computer stuff'. This, combined with intimidation, and a massive demand for good design, keeps them from expanding their skillset.

enobrev• 13 years ago

I've helped convince a few designer friends and colleagues to get into HTML / CSS as they progressed into their careers.

It always seemed to most of them like a daunting leap from the creative application of graphic editors to the very manual text-based tools (and sub-par graphical tools) for rendering designs in a browser. Most would refer to HTML/CSS as "Programming". The majority of their experience and education had been with graphical tools, so the idea of tweaking layout and composition with text was completely foreign.

Most [art] schooling up until about a decade ago was largely based on print design, which means photoshop and illustrator. There may have been a couple classes here and there about building a website, but the vast majority of college level classes for graphic design were all about print and various other analog mediums.

This is actually what eventually led me to drop out of graphic design school in 1998 because it was so far behind the times in terms of web design, which is where I wanted to be.

So with the reluctance of the most talented designers in the industry to learn the medium, it was left to the developers to cover the gap - generally, quite poorly. I've been through plenty of back-and-forth annoyances with print designers - in the very distant past - while they would ask me to tweak pixels that I could hardly bring myself to care about when I had so many other priorities on the project.

For years I'd require any designers I'd worked with to hire "frontend developers" to handle the pixel tweaking and html/css generation, which would eventually start counting against them as the design industry started catching up with the medium.

crazygringo• 13 years ago

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.

muglug2• 13 years ago

Agreed, but responsive sites benefit massively from having a choreographer-designer - one who is both able to set out a plan (in Photoshop/InDesign/xxx tool) and then describe how different page elements flow.

sgustard2• 13 years ago

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.

Sssnake2• 13 years ago

I've never seen a designer that knows anything about UX and doesn't know html and css. The look of a page is not graphic design, it is UI. The only thing that is purely graphic design is literally designing graphics, like a logo.

cordie• 13 years ago

I agree. I think it's obviously ideal to find someone who can design in photoshop translate that with html css javascript and create the entire front end experience. But is it practical?

I'm not sure. I think the designer programmer relationship needs to change. The designer must understand the programmer is going to have to do some "interpretation" of the original design. It's not going to look exactly the same.

sgustard2• 13 years ago

A good analogy is an architect (of buildings) who doesn't know structural engineering. Yes, they don't have the degree, but basic knowledge of behavior of materials, how buildings don't fall down, and so on, are the difference between pretty drawings and actual buildable designs.

chrissyb• 13 years ago

I'd have to somewhat disagree with this, Architecture is a philosophical pursuit and Engineering is physics. The two professions coexist but remain separate for accountability.

Maybe a better way of putting it might be ~ An Architect who can only conceptualize in 2D, therefore missing the opportunity to fully develop their designs in 3D.

And FWIW the only pretty drawings in my eyes are buildable designs! :)

ChikkaChiChi2• 13 years ago

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.

Trufa• 13 years ago

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.

yogo2• 13 years ago

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.

RandallBrown• 13 years ago

I have designer type friends who don't do the design in photoshop at all. They just do their design in html and CSS.

This has the obvious advantage that when you're "done" with your design, the UI code is already written.

Of course it's way easier to do things like adjust gradients in photoshop. I also assume that most people will be able to do things in photoshop that they might not know how to do in HTML/CSS.

bryanlarsen• 13 years ago

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>

At one point in time you couldn't do gradients in CSS, so that's exactly what you did. Luckily, that era is over.

IgorPartola6• 13 years ago

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.

debt4• 13 years ago

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

wonderyak9• 13 years ago

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.

IgorPartola6• 13 years ago

Not easily. Adding a few layer groups that show different states often works well for simple things. HTML/CSS + JavaScript are great if the designer knows how to do this. The next best thing is something like Balsamiq workflows with a detailed textual description.

whatusername• 13 years ago

've heard of but haven't used: http://keynotopia.com/

wonderyak9• 13 years ago

Just to belabor your well made point, here is an example of a final PSD I received from a 'professional agency': (from psdgrade.com)

https://cloudup.com/c5RmHN8t1QZ

https://cloudup.com/cmpmBEYg93c

Thats 27 different font sizes for ONE PAGE of a site. I bet most of this was done through scaling layers to 'fit' into spaces.

There were also 42 layers named some verson of <shape>-n.

grey-area7• 13 years ago

Would you normally expect a psd to contain exactly specified type sizes?

I don't use psd comps myself, but I'd treat them as more sketches and guidelines as to actual style and placement, rather than some sort of specification document, because it's a different medium and text handling in ps is pretty basic - it's really not suited to extensive text layout.

yogo2• 13 years ago

I think the first point is an issue common in print designers designing for the web. A real web designer designs knowing the limitations of the web, and with the understanding that text flows. Whenever a comp has regions with height constraints (something I believe should be avoided on the web), 9 out of 10 times it will fall apart in practice because a client will dump a bunch of text in a box and cause the other areas to create gaps.

nebtune2• 13 years ago

As a designer, I love hearing what developers want. I always hope the process is going to be a two-way conversation. It helps me a great deal to hear what the developer wants. I also agree that if you're going to design for the web, in PS, you had better at least have a basic understanding of how HTML works and how a web page is put together.

IgorPartola6• 13 years ago

Thanks for understanding. I was really hoping that the original comment wouldn't come through as a rant about designers in general, but more as a list of things that good designers should avoid. I think most dev shops can do very well to hire at least one competent designer instead of trying to separate the design phase and the development phase and outsource the design.

wonderyak9• 13 years ago

The best PSD I ever recieved had a layer exclusively reserved for annotating margins and spacing. I didn't have to dig into the PSD and check the toolbar, all of the figures I needed were right there.

It even came with a PDF style guide outlining line spacing, font size, colors in hex and margins/padding.

I've never been so elated to get a PSD.

evunveot• 13 years ago

This kind of work has been a large part of my job for a long time, and I definitely recognize all of those frustrations. This may be obvious, but the problem is usually not a lack of communication but rather that the designer/client/manager isn't able or willing to think through the design fully. As such, when you seek clarification on something, you're really asking the stakeholder(s) to figure it out for the first time.

I've learned that a good strategy is simply to figure it out for them and hand it back complete. Not only does this eliminate communication overhead, it allows me to pick a solution that strikes a good balance between quality and my own time and effort, as opposed to having to push back against some half-baked, unrealistic idea.

The vast majority of the time, whatever I come up with is accepted either without comment, with minor requests for tweaks, or with elation. In the rare instance that something needs to be redone from scratch, I've at least gotten the ball rolling and given the stakeholder(s) some idea of what's possible.

It's kind of like turning a waterfall process into an iterative one by doing the first iteration yourself.

johnjlocke3• 13 years ago

I do a lot of front end development for agencies, but also a good amount for my own projects. I only present mockups to clients, so we are all on the same page.

What I do with the PSDs for my own projects is use Layer Properties to name the color (and if applicable, the font, weight, and pt size). That way, when I go to do the build, I can glance at the layer and get that information quickly.

Many PSD designers group layers, but don't put extra effort into naming layers. Little things like that make a huge difference in time.

Quarrelsome2• 13 years ago

But also give me what a form submission error looks like.

I've been waiting over three months now for my designer to give me this. I mention it every time I see them and it never gets done.

Do they like my awful pink error boxes or just avoid errors when demoing???

IgorPartola6• 13 years ago

My favorite was this nice redesign I did where the form fields had no labels. Instead the designer cleverly used placeholders on input elements to identify them. Moreover they had a great deal of customization for each form to make them look nice and compact. At first glance this looked fantastic, until you try to add an error message to it.

I pointed this out to them, and their first inclination was to highlight the border of the errored out elements in red. Great, except for the large minority of users who are color blind. Also, this doesn't indicate what the error is, just that there is one. On top of that, form-wide (vs field-specific) errors still don't have a place.

This drives me crazy, because it's not like I can logically extend their design and say "let's put the errors here. What do you think?" Their design was so tight (in a good way I suppose) that it left no room for this kind of thing.

My suggestion is to make your version so ugly that it cannot be overlooked. Put the errors in size 72 font in neon green right over the fields. No way for it to go into production that way.

wpietri5• 13 years ago

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.

wonderyak9• 13 years ago

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.

reneherse2• 13 years ago

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-area7• 13 years ago

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).

dpeck• 13 years ago

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

cpher• 13 years ago

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• 13 years ago

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

eponeponepon• 13 years ago

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.

wpietri5• 13 years ago

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.

nickpettit• 13 years ago

Amen. This is a wonderfully eloquent summary.

tethis• 13 years ago

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

theorique• 13 years ago

Nice image. Thanks.

(upvote nonetheless)

tomatohs• 13 years ago

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.

eropple2• 13 years ago

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 or 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.

zx2c4• 13 years ago

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

http://git.zx2c4.com/psd.js/about/

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

This is a neat project from `meltingice`.

wil421• 13 years ago

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.

jbeja4• 13 years ago

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

wandsworth• 13 years ago

danboarder• 13 years ago

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.

seivan2• 13 years ago

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• 13 years ago

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

seivan2• 13 years ago

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.

estel• 13 years ago

I guess this is more an argument about designers without experience of the platform - but most designers /don't/ have experience with iOS. Especially in an agency model it's easy to "receive" a design that uses very slightly non-standard controls, attempts to use Android UI paradigms in iOS (or vice versa) or generally make everything a pain.

For example, I've had discussions where a designer has insisted that the navigation bar is 50px high, which is a proper pain. (The correct solution here being to leave it at the default of 44px, safe in the knowledge that they'd have to be properly anal to count up the difference).

tlogan• 13 years ago

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

dsego• 13 years ago

http://macaw.co looks promising.

callmevlad2• 13 years ago

Webflow (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/ (I'm one of the founders.)

callmevlad2• 13 years ago

The pain of the PSD->HTML workflow, especially around responsive design, is one of the reasons we're working on Webflow (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.

joeblau• 13 years ago

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/

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

bbx• 13 years ago

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

lstamour• 13 years ago

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...

rwhitman• 13 years ago

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.

muglug2• 13 years ago

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.

riffic• 13 years ago

there are usually two approaches to a problem: top down and bottom up. PSD -> HTML is a top down workflow.

atomicfiredoll• 13 years ago

"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.

efsavage• 13 years ago

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• 13 years ago

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• 13 years ago

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.

dalerus• 13 years ago

100% this.

We shouldn't be designing or developing in silos. I love working with developers who keep me in the bounds of reality.

mtangle• 13 years ago

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• 13 years ago

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.

workhere-io• 13 years ago

"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.

at-fates-hands• 13 years ago

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.

grimmdude• 13 years ago

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.

ctrl• 13 years ago

+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.

ilaksh• 13 years ago

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.

Sssnake2• 13 years ago

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

tomkin• 13 years ago

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.

wwweston• 13 years ago

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.

anthemcg• 13 years ago

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.

goggles99• 13 years ago

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• 13 years ago

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".

SkyMarshal• 13 years ago

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.

Bahamut3• 13 years ago

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.

supercanuck• 13 years ago

So what is the replacement?

thomasfoster96• 13 years ago

Hurrah!

dredmorbius• 13 years ago

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/ 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...)

discordian• 13 years ago

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.

tn13• 13 years ago

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.

mgkimsal• 13 years ago

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.

sandGorgon• 13 years ago

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.

martianspy• 13 years ago

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.

d0m• 13 years ago

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.

j_s• 13 years ago

Here is the direction designers should be heading:

http://www.sketchingwithcss.com/

PSD to HTML is Dead

Related Stories