Skip to content

24 ways to impress your friends

Designing for iOS: Life Beyond Media Queries

Sarah Parmenter Sarah Parmenter

63 Comments

Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.

Got something to add? You can leave a comment below.

Simon Willison

Whatever you do, do NOT redirect users from every single page on your site to the same mobile site homepage. That breaks ALL of your incoming links to e.g. articles on your page, which is incredibly frustrating. If you’re going to redirect to a mobile site, make sure you redirect to the mobile equivalent of the page the user landed on in the first place – not just the homepage.

Abraham Williams

Avoid redirecting visitors with JavaScript. It first requires the entire full version of page to load then load the mobile version afterwards making the load time even worse from not even providing a mobile version.

Gregory Van Looy

Okay, maybe not everything in the article is what it needs to be for the die-hard mobile devs but as an introduction (with some extra info) this is a superb article for the desktop front-end devs making the leap to mobile.

With the comments added we learn a lot and that’s what 24ways is about

grtz
from Belgium

Gregory

Mathias Bynens

Instead of referencing the touch icon (be it the precomposed non-glossy version or the normal one) in the HTML, you should always name the images `apple-touch-icon-precomposed.png` and `apple-touch-icon.png` respectively, and place them in the root of the domain. That way, Mobile Safari will automatically detect it.

I’m not gonna respond to the use of browser sniffing / redirection to a separate mobile site because I see other people have already made my point on that matter.

PHIL SORRELL

Great article Sarah – really gives an insight into the iPhone specific features that you can access.

There seems to be some concerns here about the redirection.

Whilst I probably would not use Javascript for the redirection, I was always under the impression that Javascript in the <head> ran before the remaining content is loaded (hence why you need to use onload if your javascript is modifying the dom structure of your page) – whilst other styles and scripts will still be downloaded, none of the content should be before the redirect kicks in.

As far as how whether to redirect to a single page or do a complete redirect, this depends entirely on what you want to achieve. I agree completely that if you wanted an iPhone version of a blog then you would probably want to do a full redirect, but Sarah’s code can easily be modified with:

header(‘Location: http://mobile.yoursitehere.com’ . $_SERVER[‘REQUEST_URI’] . $_SERVER[‘QUERY_STRING’]);

However it is equally possible that for other uses your iPhone specific version will be different to your web version, especially in the example Sarah gives as replicating an iPhone app – in this case it may be appropriate to redirect only to the homepage to provide a different user experience.

.htaccess can obviously achieve the same thing, but will not help if you have a windows server.

Philip Meissner

Instead of directing a user to an entirely different template, could developers use plugins such as http://devot-ee.com/add-ons/is-iphone/ to detect the user agent and deliver a smaller image? That way (if you’re using ExpressionEngine) you can use the same templates/URLs to reduce complexity and maintain SEO.

cancel bubble

I just wanted to chime in here with something I don’t think has been mentioned, which I feel is very important:

The limitations of iPhone caching (with OS3 and OS3.1. Hopefully Stoyan updates this for iOS4).

Stoyan Stefanov has some great findings at http://www.phpied.com/iphone-caching/

Some items I quickly gathered:

* iPhone will not cache components bigger than 15K (this is ungzipped size, meaning if you have for example a 20K JavaScript and your server sends it gzipped down to 10K, it will not be cached by the iPhone.)

* total cache is about 1.5MB

* powering off the device still clears all the cache

* consider HTML5 application cache to improve cacheability and provide offline experience

This page is definitely worth a read.

Kevin Bolduan

As far as I understand it: the “code to remove the address and status bars at the top and bottom of the screen” that you provided only kicks in for iOS if the user saves the website to their Home screen as an icon.

There are JS techniques to hide the address bar (notably using scrollTo) but unless the user has created an icon on their home screen with the functionality from Safari, you cannot remove the toolbar at the bottom of the Safari page.

Drew McLellan

@Rob L.

What if I want to zoom in because your design, though laid out with respect to the pixel size of the screen, uses a font size that’s too small for me to read easily, or I want to get a closer look at an image on the page?

The context of this tip is within your iOS-specific pages. Provided the designer has made careful UI choices, there should be no need to zoom the interface at that point any more than there’s the need to do so in a regular iOS app.

Drew McLellan

@Peter: Well, of course. No one is making that claim. But iPhone == real device that designers and developers need to know how to work with, and that’s what the outlined techniques have given us.

I had cause to find all this stuff out for a recent project, and after a lot of research still didn’t come up with as comprehensive a list of techniques as Sarah has presented. To have it all written up, collated in one place and explained by an expert is tremendously useful.

Thanks Sarah!

Stu Robson

@Peter

Did you read this part of a sentence from the first paragraph?

but many people are relying only on them to create an iPhone-specific version of their website.

Shaun Hare

Sarah, you make some very good points. I think we should especially consider the bandwidth loading lots of extra content takes. Data plans are still incredibly expensive and 3g is not ubiquitous folks ( try living in a rural area)

One other way of achieving a redirect – conforming to what is a better user experience as Simon suggests (and I wholeheartedly agree) is to use a .htaccess file

if just iPhone you could do

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} ^.iPhone.$
RewriteRule (.*) http://m.shaunhare.com/$1

