ArcadeFly Blog|Status blog for ArcadeFly

So, there’s no flood of users, or flood of push for that — just a flood of development to make things better and more kickass. Since last week we added a great way for users to add games to arcades, put a light barrier to entry in place for editing arcades through the process of claiming an arcade, added exception notifications (just emails us when something goes wrong), automated deployments, made all html valid and worked towards a faster yslow rating and of course. The last development push will be to create a good iphone version of the add games page. This will be used while walking around arcades to add games, so it’s important for it to be as easy as possible. Lastly I’ll work on making the homepage more focused, which should help users to get started.

Having the site up and functional is a great boost to working on it though. If anyone is finding it difficult to find time to work on a project, I’d suggest spend some time to deploy a working copy and get it out there. There’s more incentive now than ever before to make fixes and improvements.

It’s official — ArcadeFly is available for the public… kind of. Right now we’re still in the “testing the waters” stage where we’re on pins and needles to see if everything works. So far it’s been surprisingly smooth sailing. The basics are all in place — people can register, add arcades, edit games at arcades, favorite arcades and games, map arcades and see distance calculations. That’s pretty much the core functionality. For now though, since there isn’t much in the system, my main emphasis is on creating a kick-ass way for people to add/edit arcades and the games at those arcades. It’s still a problem though, as we can’t have people just editing them straight out — there needs to be some system in place. That’s the top priority to get that going asap.

Releasing the first version of a product should never be feature complete. That is to say you probably shouldn’t do every feature you want to do right from the start. Things that seem important in the planning stages might become altogether worthless to the users, while they spot huge holes that you’ve left unfilled elsewhere. In the end it’s all about getting done the core of your project — what people are coming there to see. If the forgot password form process ends up being a little odd, or some graphic seems a bit off; but users are still able to do what you wanted them to then you have yourself a great success. The rest of the details can easily be hammered out, and even better organized with user feedback.

For ArcadeFly it’s obvious what the core features of the project are. Finding arcades to play games at. There are a few features that aren’t going to make it into launch, but nothing I’d call a showstopper. There won’t be a friends system, a comment system or a messaging system right out of the gate. For starters it’ll be all about finding the arcades. Then as people join up, I’ll see where resources are needed and probably work on adding more ways of users to communicate. This really makes sense anyways, after all how can you message people or add friends until there’s a user base out there. The lack of commenting I do miss, but it at least it means deferring those questions like “How do I weed out spam?” and “Who deletes spam?”. Doing more work now could very well lead me to investing even more time down a path I don’t want to go. Best to keep it simple while you can.

It’s been a slow couple months, but things are shaping up for an initial release this summer. The initial launch date was sometime in July, but now the goal is by the end of August. It’s not a matter of the site being extremely complex or anything, but just getting things right the first time. It’s coming along nicely though, and I think the finished product will be worth it. At the moment I’m upgrading the core of the site from Rails ~2.0.2 to Rails 2.1, the latest and greatest. It’s requiring a few plugin upgrades, but overall it was a quick process.

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.

So what does that mean…? Phase 1 will be pretty barebones unfortunately. It will be an internal release to whoever is interested in testing things out. At this point it will not be possible to add/edit games or arcades, but the functionality of registering, finding arcades close to you or games close to you is in there, as is mapping. Once I get to a good stopping point in phase 2 in the next week or so I’ll probably put it up. If you’re interested in trying out the beta, give me a heads up and I’ll send you the info.

Phase 2 will be a maintenance release. Forms will be spiced up, a little more sharpening of the main focus of the site — that kind of thing. No new functionality will be included for this one, other than the ability to add arcades. Working out a way to edit arcades/games is going to be a little tricky. I don’t want to open it up completely as if it was a wiki, but it shouldn’t be difficult for someone that wants to contribute to do so. Once it’s possible to do the main point of the site, and do it extremely well, I’ll start implementing the “nice-to-haves” like arcade ratings, popular arcades/games and that kind of thing.

Almost since the beginning I’ve had RESTful Authentication setup on ArcadeFly, although I’d been too lazy to setup a mail server to test of it’s functionality. For testing this out though, I decided to give Google a shot thanks to an article on how to use gmail as your mail serevr for rails. Very easy to implement, although I’m still unsure on the exact limitations. I don’t expect to reach any of those during development though, so for now it’s going to serve as an easy configuration option between the two PCs I use to code.

