I admit, we've been a bit lazy on adding support for multiple browsers. My browser of choice, Firefox 3, is usually all I test in. For the most part this covers 99% of ArcadeFly, but that 2% must really annoy people who use the site in other browsers. Now though, the site should look the same in FF3, Safari, Chrome and IE7. I'm going to give it a once over in FF2 tomorrow, and consider supporting IE6. Since we're lucky enough to use JQuery, getting everything working in IE6 should come down to some CSS tweaks. With a full 20% of our visitors using IE6, this is something we'll definitely be seriously considering. If you come across any layout issues in any browsers other than IE6, please comment on them and we'll do our best to fix them up.

I'm going to try to update the blog more with some bug fix releases to keep people up to date with what's going on. The release for today is on the small side though. The profiles and arcades section have a "show arcades/profiles within so many miles" drop down, where you can select 10,20 up to 5000 miles -- or everywhere. This wasn't working due to the weird way we were using Geokit. The changes made to get this working are available on my fork of geokit-rails.

We recently fixed most the bugs currently on ArcadeFly. There's a few in the works, but nothing major outstanding. We recently upgraded to Rails 2.2 with Passenger instead of Mongrel. Things are really coming along though and become stable enough to build on. We're planning on expanding out to some new features in the coming weeks, but still looking for suggestions on where to place our focus. If you see any problems with the way things are now, please email me or just reply to this post. We're looking into some better ways of tracking bugs, but the free ones don't seem to compare).

As things start to be used it's always easier to flesh out what should be improved. For this week that has been the games list. After taking a tour of Orlando I ran into a surprising number of games that weren't in the GameFaqs listing that we're using here. The solution is to move off gamefaqs as the definitive listing for games. You'll notice that the URLs no longer use the gamefaqs ids as the URL parameters. It's just not a good idea to base your system that much on another one of which you have no control. Plus, as I was going arcade to arcade I was noticing other items that we might want to track (pool tables, air hockey, basketball, etc) that just wouldn't fit into the mold if we required all games to exist on gamefaqs. As for the games that aren't on GameFaqs, we'll soon be adding all games from the Killer List of Video Games as well. It's just about ready, but I'm running into a problem with game names that are similar but not exactly the same. After I write up a script to merge the differences between these two we should have another 1,000 or so games available.

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: 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.

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.