Another point I was told javascript (learnt from one of Andy Clarke’s workshops hat tip Dan Rubin) would also be used to lose the address bar often desired on web apps 

<script type=“text/javascript” charset=“utf-8”>
		window.onload = function() {
		  setTimeout(function(){window.scrollTo(0, 1);}, 100);
		}
</script>

Does the head tag now do that without the js? – must try that.

Thanks for sharing your practical experience.

Rob L.

[The width=device-width] declaration, added into the <head>, stops the user being able to pinch-zoom in and out of your design, which is perfect if you are designing to the exact pixel measurements of the iPhone screen.

What if I want to zoom in because your design, though laid out with respect to the pixel size of the screen, uses a font size that’s too small for me to read easily, or I want to get a closer look at an image on the page?

Don’t mean to knock the article, this section set off some potential UX alarms for me.

Ethan

There are some fantastic tips here for those cases when a separate mobile site is called for. Lovely work, Sarah, and thanks for sharing.

However, I’d like to call out one small point:

The trouble is, regardless of what you have carefully selected to be display:none; in your CSS, the iPhone still loads everything in the background; all that large imagery for your full scale website also takes up valuable mobile bandwidth and time.

Personally, I’d argue that if you’re using media queries to simply hide significant chunks of markup to different classes of users, then you really are better serving up a separate document.

But media queries, whether used on a responsive design or something more rigid, are ideal for projects when the content has been carefully considered as appropriate for all classes of users, regardless of the device. I’m working on a very content-rich redesign that requires a responsive approach, and it’s, well, geekishly exciting to see the content carefully and beautifully formatted on the myriad devices and browsers that access it. All with some careful planning, a thoughtful design, and a responsive execution.

Anyway. Just wanted to throw a quick note out there that media queries and @display: none@ don’t necessarily need to go hand-in-hand. (Which I realize you probably said somewhere, but I’m tired and oh look a shiny thing.)

Thanks again for the article!

Ben Smithett

Good (if a little iDevice-centric) article, but I’m yet to hear a remotely good reason for disabling user scaling.

“It might break my pixel-perfect design” isn’t good enough in 2010.

You wouldn’t consider doing it for a desktop site, not sure why it’s suddenly OK to do it on devices with tiny screens where zoom controls are far more important.

Daniel Davis

I was going to make the same comment as Peter but you’re also correct, Drew.

Having these tips (but remembering Simon’s caveat) is useful and saves research. Indeed, with 22% of the mobile market (StatCounter), designers and developers should know about this platform.

I think the point Peter was trying to make is that it could have been clearer that the article is aimed primarily at iPhone/iPod Touch developers. Either that, or supplement the valuable advice that’s already there with non-iOS-specific information. For example, background images overridden with media queries are not loaded in some browsers – Opera Mobile, Opera Mini, Firefox (desktop at least, not sure about mobile). [Disclaimer: I work for Opera]

Voiture neuve

Hello Sarah,

I’ve something to ask you about your post : you said that the best solution to display a website on an iPhone is not to put some “display:none;” on your css for mobile devices. You spoke about bandwith. Don’t you think that if you redirect your mobile users with javascript, you’ll use also some bandwith ?

The javascript is executed when the total page is loaded. And this page is not the mobile page, but the one for computers. So, I think that the best practice is server-side redirection with PHP or Apache, yes.

Samuel Linde

Just echoing what Simon said. There’s few things as frustrating as following a link to an article from Twitter, for example, only to end up on the mobile version of the home page with no way to find the article in question except for searching the site.

Otherwise, great summary, Sarah!

Peter Gasston

