Working with the Macbook Pro Retina

Published on September 22, 2012

I recently got the rMBP and one of the challenges I had to figure out was adjusting my work flow to an HiDPI display. Luckily, out of necessity, I’ve managed to devise a simple work around to streamline my design to development process. I’ll be discussing that in this article. Web Design with a retina Macbook Pro

You can download the source files here (GitHub). See the working HTML version here.

Table of Contents

  1. Designing with high resolution displays.

  2. Front-end development: Part I - Asset Management

    1. Preparing.
    2. Installing ImageMagick.
    3. Converting.
  3. Front-end development: Part II - CSS

Designing with high resolution displays

Normally in Photoshop, you’d start with a blank 72ppi document. But this time, you’ll have to change your metrics from pixels to points. This was not an easy habit to break for me since I’ve already set my brain to think in pixels for years.

To get started, let’s create a blank 960 pt x 720 pt document with 144ppi.

960x720pt document

This is going to be our base file which will have the full resolution of how our assets are going to be.

I’ve set my base zoom level to 50% since 100% gives us the full pixel view of the comp which is twice the size of what it’ll look like in the browser.

50% zoom level

You can zoom in if you need to look out for any “gaps” in the pixel.

This is a quick and rather odd icon I made for the sake of this tutorial. We’ll be using one element for now for simplicity.

Icon with grid enabled

Tip: It’s important to enable grid on your comp because it helps us create layouts and align things better. The settings depend entirely on preference, but I’ve set mine to gridline every 20 points with a subdivision of 1.

Note: If you need to preview this outside of Photoshop (since it looks a bit jagged on a 50% zoom level), go to Finder and navigate to your PSD and press spacebar. This will show up a quick look preview of your design and how it would look like in the browser once we set the CSS rules.

Front-end Development: Part I - Asset Management

Export the PSD’s elements to your assets/ directory as PNGs. Later, we’ll use the Terminal to type in some commands that’ll convert and resize the images we just saved which will be used for our HiDPI version while the resized assets for normal displays.

Since scaling an image twice its size will cause it to pixelate, it makes sense to use our high resolution assets as the base then scale it from there.

Preparing assets

When naming high resolution PNG files, you should place _2x right before the filename extension (e.g. logo_2x.png, icon_2x.png, etc.) as recommended by Apple’s guide for best practices in serving image sets..

Quote from Apple’s developer site:

A common file-naming convention for high-resolution images on the web is to prepend _2x before the file extension; for example, myImage_2x.jpg. Don’t use @2x in the filename, since the @ character in a URL is reserved as the delimiter separating the username and password from the host in authentication URL schemes.

However, we’re going to automate our work flow later on so disregard that note for now.

The build/ directory will contain our HTML, CSS and converted images.

Note: If you’re going to use icons in your project, it’s probably best to save them to a sub-directory in your assets/ folder named sprites/. We will combine all these icons together into one spritesheet to save up HTTP requests for site optimization. We’ll discuss that in another article. For now, we’ll keep things as basic as possible for us to easily comprehend the process.

Installing ImageMagick

Quick note: If you’ve been doing front-end development for a while, then there’s a great chance you already have imagemagick installed in your machine. You can skip this section if you want.

ImageMagick is basically a command-line tool for manipulating images. It’s extremely useful for a lot of things like making quick favicons, converting images into PDF, extracting frames from GIFs and a lot more without the use of a bitmap editing software like Photoshop.

If you’re on Mac (or Linux), you can either install this from source (if you’re masochistic enough) or use package managers. I personally use Homebrew or MacPorts to install command-line tools in my machine because they make life easier.

To Install ImageMagick through MacPorts, enter this command in your terminal:

sudo port install ImageMagick

…or through Homebrew

brew install imagemagick

Note: The recent version of Homebrew will not let you use the sudo command. If you are using zsh as your shell client instead of the pre-installed bash in your Mac OS, you might want to check your .zshrc and make sure that your path is targeted to /opt/local/bin:$PATH and not /usr/local/bin:$PATH (that was my problem before).

Converting assets

We’ll now be converting our images from the assets/ folder to build/images/.

