PSD to HTML is Dead
blog.teamtreehouse.com
blog.teamtreehouse.com
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.
I came into the world of UX and UI design by way of architecture, and it was quite a while until I found tools that really made a sensible workflow:
• Dot grid paper, index cards, pencil, and scanner for sketching & wireframing or paper prototyping (white boards too of course)
• Fireworks, Photoshop, and/or Sketch for creating graphic assets or the occasional mockup
• HAML for generating HTML
• SASS & COMPASS for creating CSS
• Foundation as a CSS framework for prototyping
• Sublime Text with Emmet(Zen Coding)
• Live Reload running on browsers in another monitor
• Git & Github to get things on the development server
My web developer partner and I sometimes refer to this as the "designer's stack".
[Edited for clarity]
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).
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.
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.
(upvote nonetheless)
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.
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.
And don't even start on responsive CSS and PSD-baking software.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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! :)
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 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 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.
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.
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.
At one point in time you couldn't do gradients in CSS, so that's exactly what you did. Luckily, that era is over.
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.
For many projects of course, it won't be sufficient: clients want (and probably need) a stunning Photoshop mockup to provide feedback and boost their self-assurance.
But if you combine a simple CSS framework (even if it's just for a grid system), Chrome's inspector, a selection of Google Fonts, and some sense of "flat" aesthetics, you can come up with a more than decent, and sometimes amazing, design. Plus, it takes 70% less time, especially considering it's usable right now.
37signals mentioned this "skipping Photoshop" attitude in 2008 [1], but I never quite managed to put it into practice until recently.
[1] http://37signals.com/svn/posts/1061-why-we-skip-photoshop
You're doing something wrong then.
http://coding.smashingmagazine.com/2013/08/09/absolute-horiz...
Even animations are easier to do in CSS due to CSS3 animation libraries.
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.
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.
Sure, it's not all bad, it got off to a pretty flawed start, but has been steadily improving.
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.
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 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.
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.
We shouldn't be designing or developing in silos. I love working with developers who keep me in the bounds of reality.
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.
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.
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.
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.
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.
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.
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.
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.
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.
https://cloudup.com/c5RmHN8t1QZ
https://cloudup.com/cmpmBEYg93c
Thats 27 different font sizes for ONE PAGE of a site. I bet most of this was done through scaling layers to 'fit' into spaces.
There were also 42 layers named some verson of <shape>-n.
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.
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.
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.
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.
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.
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).
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.
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.
It even came with a PDF style guide outlining line spacing, font size, colors in hex and margins/padding.
I've never been so elated to get a PSD.
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.
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.
I've been waiting over three months now for my designer to give me this. I mention it every time I see them and it never gets done.
Do they like my awful pink error boxes or just avoid errors when demoing???
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.
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
Background: none.
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).
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).
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.
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.
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 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.
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.
And if you're trying to extract gradients from Photoshop into CSS, SCSS, SASS: http://csshat.com/
http://git.zx2c4.com/psd.js/about/
git clone git://git.zx2c4.com/psd.js
A very large number of people who do web design for a living are much better at making their visions a reality using PhotoShop than HTML/CSS.
⚫ Consider the screen as a sheet of paper on which you can 1) communicate your message 2) provide a UI, and 3) apply your branding. Modest amounts of logo / artwork, color palette, and styling touches go a long way. Other than that, it's a rubber sheet. There are no fixed dimensions.
⚫ Start with a basic HTML5 framework. body, header, article, aside, footer.
⚫ Put minimal elements above the fold. Your header, logo, and some basic navigation. Emphasize body text and / or UI.
⚫ You almost always want to design around the text. That's your payload. For interactive tools, controls layout should be clear, consistent, logical, and most of all provide enough space to meaningfully navigate options. For that last: size-constrained modal dialogs or their equivalents (pop-up menus, etc.) are strongly deprecated. Unless the user needs to see other content while performing input, that dialog should be front, center, and the principle screen element.
⚫ CSS gives you a whole slew of tools: special selectors, including :hover, :active, :first-child, :last-child, :nth-child, :nth-of-type, shadows, columns, and more. No, MSIE legacy doesn't support many of these. Fuck'em.
⚫ Stick to light backgrounds and dark fonts, with few exceptions. http://www.contrastrebellion.com/ is strongly recommended.
⚫ Think of your page in either ems or percentages, and almost certainly ems (scaled to your principle body font).
⚫ Provide a minimum page margin of around 2ems for desktops. For mobile, enough to keep text from flush with the edge of the screen, 0.25em typically. Don't crowd your text. I accomplish this by setting a max width (usually 45-60ems depending on context), and a 2em left/right internal padding. This provides a comfortable reading width but preserves margins in narrow displays.
⚫ Scale fonts in pt, or use relative/absolute sizing based on the user's preferences. I recommend "medium" for body text.
⚫ Other than image elements and logos, avoid use of px. Never mix px and ems (say, for line heights).
⚫ Rather than a traditional sidebar, use CSS column elements for your asides, which are then full-screen width. @media queries can toggle between 3, 2, and 1 column views.
⚫ If you've got to float elements, float right of text rather than left. This is less disruptive to reading. 0.5 - 1em padding or margins is usually appropriate.
⚫ For long lists, I'm growing increasingly partial to "li { display: inline;} or inline-block (the latter allows trick such as ":first-letter" but fails for wrapping.
⚫ Make modest use of dynamic elements. I'm generally not a fan of flyouts, automatically opening menus, etc., and they're among the first elements I nuke when modifying sites. Color shifts to indicate links and other dynamic elements, however, can be useful. Google's "Grid" is a notable exception to this rule.
⚫ Don't fuck with scrollbars. Allow the user environment defaults. Yes, Google+, I'm talking to you.
⚫ DO NOT USE FIXED HEADERS OR FOOTERS. Far too many displays are height-constrained, and robbing another 10-25% of the display with elements which cannot be scrolled offscreen is an insult. If you've got to fix something, put it in a margin. Do not fix ANYTHING for mobile displays.
CSS modification: Metafilter lite http://www.reddit.com/r/dredmorbius/comments/1v8fl5/css_adve...)
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.
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".