Sorry, I do agree that this is a useful summary of iPhone development tips; however, many of the techniques are equally relevant to developing on other mobile devices, and many can also be used with media queries. The title and intro didn’t prepare me for the rest of the article.

Sarah Parmenter

@Simon Willison @Samuel Linde
I feel you failed to see this paragraph, which covers the issue you are addressing:

At this point, be sure to provide a link to the full version of the website, in case the user wishes to view this and not be thrown into an experience they didn’t want, with no way back. bq.

@Jeremy Keith
Apologies that you don’t like the way it was written, I knew I was going to stir you up on this subject given your blog post from a few weeks back.

@RobL @BenSmithett
The apps on your iPhone are not scalable, you cannot zoom in and out, if someone wants to recreate an app as close to the native ones that you can download, with careful UI and adhering to the same Human Interface Guidelines that you would use to create a native app, then disabling the user scaling is perfectly acceptable.

Marco Kunz

Many thanks to you, Sarah, for this article.

As I am just about to conquer the ways of publishing websites to mobile devices over the x-mas holidays here, it is nice to have a different approach to this as with the @media querys.

I always love to have more than one way to achieve my goals to have some flexibility.

Greetinkz from ze Germany.

Marco.

I have to vigorously agree with @Peter on this one, iPhones aren’t the only mobile devices able to display websites.

Nice article nonetheless but I wish you didn’t cater only to this subset.

Simon Young

I actually think this is one of the most useful articles in the 24ways series so far this year.

Regarding the first commenter’s succinct point that mobile != iPhone: that is of course true and there is evidence to suggest more Android phones are activated than iPhones in some areas of the world.

The problem is that targeting Android phones is difficult – different resolutions, different software functionality and hardware functionality mean that you can’t develop for the device with the kind of certainty you can for the iOS platform.

That point is as true for developing web apps for mobile as it is for developing native apps.

I think that media queries are a great solution for presenting the same content on many different platforms and devices where you can’t be sure of the size of the device and the capabilities of the platform.

But that said, if you know you have a significant mobile user base who are using the iPhone/iPod and you want to target them with a separate version of your site which targets the device’s enhanced functionality rather than presenting the content solely based on the dimensions of the screen then this article offers some great pointers on how to get started.

Thanks Sarah!

Sarah Parmenter

@Jeremy Keith

I’m obviously not doing very well on the writing front at the moment.

I understand entirely what Simon was trying to say but I have pointed out in the article, that this is only suitable for some sites, it’s up to the site owner to make that call. It’s entirely possible to send the user to an iPhone specific page of a ‘Contact us’ page if they landed on the ‘Contact us’ page of the full site, but yes, in the case of blog posts links, this creates a whole new problem and I can appreciate that.

I’m sorry that my attitude toward media queries has come across as defensive, as I say in the article, I love media queries and they definitely have great uses, but in my opinion, there is a better way to create iPhone specific sites.

At the end of the day, we’ve all got to disagree at some point, that is what moves the web forward.

Henrik Carlsson

Great article, Sarah!

As previously stated it’s nice to have a short, comprehensive text that summarize and explains these things. One of my ever ongoing projects is a webapp for both pcs and mobile. I will absolutely use this article in the next version of it.

wstn

Surely iPhone specific websites are bad? Its just as bad as the old ‘works best in Internet Explorer’ buttons from the previous decade.

I don’t do much stuff for mobile, but surely you can have one ‘mobile version’ that works pretty well across the majority of devices? It just seems stupid to tailor it specifically for a device, especially the iPhone, who’s market share is only going to get smaller.

Jamie Bicknell

Good article Sarah, as Drew mentioned it’s great to have all these techniques in one place for easy reference.

One thing I would add, which is specific for the iDevices would be text size adjusting. I had a problem with my tumblog a while back where Mobile Safari would increase the text size of the content area, so much so that it would make the text larger than the H1’s and H2’s. This can be easily remedied by adding this to the CSS to stop Safari from automatically adjusting any text:

@media screen and (max-device-width:480px) { body{ -webkit-text-size-adjust:none; }
}

Sarah Parmenter

@WSTN

Saying iPhone specific websites are bad is like saying iPhone specific apps are bad. You take advantage of what each platform has to offer and tailor make the experience for a specific audience.

Media Queries are great for creating a general mobile site, however a client of mine recently wanted a site that looked and felt like a native iPhone app, this was entirely possible with everything pointed out in this article.

Tamsin

