Spencer Fry
writes on January 15, 2014
About a month ago I hired a freelance front-end developer to code around twenty pages for Uncover – both marketing pages and pages behind a login. Interestingly enough, I hired this person via Twitter. While I didn’t vet him extensively – not asking for references, previous projects or code samples – we did speak on Skype for a solid hour, going over his experience and my requirements. After negotiating a budget, we got to work the very next day.
When hiring freelance front-end developers, I always have two concerns: (1) is their code going to be well-written, and (2) will they be pixel perfect when it comes to replicating the PSD files? More often than not when working with freelance front-end developers, I’ve found that you rarely find both capabilities in anyone under $80/hour. As Uncover is a bootstrapped company, I was looking to pay $40/hour for this job, knowing perfectly well that I’d be working with someone more junior at that price. My hope was that the person would produce well-written code and that I could project manage my way to pixel perfect.
As my new contract front-end developer began to deliver coded pages, it was clear that his code was up to snuff. Maybe a few small convention issues here and there, but ultimately those are matters of opinion in front-end development. The bigger issue – as I had foreseen – was that there were far too many mistakes on the pixel perfect side of the job. When I looked at these coded pages alongside our PSD files, there were obvious mistakes such as spacing issues, font sizing problems, and missing components, All easily spotted when comparing the two files side-by-side.
Contents
Having to fix the mistakes
I was working remotely with this front-end developer, so he would push changes to our GitHub repository for me to look at and review. I’d then load the pages that had been delivered side-by-side in my browser with the png file we had outputted from Photoshop. It became very clear when switching between the two where the differences were.
I would then reply to the front-end developer’s email with a list of changes that sometimes included screenshots of obvious mistakes. As I mentioned above, I anticipated some of this happening because of the low hourly fee, but not to this extent and not repeatedly. Some errors were blatant and definitely should not have been overlooked. Others were subtle but stood out when you tabbed quickly between the mockup and the completed HTML/CSS. I was hoping that I would see fewer mistakes going forward as more pages were delivered, but this wasn’t the case.
Luckily, the person I was working with was more than happy to fix things as I compiled lists of changes for each page. Even though with all said and done it wasn’t all that big a deal for me to create these lists, I would still implore all front-end developers to focus their attention on pixel perfect development. When you are being handed a PSD file that has been carefully styled and spaced, it’s your job to slice and dice it perfectly. The designer chose 30px spacing rather than 40px spacing for a reason. I shouldn’t have to go through each page with a comb to find mistakes.
How you can prevent mistakes
The biggest way to prevent mistakes as a front-end developer is to keep learning and continuing to practice. You can keep learning by taking advantage of Treehouse lessons and staying abreast with the latest conventions through following Hacker News, browsing Stackoverflow, reading Reddit and other notes on the craft.
As a person who learned to program in the past two years, I know what’s helped me the most in continuing to practice. Take any PSD files you can get your hands on and work on developing the front-end for them. One of the best lessons I received on front-end development when I was first starting out was when one of my friends gave me the PSD files of their website and I had to go through them and rebuild the HTML/CSS using Bootstrap. It was very helpful to him because his codebase was quite out-of-date and using Bootstrap would help with that; and it was very helpful for me as I got to learn while doing.
While practice will help you learn how to prevent mistakes, the best thing you can do is to review your code before handing it in. Just as writers write rough drafts and then edit them, code requires editing as well. You may have fudged something to get you by while you were getting a handle on the project, but it’s important to go back and fix things before delivering the work.
It’s not nitpicking if you want to be great
It may sound like I’m being picky, but mismatches of this kind taint the quality of the completed work. The work you do as a front-end developer is a reflection of the finished product (i.e., the pages) that you produce. Any errors or omissions reflect poorly on the job you did – even if you got 99% of the way there – and your employer will not be pleased to see anything but pixel perfect work.
Front-end developers have two responsibilities, and if you want to be great in that field then you need to care about both of them:
- The quality of the code needs to be excellent and modular. If you code the designs so they’re not extensible, then you’re making it very difficult for other people to work from the code you’ve written. Part of programming excellent code is to be up-to-date on the new ways of doing things. Programming languages and conventions are ever-changing, and it’s important to keep up.
- The other responsibility is to deliver back pixel perfect code in relation to the design. Anything short of that is failing to deliver great work.
I’ve worked with many front-end developers over the years – both freelance and full-time – and you can easily spot a great one based on their attention to detail, which is required for both (1) and (2) above. I’m still very happy with the front-end developer I hired and I would hire him again, but I hope he learns — and others do too — that pixel perfect front-end development matters as well as great code.
Seldom do I get asked to do pixel-perfect. If I can’t persuade the client of the weakness in the whole concept, I say I can do it. My project estimate goes up 400%. Simple. pixel-perfect is from, like 2000-2009 webs. And when I look at example pixel-perfect sites out there, I see that I could do a more elegant design right away if I were to be free of pixel-perfect restrictions. So, basically, do people want pixel-perfect, or do they want it to look good. One or the other folks.
When someone says about pixel-perfect design, I just start laughing. Cause this person for sure has no idea how a browser renders layout.
Yes, “pixel-perfect” is a print term that was somehow moved over to the web world and is completely inaccurate.
The “front-end” developer position has mutated into a jack-of-all-trades position which is continually growing more complex and many companies are still treating it as a low-level position.
FED need to know Adobe tools well, HTML, CSS. RWD, JS, at least a few JS frameworks, performance and unit testing, etc….it’s an impossible task.
“Pixel perfect” development results in bloated, ugly, and non-modular CSS, even if you have a rockstar designer.
When you have to add things like margin-bottom: 19px; and margin-bottom: 21px to similar items to get them to line up, you no longer can make use of helper classes based off of a base size, and you wind up with a lot of unmodular code. This is not the developer’s fault, and is inevitable when the client asks for “pixel perfect.”
The developer should match font sizes, line-heights, and colors precisely on the first go-round (something the dev you speak of failed to do), and the designer should have designed based off of a vertical rhythm and in multiples of a base size. If the developer follows those guidelines, things will look pretty darn close, and more importantly, consistent. Minor tweaks to a lot of elements results in magic numbers scattered throughout your stylesheet, and doesn’t necessarily make the final product look “better.”
Pursuit of perfection has been a always an interesting topic of debate between designers and front-end-developers. As a professional front end developer creating a view closest to a provided mock (on major browsers) is my passion & it comes with a cost of additional extra lines of styles. it does depend on what is being achieved from that specific page or site. Getting a pixel perfect view especially in responsive layouts using bootstrap is highly time consuming.
I won’t regurgitate the same old “pixel-perfect” comment as has been stated before in the comments (it’s perfectly valid, don’t get me wrong). For me, I was turned off by the house comparison. Your house rarely changes sizes (unless you can constantly remodel) – your walls don’t move on you and suddenly allow significantly more or less space that you can suddenly utilize to do different activities in rooms. Be willing to follow your comparisons to their logical conclusions – if website is a house, your blueprint needs to be flexible depending on the size the house is that day/visit.
Certainly, representing the design as accurately/proportionally as possible on the multitude of screen sizes is the job, but we need to balance the time spent matching designs against the that spent making the site usable, responsive, and fast.
We need to focus on working together rather than writing articles leaning one way or the other. Us web developers need our designers to think about the user experience on multiple platforms as much as they do the visual elements – or at least have some idea of how your users are using a site. That’s the ultimate goal, and when we both are flexible, we’re both happy at the end of the project.
Obviously written by someone who doesn’t understand the internet, not much more to say really.
I personally like working with designers who understand that things can’t be pixel perfect easily. When you need something that is pixel perfect, such as in a legal situation, that’s understood, but this is something that really doesn’t matter to the average user.
The best designers I ever worked with also knew CSS/Html and were able to articulate the fonts, colors etc. that they needed.
This type of article makes my head explode. YOU want pixel perfection, 99.8% of your users don’t care! Who are you making your site for, yourself or for users?
Focus more on UX and less on pixel perfection. That’s what makes people want to use or not use your site.
Yes you can make everything align perfectly in Photoshop because there are variances, you open your PS file in the same software everyday. Every web engine renders things differently when it comes to real code and display.
Greetings! Very helpful advice within this post! It’s the little changes that make the most significant changes. Many thanks for sharing!|
The problem with the internet today is that there are two many browsers. Pixel perfect design then requires yet moar code to be written to ensure each browsers is pixel perfect. There are tos to flick between multiple browsers and a PSD but it can be difficult wasting both the designer an developers time. This becomes particularly tricky with large sites and margin size issues, I tend to print my design at 100% in tracing paper to ensure each browsers is pixel perfect. People will laugh at me saying this but I wish we could all go back to Internet Discoverer 6.
Hey BenJam:
I see you are trying out Jenn Schiffer’s gimmick. LOL
I don’t waste time upfront making the PSD to HTML pixel perfect because I believe it should be handled at the very end when you are tightening up your designs and trimming any hedges before it goes live.
These issues might be spacing, margins, font-sizes.
However if you were a good designer, you would have created a layout that has utilizes reusable code and pays attention to areas where 1 line of code will take care of most of the site.
This is problem with designers and developers. Designers are not conscious of what code can be used to make better and more efficient designs.
Pixel perfection is easy, it’s getting designers to realize that other steps take priority over there 1px shadow or 15px font.
I can write css. I design screens in Sketch. I provide DETAILED specs and annotated screens, using a clearly noted scale. Yet, I get back web pages that are seriously off from the alignments, spacing, hierarchy and fonts provided to the F/E developer. And the html is not well written, either, using spans for block elements, divs for html headings, etc. I understand that pages will not render exactly the same across browsers and devices but that’s no excuse for producing html pages that don’t come CLOSE to the design. It just isn’t.
“Pixel perfection” is clearly an outmoded idea, more at home in the last decade than this.
However, that is no justification for sloppy code, or sloppy design for that matter.
Maybe I’ve been lucky, but the front-end coders I work with generally have at least as good an idea of user experience and “design” consistency as do the designers, but this does not equal pixel-for-pixel replication.
I also question whether a PSD is even a good starting point these days? Often, probably not in these days of sketching-in-code and responsive prototype frameworks.
Ultimately, I always encourage my designers and front-end coders to work together (if indeed, they aren’t the same person) to deliver a great experience across the board.
great information….
good post..thanks
Hi Spencer, I’ve liked your contributions to Treehouse, but this one isn’t well thought out at all. I understand your sentiment, but if you’re expecting a half rate designer to give you the same results as a full rate designer, and you’re on a blog that is part of the community driving mobile-first design forward, you’re speaking out of both sides of your mouth. It’s misguided and, honestly, condescending to expect pixel perfect design if the developer wasn’t involved in discussions about the implementation process and able to help in wireframing and prototyping the code base. I’d be curious to know what you consider clean and perfect code, because if it means 4x the amount of code to a get a line height 2px closer, then that is sincerely misguided and not something that I feel Treehouse should be advocating. It’s irresponsible web development and it’s putting the designer’s needs above those of the end-user. Now, with that being said, if the mistakes are egregious and the developer is being lazy, you’re certainly within your rights. But if hacks are being used to get items exactly in place and the developer is following best practices (and fighting in his weight class when it comes to rate), I think you’re in the wrong here on giving this advice to the community.
I’m happy that you enjoy my articles. I think you (and others) are getting caught up on the term “pixel perfect”. If I could go back and edit things, I’d use a different term. 🙂 It’s less about being off by two pixels to me and more about general attention to detail. I might do a follow up on this piece as this article is getting a ton of praise from the design community and a ton of hate from the developer community haha.
Hi Spencer:
This article seems to very polarizing. I think everyone brought into a web design team should have attention to detail, no doubt. However, I think it’s very distressing that what you got out of the discussion is that designers agree with you and developers disagree with you (punctuated: haha).
It isn’t about designers vs. developers – that’s a fight in which everyone loses. Teams should be working together, and not at cross purposes. We’re all in the same gang, trying to make great websites and products.
http://www.youtube.com/watch?v=UJD1oDKKMdM
I know you’re a person who has some stroke in the web community. But I believe that you should have vetted your contractor more carefully, and they probably did not need to be called out in this article the way that they were. Perhaps giving someone a smaller project at first, say a page or two, instead of twenty, would have revealed what you needed to know more quickly and at less cost.
Good day.
I am a designer first, a front-end developer second (about two years now). I have been on both ends of the issue. I have handed out my designs for coding, and feeling frustrated with what I have interpreted as lack of attention to detail. I have also tried to get my own designs rendered perfectly myself… and struggled.
When I stepped back to really figure out the areas which posed issues to reaching said “perfection” it always came down to typography. Boxes, grids, and images are a no-brainer. It’s not ambiguous to translate those from a PSD to code and anyone who can’t get that right is, in my opinion not paying attention. Any good designer will tell you that it is typography which sets the stage to all of the subtleties of spacing and rhythm which just makes things “work” and this is where a PSD to HTML workflow is dead.
You cannot use a design tool in which measurements do not translate to the web any more than you can bake a cake using grams as a unit of measurement when all you have a scale which reads in ounces. Translation is necessary. But what if you didn’t need to translate? In the case of design for the web, what if you had a typographic tool meant for the job?
About a year ago I started using typecast. For me every single design project starts there. I make my choices for type, spacing, rhythm, color etc right there. Once that’s done 90% of what makes my designs “work” is finished and it’s done right in the browser, using html and css (yes, rems and ems etc), with all code ready to export as a bonus. I can export a full html style guide and no developer (myself included) needs to start interpreting, guesstimating, or using the ruler to translate.
If I want to include said type in my psd’s I just grab some screenshots from typecast and dump them in my mockup (I simply set the layer to multiply to get rid of the white background). Pixel perfect and the type in my PSD looks exactly as it should in the browser… because it *came* from the browser.
It’s not a free service, but what I pay is more than worth it by slashing out wasted time in project management (when outsourcing developers) and tearing my own hair out when flying solo. My designs have gotten better to boot. The speed benefits are multiplied when you factor in responsive concerns.
I think if you ask any designer to really pin down where the issues lie in this pixel perfect rainbow they are chasing, most problems could invariably be traced back to the heart of design: typography. Photoshop is a terrible tool for that and you cannot blame developers for doing their best to translate your vision created in a tool so blatantly not meant for the task. If you can’t / won’t use a tool like typecast, at the very least do your mockups in inDesign where typography is rendered much more accurately and you can use paragraph and character styles to mimic css… of course your developer would need to know how to work with those files.
I think some are getting too hung up, as Spencer suggested, on the ‘pixel perfect’ term. And as Megan suggested, “If I draw a blueprint, that’s the house I want built.”
I’m currently doing front-end dev work on a web app where the designer has spent a lot of time with the design. It’s obviously very well done with great attention to detail. I’m a trained designer turned developer so I understand that both he and my contractor expect my work to reflect his designs. Is it “pixel perfect?” No, but it is very close to the original designs. We did need to make some minor adjustments on some of the form data and how to handling scrolling of content areas.
My wife and I built a house a few years back. I’d say 98% of it is exactly what we asked for. The other 2% the contractor showed us how to either make it better or fix a design flaw. He trusted us, we trusted him.
Really learnt alot from this article. As a front-end developer for over 5+ years I always try to delivery 99% pixel perfect coding to my clients. I once worked with a Client from Canada and he told me his programmers are so happy with the way I code, well commented and semantic. That have gotten me some few bonuses from my clients. Works as a freelancer on elance https://www.elance.com/s/xgcompany21/.
Thanks
I would urge any aspiring front-end developers to take this article with a grain of salt.
At the end of the article, the author offers some responsibilities of a great front-end developer: to deliver excellent, modular, and pixel perfect code. This advice is misguided, I’m afraid. As a developer, you bring the voice of the user to the design. It is your job to make a website usable, responsive, and performant. Secondly, you should strive to be as efficient as possible. Sometimes, being efficient means writing modular code. But other times, it means quite the opposite.
There are plenty of organizations that specialize in churning out HTML from a PSD. When someone hires you to create a functioning site from an established design, they should be hiring you for the expertise you hold in your domain. If an element in the design would negatively impact the usability of the site, you should offer a suggestion on how to improve it. If complex layer styles and blend modes make a page less responsive, you should ask if it can be simplified. If a design flourish would take a week to recreate, it’s your responsibility to let the client know that your efficiency will be impacted.
As has been noted in other comments, the concept of a “pixel-perfect” execution is outdated. A better title would be “Front-end Craftsmanship Matters.” If the author hired a developer to deliver a “pixel-perfect” execution of a design, and the developer fell short, then the developer would be at fault. But, to express this frustration in an article stating that pixel-perfect code is some ultimate goal every developer should strive for is misleading and just plain false.
This article’s use of the term “pixel-perfect” also implies that the designer knows best – that developers should treat the design as an immutable object. Do you want to be a great developer? Have an interest in the final product. Have pride in the craftsmanship of your code. Have ideas about how the product could be made better.
A design is not like a blueprint; a design is a keyframe. It is up to the developer to bring the design to life.
I also suggest this video from Harry Roberts: https://www.youtube.com/watch?v=ldx4ZFxMEeo
I am a graphic designer and (in training) front-end developer. “Pixel perfect” is an outdated phrase, but its spirit is still very relevant. How about “faithful reproduction” as an alternative? These days certain elements need to be flexible (particularly margins, line lengths and image crops), but it is the front-end developer’s responsibility to reproduce the character of the design. Designers: For our layouts to properly honour content on all devices, we need to learn to be flexible. Developers: This flexibility should never “break” the language of a particular design. As the web evolves we all need to communicate clearly what we expect from our colleagues, and be ready to compromise when it makes sense.
Was your design really for the web?, most of the time they aren’t, this pixel perfection imposed by designers usually lack any knowledge of modularisation and/or how we implement it in code, this obviously leads to tons of poor quality code trying to reach this so called pixel perfection.
And going into all the responsive part I guess it’s of no use, everybody commented it, but did your designer really think of this? or using web safe fonts? yeah, I’m pretty sure it wasn’t just the developers fault.
This is more a fault of expectations and pretty one-sided.
Here are my thoughts on the subject, to save them getting buried in a comment stream: http://blog.omgmog.net/post/on-the-subject-of-pixel-perfect-psd-to-html-css/
In my experience, there are more often inconsistencies from one PSD comp file to the next than are with a solid developers output. I can easily reproduce a consistent gutter, or variances on a gutter (for example) in my code than I typically get in a comp. This, not unlike CSS, gets exponentially worse with every designer added to a team.
I think pixel perfection works better when a style guide is clearly defined. Fonts, font-sizes, standard padding/margin declarations, page/component widths, grids, etc can be declared with values in written form in the step between wireframe and design.
Sass can make a solid front-end dev great at pixel-perfection, but don’t always assume that those PSDs we’re pixel-perfect out of the gate. Additionally, there’s a large movement to move from pixels to em’s and rem’s to support RWD, so whether it’s a vernacular issue alone or a larger “how the designer needs to change” discussion is irrelevant until both departments agree on the solution. Sure I can convert your pixels to em’s, but shouldn’t we both be thinking along the same lines to start?
I tend to disagree with most of what this article is postulating. That being said, I still try to perform as near pixel-perfect dev as I can – for all of you out there who are trying to achieve the same and don’t use an overlay program, there’s a nice Chrome extension for it > http://goo.gl/yqrvV
I recently wrote on this topic from a different angle:
http://lukeaskew.github.io/writings/proportionally-perfect-design.html
Attention to detail is a valuable commodity in front-end development, but I think it’s time for us to reframe the discussion, especially in light of you recent post “PSD to HTML is Dead”.
Nick just posted pixel perfect is out the door. The same thing Chris Coyier stated a year ago. And I have had to deal with this issue a few times, it is cheesy to think your little photoshop/ powerpoint mock up is going to look identical online…. duh – it will be close but all the various screens and browsers will have something just a tad different from time to time.
I’m a junior front end developer just out of University and was lucky enough to get a job straight away in a small design agency.
I initially had the same problem with such things like line spacing and font sizing etc but quickly fixed this and now it’s second nature to get these right first time. I think that comes fairly quickly with experience and in this case I would guess the Front End Dev wont make the same mistakes again.
I believe the problem lies occasionally with the battle between designer and developer. I often run into the problem of usability/functionality vs Design. The designer wants it to look a certain way yet I know in my head it may not necessarily be possible as it is simply unfriendly to the user or is bad for SEO and search rankings. However at the same time there is quite often a compromise between the two which will work how I want it to and look how the designer wants it to.
I’m a front-end developer through and through, I can only really use Photoshop to slice and I can’t really do too well on the back-end either. My whole career has been focused on front-end specific languages.
I have to say, I don’t agree with this article in the slightest, you’re very much suggesting it’s always the developers fault. It’s very much a collaborative effort when building a design, you can’t just hand over a PSD and expect the developer to deliver it in a pixel perfect manor. Developers need consistency too, if you’re complaining about font sizes, maybe they want their headings to be consistent. Spacing issues? The developer probably wants consistent margins. If you don’t work closely together and don’t learn to give a little as a designer then I would suggest you lack a true understanding of the web.
Maybe the developer did lack that attention to detail, I like to think my attention to detail is incredibly high but I will never build a pixel perfect site. At the end of the day, you’re building a webpage, you’re not building a design.
This is a bizarre article. It’s hard to tell what exactly you mean by “pixel perfect” and without seeing screenshot comparisons of the original PSDs vs the rendered pages, exactly how egregious these differences are. When I design, I get close, but with font rendering issues, the difference in rounding of em units from browser to browser, responsive layouts, etc., designing pixel perfect is a loser’s game. Of course, there’s little mentioned of whether we should be bothering with PSDs to begin with (the design in the browser/use style-tiles argument).
“….exactly how egregious these differences are…”
That sums it up perfectly. Obviously design is important but being borderline-obssessive nitpicky doesn’t help anyone nor does it help the industry. Sure you could throw a crazed Steve Jobs anecdote about perfect design and specific mm dimensions of rounded corners and bevels about but at the end of the day functionality (yes, visually too), ROI, and scalability is key in websites and applications.
No one cares how awesome your site/app looks because your font and line-height are exactly as the designer intended across 54 devices if it doesn’t work properly.
Just to pass comment on how it would be helpful to the front end guy, if the designer were to point out in a text document, where pixel perfection was important. i.e explain that all blocks of text are 10px apart and that columns are Xpx wide and the margins are always x…
Too many times I’ve had to *measure up* PSD’s before writing the CSS and too many times I’ve had to ask if “all the spaces should be the same” when some are 12px and some are 11px.
Measuring pixel distances from a PSD is a PITA – provide the PSD as a guide and then explain the grid, the font sizing, the image margins etc. Don’t make work for your front end guy, explain the measurements you used for the layout and he’ll breeze through the work and deliver pixel perfect.
Was looking for someone saying this. Most often, the spacing obtained from PSD via the ruler are ambiguous, line-heights don’t match up, margins and paddings are varying a few pixels across the whole thing.
I usually make a point of streamlining this, making spacing consistent, for instance rounding 97px to 100px rather than 100% faithful to the source, at least where I am certain that this was by error and not intentionally.
In my experience, there is no such thing as a pixel-perfect PSD, so how can there be a pixel-perfect adaption?
The term “pixel perfect” is fast joining “XML”, “non table-based layouts”, and “CSS and Java/C++ expert” as reliable indications of a job to avoid.
What do you mean by “spacing issues, font sizing problems, and missing components”? Font sizing as in the font size in my PSD is 16px and the font size on the page is 17px? That would be pixel perfection. But really, its probably going to look different even if both are set to 16px. If you are troubled by that, make sure you aren’t in the room when the developers test this site outside of Chrome. If, on the other hand, the font is 16px in Photoshop and 20px in the browser, that isn’t pixel perfection. That is a developer who made a mistake. And developers making mistakes is not cause to write a blog post, especially not one which makes confused use of an outdated standard for web development.
I think you’re getting too caught up with the term “pixel perfect” design. Can you propose a better phrase that means the same thing? If it was only a 1px font size different then I wouldn’t have made such a stink about it. It was much more wide spread than that.
Ignoring for the moment that current best practice is to specify font sizes in relative units (em, rem) with px fallbacks (what if users need to zoom in?), as far as I’m aware photoshop doesn’t specify pixel sizes for fonts but rather point sizes, which are used for print designs (after all, photoshop isn’t a web design tool) don’t convert directly to pixels. So maybe when the developer opened the PSD and used the ruler tool to measure the size of the font it may have come to 20px so that’s the size he specified in the CSS. Maybe the developer was sloppy and just put in 20px randomly, which seems unlikely. The font size, and probably other sizes and spacings for that matter, should have been communicated better in the first place and not via a PSD. The only way to make a “pixel perfect” website from a PSD would be to export the PSD as an image and put that online instead of a web page.
I don’t think there’s really an alternative to the phrase “pixel perfect” in this case. Like Harry said, it’s an outdated standard for web development, not just an outdated phrase. The problem is the rationale behind the phrase, not the semantics. Modern web development is all about relative sizing and spacing, vertical rhythm and grid systems, not pixels. The best you could do is the phrase “looking as much as possible like the high fidelity mockup”, but if the resulting website bears a large discrepancy in things like spacing and font sizes then it’s most likely because a high fidelity mockup can’t communicate those specifications very clearly.
Did you mean to include CSS in that first line!?
Am I missing this joke? 🙂
The question is, why waste time on a high-fidelity PSD mockup? The idea of making a website or application “pixel perfect” according to a PSD, nothing more than a static picture, that remains pixel perfect across all browsers and devices is insane. Sounds like you could have saved money on the hours wasted on a Photoshop expert (bearing in mind that Photoshop isn’t a web design tool) and spent it on a more expensive developer who could have done the design work in the browser. Your designer could have produced a style guide and maybe a few style tiles which could have easily conveyed to even a junior developer what they need to build. There was a treehouse article about this yesterday.
Not really sure how using Photoshop or Illustrator to mock something up is “insane” but maybe you know something that I don’t. All of the designers at Treehouse code our own front-end and the majority of us still start a design in Photoshop/Illustrator. We strive for “pixel perfection,” which which also means thinking about each responsive break point carefully. Why must we only mock up one static breakpoint? Who set this in stone?
Hold up, there are employers that want pixel perfect work!?
My concern with the pursuit of “pixel perfection” is that it can place an undue emphasis on a misleading unit of evaluation.
In plainer English, it can lead to the definition of “complete” for a design to be “once this appears on the screen exactly as I imagined it.” I prefer to define “complete” as “resulted in the on-site behaviors we anticipated.” In my experience, it is very dangerous to assume the former will always result in the latter.
I have seen far, far too many highly-polished, beautifully-embellished sites that were completely irrelevant to the people they were designed for. I’m all for pride in craftsmanship (really!), but not to the point where “perfection” is equivalent to faithfully reproducing something someone imagined, as opposed to achieving the real-world impact that thing was imagined *for*.
I could not agree more with your statement
“In plainer English, it can lead to the definition of “complete” for a design to be “once this appears on the screen exactly as I imagined it.” I prefer to define “complete” as “resulted in the on-site behaviors we anticipated.” In my experience, it is very dangerous to assume the former will always result in the latter.”
Pixel-perfect may be a dated way to describe it at this point, but I think the sentiment is right. The level of attention to detail in the design should be matched by the attention to detail in front-end. If a design or a PSD is careless or sloppy, I can’t imagine that being the front-end dev’s responsibility. On the other hand, if a PSD is organized, clean, and a lot of thought went into creating design patterns around spacing/margins/padding/type systems, I don’t expect the front-end dev’s decisions or lack of attention to detail to override it. There are few things more frustrating to me as a designer than having to reiterate ‘Please make it like the PSD’ over and over. If I draw a blueprint, that’s the house I want built.
If I’ve made a design choice that creates a complication in the browser, or something is not achievable exactly as I’ve envisioned it, I prefer and expect a conversation around those items for the benefit of both parties. I understand the need for flexibility in the design, and expect to make changes on the fly. Either way, early communication and a walk through of the design goes a long way in this handoff.
You hit the nail on the head at what I was getting at. As you say, if the designer does not give you what you need to write “pixel perfect” code then obviously the problem is on their end. It’s important that there’s sufficient communication between the two.
Hi Spencer, Megan:
I’m familiar with the work both of you have done. I’m also a front end developer who has worked on this side of the scenario several times before. I have some insights from my own experiences.
Like the one of the previous commenters, I only have a PC, while Mac is pretty much universally used. There are certain fonts that don’t translate when PSDs move from one OS to another (Helvetica is the worst offender, there are others). In that situation, a front end dev has to see that happening and figure out what is happening, or deduce what font was meant.
A lot of browser testing has to be done by your dev to ensure that your mockup is correct in all major browsers. Firefox and IE have given me headaches before.
It’s more time consuming to “measure” spacing and layout in the browser than you might realize.
It depends on whether your dev is sending back an HTML prototype or dynamic layouts. If they are pushing, I’m guessing dynamic.
My point here is that there are a lot of potential points of failure, and not every dev knows what edge cases they might need to be testing to get pixel perfection across the board.
That knowledge usually comes from getting bit by browser differences in the past.
Communication is absolutely important. Getting familiar with the other person’s workflow is important. The best way for both parties to test how they work together is to do a small, but necessary project first, and work out the bugs in communication, workflows, and expectations there, before proceeding to a larger project.
Another suggestion that I find helpful when I do my own self-managed projects, is to be very detailed in naming layers. For my own projects, I name the colors, fonts, font-sizes, and font-weights as a way to glance at the layer and read it quickly. This saves me time by not having to click text layers to get information, or pull out the eyedropper, although the ruler tool gets heavy use no matter whose PSD I’m working with.
Let me know if these suggestions sound practical, or what positive experiences you have had working with developers you have contracted.
As a UX Designer that started out as a “web designer” back when that meant you had to be able to code all your own designs (before “full stack” was a special thing), I know exactly what I am asking of developers. I still code all my freelance work, and as such I always design sites and apps to be as painless as possible to develop. I expect any front end developer worth more than $30/hour to be able to open the PSD and actually check the font faces and sizes. I would just send JPGs otherwise. I expect them to cut their own graphics from the PSD I provide (always vector or smart objects for scalability), like I have since the late 90s. I expect them to measure out padding and margins, like I have, since the late 90s, with the marquee tool, the ruler tool, or whatever tool they prefer. I am frequently, in my in-house position, disappointed by $60+/hour developers who do none of these things. I supply a PSD, an editable layered PDF Style Guide, and still I get back horrifically incomplete, incorrect work. It’s not just here either – the contractors hired by a company I did QA for a while back were just as bad. It’s so infuriating and unprofessional. It’s especially infuriating when they try to tell me they “can’t” do something, because they think as a designer I don’t know exactly how to do what I’m asking them to do.
With all the different screen sizes, designs need to grow, breathe and adjust to each size, pretty much throwing ‘pixel perfect’ out the window.
I agree with the others as well. It is almost impossible to get it pixel perfect being browsers render fonts differently as well as platforms. Our designer uses a Mac and I use a PC and when I slice up the psd, you can notice a difference in fonts from the psd file and my browsers. Same with line-heights etc.
I do try to get it as pixel perfect as I can though, however, dealing with responsive design and we use bootstrap also, our designers don’t follow the 12 grid system much so it makes it even more difficult. That is on them though. Overall, I get it pretty darn close those and attention to detail is important.
I agree pixel-perfect is becoming an outdated term since a lot of design is done through code in today’s standards, which doesn’t look identical in all browsers as images did for backgrounds, etc. However attention to detail is still very vital and maybe even more so as padding, margin, locations and sizes of elements need to change on each device with responsive design and making sure it is all cohesive is very important.
However, expecting to be able to pay half of today’s going rate for a developer and still get the same quality is unrealistic. If you pay someone half the rate then you should expect to spend some of your own time doing part of the job (ie when you say you shouldn’t have to comb through their work, this probably wouldn’t have been necessary if you were willing to pay for a more experienced developer). I understand there isn’t always budget for it, but that’s why you’re spending some of your time to be able to get it done for less and still up to your standards.
Ironically, I interviewed for a front-end developer position recently and I was told by the lead developer that having pixel-perfect on my resume was outdated. While it is much more challenging to be able to produce pixel-perfect front-end work with the surge of responsive development and design, I continue to look at it as an important base skill to build upon – i.e. walking before you run. Too many developers these days are jack of all trades and masters of none.