PSD to HTML is not dead(xhtmlized.com)
xhtmlized.com
PSD to HTML is not dead
http://xhtmlized.com/blog/psd-to-html-is-not-dead/
51 comments
tl;dr
Use Sketch if you're on a Mac
I agree with most of your points except this:
>>Moving divs around, adjusting CSS or erasing pencil off a piece of paper is never going to be as efficient as clicking on a layer and moving, resizing it, etc.
As a visual designer and front-end developer (that knows Photoshop very well), code is actually far more efficient for modern UI's. It's much better organized than the PS layer model, CSS gives you tremendous reach with your changes (especially with SASS/LESS), and Developer Tools (or Firebug) give you amazing reactivity.
However, that being said, the designer must have both design skills and coding skills, which aren't, and shouldn't both be a requirement for the position. The most creative and best graphic designers tend to not know code well enough to become more efficient with it than their traditional layout tools.
The best middle ground for "thinking for UI" and quality graphic design is Sketch. Sketch eliminates 80% of the stuff you never use in PS for web design and adds the features you didn't know you wanted. Its styling options reflect the styling options of CSS. I can't recommend it highly enough.
Honestly, unless you have some very complex personnel issues, every web designer should be using Sketch over Photoshop (and maybe use Photoshop for image manipulation).
I agree with most of your points except this:
>>Moving divs around, adjusting CSS or erasing pencil off a piece of paper is never going to be as efficient as clicking on a layer and moving, resizing it, etc.
As a visual designer and front-end developer (that knows Photoshop very well), code is actually far more efficient for modern UI's. It's much better organized than the PS layer model, CSS gives you tremendous reach with your changes (especially with SASS/LESS), and Developer Tools (or Firebug) give you amazing reactivity.
However, that being said, the designer must have both design skills and coding skills, which aren't, and shouldn't both be a requirement for the position. The most creative and best graphic designers tend to not know code well enough to become more efficient with it than their traditional layout tools.
The best middle ground for "thinking for UI" and quality graphic design is Sketch. Sketch eliminates 80% of the stuff you never use in PS for web design and adds the features you didn't know you wanted. Its styling options reflect the styling options of CSS. I can't recommend it highly enough.
Honestly, unless you have some very complex personnel issues, every web designer should be using Sketch over Photoshop (and maybe use Photoshop for image manipulation).
[deleted]
I LOVE Sketch. It's so good. What's lacking are proper video tutorials for complex things and different subjects. I'd love to see an hour long video of someone vectoring something or designing a mobile app from start to finish.
Started using Sketch a few weeks back, never went back to Photoshop.
When I design, I usually just have livereload running with my website on my right monitor and code in my left. Ctrl+S = refreshes the site = very easy to develop with just html/css.
Started using Sketch a few weeks back, never went back to Photoshop.
When I design, I usually just have livereload running with my website on my right monitor and code in my left. Ctrl+S = refreshes the site = very easy to develop with just html/css.
This is exactly what I have been wondering. Do people still use the old slicing method for their PSD documents? Whenever I code from a PSD design, it is used strictly as a reference. I attempt to reproduce it using all CSS, and then for the parts that I cannot reproduce in CSS, I will extract the images from the PSD usually by just copying the layer to a new document and saving it as a PNG. But having these PSDs is very important for me during the design process, during the coding process, and having them around to compare after you are done.
It's very easy to go off track and start designing on the fly if you don't have a solid, agreed upon, reference.
It's very easy to go off track and start designing on the fly if you don't have a solid, agreed upon, reference.
I like the way you put it. Especially the point of how this "panders to developers."
I know I would personally prefer to work where I have some sort of "from designer" reference point. Be it scribbles on paper or a PSD, don't know if I care.
I know I would personally prefer to work where I have some sort of "from designer" reference point. Be it scribbles on paper or a PSD, don't know if I care.
The problem seems to be how "PSD to HTML" is defined. The old definition of PSD to HTML frankly may have died about the time we stopped using tables to create designs in HTML.
In the yesteryears "graphic" designers designed pixel perfect designs in Photoshop and expected web designers to convert these to xhtml/css.
It was a royal pain in the ass. I have been on both ends of this.
But things are very different now, the old definition of "PSD to HTML" has died or rather evolved.
I still create the first drafts of the desktop design in Photoshop, its simply easier to do when you'd like to try various designs. But hand code it from there. No more splicing etc.
This process also makes it easier for me to visualize the code structure for mobile first(in my mind).
In the yesteryears "graphic" designers designed pixel perfect designs in Photoshop and expected web designers to convert these to xhtml/css.
It was a royal pain in the ass. I have been on both ends of this.
But things are very different now, the old definition of "PSD to HTML" has died or rather evolved.
I still create the first drafts of the desktop design in Photoshop, its simply easier to do when you'd like to try various designs. But hand code it from there. No more splicing etc.
This process also makes it easier for me to visualize the code structure for mobile first(in my mind).
Says the company whose entire business model is built around PSD to HTML conversion.
Sometimes one works better than the other for a project's specific needs. And vice versa. What we are needing to get past is pixel-perfect design, however.
Sometimes one works better than the other for a project's specific needs. And vice versa. What we are needing to get past is pixel-perfect design, however.
Not sure if it is dead or alive. But, the business is extremely challenging with players like cssilize. they charge peanuts with pms and automated quality checks.
Pay peanuts you get monkeys.
They charge $19 PER PAGE just to have "permission" to remove their name. That should be all the proof you need of their business model.
If you need more though, the "$39 a page" actually ends up being $254 a page, if you want..
* responsive.. * tested/compatible with Chrome, Safari or Opera... * accessible * commented css * commented markup * using a css grid framework * html5 * microformats * speed optimisation * sprites * a favicon * PERMISSION TO REMOVE THEIR NAME FROM THE PAGE
This is why people think "PSD to HTML" services are a thing of the past - operators who are stuck in the past and think using modern standards is a reason to charge 2x or 3x the stated price. Seriously look at their pricing page - they add the per-page price again just to use HTML5 instead of XHTML Transitional, and again to use a CSS grid framework.
They charge $19 PER PAGE just to have "permission" to remove their name. That should be all the proof you need of their business model.
If you need more though, the "$39 a page" actually ends up being $254 a page, if you want..
* responsive.. * tested/compatible with Chrome, Safari or Opera... * accessible * commented css * commented markup * using a css grid framework * html5 * microformats * speed optimisation * sprites * a favicon * PERMISSION TO REMOVE THEIR NAME FROM THE PAGE
This is why people think "PSD to HTML" services are a thing of the past - operators who are stuck in the past and think using modern standards is a reason to charge 2x or 3x the stated price. Seriously look at their pricing page - they add the per-page price again just to use HTML5 instead of XHTML Transitional, and again to use a CSS grid framework.
FWIW, I had a very good personal experience with CSSilize in last 2 companies here. I can understand why they charge $19 to remove their name (it is a very good marketing strategy, IMHO). But, they're still cheaper with additional $19 and efficient (for instance, the real time updates and ability to "control" the project through their pms are really mesmerizing)
So some folks like doing it one way, others like doing it another. Both groups think their way is better, and can give arguments in their favour.
In reality, the right decision comes down to the project goals, the deadlines, the budget, the resources, the staff, and many other factors.
This whole 'debate' has about as much depth as "should I put ketchup or barbecue sauce on my chips?".
In reality, the right decision comes down to the project goals, the deadlines, the budget, the resources, the staff, and many other factors.
This whole 'debate' has about as much depth as "should I put ketchup or barbecue sauce on my chips?".
Top comment. None of this really matters. Your craft, is your craft, is your craft.
More on this (from a programming perspective): http://vimeo.com/54042336
More on this (from a programming perspective): http://vimeo.com/54042336
Please read my latest blog post, 'Putting Condiments on Chips is Dead'
A designer I work with hands me AI files that I'm then meant to convert to a WordPress theme. She knows near zero about coding. It's a nightmare and I'm constantly in battle of functionality and her wanting things pixel perfect. The worst is that she hands over the designs to the clients who do not understand that it will not be pixel perfect and many things will change.
Hey, that's 90% of my business. At least it is an Ai file and you can pull SVGs out of it if that's your thing. You're right that it's no fun.
At some point, I decided that I'm okay with that battle (there's a lack folks who have both the skills and the masochistic willingness to do it, and I charge a relative lot for the service).
That said, I've been finding that a) designers who still really care about "pixel perfectness across devices" but don't know how to code usually aren't all that great (so I see fewer of them as move to better projects) and b) the ones that are really good also have an understanding about how the finished product should feel and will change across devices/screens sizes/etc (and what kinds of crap I might need to add because they have missed or omitted some functionality.
I've found it really helpful that the poorer designers can't think about the edge cases (or even to send a post archive or 404 page, in the case of WP sites), so I end up just doing whatever, and then iterating based on my own preferences... if they really don't like it, it's not my fault, they just send a design.
It's still all a pain in the ass, but at least I work remotely, for a few hours, and get paid okay... I just have to be okay with folks telling me to fix the "horrible looking mistakes" I did intentionally but which don't match their (non-obvious, often poorly thought-out) aesthetic bends.
At some point, I decided that I'm okay with that battle (there's a lack folks who have both the skills and the masochistic willingness to do it, and I charge a relative lot for the service).
That said, I've been finding that a) designers who still really care about "pixel perfectness across devices" but don't know how to code usually aren't all that great (so I see fewer of them as move to better projects) and b) the ones that are really good also have an understanding about how the finished product should feel and will change across devices/screens sizes/etc (and what kinds of crap I might need to add because they have missed or omitted some functionality.
I've found it really helpful that the poorer designers can't think about the edge cases (or even to send a post archive or 404 page, in the case of WP sites), so I end up just doing whatever, and then iterating based on my own preferences... if they really don't like it, it's not my fault, they just send a design.
It's still all a pain in the ass, but at least I work remotely, for a few hours, and get paid okay... I just have to be okay with folks telling me to fix the "horrible looking mistakes" I did intentionally but which don't match their (non-obvious, often poorly thought-out) aesthetic bends.
Tell her to think of the robots. There are more robots that browse the web than humans, and her static design makes them angry. You are currently giving allegiance to robots over humans because the robots are estimated to become sentient in 2030.
Hopefully this will confuse her enough to stop asking for pixel perfect html/css.
Hopefully this will confuse her enough to stop asking for pixel perfect html/css.
Have you talked her through the challenges of your role and suggested to her (and any relevant management) that it might be worth you having a basic role along the way in encouraging things in the right direction?
The definition of PSD to HTML used is just too lose. PSD to HTML will never be dead because images are the best medium to exchange visual ideas. Which, in the case of Web, are translated to HTML. So yeah, we will be using PSDs and translating them HTML in some way or another for the foreseeable future. Simply the good designers are evolving and more aware of what's doable, what's doable but pain in the ass to do, and what's not doable. And that's enough. I don't expect, and don't want, the designer to give me the design in HTML/CSS unless he/she is an expert in them for a bunch of reasons.
I believe that more or less sums up the sensationalist headlines.
I believe that more or less sums up the sensationalist headlines.
Look, designers can stick to making the website look amazing in photoshop, but let the engineers actually tell you what's possible or not using simple, responsive practices. Don't expect pixel perfect, do expect lean websites built to last.
It is always fun to discuss with customers that expect pixel perfect designs, to the point that they actually measure them it all browsers specified on the contract.
Thankfully, I am not the one usually sitting in those meetings.
Thankfully, I am not the one usually sitting in those meetings.
But what pixel perfect means in fact? That it looks as it was supposed to. If I'm a designer and design something which looks perfect, do I want a coder to alter this perfect look to something ugly?
Ideally pixel perfect is replaced with "looks perfect" and designer works closely with coder to achieve perfect look on various devices and resolutions. But I don't think coder should make assumptions how the coded design can differentiate from the original design (unless they have very good aesthetics feeling).
Ideally pixel perfect is replaced with "looks perfect" and designer works closely with coder to achieve perfect look on various devices and resolutions. But I don't think coder should make assumptions how the coded design can differentiate from the original design (unless they have very good aesthetics feeling).
Well, on those meetings means that someone on the customer side had the wonderfull job of using an on screen pixel ruler and counted the exact number of pixels.
Pixel count not the same as on the PSD image, across all targeted browsers? No money, even if it is only 1 pixel.
As ridiculous as it sounds, I do know a few of such cases.
Pixel count not the same as on the PSD image, across all targeted browsers? No money, even if it is only 1 pixel.
As ridiculous as it sounds, I do know a few of such cases.
Now that we finally have effects like shadows, gradients, and rounded corners in CSS, the trend is towards flat design. Some webpage layouts I made ten years ago look surprisingly modern again.
The typical PSD to HTML approach will evolve over time to {insert-tool}2 HTML. Since web design was a big boost for Photoshop over the years, Adobe is not going to let that audience disappear without a fight. Their Edge tools, such as Reflow (http://html.adobe.com/edge/reflow/) are the response to this trend.
Although typical all-in-one design/developers might prefer mocking-up and developing in straight HTML/CSS, there will always be a large audience that prefers visual tools. The opportunity is there for other companies to fill this need--Sketch.app comes to mind. Frameworks such as Bootstrap, Foundation, Skeleton, etc. also fill some of the demand.
Responsive design is still new to many and designers will still use Photoshop for quite a while.
Although typical all-in-one design/developers might prefer mocking-up and developing in straight HTML/CSS, there will always be a large audience that prefers visual tools. The opportunity is there for other companies to fill this need--Sketch.app comes to mind. Frameworks such as Bootstrap, Foundation, Skeleton, etc. also fill some of the demand.
Responsive design is still new to many and designers will still use Photoshop for quite a while.
> Adobe is trying to overcome Photoshop’s limitations for modern web design.
So Adobe has realized that PSD to HTML workflow is dying and tries to develop tools for the modern web workflow to stay relevant. I don't get how this argument supports author's assessment.
On the other hand external services like xhtmlized are a great way to push a website out of the door when you're an agency rooted in marketing/visual design and need to add a website to the package to get the deal. Your designers do the design, then a professional service like this will make the final product orders of magnitude better than what you could achieve without internal dev team.
So Adobe has realized that PSD to HTML workflow is dying and tries to develop tools for the modern web workflow to stay relevant. I don't get how this argument supports author's assessment.
On the other hand external services like xhtmlized are a great way to push a website out of the door when you're an agency rooted in marketing/visual design and need to add a website to the package to get the deal. Your designers do the design, then a professional service like this will make the final product orders of magnitude better than what you could achieve without internal dev team.
The argument is that having a dedicated design stage before converting to templates/app/etc is still valid. Just because that button in the PSD is a rasterized gradient, doesn't mean the resulting page will have an image - but it does mean the developers writing the HTML CSS and JS have a solid design to work from, that the client has already approved.
Do you somehow think that because the PSD to HTML process starts with a PSD file that the output is necessarily going to be a) fixed dimensions and b) lots of images? If so, I have some news for you...
Do you somehow think that because the PSD to HTML process starts with a PSD file that the output is necessarily going to be a) fixed dimensions and b) lots of images? If so, I have some news for you...
Converting PSDs to HTML/CSS has been my job for the past ten years. The "PSD that client has already approved" is part of the problem, because what's been approved is a picture of the website which may be very close to reality under some circumstances, but not necessarily what's going to be rendered on an ancient corporate workstation with IE7 which, by coincidence, is what the client uses to test the website.
Now the workflow slowly evolves and Photoshop mock-ups are still part of it, but what the client accepts is the visual style, mood, UX, content strategy etc. The design team provides style guides, graphical assets, some key components. The UX team may provide a clickable prototype or just sketches of individual pages. Front-end devs build HTML/CSS components, then individual page templates which are usually integrated with server-side logic and filled with content. Everyone can be involved at any stage so it's not a typical waterfall process, rather combining the expertise of different professionals to deliver the best product.
Now the workflow slowly evolves and Photoshop mock-ups are still part of it, but what the client accepts is the visual style, mood, UX, content strategy etc. The design team provides style guides, graphical assets, some key components. The UX team may provide a clickable prototype or just sketches of individual pages. Front-end devs build HTML/CSS components, then individual page templates which are usually integrated with server-side logic and filled with content. Everyone can be involved at any stage so it's not a typical waterfall process, rather combining the expertise of different professionals to deliver the best product.
Personally, I feel like the author is trying to suggest that something like Photoshop is an easier way to build a UI due to the somewhat drag-and-drop nature as well as the instant ability to view the result. Right now, I think both of these are trumped by modern tools: CSS's exactness and variety of properties now allow for more precise design decisions in terms of layout and structure, and its actually faster to develop in the browser iteratively using the DevTools, being able to see the final product.
What about those IT departments that do Powerpoint to HTML? :)
LOL, but I'm working on a web application whose only graphical reference is PPT... and I've done it before. Bizarre, but I suppose it's better than having a scan of a sketch on a napkin from a bar.
>do we really think that Adobe isn’t aware that Photoshop is becoming less suitable for modern web development process? Do we think that they will just sit there and watch their flag-ship and de-facto standard in web design become a plain photo editor?...All these actions show that Adobe is trying to overcome Photoshop’s limitations for modern web design.
If your business depends on Adobe's competence you may want to have a contingency plan.
If your business depends on Adobe's competence you may want to have a contingency plan.
Hahaha. Someone feels threatened. I guess they will always ave business with those who can make gradient buttons in Photoshop, but not the actual CSS for it.
So it's just pining for the Fjords?
No - it's dead and responsive and mobile load times in the graphic heavy sites it produced have killed it.
Did you even read the linked post?
Modern "PSD to HTML" is not about slicing up an image to create image based templates any more than it is about table based layouts.
Modern "PSD to HTML" is not about slicing up an image to create image based templates any more than it is about table based layouts.
The concept of psd to html is dumb from the start.
I would not hire one translator to translate from Russian to English, when the Translator only barely understands English, and one other second translator who Fixes the first translators work.
I would not hire one translator to translate from Russian to English, when the Translator only barely understands English, and one other second translator who Fixes the first translators work.
If you are designer looking to get off the 'PSD to HTML' train, this is the perfect resource for you:
http://www.sketchingwithcss.com/
http://www.sketchingwithcss.com/
What is needed I think is some sort of visual design tool, maybe not full WYSIWYG which respects and understands template languages rather than bulldozing everything.
IMHO, frameworks such as Bootstrap would fit your definition of WYSIWYG pretty well.
What I'm thinking of would be a visual editor that works with things like bootstrap.
http://divshot.com is a good tool, and it integrates with its own hosting platform as well at http://divshot.io
Have you seen http://macaw.co?
I assume that is from a talk/presentation somewhere?
Frankly those slides are nothing but a series of buzzwords and catch phrases - why even both to publish it, if any useful content is lost without the author adding content verbally. (S)He did add content verbally, right?
Frankly those slides are nothing but a series of buzzwords and catch phrases - why even both to publish it, if any useful content is lost without the author adding content verbally. (S)He did add content verbally, right?
Now I see. Modern Web = Power Point
Eew, it's like they're bringing back Dreamweaver with all those code generators.
Sorry to disagree, but it is dead, at least to me.
Blog posts about PSD to HTML are not dead.
Some necrophobes earn their own fates.
"PSD to HTML is dead" panders well to developers. But it doesn't make it true. Let's dig a little deeper into why a developer may want to believe that the incredible toolset contained within Photoshop is completely useless and unnecessary: The inability to use Photoshop.
No one is slicing and cropping a PSD into images anymore. If there are still some who believe that, you need to spend some time talking to designers and front-end web developers. There's really no excuse for this misinformation.
I'm not arguing for Photoshop here. I'm arguing for a design reference point – something that has been created by a (web/UI) designer, for the purposes of reference. It can be a piece of paper, Photoshop, etc. Photoshop makes it easy to manipulate a design. That's it – the central reason for using Photoshop. Moving divs around, adjusting CSS or erasing pencil off a piece of paper is never going to be as efficient as clicking on a layer and moving, resizing it, etc. That's just the reality of why Photoshop is used. This "debate" is reckless abandonment of logic, or simply passive-aggressive anti-design irreverence.
When a front-end/UI developer has a reference for their layouts, it allows them to skip over "where does this go?" and get to their actual job. Some developers are agile enough to extrapolate other form factors based on how the design is structured. Some developers need a desktop, mobile, and tablet design to reference. At the end of the day, no one is slicing images. I am just trying to understand what the actual argument is.
I can only assume that most would agree that an architectural design is essential for constructing a building. Are we really arguing that we don't need a solid foundation to start building from?