No user agent detection for the iPad Mini | Hacker News Reader

No user agent detection for the iPad Mini

mobilexweb.com

70 pointsdirkdk64 comments

Often I feel like it would be better if sites couldn't even tell the difference at all between my phone and tablet and a normal browser... Some mobile sites are great, but only a very small minority. Most times I get redirected to a mobile site, I switch to the desktop version and find it's a far better browsing experience and they shouldn't have bothered in the first place...

An example of this is almost any blog with the WPTouch plugin... Most regular Wordpress theme gives you a better reading experience going to the desktop site and double tapping the main column to make it fill the screen!

> Some mobile sites are great, but only a very small minority.

Indeed! Wikipedia is a thorn in my side when browsing with an iPod.

Although the title talks about detecting the iPad Mini, the article makes it clear that the real dilemma is that there is no way to know the physical size of pixels as presented on the screen and size things accordingly. That's especially important on touch devices where you want to size controls to make them finger friendly.

Why not just follow Apple's iOS control sizing guidelines, which are measured in pixels, and are exactly correct for the iPad mini (and slightly oversize for the regular iPad)?

Why not just follow Apple's iOS control sizing guidelines

Because that is completely missing the point and leaving out every device not made by Apple (which is most devices in the market).

Your aim should be to have an overall strategy for how to handle the incredible amount of devices and variations out there. And to be honest, the iPad Mini adds nothing new to this mix.

We already had the form factor, we already had the size, we already has the DPI.

If you are making web-pages, make them work on anything reasonably capable, not just iGadgets. Anything else is a big "fuck you" to Tim Berner Lee.

Do you really want to tell mister world wide web to fuck of? Do you?

Besides, optimizing for iOS-devices seems passé and counter-productive. It's currently the minority-platform and its market-share is diminishing year by year now.

Android on the other hand, with its 75% and increasing market-share, now that sounds like an audience you do want to make sure you reach. If your website works well on a variety of Android-devices, you can be reasonably sure it will work on other platforms as well, iOS included.

That's the point of CSS and media queries - to separate the style from the content. But in case you didn't read the article, you cannot in fact get the ppi value from the current version of Safari that is bundled with the iMac mini.

I think that's a red herring. Sure, the iPad mini has a higher DPI than an iPad 2. iPad 2 is 132ppi and iPad mini is 163ppi. But guess what else is 163ppi? That's right, every non-retina iPhone. So if your touch areas are large enough for an iPhone user to use, then it's large enough for an iPad mini user to use as well.

It sounds like you're arguing for designing iPad mini apps as iPhone apps, which is contrary to one of Apple's major arguments for the device over existing 7" tablets. Apple wants iPad minis to run iPad apps. Their customers probably do as well.

No, I'm advocating for not drawing a distinction between iPhone and iPad when figuring out the size of touch areas on touch-enabled apps, whether the app is optimized for an iPhone-sized display or whether it's a touch-enabled "normal" page.

I don't think you quite understand. As the devices have different physical characteristics, they require designers to know the screen sizes and pixel density.

The iPad 2 has a screen resolution of 1024x768 with a density of 132 pixels per inch. The iPad mini has a resolution of 1024x768 with a density of 163 pixels per inch.

This means that if you design for an iPad2 you are guaranteed to have smaller fonts and elements than on an iPad mini. If you design for an iPad mini, then you are guaranteed to have fonts and elements that are too large. If you design for the middle ground then your design stinks when viewed on both devices.

As for the iPhone argument: people use media queries for a reason - they design differently for the smaller screen sizes of the iPhone than they do for an iPad.

It's essential that on a touch based device that you can work out how big things will be. Perhaps I can put this in a more concrete way: if you have ever tried to upvote a comment on HN via an iPad and accidentally downvoted the person, you will immediately see the issue of tiny fonts/UI elements.

Now make those down and up arrows 20% smaller.

As you can see from one of the links in the submitted article, even Apple's own website is hard to read on a mini. Not exactly inspiring. I'm quite surprised that such a design focused company didn't realise this was going to be an issue!

Two counterpoints:

1) Why are you designing a site specifically for the iPad mini? That seems pointless. Media queries are great and all, but if you want to design specifically for touch then you should just assume a 163ppi, and that will be usable by everyone.

2) iPads typically see "full" or "desktop" websites. And they can scale. If something is too small at the default scale, then zoom in.

The size isn't that different: if your controls are small enough that they work on the 9.7" ipad but not on the 7.9" ipad, they are probably too small.

If your controls are big enough that they look normal on an 7.9" iPad but not on a 9.7" inch iPad, they are probably too large.