Useful article in places, but rather bemused about the methods posited for redirection? Javascript is wildly inappropriate if your primary concern is unnecessary bandwidth consumption (mentioned in the preceeding paragraph) – considering that Javascript won’t even be excuted until after page load. And performing blanket redirects with no consideration for specific page requested (as per your PHP example) is a usability nightmare.

Why no .htaccess? Surely by far the most appropriate solution.

Simon Dell

HI Sarah

Thanks for the useful summary of iPhone web-app tricks. I’ve been doing a bit of mobile-specific front-end work recently so I’d seen some of these tips, but not all of them and definitely not all in one place.

I want to chime in with the debate about scaling, echoing Rob L’s concern over preventing users from scaling. I think it’s an accessibility “no-no” and I“m constantly frustrated by the number of mobile site design articles advocating the idea. The web development community at large has spent the last 8-10 years collectively discussing how flexibility of design is the most practical way to help users of the widest range of abilities and devices, why suddenly stop when the pretty, hi-def, touchable screen from Apple becomes so popular?

Whilst I can see (no pun intended) Sarah’s point that native iPhone apps don’t scale with pinch (unless you turn on the phone’s accessibility features), I can’t see that as justification for preventing rescaling of a web app. Apple have picked a standard font-size for their native apps that’s pretty readable by a good range of users (apart from the SMS app which is dreadful), but there’s absolutely no guarantee designers will choose font-sizes or a visual rhythm that fits well with all users’ visual abilities, finger size or dexterity. in fact, a great many designers have a preference for small fonts.

If you’re going to encourage designers and developers to turn scaling off, at least encourage them in the same breath to research text-sizes readable by the widest range of users.

Aral Balkan

Hey Sarah,

First off, great article. I was just talking to Jeremy about this very issue a few days ago.

The important point here is to highlight how media queries are not always the right solution to implementing a mobile site. Fluid sites that morph into their mobile skins as they are resized on a desktop machine definitely pack wow factor (see Andy Clarke’s site for Hardboiled Web Design, for example) and yet, you have to ask yourself whether you are designing the site to impress desktop users when they resize their browser windows or to provide the best possible user experience for mobile users. If it’s the latter, than serving up mobile-optimized content to mobile users may be the better choice, especially if your main site content is heavy on graphics or code.

I agree with Simon’s comment that redirecting users to a separate page is not the best way of implementing this but it is just as simple to serve separate content per page/screen for mobile users.

So, for an iPhone-specific example, something along the lines of:

<?php
	$agent = $_SERVER[‘HTTP_USER_AGENT’];
	if (ereg(”(iPhone|iPod)”, $agent)) 
	{
		require(“iphone-version-of-this-page.html”);
	} 
	else
	{
		require(“desktop-version-of-this-page.html”);
	}
?>

Also, I find it either incredibly arrogant, naive, or simply devoid of understanding of user experience to suggest that it is somehow unforgivable to create a version of a site specifically optimized for the most popular smart phone in the world.

Providing an exemplary user experience requires focus. You cannot provide a great user experience by designing for the lowest common denominator.

Furthermore, you have to ask yourself not only how much actual web-browsing is being carried on non-smartphones (hint: not much) but also how many of the people browsing the web on other devices are in your target audience. It may just be that, for your target audience, it’s important to support a lowest-common-denominator mobile site that works on any Nokia dumbphone. It’s an equally-valid possibility, however, that (based on your target market, budget, and schedule) it makes more sense to focus on providing a beautiful user experience on a single mobile platform.

wstn

@Aral

The iPhone isn’t the only smartphone. This may come as a shock to you, but really, it isn’t. The options aren’t the ‘Nokia Dumbphone’ or an iPhone. I find this assumption incredibly arrogant, naive, and simply devoid of understanding of user requirements, budgets, and all the rest of the factors that go into choosing a phone.

The point I’m making is were talking about the web, not native apps or anything else, but the web. We know that a site should work, in some way or another, across all browsers / OS’s etc. My issue comes with the idea that in the mobile world, this is somehow different. If your going to have an iPhone specific site, you should be catering for all the other possible options as well, which means god knows how many different versions to keep on top of, maintain and update etc, its going to become a maintenance nightmare.

Imagine you’re browsing on your wonderful oh-so-lovely iPhone and you come across a site that wont work properly – its been built for android – chances are that’s going to annoy you, but for some reason you seem to think this is okay the other way round?

Dave Sparks

