When looking at the development of a social networking site, there are a number of fundamentals that I think need to be implemented before you can consider that you have the basic framework for a social network.

Basic Information
The absolute basic building block of such a site is the user account, or user object. The question then becomes, what do we need to store about this user? The actual requirements will vary between types of social network, but for my purposes I’m storing a small subset of common user data:

• username
• password
• nickname
• gender
• msisdn
• birth date
• address details

I’m recording the MSISDN since this will also be a mobile social network, and if we want to deliver services to the user via their phone, we need to know the number. This is also going to be the route we use for registration (text to a number to register) so we have some form of user verification.

This list is the basic information we need, but we also need some specific information that we’ll use internally, some of which the user will be able to change, some which we’ll use for identification purposes. So to this basic list I’ve added the following as well:

• registration date
• last visit
• is adult
• registered

We’ll use the two dates for some stuff as we go along (such as presence), and for redundancy (and because reading a field is quicker than calculating a date - here’s some thinking ahead going into the design), we’ll set a flag at registration time related to the user’s age. The last field, registered is a tracking field which is set to ‘true’ once registration is complete, since a user record is created for a new user as soon as they begin the registration process, not when they finish it.

Basics of Personalisation
Everyone likes to personalise their social networking accounts, but not all personalised information is always needed on every displayed page. Since we’re building up a basic user object that we’ll load for the user every time they visit, we only need some small additional information (initially at least), so we’ll add a couple of extra fields to the basic user object:

• avatar
• about me

Avatar is, as you would expect, related to a user’s picture. We’ll talk about how we deal with this information later, as there’s much more to a user avatar than just storing a picture. After all, if you have 25,000,000 users, where do you store all the pictures? You certainly don’t want every user to have their avatar stored as a blob field in the database…

The about me field is a little throwaway item I’ve put in as a quick way of letting peopel write a little about themselves, which is automatically displayed on their account. This and the avatar field are user changeable (as is the password, of course!).

The User Object
Now that we’ve determined a basic set of fields with information about a user, we can start setting up the database tables, and the underlying back-end code for loading, updating and using this object to deliver the social network itself. The manipulation of this object will be the subject of a later post.

Social Networking is something of a pehnomenon at the moment, with Facebook, MySpace and Bebo (amogn others) leading the public perception of what social networking is all about, although there are many, many others - including the one I wrote for Pitch and launched a little over a year ago.

It’s now been more than six months since I stopped working on the Pitch Social Network, and in the interim I’ve been working on developing a new social networking application. Speaking to some people I work with, I mentioned that I’d been thinking about writing a series of blog posts about Social Networking development, to discuss some of the ideas I have on how such applications should be architected, not just from a software point of view, but from the whole service architecture, including infrastructure, service design and software design.

Everyone I spoke to told me to go ahead, and now that I’m back from a few weeks away in Australia, it seemed like a good time to start.

So, what am I going to be talking about? I’m going to talk about what I see as the basics of the actual design and implementation of a Social Networking website, covering software design, service design, infrastructure thoughts, technical architecture, database design and the like. Whilst I may at times post code, this won’t be a series where I post the entire codebase for a social network, and it’s quite likely that whilst I’ll talk about certain architecture or design decisions, I may not necessarily use them in the site I’m building.

And alongside all this discussion will be an actual social networking site, which already exists on one of my servers. Or rather, there are two versions, a mobile one and a web one, with the only difference between the two being the way the underlying data is accessed. My intention is to write both versions side by side, ensuring that each version is functionally the same, and provides roughly the same experience regardless of device used to access.

Obviously there will be some fundmental differences between the two sites, at least in the plumbing. For example, mobile devices don’t normally support cookies, so the basic concept of a server-side session needs to be forgotten about, which leads on to discussions on how to deal with persistence of information between pages for a single user. And on the web, this type of discussion is moot as there are session-based services that can be used for persistence.

But I’ll try not to get ahead of myself too much in this introductory post, and leave off with a quick rundown of the tools I’ll be using:
For the site development itself: Object oriented PHP (4.3+)
For the database: MySQL 4
Development Tools: Eclipse IDE, Firefox, Opera.

And yes, an early version of the site is already available and running - links coming in a future post :)