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.

Week 2: Harnessing the Collective Intelligence

Our Web 2.0 pattern for week 2 is "Harnessing the Collective Intelligence", allowing our users to add value to our website or tool. There are many Web 2.0 applications and communities that enable this, but the most obvious (and important) example is Wikipedia.

"The free encyclopaedia that anyone can edit," as of today is has nearly 3.9 million articles in the English language. Every single one of those articles is the result of a collaboration between dozens (and, over the course of many years, perhaps thousands) of complete strangers. Apart from the occasional troll or vandal, all of these users had one goal: to add value to the article. In this case, "add value" means to make the article verifiably accurate.

Trolls, and Morons and Vandals (oh my!)

The Most fascinating aspect of Wikipedia is the ability of its users to immediately identify suspect information, and remove clearly incorrect (or inflammatory) additions.

One of Wikipedia's oldest and most common "problems" is that "well, since anyone can edit it, it might be wrong!" However, even without Wikipedia's own strict rules, contributors would happily contribute only information that they knew (and could prove) was correct.

Contributors are encouraged to submit sources for their information, and exercise cautious editing judgement in case the source itself is mistaken. When many users discover and summarise many sources, and contribute them to the article, the article becomes more complete and more accurate, and will even inevitably contain a section or two on non-mainstream interpretations of the information presented, or counter arguments from prominent proponents and opponents.

Success of Wikipedia (or: Take that, Britannica!)

In 2005, the journal Nature published an article that showed that Wikipedia was only slightly more error-prone than the Encyclopaedia Britannica, and that it contains around the same rate of "serious errors". This is, certainly, a vindication of the method: allowing users to add value to your website. By referencing sources, and triple checking each others additions, the articles become accurate and comprehensive. When you also add the fact that a web based encyclopaedia has no physical size limitation (as is the case with a traditional encyclopaedia), and is completely free to access (in this case thanks to donations) then Wikipedia must, in fact, be counted as superior to the traditional encyclopaedia.

New Blog!

Created this blog for use in INB 347: Web 2.0

Very interesting subject, it seems. Not as technically involved as I'd like.

This blog is going to be used to interact with other members of the class.