If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

For several years, I’ve wanted to create an online dating website. After starting over several times as I learned more and more about web development, I began once more last year with what would become the first public release of Black Book Singles.

Black Book Singles officially launched on July 10th. As with my original intentions, the site remains a 100% free online dating service. My intention is to generate revenue via ads, primarily through Google Adsense initially. While my choice of advertising provider may change, the method of monetizing the dating service will definitely remain the same as it grows.

To get an idea of how the basic profile layout appears, check out my dating profile, or simply take a look at the screenshot below.

In addition to profile creation and member searching, Black Book Singles members will be able to send private messages to other members, participate in public discussion via the dating advice forums, and read frequent dating tips and advice in the blog.

Although Black Book Singles still off to a bit of a slow start, the dating service has 77 registered members and 49 total profiles, 47 of which are publicly viewable. Considering that the primary incentive in joining a dating service is to meet others who use the service, and considering that most of the initial members won’t be able to fulfill that hope, these numbers aren’t too shabby — especially considering that the site was created by a one-man team with virtually no cash to put into advertising.

For those who are curious about some of the technical details regarding Black Book Singles, the site utilizes a LAMP system architecture. Here’s a bit of a breakdown of what runs the dating service:

• coded in PHP5 using the increasingly popular CakePHP framework,
• utilizes MySQL 5 for data storage,
• runs on Ubuntu linux, using Slicehost for web hosting,
• HTTP request handling performed by Apache 2,
• Sphinx full-text search engine used to perform quick location lookup, and
• memcached implemented for partial geographical data caching.

So if you’re hoping to find local singles or are simply looking to help an aspiring entrepreneur, why not go ahead and sign up today?

I’m a day later than I anticipated, but I completed my first Facebook application: Favorite Games. Perhaps the best way to summarize this application is to include what I wrote in the about page.

Track your favorite video games with Favorite Games! Let your friends know what games you’re playing, want to play, or have already finished. Your games are displayed in a clean, compact box in your profiles for your friends to see.

Check out each game’s page for trailers and gamplay videos, user ratings and reviews, and a link to Amazon in case you decide you want to buy it.

If you’re thinking about buying a new game, just take a look at the “Most Popular Games” page. This page tracks games those that are highest rated, most played, and most favorited.

Getting started is easy! Just add Favorite Games to your profile, then click the “Add Games” button in the application.

In the process of learning to program with the Facebook Platform, I soon learned that there is not much information beyond what’s available within the Facebook Developer’s Wiki. Unfortunately, the amount of information available here is limited, and some of it is outdated or deprecated. As such, I was inspired to create Facebook Developer, a website where I plan on sharing tutorials, code snippets, marketing and monetization strategies, application reviews, and much more.

As part of my efforts in working to make Facebook Developer the best site in its niche, I included a much more in-depth review of Favorite Games that can be read there.

I’m very interested in receiving comments, questions, and criticism on both Favorite Games and Facebook Developer. My goal is to make both of these the best that I can. And, with you being the end user, it’s mutually beneficial for me to provide what you’re looking for. I’m looking forward to hearing your thoughts!

I’ve been working fairly diligently over the past several weeks to get my first Facebook application up and running. I was originally hoping to have most of the work done last Monday (a little over a week ago), but I realized that was too soon to completed everything. As I finished certain tasks and resolved various issues on my to-do list, I had to add other items to my to-do list in the process. I’m finally at the point where I feel confident that all my programming work that I wanted to put into the first release of this project will be completed this week, likely by the end of Wednesday.

Once I feel that the development of my application will begin, I’ll be rigorously testing the functionality as if I were a new user to ensure everything works correctly. On top of testing the functionality from start to finish, this also includes tinkering with URL’s to ensure that users can’t break anything important.

