joey nelson blog title goes here

joeynelson.tumblr.com

In case you haven’t noticed I’m just trying to fill up the entire first page of a google search for “joey nelson“.

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.

You guys couldn’t figure out a better place to put the volume indicator when I’m watching a video?

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?

In case you haven’t noticed, I’ve been reworking my web presence a little bit and trying to get things cleaned up. One thing I noticed was that the old Anthem Type site had gone offline. Well, it’s back up and full of free fonts from Joey Nelson.

I’m not especially proud of the stuff there, it’s all over 10 years old at this point and represents some really basic attempts at type design (and some blatant appropriation). But I still see Uptown in random places a few times a week, so hey, somebody likes it I guess.

And speaking of free fonts, Fontleech is still online and has a lot of great stuff in the archives.