Masashi Narumoto's Blog

Project Kobe community feedback

Masashi — Fri, 17 Apr 2009 02:11:36 GMT

A project that we recently worked on in my team is Kobe , a Web 2.0 service development resource kit. The goal of the resource kit was to provide a collection of resources in the form of presentations, white papers, and a working sample application to enable business and technology decision makers to develop a good foundational understanding of Web 2.0 services, a conceptual architecture of a Web 2.0 service, challenges to think through when embarking on a new Web 2.0 service development project, and Microsoft platform implementation assets that are available and can be applied to materialize Web 2.0 services. The intended value of the resource kit is in the collateral in the form of the included presentations and white papers that delve into these topics. Also included in the kit was a sample application that was implemented to illustrate the materialization of the concepts discussed in the presentations and the white papers within the context of a sample scenario.

Lately we have been received some very good feedback from the developer community on the completeness of the sample application's code implementation. I am writing this post to acknowledge the feedback, and to communicate that we are looking into addressing some of the key issues comunicated and will publish an updated version of the sample application's code shortly.

While we are eager and happy to do this, we would also like re-clarify the original intent of the sample application included in the Kobe kit. The sample app is not a "reference application" in the context of code completeness. A "sample app" and a "reference app" are quite different in the context of code completeness, and we do not claim Kobe to be a reference app in this context. The Kobe sample app is a "sample" intended to illustrate the Web 2.0 service architectural concepts discussed in the included presentations and white papers, in a tangible way and in as light weight a manner as possible. It was not intended to be production ready in the context of code completeness, and hence positioned as a sample app when we released the kit. That being said and based on the feedback we have received, we are very eager to address the issues that have been communicated to us since and ensure that we can deliver an updated and a best possible sample app in the refresh release.

Many thanks to all those who have shared their feedback on Kobe so far! We will review all sumitted feedback and take action to address items within the context of the intended scope & goals of the Kobe project. Stay tuned for a posting announcing the availability of the updated version sample app.

Regards,

Masashi & Karthik

Kobe

Masashi — Wed, 08 Apr 2009 05:57:56 GMT

Do you think Web2.0 is dead? We hardly ever see it on the blogs and news right? It might be the sign of good things to come. It could be emerging into the “slope of enlightenment” at the Hype Curve. Anyways, we certainly see a number of trends(opportunities) in this industry including…

- The idea of Collective Intelligence has changed the consumers’ online experience.

- The notion of composition through API enables any developers participate in the service evolution.

- Online social communities drive the huge traffic.

List goes on.

Why not incorporate these capabilities into your application? Need a guidance on building them? Here is a resource kit for you.

The Microsoft Platform Architect Team recently released a Web 2.0 service development starter kit with resources (presentations, white papers, sample code) that provide an overview of the emerging web and drill into the aspects of planning, architecting, and implementing services for the emerging web. This is a useful collection of resources for ISVs to get to speed with the emerging web trends and obtain an overview of planning, architecting, and implementing services for the emerging web. The kit can be downloaded from here.

Technorati Tags: Kobe

Contextual Service Example

Masashi — Fri, 28 Mar 2008 21:42:46 GMT

To explore further the way context-aware services can be implemented and integrated into large communities, let’s travel a short distance into the future, to a time when the ideas in this article have borne fruit in the real world, and consider the hypothetical case of an online TV broadcasting service being integrated into a social networking site. In this example, we assume that the SNS is very large (over 100 million users), with specialized communities for interests like travel, sports, and so on; and that providers such as TV broadcasters, commerce sites, travel agencies, and more are offering services that accept context information. This SNS aggregates those services to provide users with a comprehensive experience. Further, assume that both the SNS and the television broadcast service restrict access to subscribers, and that the SNS supports user account federation so user profiles can be shared between services and users don’t have to log in to each service individually.

Our sample SNS sports a rich user experience built on Windows Presentation Framework (WPF).

The user community is represented as a virtual globe, with avatars representing users covering the surface of the globe. For each user, the avatars of his or her friends appear closest to the user’s own avatar on the globe, with friends-of-friends appearing farther away, and so on. Users can click and drag the globe to travel across its surface and find more users, giving the community a complete 3-D experience.

Every user is given a space in which to store the digital data of his or her life, like mail, calendar items, blog posts, etc. For example, a video blog function lets each user post videos from his or her life and share them with friends.

Using the site’s visual metaphor, users can seek out friends and see the information they’ve made available. Focusing on a friend will reveal that friend’s public data for viewing.

This is where context-aware services come in. Recall that user context is the mechanism that ties community and services together and integrates them. When traveling around the community, each user carries his or her context around like a calling card that contains not only the user’s basic account details but also relevant details about the user’s purpose in accessing the site—the five Ws and one H. For example, suppose a user views a list of the most popular tags attached to video blogs in a specific community on the SNS—a popular feature that provides a snapshot of what is happening in the community, in this case the student body of a university.

In this view, the service lumps all video content together, including content created and offered by the SNS itself (first-party content), video blog entries produced by users (second-party content), and embedded video clips provided through a consumer-oriented service offered by a TV network (third-party content).

When the user clicks a tag, the SNS software records his choice along with elements of his user context. For first- and second-party content, the site presumably makes use of this contextual information to aggregate user likes and dislikes in order to improve the community. If the user requests third-party content, these user context elements are transmitted to the service provider along with the content request. In “five Ws and one H” format, the transmitted user context includes the following:

· Who: The user’s account lists him as a 30-year-old male.

· Where: The IP address indicates that the user is staying at a particular hotel in Tokyo, Japan.

· When: The request is made at 9:00 pm, while the user is engaged in an online conversation with friends.

· What: From the list of popular tags, the user chose “Michiko Osada” (the name of an actress).

· How: The user is running the SNS smart client application on a desktop or laptop PC.

· Why: By tracing the user’s actions, the SNS software determines that the user is interested in previewing different television programs.

From analyzing thousands of requests made by users of this SNS and others, the TV network and other providers can detect patterns of usage and determine that users with similar user contexts often have similar tastes and interests. When the TV network service transmits the clip the user has requested, therefore, it also transmits a list of other video clips the user may find interesting, based on choices made by similar users in the past.

(In this case, users in the student community have made thousands of past requests for this particular clip, enough to make it the top recommendation for this user in this context. For users in other communities with different user contexts, the recommendation could be different. For example, in a community devoted to fashion design, the top recommendation might involve a signature piece of jewelry the actress often wears.)

The SNS smart client application shows these recommendations in a list appearing beneath the preview area at the lower right of the screen, as seen above. By scrolling through the list of recommendations, the user can access these additional clips or other content offered by other service providers without leaving the SNS environment.

By clicking a preview, the user begins watching the program, which appears in the main area of the screen. The content includes metadata that allows members of the community to share opinions on it using tagging, recommendations, and commenting. In the illustration below, a comment window appears at the bottom of the screen so users can share their opinions on the clip while watching it.Although the notion of sharing comments among users is already implemented in some services, this service offers an additional feature which enables you to specify the boundary of your comment sharing. That said, you can share your opinion only with your friends if you wish . You might argue it's a subtle difference but it produces a tremendous advantage in the user experience.

This hypothetical SNS software allows users to watch video content either within the application, or on a television equipped with compatible media center software. By choosing to view the full program on TV, the user transmits his user context to the service provider again. This time, it’s slightly different:

· Who: 30-year-old male.

· Where: A hotel room.

· When: At 9:10 pm, about 10 minutes after requesting the preview clip.

· What: The same tag (“Michiko Osada”) that led the user to the preview in the first place.

· How: Via the media center application on a compatible TV device.

· Why: The user has viewed the preview clip and now wishes to watch the entire program.

While watching the program on the hotel’s TV system with broadcast-quality picture and sound, the user can use his computer to supplement the experience with the SNS. For example, the program the user is watching is about Kazutoyo, a famous samurai in Japanese history. The name “Kazutoyo” appears on the SNS as a tag associated with the program. When the user clicks the “Kazutoyo” tag, the application makes search requests to several different services, transmitting the following user context:

· Who: 30-year-old male.

· Where: A hotel room.

· When: At 9:30 pm, while watching television.

· What: The tag “Kazutoyo.”

· How: Using the SNS application on a PC.

· Why: The user has encountered the tag on the SNS and wishes to browse any information associated with it.