An interesting read through the comments. I think there’s certainly no problem with having a specific site for a mobile device given the large difference in the platform from the desktop. It is not really comparable to having a separate site for each browser as @WSTN suggests.
Personally as well I live in an area with very little 3G coverage so I also find it useful for a site to have a mobile version that’s maybe a little less heavy on the loading times.

Anyway I wanted to ask what’s peoples preferred method for allowing users to access the full site when they click the to view it? Simply using a session variable and checking that alongside with the device query?

Aral Balkan

Hi WSDN,

You’re right, there definitely are other smartphones out there – Android being the main competitor at the moment (but my favorite underdog is the Palm Pre). Windows Phone 7 is also – much to my surprise – looking like a strong contender.

And I have nothing against graceful degradation either. What I do have a problem with is the assumption that any experience you build must run on every device out there. The only way to truly achieve this is to cater to a lowest common denominator in your design. I couldn’t think of anything else more mind-numbingly boring. That’s not design, it’s accountancy.

Or, you can pick and choose the platforms/devices that you want to support well and optimize the experience for those. It doesn’t have to be just the iPhone. But you do need focus. And there’s nothing wrong with specifically optimizing your site for iPhone – as was stated in some of the comments and which my own comment was responding to.

Soap’s great for cleaning stuff. But we use shampoo for our hair, detergent for the dishes, and toilet cleaner to clean the toilet. Each is optimized for the task at hand and thus provides a better user experience for each specific use case. Sure, we could use soap for all three, and it would probably get the job done, but it wouldn’t be as good an experience.

bruce

If a customer requires an iPhone site, an iPhone site he will get. That’s business.

But it’s also our job to educate customers so that they consider a site that works for the majority of the planet. If they decide they don’t want that, so be it.

It seems to me that developers should bug Apple to fix the bug in their media queries implementation so the standards-based CSS approach is more viable that device-specific sites.

Anyway, I would say that, wouldn’t I? And I didn’t come here to pontificate, but rather to bring your attention to a rather excellent blog post by Greg Rewis that researches ““what does a mobile device download when encountering a page using media queries?”.

http://blog.assortedgarbage.com/?p=564

Jason Rhodes

@aral

And I have nothing against graceful degradation either. What I do have a problem with is the assumption that any experience you build must run on every device out there. The only way to truly achieve this is to cater to a lowest common denominator in your design.

Isn’t that pretty much the defintion of graceful degradation / progressive enhancement, though?

If a client wants an iPhone only site, they really want an iPhone app. You might not be able to convince them of that and you may have to build them a site just for iPhone, but it’s certainly not the ideal we should be aiming for, is it?

Christoph Zillgens

I really like the article for making clear that media queries are not (or not necessarily) the weapon of choice when making a mobile site and for providing many useful tips.

What I dislike is the paragraph about scaling. I’m with Rob and Ben. It’s really annoying for me on many so-called “mobile-optimized” websites to not being able to zoom.
A mobile site is not an app, I’m still in Safari where I’m used to use pinch-zoom, if the text is too small to read, or to quickly scale images.

It’s not the designer’s task to take away functionality ( even if he/she then carefully guess what might be a readable font-size for me).

Peter Gasston

@Aral Balkan – You seem to have come in halfway through the conversation. The original title of this article didn’t mention iOS, and the opening paras mixed ‘mobile’ and ‘iPhone’ (they still do, but that’s less important now). That’s what led to my negative comment, and probably to others (if I can presume to speak on their behalf). The title’s since been changed to make clear that this is iOS specific, but obviously the comments no longer reflect this.

Francesco

Very interesting discussion! And very interesting article, even though I agree that it’s bad-titled.

@Aral, I wanted to add that in my opinion it’s not entirely true that “the only way to truly achieve this is to cater to a lowest common denominator in your design.” Actually, I think that the exact opposite is true. Not easy to do, of course. But I think that (when we can) we should design for the best possible experience, and let those other browsers/device do what they can.

Like we already do with the desktop. We do use CSS3, knowing that IE can’t show most of them (and its users won’t even realize), don’t we? Here it’s harder, because we’re talking about many more devices… but theoretically it seems to me it’s the same thing.

Great article, anyway, lots of good stuff to use, in addition to media queries.

wstn

@Jason – That’s spot on what I was getting at mate, if you want something iphone only, make it an app.

@Aral