While still on the terminal, go to the root directory of your project and enter this command:

find assets/*.png -exec convert {} -set filename:name '%t' 'build/images/%[filename:name]_2x.png'  \;

This basically finds all PNG files in our assets/ folder, rename them through imagemagick, and export them to build/images/ prepending _2x before the file extension.

Next, we will resize the images in half and place them on the same directory we did with our previous command. But this time without the _2x. To do that, enter:

find assets/*.png -exec convert {} -resize 50% -sharpen 0x1 -set filename:name '%t' 'build/images/%[filename:name].png' \;

Aside from resizing the images, it also sharpens them a bit by 1 pixel to remove some hints of blurriness produced from the resize operation. If you go to build/images, you’ll see all of the elements in place.

To make this a lot easier, let’s create a Makefile that’ll automate the scripts we have above:

    # save the high res version.
    find assets/*.png -exec convert {}\
        -set filename:name '%t' 'build/images/%[filename:name]_2x.png'  \;
    # convert the image, sharpen them, and save.
    find assets/*.png -exec \
        convert {} \
        -resize 50% \
        -sharpen 0x1\
        -set filename:name '%t' 'build/images/%[filename:name].png' \;

Now everytime you need to convert your PNG elements, you just type make in your Terminal. That will basically run the commands we did earlier saving us from doing repetitive keystrokes.

You might be thinking how this could have been done by simply saving up two versions manually instead of typing some arcane texts in the command line. But I think the key part of being a productive designer/developer is being able to reduce repetitive tasks as much as possible and focus on getting more important things done.

So to recap, everytime we add a new element in the assets/ folder, we need to navigate to our project directory in the command line and enter make. Pretty simple.

Front-end development: Part II - CSS

We will initially build our low-res version using our resized PNG assets (the one without the 2x suffix) because:

  1. The majority of web users are still on regular displays. So that makes them our priority.
  2. We don’t want to burden our non-HiDPI clients with unnecessary bandwidth since they won’t really see the difference.

Here’s a simple CSS rule for the phone icon styling in my css/site.css

    background: url(images/icon.png) top left;
    width: 133px;
    height: 148px;

To make the retina counterpart, let’s create a new CSS file called css/retina.css

Include a link tag to our HTML file that’ll load our retina.css if the client’s browser meets the pixel ratio requirement.

    media="only screen and (-webkit-min-device-pixel-ratio: 2)"

Let’s create that CSS file and add some rules that swap the non-retina images with the HD version:

.icon {
    background-image: url(images/icon_2x.png);
    background-size: 133px;

Thebackground-size property explicitly tells the browser to constrain the width of the background image (proportionally if the 2nd argument, which is the height, is not provided) so that it doesn’t render its native value which is twice the size of the non-HD version.

So there you go. A basic work around in designing and developing a retina-compliant website while on a retina display. If there are parts that I fail to explain more clearly, do let me know in the comments and I’ll try my best to explain.

Personal Thoughts

Initally, I thought that supporting retina displays will just be another chore that I need to incorporate in my life that really doesn’t add anything to the user-experience. Turns out I was wrong.

Seeing crystal clear graphics on the web made me want to go back to doing 3D graphics again where I’d spend hours making it look beautiful and crisp. I remember 5 years ago, people were totally fine with 360p in YouTube, but now in every non-HD video that I come across with, people would always ask and most often times complain for the lack of a 720p or 1080p version.

This goes without saying that you should first weigh the benefits. Does it contribute to the improvement of the user-experience? Does it make them want to go back to your site? Is the target market a demographic where high speed internet is abundant?

But I’ll tell you this: As someone who’s been designing and developing for the web for roughly 8 years, this brings back my enthusiasm in making highly detailed graphics again. Really exciting times!

Hopefully, in the future LTE becomes common in most places in the world where tech consumption is high like ours. I currently live in the Philippines, and the fastest mobile connection we have here is still a 3MBPS 3G connection and that’s only the case if you live around the country’s business district which is Makati. In other places, it’s practically unbearable.

Anyway, I do hope you enjoyed this article and feel free to comment, ask or give suggestions below!