iPhoneWebDev - Blog

In my last article I wrote about making the Xenagia Book Index iPhone Friendly, and in the process optimized much of our science-fiction, fantasy, and horror web site for iPhone usage. However, I left one section untouched: our forums.

In this article I’m going to talk about what was required for that final step: the creation of an iPhone skin for vBulletin.

vBulletin: Bane and Boon

Between our entertainment sites at Skotos, RPGnet, and Xenagia we’ve gone through at least three different forum software packages that I can remember. The latest, and the one that we’ve used for six years or so, is vBulletin. It’s generally outperformed its competitors, and though we’re constantly pushing the edge of its capabilities at our very large RPGnet site, it generally does as well as I’d expect a reasonably priced commercial package to do.

vBulletin is also very customizable. Sort of. There are literally hundreds of CSS entries, template files, and plugin hooks that you can work with to make your forum look like whatever you want. However, I think the sameness of most vBulletin sites speaks to how difficult that actually is. Although it’s nice to be able to change anything from how messages display to the look of your forum home page, it’s just about impossible to dig through the tens of thousands of lines of code to find what you want.

Most sites make simple CSS changes (mainly color modifications) and leave it at that. To make Xenagia iPhone friendly, unfortunately, I knew I needed to go further than this. There would be modifications to the CSS to make the forum pages more readable, but I knew that I also wanted to make changes to how pages some displayed, and that meant doing template work, which I didn’t look forward to.

To begin any major vBulletin work like this, you want to create a new style. That’s done through the “Style Manager” under the “Styles & Templates” menu item in the administrative control panel. You find your default style and then you make a new child style. This new style will thus inherit all the changes you’ve already made, but also allow you to make more changes for iPhone viewing.

And this is where the next problem reared its head: by making changes to a child you override the parent style. After creating my iPhone skin that meant that I now had a setup where some new changes to main Xenagia style wouldn’t be inherited (because the info was also modified in the child). At first I tried to get around this by only editing items that weren’t modified in the original style. Though that was a fine goal, I wasn’t able to stick with it, just because of some of the changes that had to be made.

The CSS Changes

The first goal was to make the site broadly readable, with most text being legible in portrait mode without zoom. Being a good iPhone Web Developer I first tried to do this via the “viewport” tag. However, much as I found was the case when I’ve tried to use the viewport tag before, it broke. Random page had randomly sized columns that were totally empty. I tried a few different viewport numbers before giving it up as worthless.

Which meant I then turned to CSS.

I spoke more extensively about this in my last article, so I won’t dwell too much on the CSS work I did. Basically, I increased the default sizes of various variables to make them easier to read when small.

In vBulletin this is all done through another Style Manager option. From the drag-down menu for your new iPhone child style you can find “Main CSS”. The first thing I did was crank up all my fonts. Anything that was 10pt became 14pt while anything that was 11px (about 8pt) became 13pt. The latter is still a bit small, but it was a compromise that was required to keep everything looking good. The other option I found to change was the “<select> Menus” CSS which I popped up to 125%.

Voila! Everything was now sized much better with just several minutes of work. If you don’t do anything else, this is a great way to quickly and easily improve iPhone accessibility to vBulletin. The downside is that it doesn’t look that great. Huge numbers of columns cut text down into bite-sized bits that eat up all your vertical real estate.

Fortunately I had a plan to resolve this too: deleting information.

Information Management & Template Changes

This is definitely not going to be for everyone, but I think an entirely valid strategy for iPhone optimization of web pages is the removal of some information from iPhone views. Generally you don’t want to remove information which genuinely displays useful content to your viewer, but removing less relevant information can make it that much easier for an iPhone viewer to actually read what’s important.

I removed two types of information in this stage:

First I removed information that was only of interest to a newcomer to the site. For the Xenagia forums, this was the description of what each and every subforum on the site was for. For example the “Books” forum had two lines below the forum link which read: “Isaac Asimov, J.R.R. Tolkien, Stephen King.; Comic books and graphic novels too.” Clearly that type of signpost is useful for a first-time reader, but it’s not required for someone familiar with the site, and my general assessment is that if someone goes to the trouble of hitting your site on an iPhone, it’s because they’re already a fan.

Second I removed information that I felt wasn’t necessary to have a good experience at the site. Some of this information is definitely useful to some small degree, so it was overall a judgment call.

Here’s everything that came off:

• For the forum views I removed the thread and post columns, which served no real purpose except to show how popular our forums are (or aren’t). There was also a column which showed the last post for each forum, containing a thread title, a date, and an author. Though this was all useful, I wanted to cut the three lines these represented for each forum to two. I ended up removing the author line because I felt like it was the one least likely to encourage a reader to click through.
• For the thread views I removed the views column, which again I felt was something that only highlighted the popularity of the site (or thread) without giving the viewer real information. I left the replies column, which I felt was meaningful at this per-thread level, though I changed the title of the column from “Replies” to “Rep.” just to save some space. I also again mucked with the “Last Post” column. Here I had three entries: date, time, and last author. I really wanted to cut something to squeeze down this column size, and I ultimately decided on “time”. The forum software already shows whether a viewer has read something or not, so I figured that along with the date would give them enough of a guidepost to where they were. If I’d wanted to be more sophisticated I would have changed my listing to show the date for the last 24 hours, else the time, but that would have required digging even further into vBulletin.
• I opted not to change the messages view pages as all. Some of the text is a bit small in the message headers, but I decided to generally leave it. If I later modify anything, it’ll be to go back and make the author names larger.

This was all done via the aforementioned vBulletin templates. These are essentially chunks of HTML code interspaced with variables and links to other templates that are put together to create vBulletin pages. A listing of them can find in the Style Manager under “Edit Templates” for your new style.

forumhome_forumbit_level1_post, forumhome_forumbit_level1_nopost, forumhome_forumbit_level2_post, and forumhome_forumbit_level2_nopost were the four templates I edited to remove the forum descriptions.

The FORUM_DISPLAY and FORUM_HOME templates held the key to removing the thread and reply columns on the forum display pages (showing how obnoxiously things are divided up) as well as changing the word “Replies” to “Rep.” on and removing the “Views” column on the thread display pages.

A special template called forumhome_lastpostby is where I modified the “last post” element on the forum display, while threadbit is where I modified the “last post” element on the thread display.

Whew.

Conclusion

So that’s what was required to make the Xenagia vBulletin more iPhone friendly. The CSS is easy, but the template work is a pain–to the point where I’m not looking forward to digging through all those templates again to set RPGnet up similarly.

But if you want to do it youself, now you’ve got a thumbnail guide.

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.