That’s where social networks like MySpace, hi5, and orkut come into play. While Facebook might be the largest social network and the most used in North America, MySpace still retains a loyal set of users. Networks like hi5 and orkut maintain strong regional networks, with others like Vkontakte commanding small, but extremely engaged regional users.

Facebook is effectively a ‘me too’ developer arena, with an aggressive and unfriendly referee in Facebook Corporate. Most of the spamish tools used by Zynga and Playfish to grow their networks during the last redesign renaissance are gone now. Wall posts? Gone. Stream Posts with lots of images and spammy links? Gone. Notifications? On the way out baby. Facebook is attempting to detatch themselves from developers that helped increased the retention of their platforms by reducing branding and making it difficult for new developers to grow their audiences. With the introduction of Facebook payments, the writing is on the wall for companies like offerpal and trialpay as well.

So, what’s a developer to do? Social networks arn’t going away, and there’s still money to be made developing for other platforms that are looking to lure developers of A-list apps away from Facebook. MySpace is trying to do exactly that with a revamped API and a development contest aimed at giving developers something else to playwith on the platform. To be honest, there are some fairly interesting ideas in the streaming apis, borrowed from what Twitter is up to lately with its streaming API. It’s a huge waste of time and money, tho. The MySpace API’s are poorly documented and don’t really focus around what developers need to pull from the network on a regular basis (Friends, Userdata, Viral Channels). What’s worse, all of the MySpace API interactions are governed by what must be the worst authentication system ever imagined in Google’s OAuth for Opensocial.

Just look at the work flow for this beast of an authentication system. Wanna get some information from the user? You need ten steps to make that happen. Five full request / response cycles to make anything happen if the user isn’t authenticated. MySpace will let you skip one of those cycles if you’re making the request from an already authenticated user within one of their application pages, but you’re still going to walk through the overly complicated process of authentication to do almost anything. You could use the MySpace SDK for most platforms, and they do a great job of abstracting away all of this OAuth complexity, but as a developer, I should be able to look at the calls and understand how they work immediately.

Developers should be somewhat afraid of things that are black box implementations of anything, and while the MySpace SDK isn’t exactly black box, it isn’t intuitive either. It takes a real time investment to understand any call made to the api that involves OAuth. What’s worse is that it’s needless complexity. Twitter’s API uses tried and true authentication headers to prove identity. Easy, understood, you know what’s going on immediately and should something break, how you can roll up your sleeves to see what’s wrong.

Most developers who work on the MySpace platform won’t take the time to understand it because of the massive bloat attached to it. It’s too far gone now for any proper change with the MySpace API, not because it can’t be changed, but because there is no culture in place to change it.

Want developers to work and create for your platform? Get out of your own way.

The guys involved with Play! released 1.0 earlier this month, so I bundled up a OSX installer to place the commands in convenient places for mac users.

Check it out here:

http://driftlogic.net/play_framework

Google was the first really ’successful’ company to adopt the simple site approach. Yahoo was the big dog on the block with it’s dramatically complex presentations and homepage, exposing all of the information about the nuts and bolts of the machine along with the attempt to force feed users associated content at the search box and home page.

Intentional or not, Google figured out the one cardinal rule of web development. Users visit sites with a task in mind, and that task is often singular. No matter what the site or application, users don’t spend time exploring, unless your site keeps a tight narrow focus. Users who land on a site looking for information about racing will spend more time exploring your site if it has a focus on racing, less time exploring of racing is just one component of a multi-focus site. Search results have conditioned users to expect results to be single page only, with little related information if any.

Developers and designers have a great deal of trouble scaling back ideas to fit into this singular focus approach and filtering out the noise. Most of it has to do with the brainstorming at the beginning of the project. When an idea sparks, random thoughts are encouraged in brainstorms or while the idea is being developed. But before development begins, teams need to spend time performing a reality check, not only in regard to the scope of the development, but about what ideas are included.

The scope of the project to the first milestone is a great barometer of success. Ideas that keep development as tightly focused as the idea tend to produce better products and better code. Projects where developers are scattered, attempting to work on multiple facets of a system simultaneously are a good indicator that the project lacks focus. Attempting to narrow the scope during development is nearly impossible, and almost always results in missed deadlines and backwards development.

Successful projects focus on the idea most commonly found in development for social networks where releases focus on minor features and continuous integration and release. Plan schedules around minor features, not major ones. If a feature can’t be paired down to a series of minor releasable features, it should either be considered a separate project outside of the current scope, or be refactored before development begins. Even beyond this, each complete minor feature should be considered a full release. That might mean that you’re releasing new features each week, and honestly, that’s okay. Users adapt to incremental changes in a far more flexible way than large scale changes, particularly in the flow of your site.

Happy, focused developers tend to lend to happy, focused users and user experiences.