Hacker News new | comments | show | ask | jobs | submit login
Detect iPad Mini in HTML5? (stackoverflow.com)
158 points by mrtnkl 1890 days ago | hide | past | web | favorite | 114 comments



    +-----------------------+
    |   Are you using an    |
    |      iPad mini?       |
    |                       |
    |  [yes]        [ No ]  |
    |                       |
    +-----------------------+


If you end up using this approach, I'm pretty sure the standard convention in iOS is to have the negative button on the left.


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"


/4


You forgot [cancel]


Wouldn't "No" be considered "Cancel" in that situation?


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.


It was also partially a joke, remembering one WTF moment I had with Windows Vista (don't know if it still happens):

    +--------------------------+
    |                          |
    |     An error occured!    |
    |                          |
    |  [yes]  [ No ]  [cancel] |
    |                          |
    +--------------------------+


Yes, people forget that Cancel is the answer in the case of "I didn't mean to click the thing that triggered this box".


Exactly what I was thinking... almost.

In the option screen, just put a little switch to turn iPad Mini formatting on or off.


You shouldn't need to know if it's an iPad Mini.

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.


The size difference between an iPad and iPad mini is nowhere near 1920x1200 vs 1280x800 on a 15" screen, it's only 20% smaller (44px vs 36px).

http://jsbin.com/inuxah/1


What if they made a device that was 2 inches smaller than that with the same resolution? Surely that would be unimaginable.

The need for good standards remains.


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.


Alternatively make it user adjustable - good for accessibility too.


[deleted]


Duplicate of a comment I made below but:

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.


44px on an iPad has always been larger than on the iPhone. 44px on an iPad mini will be the exact same size as on an iPhone.


Yes. Because sight-impaired people are a mythical creature I only read about in books.


But not large print books because that might suggest that they were real.


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?


This is the paradox of platforms in general: the more you empower smart, nice devs, the more you also empower not-so-smart, not-so-nice devs.


Agreed.

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.


I can appreciate a mobile version when the site has a lot of art assets and I'm on a cellular connection.


OTOH, if someone says "your site is too small to read on a mini", I'm not sure what good answer you have, except to make it bigger for everyone.


There is no "site too small to read" on iOS unless you deliberately mess up zoom values.


Heh. Have you looked at Hacker News on an iPhone? Zoom doesn't do much good when you have to pan and zoom to read each line of text.


I think that falls under "deliberately using crap HTML" ;)


Funny, I was just reading this on an iPhone and it's completely legible (even in portrait mode).


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.


Voting is really hard too. I just don't bother voting anymore on iDevices until there is at least a 40x40 button I can use with my stubby fingers.


The Subtle network, on an iPad2, in portrait. Somehow, they manage to cut off the text of the body column.

So, not exactly too small, but too narrow.


That's a design failure (position:fixed also makes it crap), but it's not related to text/element size anyway.


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.


Already posted it on SO but here goes:

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


I assumed that was a joke.

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.


If you play the sound using the Web Audio API, you're not restricted by user interaction.


This specifically arrived for MobileSafari only in IOS6, right? Do you have an example of a page demonstrating a sound without interaction for testing?


If they are running a version of iOS older than 6.0, they are definitely not using an iPad Mini, so you have answered the question in that case.


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.


Really? I swear there are video games that start playing music when launched, but maybe they are just clever about it.

Edit: Oops, this is a Safari question, not an iOS app question, so this doesn't apply.


+1 on creativity :)


Alternative: play a low frequency sound and detect the stereo speakers using the built-in magnetometer / compass sensor.


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.


    iPhone 3GS: 160dpi
    iPad Mini: 163dpi
    iPad 2: 129dpi
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.


You're missing the point entirely.

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 will be less than 40 points wide, but the physical size of that button is still big enough. It is the exact same size as buttons on the iPhone.

You're saying that buttons on the iPad mini must be physically larger than buttons on the iPhone? For what reason?


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?


Device fragmentation is a massive problem for Apple developers.


I'm going to take that as sarcasm...


It's actually becoming more of a problem. The longer screen of the new iphone for example.


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.

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...


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?


Perhaps the following solutions are possible:

- 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"


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.


Yes, please do.

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.


The recommended minimum target size for iPad (44px) is fine on an iPad mini. You don't need to change it unless it's already too small on the iPad.


There are edge ceases where the screen size really matters. Like displaying a ruler to scale in a geometry webapp.


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...


This is rather dogmatic. You could also say the whole point of a 10" Retina screen is to use smaller text sizes... and the mini defeats that.


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.


How can it possibly be large enough for a UX designed for an iPad, having elements sized minimally for a human?


Or just design your touch targets to be acceptable on both.

Visual size is much less of a concern as people will simple tend to hold a 7" tablet closer than a 10" tablet.


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.


This question is about doing it in HTML5 though, so it's not like the iOS app guidelines are particularly followed.


Touch targets are the same size as on iPhone, so really should not be an issue there.


May I ask why it sucks? Genuine question. I don't get it.

(I'm asking in the context of someone who strongly appreciates "semantic markup" and "separate content from presentation".)


Breaking the "cm" units in CSS is inexcusable.


It's actually required by the CSS spec[1]: 1px is equal to 1/96th of 1in, 1pt is equal to 1/72nd of 1in

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.

[1]http://www.w3.org/TR/css3-values/#absolute-lengths


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).


True, but, also from there:

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 don't understand why CSS would have both actual lengths, and device pixel lengths, and then define them relative to each other. That makes no sense.


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.


And actual hard questions that can't be answered by Googling just sit there with no answers. And then I win the Tumbleweed badge: http://stackoverflow.com/badges/63/tumbleweed

That kind of thing is the problem with SO, not the ones with 5k views and hundreds of votes.


Most questions on SO fit into one of three buckets:

1. Trivial aka Dozens of answers aka Fastest gun in the west

2. Hard aka Unanswered

3. Interesting aka Closed


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.


One user posted a link to this blog post which describes a seemingly quick and easy Javascript detection method: http://konstruktors.com/blog/web-design/4396-detect-ipad-min...

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.


> we may want to scale certain images or buttons

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.


If you have that space available why not just make it part of the touch target in the first place?


You could do that and keep track of touches that are not very close to the target's center instead. But it seems a bit more complicated to implement.


http://konstruktors.com/blog/web-design/4396-detect-ipad-min...

iPad Mini: screen.availWidth = 768 screen.availHeight = 1004

iPad 2: screen.availWidth = 748 screen.availHeight = 1024


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.


Get Raymond Chen to patch iOs.


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.


window.screen.availHeight and window.screen.availWidth look like the best bet.


Is everyone forgetting that you can easily zoom on any iOS device?


Most sites that are device specific disable zooming.


Which drives me crazy. If I want to zoom, let me. I don't care of the designer wants a pixel perfect layout, that's not the web.


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'.


If a dev can ensure that the app works correctly (in terms of size proportions) on the Mini, would it not also ensure it works on the non-Mini?



The iPad 2 is ever so slightly faster: http://www.youtube.com/watch?v=YpV8AoToeHs

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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: