Start Small, Get Huge

The larger a vehicle is, the more fuel it consumes, the more power it needs to move, the more costly it becomes. This is no different to businesses or their products. Thanks to the ever-changing internet, it's possible for a lone man to do more than what entire businesses could twenty years ago. Smart organisations have noticed this, and adapted to exploit it. By changing to a smaller business model that utilises the internet, an organisation can cut costs and for more efficient solutions.


However, becoming lightweight isn't the entire solution. For example, an exploding demographic can easily overwhelm a service, or the competition may change their system to one that's more efficient. Indeed, a business needs to be flexible and scalable to remain competitive. Seth Godin described it best when he said "Get small. Think big." It means to deliver a big product or service, but in a way that minimises cost and resources.

 Some methods that enforce this behaviour include:

• Outsourcing whenever appropriate - Do calculations off-site or direct specific tasks to specialist services.
• Using loose coupling - Be able to change methods without changing the end result.
• Operating fast - Finding and solving problems earlier.
• Avoid restrictive solutions - Open-ended or remixable solutions enable flexibility.

It's interesting to note that this pattern often overlaps with the Perpetual Beta pattern. A beta may start small, allowing it to grow to fill its audience's tastes. Or a program that continues to evolve may adapt to its competition, or try to appeal to a newly-found niche audience.

There's a lot of roles that can be delegated off-site.
Finding the right methods and services to produce them can save
a fortune, which means success or failure to smaller businesses.

One organisation which "started small, thought big" was Mojang, founded near the end of their first project: Minecraft. Before Mojang was founded, it was just Markus "Notch" Persson, a lone programmer and developer.  Minecraft at this stage was a simple java game embedded in the browser, limited in features and especially buggy in multiplayer.


As Minecraft progressed, so too did its environment. In fact, the website could not keep up with the explosive growth of its user base: repeatedly the servers collapsed from the sheer number of users trying to play the online game. Quickly, Mojang changed its act: Minecraft was altered so people could play the game offline (albeit limited with some features) and found a different plan for its servers so it could cater for the increasing demand.

This quick action allowed Mojang to recover from an unfavourable scenario and averted complete disaster. If the group didn't rely on their host or act quickly, the interest in the game would have dwindled and possibly stopped altogether. As of today, Mojang has since "completed" Minecraft, and has grown both in number and in projects.

References:
OpenText, Low Cost Enterprise Scalability, retrieved 11th May 2012
Seth Godin (2005), Small is the new big
Mojang Homepage

Giving the Niche a Chance

Most real world vendors are restricted in what they can sell: they can only have so much space on their shelves and best business practices dictate that the most profitable action is invest in what is most likely to sell. Some products are too costly to produce or have too small a demand to justify ordering. As the internet evolved, most businesses adapted in order to take advantage of its features.

Being online allows vendors to sell products without physically having them on hand. The lack of such a restriction means the service can easily stock on a wider range of products, effectively allowing a vendor to supply to a wider array customers. Where there is demand, but not as much as the most popular products, is known as the Long Tail of an audience. Theoretically, all the less popular products combined are just as profitable as the "head" of sales.

The "Long Tail" is in yellow. Theoretically, all the less popular products
combined are just as profitable as the "Head" of sales.

One Web 2.0 pattern is to take this a step further: they aim to make the long tail more accessible and viable in order to exploit it. The easiest method to accomplish this is to allow users to sell their own products through the application. Akin to Innovation in Assembly,  those who utilise the service to sell their products share the same community as their customers. Ideally, the community should be able to meet its own demand.

Valve benefits especially from this pattern with its application Steam. Steam provides games, allowing customers to download, play, socialise and even keep their save data online. If a user makes a purchase, they have the ability to download the game as many times as they want (as long as their internet connection is capable, at least). While Valve has released several games for Steam, they also allow other corporations and even independent developers to sell through the platform as well.

One vital feature about Steam is that it avoid any form of production costs: all of its software can be downloaded online. Because of this, Valve have seemingly infinite "shelf space." In the same vein, developers only need to produce one copy, one that can be shared to any buyers. With packaging and delivery out of the equation, the games have less costs and therefore are easier to profit from.

So the platform Steam allows enables developers big and small to profit, but that alone doesn't guarantee sales. Valve has been fair to most (if not all) of its participants, featuring new games big and small as they are released. This free publicity assists the niche market, giving it the strength needed to compete against the popular mainstream market.


References:
Ajeet Khurana, About.com, Advantages of Ecommerce
Jason Van Dyk, (2nd May 2010), Leveraging the Long Tail using Web 2.0
Wikipedia, Long Tail article, retrieved 4th May 2012
Valve Steam Webpage

Eternal Unfinished

When software was updated, often users would either need to download the fresh new version or download a patch that updated the software itself. This effort relied on users to make sure software was up to date. Inevitably this would lead to compatibility issues with differing versions of software.

For web applications and services, this problem was less of an issue: only the internet application itself would need to be updated. Everyone who utilised the application was using the latest software. However, the service would need to deny access to users whilst updating. But then, there's cases where an application provides its services, but still updates behind the scenes. This is where the Perpetual Beta is most recognised; an online service or application that incrementally improving itself to suit its customers, possibly without denying them the service.


"Perpetual Beta" implies software that isn't quite ever finished, but it would be more accurate to say it's about updating software in small  but often bursts, as opposed to large patches. A website that continually improves itself gives the illusion of being alive as it evolves. There are several advantages to updating often and online over the traditional monthly patch:

• Gradual Changes ease new features into the system
• Lower risk of  implementing bugs
• Increased response to errors and feedback

Being in a state of constant development allows a business to release its product early and take advantage of the aforementioned perks. Unfortunately, the label "beta" is also used as a safeguard to protect the application and service. While users of the software will understand if a feature doesn't work, developers may grow complacent; focusing on features and new functionality whilst ignoring common bugs.

One site which has taken advantage of this pattern is Kongregate, a website dedicated towards flash games. Originally starting with the simple ability to play (and upload) flash games, record user profiles and record the games they play, Kongregate has slowly implemented features such as achievements, forums, contests and a "beta" section (where developers can test their games online and see how they look in the browser). When it began in 2006, updates for the website itself would only be made once every few months, but developers quickly adopted the "Perpetual Beta" format, adding new features and providing a better service for their users.

Kongregate's beginning was slow because there weren't many features or problems to patch, allowing its developers to cover all its primary functionality. When the core essentials were set up, Kongregate reaped the benefits of the developer pattern. The service was able to expand gradually with new features, services, and developers to focus on issues (usually because they were related to said  features).

The flash game website has been fleshed out over the years and continues to look for ways to improve its user experience, but it is never quite "finished."

References:
Steve Matthews, (10 August 2011), Perpetual Beta – The Real 21st Century Library Model?
Wikipedia, Perpetual Beta article, retrieved 28 April 2012
Bill (Praxis101), (17 May 2006), "Perpetual beta" means never having to say you're sorry 
Caroline McCarthy, (18 January 2007), Perspective: Beta--the four-letter word of Web 2.0
Kongregate Website

Suiting the System

The line "Software above the level of a single device" has been echoed by the Web 2.0 community ever since O'Reilly quoted it. The line is a simplified rendition of the final sentence in Dave Stutz's email to Microsoft after his resignation: "Useful software written above the level of the single device will command high margins for a long time to come." Unfortunately, the meaning of "above the level of the single device" is hard to discern. It is easier to simply read it as: "Don't restrict yourself to the one machine or you'll only limit yourself."

What this means is in developing software, sometimes it is ideal or even necessary to design for different platforms. With more and more technology being granted the abilities and functions of the standard desktop computer, developers have many options to choose from. Likewise, more technology opens up possibilities of how users interact with the software. A user at their desktop is more committed to their task, whereas someone out utilising their phone might only need it for a brief moment.

Software for different devices can be comparable to furniture.

However, it is not enough to simply release the software for different platforms: the software must be tailored to suit the device. Adapting software to multiple devices is often a difficult task due to how differently the platforms can operate. Just converting a program for a different operating system can be a daunting task, especially if the software is especially large in scope. For every target platform developers intend to release their software on, they have to take into consideration:

• Programming language(s) accepted by the platform
  
• Inputs and outputs of the device
• Capabilities and requirements of the device and its platform.

These issues are easier to deal with earlier in a project's life, where design choices are not set in stone and changes can be made with little repercussion.

One instance of poor tailoring can be seen as old as Sonic the Hedgehog 2, which was originally released for the Sega Master System and later released for the Sega Game Gear. While the controls easily translated between the two, developers skimped on an important detail: the game gear's smaller resolution. With no custom graphics or changes to level layouts to compensate, the player had less time to react to obstacles on the screen. Although technically the same game, the game gear version was much more difficult to play.

On the other hand, Adobe downsized the famous image editor Photoshop from a desktop application to something that works on a mobile device: Photoshop Express. The functionality of Express is limited in comparison to its origin, due to the hardware capacity of the mobile phones. However, it also includes the ability to save images online so the user can utilise or display their skills. Having an online profile that stores user's images is almost a necessity for the mobile product as mobiles can't store too many images.

