At the beginning of September, Apple announced the iPad Pro, it’s latest iteration of the massively successful line of tablets. The iPad pro shares a lot of similar features to it’s predecessors, offer a powerful, yet portable touch device. However, where it differs from the iPad Air is it’s whopping 12.9″ retina display. This is just 0.4″ short of the 13″ retina Macbook Pro display size (which is 13.3″ diagonally across the screen), so we’re essentially dealing with something in size that has previously been reserved for laptops and notebooks.
How will this affect web development?
In order to explain how this is a game-changer, I first need to explain (roughly) how responsive development is currently carried out. Before the advent of smart phones and tablets, a site was designed and built for a fix width, somewhere in the region of 800 to 940 pixels in width, give or take. This would fit into most users viewports on their desktop web browser and you didn’t have to do much in the way of how the user interacted with your site; a mouse click was sufficient to get around, and this functionality is obviously already built into an operating system and any browsers it makes use of. As a developer you were really placing objects around a screen, in a particular flow, whilst possibly adding some fancy effects or animations.
However, this all really changed with the introduction of smart phones and tablets. There were two issues, the first being the screen size was now considerably smaller and the second being the mouse had been replaced with the finger, which could be considered a lot less accurate than the deliberate movement and click of a mouse cursor. When Apple first introduced the iPhone, their solution was to display a scaled version of the site, with a zoom capability that allowed you to make areas of the site bigger/smaller and then tap on those zoomed items to interact with them. It worked, it was relatively intuitive, but it still didn’t feel like a complete solution.
Prior to the iPhone, in 2004 Cameron Adams first demonstrated the idea of an adaptive/fluid layout that changed depending on device width, but it wasn’t until 2009 that the technology required to make it standard (CSS3 media queries) was made available for developer consumption. It’s unclear who is really responsible for responsive design taking off (you could say it was really the development communities passion for it), but in terms of it becoming a necessity, none other than Google can take the crown for moving it from a recommendation to a necessity (Google now include having a mobile site as a parameter for ranking your website).
For a brilliant series of animations on responsive design, check this out.
So media queries have resolved the first issue, where width (or height!) of a device can be used as a marker to decide how to serve content to the user. Media queries at this point also allowed us to change the way elements on a site were used. For example, a button on a desktop site would only need to be big enough to be visible, and for a mouse cursor to click it. However, on a mobile or tablet, your finger as a clicker is considerably bigger than a mouse cursor, and as such you need to make a button bigger to cover for people with…ahem…bigger fingers.
Changing the way we develop websites
Now, onto the key point. Using the example above, you generally knew that a tablet would be no bigger than 1024 pixels in width (although normally 768 pixels, as most people hold their tablets in portrait mode). So using this logic, you could use screen width as a marker for whether the user was on a touch device or a “click” device. I absolutely accept that this wasn’t ideal, and as the line blurred between desktop/laptop and tablet, it didn’t always apply, but most of the time it worked.
With the introduction of the iPad Pro, the lines are no longer blurred, they overlap. The way around this is to use a library such as Modernizr, (something i’ve now been using for a few years to cover the blurred-line scenarios) which allows you to check for browser features, which in this case would mean checking to see if the browser supported touch events. In this scenario it would mean serving a slightly larger button to an iPad pro, than you would a retina Macbook Pro, albeit screen size they’re exactly the same.
Some may not see this as important, but User Experience should be at the very forefront of any project, and although covering every device and browser would be a near infinite task, it’s well worth spending the time and money to cover the main players, and it’s safe to assume the iPad Pro will be one of them (Microsoft fans, I know the Surface Pro has a big screen too, but it’s popularity probably puts it in the blurred line category).
If you have any thoughts, please comment below or get in touch with me.
Header image courtesy of Mac Rumors