You cater for the lowest common denominator, and enhance upwards for others. As Jason said, you say you agree with Graceful degradation (although I was more getting at progressive enhancement, but that’s for another time) and then define it in the sentence about what you don’t agree with, that’s awfully contradictory.

My point is, weather your intending for the site to be viewed on a phone or a PC or whatever, its still web design and it should still follow the accepted, much debated, web standards and best practice. If you really feel like you cant achieve the user experience you or your client wants and have to build it device specific, it should really be a native app.

David Goss

For those who are questioning why, if you wanted something specifically for iPhone, you wouldn’t just build a native app, there are a couple of reasons. To build a native app, you have to build it in Objective C. If what you want can be achieved in HTML, CSS and JS, then why go to the trouble/expense of getting it built as a native app? (Although to be fair, if you want to charge some money then that changes things) Also, to publish a native app, it needs to be approved by Apple. The content you are delivering could be outside the approval requirements. So, I’d say it is a valid article, but that media queries is a different discussion.

Chris Garrett

Media Queries certainly aren’t sufficient for large scale applications, but redirecting to an entirely alternative site isn’t sufficient either.

In a Rails environment, I’d be inclined to create a mobile specific layout and use a strain of respond_to to serve mobile specific views where necessary. It’s a much more DRY approach and keeps everything a lot more maintainable.

I fail to see why anyone would break the development process by creating and serving versions of applications specifically for iOS. Apart from visual language, which isn’t really necessary in a web app (being OS agnostic by their nature) the principals of good mobile design apply across iOS, Android, WebOS, etc. Are we likely to start creating OS X or Ubuntu specific versions of a web application?

If people stop mimicking the Apple aesthetic and apply their own sensibilities, rooted in fundamentally good mobile design principals, we’ll end up with much more robust and applicable mobile web apps.

darren.nicholls

@wstn “if you want something iphone only, make it an app.”

I don’t think having a smart phone specific, in this case iphone version of a site into an app is a well thought through idea.

Firstly, cost implication would balance out that a mobile optimised version of a site is more cost effective than an app. Secondly, an app and website are two separate entities and should be treated as such.

Drew Neil

Thanks for bringing all of this together in one place Sarah – it’s a useful reference containing some great advice.

The controversy around this article stems from the question of whether alternate versions of a website should be served for different browsers/devices. I think that people are quibbling over the wrong dichotomy. It is now possible to create applications for iPhone using HTML, CSS and JavaScript, then deploy them to the App Store using PhoneGap. In my mind, that significantly shifts the balance when weighing pros and cons of web apps Vs native apps. A web developer can now build applications for iPhone/iPad without having to learn Apple’s iOS SDK. The advice in this article is sterling for anyone who wants to do that.

Brad Touesnard

The biggest cause for argument here in the comments seems to be budget. Some of you are considering budget as part of the equation and some aren’t.

With little to no budget for a mobile site, of course using CSS Media Queries to make the site a little friendlier for mobile users is a good idea. But if the client has budgeted appropriately for a separate mobile experience, then I have to agree with @Sarah and @Aral that CSS Media Queries are probably not going to cut it.

The article has some excellent tips about web development on the iPhone, so thanks to @Sarah for that. However, I have to agree with @Jeremy and @Simon that there is definitely some questionable bits (redirecting with JS and the display:none comment).

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

Andy

Hmm – interesting article – one that went straight into Evernote before reading any of this discussion.

I’ve spent the past few months using @media queries to adjust site layout for other devices, including our own little website, and it does work very well.

Regarding the use of display: none to hide content – I like Andy Clarke’s solution of placing @media queries inside specific CSS links as shown at the end of this article – <a href=“http://stuffandnonsense.co.uk/blog/about/hardboiled_css3_media_queries/”>Hardboiled CSS3 Media Queries</a>
This way you’re only using the correct CSS for the device / browser, not loading superflous code / images and aren’t relying on javascript / browser sniffing to serve up the correct page layout…

…browser sniffing being something of a no no of course in today’s web standards world (altho it didn’t stop Apple doing it with their “HTML5 showcase” did it?!)

Which I guess brings me to my main issue with what is otherwise a very useful article, that being the obsession with iPhones (and all things Apple for that matter).

I saw @sazzy at DIBI at the beginning of this year. I nearly didn’t as I didn’t have any interest in making iOS apps, but decided to give it a go and was pleasantly surprised. Not only was Sarah an excellent speaker, clearly skilled and passionate about her work, but a lot of what she said was relevant to all smartphone devices, not just the iPhone.

