Designing for iOS: Life Beyond Media Queries
december 2010 by cloudseer
Although not a new phenomenon, media queries seem to be getting a lot attention online recently and for the right reasons too – it’s great to be able to adapt a design with just a few lines of CSS – but many people are relying only on them to create an iPhone-specific version of their website.
I was pleased to hear at FOWD NYC a few weeks ago that both myself and Aral Balkan share the same views on why media queries aren’t always going to be the best solution for mobile. Both of us specialise in iPhone design ourselves and we opt for a different approach to media queries. 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.
You can greatly increase the speed of your website by creating a specific site tailored to mobile users with just a few handy pointers – media queries, in some instances, might be perfectly suitable but, in others, here’s what you can do.
Redirect your iPhone/iPod Touch users
To detect whether someone is viewing your site on an iPhone or iPod Touch, you can either use JavaScript or PHP.
The JavaScript
if((navigator.userAgent.match(/iPhone/i)) || (navigator.userAgent.match(/iPod/i))) {
if (document.cookie.indexOf("iphone_redirect=false") == -1) window.location = "http://mobile.yoursitehere.com";
}
The PHP
if(strstr($_SERVER['HTTP_USER_AGENT'],'iPhone') || strstr($_SERVER['HTTP_USER_AGENT'],'iPod'))
{
header('Location: http://mobile.yoursitehere.com');
exit();
}
Both of these methods redirect the user to a site that you have made specifically for the iPhone. 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.
Tailoring your site
So, now you’ve got 320 × 480 pixels of screen to play with – and to create a style sheet for, just as you would for any other site you build. There are a few other bits and pieces that you can add to your code to create a site that feels more like a fully immersive iPhone app rather than a website.
Retina display
When building your website specifically tailored to the iPhone, you might like to go one step further and create a specific style sheet for iPhone 4’s Retina display. Because there are four times as many pixels on the iPhone 4 (640 × 960 pixels), you’ll find specifics such as text shadows and borders will have to be increased.
<link rel="stylesheet"
media="only screen and (-webkit-min-device-pixel-ratio: 2)"
type="text/css" href="../iphone4.css" />
(Credit to Thomas Maier)
Prevent user scaling
This 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.
<meta name="viewport"
content="width=device-width; initial-scale=1.0; maximum-scale=1.0;">
Designing for orientation
As iPhones aren’t static devices, you’ll also need to provide a style sheet for horizontal orientation. We can do this by inserting some JavaScript into the <head> as follows:
<script type="text/javascript">
function orient() {
switch(window.orientation) {
case 0:
document.getElementById("orient_css").href = "css/iphone_portrait.css";
break;
case -90:
document.getElementById("orient_css").href = "css/iphone_landscape.css";
break;
case 90:
document.getElementById("orient_css").href = "css/iphone_landscape.css";
break;
}
}
window.onload = orient();
</script>
You can also specify orientation styles using media queries. This is absolutely fine, as by this point you’ll already be working with mobile-specific graphics and have little need to set a lot of things to display:none;
<link rel="stylesheet"
media="only screen and (max-device-width: 480px)" href="/iphone.css">
<link rel="stylesheet"
media="only screen and (orientation: portrait)" href="/portrait.css">
<link rel="stylesheet"
media="only screen and (orientation: landscape)” href="/landscape.css">
Remove the address and status bars, top and bottom
To give you more room on-screen and to make your site feel more like an immersive web app, you can place the following declaration into the <head> of your document’s code to remove the address and status bars at the top and bottom of the screen.
<meta name="apple-mobile-web-app-capable" content="yes" />
Making the most of inbuilt functions
Similar to mailto: e-mail links, the iPhone also supports another two handy URI schemes which are great for enhancing contact details. When tapped, the following links will automatically bring up the appropriate call or text interface:
<a href="tel:01234567890">Call us</a>
<a href="sms:01234567890">Text us</a>
iPhone-specific Web Clip icon
Although I believe them to be fundamentally flawed, since they rely on the user bookmarking your site, iPhone Web Clip icons are still a nice touch. You need just two declarations, again in the <head> of your document:
<link rel="apple-touch-icon" href="icons/regular_icon.png" />
<link rel="apple-touch-icon" sizes="114x114" href="icons/retina_icon.png" />
For iPhone 4 you’ll need to create a 114 × 114 pixels icon; for a non-Retina display, a 57 × 57 pixels icon will do the trick.
Precomposed
Apple adds its standard gloss ‘moon’ over the top of any icon. If you feel this might be too much for your particular icon and would prefer a matte finish, you can add precomposed to the end of the apple-touch-icon declaration to remove the standard gloss.
<link rel="apple-touch-icon-precomposed" href="/images/touch-icon.png" />
Wrapping up
Media queries definitely have their uses. They make it easy to build a custom experience for your visitor, regardless of their browser’s size. For more complex sites, however, or where you have lots of imagery and other content that isn’t necessary on the mobile version, you can now use these other methods to help you out. Remember, they are purely for presentation and not optimisation; for busy people on the go, optimisation and faster-running mobile experiences can only be a good thing.
Have a wonderful Christmas fellow Webbies!
mobile
shared
from google
I was pleased to hear at FOWD NYC a few weeks ago that both myself and Aral Balkan share the same views on why media queries aren’t always going to be the best solution for mobile. Both of us specialise in iPhone design ourselves and we opt for a different approach to media queries. 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.
You can greatly increase the speed of your website by creating a specific site tailored to mobile users with just a few handy pointers – media queries, in some instances, might be perfectly suitable but, in others, here’s what you can do.
Redirect your iPhone/iPod Touch users
To detect whether someone is viewing your site on an iPhone or iPod Touch, you can either use JavaScript or PHP.
The JavaScript
if((navigator.userAgent.match(/iPhone/i)) || (navigator.userAgent.match(/iPod/i))) {
if (document.cookie.indexOf("iphone_redirect=false") == -1) window.location = "http://mobile.yoursitehere.com";
}
The PHP
if(strstr($_SERVER['HTTP_USER_AGENT'],'iPhone') || strstr($_SERVER['HTTP_USER_AGENT'],'iPod'))
{
header('Location: http://mobile.yoursitehere.com');
exit();
}
Both of these methods redirect the user to a site that you have made specifically for the iPhone. 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.
Tailoring your site
So, now you’ve got 320 × 480 pixels of screen to play with – and to create a style sheet for, just as you would for any other site you build. There are a few other bits and pieces that you can add to your code to create a site that feels more like a fully immersive iPhone app rather than a website.
Retina display
When building your website specifically tailored to the iPhone, you might like to go one step further and create a specific style sheet for iPhone 4’s Retina display. Because there are four times as many pixels on the iPhone 4 (640 × 960 pixels), you’ll find specifics such as text shadows and borders will have to be increased.
<link rel="stylesheet"
media="only screen and (-webkit-min-device-pixel-ratio: 2)"
type="text/css" href="../iphone4.css" />
(Credit to Thomas Maier)
Prevent user scaling
This 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.
<meta name="viewport"
content="width=device-width; initial-scale=1.0; maximum-scale=1.0;">
Designing for orientation
As iPhones aren’t static devices, you’ll also need to provide a style sheet for horizontal orientation. We can do this by inserting some JavaScript into the <head> as follows:
<script type="text/javascript">
function orient() {
switch(window.orientation) {
case 0:
document.getElementById("orient_css").href = "css/iphone_portrait.css";
break;
case -90:
document.getElementById("orient_css").href = "css/iphone_landscape.css";
break;
case 90:
document.getElementById("orient_css").href = "css/iphone_landscape.css";
break;
}
}
window.onload = orient();
</script>
You can also specify orientation styles using media queries. This is absolutely fine, as by this point you’ll already be working with mobile-specific graphics and have little need to set a lot of things to display:none;
<link rel="stylesheet"
media="only screen and (max-device-width: 480px)" href="/iphone.css">
<link rel="stylesheet"
media="only screen and (orientation: portrait)" href="/portrait.css">
<link rel="stylesheet"
media="only screen and (orientation: landscape)” href="/landscape.css">
Remove the address and status bars, top and bottom
To give you more room on-screen and to make your site feel more like an immersive web app, you can place the following declaration into the <head> of your document’s code to remove the address and status bars at the top and bottom of the screen.
<meta name="apple-mobile-web-app-capable" content="yes" />
Making the most of inbuilt functions
Similar to mailto: e-mail links, the iPhone also supports another two handy URI schemes which are great for enhancing contact details. When tapped, the following links will automatically bring up the appropriate call or text interface:
<a href="tel:01234567890">Call us</a>
<a href="sms:01234567890">Text us</a>
iPhone-specific Web Clip icon
Although I believe them to be fundamentally flawed, since they rely on the user bookmarking your site, iPhone Web Clip icons are still a nice touch. You need just two declarations, again in the <head> of your document:
<link rel="apple-touch-icon" href="icons/regular_icon.png" />
<link rel="apple-touch-icon" sizes="114x114" href="icons/retina_icon.png" />
For iPhone 4 you’ll need to create a 114 × 114 pixels icon; for a non-Retina display, a 57 × 57 pixels icon will do the trick.
Precomposed
Apple adds its standard gloss ‘moon’ over the top of any icon. If you feel this might be too much for your particular icon and would prefer a matte finish, you can add precomposed to the end of the apple-touch-icon declaration to remove the standard gloss.
<link rel="apple-touch-icon-precomposed" href="/images/touch-icon.png" />
Wrapping up
Media queries definitely have their uses. They make it easy to build a custom experience for your visitor, regardless of their browser’s size. For more complex sites, however, or where you have lots of imagery and other content that isn’t necessary on the mobile version, you can now use these other methods to help you out. Remember, they are purely for presentation and not optimisation; for busy people on the go, optimisation and faster-running mobile experiences can only be a good thing.
Have a wonderful Christmas fellow Webbies!
december 2010 by cloudseer
Four short links: 13 December 2010
december 2010 by cloudseer
European mobile operators say big sites need to pay for users' data demands (Guardian) -- it's like the postal service demanding that envelope makers pay them because they're not making enough money just selling stamps. What idiocy.
Grace Programming Language -- language designers working on a new teaching language.
Gawker Media's Entire Database Hacked -- 1.5M usernames and passwords, plus content from their databases, in a torrent. What's your plan to minimize the harm of an event like this, and to recover? (via Andy Baio)
Macmillan Do Interesting Stuff (Cameron Neylon) -- have acquired some companies that provide software tools to support scientists, and are starting a new line of business around it. I like it because it's a much closer alignment of scientists' interests with profit motive than, say, journals. Timo Hannay, who heads it, runs Science Foo Camp with Google and O'Reilly.
broadband
business
design
language
mobile
nature
netneutrality
science
scifoo
security
shared
from google
Grace Programming Language -- language designers working on a new teaching language.
Gawker Media's Entire Database Hacked -- 1.5M usernames and passwords, plus content from their databases, in a torrent. What's your plan to minimize the harm of an event like this, and to recover? (via Andy Baio)
Macmillan Do Interesting Stuff (Cameron Neylon) -- have acquired some companies that provide software tools to support scientists, and are starting a new line of business around it. I like it because it's a much closer alignment of scientists' interests with profit motive than, say, journals. Timo Hannay, who heads it, runs Science Foo Camp with Google and O'Reilly.
december 2010 by cloudseer
One web
december 2010 by cloudseer
I was in Dublin recently to give a little talk at the 24 Hour Universal Design Challenge 2010. It was an interesting opportunity to present my own perspective on web design to an audience that consisted not just of web designers, but designers from many different fields.
I gave an overview of the past, present and future of web design as seen from where I’m standing. You can take a look at the slides but my usual caveat applies: they won’t make much sense out of context. There is, however, a transcript of the talk on the way (the whole thing was being captioned live on the day).
Towards the end of my spiel, I pointed to Tim Berners-Lee’s recent excellent article in Scientific American, Long Live the Web: A Call for Continued Open Standards and Neutrality:
The primary design principle underlying the Web’s usefulness and growth is universality. When you make a link, you can link to anything. That means people must be able to put anything on the Web, no matter what computer they have, software they use or human language they speak and regardless of whether they have a wired or wireless Internet connection. The Web should be usable by people with disabilities. It must work with any form of information, be it a document or a point of data, and information of any quality—from a silly tweet to a scholarly paper. And it should be accessible from any kind of hardware that can connect to the Internet: stationary or mobile, small screen or large.
We’re at an interesting crossroads right now. Recent developments in areas like performance and responsive design means that we can realistically pursue that vision of serving up content at a URL to everyone to the best ability of their device. At the same time, the opposite approach—creating multiple, tailored URLs—is currently a popular technique.
At the most egregious and nefarious end of the spectrum, there’s Google’s disgusting backtracking on net neutrality which hinges on a central conceit that spits in the face of universality:
…we both recognize that wireless broadband is different from the traditional wireline world, in part because the mobile marketplace is more competitive and changing rapidly. In recognition of the still-nascent nature of the wireless broadband marketplace, under this proposal we would not now apply most of the wireline principles to wireless…
That’s the fat end of the wedge: literally having a different set of rules for one group of users based on something as arbitrary as how they are connecting to the network.
Meanwhile, over on the thin end of the wedge, there’s the fashion for serving up the same content at different URLs to different devices (often segregated within a subdomain like m. or mobile.—still better than the crack-smoking-inspired .mobi idea).
It’s not a bad technique at all, and it has served the web reasonably well as we collectively try to get our heads around the expanded browser and device landscape of recent years …although some of us cringe at the inherent reliance on browser-sniffing. At least the best practice in this area is to always offer a link back to the “regular” site.
Still, although the practice of splintering up the same content to separate URLs and devices has been a useful interim step, it just doesn’t scale. It’s also unnecessary.
Most of the time, creating a separate mobile website is simply a cop-out.
Hear me out.
First of all, I said “most of the time.” Maybe Garrett is onto something when he says:
It seems responsive pages are best for content while dedicated mobile pages are best for interactive applications. Discuss.
Although, as I pointed out in my brief list of false dichotomies, there’s no clear delineation between documents and applications (just as there’s no longer any clear delineation between desktop and mobile).
Still, let’s assume we’re talking about content-based sites. Segregating the same content into different URLs seems like a lot of work (quite apart from violating the principle of universality) if all you’re going to do is remove some crud that isn’t necessary in the first place.
As an example, here’s an article from The Guardian’s mobile site and here’s the same article as served up on the www. subdomain.
Leaving aside the way that the width is inexplicably set to a fixed number of pixels, it’s a really well-executed mobile site. The core content is presented very nicely. The cruft is gone.
But then, if that cruft is unnecessary, why serve it up on the “desktop” version? I can see how it might seem like a waste not to use extra screen space and bandwidth if it’s available, but I’d love see an approach that’s truly based on progressive enhancement. Begin with the basic content; structure it to best fit the screen using media queries or some other form of feature detection (not browser detection); pull in extra content for large-screen user-agents, perhaps using some form of lazy loading. To put it in semantic terms, if the content could be marked up as an aside, it may be a prime candidate for lazy loading based on device capability:
The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content.
I’m being unfair on The Guardian site …and most content-based sites with a similar strategy. Almost every site that has an accompanying mobile version—Twitter, Flickr, Wikipedia, BBC—began life when the desktop was very much in the ascendency. If those sites were being built today, they might well choose a more responsive, scalable solution.
It’s very, very hard to change an entire existing site. There’s a lot of inertia to battle against. Also, let’s face it: most design processes are not suited to solving problems in a device-independent, content-out way. It’s going to be challenging for large organisations to adjust to this way of thinking. It’s going to be equally challenging for agencies to sell this approach to clients—although I feel Clearleft may have a bit of an advantage in having designers like Paul who really get it. I think a lot of the innovation in this area will come from more nimble quarters: personal projects and small startups, most likely.
37 Signals recently documented some of their experiments with responsive design. As it turned out, they had a relatively easy time of it because they were already using a flexible approach to layout:
The key to making it easy was that the layout was already liquid, so optimizing it for small screens meant collapsing a few margins to maximize space and tweaking the sidebar layout in the cases where the screen is too narrow to show two columns.
In the comments, James Pearce, who is not a fan of responsiveness, was quick to cry foul:
I think you should stress that building a good mobile site or app probably takes more effort than flowing a desktop page onto a narrower piece of glass. The mobile user on the other side will quite possibly want to do different things to their desktop brethren, and deserves more than some pixel shuffling.
But the very next comment gets to the heart of why this well-intentioned approach can be so destructive:
A lot of mobile sites I’ve seen are dumbed down versions of the full thing, which is really annoying when you find that the feature you want isn’t there. The design here is the same site adapted to different screens, meaning the end product doesn’t lose any functionality. I think this is much better than making decisions for your users as to what they will and won’t want to see on their mobile phone.
I concur. I think there’s a real danger in attempting to do the right thing by denying users access to content and functionality “for their own good.” It’s patronising and condescending to assume you know the wants and needs of a visitor to your site based purely on their device.
The most commonly-heard criticism of serving up the same website to everyone is that the existing pages are too large, either in size or content. I agree. Far too many URLs resolve to bloated pages locked to a single-width layout. But the solution is not to make leaner, faster pages just for mobile users; the answer is to make leaner, faster pages for everybody.
Even the brilliant Bryan Rieger, who is doing some of the best responsive web design work on the planet with the Yiibu site, still talks about optimising only for certain users in his otherwise-excellent presentation, The End of Unlimited Bandwidth.
When I was reading the W3C’s Mobile Web Best Practices, I was struck by how much of it is sensible advice for web development in general, rather than web development specifically for mobile.
This is why I’m saying that most of the time, creating a separate mobile website is simply a cop-out. It’s a tacit acknowledgement that the regular “desktop” site is beyond help. The cop-out is creating an optimised experience for one subset of users while abandoning others to their bloated fate.
A few years back, there was a trend to provide separate text-only “accessible” websites, effectively ghettoising some users. Nowadays, it’s clear that universal design is a more inclusive, more maintainable approach. I hope that the current ghettoisation of mobile users will also end.
I’m with Team Timbo. One web.
Tagged with
mobile
responsive
design
performance
oneweb
accessibility
mobile
responsive
design
performance
oneweb
accessibility
shared
from google
I gave an overview of the past, present and future of web design as seen from where I’m standing. You can take a look at the slides but my usual caveat applies: they won’t make much sense out of context. There is, however, a transcript of the talk on the way (the whole thing was being captioned live on the day).
Towards the end of my spiel, I pointed to Tim Berners-Lee’s recent excellent article in Scientific American, Long Live the Web: A Call for Continued Open Standards and Neutrality:
The primary design principle underlying the Web’s usefulness and growth is universality. When you make a link, you can link to anything. That means people must be able to put anything on the Web, no matter what computer they have, software they use or human language they speak and regardless of whether they have a wired or wireless Internet connection. The Web should be usable by people with disabilities. It must work with any form of information, be it a document or a point of data, and information of any quality—from a silly tweet to a scholarly paper. And it should be accessible from any kind of hardware that can connect to the Internet: stationary or mobile, small screen or large.
We’re at an interesting crossroads right now. Recent developments in areas like performance and responsive design means that we can realistically pursue that vision of serving up content at a URL to everyone to the best ability of their device. At the same time, the opposite approach—creating multiple, tailored URLs—is currently a popular technique.
At the most egregious and nefarious end of the spectrum, there’s Google’s disgusting backtracking on net neutrality which hinges on a central conceit that spits in the face of universality:
…we both recognize that wireless broadband is different from the traditional wireline world, in part because the mobile marketplace is more competitive and changing rapidly. In recognition of the still-nascent nature of the wireless broadband marketplace, under this proposal we would not now apply most of the wireline principles to wireless…
That’s the fat end of the wedge: literally having a different set of rules for one group of users based on something as arbitrary as how they are connecting to the network.
Meanwhile, over on the thin end of the wedge, there’s the fashion for serving up the same content at different URLs to different devices (often segregated within a subdomain like m. or mobile.—still better than the crack-smoking-inspired .mobi idea).
It’s not a bad technique at all, and it has served the web reasonably well as we collectively try to get our heads around the expanded browser and device landscape of recent years …although some of us cringe at the inherent reliance on browser-sniffing. At least the best practice in this area is to always offer a link back to the “regular” site.
Still, although the practice of splintering up the same content to separate URLs and devices has been a useful interim step, it just doesn’t scale. It’s also unnecessary.
Most of the time, creating a separate mobile website is simply a cop-out.
Hear me out.
First of all, I said “most of the time.” Maybe Garrett is onto something when he says:
It seems responsive pages are best for content while dedicated mobile pages are best for interactive applications. Discuss.
Although, as I pointed out in my brief list of false dichotomies, there’s no clear delineation between documents and applications (just as there’s no longer any clear delineation between desktop and mobile).
Still, let’s assume we’re talking about content-based sites. Segregating the same content into different URLs seems like a lot of work (quite apart from violating the principle of universality) if all you’re going to do is remove some crud that isn’t necessary in the first place.
As an example, here’s an article from The Guardian’s mobile site and here’s the same article as served up on the www. subdomain.
Leaving aside the way that the width is inexplicably set to a fixed number of pixels, it’s a really well-executed mobile site. The core content is presented very nicely. The cruft is gone.
But then, if that cruft is unnecessary, why serve it up on the “desktop” version? I can see how it might seem like a waste not to use extra screen space and bandwidth if it’s available, but I’d love see an approach that’s truly based on progressive enhancement. Begin with the basic content; structure it to best fit the screen using media queries or some other form of feature detection (not browser detection); pull in extra content for large-screen user-agents, perhaps using some form of lazy loading. To put it in semantic terms, if the content could be marked up as an aside, it may be a prime candidate for lazy loading based on device capability:
The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content.
I’m being unfair on The Guardian site …and most content-based sites with a similar strategy. Almost every site that has an accompanying mobile version—Twitter, Flickr, Wikipedia, BBC—began life when the desktop was very much in the ascendency. If those sites were being built today, they might well choose a more responsive, scalable solution.
It’s very, very hard to change an entire existing site. There’s a lot of inertia to battle against. Also, let’s face it: most design processes are not suited to solving problems in a device-independent, content-out way. It’s going to be challenging for large organisations to adjust to this way of thinking. It’s going to be equally challenging for agencies to sell this approach to clients—although I feel Clearleft may have a bit of an advantage in having designers like Paul who really get it. I think a lot of the innovation in this area will come from more nimble quarters: personal projects and small startups, most likely.
37 Signals recently documented some of their experiments with responsive design. As it turned out, they had a relatively easy time of it because they were already using a flexible approach to layout:
The key to making it easy was that the layout was already liquid, so optimizing it for small screens meant collapsing a few margins to maximize space and tweaking the sidebar layout in the cases where the screen is too narrow to show two columns.
In the comments, James Pearce, who is not a fan of responsiveness, was quick to cry foul:
I think you should stress that building a good mobile site or app probably takes more effort than flowing a desktop page onto a narrower piece of glass. The mobile user on the other side will quite possibly want to do different things to their desktop brethren, and deserves more than some pixel shuffling.
But the very next comment gets to the heart of why this well-intentioned approach can be so destructive:
A lot of mobile sites I’ve seen are dumbed down versions of the full thing, which is really annoying when you find that the feature you want isn’t there. The design here is the same site adapted to different screens, meaning the end product doesn’t lose any functionality. I think this is much better than making decisions for your users as to what they will and won’t want to see on their mobile phone.
I concur. I think there’s a real danger in attempting to do the right thing by denying users access to content and functionality “for their own good.” It’s patronising and condescending to assume you know the wants and needs of a visitor to your site based purely on their device.
The most commonly-heard criticism of serving up the same website to everyone is that the existing pages are too large, either in size or content. I agree. Far too many URLs resolve to bloated pages locked to a single-width layout. But the solution is not to make leaner, faster pages just for mobile users; the answer is to make leaner, faster pages for everybody.
Even the brilliant Bryan Rieger, who is doing some of the best responsive web design work on the planet with the Yiibu site, still talks about optimising only for certain users in his otherwise-excellent presentation, The End of Unlimited Bandwidth.
When I was reading the W3C’s Mobile Web Best Practices, I was struck by how much of it is sensible advice for web development in general, rather than web development specifically for mobile.
This is why I’m saying that most of the time, creating a separate mobile website is simply a cop-out. It’s a tacit acknowledgement that the regular “desktop” site is beyond help. The cop-out is creating an optimised experience for one subset of users while abandoning others to their bloated fate.
A few years back, there was a trend to provide separate text-only “accessible” websites, effectively ghettoising some users. Nowadays, it’s clear that universal design is a more inclusive, more maintainable approach. I hope that the current ghettoisation of mobile users will also end.
I’m with Team Timbo. One web.
Tagged with
mobile
responsive
design
performance
oneweb
accessibility
december 2010 by cloudseer
Anatomy of an ebook app
november 2010 by cloudseer
A week ago, we received a pleasant surprise. Apple had featured our ebook, "Rabbit and Turtle's Amazing Race" in the iTunes App Store. The publicity came with an immediate 3-5X pop in paid downloads of our book, pushing it to the #12 Top Grossing Book for iPad.
"Rabbit and Turtle's Amazing Race" is a children's rhyming book with illustrations, quirky interactions and sound. It's "pop-up book meets the iPad." That's the design goal, at least.
I would love to tell you that building a book was a straight path from concept to storyboard to launch and inevitable success. The truth, however, is a bit more complicated.
In the paragraphs ahead, I will try to give you a sense of how we built our book, the mistakes we made, the discoveries, course corrections, and how it all worked out for us. If I miss something integral to you, please follow up in the comments.
Fragmentation lives: Building for iPhone, iPod Touch and iPad
At my company, Unicorn Labs, we have now built 13 apps for Apple's iOS Platform. Eight of them are optimized for the iPhone and iPod Touch. Five are built for iPad.
From a technical perspective, I can say that developing for the platform is not a simple matter of write once, run everywhere.
That is not to say that the experience building iOS Apps and plugging into the iTunes App Store has been unfavorable. Quite the opposite. I am very proud of the productivity that we have realized, the global, automated reach and distribution that we have been afforded, and the goodness of frictionless billing/payment.
But, I would be less than intellectually honest, and strategically dumb, if I failed to underline that that matrix that I talked about here is upon us.
One small example of this is that the newest version of the platform is iOS 4.x. The new OS gives you some wonderful capabilities, such as video capture services, multi-tasking and of course, taking advantage of functionality like Retina display on iPhone 4 and the new camera on Gen 3 iPod touch. Simply put, it is a case of a really solid system just getting better. Don't even get me started on how experientially enhancing iOS 4.2 is on iPad.
However, the point is this: once you call certain functions or use certain libraries that iOS 4 gives you access to, you pretty much no longer will run on iOS 3.x devices.
While this issue will be resolved later this month when Apple rolls out it's unification release for iOS across all devices (the aforementioned 4.2), the other truth is there's now a feature matrix that one can access as a developer to varying degrees, such as camera, telephony, video capture, audio, and photos.
Deciding which of these functions to use, abstract or ignore exposes you (as a developer) to all sorts of reach, performance and support complexity challenges and tradeoffs.
Moreover, in building our family of apps, we have leveraged two different development platforms that are complementary to Cocoa Touch. They are Ansca's Corona and the Cocos2d middleware. Even here, actions like plugging into Facebook and interfacing with native Cocoa Touch functions are slightly different in each of these realms.
Android devotees, I hear you snickering. Before you do so, know that these complexities are materially worse in the Android world, where not only do you have to contend with these same challenges across far more device types, but also the meta-platform "forking" decisions of different handset makers and carriers.
Nothing is free, but the cost is relative to not hopping aboard the greatest rocket ship ride since the advent of the web, and the rise of the PC before that. The apps lifestyle -- aka "There's an app for that" --- is the real deal. The mobile age is upon us.
What exactly is an ebook, anyway?
I have written in the past about where I think ebooks are headed ("Rebooting the book"), but the essence is this.
The advent of sound in motion pictures transformed not only how films were made, but what they were and the economics behind same. This is the rapidly approaching future for the book business and print media in general.
The current state of the ebook business is nominally better than a PDF stuffed into a bookish-sized reader. Think: Amazon's Kindle. It's mostly text, devoid of sound and/or interaction.
By contrast, in iOS an ebook is an app, and there are few limits to what an app can do. Touch, interact, be read to, savor high-definition art and stereophonic ambient sounds and special effects.
"Rabbit and Turtle's Amazing Race" was built in Corona, and we're happy with the decision. Our next book, scheduled for release in time for Christmas, is also built using Corona. In fact, the Play-Doh-like qualities of Corona enabled us to almost simultaneously come out with both full (paid) and lite (free) versions of the book on both the iPad and iPhone/iPod Touch.
Finally, a non-trivial benefit of Corona is the fact that porting to Google's Android is straight-forward, closer to a compile option than a re-architecting.
As noted earlier, we looked conceptually to the pop-up books from our youth for inspiration in cobbling together a book that has a solid story (a re-envisioning of the "Tortoise and Hare" fable) but is also packed with lots of cool sounds and visual interactions.
Now that I built it, will they come?
Here's the rub. The App Store model is hugely competitive. It's got around 300,000 apps, and the ease of development and distribution means that clone versions of your app are coming.
Worse, pick the wrong category, and your chances of being discovered by your target audience get lower.
For example, the Games and Entertainment categories are fiercely competitive. Choose Photo instead. Many iPhone categories are seemingly saturated. Their iPad counterparts are in an earlier stage in the product innovation lifecycle, albeit targeting to a much smaller base than the combined base of iPhones and iPod touches.
So how do we approach this from a go-to-market perspective? For one, we committed to iterating the book. Over a few different releases, we added new features, fixed bugs, and generally improved the product based upon user feedback and proactively monitoring usage data.
This turns updates into pseudo marketing events. And who doesn't like a solution provider that is committed to making their products better for its users?
The idea of marketing events brings to mind the indelible truth that with apps, the initial launch date is such a significant milestone that there's a tendency to underplay events like product updates and market validation news. Don't fall for that trap.
Similarly, we baked social sharing into all of our products. We live the medium by Facebooking, blogging, micro-posting, and tweeting. It's the ultimate drip marketing methodology.
We also assembled a media list and reached out to the folks that we hope will be advocates for our products. We customized, tweaked and tested messages and media kits. Obviously, the product has to deliver.
Finally, We approach app building like a shark that has to keep moving to keep alive. It's exhausting and exhilarating at the same time.
Related:
Rebooting the Book (One Apple iPad Tablet at a Time)
Apple, the Boomer Tablet and the Matrix
Apple's segmentation strategy, and the folly of conventional wisdom
iPhone economics and lower barriers to entry
The expanding influence of apps and mobile
Mobile
Publishing
apple
apps
ebooks
ipad
shared
from google
"Rabbit and Turtle's Amazing Race" is a children's rhyming book with illustrations, quirky interactions and sound. It's "pop-up book meets the iPad." That's the design goal, at least.
I would love to tell you that building a book was a straight path from concept to storyboard to launch and inevitable success. The truth, however, is a bit more complicated.
In the paragraphs ahead, I will try to give you a sense of how we built our book, the mistakes we made, the discoveries, course corrections, and how it all worked out for us. If I miss something integral to you, please follow up in the comments.
Fragmentation lives: Building for iPhone, iPod Touch and iPad
At my company, Unicorn Labs, we have now built 13 apps for Apple's iOS Platform. Eight of them are optimized for the iPhone and iPod Touch. Five are built for iPad.
From a technical perspective, I can say that developing for the platform is not a simple matter of write once, run everywhere.
That is not to say that the experience building iOS Apps and plugging into the iTunes App Store has been unfavorable. Quite the opposite. I am very proud of the productivity that we have realized, the global, automated reach and distribution that we have been afforded, and the goodness of frictionless billing/payment.
But, I would be less than intellectually honest, and strategically dumb, if I failed to underline that that matrix that I talked about here is upon us.
One small example of this is that the newest version of the platform is iOS 4.x. The new OS gives you some wonderful capabilities, such as video capture services, multi-tasking and of course, taking advantage of functionality like Retina display on iPhone 4 and the new camera on Gen 3 iPod touch. Simply put, it is a case of a really solid system just getting better. Don't even get me started on how experientially enhancing iOS 4.2 is on iPad.
However, the point is this: once you call certain functions or use certain libraries that iOS 4 gives you access to, you pretty much no longer will run on iOS 3.x devices.
While this issue will be resolved later this month when Apple rolls out it's unification release for iOS across all devices (the aforementioned 4.2), the other truth is there's now a feature matrix that one can access as a developer to varying degrees, such as camera, telephony, video capture, audio, and photos.
Deciding which of these functions to use, abstract or ignore exposes you (as a developer) to all sorts of reach, performance and support complexity challenges and tradeoffs.
Moreover, in building our family of apps, we have leveraged two different development platforms that are complementary to Cocoa Touch. They are Ansca's Corona and the Cocos2d middleware. Even here, actions like plugging into Facebook and interfacing with native Cocoa Touch functions are slightly different in each of these realms.
Android devotees, I hear you snickering. Before you do so, know that these complexities are materially worse in the Android world, where not only do you have to contend with these same challenges across far more device types, but also the meta-platform "forking" decisions of different handset makers and carriers.
Nothing is free, but the cost is relative to not hopping aboard the greatest rocket ship ride since the advent of the web, and the rise of the PC before that. The apps lifestyle -- aka "There's an app for that" --- is the real deal. The mobile age is upon us.
What exactly is an ebook, anyway?
I have written in the past about where I think ebooks are headed ("Rebooting the book"), but the essence is this.
The advent of sound in motion pictures transformed not only how films were made, but what they were and the economics behind same. This is the rapidly approaching future for the book business and print media in general.
The current state of the ebook business is nominally better than a PDF stuffed into a bookish-sized reader. Think: Amazon's Kindle. It's mostly text, devoid of sound and/or interaction.
By contrast, in iOS an ebook is an app, and there are few limits to what an app can do. Touch, interact, be read to, savor high-definition art and stereophonic ambient sounds and special effects.
"Rabbit and Turtle's Amazing Race" was built in Corona, and we're happy with the decision. Our next book, scheduled for release in time for Christmas, is also built using Corona. In fact, the Play-Doh-like qualities of Corona enabled us to almost simultaneously come out with both full (paid) and lite (free) versions of the book on both the iPad and iPhone/iPod Touch.
Finally, a non-trivial benefit of Corona is the fact that porting to Google's Android is straight-forward, closer to a compile option than a re-architecting.
As noted earlier, we looked conceptually to the pop-up books from our youth for inspiration in cobbling together a book that has a solid story (a re-envisioning of the "Tortoise and Hare" fable) but is also packed with lots of cool sounds and visual interactions.
Now that I built it, will they come?
Here's the rub. The App Store model is hugely competitive. It's got around 300,000 apps, and the ease of development and distribution means that clone versions of your app are coming.
Worse, pick the wrong category, and your chances of being discovered by your target audience get lower.
For example, the Games and Entertainment categories are fiercely competitive. Choose Photo instead. Many iPhone categories are seemingly saturated. Their iPad counterparts are in an earlier stage in the product innovation lifecycle, albeit targeting to a much smaller base than the combined base of iPhones and iPod touches.
So how do we approach this from a go-to-market perspective? For one, we committed to iterating the book. Over a few different releases, we added new features, fixed bugs, and generally improved the product based upon user feedback and proactively monitoring usage data.
This turns updates into pseudo marketing events. And who doesn't like a solution provider that is committed to making their products better for its users?
The idea of marketing events brings to mind the indelible truth that with apps, the initial launch date is such a significant milestone that there's a tendency to underplay events like product updates and market validation news. Don't fall for that trap.
Similarly, we baked social sharing into all of our products. We live the medium by Facebooking, blogging, micro-posting, and tweeting. It's the ultimate drip marketing methodology.
We also assembled a media list and reached out to the folks that we hope will be advocates for our products. We customized, tweaked and tested messages and media kits. Obviously, the product has to deliver.
Finally, We approach app building like a shark that has to keep moving to keep alive. It's exhausting and exhilarating at the same time.
Related:
Rebooting the Book (One Apple iPad Tablet at a Time)
Apple, the Boomer Tablet and the Matrix
Apple's segmentation strategy, and the folly of conventional wisdom
iPhone economics and lower barriers to entry
The expanding influence of apps and mobile
november 2010 by cloudseer
We're about to scratch the real-world data itch
march 2010 by cloudseer
Since virtually all of my work is done on the web, I've grown accustomed to granular information. Even a casual look at web traffic reveals insight. I can see the topics that strike a nerve with visitors. I can pick out new or unusual traffic sources. I can even see how usability and design influence click-throughs.
Yet, all that goes away in the real world. My parents, for example, have owned the same retail store in the same location for more than 20 years. They have strong relationships with regular customers and they're committed to their local community. Despite all this experience, many of their decisions are still based on hunches. They don't have much data and their feedback mechanisms are limited to word of mouth and occasional coupon campaigns.
But what if my parents -- or any small business owner, for that matter -- could gather hard data that showed foot traffic broken down by months, weeks, days and times? What if they could experiment with product display hot spots and analyze the sales results? What if they could entice customers back to their store with customized offers?
Mobile location services may soon make this sort of real-world analytics possible -- and not just for the big guys. Foursquare, which we recently profiled here on Radar, is already rolling out an analytics dashboard that will give business owners data about the people who check in to their establishments. That's a huge first step, and I imagine other location services will follow suit with their own analytics packages. Within a year -- maybe even six months -- we'll see a lot more discussion around local SEO and mobile-based social search. And I won't be surprised at all if mobile bar code/image scanners transform from fun fringe apps to core functionality, especially if associated data can be harnessed and analyzed. Put all this together and it feels like we're on the verge of finally scratching that real-world data itch.
analytics
location
mobile
shared
from google
Yet, all that goes away in the real world. My parents, for example, have owned the same retail store in the same location for more than 20 years. They have strong relationships with regular customers and they're committed to their local community. Despite all this experience, many of their decisions are still based on hunches. They don't have much data and their feedback mechanisms are limited to word of mouth and occasional coupon campaigns.
But what if my parents -- or any small business owner, for that matter -- could gather hard data that showed foot traffic broken down by months, weeks, days and times? What if they could experiment with product display hot spots and analyze the sales results? What if they could entice customers back to their store with customized offers?
Mobile location services may soon make this sort of real-world analytics possible -- and not just for the big guys. Foursquare, which we recently profiled here on Radar, is already rolling out an analytics dashboard that will give business owners data about the people who check in to their establishments. That's a huge first step, and I imagine other location services will follow suit with their own analytics packages. Within a year -- maybe even six months -- we'll see a lot more discussion around local SEO and mobile-based social search. And I won't be surprised at all if mobile bar code/image scanners transform from fun fringe apps to core functionality, especially if associated data can be harnessed and analyzed. Put all this together and it feels like we're on the verge of finally scratching that real-world data itch.
march 2010 by cloudseer
Copy this bookmark: