Week 10: Lightweights and Scalables

Our final Web 2.0 pattern is Lightweight Models and Cost-Effective Scalability.  A sort of amalgamation of all previous patterns, Lightweight Models and Cost-Effective Scalability means cheap, re-usable, easy to upgrade web-based solutions or services.  The service must be cheap to implement and easy to access (lightweight) and must be easy to modify and upgrade in the future (cost-effective scalability).  The ultimate goal is to get the products released sooner and cheaper, without sacrificing future growth or improvement.  We can start making money as soon as possible, start getting feedback as soon as possible, and begin upgrading and fixing the service after release.

This pattern is represented in almost all Web 2.0 applications.  It therefore makes it very difficult to pick one example to serve as a better example than any other.  So for the third and final time, we're going to talk about YouTube.

YouTube is a framework: a bare bones service that allows users to share, search, and view, and monetize their own content.  The greatest cost the YouTube has to bear is the cost of the servers required to store all that video, but YouTube can make that all back (and much more) simply by displaying advertisements on video pages.

YouTube doesn't have to pay for any of the actual content.  The cost of producing videos is born by the content creators.  YouTube's own marketing was almost entirely viral, and didn't cost YouTube a cent.  People started using it and telling each other about how great it was.

So, YouTube simply hosts content.  It doesn't pay for content, it doesn't pay for marketing, and it makes a boatload of cash with advertisements.

Week 9: Leveraging the Long Tail

Our Web 2.0 pattern for the week is "Leveraging the Long Tail".  The "Long Tail" is the large number of small niche successes that are increasingly making up the bulk of most products and services, and is distinct from the "Head", the comparatively small number of mass-market products.

"Leverage" is an over-used and under-defined business term that can be taken here to mean "finding success in", or "monetising".  So we must talk about a service that allows people to find success in The Long Tail, and what better example than our old friend YouTube?

Yes! YouTube, service for the sharing and distribution (and monetisation!) of video content.  YouTube may be the perfect example, since anybody can upload videos, and the people who actually want to watch those kinds of videos will be be able to find them easily enough with YouTube's already pretty stellar search functionality.

The popularity of it's videos and channels matches perfectly the graph given above.  You have a few channels that most people watch, but most channels only a few people watch.  Different channels and users are able to provide whatever content they want to provide, and the people who come to watch are watching only the videos that they want to watch.

Finally, YouTube allows you to monetise your channel!  This means that anybody with a YouTube partnership is allowed to gain advertisement revenue from people watching their content.  It's true that you require a large number of viewers to guarantee a large income, but nevertheless it remains true that those in The Long Tail can experience some monetary reward for their hard work.

Week 8: Perpetual Beta

This week, our Web 2.0 pattern is the "Perpetual Beta".  Providing a service on the internet removes much of the costs and problems once associated with software releases: you no longer have to prepare such-and-such a number of physical CDs, and prepare them in boxes to be shipped on certain dates to certain stores in certain countries to be put on sale at certain times.  The producers need only publish their work to a given web space, and the service is thenceforth immediately available to all users.

This allows for a great deal of flexibility in release schedules.  You don't need to release everything straight away.  You don't need to do a great deal of internal testing (the users can do this for you, for free)!  The result has been the "Perpetual Beta".  Release early, so your users get some of the functionality immediately.  Release often, because there is always an improvement to be made or a feature to add.

What example can I possible use this week?  The "Perpetual Beta" is applied, implicitly, to all Web 2.0 applications; it is a consequence of the development environment, the platform, and the user's demands.  So why not talk about Facebook?

You can use the Facebook Blog to get a reading on how many updates are made to Facebook's functionality over time.  The last post made on the Blog is dated 19 January 2012 at the time of writing, but in January alone of this year the Blog announced more than 10 new Apps based around Facebook's new "Timeline" feature, and the ability to listen to music with your friends.  December of 2011 including the release of the Timeline feature itself, and many improvements for Facebook on Android devices.  It seems like every month they're releasing some extra feature or improvement, and this is without people designing all kinds of apps and games for Facebook in their own time!

Facebook might have been good enough had it stayed the way it was a couple of years ago, but by taking full advantage of Perpetual Beta, Facebook is always being tested by its users, and improved by the developers.  Facebook gets better every month because of this, and therefore is an excellent service for displaying the power of the principles of the Perpetual Beta!

Week 7: Software Above the Level of a Single Device

