Interactive 8-Ball Facebook App

So we’ve jumped on the Facebook bandwagon a bit. You can now install the Interactive 8-Ball application to your Facebook profile.

Why would you want to install I8B on your Facebook profile?
I don’t know, but if you use Facebook as your homepage instead of iGoogle it’s nice to have I8B right there. We also update your profile and mini feed every time you ask a question through Facebook. Although this last bit can get tricky; we had a lady email us to take down a question she asked about a love prospect for fear of being had. (Which only gave us another idea for a Facebook app that we might share at some point.)

And What Happened?
I8B got a ton of traffic. In three days, we got 400 people to install the new application. Traffic to I8B trippled to 800 visits a day and then… leveled out. We actually lost 5-10 users today as people have started to uninstall the application. So growth is not exactly parabolic so far.

I guess we need something more to help the spread. (This blog post? A mention at TechCrunch? Maybe I’ll resubmit I8B to Emily Chang’s eHub.) It would be nice to have the 20,000 users that the other lame-o eight ball application on there has. Of course they got there first and so are high in the app directory and have the catchy URL at apps.facebook.com/eightball. (ours is apps.facebook.com/bettereightball) 😉

What’s next?
A WineLog app for Facebook, duh. The I8B stuff was kind of a primer for work on a WineLog application. And good thing too. It is nice to work out all of the kinks using a brand that we aren’t as invested in. This article helped me a bunch, but it also took a lot of hacking around to figure out what he meant by everything. The toughest part was fixing Facebook’s broken PHP4 client. Don’t even try messing with that unofficial one. If anyone needs help, shoot me an email or IM.

Anyway, a WineLog app would be fun. Again, I would rather just go to WineLog to see what my friends are drinking. But if you spend your day at Facebook, it’s sweet to get notifications on what people are logging. And it will hopefully introduce WineLog to some new folks. Cross your fingers.

UPDATE: Here are links to my versions of the facebook api scripts. Download them and rename them to .php. I hope to comment up the code when I get a chance, so you can see what I changed. But in the meantime, this might be a better starting place for you than Facebook’s version.

facebook.php
facebookapi_php4_restlib.php
IsterXmlSimpleXMLImpl.php

Download all of the above files, rename them to .php, and follow the tutorial instructions here (or do whatever you’re doing). The strange one at the bottom is a library to handle XML objects (PHP5 does this natively I suppose). Read here for more on simplexml44. Or here is the entire simplexml gzip file as I unzipped and installed it on my server.

Interactive 8-Ball Facebook App was last updated on June 28, 2007. Bookmark the permalink.

What Address to Use for WineLog Mobile?

We are getting ready to release mobile access to WineLog. I wanted to pose a question around this, and I hope to get at least a few responses. So here goes…

What should we make the address for the WineLog mobile site?

Here are a few options. Feel free to come up with your own.

  • http://winelog.mobi
  • http://mobile.winelog.net
  • http://mob.winelog.net
  • http://winelog.net/mobile

We picked up the winelog.mobi domain a little while ago “just in case”. I’m not really a fan of the new top-level domain. Creating a separate subdomain for the mobile version seems much more elegant to me. Although, keeping the mobile site and regular site on different domains will help with traffic tracking and the such.

The effect on Google juice should also be taken into account though. By using a different top-level domain, we’ll be losing the Google ranking we’ve established. But maybe a .mobi address will help with mobile search engine ranking. I doubt it though since Google themselves aren’t using the .mobi domain. http://www.google.mobi redirects to http://www.google.com/mobile.

“mob” is quicker to type than “mobile” or “mobi”, so I’m pretty fond of mob.winelog.net. But I also want to keep to any standards that have been developing. My only experience with this so far is http://mobilicio.us, where we made the base site the mobile site and use http://mobilicio.us/www as the “project site” meant to be viewed from a larger screen. The mobile application was what people would want, so we put it right there at the root level. We did use the funny .us top-level domain to stay hip and remind people of the interaction with http://del.icio.us.

So I’m really looking forward to everyone’s opinions on this. Thanks in advance.

What Address to Use for WineLog Mobile? was last updated on January 17, 2007. Bookmark the permalink.

Making Our Current Features Solid Before Adding New Ones

Kim and I were getting a lot of work done on a new import tool for WineLog. There is no question that this tool is awesome. It is one-of-a-kind and will help users who have invested a lot of time into another wine tracking system to convert to WineLog. This new feature is good for our users, and good for the growth of WineLog.

However, there are a lot of existing features that could use our attention. The RSS feeds for instance need some help. Some are more flexible than others, some are not yet taking advantage of the smarter search code, and some are not working at all. There is a lot we can do to make subscribing to our content through RSS more user-friendly and easier to understand for folks who may not be familiar with Real Simple Syndication.

There are a lot of web sites moving into the wine space recently. Some of these web sites are really solid. While I think we currently offer the best mix of features and community, others are catching up fast. And their quality is not suffering. We can’t afford to have a reviewer say something like, “Sure, WineLog has a huge database of wines, but such and such a feature was rough around the edges and confused me.” We can’t afford to lose a user who runs into a problem like that.

For these reasons, over the next few weeks Kim and I will be focusing on making our current feature set as solid as possible before moving on to new things. Adding new features will only complicate things if we’re not sure that the current offerings are the best they can be. Sometimes we try to run faster than our legs can take us and we stumble a bit. When this happens, we need to slow down a bit and focus on our technique.

Making Our Current Features Solid Before Adding New Ones was last updated on December 13, 2006. Bookmark the permalink.