With that out of the way time to worry about a few smaller issues. Created a signup form at www.ArcadeFly.com. If you’re curious as to why I’m going with the www prefix, it’s mostly because of the site’s audience. For a mostly tech offering, or a tech blog I understand it makes perfect sense to do it the “right” way and use just the domain (we’re doing that for Adogo), but since this will be mostly video gamers and hopefully some not-as-technical people, adding www seems like the way to go. Non-www still forwards that way of course, and I don’t doubt that there will be a huge intersection of progammers and gamers.

Aside from that I learned a little bit about just how Rails Observers work. Such a simple topic I see why I don’t read too much more about it. There’s surely more to it than I’ve found, but it begins with a “config.active_record.observers” option in the environment.rb file where you point it to a classname. For RESTful authentication, for example, you’d point it to :user_observer. This will handle automatically sending out email messages based on changes to the user object. For instance, the UserObserver class is an ActiveRecord::Observer and shares methods like “after_create”, “after_save” and other points. Very powerful feature that’s easy to implement.

Getting nice looking error messages isn’t easy. It’s easy to use the Rails default (”error_messages_for”) but for the type of errors you’d ideally want you’ll still have to do a little leg work. One nice part it that any form fields that are being output using the Rails form helpers will be wrapped in a div with the “fieldWithErrors” class. This makes adding a red border to problem fields extremely simple.

Also, with the help of the recent post about multiple selects over on railscasts, I was able to add in my country/select fields in a very streamlined way. I’m using the same “address” partial for users and arcades at the moment as well, with that partial including the javascript in the header. Pretty slick just including a partial and having all the javascript just fall into place. For now adding a single arcade is working fine all around, although i’m a little concerned with how my nested resources are starting to become cluttered.

Nested resources are just what they sound like. For instance if you wanted to get a users address, you might go to the url http://localhost:3000/users/:user_id/address/1. That’s a very useful looking URL that you can find a lot from. The downside is that the controller/action this will hit is (by default) address_controller.show. This is the exact same controller/action that is hit when you go to http://localhost:3000/address/1 though! The only difference is that there will be a “user_id” variable passed in. After that though you might handle little things differently like the title, the edit link for that resource, and maybe even the entire page. Aparently you can make this resource go to another controller, like “user_address_controller” for example and not have to worry about this. I’m starting to think this is the way to go for a lot of this.

So far YM4R and GeoKit are working out aside from a few oddities. GeoKit install and geocoding was flawless, but I’ve yet to use the advanced finders for distance. At the moment the user/gamer/player (haven’t decided what to call it as of yet) doesn’t have an address associated with it for mapping functionality. Should be easy enough to compute according to tutorials.

YM4R makes the simple things even easier, but due to the very small amount of documentation its been a bit difficult to find examples. It’s probably time to start digging through the plugin code for clarification. YM4R is used for creating your Google Map markers in Ruby code, storing them to single variable and then being able to generate the header javascript, as well as the div/span/whatever the map will be created in. It’s easy enough to wrap some code in a content tag from within a view for a specific map.

<% content_for(:header) do %>
<%= GMap.header %>
<%= javascript_include_tag("markerGroup") %>
<%= @map.to_html %>
<% end %>

The @map variable was created within the controller with all points that will be created, as well as any map settings — like zoom level, lat/long to center in on, as well as managing groups, clusters and anything else. When generating a map with a group of points, it’s possible to have ym4r decide where to zoom in on, as well as what zoom level. This is as easy as a few lines:

sorted_latitudes = @arcades.collect(&:address).collect(&:lat).compact.sort
sorted_longitudes = @arcades.collect(&:address).collect(&:lng).compact.sort
@map.center_zoom_on_bounds_init([ [sorted_latitudes.first, sorted_longitudes.first],
[sorted_latitudes.last, sorted_longitudes.last]])


I’m still working on some of the basics of mapping that aren’t quite as well documented. Things like having a marker point popup on start, or having a link on the page outside of the map that opens a map marker. These kinds of things are simple when you step into javascript, and heavily documented, but not quite as much so with wrapper plugins. I’ll probably mess around with it a bit more, before deciding if straight javascript or ruby is the way to go.

As far as javascript goes, one solution that looks interesting is Mapstraction. There is actually a YM4R wrapper for it as well, although it appears out of date (and undownloadable). The idea is that you can switch which mapping engine you use. Always a plus to give users the ability to decide which mapping engine they prefer, but I imagine it’s at the cost of some features. Google, for instance has quite a few different ways of grouping points so the browser doesn’t crash to a halt. For instance, if you use clustering (which the ym4r gm plugin supports), markers that indistinguishable at far out zoom level will be shown as a single point. This keeps the map clean so that you won’t have a collection of points all on top of each other. We’ll see how it goes with the remaining tasks!