This week's Web.20 pattern is called "Software Above the Level of a Single Device".  The PC is not longer the only device that can be used to access the internet (and, therefore, all the useful and interesting applications thereon).  It therefore behoves the developer of a Web 2.0 application to consider which devices will users want to use when accessing this service, where (geographically) they could access this service, and what extra opportunities we can explore given this information.

Our interactions on the web are increasingly spanning all devices and methods of communication.  A photo taken on a mobile phone can be sent by email to a friend who turns it in to a satirical motivational poster using a  free web application, which is in turn uploaded to Facebook where it is now accessible to all his friends.  Each of these services (email, de-motivator, and Facebook) are now accessible anywhere because they are increasingly being designed to work on as many devices as possible, especially mobile devices.

Twitter and Facebook

Twitter and Facebook are two of the most successful Web 2.0 applications.  A huge part of that success is due to their being designed for use on mobile devices.

Today, smart phone developers explicitly advertise that Facebook and Twitter are accessible from the device as part of the devices services.  This Android, actually has a Facebook button under the regular QWERTY keyboard: simply press it, and you can be connected.

That's not all.  Twitter and Facebook are connected to each other such that any post made on twitter can be automatically  shared on Facebook as well (where it's easier to have an in depth discussion, if such a thing is warranted).

Twitter:

Automatically on Facebook:

Week 5: Rich User Experiences

Back to obvious examples, with this week's Web 2.0 Pattern: "Rich User Experiences" or RUEs.

Since the internet (and it's associated technologies) are more powerful than ever, there has been a shift away from desktop applications (think Microsoft Office) toward online alternatives (think Google Docs). These online applications combine the best features of the desktop version (lots of functionality, and speed) with the best features of the online version (interactivity, easy of sharing, and simultaneous editing ability, to name a few).

Google Docs does provide a Rich User Experience: a free, fast, lightweight, easy to share, office suite that requires no download, no large install, and, technically, not even a desktop computer. It's capable of doing pretty much anything a traditional office suite can do (like Microsoft Office or Open Office): create and edit word documents, slideshows, spreadsheets, pictures (as in a Paint Program), tables and forms. Just about the only thing it doesn't provide is database management software (knowing Google, they probably see this as a serious issue that needs to be resolved).

After you create these many and varies pieces of work (or play) you can combine them, and share them, and let other people edit them, easily from the comfort of their own office (or smart phone). And it doesn't matter what device you are using, they're all compatible with Google docs. And, as if you needed Google Docs to be able to do anything else, it still allows you to download a copy of the document in pretty much any format you like (except for some proprietary Microsoft formats).

Is this User Experience not Rich?

Week 4: Innovation In Assembly

The Web 2.0 Pattern of the Week is Innovation in Assembly, or: what's the best way to actually build our services, keeping in mind the demands of our potential customers?

As we all know, Web 2.0 is defined by the consumer also being the producer. Previously we have talked about this in terms of the end product itself: media or information. But what about the services that provide this media or information? If the product itself is consumed and produced by the users, then why not the services themselves?

The Application Programming Interface

A program or service can have what is called an Application Programming Interface (API). This is, in basic terms, a list of functions that another programmer can have access too, and are taken from the base program. The API, in effect, "exposes" a bunch of useful tools and information that the base program already uses implicitly.

Why should an application have such an animal? Well, in almost all cases, it's because the original developers understand a couple of really important things:

1) We don't know everything about what our potential users may want,

2) We don't know all of the potential applications that our base program may have,

3) We can't work as fast as a large fanbase with the drive to make a new program (and the tools to do so) can, and

4) Free labour is free.

By providing an Application Programming Interface, the developers of the original service immediately give the users to ability to fulfil their own demand for a service they want for a very affordable price and no additional effort. How can you possibly say no?

Challonge.com

So far in these weekly discussions I have been talking about obvious examples of the pattern in question. This week I'm going to deviate, and talk about something that I already have some knowledge in.

Challonge.com is a web service that allows for users to create and manage their own tournaments. It's suitably abstract enough to work for any game or sport you care to name, but is most popular among the competitive video gaming community. It's fast, it's free, it's easy to use, and it's relatively customisable.

But, as if those things were not enough, Challonge also provides an API. Using the Challonge API you can create, delete, populate, and edit tournaments and players and their scores.

So, why would I want to use the Challonge API when organising my tournament? Well, the Challonge service itself doesn't allow for any more complicated tournament structures than the single elimination, double elimination, round robin and so on. It also doesn't recognise players over multiple tournaments, and so a players long-term performance isn't captured.