Different services would return different responses, such as Kazutoyo-related merchandise or information about Kazutoyo’s birthplace and options for traveling there. By observing and analyzing what the user does with this information, the SNS can trace the chain of the user’s curiosity, which it can use to refine its future estimations of user contexts.

User context is the key to bridging the gap between social communities and commercial services in order to create a true digital lifestyle. By offering services that can accept and understand user context metadata, providers can help denizens of online communities enrich their experience with content and features tailored to specific interests. In turn, users and communities can take advantage of these services to improve the communities themselves.

Contextual Service

Masashi — Mon, 24 Mar 2008 21:54:56 GMT

User context is the mechanism by which service providers connect consumption with delivery in a user-centric way. Journalists adhere to a maxim commonly called five Ws and an H. According to this principle, a complete and proper news story must answer six questions about its subject: who is involved in the story, what happened, where it happened, when it happened, why it happened, and how it happened. By promptly answering these questions, preferably in the first few paragraphs of the story, the journalist conveys the most important points to the reader as quickly as possible, and can devote the rest of the story to providing context and additional details.

Similarly, when developing a community-aware service, you can use the five Ws and one H to understand your audience better. Try to answer the following questions:

· Who are your users? What traits do they share, and how do they differ? For developers of specialized services, this question may be easy to answer: sporting content will naturally be of interest to sports fans, streaming video of classic movies can be expected to attract film buffs, and so on. For general-interest content, the user base may be a bit harder to nail down, although you can still look for reasons users would be attracted to your service rather than someone else’s.

· Where are your users? What countries or regions are they from? Do they access your content from home, work, school, or elsewhere?

· When are they interested in accessing the content? The answer can simply involve the local time and time zone, or it can be expressed situationally: for example, the user may wish to access the content while chatting with friends online.

· What do they want from their experience, and why? This information is difficult to gather directly, but you can often infer it by paying attention to the community itself: the conversations users have, the tags they create and use, the interests shared by users of the specific community itself, and so forth.

How do they access the content? As the use of alternate devices continues to grow, this will become an even more important question.

The user context, then, is metadata that accompanies the user and captures his or her current needs and circumstances as accurately as possible, in the form of answers to these six questions. Some of this metadata, like time, place, and user profile information, would typically be sent along with the request directly, and some would be synthesized by the provider based on other information. For example, a request sent through a specific user community could carry a unique ID string identifying the community. A provider can learn about the “character” of different communities by detecting ways in which requests from a given community tend to resemble each other over time. For example, if requests from a certain community tend to involve travel-related subjects, the provider can recognize future requests from that community as potentially involving travel as well (in other words, “travel” becomes part of the answer to the “why” for such requests). If the user ID string is blank, the request will be treated as anonymous, as in the current access model.

Some examples of user contexts in real scenarios:

MSDN

When

Time

N/A

Where

Home, office, mobile

N/A

Who

Age, nationality, gender

Developer; architect

How

Device

Programming language

What

Program (tag)

Class library; article

Why

Pre-view, watch

Extend office system

Context can be captured and transmitted in different ways for specific providers. For example, developers typically interact with MSDN through Visual Studio’s built-in assistance mechanisms, by visiting msdn.microsoft.com using a Web browser, or a combination of the two. By capturing the user’s method of access, MSDN can respond appropriately to provide the best information to the user depending on context.

Connecting Users with Information

In addition to providing users with contextually appropriate information, you can make recommendations to individual users based on the preferences and choices of other, similar users. In this way, you can create semantic connections between different pieces of information and make users aware of new and potentially useful things.

The picture below illustrates the core concept of user context.

1. Users make requests to services with their individual contexts (who, what, where, when, why, and how).

2. Services send back the list of choices that best fits the context.

3. When the user makes his or her choice, it creates additional metadata that enables further context-based categorization of the information.

4. As a result, the recommendations provided to users with similar contexts can be improved.

Over time, this process makes it possible to categorize information according to some fairly specific criteria, such as “the most popular handbag among females in their thirties residing in Milan, Italy.”

Improving Service Quality

Context can be used to analyze user behavior. For example, by examining context you can determine whether different types of content appeal to specific demographic categories: users of a certain age, of one gender or the other, and so on. Because user context addresses not just requests themselves but also the reasons and motivations behind them, it can contribute valuable intelligence that can help you predict future demands and changes in behavior patterns.

Looking even more boldly into the future, we can envision a time when user context is as much a part of a person’s identity as his or her name. If it becomes practical to store one’s entire life online, user context can be expected to play an important part in integrating and tying together the disparate parts into a cohesive whole.

Architecture for Consumer Oriented Services Cont'd

Masashi — Tue, 05 Feb 2008 00:10:43 GMT

At the previous post, I wrote a picture below to illustrate the architecture for consumer oriented services. Now let me explain each architectural elements as follows.

Propagation Architecture

The propagation architecture concerns the mechanisms by which users can share your service with others.

The number of users you can reach directly through conventional promotional activities is dwarfed by the tremendous number of users of social network sites, blogs, and other online communities that form the long tail of online activity. By providing services that are easy to share and embed, you can take advantage of the viral propagation channels that arise naturally within successful online communities.

Of course, just because a service is easy to share does not necessarily mean that users will share it. Users won’t propagate your service unless they are motivated to do so, because they find it personally compelling or believe others will benefit from it. User context is an important factor that determines how successful a consumer oriented service will be. User context, in the form of computer-readable metadata, can potentially connect like-minded people much more effectively than current mechanisms like comments and recommendations. It can make propagation much more natural without requiring a great deal more effort.

To be useful to the target audience, a service has to fit into users’ lifestyles. This includes providing content in manageable units, supplying community mechanisms along with the service, and taking the end-user experience into account.

The “delivery unit” of the service should be small enough to be easily manageable in a variety of contexts. For example, consider an episode of a popular television program made available as a service. An entire, unbroken 30- or 60-minute program might be unmanageable and inhibit user sharing. Providing key scenes lasting only a few minutes each, on the other hand, might be more likely to compel users to watch individual scenes through to the end, and to share them with friends.

Including mechanisms like tagging, recommendation, evaluation, and commenting can encourage the formation of communities and make it easier for users to find services that interest them. Social networking sites that allow the embedding of third-party services often have their own community mechanisms, of course, but that doesn’t preclude service providers from offering theirs.

Consumption Architecture

The consumption architecture determines how users access your service. In the current prevailing consumption model, users typically visit a Web site that offers the desired content or service, perhaps after locating it through the use of a search engine, and then consume it by viewing or interacting with it through the Web browser. While this is a reasonably useful and intuitive model, it has several deficiencies that the coming generation of consumer oriented services will be tailored to address.

Consumer oriented services should offer a rich user experience that is personalized, contextual, and interactive. The web page, accessed through a browser application on a desktop or laptop computer, remains the base unit of content and function on the Internet in the popular imagination, but that may not last much longer. Techniques like Ajax and DHTML threaten to render the static “page” metaphor obsolete, and the future will likely bring further convergence between the desktop and Web-based user experiences.

In the future, too, providers will continue to tailor their services to provide a rich user experience on a variety of alternative devices, including televisions, PDAs, mobile phones, video game consoles, and portable media players. The importance of such alternative devices is increasing as their popularity rises; many offer rich multimedia experiences, including sound and full-motion video. It may make sense to target users of these devices as well as users on the desktop, perhaps offering enhanced experiences that take advantage of the unique strengths of various alternative form factors.

With users moving effortlessly between house and car, between computer desk and living room, providing a seamless user experience is an important component of the so-called digital lifestyle. The user experience for your service across all targeted devices should be as consistent as the form factors will allow, with little or no customization or configuration required of the user. When possible, the service should be optimized to provide some subset of features in a disconnected state, with the transition between connected and disconnected states handled seamlessly by the software. If users can incorporate your services into different aspects of their lives in a minimally intrusive way, they are more likely to only to use your service more frequently, but also to share it with others.

Composition Architecture and Federation

The composition architecture enables your service to integrate with other Web sites, platforms, or devices. The composition architecture can be said to have three tiers, representing users, providers, and intermediaries (aggregators).

User Tier: Mashups

As the Web moves from a universe of static, monolithic pages to one of dynamic, modular components, one of the more notable and innovative trends in Web site design has been the emergence of sites that combine custom code with services from one or more external, independent providers in a seamless, integrated interface that provides access to many different functions, regardless of origin.

Compared to business-to-business (B2B) interfaces, which can be very complicated and strict in order to facilitate the seamless integration of large systems, business-to-consumer (B2C) Web services tend to be structured more casually. At the heart of the consumer oriented service ideal is the notion that the service provider supplies all the tools necessary for other parties to consume and integrate a service. In the tradition of the Internet, services are provided using open, published interfaces to which any authorized consumer may connect, and (aside from possibly creating accounts or usage tracking identifiers) the provider does not need to add components to its own infrastructure to accommodate individual consumers. This casual integration can be accomplished using a number of different techniques.

One way to provide such services is through ordinary HTML techniques that use the markup language’s hyperlinking and object embedding features to provide content and behavior from external sites within a Web page. This can be as simple as a static graphic that shows current weather conditions at a particular location, or it can return custom information and function through Representational State Transfer (REST) techniques. For example, several popular social bookmarking services provide graphics and code that providers can include in their pages to allow users to submit content easily to the services. It’s not uncommon to see a row of icons at the bottom of blog posts and news stories encouraging users to submit them for discussion at several different community sites.

For more elaborate functionality, providers often expose content and functions for consumption using XML-based web service protocols like XML-RPC and SOAP, as well as non-XML serialization formats like JavaScript Object Notation (JSON). Objects exposed using these techniques can be made available to server-side code on the target systems and used to integrate content and functions from a number of different sources tightly into a single Web page.

Providers commonly offer data and methods together as web APIs, which can be implemented in a number of different ways. This has led to the emergence of the mashup as an easy, lightweight mechanism by which even amateur Web developers can combine services in innovative ways. Mashup creation has proven popular with commercial sites and hobbyists alike. Map services are popular with today’s mashup makers, as are services that allow people to share media like photos and videos. As providers implement web APIs and other mashup tools more widely and they become more accepted, expect to see business data offered for integration, as well as additional lifestyle features like shopping. Ideally, information exposed by these services will be semantically meaningful through metadata, so that it can be included in integrated search results.

Intermediate Tier: Aggregation

An intermediate tier aggregates services from multiple providers, rather than providing services of its own. The proliferation of services provides an opportunity for aggregators specializing in particular subjects or subject areas to arise. For example, an aggregator specializing in marine biology might offer access to a comprehensive selection of marine biology-related content from different providers: video clips, photographs, book excerpts and articles, and so on. We can expect to see vertically-oriented aggregators emerge soon as a major service category.

Provider Tier: Federation

In addition to the benefits explained under “Choosing Platforms,” above, relying on major platforms can make it easier to federate with other providers. By federating with other service providers, you can offer users more information than you’re able to supply on your own. If you provide a service that offers information about restaurants in a metropolitan area, for example, you’re unlikely also to specialize in logistical information like driving directions or mass transit information. By federating with providers that do offer this specialized information, you can offer a service that combines these two kinds of information in an integrated whole that is uniquely capable of capturing the user’s interest and curiosity.

Federation also makes it possible to integrate multiple services that each rely on user authentication. Ordinarily, users must authenticate to different services individually, which can be difficult or impossible. Federation makes it possible to give users single sign-on access to a number of different services from different providers, each of which can track and log the user’s activity as appropriate for that service.

In addition to user ID information, you can federate data and functionality. This makes it possible to offer a service that incorporates functions like e-mail and chat to encourage users of the service to conduct active conversations, reinforcing the idea of community.

Delivery Architecture

The delivery architecture defines how your service is deployed and how users access it, including hosting arrangements, the targeted end-user experience, and the nature of the service itself.

Consider the nature of a consumer oriented service: Its purpose is to provide access to information, functionality, or both to multiple end users in a contextual manner. Depending on its nature, it’s required to capture user’s intent and provide services in a manner appropriate to that intent. There are a number of ways to capture user’s intent. I will show you some of them in upcoming posts.

Besides, the end-user experience encompasses things like users’ available bandwidth, the devices they use to access your service, and their geographic location. If you have or anticipate a large number of users with wireless-enabled PDAs, for example, you might consider offering a smart-client interface to your service that’s tailored to the handheld form factor and includes offline functionality to make the service usable as the user passes in and out of wireless range.