Both editions for Photoshop represent their respective devices well: the desktop Photoshop is a complete workstation, allowing the user to sit down and focus on creating a masterpiece whereas Express is more interested in short, portable sessions and online support. These differences utilise the benefits of their own platforms and therefore provide appropriate services.


References:
Paul Cooper, (10 Dec 2007), Software above the level of a single device
Dave Stutz, (2003), Advice to Microsoft regarding commodity software
Sonic News Network, Sonic the Hedgehog 2 (8-bit), retrieved 20 April 2012
Adobe Photoshop Homepage 
Aaron Chan, (18 March 2009), Cross Platform Development and Porting, retrieved 21 April 2012
Mindfire Solutions, (14 January 2001), Porting: A Developer Primer

A Wealth of User Experience

Compared to days of yore, where a website was simply a collection of static pages. The information a single page could have was often typed in manually,  As the average computer has improved, so too have the interactive capabilities of the standard website.  Development has reached the point where some web applications and services could easily be mistaken for typical desktop applications. A modern website which provides a high level of interactivity is considered to be utilising a Rich User Interface.

For an application to qualify as "capable of providing a Rich User Experience," two criteria must be fulfilled:

1. It must be interactive.
2. It must use connectivity.

One point of interest is that the criteria do not explicitly mention web browsers or web pages. This is because it's possible to have several Rich Internet Applications within either platforms. Typically provided through any combination of tools and languages including HTML5, Microsoft Silverlight and Adobe Flash.

Not all interactivity is good for a Rich User Experience.

Desirable features for a Rich User Interface can include:

• Focus - Through modal windows, sliding layouts and using tabs, it's possible to hide information or boxes until the user actually requires it. One example would be a log-in box that won't show until the user clicks to log in.

• Context Sensitive Input - The interface should expect the user to utilise key presses and mouse movements (or other inputs) and react accordingly. Some of the more advanced sites that allow replying or commenting automatically bold or italicise text when a user presses the standard hotkeys.

• Dynamic data - The information provided is live, connected to a database. If a user searches through the products of an online store, the store should provide an active list of its products as opposed to a static table of data that was typed in manually.

What's important here is these three features alone fulfil the above criteria. Focus and CSI react to the user's input, and therefore make the application interactive. Whereas dynamic data can only be provided if the application has a connection to a database.

One website that I believe provides a fairly rich user interface would be Blogger itself. Although a blog owner has access to more features and controls, the typical blog page will suffice in satisfying the above criteria:

Blog Features

• The blog owner may edit, remove or otherwise modify their own page. (Interactive)
• Users reading the page may comment or reply to other comments. (Interactive)
•  If replying, the input box shifts underneath the targeted comment. (Focus)
• Displays  how many comments a post has and (if viewing a specific post) the comments themselves (Dynamic Data)
• It displays all the blog's posts in order, from most recent to least recent. (Dynamic Data)

Without becoming an exhaustive list, the standard Blogger post could be considered a Rich User Interface. While the blog itself doesn't provide much context sensitive input, users can still interact by commenting. Likewise, the comments and related blog posts are dynamic in themselves.

References:
Travis Stiles (2005), Rich User Experience, Retrieved 30 March 2012 
Florian Moritz, Rich Internet Applications (RIA):A Convergence of User Interface Paradigms of Web and Desktop, Retrieved 30 March 2012
Cameron Chapman (21 June 2009), 7 Rich & Creative User Interfaces and How to Create Your Own, Retrieved 30 March 2012
Blogger Website

If They Can Build it, They Will Come

Sometimes, a business doesn't have the funds, the skills or the time to develop and maintain their service. Or perhaps, they quite simply want to tap into the skill and abilities of its users. By releasing a free application programming interface (API), there's a chance that the users will begin to build upon it. In other words, it's Harnessing the Collective Intelligence. However, it is aimed towards a select sort of members in the collective: the developers.

Imagine, that crowd of many skills, tastes and perspectives. Imagine they all want to improve the software, and have the capacity to do it. This is the potential of open source and open API. If there are issues with the software, the volunteer developers will find it. If there's a new feature that could be used, it can be developed by the people, for the people. This practice is known as Innovation in Assembly.

However, it isn't as simple as releasing an API (although that can happen). Rather, akin to harness collective intelligence, an API needs to be made attractive to the users. The more an API appeals, the more likely a skilled and insightful developer will utilise it. Several guidelines for Attractive APIs can include:

• The API is easy to access and easier still to use.
• The service is useful and the API can add to or use it in a new way
• The business trusts their customers, and learns from them.
• Documentation is clear, concise and possibly in different languages.
• Having a business plan in place to consider possibilities

Mozilla's Firefox is an interesting case. A simple web-browser that intentionally started off open-source has a variety of languages that enable users to contribute an incredible array of add-ons and tools. What makes it an interesting case is that amidst the add-ons and extensions, the community has contributed APIs for the platform, enabling new platforms within a platform.

On Mozilla's own site, they listed five main objectives:

1. Non-profit - Firefox is and always was free, people could donate if they felt it a worthy cause. This also enabled users quick and easy access to the browser.
2. Track record - It claims to have a long history of making decisions for individuals and the Web as a whole. By making decisions that aim to be a win for everybody, Mozilla has acquired many loyal customers.
3. Empowering - In contrast, they display their trust in the community by enabling the ability to modify and contribute to the software. 
4. Community - A powerful display of a harnessed collective intelligence; the customers are the developers.
5. Challenger spirit - When Firefox first came out, it directly challenged Microsoft's Internet Explorer as a browser. Skip a few years later, and it still remains a strong competitor in the market.

Firefox is a powerful demonstration of Innovation in Assembly, as it relies heavily on its community to add functionality and security to the software. It becomes rather evident that Mozilla's objectives were parallel to typical API guidelines, which is why Firefox has had such success.

References:
Nalla Senthilnathan (2004), How to design good APIs and Why they Matter, retrieved 23 March 2012
Marieke Guy (2009), What Makes a Good API then?, retrieved 23 March 2012
Mozilla, Mozilla Firefox Homepage, viewed 24 March 2012
Mozilla, Firefox Brand Toolkit, retrieved 24 March 2012

Knowledge is Power

While Harness Collective Intelligence focuses on users being the ones who contribute and improve on the Web 2.0 application, there's a side that the business must focus on. A variety of blogs coin it as Data is the Next Intel Inside, but I believe its easier understood through the idiom: knowledge is power.  Having data on a user or a subject enables the ability to act with that data in mind. If you knew your friend liked orange juice, you'll be more likely to look for orange juice should you both stop for a drink. Businesses have discovered this potential in data, resulting in Data Mining.

A business has to get data first. Though there are two general paths one can take: generate the data or acquire the data from an outside source. Generating data can be an expensive task, especially if the business covers an undeveloped topic. Acquiring data typically comes from two different sources: other businesses or the consumers themselves (the collective intelligence).

The hardest part of data collection and processing is knowing how accurate it is. If you were told your friend liked orange juice, but in reality they had allergies, the resulting situation could be catastrophic. Trying prove generated data to be accurate can be one of the factors why generation can be so expensive. On the other hand, this is where Harnessing the Collective Intelligence can really shine. It was established in my previous post that the collective intelligence generally brings more to a business than its own staff. Users implementing and criticising their own data frees the business' hands and allows them to focus on what to do with the data.

But before the business can act, it must address the concern of "who actually owns all the data?" While a business who generated their own data could claim it as all as theirs, one that relied on a collective intelligence may find this to be a stickier problem. Depending on the End User Licence Agreement, a user may take down their information at any time, or it will continue to be stored within the business databases even after deleting their account. There are some instances where the data belongs to nobody in particular, and the business simply organises it for easier use.

Once a business has organised their data, recognised its source and what they can or can't do with it, it must then decide how to utilise the data, whether it be shared to other businesses, analysed to provide better products. What the business decides to do with the data depends on whether it aims to be a supplier, consumer or even a combination of the two.

One such business that works with its data is YouTube. The video streaming website has been around for years because it understands just how vital information can be. To start with, YouTube gathers users' view history, likes, dislikes and favourites. With this data, YouTube can cater to advertisers and users alike. Advertisements can be attributed to the right videos and users receive advertisements and recommended videos more relevant to their own interests. User activity can be an indicator to what's currently popular and how often each channel updates. Furthermore, if a YouTube user is popular and active enough, YouTube can reward the user by offering them a partnership.

But who owns what data? Grant Cowell summarised it up as "the user will always have the ownership of their content, but by signing up and using the website, they grant YouTube to do whatever it wants with the videos." Implicitly, users are putting their trust in YouTube to not do anything nefarious with their videos and data. But YouTube is required by law to monitor the videos it distributes. If a user uploads content that is offensive or infringes copyright, YouTube may remove it in order to protect itself and its users. Being granted the freedom to do what they want implies to users that YouTube expects them to obey the rules. This circle of trust between YouTube and its users allows the site to prosper whilst dealing with the technicalities of data ownership.

 References:

Albion Research Ltd. (2012), Why should I be considering Data Mining?, Retrieved March 17, 2012

YouTube (2012), Advertising with YouTube, Retrieved March 17, 2012

Grant Cowell (2011), Who owns your YouTube video? You, Youtube, or Someone Else Entirely? Retrieved March 17, 2012