PSD to HTML is not dead(xhtmlized.com) |
PSD to HTML is not dead(xhtmlized.com) |
"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?
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).
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.
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 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.
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).
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.
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.
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?".
More on this (from a programming perspective): http://vimeo.com/54042336
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.
Hopefully this will confuse her enough to stop asking for pixel perfect html/css.
I believe that more or less sums up the sensationalist headlines.
Thankfully, I am not the one usually sitting in those meetings.
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).
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.
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.
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...
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.
If your business depends on Adobe's competence you may want to have a contingency plan.
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.
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.
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?
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.