Google should at the very least keep the same aspect ratio when allowing manufacturers to use other resolutions.
They currently allow (split by 10 for better comparison):
320:240 (13.3:10), 480x320 (15:10 ratio), 800x480 (16.6:10), 854x480 (17.7:10/16:9), 960x540 (17.7:10), and then 1280x800 on tablets where 48 of the pixels are for the bottom bar, so it's more like 1280x732 (17.4:10).
I would be easier to do "pixel perfect" design if Google would at least not use all these resolutions that have little to do with each other. It goes to show that Google doesn't put much thought into these kind of design details.
This is the kind of "standardization" I'd like to see Google bring to Android. Would it be that bad to deny a manufacturer the use of a 854x480 resolution over a 800x480 one? or whatever they choose to be the standard? I don't think so, but they don't seem to care much about it.
The 960x540 resolution was probably unnecessary, too, considering we're about to see 1280x720 resolutions coming into market just 6 months later. If a manufacturer decides to make a 1366x768 display later, should they allow them to do it? They shouldn't because the improvement is marginal and developers have to support one more resolution with little benefit, but they probably will allow it.
It goes to show that Google doesn't put much thought into these kind of design details.
Maybe Google thinks, as I do, that designers should be able to make their stuff look good in a variety of resolutions. Desktop/laptop computers have a range of resolutions and aspect ratios, but people have been making UIs look good on them for years.
The problem is that desktop computing is based on mouse interaction, and the precision unit is the pixel. On touch-based devices, it is the human finger. The actual physical dimension of the buttons and other UI elements, including spacing, start to matter a lot more. When you allow for a huge range of resolutions all at different physical dimensions, it's nearly impossible to craft a good UI for all of them. It's going to be a lot of work (too much for most devs) to verify that their flexible layout is going to work from 320x240 to 960x540 and remain usable and readable. Because it's so hard to craft the perfect experience for all, most just don't bother and just settle for good enough. In the end, there are huge benefits to the way Apple is doing things from a UX perspective.
There are two things that make it less of an issue with Desktops/Laptops.
1. There aren't really that many native ratios. Realistically, you're looking at 4:3 for CRT's, 5:4 for non-widescreen LCD's, and 16:9 or 16:10 for widescreen LCD's. So that's not as bad when creating a full-screen application, because you can also letterbox the 16:10 to 16:9 for full 1080p video.
At this point, if I were a developer, I wouldn't even care about 4:3 resolutions, and just have 5:4 and 16:9.
2. Desktops and laptops, in general, have a lot more pixels to deal with, and are usually farther away from the user's face, so there is a bit more leeway when scaling your UI.
There was time, when desktops had 640x480, 800x600 and 1024x768 (heck, the currently most sold 1366x768 is not that different), which is similar to today's smartphones. They had also much bigger diagonal/lower dpi, so there was actually less leeway and every pixel counted.
All of which were 4:3 ratios. 1366x768 is also 16:9.
My point is that it's easier to scale any given UI when you have known pixel ratios. While the actual number of pixels may be different, it's easier to scale a UI from 640x480 to 800x600 than to scale 640x480 to 1600x1024.
OK. There were also 640x400, 640x350 (EGA) and 1280x1024. Under Windows, also "Small fonts" and "Large fonts", which changed size of controls, but not bitmaps.
Each of these options gives you something. Focusing on single resolution (or fixed-number multiples) is short signed, almost like basing your's OS binary API on soon-to-be obsolete and unstable C++ ABI (I'm taking shots at BeOS - they took the easy solution at the beginning and what problems it caused).
Especially when the system has the tools to handle the differences.
Comments
Google should at the very least keep the same aspect ratio when allowing manufacturers to use other resolutions.
They currently allow (split by 10 for better comparison):
320:240 (13.3:10), 480x320 (15:10 ratio), 800x480 (16.6:10), 854x480 (17.7:10/16:9), 960x540 (17.7:10), and then 1280x800 on tablets where 48 of the pixels are for the bottom bar, so it's more like 1280x732 (17.4:10).
I would be easier to do "pixel perfect" design if Google would at least not use all these resolutions that have little to do with each other. It goes to show that Google doesn't put much thought into these kind of design details.
This is the kind of "standardization" I'd like to see Google bring to Android. Would it be that bad to deny a manufacturer the use of a 854x480 resolution over a 800x480 one? or whatever they choose to be the standard? I don't think so, but they don't seem to care much about it.
The 960x540 resolution was probably unnecessary, too, considering we're about to see 1280x720 resolutions coming into market just 6 months later. If a manufacturer decides to make a 1366x768 display later, should they allow them to do it? They shouldn't because the improvement is marginal and developers have to support one more resolution with little benefit, but they probably will allow it.
It goes to show that Google doesn't put much thought into these kind of design details.
Maybe Google thinks, as I do, that designers should be able to make their stuff look good in a variety of resolutions. Desktop/laptop computers have a range of resolutions and aspect ratios, but people have been making UIs look good on them for years.
The problem is that desktop computing is based on mouse interaction, and the precision unit is the pixel. On touch-based devices, it is the human finger. The actual physical dimension of the buttons and other UI elements, including spacing, start to matter a lot more. When you allow for a huge range of resolutions all at different physical dimensions, it's nearly impossible to craft a good UI for all of them. It's going to be a lot of work (too much for most devs) to verify that their flexible layout is going to work from 320x240 to 960x540 and remain usable and readable. Because it's so hard to craft the perfect experience for all, most just don't bother and just settle for good enough. In the end, there are huge benefits to the way Apple is doing things from a UX perspective.
There are two things that make it less of an issue with Desktops/Laptops.
1. There aren't really that many native ratios. Realistically, you're looking at 4:3 for CRT's, 5:4 for non-widescreen LCD's, and 16:9 or 16:10 for widescreen LCD's. So that's not as bad when creating a full-screen application, because you can also letterbox the 16:10 to 16:9 for full 1080p video.
At this point, if I were a developer, I wouldn't even care about 4:3 resolutions, and just have 5:4 and 16:9.
2. Desktops and laptops, in general, have a lot more pixels to deal with, and are usually farther away from the user's face, so there is a bit more leeway when scaling your UI.
There was time, when desktops had 640x480, 800x600 and 1024x768 (heck, the currently most sold 1366x768 is not that different), which is similar to today's smartphones. They had also much bigger diagonal/lower dpi, so there was actually less leeway and every pixel counted.
All of which were 4:3 ratios. 1366x768 is also 16:9.
My point is that it's easier to scale any given UI when you have known pixel ratios. While the actual number of pixels may be different, it's easier to scale a UI from 640x480 to 800x600 than to scale 640x480 to 1600x1024.
There was time, when desktops had 640x480, 800x600 and 1024x768
Those are all the same ratio (4:3). You don't have to change the relative position or size of the elements to accommodate them all.
OK. There were also 640x400, 640x350 (EGA) and 1280x1024. Under Windows, also "Small fonts" and "Large fonts", which changed size of controls, but not bitmaps.
Each of these options gives you something. Focusing on single resolution (or fixed-number multiples) is short signed, almost like basing your's OS binary API on soon-to-be obsolete and unstable C++ ABI (I'm taking shots at BeOS - they took the easy solution at the beginning and what problems it caused).
Especially when the system has the tools to handle the differences.
>Under Windows, also "Small fonts" and "Large fonts", which changed size of controls, but not bitmaps.
It's worth pointing out that the large font option basically breaks Windows applications, including MS Office.
Also, computer apps don't usually run full-screen.