@Sarah Parmenter
Sucks that you’ve been copping so much heat for this, it’s a helpful article (especially with the title change!)
Perhaps an update to acknowledge the change from mobile to iOS in the title would be helpful. That does completely change the context of the earlier comments.
I completely agree that, considering the mobile browsing context, sometimes the best solution is to create a separate “m.” site rather than just using media queries as a crutch. This debate has been raging all year, I wrote about it here:
http://www.bensmithett.com/blog/on-using-responsive-web-design-to-create-a-mobile-website
Now, on disabling user scaling!
We’re not talking exclusively about recreating a native iPhone app with HTML/CSS/JS here, we’re talking about the whole mobile web. Some mobile websites may be nothing more than an app with a few big, touch-friendly buttons. In that case, if it’s well designed, you might be OK to disable zoom.
I wouldn’t, but let’s not get into the “iPhone-specific” vs “works on every device” argument.
Let’s say you create a site just for iPhone that has text-heavy pages (like a blog) and disables user scaling. For example:
http://m.ngenworks.com/blog/ngen-works-goes-mobile/
Now my very real experience with this site is that I went to that page while I was sitting on the train – the sun was glary and the carriage was shaking me about, making it more difficult than usual to read. I wanted to zoom in to bump the text size up a bit, but user scaling is disabled so I couldn’t.
What you have there is a design decision that actively makes it difficult for any user in that common mobile browsing context from interacting with your site.
There’s nothing wrong with a site not looking pixel-perfect if a user does choose to zoom, but it shouldn’t break the page completely and you should at least give them that option.
Caveat: My Android reflows text upon zoom to fit the viewport, iPhone does not. Depending on how you design it, this could be an issue (introducing horizontal scrollbars and all that.)
Ben Smithett
@Sarah Parmenter
Sucks that you’ve been copping so much heat for this, it’s a helpful article (especially with the title change!)
Perhaps an update to acknowledge the change from mobile to iOS in the title would be helpful. That does completely change the context of the earlier comments.
I completely agree that, considering the mobile browsing context, sometimes the best solution is to create a separate “m.” site rather than just using media queries as a crutch. This debate has been raging all year, I wrote about it here:
http://www.bensmithett.com/blog/on-using-responsive-web-design-to-create-a-mobile-website
Now, on disabling user scaling!
We’re not talking exclusively about recreating a native iPhone app with HTML/CSS/JS here, we’re talking about the whole mobile web. Some mobile websites may be nothing more than an app with a few big, touch-friendly buttons. In that case, if it’s well designed, you might be OK to disable zoom.
I wouldn’t, but let’s not get into the “iPhone-specific” vs “works on every device” argument.
Let’s say you create a site just for iPhone that has text-heavy pages (like a blog) and disables user scaling. For example:
http://m.ngenworks.com/blog/ngen-works-goes-mobile/
Now my very real experience with this site is that I went to that page while I was sitting on the train – the sun was glary and the carriage was shaking me about, making it more difficult than usual to read. I wanted to zoom in to bump the text size up a bit, but user scaling is disabled so I couldn’t.
What you have there is a design decision that actively makes it difficult for any user in that common mobile browsing context from interacting with your site.
There’s nothing wrong with a site not looking pixel-perfect if a user does choose to zoom, but it shouldn’t break the page completely and you should at least give them that option.
Caveat: My Android reflows text upon zoom to fit the viewport, iPhone does not. Depending on how you design it, this could be an issue (introducing horizontal scrollbars and all that.)