However, with the API, we can create complicated tournaments and remember who played in them, and what their performance was. For example, suppose we wanted our players or teams to play in a group stage, with an elimination "playoffs" (as most tradition sports competitions do) then we can used the API to create two separate Challonge tournaments (one a round robin, and the other single elimination) and have the winners of the first automatically placed as the participants in the second.

We can also relate all of this information in our own database automatically, to record our players performance. By using an API Challonge has given us to ability to tailor our own tournament system to meet our own needs. We required no additional help from Challonge itself, beyond the creation of the API, and we did it relatively cheaply (and it didn't cost Challonge a cent!).

How can you say no?

Week 3: The Importance of Data in Web 2.0

The Web 2.0 pattern for this week is "Data as the New 'Intel Inside'", or the importance of data in web 2.0 applications. This goes beyond the regular information that an application provides for it's users, but also includes the users personal details, habits, likes, dislikes, and friends, and probably many more things besides. It can also include "meta-data", categories, and generalisations. Most importantly, though, the data is linked. Users can know, therefore, what their friends like, or what things (movies, websites, t-shirts) they themselves might be interested in.

It's not merely useful to the user, either. Organisations themselves find a great deal of use for this data. For example, a company may need to know if their products are well received, or weather or not their competitors are having a better time reaching customers, or what advertisements work best on which websites at what times, and much more.

Today, I'll be talking about YouTube, and focusing on not just the videos that people make, but also what people watch, and why, and what people like, and how this information is used to make YouTube a great place to find (and publish) videos of all kinds for viewers of all kinds.

YouTube - Broadcast Yourself

YouTube is a video sharing service, which allows people to upload, view, and share a variety of videos of all types. Dozens of hours of video are uploading to YouTube every minute, and run the gamut from documentary, to comedy, to MIT lectures. All of these videos need to be categorised, and users need to be able to find the types of videos they are looking for. For starters we'll look at how videos are categorised, and then talk about how users (viewers) are associated with categories, and how YouTube then generates recommendations for the user based on this data.

Tags as Categorisation

When a user uploads a video, the user is asked to label it with "tags". These can be any combination of letters or numbers, technically, but are usually used to describe the video in question. A new video review for the movie John Carter, for example, might contain the tags: "review, john carter, movie, disney".

In a stroke, the video has been placed in four categories: videos which are reviews, videos about movies, videos about John Carter, and videos about Disney. All of these categories now "overlap" with this video, and also the system can begin comparing it to other videos that also share these categories. These videos (usually prioritised by popularity) will be displayed next to our John Carter review, and (assuming more reviews of John Carter exist) will include other John Carter reviews.

However, this is only the beginning of the systems data collection on what the user in question may want to watch.

User Views, "Likes", "Dislikes", and Activity

Each time a user views a video, the system takes note of many slight and important details, such as how long the user watched the video for. The use may also "like" or "dislike" the video in question. One might also "favourite" it (bookmarking it for later), or share it with one's friends (on a social networking site, say).

Whenever a user "likes" or "dislikes" a video, the system takes note, and begins to associate the user not just with the video itself, but with the tags the video is categorised with. If a user "liked" our John Carter review, the YouTube system would also (tentatively) associate that user with liking the categories "John Carter", "Movies", "Reviews" and "Disney". It has begun to get a sense of what content you like to see!

The more likes and dislikes a user has, the more precise (and certain) the YouTube system becomes at guesstimating which content the user wants to see. Now, on the YouTube homepage, when the user logs in, they will see a long list of "Recommended Videos" that match what the user likes. If our user, for example, also liked a Lion King tribute video, and an Aladdin parody, the system would become very confident that our user likes Disney films, and would recommend more videos of that nature to the user.

YouTube does more than count Likes and Dislikes, of course. If you favourited a video, then the system will assume that you like it. The same is true if you watched the video all the way through to the end. Conversely, if you closed the video straight away, the system would take that as an indication of dislike or disinterest.

How Data Collection Makes YouTube Better

So we can see that all of the data gathered by YouTube, and the way it is used, makes YouTube a tailor made experience for each user. The more the user uses YouTube, the more precise recommendations become, and the more user friendly YouTube becomes. It becomes much easier to find content that you probably didn't know existed by boldly recommending it to you on the front page.

All of this powerful customisation happens independently of a user subscribing to a channel. Indeed, the channels themselves (that is to say: other users) also have tags associated with them, and can be recommended in the same way.