ArcadeFly Blog

For the first release of products it seems like in most the books I’ve read they talk more about getting the basic foundation for a site for an initial launch, rather than getting something that’s good and people actually use. I’m taking an approach more along the lines with what’s described in Designing the Obvious for ArcadeFly though. Rather than skipping things I’m fully embracing them — if they’re essential to the user experience. I’m concentrating most on what people will use most — makes sense right? I’m taking this down to the small details like auto-selecting form fields, keeping tab navigation order logical and generally just trying to solve problems before they occur. For instance, on the forgot password form we ask for the email you signed up with. If you enter one that doesn’t exist it’ll ask you if you want to register, and if you click on the link, it’ll show the register form with the email you entered previously already filled in. Likewise, if you enter an address for distance calculations then decide to register, we’ll try to sync up your address with the fields on the address form.

Syncing up an address like “1486 E Buena Vista Dr, Lake Buena Vista, Florida, 32830″ (Disney Quest) with the individual parts by itself isn’t an easy task. You can try to parse this out by comma, and maybe if you’re lucky you’ll split it correctly. There is an easier way though — GeoKit to the rescue! Load up script/console and try out Geokit directly:

>> loc = GeoKit::Geocoders::GoogleGeocoder.geocode("1486 E Buena Vista Dr, Lake Buena Vista, Florida, 32830")
=> #<GeoKit::GeoLoc:0x223ba34 @state="FL", @success=true, @provider="google", @lng=-81.517122, @city="Orlando", @country_code="US", @lat=28.367984, @street_address="1486 N Buena Vista Dr", @full_address="1486 N Buena Vista Dr, Orlando, FL 32830, USA", @zip="32830", @precision="address">

Thanks GeoKit! Even if this was called with just “1486 E Buena Vista Dr, 32830″, we’d still get the same results down the latitude and longitude. From here it’s just a matter of using loc.city, loc.zip, loc.country_code as much as we need. For a user who just wants to come to ArcadeFly but not register, they can enter their address and we’ll save it in their session as a string (or at least that’s the plan), then if they decide to register this method helps split it apart. Pretty slick all around. Users shouldn’t have to enter data more than once after all.

Slowly inching towards the end of phase 1 now. Over the weekend I managed to wrap up just about all the remaining login/user interactions in ways I thought were intuitive. For this project I am doing most of this myself, with the help of the RESTful Authentication rails plugin. I did run into one awkward case I should probably check on a little more though. If a user has signed up but not activated their account, and they complete the “forgotten password” form, I need to rework it. I don’t like the way RESTful authentication does this part actually. You cannot reset your password unless you have already activated your account. I’d say whenever someone changes their password also set their activation code to null, making them activated. This is sort of a side effect of changing password, but it makes sense. If soeone can change their password they should meet the conditions for activation as well.