Joey Nelson Blog Thing

I recently launched a ton of changes to omgtru, a site for my friends that runs my msgblorb message board software. There are a ton of backend improvements, mostly focusing on speed, but there’s some flashy stuff on the frontend. I’m especially happy with the new iPhone optimized version of the site.

My goal was to build a feature-complete version of the site with the same look and feel that performed beautifully on the iPhone and was as easy as possible to interact with. I was able to do it using essentially the same html (there are a few if $is_iphone statements in the templates, what can you do?) with some iPhone-specific CSS and js. That way I don’t have to maintain two separate sets of templates, which is something I’m delighted to avoid.

Building a web app interface specifically for the iPhone is an interesting challenge. The most obvious lesson is to make your interactive UI elements BIG. Since I’m clicking on a tiny screen with my fat, clumsy fingers, I need an easy target. omgtru uses pretty small, minimal UI elements so it definitely took some adjustments.

And obviously, you can’t use anything that relies on hovering. Working with scroll events is also a lot trickier, since the iPhone uses a viewport inside of the window.

And since your users could be on some slow ass 3G connections, your tried and true performance best practices are now doubly important. You definitely also want to cut out any CSS/JS that the iPhone site doesn’t need. If you’re consolidating and gzipping those files it won’t be a huge savings, but I managed to shave off several kb by getting rid of some jQuery plugins that iPhone users didn’t need.

This was my first experience building a web app interface specifically for the iPhone and I’m pretty happy with the results. My advice is to just use the app like crazy (on a real phone, not just the simulator) and keep getting rid of everything that annoys you. Then you should be in good shape.

If you’re trying to build a minimal UI, you’ll probably end up using form hints at some point. These hints are the example text that occupy a text input until the user types something:

This is a nice feature for users, but it’s always required some hacky javascript to pull it off. The simplest approach is to set your hint as the text input’s value, and style it with lighter gray text. There are a couple of annoying things here:

• If the user doesn’t type anything, the form will submit the hint as the input value (unless you code around this)
• Hints in a password field will show up as hidden passwords (•••••)

So that sucks.

Another option is to make a dummy input with the hint and display that above your real input. When the user clicks the dummy input to start typing, you hide the dummy input to reveal the real input beneath it. The EZPZ Hint jQuery plugin is a really nice example of this.

I’ve been happily using that until recently, when I was building an iPhone-optimized version of omgtru. EZPZ Hint looked great, but had an annoying issue in Mobile Safari: when you clicked the dummy hint input, the keyboard would pop up. The dummy input would immediately get hidden and the keyboard would slide down. Then, focus is set to the real input and the keyboard pops up again.

Of course, everything worked, but it really bugged me. So I started looking into some of the new HTML5 form features. Luckily, there is a new input attribute called placeholder that does exactly what we want. We just set up our input like this:

<input name="username" placeholder="Enter username">

No hacky js necessary. It doesn’t work in every browser, but it works in Webkit (including Mobile Safari). So we just have to check and see if our browser supports it. If not we can fall back to EZPZ Hint with an input set up like this:

<input class="hint" name="username" placeholder="Enter username" title="Enter username">

(You could get rid of the redundant placeholder/title by setting one of them dynamically based on the other.)

So let’s see if our browser supports the placeholder attribute. Of course we want to do this the right way. We don’t want to do browser sniffing. Really. We just want to check with the browser and see if an input element has the placeholder property:

if(!('placeholder' in document.createElement('input'))){
	$('input.hint').ezpz_hint();
}

Awesome, it works! Uh, except on my iPhone (iPhone 3GS, still running iOS 3). Why? I have no idea. Mobile Safari supports placeholders but fails that test. So we have to resort to some good-old fashioned browser sniffing. This makes us horrible people.

So figure out how you want to do that. I have to do it in PHP anyway so I’m just setting a javascript variable:

if(!is_iphone && !('placeholder' in document.createElement('input'))){
	$('input.hint').ezpz_hint();
}

So that’s it. Hopefully browsers will adopt placeholder text across the board and someday we won’t have to deal with any hacky workarounds. I can dream, right?

AT&T is screwing up in every imaginable way lately. I can’t wait to sign a 2 year contract with these guys!