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.
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".
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).
Yes! I have a beef with the notion of "design" as a role. It's a thinker/doer split, which is inherently problematic. Software creation is almost entirely design activity; it's just enough different sorts of design that we need a team to be able to do them all well.
For me, design artifacts are a way to communicate and a way to prime the pump so that you can start iterating in the real medium and getting real-world feedback. For both uses I'm alway seeking the minimum amount of investment in design artifacts, because as soon as the real product is live and in use, the artifacts are all candidates for recycling.
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.
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.
Ironically I think the worst culprit for the fixed-width revolution was early CSS. There was a lot more variable-width scaling pages back when everything was tables, but IE-compatible CSS made that nigh-impossible.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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'.
I feel like this doesn't happen so much anymore. At least from recent graduates of top NYC design schools, you'd be hard pressed to find a communication designer / graphic designer who isn't worried about having to learn HTML/CSS because "print is dying".
My hazy recollection was that at some point people doing flat, non-interactive design called themselves "print designers" or some variant. E.g., magazine designers, book designers. I'm wondering when they dropped the medium-specific notion of design. Are you saying that goes back before the 1950s?
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.
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.
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.
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.
I haven't used it recently, but a few years ago? AI was terrible compared to PS. I mean, I like vector graphics and was willing to struggle with a lot of pain for the advantage of using vectors instead of rasters for a project... holy crap AI was awful. Crashy, cumbersome, cringeworthy.
I'm an amateur, so I'm not going to be an expert on the professional features, but a few days with AI led me to go right back to Inkskape.
I have no idea why they put their resources into that thing over Fireworks.
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.
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.
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.
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.
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! :)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
For a startup landing page layout, Bootstrap is more than enough. (see examples at http://www.blacktie.co )
If you want interactivity via AJAX/Angular, you'll need to include some sort of JavaScript of course, but that's outside the scope of the layout question.
No LESS is a stylesheet language that compiles down to CSS. Javascript isn't involved at all, unless you use their script tool to run uncompiled LESS in the browser. That is only meant for prototyping though, in production it will be compiled down to CSS.
The important part for elorant (and me) is that CSS is awful to work with. And everyone in this thread is proving it by pointing out that you should use some kind of translation layer instead of actually touching it.
Well, there's two things at play here. The complexity of the CSS model in the browser (plus all the browser-specific quirks) and the CSS syntax. Less only solves the CSS syntax issue.
My reading of this thread is that it was started based on the complexity of dealing with CSS in the browser rather than dealing with the CSS syntax.
CSS also has serious issues with its design (not just syntax) - it's a pretty awful markup language, because it was created apparently without reference to hundreds of years of graphic design and text layout and missed out some essential typographic and design concepts.
To pick a few examples, until recently you couldn't have grids, multiple columns of text (still pretty broken), embedded fonts, and the box model is unnecessarily complex, which led to loads of bugs in the browsers. That's easy to say in retrospect of course, and lots of the problems are now being fixed or worked around, but it's a pretty gnarly language, and many criticisms of it are not based only on ignorance but on substantial flaws in the original design. CSS is awful to work with, and is only slowly getting better.
The slowness is largely due to competing interests & implementations by those interests. I don't think blowing away CSS completely would be a good solution - just look at the skepticism by many over Google trying to implement Dart in Chrome, and whether it'd be successful in eliminating JavaScript.
It does suck to work with, but it is workable if you put in the time investment to learn it, just like any language. Nothing that justifies flat out incorrect statements/dramatic behavior.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
To pile onto wonderyak's point, I am a developer, not a designer. I wish I was also a designer, but due to where my talents and experience lies, I cannot do both well at this point. The problem is that I cannot tell what is and what is not important in a design that is handed to me. I have had conversations with designers where I inadvertently change a margin on a callout box by +/- 10% and the designer notices and explains that they arrived at the exact margin by a long research process, and by the way it matches all other places where the margin is exactly 40 pixels and not 36, etc. There are changes that are not consequential and there are changes that completely undermine the message the designer was trying to send. This is not an ego trip. This is a professional telling me that they've thought through the problem and I trust they know much more about the problem domain than I do.
Ideally, I try not to change the design if possible. However, unless the designer is very good, it does require lots of tweaking here and there, which introduces delays and compromises the vision for the finished product. If a designer has long since walked away, it can become a huge problem.
As a designer and a developer (I often do both), I think I see where you're coming from, however I feel this is more a sign of a breakdown in the relationship between the developer and designer than a shortcoming of the tools. Design isn't so scary - I think a lot more developers should try to pick up a little, just as designers should know at least a little about the final medium for their work, and in an ideal workplace there should be at least a handover with plenty of chance for feedback on things like text styles, not just throwing something (PSDs in this case) over the wall from designer to developer.
I would never accept a photoshop comp as a developer or send one as a designer and expect it to be reproduced exactly, because it's in the wrong medium, and it's a terrible way to specify things like text sizes or column widths except as a general indication. There has to be some give and take (and a lot of feedback) in a process going from something static and done without grids like a sketch (e.g. a psd or pencil sketch) to a final website, so what you describe in your feedback from the designer is a normal process I think and to be welcomed, it's inevitable in the translation to HTML. The design will change as it has content added and goes into templates, adaptations will have to be made, and the design must be flexible enough to deal with that, and your designer should be around to help with it - if they're not they're not doing their job properly.
I guess what I'm trying to say is that dealing with change is part of the job in design, and your designer should gracefully do so, in which case it is no problem if they gave you a vague psd - it should be vague at the early stage before implementation, because there will be changes, and additionally, html is just not a medium which allows us to specify layouts which are exactly the same in all conditions - browsers, text sizes, fonts, scripts, proxy servers mangling images, user stylesheets all affect layouts, so you have to accept that not all users will see content at exactly the same sizes or with the same fonts or even the images as you intended them (if they're on a mobile network, a proxy might have downsampled the images).
So this works really well when you are working with the designer. When I can walk into your office and say "hey, can you pull up the dev site and take a look at page X? I think we need to figure out a better way to display this" I am very happy. Even mediocre designers can deal well with this modus operandi and produce much better than mediocre results.
Where we run into a problem is when a client hires a design firm, works with them for months on a new site or application look and feel, gets invested in it, pays the designer and maybe even starts development with a few days' overlap with the dev shop. Another example is when you deal with extremely low budget jobs (less than $1k), where you are simply trying to minimize hours spent on a project. I have done WordPress themes off good, clean PSD's only in less than 8 hours. I have also spent close to 80 hours on some where the PSD's were super detailed, but lacked any kind of direction. When the designer or the developer is not in-house, communication is key, but is often a place where costs are cut.
I truly believe both design and development must be ongoing and collaborative processes, and the problems you've identified above are all down to trying to divide work at points where it cannot usefully be divided - the first scenario you mentioned is the only way to produce good design IMHO - as a collaboration with the client and any other parties like developers.
I agree with everything you're stating here, I just wish it was that easy in practice.
Some of the problems with deliverables is managing client expectations, they expect or have gotten used to seeing output of a PSD that counts as 'what their site will look like'. The creation of a PSD as a deliverable for the 'final design' is boilerplate for every agency I've ever worked with.
Responsive design has finally started nailing the coffin though; it becomes too cumbersome for designers to create renderings of different viewports, let alone understand the intricacies of how media queries work or how assets are delivered to different devices.
There has been a lot of creative thinking about deliverables (Style Tiles, Atomic Design) which is helping us get over the hump.
I would hazard a guess that most of the sites in the SMB space are either WordPress templates or custom designs that were then handed off to a service or an outside developer to make into functional websites. Sometimes, the developer doesn't get to see anything until the client has signed off on the design. I see this happening with large companies which do multiple millions of dollars a year in agency work.
Yes, since there is an implicit agreement beforehand that the PSD should be converted to HTML/CSS.
For example, if I missed a border on an element or margin spacing between text areas this would be something I would be expected to fix. The designer would most likely point this out. Many designers I've worked with get very upset if you change anything in this regard without some sort of discussion.
The point you bring up about text handling is true as well, which is another reason that PS is not a great way to design for the web. AI might be a little better, but not by much.
Yes, since there is an implicit agreement beforehand that the PSD should be converted to HTML/CSS.
I see why it'd be a pain for you, but feel like this process of handing over a supposedly pixel-perfect design is inherently broken - without collaboration the design will be dead as handed over - it should be changing constantly as you encounter difficulties, first in translation to templates, then in putting in content.
Specifying text sizes in a PSD is insane! It doesn't even have styles so I see why the designer hadn't bothered. I think I'd honestly prefer to receive a hand-drawn image with scribbles for the different text sizes.
Oh, the process (as normally done for the past decade) is completely broken. Thats one of the reasons that the groupthink behind "PSD to HTML is Dead" is important in spite of how hyperbolic the statement is.
There is always an adjustment period throughout development, however just a simple understanding of the medium would eliminate all but the toughest of these problems.
For as long as I've done this I have mostly worked with designers that started in print, have zero to very little experience in working with the web and do not care to learn.
It is not just the designers who hold blame here though as the instituions which employ them do not require anything more than they've done their whole careers.
Combine that with the fact that a lot of these designers are expected to design for both print and screen, it creates a situation where you cannot expect someone to know all of the nuances of both mediums. When this happens, things like declared text sizing is important in the PSD because thats how they set up their print files too. Everything is implicit.
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.
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.
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.
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.
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.
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.
It may have been a rant, but there was some great info in there. Being a designer, I didn't take offense at all. Many designers don't want to "get there hands dirty" with html, but I think that's changing, especially as there are newer designers that have never designed for print entering the market.
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.
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.
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.
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.
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
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).
Because stock iOS (iOS 7 changes this a little bit, but not much) only gets you so far. Things like pixate get you a little further, but ultimately some sort of visual design process comes into play, typically with a tool that's been used in that process since time itself began.
Background: 20 years as a creative technologist currently doing iOS based experiential retailing for huge brands where the interactivity and visual appeal simply doesn't exist in stock iOS. And I also wrote an app publishing tool that works similarly to Adobe DPS (build informational apps in Photoshop, see http://www.youtube.com/watch?v=YXlHFhbqzHU).
"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.
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.
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.
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.
+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.
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.
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.
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/
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.
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.
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.
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.
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.
⚫ 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.
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.
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.
> 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".
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.