Category Archives: Web design

Designing for Development: Less perfect content, please!

It’s a new year, which means it’s time for a new blog series! This one is aimed at web designers who collaborate with developers. As a developer (who also designs), I’m going to give you some quick tips about how to make your designs more development-friendly!

The first one is about designing around perfect content. Here’s the kind of thing I mean:

If your client hasn’t given you content yet, it’s tempting to make a grid like the one you see above. What could possibly go wrong?

Well…

I think you get the idea.

When your developer or client starts working with real content, which is always imperfect, cracks often start to show in designs. Sometimes your design will just break, and sometimes developers will start making assumptions about how to handle these cases.

For example, with the grid of posts with one far longer title, one developer could interpret it like this…

…while another developer could interpret it like this:

With the word that’s too long for its container, one developer could interpret it like this…

…another developer could interpret it like this…

… while a not so careful developer might just leave it alone.

Uh oh!

Or, let’s say we have another lovely grid of posts like so:

What happens when there’s fewer lines? Does the title align in the centre, or at the top?

Or… what happens if the title is quadruple the length of your sample title? I won’t illustrate that one; you can use your imagination!

If you’ve designed yourself into a box (literally and figuratively! seewhatididthere?) where a particular piece of content can only be a certain number of lines, you have a recipe for disaster. You can try to tell your client to stick to a certain number of characters, but this is really punishing your client for your design choices. Design should be in service of content, not the other way around. Plus, just try and get them to stick to your character limit. Good luck with that ????

By the way, if you think that this doesn’t apply to you because you’re designing with real content instead of sample content (hooray! you rock!), think again. You don’t know what kind of content your client is going to create in the future!

If you’re working with a design-conscious developer, they can be really helpful in these situations. If you haven’t thought about these cases, a developer who understands how good design looks and feels can probably figure out a best case scenario to handle these situations. But, as you may have experienced, not every developer is also a designer, so leaving these situations in another person’s hands leaves some potential for disappointment, on your part and your client’s.

To make your designs as development-friendly as possible, do a little brainstorming before you start designing about potential variations in the content. Write ‘em down! Then, when you’re designing, decide how you would like to handle these non-perfect cases. That way, your developer will know exactly what to do when they arise (which they will), your client won’t be surprised when the site looks slightly less perfect than your perfect design, and everyone will be a lot happier!

Psst – have a free minute or two? I’m looking for your input! I’m creating a workbook for designers and developers to communicate better with each other and create a process that works best for them. To make it as useful as possible, I’m looking for feedback/rants/etc. from web designers and developers who collaborate with each other. Want to tell me what you really think? Fill out this quick + painless survey. Thanks for your time! ❤️

Alternatively, don’t care to share but want to find out more about it when it’s released?

What DPI do web images need to be? (spoiler alert: it doesn’t matter)

web-images

If you’ve ever had to communicate with someone about creating/resizing images for the web, I’ll bet you’ve heard a lot about “72 DPI”. As in, “images for the web should be 72 DPI while images for print should be at least 300 DPI”. You might even think it’s true.

Friends, I’m here to put the 72 DPI myth to rest.

If you’re sitting here thinking “WTF is DPI?” or “Is DPI the same as PPI?” or “Why, oh why, are there so many acronyms in the world?”, DPI stands for “dots per inch”, and PPI stands for “pixels per inch”. The term DPI is generally used for printed images since printed images are made up of tiny dots, while the term PPI is mostly used for screens, since screens contain pixels. They’re quite similar, and people often use them interchangeably, which is a little confusing, so don’t worry about it for now. Let’s think of them interchangeably for our purposes.

Now, let me show you three images from Placekitten, aka the best site ever. One is at 72 DPI, one is at 300 DPI, and one is at 1000 DPI:

72 DPI

72 DPI

300 DPI

300 DPI

1000 DPI

1000 DPI

Don’t believe me? Download them and open them in Photoshop. Take your time. I’ll be here!

Craziness! How could this be?

All you have to do is look back to what the acronym actually stands for: pixels/dots per inch. This refers to how many pixels/dots are squeezed into one inch of space on a printed page. Two images with the same pixel value (let’s say, 1000 pixels wide) will print at very different sizes depending on the set DPI. That image at 72 DPI will be 13.88 inches wide, while that same image at 300 DPI will be 3.33 inches wide. It’s just basic math. All DPI does is determine how many pixels your printer is going to cram into one inch of space on the page. That’s why a higher DPI image looks better than a lower DPI image – the more pixels you squeeze into a small area, the finer the detail in your printed image.

Remember the three images I showed you above with different DPI values that look exactly the same on the web? Here’s what they’d look like printed:

72 DPI

72 DPI

300 DPI

300 DPI

1000 DPI

1000 DPI

Ahhh, so image DPI does matter… but only if you’re printing it out.

So, how does this relate to the web, again?

Trick question – it doesn’t. Look back up again at the three original kitties – their size doesn’t change at all on your screen, because your screen understands one measurement: pixels. Pixels are all you ever need to think about. To determine how big an image should be on your website, you have to know what size in pixels it needs to fill. Your designer/developer should tell you something like “please make sure that images for this particular section of your website are X pixels wide.” The target size of your image is determined by the size of the container it needs to fill, and that measurement is different from website to website (or even in different parts of the same website), so the person who created your website (or your theme documentation, if you’re using a pre-made theme) will be able to tell you what size you should be aiming for. In pixels. Just pixels.

Hey, what about retina displays?

Glad you asked! Retina displays, also known as “high DPI” displays, are awesome in that they cram more pixels into their screens than standard displays. This means that each individual pixel is even smaller so you get a much sharper image than on a standard screen. So doesn’t image DPI matter now? Doesn’t it?

Nope. All you really need to know is that if you’re optimizing for a retina display that’s squishing double the number of pixels into the same area as a non-retina display would, you need to double the pixels in your image so it still appears crisp. So, a logo that’s 300px across normally should be saved at 600px. Then, when that image is presented at 300px as originally intended, it’ll look nice and crisp on retina screens since the image has double the number of pixels and so does the screen. The DPI/PPI setting in Photoshop is still irrelevant because you’re not printing it out.

If in doubt, remember that on the web, it’s all about the pixels. Unless you’re using a vector format like SVG, in which case, high five. You’re awesome.

Want more articles like this? Get ’em in your inbox!