Recent experiences have brought me to write this article, for the sake of improving developer <–> designer communication.
If you’re a developer – read about basic design principles. Color schemes, golden ratio, typefaces and the likes. If you’re a designer – find a introductory tutorial on html and read it.
If you made it this far, means that you’re interested a bit more. The read is going to be a bit longer than usual so grab a beverage and read on. Hopefully, you’ll get some new insight.
I do some design work (though that’s an overstatement) but I am a developer, so this article will probably sway on the developers side, what I can promise though, is that I’ll do my best to stay impartial.
Just to make things clear – I do not advocate that every (web) developer should be able to do (web) design, nor do I claim that every designer should be able to throw together a web page. What I am trying to say is that both parties should be aware of the other’s workshop – at the very least the basics.
There are a few things that are important to developers, and a few that are important for designers. I’ll try to point them out and describe the interesting bits.
First and foremost – the grid. No, I’m not talking about this, I’m talking about this. For a front-end developer, this is an essential and required thing to have. Yes, there are situation where you don’t want that, but believe me, these are very rare. The key thing behind the grid is that every page is ‘within the same box’. By box I don’t necessarily mean a fixed width limiting shape. There are a bunch of ways in which this would be undesired. What I do mean is that the page has visual structure and has ‘containers’ into which content can be placed.
Having a well defined grid saves development time. There are quite a few css frameworks that have helper classes that speed up creating the page grid significantly. Why? well, because creating a grid is boilerplate code. It’s either the same or very similar in every ‘layout type’ (so fixed width, fluent, responsive…). Repeating this code is just a waste of time.
Now I’ve seen quite a few designs that don’t show the grid. Either because it’s not there (as in not used) or just not shown. The former case I condemn. Well, that’s a strong statement, but as I mentioned there are really just a few cases in which it’s justified not to have one. The latter can mean a few things. Either that the grid is obvious – that’s the easy case – no problems here, or, that someone forgot to put it there. I understand that this may be a bit more work for the designer, but it’s worth it. If I don’t see a grid, I need to measure – I can, but that may turn out to be inaccurate (if the results don’t resemble anything standard(ish)) or, I can make up a grid that’s closest to what I see – that’s usually a bad choice. It creates discrepancies between the implementation and the intended design and it creates friction on the designer-developer front – after all, it can be perceived as stepping on someone's toes or changing their work.
So designers, please – put a grid in the design and developers – don’t try to match one that’s closest – just ask.
If you’re working with designers who came from print – they will most likely use jargon. ‘Fold’, ‘gutter’, ‘kerning’… if you’re a developer – learn what that means. It helps. There are less misunderstandings and the conversation goes smoother. There’s another upside to this – you don’t need to come up with css class names.
Nope, not the final frontier. The margins, paddings but also the sizes. 17px looks weird – at least for me it used to for a while. I mean why not use something ‘decent’ like 15 (roundish) or 16 (power of 2). Well – there’s a simple reason – because it looks better.
A 957px grid with 17px gutter on the left and 13px on the right may look weird to a developer, but if it fits the design – get over it – they’re just numbers. Be cautious though – if one margin is 20px and the other is 21px there’s a possibility that someone’s finger just slipped.
If you’re male – here’s a new thing – there are more than 16, although, some look very similar…and if you’re confused about the names, use this. Jokes aside – this subject is something that has changed over the years. There was a set of web safe colors, there still is, but they’re not that significant any more. OLED screens, retina displays – quality of displays is rising, having a web safe color is not that significant any more. Keep in mind though, that the contrast still needs to be high enough for the user to spot the difference – even on the best mobile display if the user is standing in the open and the sunlight is above his/her head, the difference between amaranth and alizarin crimson may not be enough.
So developers – lay off the hard requirement for web safe colors, I know photoshop has the tool for that, but, it’s just not worth the hassle. Designers – keep in mind that even that you’re designing for web (hopefully you’re doing more than that), chances are that the users will view the page on something different than a computer and in a place that has varying lighting.
That’s a big one. In the previous paragraph I said that web safe colors are not that significant any more, but for the moment – web safe fonts are. There are a few places where you can get a list of them like here or here. If you want to use a custom font, no problem, just don’t use too many. The reason is simple – font files tend to be big and you need 4 of them to cover all the browsers – that means the page load time will be longer and the overall user experience will drop. Also, there is a rule of thumb that a design should not be cluttered with too many font faces so all of that brings us to one conclusion – custom fonts – yes, but not too many.
Which fonts? Well, web fonts – that means a few things, but first let me direct your attention to 2 sites. Google fonts and font squirrel. The first provides less fonts but also provides a simple way to use them directly from google servers so that’s nice. There’s also a brilliant tool there – a gauge that shows the impact on the page load time – use it, keeps the awareness. The latter is a database of free fonts. Most of them can be used on the web. There’s a webfont generator there that helps with converting regular fonts to packages for web use, though it’s better to use a font that has this custom made - the automatically converted versions tend to have decreased quality.
Another thing to keep in mind is fall-back fonts. There’s a nice website called css font stack that helps with finding the right fall-back – use it. If you don’t fin your font, ask the designer what should the fall-back be.
And another important matter - fonts are copyright protected – as a developer and as a designer – make sure that you have a license for the fonts you use or if they’re free, that they’re also free for online use.
That one always brings a smile to my face – in my mind, this is something extremely important to designers and extremely unimportant to developers. There is a css property called letter-spacing. Use it. It’s weird and funky – after all, what the hell is a 1.5px? Aren’t these supposed to be undividable? Well, in theory – no, and in practice – also no. Developers - read about sub-pixel hinting, antialiasing and the likes and get used to the fact that you’ll have weird numbers in the css file (although after that 1.5 will still look weird, though 1.33 not that much). Designers – understand that there’s a very big difference in what photoshop can do with fonts and what a browser can do with fonts … and if we’re at it what a browser is supposed to be able to do with fonts.
Letter spacing is very inconsistent across browsers. A letter-spacing value of 1px looks very different o chrome, firefox and IE… and on mobile versions the difference is even bigger when you consider the fact that page scaling is a frequent case there. So although this may be very important to the design – there’s a technical limitation here, and the best result that can be achieved may sometimes be close enough, but it will never be pixel perfect.
Layer blend modes
What does all of that mean? Well, if you’re working on a design that has an overlay menu and that ‘burn’ mode just looks so well – change it. There are cases however in which this can be technically possible. In fact, I’m almost sure that technically it would be possible to achieve any effect but the trade-off is just too big. If it’s just the development time – fine with me. If the client pays for that, I’d be more than happy to do it. But most cases, it’s a trade-off in performance and that hits the user. That’s something I refuse to do. Remember, performance is a feature, and although often it’s not written or mentioned, poorly performing web sites will discourage users – that has been proven in a vast majority of ux studies.
Indirect design features
What I mean is things like favicons and other icons (apple, windows 8), hover/focus/visited states and other things that are often considered as obvious and thus everyone forgets about them. I’m not really sure who should be responsible for delivering them. As a developer, I know that I’d benefit from having these in the design – less work for me, and more certainty that everything plays nice together, but on the other hand, hover and focus states are often a very obvious or simple thing. Icons – well, if there’s a logo that fit’s in a 16x16 then you’re good to go, but what about the emerging windows 8 tile icons? The variety of sizes gives lots of opportunities here and it would be a shame to waste them, plus - that’s something that requires design touch. Though on the other hand – who knows. One thing I do know – the developer should do as little design decisions as possible – not because it’s not his responsibility. It’s because developers usually don’t have ‘that touch’ for aesthetics. Just keep that in mind.
Possibly, but for me, the mentioned parts are enough to get started. If you have some ideas of your own – share them in the comments. I’m sure I left out a few things.