Topic Archive: Facebook

Getting things done with Flock and Meebo

Brian Dillard, Monday, September 8, 2008 @ 3:01 pm

During a recent GTD weekly review, I suddenly realized how many distractions had worked their way into my daily office routine: personal email, personal instant messaging, entertainment feeds, Facebook. I suspect such time-wasters pose a bigger danger to web developers than to other professionals, if only because the programs they run in are so central to our work. I run Firefox for web development, Adium for instant messaging, and NetNewsWire for industry news all day out of necessity. If I allow my personal distractions to jump out at me from those programs, my productivity plummets.

This weekend, I worked hard to de-tangle my professional and personal lives. My tools? Flock, the Mozilla-based "social browser," and Meebo, the browser-based IM aggregation service. My goal was to separate all personal bookmarks and RSS feeds from NetNewsWire and Firefox into Flock, then move all my personal IM accounts from Adium to Meebo. The end result was a self-imposed firewall between productive time and fun time. (Thanks to many a Lifehacker article for the basic idea, if not the implementation.)

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

agile ajax

Getting Started with Facebooker

Josh Symonds, Wednesday, July 30, 2008 @ 3:53 pm

Developing for the Facebook platform can be a big headache, and on Rails your headaches are unfortunately compounded from the get-go. While the otherwise-inferior PHP users get an API library from the Facebook development team (I'm kidding, I love you PHP guys), on Rails we have to deal with gems that aren't even at version 1.0 yet. While Facebooker is quite good at this point, its documentation covers a rather sparse selection of its impressive feature set, and RFacebook, which is better documented, hasn't been updated in aeons and is way more difficult to use besides. And unfortunately the standard Facebooker tutorial doesn't include the newest features from the recent Facebook profile overhaul or even all the necessary steps to get a new Rails application running on Facebook. So, enter Josh.

In this blog post I'll tell you the best way to integrate Facebooker into a new Rails project so you can start developing social networking applications quickly and easily, and how to hook them in to Facebook's new profile plan. The goal is that by the end of this post you'll have a totally working Facebooker Rails application and you'll understand how to develop in it at least a little bit.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

agile ajax

Facebook apps: Not too late to compete on the user experience front

Brian Dillard, Thursday, May 29, 2008 @ 4:12 pm

Despite the hype, Facebook's a frontier rather than an established metropolis. There's still room to ride into town on a white horse and save the day, earning yourself a healthy reward in the process. Exhibit A? The so-so user interface standards of the social network's most popular applications.

I recently, belatedly started playing Scrabulous with various friends and I'm shocked at the just-okayness of its UI. The lack of an on-screen legend for the mechanics of the variously shaded bonus squares? Puzzling. The drag-and-drop interface for shuffling tiles around in your tray? Maddeningly persnickety. The mismatch between the word lookup feature, which uses thefreedictionary.com, and the application's own, internal whitelist of valid words? A real bummer.

Scrabulous provides an adequate ripoff of a venerable and justly loved board game. But the rough edges of its user experience suggest that Facebook still has plenty of room for folks who know how to polish a UI till it gleams. Sure, first-to-market advantage gets magnified on social networks. But as these new application platforms mature, I'm convinced user experience design can provide a compelling means of product differentiation.

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

Recent Ajax Framework Releases/Developments

Dietrich Kappe, Tuesday, April 22, 2008 @ 4:13 pm

Some noteworthy Ajax Framework releases have come out in the last few weeks, along with some other news of interest:

• Ext JS 2.1 and Ext GWT 1.0 Beta - Better performance, new Slider, StatusBar components. REST support (support for other HTTP methods beyond POST and GET). The Ext GWT 1.0 Beta consummates the love affair between GWT (Google Web Toolkit) and Ext that was started by gwt-ext and MyGWT, but provides the comfort of knowing that it is supported by the Ext JS folks. Note: Ext GWT is pure GWT, not an Ext JS wrapper.
• Dojo 1.1 - First off, API compatibility between 1.0 and 1.1. Unified timing loop (ala Scriptaculous) for animation effects, with increased performance. Syntactic improvements to dojo.query. Unification of XHR functionality into dojo.xhr() function.
• Backbase Enterprise Ajax 4.2 - Backbase has been in the commercial framework game longer than almost anyone. Among the new features: hierarchical data bindings and improved performance. If you've wanted data binding for tree widgets, have a look.
• Google Search, Feed and Translation API - I opined a while back that Google discontinued their SOAP search API because they didn't want people reordering or otherwise manipulating their search results. Looking at the terms of use of the new REST service, you can see that this continues to be a concern:  You agree that you will not, and you will not permit your users or other third parties to: (a) modify or replace the text, images, or other content of the Google Search Results, including by (i) changing the order in which the Google Search Results appear...
• Google App Engine - it only runs Python apps right now, and it's a preview release available to a select few, but you can already see that this is Google's challenge to Amazon's EC2 compute cloud. In at most a year, unless you are security sensitive -- health care, financial services -- or running on Windows, you won't be building and maintaining data centers. The capital requirements for launching sophisticated and scalable online services is about to change.
• Echo3 (beta) - it's getting close. Superior performance to Echo2. Easier development of new components. Automatic serialization of objects between client and server. All HTML rendering now done on client. Overall the JavaScript client code is now of a design quality on par with the server code.

Lots of exciting developments for Ajax developers and Web 2.0 entrepreneurs. I, for one, can't wait to see how the Google App Engine compares to EC2 for deploying and scaling Facebook applications.

Technorati Tags: ajax, dojo, google app engine, gwt, ext js, backbase, echo3, google search

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

Facebook Application Logistics for Team Development

Noel Rappin, Monday, April 21, 2008 @ 11:56 am

Facebook is a unique platform for application development -- Facebook applications have a powerful API, a large user base, and low barrier to entry. With the Rails Facebooker plugin, a Rails programmer can treat the Facebook user data as an extension of existing Rails session features. It's all very nice, and I'm not going to talk about any of that this time around.

I'm going to talk about the logistics of doing Facebook apps. When a user sends a request to a Facebook app, Facebook intercepts it and forwards the request to the third-party app server, along with some specific Facebook data, like the ID of the user making the request. Applications have to be registered with Facebook, and have a unique URL prefix at apps.facebook.com. You also provide the URL for your third-party server.

This sets up some challenges for a development team. First off, your application probably relies on Facebook services, meaning it can only be fully tested from within Facebook. This implies that the external Facebook server needs to be connected to your development server. Since many Rails developers run off their own development machine behind a firewall, this is potentially awkward. Similarly, the fact that the Facebook application has a single URL mapping makes it difficult for multiple developers to work on the same application without tripping over each others' work.

How can a development team make this work?

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

Ideal team size for your next Facebook project

Ivan Moscoso, Monday, February 11, 2008 @ 12:36 am

I recently worked on a Facebook application for one of our clients.  This turned out to be our first collective experience building for Facebook, and it involved a mixture of re-using existing web services and building new ones for use by the same infrastructure.  All in all, a challenging thing to build and deliver given a relatively short deadline.

While there were many architectural considerations at hand, one of the interesting aspects of the project for me dealt with how we structured our team and went about tackling the problem.  As a result, I have a bit of advice on team size for those of you considering similar projects with an existing team at your company.  But first, a little history...

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

20 useful Facebook/FBJS developer resources

Brian Dillard, Thursday, January 3, 2008 @ 12:19 pm

The Facebook application platform is less than a year old, and Facebook JavaScript (FBJS) made it out of beta less than four months ago. It's therefore unsurprising that comprehensive developer resources for both are a little thin. Most of the real content comes from official Facebook properties. Still, a little digging helped me uncover some decent tutorials and a wealth of open-source wrapper libraries for Facebook's RESTful API. Interestingly, I didn't uncover any big attempts at Prototype-style FBJS toolkits - just a few scattered examples of utility classes. It seems that Facebook development experience is still enough of a competitive advantage that the experienced few aren't rushing to create helper libraries for their hapless peers.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

FriendFeed, Jaiku and Plaxo Pulse: Networks within networks

Brian Dillard, Friday, October 19, 2007 @ 2:00 pm

I'm as sick of signing up for new social networks as anybody. I'll never get back the hour I spent establishing an Orkut profile I never used just because two hipster friends momentarily thought Orkut was cool and badgered me into submission.

That said, I'm a little dismayed by the identity-management land rush. For a couple of years now, we've been hearing about this glorious world in which we'll be able to aggregate our online identities across multiple social networks. In just the last few weeks, I've gotten invitations to beta-test three new identity aggregators (FriendFeed, Plaxo Pulse and Jaiku). And now Facebook announces that it wants to make my data portable so I can take it with me to whatever network I want - a move unsurprisingly endorsed by Plaxo and other bit players.

Facebook's announcement is obviously a marketing move - just another step in its strategy to position itself open ecosystem rather than a closed network. But FriendFeed and its ilk are another matter. I have no doubt that the future will involve a procession of new, flavor-of-the-month social networks. But it's hard to imagine any one of these meta-networks building the ubiquity of the networks they cannibalize.

Most of these services fall into three categories: content aggregators, identity managers and reputation protectors. Content aggregators (such as FriendFeed and Profilactic) try to mege all of your "attention data" into a single stream for syndication. Identity managers (such as FindMeOn) seek to create a "master" online identity with permissioned access to all of your other identities. Reputation protectors (such as Naymz and ClaimID) help you establish and protect your online "brand."

There's a lot of overlap between the three concepts, but they all suffer from the same problems:

• They're too complicated to use: I gave FindMeOn a whirl about a year ago, but I found its system of "badges" and "digital keys" complex and annoying. It didn't help that its visual design and Ajax interface were so cluttered and quirky. FriendFeed, which is still invite-only, offers a much cleaner and more direct user experience. But its RSS mash-up strategy is far less ambitions than that of FindMeOn and its nebulous parent, Syndiclick. Regardless, none of these services really reduces the complexity of managing your online identities. If anything, they add to it, forcing you to keep one more profile up to date.
• They solve a problem most average users don't have: Tech professionals and early adopters may all have a zillion online identities, but most social-network users have at most a handful of accounts. As they discover new services, they're likely to stop using older ones. I loved Friendster as much as anybody back in 2003, but I never log on anymore because none of my friends do. Ditto MySpace circa 2005. I may have a trail of social-network accounts, but only a few are ever going to be truly active at any given time.
• They're a little too good at what they do: As earlier commentators have pointed out (here, here and here), social networks often derive much of their value from being walled off from one another. Users may want to share different data with friends, family members, colleagues and romantic prospects. Aggregating all of your identities just to re-segment them seems like too much work.

Is anybody out there actively using these services and, if so, how useful are they? As always, I'd love to hear in the comments.

Technorati Tags

• social networking
• Friendster
• MySpace
• Facebook

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax