Designing the clone

Now that we have the list of features that we want to implement for Colony, let’s
start designing the clone. The design and implementation of this clone will be
described over this and the next chapter. We will start with the data model in this
chapter and move on to describing the application fl ow and deployment with the
next chapter.

Authentication, access control, and user management

Authentication, access control, and user management are handled much the same as
in previous chapters. As with the other clones, authentication is done through RPX,
which means we delegate authentication to a third party provider such as Google,
Yahoo!, or Facebook. Access control however is still done by Colony, while user
management functions are shared between the a uthentication provider and Colony.

Access control in Colony is done on all data, which prevents user from accessing
data that they are not allowed to. This is done through control of the user account,
to which all other data for a user belongs. In most cases a user is not allowed access
to any data that does not belong to him/her (that is not shared to everyone). In some
cases though access is implicit; for example, an event is accessible to be viewed only
if you are the organizer of the event. Note that unlike Photoclone, which has public
pages, there are no public pages in Colony.

As before, user management is a shared responsibility between the third party
provider and the clone. The provider handles password management and general
security while Colony stores a simple set of profile information for the user.

Status updates

Allowing you to send status updates about yourself is a major feature of all social
networking services. This feature allows the user, a member of the social networking
service, to announce and define his presence as well as state of mind to his network.
If you have gone through the Twitter clone chapter, you might notice that this
feature is almost the same as the one in Tweetclone.

The major difference in the features is in who can read the statuses, which can
be quite subtle yet obvious to someone who has read the previous chapters. In
Tweetclone, the user’s followers can read the statuses (which is really just anyone
who chooses to follow him or her) while in Colony, only the user’s friends can read
the statuses. Remember that a user’s friend is someone validated and approved by
the user and not just anyone off the street who happens to follow that user.

Status updates belong to a single user but are viewable to all friends as a part of the
user’s activity feed.

User activity feeds and news feeds

Activity feeds, activity streams, or life streams are continuous streams of information
on a user’s activities. Activity feeds go beyond just status updates; they are a digital
trace of a user’s activity in the social network, which includes his status updates. This
include public actions like posting to a wall, uploading photos, and commenting on
content, but not private actions like sending messages to individuals. The user’s activity
feed is visible to all users who visit his user page.

Activity feeds are a subset of news feeds that is an aggregate of activity feeds of the
user and his network. News feeds give an insight into the user’s activities as well
as the activities of his network. In the design of our clone, the user’s activity feed is
what you see when you visit the user page, for example http://colony.saush.
com/user/sausheong, while the news feed is what you see when you first log in
to Colony, that’s the landing page. This design is quite common to many social
networking services.

Friends list and inviting users to join

One of the reasons why social networking services are so wildly successful is the
ability to reach out to old friends or colleagues, and also to see friends of your
friends. To clone this feature we provide a standard friends list and an option to
search for friends. Searching for friends allows you to find other users in the system
by their nicknames or their full names. By viewing a user’s page, we are able to see
his friends and therefore see his friend’s user pages as well.

Another critical feature in social networking services is the ability to invite friends
and spread the word around. In Colony we tap on the capabilities of Facebook and
invite friends who are already on Facebook to use Colony. While there is a certain
amount of irony (using another social networking service to implement a feature
of your social networking service), it makes a lot of practical sense, as Facebook
is already one of the most popular social networking services on the planet. To
implement this, we will use Facebook Connect. However, this means if the user
wants to reach out and get others to join him in Colony he will need to log into
Facebook to do so.

As with most features, the implementation can be done in many ways and Facebook
Connect (or any other type of third-party integration for that matter) is only one
of them. Another popular strategy is to use web mail clients such as Yahoo! Mail
or Gmail, and extract user contacts with the permission of the user. The e-mails
extracted this way can be used as a mailing list to send to potential users. This is in
fact a strategy used by Facebook.

Posting to the wall

A wall is a place where users can post messages. Walls are meant to be publicly read
by all visitors. In a way it is like a virtual cork bulletin board that users can pin their
messages on to be read by anyone. Wall posts are meant to be short public messages.
The Messages feature can be used to send private messages.

A wall can belong to a user, an event, or a group and each of these owning entities
can have only one wall. This means any post sent to a user, event, or group is
automatically placed on its one and only wall.

A message on a wall is called a post, which in Colony is just a text message (Facebook’s
original implementation was text only but later extended to other types of media).
Posts can be remarked on and are not threaded. Posts are placed on the wall in a
reverse chronological order in a way that the latest post remains at the top of the wall.

Sending messages

The messaging feature of Colony is a private messaging mechanism. Messages are
sent by senders and received by recipients. Messages that are received by a user are
placed into an inbox while messages that the user sent are placed into a sent box.
For Colony we will not be implementing folders so these are the only two message
folders that every user has.

Messages sent to and received from users are threaded and ordered by time. We
thread the messages in order to group different messages sent back and forth as part
of an ongoing conversation. Threaded messages are sorted in chronological order,
where the last received message is at the bottom of the message thread.