I can understand that Sarah is a big iOS fan, and has a name for herself as such, with presumably plenty of interesting work making iPhone apps etc, but I think it’s about time we all started accepting that the iPhone is not the be all and end all of mobile phones, <a href=“http://www.alistapart.com/articles/smartphone-browser-landscape/”>as was mentioned</a> in Peter Gasston’s first comment.

I also raised an eyebrow to Aral’s comments that designing for anything other than an iPhone is designing for the lowest common denominator. As I think WSTN so well brought up there’s a big difference between “Nokia dumbphones“and the likes of the HTC Desire.
I can see that an old Nokia WAP phone would be like the IE6 that we all know and hate, and presumably have largely ditched now in terms of development and testing. But the Blackberry’s, Palm, WinMo7 and most significantly Android represent a very real browser share, and one we should be educating our clients about.

If a client came to me asking for a website with an iPhone specific mobile site, I would look for all the research that suggests that within a year or two, Android will be as big as iOS, and if they want to make their website relevant to the typical mobile visitor not just on the day of launch but in 12 or 24 months time when the smartphone market will be a lot more diverse than todays iOS-centric one it would irresponsible for me to say “sure – iPhone only site it is” – I would be pushing very hard to make a site that works across all smartphone devices.

Don’t get me wrong – I’m all for webdesigning the <a href=“http://hardboiledwebdesign.com/”>Hardboiled</a> way, pushing limits and designing for the best. I do however get a bit irritated by a lot of people that seem to be under the impression that the iPhone browser is so far ahead of all other smartphone browsers that they don’t warrant consideration. There’s very little that Mobile Safari does that Android browser doesn’t – some HTML5 form elements perhaps, but all the amazing webkit juiciness is in there. “The best” that we speak of should include these other webkit enabled smartphones.

And surely this is what the open web standards movement is all about – I honestly think that moving towards closed, native specific platforms is a very bad thing for the web at large – an excellent article by Tim Berners-Lee in the <a href=“http://www.scientificamerican.com/article.cfm?id=long-live-the-web”>Scientific American about this can be found here</a>.
I would much rather be aiming for flexible, cross device mobile sites that play to their typical usage, size restrictions and common hardware opportunities far more forward thinking than spending clients money on closed, platform-exclusive sites that don’t take the future into account websites.

Viva la web app!

Ivan Nikoli?

Sarah, you’ve forgot to mention that by setting “apple-mobile-web-app-capable” in meta tag web app/site must be fully “AJAX-ed” – that means, any page call must be done inside JS. If it’s outside page call or simple operation like clicking/tapping on default link, iOS (since it’s the only platfom that recognizes this value, not sure about the others) will exit the app and launch requested page in Safari with defaut view (chrome, etc.).

Also, browser sniffing with JS is kind-of a bad practice and prone to errors, but unfortunately widely used.

Otherwise, great discussion and comments, especially regarding context of mobile web apps/sites.

I don’t see the need for mobile.domain.com.

You have your sites HTML, and then serve up different stylesheets for different mediums. Of course, if you want to tailor fo iPhone, you make a sheet for that.

It’s important to have the different mediums in mind when laying out the basic HTML structure. Don’t duplicate your site.

Jason Kneen

@Tor

Some people would say that the use of the http://mobile. etc gives people the choice as to what they see.

I sometimes hate being thrown into a mobile site when I wanted to see the full version. I then have to find the link (if it’s even there) that will let me do that.

Amazon is a good example of that where the mobile site doesn’t give me the features I needed today (sellers profile) in order to update a shipment notification.

Jason

cancel bubble

Following up on my previous post re: caching, Stoyan Stefanov provided me with these links (he won’t be updating his iphone caching post, says these are better options):

http://www.yuiblog.com/blog/2010/07/12/mobile-browser-cache-limits-revisited/

http://stevesouders.com/tests/cachesize/

Definitely good stuff there.

Jason Karns

I’m quite surprised by the number of comments who think that JavaScript execution is delayed until the page is fully loaded. JavaScript is downloaded, parsed, and executed at the very location it is referenced in the page. It is for this very reason that many performance-minded people tell you to place your scripts at the bottom of the page; because they BLOCK loading of the page while they are downloaded and executed. It is this very problem of waiting for the DOM to be ready in order to execute DOM-dependent code that so many JS frameworks solve with OnDomReady events and other onload hacks.

