iPhoneWebDev - Blog

My name is Shannon Appelcline. I help run the Skotos Tech sites and I’m a long time writer on game design, community development, and several other topics related to online web sites. I’ll also be an occasional contributor to this blog. In writing here I plan to maintain my focus on the work that I do professionally: the design and development of content-rich, text-based entertainment sites. Currently I’ve got two that consume most of my attention: RPGnet is a community centered on the discussion of tabletop roleplaying games like Dungeons & Dragons while Xenagia is a community centered on the discussion of books, movies, TV shows, comics, and anything else related to the genres of fantasy, science-fiction, and horror.Our main audience for these sites is desktop users, who are the group most likely to be able to interact with our forums, reviews, indexes, and other interactive features. However, because our sites are almost entirely composed of text with few graphical nuances, making them more usable on iPhones is an obvious step.To use Christopher Allen’s terms, we’ll be doing our best to make our sites very iPhone Friendly, with some work we’re doing, such as CSS differentiation and minor changes to layout approaching the level of iPhone Optimization. This is the perspective that I’ll be bringing to this blog in this and future posts.This week I kicked off iPhone integration with one of our major apps, the Index.

---

Making the Xenagia Index iPhone Friendly

One of the services we run at Xenagia is a Book Index. This database of fantasy, science-fiction, and horror books makes it easy for readers to look up books from their favorite authors, set in their favorite backgrounds, or part of their favorite series. As such, it was a great candidate for iPhone optimization. Having the Xenagia index available on your iPhone when you walked into a book store offered a number of advantages:

• If you stopped by a book store by surprise and didn’t remember quite what you wanted to buy, you could look up which books you’d rated in the Index, or which ones you’d marked as owned, and thus know what to get next.
• If you became intrigued by a new book you could use the Index to look up what other Xenagia users said about it.
• If you became convinced to buy a new book, you could use Xenagia as a reference to make sure there weren’t any earlier books in the series to read first (or later books that you might as well buy at the same time).

In preparing our iPhone optimization I had one primary goal: I wanted to make it possible to read as much of the site as possible without ever having to zoom.

Relative & Absolute in CSS

The first time I pulled the Xenagia index up on an iPhone, I was surprised. It looked pretty good. I could read most (but not all) of the text without zoom and I could click most of the links. Having since looked at page after page of sites that were all but unreadable in full-size view, I attribute the initial success at Xenagia to our decision to use relative values in our CSS.Though CSS has generally been a boon to web design because of the fact that it allows you to make standardized formatting changes across one or more documents, the “absolute” valuations that it introduced have largely been a bad thing.HTML was designed as a markup language, not a layout language, and for good reason. You never know what sort of display someone will be using to look at your page, and thus you can never see how your page will really look to other users. For years now people have tried to create beautiful page layouts, but an iPhone viewing just shows how easily that fails. A page designed for 1200 pixel width is never going to look good at 320 pixel width unless you’ve let go and simply offered mark-up “suggestions” rather than requirements.However, even with good relational CSS, some text still too small on the iPhone screen, and thus some more work was needed.

A Look at Viewports

There are a number of tricks that you can use to try and make your pages more readable on the iPhone. The simplest is probably a meta tag that the iPhone respects called “viewport”. It looks like this:

<meta name="viewport" content="width=320" /> 

Usually the iPhone takes a large-size web page, comparable to what you’d view on your desktop, and scales it down to the width of your iPhone screen. The viewport command says, “No, don’t do that. Instead view this page at exactly the WIDTH, scaling it as appropriate.”So, the above viewport command would show your page as if it were being displayed on a 320-pixel wide browser, rather than something much larger. If you put it in your global header, you could instantly be done, no muss, no fuss. Except there’s two problems:

1. There’s some sort of bug in the function as it currently exists which leaves big columns of white space on the screen for some pages.
2. It depends on your page being viewable at the size you specify, which notably means you can’t have any graphics wider than that and you can’t have any tables which really need to display wider than that.

Although I can definitely envision text-dominant pages where these would both be the case, it’s not going to be the case for 99% of web pages. As a result for Xenagia I looked at this option in passing, saw how it worked, and moved on.

Selecting CSS

The more obvious answer–and the one more likely to work–seemed to be CSS. For a site built on CSS–which Xenagia is–you can just create two different CSS files, one for regular web browsing and one for the iPhone and take care of most of the resizing there. This was the approach I ultimately decided to take.Apple foresaw this as a way to achieve iPhone optimization of a site, and they suggested the following code to implement it:

<LINK rel="stylesheet" media="only screen and (max-device-width:480px)" href="http://www.xenagia.net/include/styles-small.css" TYPE="text/css"><br><LINK rel="stylesheet" media="screen and (min-device-width:481px)" href="http://www.xenagia.net/include/styles-main.css" TYPE="text/css"> 

And although that worked fine in Netscape, in Safari, and on the iPhone, IE in Windows XP utterly failed using this method. If you wanted you could use a more complex method where you only used Apple’s suggestions if you didn’t detect iE (<!–[if !IE]–>), but by then you’re getting more convoluted than I like.Instead I adopted the equally easy (but less elegant) method of checking the user agent and setting a flag for the iphone only (though it’d be good to later expand this into a general list of smart mobile devices):

if (ereg("iPhone",$_SERVER['HTTP_USER_AGENT'])) {$iphone = 1;} else {$iphone = 0;} 

(All code examples are PHP.)That variable was then used to choose which of the two style sheets to apply, placing all of the work on the server side of things, and thus not depending on inconsistent methods to define browser media.

Setting the CSS

After that the process of writing an iPhone-specific style sheet was pretty simple, and mainly involved resetting things until they looked good on a typical iPhone.The biggest change involved cranking up the font sizes for default paragraphs and lists:

{font-family: Arial,Helvetica,sans-serif;color: #000000;font-size: 160%} 

This was pretty unusual. Usually we don’t fool with the font size for the default mark-up, and instead introduce classes for bigger and smaller words, but it was necessary here where we really wanted everything bigger.It also ended up causing some problems, because of the fact that relative values are multiplicative. As originally defined I also set “td” to be at 160% … which resulted in situations where there were paragraphs in a table, and suddenly everything got sized up to 256%.There wasn’t an entirely good solution to this because the web site was built on the assumption that “p”s and “li”s could be put freely in “td”s. For now we’ve just left “td” without size modification and are trying to use “p” markers or class tags more consistently at the start of “td”s. The opposite case, where the two were entirely separated (e.g., never any “p”s or “li”s in “td”s) would have worked too.Afterward I had to change all of my standard classes to also be readable on the iPhone:

p.smallwords,td.smallwords,li.smallwords {font-size:120%}p.medwords,td.medwords,li.medwords {font-size: 160%}p.bigwords,td.bigwords,li.bigwords {font-size: 200%;font-weight: bold;} 

(Here the problem of multiplicative relatives didn’t show up, because we never marked both a container and the contents with a class tag.)The one other notable problem with page contents was that our forms were all but unreadable … so small that it was hard to even select them. We don’t usually modify these at all with CSS, but it was easy enough to do when I saw the need:

select,input { font-family: Arial,Helvetica,sans-serif;color: #000000;font-size: 125% } 

For a text-dominant web site, just upping the standard font size to 160% or a bit lower and the standard select and input boxes to 125% or a bit higher will do wonders for making it readable on an iPhone without requiring zoom.

Graphics, Part One: The Links

The people I know who are professional web designers regularly complain about graphics being created to show text. Many of us do it, because it allows us to create more professional looking pages, but it goes against that very ideal that I mentioned above: you’re again laying out your page rather than marking it up.Nonetheless, at Xenagia we did exactly this. Our standard nav bar was composed of graphics and they were, of course, all but unreadable on the iPhone. Changing those out to styled words improved readability 100%, and also probably sped up the load-time of every one of our pages while decreasing the bandwidth.Here’s the style I used for our new navbar:

.headerword { font-family: Verdana,Arial,Helvetica,sans-serif;font-size: 130%;color: #ffffff;font-weight: bold;font-variant: small-caps; } 

Graphics, Part Two: The Displays

By now we were getting down into the nitty gritty. For the most part things looked pretty nice, but I was trying to seek out the low-hanging fruit–those things that could be pretty easily improved on the iPhone.One of these had to do with covers, and exposed what’s probably another bug in the iPhone. Many of our book index pages have covers associated with them. They show as thumbnails on a book information page, and when you click on that thumbnail it brings up the actual graphic file.Unfortunately the iPhone doesn’t treat these graphic files sensibly. When it shows a graphic file it treats it just like any other page, when means that it acts like it’s looking at a much larger web browser, and thus shrinks it way down.This is currently the one use of viewport at Xenagia. I wrote a new viewer page which was actually HTML (rather than just a JPG), and in that page I determined the width of the picture, then set that as the viewport.

$size = getimagesize($pathPic . "show-pic.phtml?picid=$picid");...<head><meta name ="viewport" content="width=<? echo $size[0]; ?>"></head>  

The result looked very nice, but I didn’t wanted to use this new HTML page for displaying on other browsers. Not only did it introduce a bit of CPU work that wasn’t usually necessary, but by displaying an HTML page rather than the pure JPG, it’d get in the way of the automatic resize function of programs like Firefox.I wanted to avoid–as best as possible–coding our pages to do special things when they saw an iPhone, but this is one place where I felt like I couldn’t avoid it, so I took advantage of the $iphone variable I’d already set:

if ($iphone) {$picDisplay = "show-pic-wrapper";} else {$picDisplay = "show-pic";} 

Making Mods & Letting Go

With that floodgate broken I did a little bit more work in my code to specialize individual pages for the iPhone, though I kept it to a handful of mods overall.One thing I did was increase the size of the thumbnails shown on the individual book data pages. This offered a sort of interesting look at the type of work you’re doing when you’re optimizing a page for the iPhone. On the one hand by increasing my fonts and some of my graphics I was doing much of the work that the viewport meta tag would (if it worked right). On the other hand, however, there were a handful of more rigid elements that I didn’t change, such as our banner ads (which genuinely have to be 728 pixels wide) and various tables, which are among the tightest elements on our page. I think that’s really the trick: to determine what all you can size up, and do it.I also made some minor layout changes, so that, for example, where our general data on a book appears in two columns on most browsers, on the iPhone it appears in just one. This was just done with some simple HTML changes for now, but I want to look into abstracting it out to CSS in the future.Despite getting into these minutia, I also think it’s important in iPhone optimization to know when to let go.There are some things that just don’t look as good on the iPhone as they do on a desktop browser. That hurts my aesthetics, but on the other hand I can accept that it’s a smaller platform that just isn’t going to have the same capabilities–if you want things to be readable without zooming.There are also going to be some things that are still too tiny. My “smallwords” class, which displays at 120%, is a little too small to read easily in portrait mode (though it’s perfectly readable when you landscape it). I decided to allow that because it’s the less used information and also the one a user is more likely to be familiar with–because it’s standardized on every page.(And it’s also all arranged in a column, making it easy to zoom if needed.)

One Last Trick: Scrolling

Here’s one last trick that I inserted into my standard header file:

<body bgcolor="#000000" rightmargin="0" leftmargin="0" marginwidth="0" marginheight="0"<? if ($iphone) { ?>echo "onload='setTimeout(function(){window.scrollTo (0, 1);},1);'"<? } ?>> 

This deals with the iPhone chrome that appears at the top of every page by scrolling it off the screen. The timeout is required to make it work. The result isn’t entirely elegant, because the page moves up then the chrome disappears, but nonetheless it gives the iPhone viewer an extra 60 pixels of viewing without them scrolling on every page–particularly crucial if they’re viewing in landscape mode.

Conclusion

Not every website will find it possible to offer no-zoom readability. However, if you can this should offer a good first cut. Just introducing a new CSS, upping the sizes of your fonts there and replacing any graphical text with plain text will do a lot to make your site more accessible on the iPhone, and thus more usable by a growing technological segment.Most of the tips in this article ultimately derived from http://www.iphonewebdev.com/’s mailing list.Next week I plan to look at the one major element on our sites that these changes didn’t touch: the vBulletin forums. I plan to create a more readable skin for iPhone usage and intend to incorporate a method I didn’t use here: omitting some information when it’s less important.

In considering how web sites can interact with the iPhone, I’ve created five broad definitions for levels of support:

---

iPhone Incompatible: These are sites that do not work on the iPhone because they require the use of Flash, SVG, or other plugins that are not supported, or because they rely on certain embedded media players. These sites are totally incompatible with the iPhone and can not be accessed, even via painful methods like constant zooming and scrolling. Other incompatible sites have one very wide column, and thus without a viewport tag are very difficult to read, even with zooming and scrolling (see example).

iPhone Compatible: Most websites should just work with the iPhone. Thus, If a website doesn’t have any of the incompatibility problems noted above, it is technically compatible—though it may look awful, have fonts that are too small to read except at high zoom, or have other issues. Nonetheless, we call these sites iPhone Compatible because they are at least usable.

iPhone Friendly: There are a variety of simple techniques that a website can use to help an iPhone display them. These include: informing the iPhone of the viewport size of the overall page; having columns no wider then either the 320px width (for upright view) or 480px (for sideways views); breaking columns up into more appropriately sized blocks; offering the iPhone some style tips on font size handling; using the appropriate links that the iPhone supports; and optimizing Quicktime files. Websites that offer these features are iPhone Friendly.

iPhone Optimized: It is possible to have a different CSS file for use by the iPhone, or to detect the iPhone in the http headers and offer completely different web pages. The iPhone supports CSS3 and some of the special graphic capabilities that both Safari 2.0 and 3.0 support (called Canvas). There are a lot of other features that probably can be offered when you know you are running on a webkit browser. Web sites that do this I call iPhone Optimized. Note, however, that a website does not have to be 320px wide to be iPhone Optimized—the iPhone supports very powerful scaling features that even iPhone specific web sites should offer. We don’t want to limit our users to a 320×480px narrow tunnel when we can give them a much larger overview by appropriately using scaling.

iPhone Webapp: The final category are those web sites that try to emulate the functionality of the built-in iPhone applications. These web pages limit the size of the page to 320×480px (or 480×320px), make extensive use of Canvas, and use a lot of AJAX functionality. These web pages should be called iPhone Webapps.A current discussion on the list on the topic of iPhone Webapps relates to standards and compatibility. Some developers are happy to use iPhone specific functionality, producing apps (or at least UI branches) which only work on that platform, while others are more interested in producing apps that will work on a variety of mobile platforms, including the next-generation webkit-based webphones which will likely follow the iPhone to market. When designing an iPhone webapp you should be aware of the advantages and disadvantages of either approach. To quote iPhoneWebDev member Randy Walker in a discussion on the list on this topic:

“Each category of programming is going to have its own rules/ideals for what is the overall good for that category. However, for clarity and sanity, the debating of those rules/ideals needs to be restricted to their individual categories. The thing that’s going on here is a cross category debate of rules/ideals. As soon as the ‘compatible with’ camp starts telling the ‘made for’ camp how to do things, both camps start spinning their wheels and chasing their tails. If ‘compatible with’ is your thing, or what your client will hire you for, GREAT! I wish you all the best. But if ‘made for’ is your niche, then do not hesitate to pull every CSS trick/hack out of the book to elevate the experience of your iPhone app as high as possible. Don’t ‘pump the bass’ just to make it compatible with other phones or desktop browsers as that would lessen the iPhone experience of the app. I’m not talking in absolutes here, i.e. yes, you can adjust code so it does similar things on other devices… So don’t flame me or start any sort of device wars. That’s not what this is about at all.”

---

These five categories are not official Apple designations for types of iPhone support by web sites, but I think they are a useful convention when talking about developing websites for the iPhone.

(This is a cross post from my blog at Life With Alacrity)

I feel privileged and honored to have been part of the iPhoneDevCamp this last weekend. Over 380 iPhone developers came out to the Adobe Campus in San Francisco to help each other make the best possible web pages and webapps for the iPhone.

I was the keynote speaker on Saturday and Master of Ceremonies for the MacHack-style Hack-a-Thon Demo on Sunday.

At the Hack-a-Thon almost 50 iPhone web applications were demonstrated to an enthusiastic audience. Take a look at Tilt, a game that takes advantage of the iPhone’s motion sensor, PickleView, which is a same-time live baseball game enhancer, and The Pool, an attractive social game of water droplets hitting a pool. What is remarkable about these applications is not just the quality, but that each of them was written over just the weekend by a small team of 3-4 people who hadn’t met each other before Friday!

Prizes were awarded after the Hack-a-Thon based on the spirit of openness, contribution, sharing, and participation. Prizes included 3 iPhones and some very expensive Adobe software. In particular Joe Hewitt, of Firebug fame, was honored for his positive contributions, generous spirit, and wonderful iPhone UI example code. During the demonstrations, more than one person praised Joe, saying that his assistance, his code, or his debugger made their apps possible. Personally, I think about one-third of the web apps presented used some of his code.

Building on my experience with the same-time collaboration tool SynchroEdit, and the Skotos web-based games, I worked remotely with Kalle from Sweden and Erwin from Kansas to present an AJAX chat application called iLace. I am particularly proud of how well this little web application performs and how well it works using the iPhone UI. In particular, I think its melding of text entry and chat message receipt and its response to changes between portrait and landscape modes are very good examples of what can be done for chat on the iPhone. Source code is available!

My keynote presentation slides are now available in .pdf and .mov. I’m told a live recording of the session and an .mp3 will be available soon.

Over the last few weeks an online developer community that I started at WWDC called iPhoneWebDev has grown to over 650 members. It’s now the best place to get online support for building iPhone web pages and webapps. I’d like to keep the momentum from the iPhoneDevCamp going forward on this list, so if you are interested in developing for the iPhone, check out the example code and join the discussion today!

Apple yesterday released documentation regarding Web Development for the iPhone, including Development Guidelines.