As soon as I release my application, I will post the full details about it here, and I will be contacting an assortment of Facebook-related blogs that I have come across in the past. As other blogs include any press releases about my app, I’ll be sure to include links here for anyone who is interested in following the scope of its publication. I am optimistic that a large number of potential users will have the opportunity to discover this Facebook application through a variety of sources so long as I remain diligent in my efforts to contact other website authors.

In addition to contacting other websites, I’ll be sending app invites throughout Facebook (although I believe the daily invitation limit is set to either 10 or 20 per user), and I’ll post links for my Facebook friends to see in their News Feeds.

I’m started to get excited to share all my hard work with those of you who are interested!

After improving my Facebook dialog code by over 99%, I decided to take it one step further. The previous improvement allowed the dialog contents to be loaded dynamically with a Mock AJAX call. However, the user was left wondering what was going on if the AJAX request had a slow or even marginal response time. I decided it was necessary to show the dialog box immediately, offering a “Loading..” message until the content arrives.

Creating a loading message message in a Facebook dialog is not as straightforward as it could be. I admit, this is one area where Facebook could stand to improve its JavaScript and Markup Language implementations. After spending a few hours trying to come up with a method to do this, I finally came up with the following setup.

First, I need to pass loading message FBML to the FBJS Dialog constructor. Second, I need to make the AJAX request for the desired dialog contents. Finally, I need to replace the loading FBML with that returned in the AJAX response.

The Loading Message

In order to pass FBML (or even pure HTML) into an FBJS Dialog, it must be pre-rendered. This adds a slight complication to the solution. Fortunately, Facebook offers a means for working around this issue via the <fb:js-string> tag. This tag can be used to render FBML and store it into a JavaScript variable. We can now use this knowledge in creating a loading message.

<fb:js-string var="add_dialog_fbml">
<div id="add_dialog">
<div class="dialog_loading"><img src="<?php echo AppCallbackUrl;?>images/loading.gif"/> Loading...</div>
</div>
</fb:js-string>

The extra DIV element with ID “add_dialog” is important, as we’ll see momentarily.

The FBJS

The next step is to update the FBJS function that creates the Dialog object. Previously, the AJAX call was made prior to any Dialog code executing. For this change, the Dialog needs to be created with the loading message content prior to executing the AJAX request.

<script><!--
function showItemDialog(id, title, ok, cancel) {
// Set the default values.
if (title === undefined) { title = "Add to My Items"; }
if (ok === undefined) { ok = "OK"; }
if (cancel === undefined) { cancel = "Cancel"; }
// Build the Mock AJAX object to request the dialog contents.
var ajax = new Ajax();
ajax.responseType = Ajax.FBML;
ajax.requireLogin = true;
ajax.ondone = function(data) {
document.getElementById('add_dialog').setInnerFBML(data);
};
// Create a "loading" dialog box that will be updated via the Mock AJAX request.
dialog = new Dialog().showChoice(title, add_dialog_fbml, ok, cancel);
dialog.onconfirm = function() {
// Submit the form if it exists, then hide the dialog.
frm = document.getElementById('frm_additem');
if (frm) { frm.submit(); }
dialog.hide();
};
// Update the dialog contents via Mock AJAX request.
ajax.post("<?php echo AppCallbackUrl;?>ajax/add-dialog.php?asin=" + id);
}
//--></script>

Note the use of the “add_dialog_fbml” variable (as declared through the <fb:js-string> FBML tag) when creating the dialog. Also, remember that “add_dialog” DIV that I mentioned before? Here you can see why it’s important. This bit of FBJS calls the “setInnerFBML” prototype function on this DIV element in order to update the dialog’s contents. Naming this DIV element provides a reference point for updating the content once the AJAX response is returned.

In developing my Facebook application, there has been much to learn about the specifics regarding the Facebook API structure. My most recent endeavor included creating dialog boxes (<fb:dialog> elements or DBJS Dialog objects for those in the know) that are used for updating user content within my application.

Part of the Facebook application I’m building includes setting up items with certain details as specified by the user. Specifically, the user can say if they own something, used something, or want something. In an effort to keep the page relatively uncluttered, the status of these items is set up to be changed within a dialog window, such as the one above.