Programming Architecture

By providing developers with a public API, you can create a “hackable” platform developers can use to modify and enhance the underlying service in a number of ways. APIs are a popular way to provide developers with a programming interface for lightweight, dynamic languages.By giving external developers the ability to enhance some features of your service, you give the service itself the power to evolve over time.This phenomenon is in evidence at a number of major SNS and portal sites.

Core Service Architecture

Consider your needs in the following areas related to core service:

· Consider how your content can be optimally indexed for conceptual requests.

· Consider how your content can be optimally indexed for specific communities.

· Determine your schema for both provider-generated and user-generated metadata.

· How will you identify your users? Consider the user attributes you’ll want to store: ID, preferences, account data, and so on.

· Consider any provisions you’ll need to make for user groups. Think about the relationships among the elements listed above, as well as others, and address them as necessary.

Management Architecture

As with any large-scale public Web application, the management architecture provides a centralized mechanism for performing administrative tasks. In addition to general administration, consider your needs in the following areas:

· Self-service configuration by users.

· Self-service configuration by communities.

· Integration with hosting providers.

· Integration with federated service providers.

Architecture for Consumer Oriented Services

Masashi — Tue, 29 Jan 2008 01:13:27 GMT

From a service provider’s perspective, there are a few principles to keep in mind when envisioning and building architecture:

1. You go to them. Building consumer oriented services involves standing the traditional view of the Internet on its head. Users and providers are accustomed to thinking of the Web as being akin to a physical world with familiar, if figurative, laws of physics: to get information or make use of a service, you visit the location where it “lives” and consume it there. A URL is like a street address that marks the location in virtual space where the resource can be found, and the browser is the means of transportation by which users travel from place to place.

The ideal consumer oriented service, by contrast, is designed to come to the user. To consume and distribute it, the user can simply drop the service into his or her SNS profile or page, or send it to friends in a message. For example, several services allow users to embed streaming video in a Web page simply by adding a few lines of HTML code, something even novice users can do. Savvy users and sites can modify the presentation of standards-compliant services so things like controls, text labels, and backgrounds can be visually integrated with the rest of the hosting site without changing the service’s underlying functionality. By making services available for seamless embedding in this manner, you can reach the large subset of casual users who would not make the affirmative decision to visit your site directly.

2. Build services that integrate into users’ daily lives. As discussed earlier, more people are using the Internet for lifestyle-related purposes, in addition to simple information retrieval. People go online to connect with friends, coordinate their “offline” activities, play games, fall in love, and do any number of other things to pursue entertainment options and manage various aspects of their lives. Think about how you can build services that can integrate into users’ virtual living spaces.

3. Leverage user activity to improve your service. Think of users not only as consumers, but as potential contributors to a “read/write” service. Through participatory mechanisms like tagging, evaluation, and commenting, users construct valuable metadata that you can use to classify your offerings and extend their reach. In addition, by incorporating the idea of user context, you can leverage user requests to create additional metadata of your own.

4. Expose everything to the public so users can handle it freely. Openness is the key to creating a service that can change and evolve over time. Providing users, developers, and other providers with an open, well documented, self-service interface can lead to your services being used in ways you never dreamed of, helping you take advantage of even more of the long tail.

With that in mind, there are a few architectural considerations as shown in the diagram below.

In addition to the users that consume the service and the various providers that interface with it, this architecture comprises seven components:

· Core service: The essential component of your service that provides users with access to information, functionality, or both.

· Management: The mechanism by which administrators can configure and operate the service from within designated environments and platforms.

· Composition: Packages features into multiple services at the user and provider levels.

· Programming: Provides developers with a public API they can use to enhance the original service.

· Delivery: Determines how your service is presented for consumption.

· Consumption: Dictates how users access your service themselves.

· Propagation: Decides how, and if, users are allowed to share and distribute access to your service on their own.

Social network as a platform

Masashi — Thu, 24 Jan 2008 01:05:56 GMT