Attending events

Events can be thought of as locations in time where people can come together for
an activity. Social networking services often act as a nexus for a community so
organizing and attending events is a natural extension of the features of a social
networking service. Events have a wall, venue, date, and time where the event is
happening, and can have event-specific pages that allow users to customize and
market their event.

In Colony we categorize users who attend events by their attendance status.
Confirmed users are users who have confirmed their attendance. Pending users are
users who haven’t yet decided to attend the event. Declined users are users who have
declined to attend the event after they have been invited. Declinations are explicit;
there is an invisible group of users who are in none of the above three types.

Attracting users to events or simply keeping them informed is a critical part of
making this or any feature successful. To do so, we suggest events to users and
display the suggested events in the user’s landing page. The suggestion algorithm is
simple, we just go through each of the user’s friends and see which other events they
have confirmed attending, and then suggest that event to the user.

Besides suggestions, the other means of discovering events are through the activity
feeds (whenever an event is created, it is logged as an activity and published on
the activity feed) and through user pages, where the list of a user’s pages are also
displayed. All events are public, as with content created within events like wall posts
and pages.

Forming groups

Social networking services are made of people and people have a tendency to
form groups or categories based on common characteristics or interests. The idea
of groups in Colony is to facilitate such grouping of people with a simple set of
features. Conceptually groups and events are very similar to each other, except
that groups are not time-based like events, and don’t have a concept of attendance.
Groups have members, a wall, and can have specific pages created by the group.

Colony’s capabilities to attract users to groups are slightly weaker than in events.
Colony only suggests groups in the groups page rather than the landing page.
However, groups also allow discovery through activity feeds and through user pages.
Colony has only public groups and no restriction on who can join these public groups.

Commenting on and liking content

Two popular and common features in many consumer focused web applications
are reviews and ratings. Reviews and ratings allow users to provide reviews (or
comments) or ratings to editorial or user-generated content. The stereotypical review
and ratings feature is Amazon.com’s book review and rating, which allows users to
provide book reviews as well as rate the book from one to five stars.

Colony’s review feature is called comments. Comments are applicable to all usergenerated
content such as status updates, wall posts, photos, and pages. Comments
provide a means for users to review the content and give critique or encouragement
to the content creator.

Colony’s rating feature is simple and follows Facebook’s popular rating feature,
called likes. While many rating features provide a range of one to five stars for
the users to choose, Colony (and Facebook) asks the user to indicate if he likes the
content. There is no dislike though, so the fewer number of likes a piece of content,
the less popular it is.

Colony’s comments and liking feature is applicable to all user-generated content
such as statuses, photos, wall posts, activities, and pages.

Sharing photos

Photos are one of the most popular types of user-generated content shared online,
with users uploading 3 billion photos a month on Facebook; it’s an important
feature to include in Colony. The photo-sharing feature in Colony is similar
to the one in Photoclone.

The basic concept of photo sharing in Colony is that each user can have one or more
albums and each album can have one or more photos. Photos can be commented,
liked, and annotated. Unlike in Photoclone, photos in Colony cannot be edited.

Blogging with pages

Colony’s pages are a means of allowing users to create their own full-page content,
and attach it to their own accounts, a page, or a group. A user, event, or group can
own one or more pages. Pages are meant to be user-generated content so the entire
content of the page is written by the user. However in order to keep the look and
feel consistent throughout the site, the page will be styled according to Colony’s look
and feel. To do this we only allow users to enter Markdown, a lightweight markup
language that takes many cues from existing conventions for marking up plain
text in e-mail. Markdown converts its marked-up text input to valid, well-formed
XHTML. We use it here in Colony to let users write content easily without worrying
about layout or creating a consistent look and feel.

Technologies and platforms used

We use a number of technologies in this chapter, mainly revolving around the
Ruby programming language and its various libraries. Most of them have been
described in Chapter 1. In addition to Ruby and its libraries we also use mashups,
which are described next.

Mashups

As with previous chapters, while the main features in the applications are all
implemented within the chapters itself, sometimes we still depend on other services
provided by other providers. In this chapter we use four such external services—RPX
for user web authentication, Gravatar for avatar services, Amazon Web Services S3
for photo storage, and Facebook Connect for reaching out to users on Facebook. RPX,
Gravatar, and AWS S3 have been explained in previous chapters.

Facebook Connect

Facebook has a number of technologies and APIs used to interact and integrate with
their platform, and Facebook Connect is one of them. Facebook Connect is a set of
APIs that let users bring their identity and information into the application itself. We
use Facebook Connect in this chapter to send out requests to a user’s friends, inviting
them to join our social network. The steps to integrate with Facebook Connect are
detailed in Chapter 6, Social Networking Services — Cloning Facebook 2.

Note that for the user invitation feature, once a user has logged in through Facebook
with RPX, he is considered to have logged into Facebook Connect and therefore can
send invitations immediately without logging in again.

Comments

comments