Would it be helpful to be able to display certain buttons or other elements at a set physical dimension as opposed to pixel dimensions? For example, always show a button big enough for a finger (e.g., 1.5 cm). I ask because we recently launched a web app (www.lifesizer.com) that allows sites to display images in actual life size and think it could be great for designing mobile web sites, but comes with other implications for design, such as modifying layouts for devices with different screen sizes even if they have the same pixel dimensions.

We are currently focused on ecommerce and product review sites, but would love to hear if people think it would be helpful for a new take on responsive design.

There are some alternate browsers for iOS that allow you to send a desktop user agent. Sleipnir, Atomic, probably others.

I just love it when I click on some deep link into a site, and it redirects me to the HOME PAGE of the mobile site, with no way to get to the page I was actually interested in.

Yeah, or the sites that say "this content is not available on our mobile site" - so show me the desktop version rather than the homepage!

or better yet.. when people submit links on social networks that contain the m.subdomain and you try to click on the link via desktop AND it's impossible to read b/c it's formatted for a mobile device.

people should use mobify

http://xkcd.com/869/

A List Apart had a good article today on this subject: http://www.alistapart.com/articles/your-content-now-mobile/

Or any site running the dreadful onswipe.

I'd much rather use features that are consistent and that I am familiar with on my device (zooming in Mobile Safari) than every Tom, Dick, and Harry deciding how they are going to cripple their site because User Agent =~ /Mobile/.

Then just find a way to kill javascript, and the world will finally be sane again.

Precisely - I still fail to understand this need to constantly add the overheads for supporting multiple mobile platforms / devices.

Pinch to zoom / double tap are amazing features made precisely for this - if the text, image or control is too small I just pinch or double tap; takes a fraction of a second and I still get the whole website experience as it was meant to be.

Until the developer decides he always wants everything pixel-perfect, writes a separate stylesheet for each device/class of device, and locks your zoom.

Fuck you, developer. Let me zoom. It's my device.

Even big sites such as wired.com and Youtube get it wrong, both refusing to serve certain videos for your flash-disabled desktop Safari unless you fake iOS UA.

The solution to this is to design for the iPad mini. If you make the user interface elements large enough to tap on a mini, they will also be large enough to tap on a full sized iPad. This also has the benefit of presenting a single user experience no matter what size iPad the user has, which I think is a plus.

This.

Follow Apple's human interface guidelines and you'll get this for free. Don't treat them as sacred tomes, but it's no accident that the DPI on the iPad Mini is the same as that of the non-retina iPhone/iPod Touch, and they suggest the same minimum tap target size on both platforms.

The only exception to this is if you're making a ruler, and you're not.

I agree with you. But I think the argument against this is that the elements will be slightly larger than they need to be on the full size iPad and you are thus not making the most of the available space.

> Don’t disable zoom ability in the viewport metatag, such as in user-scalable=no.

Please don't ever do this. It really sucks for reading your site on a touch tablet.

but please please please, if you're making a site that is even the least bit elastic, do put in a "<meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0">. if you don't put in a min-scale=1, the iPad renders pages at 1024px wide and then scales them down to 768px, making everything unnecessarily small.

That sounds like a bug in the iPad browser?

It's not really a bug; that's how it's designed. If you don't tell it that you've though about how to zoom for mobile devices, it guesses for you.

Making sure there's at least some legible text in the page if it's not on the last couple lines sounds like a start...

You almost have to. position:fixed on a lot of android devices won't work without it.

There is no user-agent detection between any models on iOS in Safari; it's not an oversight. You've never been able to detect a difference between iPad 1. 2, 3, 4 or 2(mini) or iPhone 3, 3GS, 4 and 5, nor should you. User agent detection is horrible and this isn't news.

Downloads over iTunesD show difference though; since you may want to serve them different payloads. "iTunes-iPad/5.1.1 (4; 16GB; dt:77)" vs. "iTunes-iPad-M/6.0.1 (2; 64GB; dt:75)"

You are missing the point. It's not about UA detection, it's about feature detection.

Please, let's not get started all over again. UA detection is dead. Don't do it. Mobile Safari has a zoom-in feature (double-tap) that works perfectly without any "fixes" by the website developer.

I'd draw a distinction and say that it's probably something determined by a designer who wants to show off their Photoshop skills by having several meticulously designed websites for different devices.

As a developer, I'd leave the zoom as is and avoid this browser stuff like the plague. Too much repeated code.

Rumours of it's death are premature. It's used by over 80% of the Alexa top 100 sites. http://mobiforge.com/designing/blog/server-side-device-detec... Why? Because it can help tailor the user experience, reduce page payload etc.

You can test whether a site is using UA detection here: http://hydra.mobiforge.com

And billions of people smoke. Doesn't mean it's good practice.

Good. User-Agent detection has always been a hack.

How is this good? How is this considered to be a hack? You make this sound like something that can be achieved in a more sophisticated way. How?

It's good because it's not something that should be done.

Ask yourself why you need to detect the user agent.