Though it’s certainly possible to build a consumer oriented service from scratch, relying on existing platforms to deliver your content or service can reduce development time and give you a valuable boost during startup. What’s more, integrating your offerings into existing major platforms enables you to take advantage of their existing user bases. Basically there are I think 3 kinds of platforms you can rely on, which are Service, People and Technology. The service platform is a set of services like maps, e-mail and user ID commonly mashupped across bunch of applications. As for the people platform it’s the conceptual place in the cloud where vast majority of users live. The technology platform is the most used technology such as devices and/or applications at user’s hand.

Although the service and technology platform are easy to understand what it means, I think I need to explain a bit more about people platform here.

From the consumer’s perspective, participating in online communities and communicating with friends are key motivations for going online in the first place. It’s appropriate, therefore, to consider these communities as an appropriate platform for your services. Today end users increasingly perceive them as their entry points to the Internet “cloud,” either literally (set as the browser’s home page, for example) or conceptually as the place or places they feel most at home while online. Providers should therefore properly consider these social spaces to be venues through which they can reach users via services that can be easily “plugged in” to service-aware communities. By federating contents and/or functionality from other service providers, you can maximize flexibility and usefulness to meet users’ requirements. Even if you already have your own user community, you should consider leveraging other communities as well. Some large SNS sites have as many as 50 million users and are still growing at a good pace. Facebook is the perfect example of people platform. Setting a privacy issue aside, it’s heading in the right direction by hosting social Ads as well as applications. As local/vertical social networks become more popular, there will be a good opportunity for service providers to serve them in a manner appropriate to user’s interests.

Consumer Web today

Masashi — Tue, 22 Jan 2008 06:20:00 GMT

I'm a solution architect in the Platform Architecture team at Microsoft. Last couple of years I’ve been working with service providers like e-commerce, digital entertainment. Let me name it “consumer oriented service”. Through my investigation on consumer oriented services, I found two key trends in this domain as follows.

1. Integration between commercial services and social networks.

2. Web as a knowledge base

Users are increasingly turning to the Web not just for information but for lifestyle purposes: to meet and interact with like-minded people in online communities. As the lifestyle component of the online experience has grown in importance, service providers have moved to meet the demand. The extent and nature of this shift can be detected by observing a number of trends.

One trend has been the rise of specialized service and content providers, a phenomenon sometimes called “narrowcasting.” Despite being known as a global medium, the Internet offers significant opportunities for services with specialized appeal. Locally- or regionally-targeted services have been around for a while, but as the Internet continues to extend its reach to new populations and devices, successful regionally-targeted services are emerging in smaller communities geographically and culturally distant from big, tech-friendly cities like San Francisco and Tokyo.

Vertical social networks, which serve specific occupations or hobbies, are also growing in popularity. By definition, users of these online community share certain interests, which can make them very valuable resources for service providers to cultivate. A service of interest to physicians, for example, will have a large potential audience in a vertical SNS for the medical community.

Another important trend is the increasing use of APIs to expose content and function on the Web as services to be consumed by others. In addition, some major community sites are considering providing open APIs to enable access to certain profile data, which can give service providers important information. With traditional commercial service providers embracing social networking sites instead of shunning them, expect the future to bring additional synergy between online and offline services, and increased integration between commercial services and social networks.

From service provider’s perspective, the biggest potential benefit of leveraging large communities is the huge number of potential users they present. Ideas reproduce memetically within online communities: as users discover them, they inform others, and the process repeats in a viral fashion. Many social networking sites are set up explicitly to accommodate this kind of viral propagation, through recommendation, tagging, and commenting mechanisms. By taking advantage of this, you can rapidly increase your user base and turn users into contributors if you like—the more users you get, the better your service will be. Commercial services have begun adopting the principles and approaches of social networks, but there’s still a cultural mismatch between the two worlds. The figure below depicts this as a gulf between services at the top and user communities at the bottom. To bridge the gulf, service providers must understand users’ needs and serve them in a manner appropriate to the context in which the user is making the request.

Of course, creating consumer oriented services involves multiple stakeholders, their requirements and architecting them . I expect my future contribution to guidance which describes key aspects of building consumer oriented services. It may include the following pillars.

- Architecture of Ad funded software

- Community support to generate network effects

- Service federation by Open API

- Service extensibility by hosting widgets

- Context awareness

- Data model for user generated content

I invite you to walk with me and take a journey to discover an ideal service which creates a true digital lifestyle.