Most people will just click yes or no to get past this screen. Better to ask "What iPad device are you using?" With options (with pictures?) of "iPad Mini" and "iPad 1/2/3"
People will want a Cancel button because they don't want to be asked a question at that time, but then they'll want to be able to answer (or change the answer) to the question later; e.g. on an options screen.
If your fonts / buttons are too small, then just make them bigger. Easy.
This will then mean it will be even more accessible on the 10" device.
Plus we've never bothered to know the PPI of the screens before, I've got a 15" screen that is 1920x1080 as well as a 50" screen. But I don't see anyone checking for that. Just stick to reasonable sized fonts and buttons and you should be good.
Dilemma: the size of a finger doesn't change just because your screen is higher resolution. A button and interface designed for the mini might look goofy on the larger device; an interface designed for the larger iPad might be entirely unusable on the Mini. And it's reasonable for designers to want to solve that problem.
Furthermore, your example is anecdotal and fairly meaningless. I've got a 15" screen that's 2880x1800, so what of it? I definitely don't run it at native resolution—it's scaled 2x, or 1.5x down. And it Just Works because there are APIs for native applications and in CSS that expose the pixel density so that developers can deal with it gracefully. Why not do the same for other devices which are also supposed to be high resolution—and more importantly—resolution independent?
The truth is, all of these devices have different pixel densities, and we're supposed to be moving in a resolution-independent direction, such that the physical size of the device and the number of pixels on its screen are completely arbitrary and controllable variables. Especially on mobile, interfaces depend on physical size, not on resolution; the size of a the main input mechanism does not depend on screen resolution or device size—it is static. It is a finger. We should be able to control the UI correctly instead of kludging around the problem.
This idea that you shouldn't need to design apps correctly is simply an excuse for the lack of means to do so. It's a poor argument.
They wouldn't, because it would have too high DPI. That's why they went for a multiple with Retina screens. I remember seeing an Android with a 1280x800 display or similar, using "mobile-optimized" sites was a pain.
There seem to be two main things here - touch targets and fonts.
All the reviews have suggested that by and large touch targets on existing apps are fine which suggests that it's not only possible but actually pretty simple to size them such that they're fine for both devices.
Fonts are somewhat different. There have been comments which suggests that some fonts are smaller than you'd want on the mini but the other side of that is that there is no one "right" font size. When I was in my 20s frankly the smaller the better, now I've turned 40 I'm happier with larger.
I agree configurability can be a cop out (and iOS is almost a monument to that view) but there are some things where there are really good reasons why you might make it something the user can work with and this feels like one.
"I agree configurability can be a cop out (and iOS is almost a monument to that view) but there are some things where there are really good reasons why you might make it something the user can work with..."
Totally agree! For example, allowing a user to make a site's font larger is great for accessibility - and just plain nicer for folks with less than perfect eyesight.
"...and this feels like one."
Totally disagree! ;) The issue at hand isn't accessibility, it's fundamental user experience. Since the first iPhone came out, the core of Apple's UI guidelines has been (paraphrasing, of course) "don't make anything smaller than 44px, because that's the smallest area an average-sized finger can reliably tap." Now, they've thrown that out the window. 44px on iPad isn't the same physical size as on iPad Mini, and that's where designers run in to trouble.
Every element on a page - form fields and buttons, line height, images, spacing around and between content, etc etc - all need to be adjusted for the physical difference in size between the iPad and iPad Mini. A gap between two buttons that is "just right" on iPad may very well be too small on iPad Mini, and we, as designers, have no way to make it better. That's the problem.
The and this feels like one was actually intended to suggest that tweaking font size feels like something that should be user controllable.
In terms of the 44px - the original iPhone and iPad had different PPIs, and the current iPhones and iPads also have different PPIs, so the 44px has never mapped to a constant physical size across all devices.
In actual fact the iPad mini has exactly the same PPI as the original iPhone (163) which was presumably what the UI guidelines had in mind which means that 44px should be perfect for it. 44px on the iPad will actually allow more area than the smallest possible area.
This is probably why pretty much every iPad app has been is completely usable on the iPad mini.
Certainly the fact that existing apps are fine undermines any suggestion that everything needs to be adjusted - if anything the evidence is that nothing does. While I'm sure there are some exceptions to that it'll be relatively few and the best approach is probably to scale everything and have a little more space than the minimum on other displays rather than to try and code individually for each one.
I imagine this is an intentional omission based on Apple's own research. Personally, while I'm not in the market for an iPad mini it would irritate me if developers tried to treat it as a separate target for layouts. The whole point is it's supposed to be a (slightly) more compact iPad but behave identically.
Or based on the frustration of iPhone users being punted onto second rate "mobile sites" when the full site in Safari with a bit of zooming is absolutely fine.
Don't give people any more information which they're likely to use to do dumb things?
With this though I'm not hearing any argument that suggests there's a compelling reason to distinguish based on this platform. I'm not saying that there isn't one, just that in a situation like that the chances are there will be a lot more implementations that do something stupid with it than do something good.
I tend to side with empowering devs by default (of course), but I see your point. Readability should be addressed with adjustable fonts on all devices anyway. The only possible case I could see is augmented-reality stuff where the real size matters, maybe such as rendering a ruler to the screen. An edge case, admittedly, but if it were my edge case, I'd be pissed.
I'd certainly never say don't do something because devs can't be trusted with it, though I don't think that's Apple's logic here.
If it's an intentional thing I think they genuinely (possibly mistakenly but genuinely) believe that it's unnecessary rather than that it would be useful but abused.
Your eyes must be better than mine, because I have to hold my phone about 4 inches from my eyes to read it, and even then it's too small to be comfortable for more than a few seconds. And on a non-retina screen, it's just hopeless.
People tend to think that everything that Apple does is part of some kind of masterplan. They're humans too, and this is clearly a feature missing on their development environment.
Play a stereo audio file and compare the accelerometer response when volume is high on the right channel and on the left channel - iPad2 had mono speakers and iPad Mini has stereo speakers built in
While this might work, wouldn't the sound have to be audible to the user in order for this to work? And therefore when you browse to a web-site it is going to let out a bloop on LOUD just to test the device?
Personally if that happened to me I would never visit your web-site again.
iOS audio will only play in response to user generated event (click for example) never when the site loads.
And I am not saying it has to be a random noise or very loud the accelerometer on the iDevices since the iPhone 4 is superb a very low sound will probably be sufficient. The sound can be easily integrated into the natural flow of the site, as many sites already do small beeps or play music etc to provide feedback to the user.
This specifically arrived for MobileSafari only in IOS6, right? Do you have an example of a page demonstrating a sound without interaction for testing?
My interest is in the digression -- playing sound without a user click to initiate -- rather than the Mini-detection. So still interested in a clarification/example of where this is possible.
Wouldn't work. A lot of users use headphones. I like your angle though.
You would be better off asking the use to throw their iPad up in the air (at least 3 metres for accuracy) and measure the time it takes to come to rest. Just remember to use the microphone to listen for a cracking of glass sound so the algorithm is correct.
The iOS guidelines are 40 points for a button on all devices. So a button on an iPad mini is the same physical size as a button on an iPhone. Complaints about fixed finger sizes don't really make sense to me. If buttons on the iPad mini are too small, so are the buttons on every iPhone app made since 2007.
Some sites have device-specific designs, and so they present different designs for the iPad 2 and iPhone. Your comment would be applicable if the iPad Mini were indistinguishable from the iPhone and were served designs meant for the iPhone as they have roughly the same pixel density, but as it stands it is indistinguishable from the iPad 2 and thus it would be served a design not meant for its pixel density.
If you're concerned about the size of touch targets on the iPad mini, they are already the EXACT same size as the touch targets on an iPhone since the two share the same pixel density and recommended touch target size (40px).
Re-read my comment. If someone has an iPad 2 specific design which uses buttons which are 40 points wide on an iPad 2, those buttons will be less than 40 points wide when that design is inevitably served to an iPad Mini user.
If iPad Minis are served iPhone-specific designs, then you're right—it doesn't matter. And perhaps the solution is "you shouldn't be making iPad 2/iPhone-specific designs," but that's not what I'm getting at.
It is the exact same size as buttons on the iPhone if you are rendering the iPad 2 design on the iPhone as well, but in that case the button on the iPhone would be less than 40 points wide and also too small by Apple's guidelines. I am saying that it would be against Apple's guidelines on both the iPhone and the iPad 2.
That's why I mentioned an iPhone-specific design, as well. The iPhone's pixel density isn't a problem because it can be distinguished from the iPad 2. And, as you've shown, if the iPhone-specific design is displayed on the iPad Mini then there is no problem at all. The issue is that there is no way to distinguish between the iPad 2 and the iPad Mini.
These people can presumably adjust their designs so they work on the iPad mini and the new design will still work well on the iPad 2 (just with slightly roomier touch targets and slightly larger fonts).
Can someone give me a real world example of a site than needs to have separate versions for the iPad Mini and the iPad 2 where some genuine benefit accrues (ideally to the user rather than the organisation who run the site)?
I'm genuinely interested in what that site might be and what the problem with a single version which works for both devices is. At the moment all I'm hearing is a lot of vague hypotheticals and frustration but not much in the way of real reasons why it's a problem.
Are they also coding individually for every single Android device? And if so how many designers are they employing and how the hell are they justifying the expense?
Also, the fact that you need to keep devices around just to test older OS versions. iOS has good upgrade stats but a lot of people are not upgrading to iOS 6 yet, and Apple is also marooning some well used devices like the iPad 1.
Just to put some numbers to the upgrade stats you mentioned, Chitika reported 61% of iOS users were on iOS6 in late October about one month after its release.
The main issue is how fast those 5.1 people are moving on. Some of them are on iPad 1, so they will never upgrade. Other people are just indifferent to iOS upgrades, or don't have enough free space, or just plain don't want the upgrade due to the Maps and YouTube changes.
Honestly, the main driver of the iOS 6 adoption at this point just seems to be selling new devices that come with it.
It's a single data point but the reason I haven't updated is the 2.7gb of space required for IOS 6. I wanted an ipad 3 on day 1 and they only had the 16gb in stock. Which has just 12gb of usable.
My impression was that the 2.7GB was required for installation itself (space to save the installer, extract temporary files and install), after installation you get most of that space back.
True, although for a lot of people, that's a problem in itself. In a "post-PC" world where most of the space is taken up by photos and videos, how do you clear out 2.7 GB?
Please don't. The iPad mini is an iPad. It should run everything exactly the same way. Please don't fracture the experience. The whole point of the mini is that the screen size is large enough that it doesn't need to be a compromise.
If someone is playing a game on an iPad, the buttons for controlling the character should not be huge on the screen. They need to be shrunk down and moved off to the corners so the thumbs can easily reach and touch them.
This is an interesting conundrum. How do you accommodate both people who have small fingers and bought the mini precisely because everything is smaller and more convenient on it, thus expecting that everything is scaled down; as well as people who expect the mini to act as a smaller viewport to applications and websites that retain the same physical size?
If only you could ask the user if he has big hands or something...
Font sizes are a user controlled preference, either through zooming or a size setting. I don't see people enforcing font sizes on iPad 2 users, or defaulting to abnormally small fonts for Retina users.
Most of the mobile browsers don't have a size setting, and zooming is problematic since they don't reflow. So you can't practically zoom more than one line's width, or you will be panning constantly.
Honestly, that sucks and is really unacceptable. We are talking about significantly changing the size of buttons/text between these two tablets. You should be able to design for both.
I don't think we are. Every iPad mini review I've seen so far says existing applications work fine and touch targets aren't an issue.
Font size is the only thing I've seen mentioned and there's a large element of that which is user preference (hence the adjustable fonts in iBooks, Kindle, Instapaper etc.).
The answer would seem to be sensible sized touch targets that work on both and adjustable font sizes which are actually beneficial to everyone regardless of what device they're using.
Exactly - Apple have always been completely crystal clear that your touch targets should be a minimum of 40x40pts. Your graphics themselves might be smaller, but the touchable area should be at least 40x40.
Text size, certainly, but touchable targets shouldn't be a problem assuming you're following Apple's guidelines. I appreciate that may not always be the case, but then you only have yourself to blame.
In CSS, px does not have a direct relation to screen pixel. From your reference:
> The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96 inch).
For lower-resolution devices, and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit. For such devices it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel.
I know. it seems to me that there should be 3 ways of referring to distances and sizes; absolute (px: actual hardware dots not scaled), real world (cm/mm/inches/pt) and relative (100%/0.75).
This question is making me really wonder how anything useful ever gets done on StackOverflow: every time I look back at it, there is some new answer with 50+ upvotes that is just as wrong as every other answer. Are people seriously upvoting things because they "sound right"? There also tend to be a bunch of comments from people with rampant speculation as to why various behaviors occur, without having even taken the time to just test whether the things they are talking about actually happen on real devices, or continue to happen if you mess with the device some between tests (such as rotating it).
That says more about HN, or other referring sites, than it does about Stack Overflow. The problem you mention afflicts questions with incoming links much more often.
Obviously stuff that gets linked externally all over the place has different kind of answers and voting than your average SO question. Seems silly to judge the whole site on it.
The average question is probably either one of the following anyway:
• How can I parse a bit of information from a HTML page? [regex] [php]
• Why does the compiler complain here? [c#]
• Regex question [regex]
• How to add two numbers in jQuery? [jquery] [html]
• What does this operator do? [java]
The long tail of not-very-highly voted questions is mostly beginner questions about a particular language or environment. As for me, it gets tiring explaining exactly the same thing in slight variations (adapted to the problem) three times a day.
Yep, a few times I had an actually hard problem and the question got maybe 15 views, no answer and just sat there dying.
However, that's probably the sort of question you won't get answered in any forum or similar. SO does very well for the trivial and semi-complicated questions – the kind where there are enough developers to have encountered the problem already to answer. And it does so in a way that appears quite high in Google's results and often comes straight to the point (i.e. the answer) – they set out to become better than expert-sex-change which hides the answer below a plethora of ads and it's only visible if you come from Google/Bing. I'd say SO's dominance here is for the better.
That's not to say there isn't anything left to improve, though :-). For trivial questions there are usually a hundred duplicates, at least one of which is often the official documentation.
I can't confirm it for myself, but if what the blog post says is true, isn't this an easy method for detection? Though, I can't imagine that all of the people who have deemed it impossible glossed over this.
Start with iPad2 mode. Add some invisible areas around those images and buttons. If the user keeps touching these areas instead of actual UI, switch to iPad Mini mode. This is also good for iPad2 users who have big and/or clumsy fingers.
I think the approach of asking a user if they are using an iPad Mini or an iPad 2 is a good one. Apple values the UX so much that anything which degrades it will be noticed and updated.
I updated the question and gave a bit more reasoning to why it's ridiculous that we aren't able to properly tell the difference between an iPad Mini and an iPad 2.
Short version: It's not just about size. It's about weight and form factor. The iPad mini can and will be used differently, like being held with one hand. Designers/ developers such as myself should be able to provide users with a different default controlscheme for the Mini that could make advantage of this situation (such as using tap to walk instead of a virtual thumbstick - but that's just an arbitrary example).
Is there a difference in the default font size of iPad 2 and iPad Mini? Seeing as the latter has a higher pixel density, it would make sense to me (but you never know).
Anyway, if that is indeed the case, you could use CSS media queries built with ems instead of pixels. I think it makes much more sense than the regular pixel-based approach as our mobile devices get increasingly higher resolutions and pixel densities.
Some way down in the answers is the proposition to simply ask the user. As spartan and elegantly simple it is, I'm not sure the user will always be accurate, what then ?
All comments focus on the 'rendering' issue, what about log/traffic analyses ? The root of the problem is Apple not following standards and pushing 'native apps'.
Would a JS micro-benchmark work e.g. some integer calculation ? Of course performance may change depending on the other apps the user has open but maybe it doesn't.