Original Design

At first, the only means I found for displaying dialog boxes with varying content was to create an fb:dialog element in my FBML. Each of these tags included much more FBML — the title, content, and action buttons — resulting in lengthy HTTP responses. Specifically, the FBML for each item’s dialog was over 1,500 characters (or 1,500 bytes) varying slightly from item to item. With up to 40 items appearing on the busiest page, over 60,000 bytes of data will have to be sent to a single user for dialogs that will typically go unused in a single page load. This will undoubtedly result in slow responses to user requests when the application goes live, which will be unacceptable for a positive user experience.

Improved Design

After doing some searching, I found that there is a better method for dynamically generating Facebook Dialog objects via FBJS with a single function instead of numerous fb:dialog elements as described above. First, I created a simple function that requests the dialog content via Facebook’s Mock AJAX. The function is exactly 658 characters long, which could further be reduced by removing white space and utilizing an obfuscator if desired.

<script><!--
function showItemDialog(id, title, ok, cancel) {
// Set the default pop-up dialog values.
if (title === undefined) { title = "Add to My Items"; }
if (ok === undefined) { ok = "OK"; }
if (cancel === undefined) { cancel = "Cancel"; }
// Retrieve the dialog contents via Mock AJAX, and display the dialog.
var ajax = new Ajax();
ajax.responseType = Ajax.FBML;
ajax.requireLogin = true;
ajax.ondone = function(data) {
dialog = new Dialog().showChoice(title, data, ok, cancel);
dialog.onconfirm = function() {
document.getElementById('frm_additem').submit();
}
ajax.post("<?php echo AppCallbackUrl;?>ajax/add-dialog.php?id=" + id);
}
//--></script>

(Note that the AppCallbackUrl value in the code above is simply defined in an include file via PHP’s define function.)

The second step was to provide the output from the add-dialog.php file referenced in the JavaScript above. Basically, I looked up the item ID passed to the PHP file, and returned FBML based upon the item’s details. The resulting output from the code is about 950 characters long, varying slightly from item to item.

<?php
// Include the Facebook client library and app config.
require_once('../../client/facebook.php');
require_once('../inc/config.inc.php');
if ($_REQUEST['id']) {
$item = getItem(trim($_REQUEST['id']));
}
?>
<?php if ($_REQUEST['id'] && $item):?>
<form id=”frm_additem” action=”add.php”>
<input type=”hidden” name=”action” value=”add”/>
<input type=”hidden” name=”id” value=”<?php echo $item['id'];?>”/>
<p>Add <a href=”item.php?id=<?php echo $item['id'];?>”><?php echo $item['name'];?></a> to My Items?</p>
<table>
<tr valign=”top”>
<td><label for=”sel_status”>Status:</label></td>
<td><select name=”status” id=”sel_status”>
<option value=”O”>Own It</option>
<option value=”U”>Used It</option>
<option value=”W”>Want It</option>
</select></td>
</tr>
</table>
</form>
<?php else:?>
Sorry, the item you selected could not be found.
<?php endif;?>

(Note that, although I’ve edited the content of the file here for the sake of not wanting to reveal my personal coding efforts, the above code essentially performs the same task.)

Finally, I had to make a simple update to my anchor tags in the FBML for each item that needs to be associated with a Facebook dialog. This was a simple change within my items loop, coded as follows.

<a href="#" onclick="showItemDialog('<?php echo $item['id'];?>’); return false;”>Add Item</a>

Quantified Results

In all, I reduced the average response length for an individual dialog element by almost 37%. Additionally, assuming that a user loads a page with the maximum of 40 items, there is more than a 97% improvement in the amount of data sent as required for displaying dialogs. Furthermore, if the user doesn’t utilize any of the dialog boxes while visiting one of these pages, there is more than a 99% improvement in the HTTP response length! It doesn’t get much better than this, people.