Detect iPad Mini in HTML5?
stackoverflow.com
stackoverflow.com
+-----------------------+
| Are you using an |
| iPad mini? |
| |
| [yes] [ No ] |
| |
+-----------------------+ +--------------------------+
| |
| An error occured! |
| |
| [yes] [ No ] [cancel] |
| |
+--------------------------+In the option screen, just put a little switch to turn iPad Mini formatting on or off.
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.
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.
The need for good standards remains.
Deleted comment
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.
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.
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.
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.
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.
So, not exactly too small, but too narrow.
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.
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.
Edit: Oops, this is a Safari question, not an iOS app question, so this doesn't apply.
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.
iPhone 3GS: 160dpi
iPad Mini: 163dpi
iPad 2: 129dpi
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).
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.
You're saying that buttons on the iPad mini must be physically larger than buttons on the iPhone? For what reason?
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.
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?
9% were on iOS 4
4% on iOS 5
25% on iOS 5.1
http://bgr.com/2012/10/22/ios-6-adoption-rate-60-percent-iph...
Honestly, the main driver of the iOS 6 adoption at this point just seems to be selling new devices that come with it.
- Hardware fingerprinting with the canvas-tag ( http://cseweb.ucsd.edu/~hovav/dist/canvas.pdf )
- Somehow check which assets are preferred downloads:
rel="apple-touch-icon" sizes="144x144"
rel="apple-touch-icon" sizes="114x114"
rel="apple-touch-icon" sizes="72x72"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.
If only you could ask the user if he has big hands or something...
Visual size is much less of a concern as people will simple tend to hold a 7" tablet closer than a 10" tablet.
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.
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.
(I'm asking in the context of someone who strongly appreciates "semantic markup" and "separate content from presentation".)
So, given that hard requirement, you have three options:
- make your hardware have 96 dpi (or a multiple thereof).
- have 1 'px' equal to 1 screen pixel (or point) but 'cm', 'in' etc. not equal to real-world centimetres, inches etc.
- have 'cm', 'in' etc. identical to real-world centimetres, inches etc., but 'px' without a direct relation to a screen pixel (or point).
Apple (and everyone else except perhaps printers) chose the second of those options.
> 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.
• 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.
That kind of thing is the problem with SO, not the ones with 5k views and hundreds of votes.
1. Trivial aka Dozens of answers aka Fastest gun in the west
2. Hard aka Unanswered
3. Interesting aka Closed
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.
iPad Mini: screen.availWidth = 768 screen.availHeight = 1004
iPad 2: screen.availWidth = 748 screen.availHeight = 1024
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).
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.
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.