Wouldn’t specifying sizing in viewport units (http://generatedcontent.org/post/21279324555/viewportunits) solve at least some of this problem? Your not trying to pinpoint some, possibly unreachable with the mini, target.
It’s kind of disappointing that Apple is pushing super-high-density displays while at the same time ignoring any kind of true resolution independence. All their solutions involve simply doubling/halfing pixels/dimensions.
Android has device-independent-pixels (dp), and Webkit has device-pixel-ratio (as pointed out above by dazweeja) to allow designers to create layouts that should be approximately the same physical size regardless of a display’s actual physical size or density. Android apps can easily reference a device’s dimensions in dp, and a smart web layout can easily compute an equivalent to dp using device-[width|height]/device-pixel-density. In this regard, the Web (well, at least Webkit) is actually far ahead of OSX and iOS in resolution independence.
The issue isn’t whether the iPad Mini should lie about its dimensions, it’s that it should have a proper density attribute.
Copy & paste the code below to embed this comment.
Luke Wroblewski
While I appreciate all the suggestions on what would be the right way to describe screen variance to developers (physical dimensions, different units, etc)… I think the core issue is still a set of common defaults. Even if we were dealing with different descriptions of screens, wouldn’t the need for a sensible default remain?
For me, this isn’t just a developer connivence issue. It is a user experience issue.
Based on the “data”:http://www.lukew.com/ff/entry.asp?1549 I’ve seen, as tablets get smaller people’s use of the Web drops.
10 inch tablets (like Samsung’s Galaxy Tab) average 125 page views in the browser per tablet.
9 inch tablets (like Apple’s iPad) average 116 page views in the browser per tablet.
7 inch tablets (like Amazon’s Kindle Fire) average 90 page views in the browser per tablet.
5 inch tablets (like Samsung’s Galaxy Note) average 79 page views in the browser per tablet.
Why is that? Usability testing of Amazon’s 7 inch Kindle Fire seems to reveal some answers.
The most striking observation from testing the Fire is that everything is much too small on the screen, leading to frequent tap errors and accidental activation.
For 7-inch tablets to succeed, service and content providers must design specifically for these devices. Repurposed designs from print, mobile phones, 10-inch tablets, or desktop PCs will fail, because they offer a terrible user experience.
Because of this I consider it my obligation as a designer for the Web to provide the bet possible experience for people. One that is adapted for each screen as much as possible. This is not an issue of me (as a designer) trying to “control” the experience and take it away from users.
Quite the opposite, I want to craft something that has a good enough default experience so that the burden of making things readable/tappable is not on the user. As this “data”:http://www.lukew.com/ff/entry.asp?1549 shows a bad rendering can cripple engagement.
This is why I still maintain the iPad Mini has a vexing viewport. A sensible default (like those discussed in the article) could address these kinds of issues. But instead of erring on that side of the consideration set, Apple seems to have focused on not “fragmenting” the work developers have already done to build/design things for the full-sized iPads. Hence the situation we’re in now.
The intent of this article isn’t to illustrate a “new” problem. It’s suggest that today (given standards already implemented in browsers) we would really benefit from sensible, consistent defaults. Please device & browser manufacturers -help us out.
Secondarily, we as makers of the Web need to do our part. To prove to browser maker/device manufacturers that when they set sensible & consistent defaults, we’ll do our best to create a great experience that takes advantage of the information they have lovingly given us. This in turn will create more use, enjoyment, and utility from the Web our their devices.
Luke, just want to make sure I follow the principle you are trying to state/uphold, especially with the size stats in this last post: If we’d all be allowed to build great small-tablet experiences, at the right scale and everything, then use would become more equal among all devices, right?
Copy & paste the code below to embed this comment.
Luke Wroblewski
@shoobe01
At the very least, experiences wouldn’t be automatically crippled because no adaptation/optimization can occur.
At the very best, engagement would go up substantially. I have many data points that show just optimizing layout for smartphones drives core metrics (like conversion/use) 2x-3x higher. So if that model/example carriers over to other form factors… yes.
I would love to see some articles written by the people that make device browsers talking about the other side of this issue. We often treat browsers like they’re handed down to us from a deity, but the design decision behind the iPad Mini’s viewport width was made by a person, and that person probably has some interesting insights into making a non-desktop browser that works with the modern Web.
I know these people are often locked behind some monolithic corporations, but I can’t think of a better publication than A List Apart to seek them out and add them to this conversation.
Copy & paste the code below to embed this comment.
Luke Wroblewski
@Ryan Cannon
Here’s “my conversation”:http://storify.com/lukew/viewport-on-the-ipad with Matt Brubeck at Mozilla mobile who implemented meta viewport support in mobile Firefox
Copy & paste the code below to embed this comment.
Richard Fink
The rise of Zoom as the universal means of sizing and resizing the content within the viewport had an inescapable side effect (but please please correct me, anybody, if you’ve found an escape hatch I’ve overlooked):
Abandoning Text Size for Zoom placed the responsibility for providing the user with a means for enlarging or reducing the size of TEXTTHATWRAPS within the viewport, squarely onto the shoulders of developers. It’s too bad screen real estate has to be allocated to this, but there is no choice. So I agree very much with jPogue’s comment about this. (http://www.alistapart.com/comments/vexing-viewports/P0/#5) But I would go a step further and say that Text Size controls used along with font-sizes specified using em or percent, are not merely relevant again, they are essential.
Android Chrome and Mobile Webkit (as featured in Android 4.x) does support SVG, yes, but not Mobile Webkit as features in Android 2.x. Half of all Android users are still on Gingerbread, and almost a quarter of Android users are still on Froyo! ( “source”:http://www.androidtapp.com/android-fragmentation-less-than-3-on-googles-latest-most-devices-on-two-year-old-software-not-the-case-with-apple-products/ )
Could this not be solved by having physical device viewport widths for each device as opposed to one based of the number of pixels?
If you know the “physical” size of the view port, there’s no margin for error? There may be some issues if people are using larger monitors but not at full resolution, however that would just be some fairly simple math on the device makers behalf to basically say “This browser window is X cm wide.”
We need to move away from this old-world notion of pixel-based designs. What we really need to base our designs on are the physical dimensions of the screen (fully available to us through media queries).
‘Number of pixels’ are a nice to have to make sure our images are as crisp as possible and it would be beneficial if the browser would return the truthful amount rather than impersonating an older version of itself.
Copy & paste the code below to embed this comment.
efc
I agree with one premise of this article (web designers and device designers each have to hold up their end of the bargain) but not the other (Apple failed to do this). You see, I think the bargain is a complex one. Web designers do their best to predict what will work best for the user and design to that standard, but device designers are doing the same thing. They won’t always agree, that is the point of the agreement, we can agree to disagree and trust one another in our different world views.
In this case I believe Apple carefully considered the matter and decided that the market for the mini would be people who wanted to trade size and weight for slightly smaller rendering. This choice positions the mini for a younger (less eye-challenged) crowd. Apple made this choice evident not simply with its viewport setting, but with the whole interface of the mini, which renders all of iOS a wee bit smaller than the regular iPad.
Apple’s choice gives people in the market, you and I as we survey devices to buy, a real choice to make. Do we want everything a bit bigger, or do we want a smaller/lighter device. We make that bargain when we buy the device.
As web designers we should not be second guessing that bargain. Our end of the bargain is to render for a 768 viewport. That’s what the user, implicitly, expects because that is how the device is designed. As a mini owner, I would be very upset if a web page rendered in any way differently on the mini than it did on the iPad. After all, I would have bought the mini based on the bargain Apple offered: same iPad, just smaller. Who am I as a web designer to decide that my personal preference for “bigger” is the “right” choice.
We should keep our end of the bargain, design for the viewport we are given. Leave it to the hardware manufacturers to set the viewport they intend for their product and the market of buyers to vote with their purchases on whether that configuration makes sense. So far, Apple seems to have no problem selling the mini’s value proposition.
Copy & paste the code below to embed this comment.
efc
One more thought on this issue. Some have advocated bringing back font size controls and the like. Actually, what would be much simpler for browser makers would be for them to offer users the ability to modify the viewport. In other words, create an “accessibility” type setting that lets the user zoom the viewport by a few set multiples. If my eyesight is very poor, I might choose a 2x “view” and then the browser on the mini would report 384 for the viewport. Or I might choose a less aggressive 1.25x view just because my fingers are a bit too fat for the tiny buttons and then my viewport would be reported as 614.
It would also be (relatively) easy for browser designers to implement, since other forms of zooming are already common in their frameworks.
This would provide a three-way bargain: web designers design for viewports, manufacturers set reasonable standards for their device’s intended market, users get to override manufacturers if they so desire.
By the way, I don’t think this setting would be used very often. I think it could be relegated to the purgatory of the iOS Settings app, for example, as part of Safari or Accessibility options. It would not have to be as immediately available as the old font size widgets.
Copy & paste the code below to embed this comment.
Luke Wroblewski
Everyone, Yes it would be great to have better information about screens. However device-width (for viewports) is a mechanism in place today on many of the most popular browsers (esp. mobile) out there. So we can use it now to adapt/optimize designs. Which is is why we’re bringing up the issue of consistency & sensible defaults in its implementation in different devices/browsers.
You don’t have to use device-width in your sites/designs. There’s LOTS of ways already out there to get screen info. It is not the only measure of how many pixels a screen has. If you want to get scared, check out “James Pearce’s in depth-analysis”:http://tripleodeon.com/2011/12/first-understand-your-screen/
If you use “device-width” for your layouts, you are saying “browser use the size that is best for this device” that does not mean a literal translation of physical pixel size. In fact, viewport is variable by design. Having a different “device-width” from the number of physical pixels is not “lying” it is setting a sensible rendering baseline based on the size/form factor of the device.
As we outline in the article this can be done with different default zoom levels as well (i.e. 1em = 20px vs. 16px)
Thanks for writing this, it is perplexing. I’m having a hard time justifying these high-def mini devices because all they do is make our sites look like garbage. As a photographer I struggle with uploading higher resolution photos to my site verses keeping them small for browser speed. I can see how having higher resolution viewing screens would be beneficial for other tasks (like editing photos) but is anyone really doing anything on these devices other than searching the net?
The way to solve this problem with iPad Mini is to declare them as retina devices. They could have done the same as with Ipad Retina: declare 2048 pixel device a 1024 resolution. IPad Mini could have been declared also a half resolution device to browsers. Instead of their 1024×768 they could have use the half resolution of 512×384, and everything would have been the normal size.
The device width is—and should remain—the physical amount of device pixels. The issue here is how the devicePixelRatio is calculated. As Scott mention, the W3C has suggested a baseline target to aim for. Just use the correct devicePixelRatio
physicalPixels * idealPixels = devicePixelRatio
40 Reader Comments
Back to the Articlemarcelshields
Wouldn’t specifying sizing in viewport units (http://generatedcontent.org/post/21279324555/viewportunits) solve at least some of this problem? Your not trying to pinpoint some, possibly unreachable with the mini, target.
just6979
It’s kind of disappointing that Apple is pushing super-high-density displays while at the same time ignoring any kind of true resolution independence. All their solutions involve simply doubling/halfing pixels/dimensions.
Android has device-independent-pixels (dp), and Webkit has device-pixel-ratio (as pointed out above by dazweeja) to allow designers to create layouts that should be approximately the same physical size regardless of a display’s actual physical size or density. Android apps can easily reference a device’s dimensions in dp, and a smart web layout can easily compute an equivalent to dp using device-[width|height]/device-pixel-density. In this regard, the Web (well, at least Webkit) is actually far ahead of OSX and iOS in resolution independence.
The issue isn’t whether the iPad Mini should lie about its dimensions, it’s that it should have a proper density attribute.
Luke Wroblewski
While I appreciate all the suggestions on what would be the right way to describe screen variance to developers (physical dimensions, different units, etc)… I think the core issue is still a set of common defaults. Even if we were dealing with different descriptions of screens, wouldn’t the need for a sensible default remain?
For me, this isn’t just a developer connivence issue. It is a user experience issue.
Based on the “data”:http://www.lukew.com/ff/entry.asp?1549 I’ve seen, as tablets get smaller people’s use of the Web drops.
Why is that? Usability testing of Amazon’s 7 inch Kindle Fire seems to reveal some answers.
Because of this I consider it my obligation as a designer for the Web to provide the bet possible experience for people. One that is adapted for each screen as much as possible. This is not an issue of me (as a designer) trying to “control” the experience and take it away from users.
Quite the opposite, I want to craft something that has a good enough default experience so that the burden of making things readable/tappable is not on the user. As this “data”:http://www.lukew.com/ff/entry.asp?1549 shows a bad rendering can cripple engagement.
This is why I still maintain the iPad Mini has a vexing viewport. A sensible default (like those discussed in the article) could address these kinds of issues. But instead of erring on that side of the consideration set, Apple seems to have focused on not “fragmenting” the work developers have already done to build/design things for the full-sized iPads. Hence the situation we’re in now.
The intent of this article isn’t to illustrate a “new” problem. It’s suggest that today (given standards already implemented in browsers) we would really benefit from sensible, consistent defaults. Please device & browser manufacturers -help us out.
Secondarily, we as makers of the Web need to do our part. To prove to browser maker/device manufacturers that when they set sensible & consistent defaults, we’ll do our best to create a great experience that takes advantage of the information they have lovingly given us. This in turn will create more use, enjoyment, and utility from the Web our their devices.
shoobe01
Luke, just want to make sure I follow the principle you are trying to state/uphold, especially with the size stats in this last post: If we’d all be allowed to build great small-tablet experiences, at the right scale and everything, then use would become more equal among all devices, right?
Luke Wroblewski
@shoobe01
At the very least, experiences wouldn’t be automatically crippled because no adaptation/optimization can occur.
At the very best, engagement would go up substantially. I have many data points that show just optimizing layout for smartphones drives core metrics (like conversion/use) 2x-3x higher. So if that model/example carriers over to other form factors… yes.
Ryan Cannon
I would love to see some articles written by the people that make device browsers talking about the other side of this issue. We often treat browsers like they’re handed down to us from a deity, but the design decision behind the iPad Mini’s viewport width was made by a person, and that person probably has some interesting insights into making a non-desktop browser that works with the modern Web.
I know these people are often locked behind some monolithic corporations, but I can’t think of a better publication than A List Apart to seek them out and add them to this conversation.
Luke Wroblewski
@Ryan Cannon
Here’s “my conversation”:http://storify.com/lukew/viewport-on-the-ipad with Matt Brubeck at Mozilla mobile who implemented meta viewport support in mobile Firefox
Richard Fink
The rise of Zoom as the universal means of sizing and resizing the content within the viewport had an inescapable side effect (but please please correct me, anybody, if you’ve found an escape hatch I’ve overlooked):
Abandoning Text Size for Zoom placed the responsibility for providing the user with a means for enlarging or reducing the size of TEXT THAT WRAPS within the viewport, squarely onto the shoulders of developers. It’s too bad screen real estate has to be allocated to this, but there is no choice. So I agree very much with jPogue’s comment about this. (http://www.alistapart.com/comments/vexing-viewports/P0/#5) But I would go a step further and say that Text Size controls used along with font-sizes specified using em or percent, are not merely relevant again, they are essential.
Miff
Android Chrome and Mobile Webkit (as featured in Android 4.x) does support SVG, yes, but not Mobile Webkit as features in Android 2.x. Half of all Android users are still on Gingerbread, and almost a quarter of Android users are still on Froyo! ( “source”:http://www.androidtapp.com/android-fragmentation-less-than-3-on-googles-latest-most-devices-on-two-year-old-software-not-the-case-with-apple-products/ )
wehavethemegapixels
Could this not be solved by having physical device viewport widths for each device as opposed to one based of the number of pixels?
If you know the “physical” size of the view port, there’s no margin for error? There may be some issues if people are using larger monitors but not at full resolution, however that would just be some fairly simple math on the device makers behalf to basically say “This browser window is X cm wide.”
aepicos
We need to move away from this old-world notion of pixel-based designs. What we really need to base our designs on are the physical dimensions of the screen (fully available to us through media queries).
‘Number of pixels’ are a nice to have to make sure our images are as crisp as possible and it would be beneficial if the browser would return the truthful amount rather than impersonating an older version of itself.
efc
I agree with one premise of this article (web designers and device designers each have to hold up their end of the bargain) but not the other (Apple failed to do this). You see, I think the bargain is a complex one. Web designers do their best to predict what will work best for the user and design to that standard, but device designers are doing the same thing. They won’t always agree, that is the point of the agreement, we can agree to disagree and trust one another in our different world views.
In this case I believe Apple carefully considered the matter and decided that the market for the mini would be people who wanted to trade size and weight for slightly smaller rendering. This choice positions the mini for a younger (less eye-challenged) crowd. Apple made this choice evident not simply with its viewport setting, but with the whole interface of the mini, which renders all of iOS a wee bit smaller than the regular iPad.
Apple’s choice gives people in the market, you and I as we survey devices to buy, a real choice to make. Do we want everything a bit bigger, or do we want a smaller/lighter device. We make that bargain when we buy the device.
As web designers we should not be second guessing that bargain. Our end of the bargain is to render for a 768 viewport. That’s what the user, implicitly, expects because that is how the device is designed. As a mini owner, I would be very upset if a web page rendered in any way differently on the mini than it did on the iPad. After all, I would have bought the mini based on the bargain Apple offered: same iPad, just smaller. Who am I as a web designer to decide that my personal preference for “bigger” is the “right” choice.
We should keep our end of the bargain, design for the viewport we are given. Leave it to the hardware manufacturers to set the viewport they intend for their product and the market of buyers to vote with their purchases on whether that configuration makes sense. So far, Apple seems to have no problem selling the mini’s value proposition.
efc
One more thought on this issue. Some have advocated bringing back font size controls and the like. Actually, what would be much simpler for browser makers would be for them to offer users the ability to modify the viewport. In other words, create an “accessibility” type setting that lets the user zoom the viewport by a few set multiples. If my eyesight is very poor, I might choose a 2x “view” and then the browser on the mini would report 384 for the viewport. Or I might choose a less aggressive 1.25x view just because my fingers are a bit too fat for the tiny buttons and then my viewport would be reported as 614.
This would have an advantage over font size choice of being (A) universal across websites and (B) giving the website designers the cues they need to fix up the whole design, not just the fonts, while © adding no extra work for the web designer who is already dealing well with viewports.
It would also be (relatively) easy for browser designers to implement, since other forms of zooming are already common in their frameworks.
This would provide a three-way bargain: web designers design for viewports, manufacturers set reasonable standards for their device’s intended market, users get to override manufacturers if they so desire.
By the way, I don’t think this setting would be used very often. I think it could be relegated to the purgatory of the iOS Settings app, for example, as part of Safari or Accessibility options. It would not have to be as immediately available as the old font size widgets.
Luke Wroblewski
Everyone, Yes it would be great to have better information about screens. However device-width (for viewports) is a mechanism in place today on many of the most popular browsers (esp. mobile) out there. So we can use it now to adapt/optimize designs. Which is is why we’re bringing up the issue of consistency & sensible defaults in its implementation in different devices/browsers.
You don’t have to use device-width in your sites/designs. There’s LOTS of ways already out there to get screen info. It is not the only measure of how many pixels a screen has. If you want to get scared, check out “James Pearce’s in depth-analysis”:http://tripleodeon.com/2011/12/first-understand-your-screen/
If you use “device-width” for your layouts, you are saying “browser use the size that is best for this device” that does not mean a literal translation of physical pixel size. In fact, viewport is variable by design. Having a different “device-width” from the number of physical pixels is not “lying” it is setting a sensible rendering baseline based on the size/form factor of the device.
As we outline in the article this can be done with different default zoom levels as well (i.e. 1em = 20px vs. 16px)
ContinuumPhotography
Thanks for writing this, it is perplexing. I’m having a hard time justifying these high-def mini devices because all they do is make our sites look like garbage. As a photographer I struggle with uploading higher resolution photos to my site verses keeping them small for browser speed. I can see how having higher resolution viewing screens would be beneficial for other tasks (like editing photos) but is anyone really doing anything on these devices other than searching the net?
milosp
The way to solve this problem with iPad Mini is to declare them as retina devices. They could have done the same as with Ipad Retina: declare 2048 pixel device a 1024 resolution. IPad Mini could have been declared also a half resolution device to browsers. Instead of their 1024×768 they could have use the half resolution of 512×384, and everything would have been the normal size.
David Knowles
The device width is—and should remain—the physical amount of device pixels. The issue here is how the devicePixelRatio is calculated. As Scott mention, the W3C has suggested a baseline target to aim for. Just use the correct devicePixelRatio
physicalPixels * idealPixels = devicePixelRatio
David Knowles
Oops I meant; physicalPixels / idealPixels = devicePixelRatio ^^
ashandrien 1
The end of this article kind of reads like an Anonymous manifesto…hmmm
katex
More like the shady manifesto.. double hmmm