Responsive Design Links + Pixel Density vs Pixel Dimensions

This Focus Topic: Responsive Design post centers on some links we found helpful and a test we did to wrap our head around resolutions for desktop screens, iPhones and iPads.

Responsive Design theory links:

• A Better Photoshop Grid for Responsive Design
• Responsive Images: How they Almost Worked and What We Need
• Improve Responsive Designs & Re-Use Images With CSS3′s Background-Size Property
• Inspiration: Fluid & Responsive Design
• Responsive Web Design, Most Complete Guide
• Multi-Device Layout Patterns
• Device-Agnostic Approach To Responsive Web Design
• Deciding what Responsive Breakpoints to use

Testing out resolution — what does it all mean?

Now, before anyone gets up in arms with my examples, please understand that we are designing and developing in a device-agnostic way and are basing our media queries on size mostly (with a consideration for the switch between tablet and desktop, i.e. finger tip input and mouse input).

If I’m wrong about anything I’ve said here, please [politely] let me know in the comments or via another contact method. This stuff is new to me, and it’s actually new to everyone, so we’re all figuring it out.

I was asking questions like:

Can you create higher resolution images on the web so they look better in a retina iPhone or a retina iPad?

The short answer is yes, you can. The long answer gets more complex.

This is something you want to be careful with — using media queries and fancy code to choose which image to display so you aren’t bogging down standard smartphones and desktop screens with HUGE IMAGES.

First off, let’s set down some concepts and numbers:

• There is a difference between dimension — which is measured in pixels — and density which is measured in pixels per inch (ppi).
• You have to combine these two numbers to hit the target output of an image.
• I use Photoshop to work up app / web designs — so if I start with a 2048 x 1536 at 264 ppi Photoshop file I can faithfully use this to create retina iPad apps.
• If I am doing non-retina apps I cut the file in half – both in dimension and ppi to be 1024 x 768 at 132 ppi.
• If I have the same thing going to a webpage I can change the ppi in Photoshop which will refigure my dimensions to be 559 x 419 at 72 ppi
• There is more to know about scaling between sizes, that is for another time though. You can start with this article.
• Some baselines are:

* DPI is dots per inch, and old print term.

You can see a whole bunch more pixel density numbers here ›

iOS Cheat Sheet measurements are here ›

One reason the new devices are a higher density is because you hold them closer to your face, so they need to be cleaner. A billboard resolution when viewed from the same distance as a magazine won’t hold up. Standing as close to your TV as you do to your phone just won’t work for resolutions.

The thing we are actually trying to learn:

Devices with a higher density mash more pixels into an inch. 

So you can’t actually have a PNG file that is 500 px by 500 px at 72 dpi and another one that is 500 px by 500 px at 264 dpi. It just doesn’t work that way. For one thing, you can spool out those images — but when you open them back up in Photoshop you’ll just have several 500 px by 500 px images that are all 72 dpi. I know this because I tried. Maybe it’s the way Photoshop handles it, maybe it’s that PNGs are always 72 dpi, I’m not clear on the reason.

But when you go back to the fact that a higher DENSITY means that more pixels are mashed into a smaller space you want your images to be:

• 72 dpi = 500 px by 500 px
• 132 ppi = 917 px by 917 px
• 264 ppi = 1833 px by 1833 px

How did I figure out the dimensions? Easy, I just changed the ppi setting in Photoshop and let it handle the dimensions.

Then I dropped the three images onto an HTML page, but then instead of letting the images be three different sizes I made them all 500 px by 500 px and this is what you get:

http://www.sawayaconsulting.com/resolutiontest/

On a computer screen you won’t see the difference, on an iPhone you can start to see it. On a new retina iPad you can see it more.

Conclusion

There are so many concepts to understand when building responsive design. How you want to structure you content breaks. How you want them to flow and where the cut off pieces live. What kind of anomalies are you going to encounter in a the normal course of web design – Safari, Firefox, IE – and what added complexity do you get with Safari Mobile and Android.

This article confuses the lines a bit between straight up responsive, device agnostic design and mobile resolutions. This is something that will make more sense in future posts, but this is a good basis to get a few things understood.

This work includes the photo “Pixel-Spatz,” available under a Creative Commons Attribution license, © _Tasmo.

Mobile App Sends Brochures to Prospects at Tradeshows

We’ve all been to trade shows and walked away with a bag full of brochures, business cards and swag. At best you slog through it and find the contact information for the one thing that you found interesting, at worst you dump the entire mess in the landfill and end up on a dozen automated email lists.

What if the thing you are interested in is a drill rig? Something massive, with lots of specs, configurations and information you need to know—and what if you need to share this information with your various counterparts that speak Russian, English, Spanish or French? You will throw your back out schlepping home that much paper!

We worked with our client, Boart Longyear, to come up with an innovative solution that connects the huge drill rig you see at a trade show with a mobile app that all the sales people carry. This app is available for iPad and iPhone (you can get it here). Sales people scan a QR code that’s on the drill rig which automatically pulls up all the information available on the rig, puts the prospect’s contact details into the app and then sends along all of the brochures in PDF format.

Easy for the sales person—they don’t have to go back to the office and enter in contact information or try to remember what was talked about.

Easy for the prospect — they get only the info they need, as soon as they have given their information (not weeks later when someone finally dumps them in a mailing list).

We helped Boart Longyear’s marketing department put together an app aimed at their sales people as well as current and potential customers. The app allows the sales force to have all of the most current brochures with them at all times to view or send to clients.

The app also features a QR Reader that works with Boart Longyear codes to display brochures and related website landing pages. This is a great feature to quickly connect information sent out or viewed at a tradeshow.

To keep everything working smoothly we created a backend management system so they could update, add and delete brochures from the app without needing to push out an update each time. This means that when the company changes something they can be assured that only the most recent and correct information goes out to potential clients.

We want to thank our awesome client for working with us on this project. It’s always a pleasure to work with super fun clients on projects that really hit on the goals for the business.

Get the app in iTunes ›

Scan QR code with your iPhone or Pad.

Providing your UDID

When we design and build mobile apps for clients we often ask for your UDID — this is a unique number assigned to your iPhone or iPad. We put these in Xcode to allow your device to view the in-progress app.

You will need to provide a UDID for every device for every team member that will be part of the review/approval process.

Here is a great tutorial / visual walkthrough on how to get your UDID ›

1. Go into iTunes, select your device.
2. Click Serial Number until this changes to display your UDID.
3. ⌘ + C will copy this — NOTE you won’t be able to select anything on this screen, but it will still copy it.
4. Paste this into an email and send it over to us.

Why Build a Mobile App – Presentation

As we mentioned in our first Why Build a Mobile App blog post, we have put together a presentation. This presentation includes all of the information in the original post, plus numbers around the smartphone market and a lot more information about the development chain.

Take a look:

Quick Poll: How have you accessed information lately?