Why? Because it can help improve the user experience (page payload, image sizes etc). There's a good reason why Google, Facebook, Netflix, eBay, Yahoo, BBC, Amazon etc. do it. It's also part of RFC 1945 (HTTP 1.0) and RFC 2616 (RFC 1.1). Not exactly a hack -- it's designed into the HTTP protocol since 1996.

To allow folks to read legible text. To ensure that elements aren't that small you tap on the wrong thing. To provide a reasonable user experience to your audience.

How exactly would you resolve the problem?

All the comments so far have been with regards to modifying a site's appearance based on the device.

A totally separate use case is for business intelligence reporting. It's not so bad with the iPad 2 vs iPad Mini because they have virtually identical hardware other than the physical screen size (same CPU, memory, CPU, etc). However it's more important with, say, the iPad 3 vs iPad 4. Although both are fairly similar (both are branded as the "new iPad"), they do have different CPUs.

For our business, it is valuable to know which physical devices people are using, not just which OS or browser version they are on. Our product is one which heavily relies on the CPU performance - knowing which devices our customers are on tells us which devices we should prioritise the testing on. Yes, we may be able to optimise the product to work on an iPhone 3G (picked as an example of a lower end iPhone), but if the number of customers who use that device is low enough, then the business case won't stack up. When it comes to device testing, it seems only prudent to try and mimic the device profile of our customer base.

Also there are other, perhaps less tangible, use cases for understanding the device profile for our customer base. For instance, if iPad Minis are more popular for a particular demographic (perhaps rush-hour commuters), this may inform business decisions about development priorities, feature roll-out, or marketing campaigns.

In summary - please don't assume that the only reason for device detection is to change the appearance of a site; the data can be valuable in other ways too.

I don't think anyone is assuming that that's the only reason but just because something is valuable to corporates doesn't mean you have the right to have that information.

After all I'm sure that it would be useful to you if my browser told you my age, sex, salary, where I live and how many kids I have but that doesn't mean it should happen.

Besides in this instance the hardware is remarkably similar to the iPad 2 (which is the thing you can't tell it apart from). It's unlikely there's anything the mini can do that the iPad 2 can't from a performance perspective so you really don't need to distinguish them.

"It's not so bad with the iPad 2 vs iPad Mini because they have virtually identical hardware other than the physical screen size (same CPU, memory, CPU, etc)."

But screen size, and resulting element scaling, IS one of the most important things.

I think this is a case for continuing the current course. By that, I mean that these obvious missing issues of Apple would be fixed in the next revision if a large plurality of websites did not display well. I doubt the websites themselves would be affected in the long term, however. Of course, I base this behavior analysis on a sample of one (my apologies to the staticians out there).

Hmm

I'd argue detecting iPad 2 in landscape mode would be an opportunity for an extra RHS column

While on Mini, you'd just drop that

Shame we can not have that possibility, as the extra 19% of screen makes an extra column readable.

I'd be pretty unhappy if my favourite website was missing a column just because I was on my mini.

You already have that on phone vs desktop.

It's the nature of things, and should not be an issue if the responsive design is done properly

But the iPad and the iPad mini has the same number of pixels. If I browse a site on my mini I expect the same UI as when I use my iPad.

This is true. But there is a strong case for increasing font size on a mini, and letting the content breath more. So dropping a RHS column would help that.

This is if you believe in non-zoomable design. If you allow the user to zoom, one option would be to deliver full desktop design and content, as you prefer.

Give it a math problem to solve and find our how long it takes to solve it. It's a hack, but that is probably the best way to determine what iOS device it is.

It also has the same processor as the iPad 2. And probably the same RAM, so don't go there either.

This really only matters for pages designed to look "native", in which case as long as you don't have a tap area smaller than about 44x44 pixels (like Apple has always recommended) then you shouldn't really have a problem at all.

If it's a normal site then this shouldn't matter one bit because most people will be zooming into your pages anyway, unless you've disabled that (which you really shouldn't.)

After the ipad mini introduction video with Ive waxing on about how they redesigned it from scratch for the smaller form factor, it's irritatingly condescending that they report false results back to media queries to prevent designers from doing the same.

would it be possible to do it by using one of these two approaches after the first general iPad user agent check?

-using a full screen image and getting an useful parameter from that via javascript

-uploading a screenshot of a graphics element via javascript/canvas for a server to evaluate

They'll probably be able to patch this. Most likely it's a simple oversight

No oversight, you've never been able to differentiate between device models in the iOS User-Agent. Nothing to see here.

The article isn't talking about UA detection, but rather feature detection. In particular, working out the devices ppi.

Thank you Apple! Good decision there. If your site needs special tweaks just because the screen is a mere 19% smaller then your design sucks. Just my opinion.

Reply on news.ycombinator.com