For this last one on mobile websites and web apps, we’ll take a look at a brilliant technique for making your website functional for both the desktop and the web. We’ve already seen one solution for offering a different experience: OpenMktApp’s redirect to their “install” page for first-time iOS visitors. Now we’ll look at a more elegant solution. And coming later this month in the mobile design series, we’ll take a look at some of the design principles behind doing this.

Since iOS devices all run WebKit, they’re all quite advanced when it comes to the CSS they’re able to parse. This includes, as we’ve previously seen, the media declaration in a <link> tag for a CSS file, but also includes CSS3’s @media declaration inside a CSS file. The primary purpose for this would be to adjust for the vastly different widths we have (we can even adjust for varying widths on desktop browsers, too), but we can also use it to do other fun stuff.

Take a peek at one example of changing the display of a site based on width on Simon Collison’s website, Colly. If your viewport is set to ~950px or greater, we have the full-width, four-column layout. However, as you shrink your viewport down, the layout changes to a two-column display, then finally to a one-column display where the single item is slightly larger in width than the single items are in the two- or four-column views. All-in-all, a rather lovely design. And the whole “Celebrated Miscellany” idea produces a fascinating aesthetic. It reminds this writer of an old science journal, like something Darwin or Audubon might have drawn.

So how do we do it? Well, Colly uses a series of @media rules at the very end of his stylesheet. Here’s one of the bits we’re talking about (edited for brevity):
@media (min-device-width:1024px) and (max-width:989px), screen and (max-device-width:480px), (max-device-width:480px) and (orientation:landscape), (min-device-width:481px) and (max-device-width:1024px) and (orientation:portrait) { div#page { width:468px; } .home ul#navigation_pri, .home ul#subnav-b { padding-bottom:30px; } … div#siteinfo p { font-size:14px; } }
So what’s happening there? well, all of the CSS rules for this particular @media query are encapsulated in the query itself. The query is asking a number of different questions to cover quite a few bases, but this particular set of CSS covers the “less than 950px viewport” eventuality. As for mobile devices, this view comes into play if an iPhone is in landscape mode, or if an iPad is in portrait mode.

The second @media query looks like this:
@media (min-device-width:1024px) and (max-width:509px), (max-device-width:480px) and (orientation:portrait) { div#page { padding:30px 0px 10px 0px; width:306px; } … }
It’s considerably simpler, as it doesn’t have to ask as many questions about your viewport or device width. The first part of the query takes care of iPads and desktops alike, while the second handles the smaller display devices.

So there you have it folks, the ability to craft resolution dependent layouts and styles. Now go forth and amaze your clients!

We’re going to take a break from JS frameworks to look at an interesting site / web app that came across the radar recently: OpenAppMkt. You’ll want to check it out both on your desktop as well as on your iOS device, as each has a completely different interface. On the desktop, you’ll immediately begin browsing the site’s collection of web apps, but on iPhone, you’ll be asked to add it to your home screen, and you’ll get to see a pretty decent web app first hand!

This is a great idea, and it really drives home the idea that web apps can augment, or even supercede, native applications in some ways. If you load it up in desktop Safari with the user agent manually set to MobileSafari (via the Developer menu), you can actually see that they’re using jQTouch, which was mentioned in a previous post.

It is worth noting that, true to the “β” (“beta”) character after the name, the site is still very much a work in progress. This is best exemplified by the jerky scrolling, and somewhat jerky animations. This could be due to jQTouch’s work-in-progress nature, or OpenAppMkt’s modifications to the jQTouch code (if any).

Moving on to what the app can do, though: they’ve utilized a very interesting mechanism to enable you to “install” the web apps directly from their interface. When you click install, a new window loads, still at OpenAppMkt, then instructs you to “add to home screen.” When you do that, OpenAppMkt grabs the home screen icon and name of the app you’re trying to “install,” and sets that. Now, when you go to load that app, it briefly heads to OpenAppMkt, then proceeds onward to the actual web app itself. While this does add a layer of abstraction, it increases the visibility of “installing” web apps, if you will, by adding them to the home screen, which is definitely a good thing.

Not only that, but their greater goal seems to be to build a clearinghouse for web apps, similar to Apple’s own Web Apps directory, but with reviews and ratings. Creating this sort of community for these apps only improves their visibility and usefulness. Hopefully OpenAppMkt is here to stay!

Continuing on our trek through the JavaScript frameworks that can improve your web app users’ experiences, we come to jQTouch. jQTouch is a little different from the other frameworks we’ve looked at, primarily because it relies on the jQuery JavaScript library, which is one of the most popular JS libraries out there. This does, however, add some weight to any web app using jQTouch, so be aware that this may negatively affect load times and user experience.

Still, the familiarity most developers have with jQuery, combined with the polish of this framework/plugin, makes it a very attractive option for any web developer. Let’s take a peek at what it can do. It uses native WebKit animations, it can preload images, has a variety of themes built in to it (and you can easily make more using SASS), and has not just the usual JS CallbackEvents, but can also respond to a variety of touch events! Now that is very cool.

As an example, here’s how easy it is to replace a standard click with jQTouch’s custom tap event:
$(function(){ $('#tapme').tap( function(e){ console.log('Tapped!'); }); });
Now that is just brilliant. A “swipe” CallbackEvent is also under development. As of now, it appears to be hit-or-miss, but it’s in there.

If you want to explore some of what jQTouch can do, head on over to the demo on your iPhone. Bear in mind that as useful as this is, its definitely still under heavy development; as it is, the most recent commit to the github repository was July 21, so things are definitely still active.

If you want to explore the code, head on over to the aforementioned github repository. Cheers!

In the same vein as the previous article on PastryKit, we’re going to take a look at another web app framework, iUI, that can help you more easily develop a far richer experience for your users. iUI was developed by Joe Hewitt, the same man behind FireBug, which gives Firefox the ability to inspect web pages (similar to Safari’s Web Inspector).

Previously, we talked about PastryKit, which adds native-like scrolling, hides the browser toolbar, and provides static navigation/control elements. iUI seeks to do more, offering these features:

• Creates Navigational Menus and iPhone-style interfaces from standard HTML
• Does not required use or knowledge of JavaScript to create modern mobile web pages
• Abi handle phone orientation changes
• Provide a more “iPhone-like” experience in your Web apps

It should be noted that Digg.com uses an early version of iUI, called “iphonenav” for its interface. Quite an endorsement! As for what’s going on, you should head over to this URL on your iPhone:

http://www.iui-js.org/samples/digg/

There you’ll find an updated, miniature version of Digg, used as a demo for iUI. You’ll notice that it has a “Get 10 More Stories…” link at the bottom, which dynamically loads more stories, working in a similar manner as the Mail app on iOS. In addition, tapping on a story, instead of load a whole new page, merely slides right to show you the content, after a brief pause to load it. Some very lovely AJAX happening here.

It should be noted, however, that the scrolling is the default Safari scrolling, not the juiced-up version that PastryKit offers. Still, if you keep your lists short using the “load x more” link like the Digg example, that may be a non-issue.

One last thing to note is how iUI handles changes in orientation. While it’s not baby smooth, it does redraw elements, which may allow you to create a far more pleasant experience on the whole, even though a slight delay occasionally occurs when changing orientation. Try it out with that Digg example.

There’s a few more features, but you can read more about it over at Joe’s Introducing iUI post. Enjoy!

One of the things about a web app that really sets it off as not being native is the scroll behavior. On a native app, when you slide or flick to scroll the viewport, iOS detects this and grants inertia and speed based on your finger movement. And, like in the real world, “friction” occurs and slows the scroll movement until it either stops, or hits the end.

In MobileSafari, and, by extension, in any web app (yes, even those that run in their own instance), things operate on a different, much more direct scheme. There’s almost no inertia, faster flicks does not impart greater speed, and if you reach the bottom of the page, it will pull away from the bottom bar or bottom of the screen. Thankfully though, we can correct for this with some brilliant JavaScript.

Now, while we could go about setting these things up manually, there are a few great JavaScript frameworks that can help us accomplish all this with a minimum of fuss. We’ll only be looking at one framework today, and only at the surface level, but we’ll be pointing out some of the best resources to go further.

That framework is PastryKit, which is Apple’s own web app framework. There isn’t any official documentation on it from Apple, but other developers have beautified the originally published, minified code, pulled it apart into its component modules, and begun to figure it out. If you want to see it in action, you can either head over to John Gruber’s Daring Fireball article about it, or open up the iPhone User Guide on your iPhone; it’s one of the default bookmarks.

Here are a few links to get you on the right track with using PastryKit:

• “PastryKit: digging into an Apple Pie”: This is one of the first articles to take PastryKit apart, beautify it, separate it out into its components, and its a great place to start.
• “Pastry Kit – Apple’s iPhone JS Library”: This article should definitely be your next stop, as it includes a copy of the entire assets collection for the entire version 3 of the iPhone User Guide, which gives you access to the minified version of the PastryKit JavaScript and CSS. They have a few other supplemental materials as well to get you started.

Between those two articles, you should be able to start diving in to things here and getting your own native-like scrolling happening. Good luck!

This go-round, we’re going to tackle the issue of iPhone 4 and how to draw things beautifully to its Retina display. Before we dive in, let’s define some terms.

• Pixel: More precisely called a device pixel, this is a unit of measurement. In this article “pixel” alone refers to a physical pixel, a single point of color on a display. Further discussion of pixels may be found in the Wikipedia article.
• CSS Pixel: A relative unit of measurement using the same nomenclature as the aforementioned pixel. This is displayed at a relative physical size, based on the pixel ratio of the device’s display.
• Point: For the case of discussion iOS devices, this is a new unit of measurement Apple has created to create greater control over the ratio of CSS pixels to display pixels. This does not refer to the unit of measurement for printed font size, which is primarily seen in a word processor.

So, with this new arbitrary unit, the point, in place, the iPhone screen is now 320 points wide, regardless of device. What that point actually looks like is something else entirely.

On iPhone 4, a point renders as a 2×2 square of physical pixels, explaining how 320 = 640. If we were working on a native app, you could just specify all of your measurements in points, and create two sets of images with special names. But we’re working on a web app, where the unit “points” is already taken by the aforementioned “print points.”

This means that all of your measurements for things that are bitmapped must be halved, as iPhone 4 will be doubling them. As if we didn’t already do too much math when writing our CSS. To illustrate how this works, here’s a simple example: if you want to draw a 32×32 actual pixel image, you must specify its size in your CSS as 16×16. Easy enough, but how to target just iPhone 4? Quite simply, actually; we can conditionally call up a stylesheet based on iPhone 4’s high DPI nature, like so:
<link rel="stylesheet" type="text/css" href="/css/retina.css" media="only screen and (-webkit-min-device-pixel-ratio: 2)" />
With that tidbit above, we’re using the -webkit-min-device-pixel-ratio declaration, which came to be in iOS 4. iPhone 4 has a pixel ratio of 2 (e.g., 1 CSS pixel = 2×2 physical pixels), so we specify that our media correspond to that particular criterion, and only iPhone 4 (and any future iOS device with a pixel ratio of 2 or greater) will parse this CSS file.

Now that we know all about optimizing a regular site for iOS, let’s explore setting up a web app specifically designed for iOS. There are a number of great examples: touch.facebook.com, Hahlo (a brilliant web app Twitter client), Harvest, and many others. So what makes them great?

First, all of these web apps have used the previously mentioned viewport meta tags to optimize their site to be full-width, and fixed at that width (no scaling):
<meta name="viewport" content="user-scalable=no, width=device-width" />
They’ve also made sure to design their site within the constraints of the device. In the case of iPhone, that’s 320px wide, although iPhone 4 complicates things by upgrading that number to 640px. We’ll discuss the design difficulties present by iPhone 4 in a later document, but for now, we’ll assume 320px is the number to use.

Additionally, these interfaces understand that there is no :hover pseudoclass for links, buttons, or other interactive elements in the iOS interface, as there is no mouse pointer, and thus no clicking. Instead, our interactive gesture is the tap. So we need to ensure none of our interactivity relies on a user being informed by hovering over an element, as they cannot. Thankfully, for things like dropdown menus, Apple has created an abstraction where the first tap equates to a mouse hover and opens up the dropdown, so your dropdown menus can survive relatively intact.

The last few pieces that offer greater immersion and a more pleasant experience have to do with the “add to home screen” feature Apple added some time ago. When a user goes to bookmark your site, they have the option of adding it to one of their home screens. When they do, a dialog sheet appears, showing a tiny screenshot of your site and its <title>. You can, however specify an icon instead of having that ugly little screenshot, by specifying this in your <head>:
<link rel="apple-touch-icon" href="/custom_icon.png"/>
The above, however, will apply the default effects to your icon (rounded corners, drop shadow, and a reflective shine or “gloss”.) If you like your icon how it is, simply specify this instead:
<link rel="apple-touch-icon-precomposed" href="/custom_icon.png"/>
You can also simply place a file called apple-touch-icon.png or apple-touch-icon-precomposed.png at the site root. If you use apple-touch-icon-precomposed.png as the filename, Safari on iPhone OS won’t add any effects to the icon. As for creating this icon, you’ll need to make three icons, one at 57px for older iOS devices, one at 72px for iPad, and one at 114px for iPhone 4. While that may make you despair at the extra effort, be aware that if you delve into native app development, you’ll need to make eleven (!) icon sizes. Astounding.

So, now you’ve got your three icons, and you want to include them and get things looking right per device. Here’s what you need:
<link rel="apple-touch-icon" media="screen and (resolution: 163dpi)" href="/iOS-57.png" /> <link rel="apple-touch-icon" media="screen and (resolution: 132dpi)" href="/iOS-72.png" /> <link rel="apple-touch-icon" media="screen and (resolution: 326dpi)" href="/iOS-114.png" />
Obviously, add the -precomposed bit to the end of the rel argument if you have a fancy-looking icon already.

Not only that, but we can add two other elements to further enhance things when they add your web app to their home screen. The first is to specify that your app run in full-screen mode with this code:
<meta name="apple-mobile-web-app-capable" content="yes">
This removes the Safari toolbar, and your app will now have it’s own presence in your multi-tasking tray in iOS 4, instead of merely launching Safari and navigating to the address of your web app. You can also specify the top status bar (which has the carrier signal strength, time, etc.) like so:
<meta name="apple-mobile-web-app-status-bar-style" content="black">
Apple says it best about this one:

If content is set to default, the status bar appears normal. If set to black, the status bar has a black background. If set to black-translucent, the status bar is black and translucent. If set to default or black, the web content is displayed below the status bar. If set to black-translucent, the web content is displayed on the entire screen, partially obscured by the status bar. The default value is default.

Pretty sweet. What’s more, we can even have a splash screen by specifying this:
<link rel="apple-touch-startup-image" href="/splash.png" />
This should be a 320x640px (or 640x960px on iPhone 4) PNG image. It should be pointed out that there are some bugs for the apple-touch-startup-image and the apple-touch-icon in iOS 4 when you specify apple-mobile-web-app-capable, and they only load the lower resolution icons. Hopefully these bugs will be fixed soon. Regardless, enjoy customizing your users’ experience!