It is perfectly acceptable (from a performance standpoint) to use JS as your redirection method.

Mike Mai

my blog has a few extra lines of media queries and it’s working gracefully on iphones and androids. not perfect, but almost perfect.

great article, sarah. it’s a very good intro to mobilesite design

Jeremy Keith

This is a good article about developing iPhone-specific websites, but it has been framed in a very odd way. The title and introduction seem to be misdirecting attention away from the focus of the article and encouraging a dichotomy that I don’t think exists.

For example, people aren’t using media queries (and fluid grids and flexible images) to create platform-specific versions of their sites; they’re using them to create layouts that can adapt to many screen sizes on many devices …not just the iPhone.

It’s a shame because, as I said, I think this is a good article about a specific topic. I don’t understand why it has been artificially broadened with references to a separate, wider topic (the straw man about display: none seems especially weird).

And now, instead of responding to the content of the article, I find myself responding to its framing. Sorry.

Sam Hill

The article states “The trouble is, regardless of what you have carefully selected to be display:none; in your CSS, the iPhone still loads everything in the background; all that large imagery for your full scale website also takes up valuable mobile bandwidth and time.”

This is only partly true. Images referenced within a media query are only downloaded to the device if the media query is applicable.

So, if you’re using media queries to create a mobile and desktop version of your site using the same URLs, simply wrap your desktop css within a media query as well.

Jeremy Keith

Sarah, I think you’ve misunderstood what Simon was saying. The code you’re suggesting would always direct a user to the homepage of a mobile site. e.g.:

example.com/section/article

…will be redirected to:

mobile.example.com

…instead of:

mobile.example.com/section/article

As for my comment, I hope you appreciate what I was trying to say: that this otherwise-useful article is somewhat marred by its overly-defensive attitude with regard to media queries — a technology that’s tangential to the subject of the article (building iPhone-specific websites).

wstn

@Sarah

I don’t think its like saying specific apps are bad at all. In fact I meant quite the opposite, you expect apps to be tailored for specific devices, you expect websites to work across them all.

You wouldn’t have 4 versions of a website, one for IE, FF Chrome and Safari, would you? We’ve all seen / had the discussion about Progressive enhancement and all that jazz, its okay for something to not look like a carbon copy across different browsers / systems, so surely the same rules apply to mobile? You want one mobile site, that works across multiple OS/Devices – maybe with a slightly different experience for each one.

Creating websites that are tailored to an individual device is sort of totally the opposite to the view that’s come about in the ‘standards generation’ of designers and developers like ourselves. Or am I missing something? Like I said, I don’t do a great deal of mobile.

Scott Jehl

There are some great iOS tips here, and in that regard, this article is helpful (though the meta tag tip for hiding browser chrome is only true when the site is running from an installed-bookmark, as far as I know).

Unfortunately, the included media query opinions make those better points harder to appreciate, as (with honest respect to the author) those portions of the article are not consistent with my experience in the medium. To build on Ethan’s points above, responsive design is not about taking a desktop-oriented design and doing whatever possible (display:none, etc) to make it look presentable on mobile. It’s a strategy that aims to provide a great and appropriate experience to all browsers and devices in a responsible fashion. Content that isn’t relevant to users on an iPhone may in fact be unnecessary in all contexts, or more frequently, that content is actually appropriate to both contexts and just needs different presentation and behavior to cater to each use case (bigger hit areas on links, collapsing large nav lists, touch gesture improvements, etc, etc).

In my experience with mobile, as dev lead on the jQuery Mobile project, and being deep in the process of building a responsive design for a fairly complex site (the one Ethan tweeted excitedly about yesterday), even “application”-like experiences can be built with progressive enhancement, feature detection for touch events, and media queries to optimize the same content for different viewing contexts. Even your images can be responsive now! http://bit.ly/g0IDAI

One last point: the JS community spent years bogged down in User Agent string parsing madness before fairly recently making a forward-looking shift towards feature-detection-based approaches (jQuery no longer uses it internally, for example).

It may have been pointed out already, but the User Agent detect cited in this article will include Opera Mini users on the iPhone (info here: http://bit.ly/aXvUmZ), which is probably not intentional, and a good example of why UA detect assumptions are a dangerous bet.

<pre><code>

( /iPhone/i ).test(“Opera/9.80 (iPhone; Opera Mini/5.0.0176/812; U; en) Presto/2.4.15”)

==> true

</code></pre>

Impress us

Be friendly / use Textile