A good question .. raised at forumoxford. Here is my analysis .. I believe that most of what I am describing below can be done by a product such as Xtract today

What is the Long Tail?

The Long Tail is the opposite of the Pareto distribution(aka 80/20 rule) and is the preferred business model behind many of the recent Web successes – specifically Amazon.com.

Supply side motivations

On the supply side, we need low inventory and distribution costs. This means, unpopular products can be stocked. Netflix and Amazon are examples of this model.

Demand side motivations

Demand side motivations include search engines, recommendation engines, sampling tools etc allowing customers to search a wide range of products OR for products that they normally cannot find physically in a store due to lack of time. Again, Amazon.com and many others excel here.

Much has been said about why telcos cannot execute Long Tail applications. So, I am addressing the more challenging aspect of – How Telcos CAN execute Long tail applications.

Firstly, demand side is a software, recommender, and influencer problem. This can be addressed.

The supply side problem is more complex. The Telco needs to maintain a Long Tail inventory of some entity. The obvious answer is a Long Tail of content. A more interesting answer (for a Telco) is a Long tail of people.

A Long Tail of people is an interesting proposition for a Telco since it is accessible through voice and SMS. Remember that a social network can be built from transactions i.e. the underlying data. There are various research papers about how this can be done(for instance creating a social network from email data or from IM data). Therefore, implicit and explicit recommendations can be captured from voice data or SMS data and that can then be used to identify the long tail in an aggregated manner

Here is an example:

If many people call a specific Pizza place, then that Pizza place gets an implicit recommendation as ‘Good’. Note that individual records are not revealed ; rather aggregate records are used to create the rating. The initial rating can be displayed to the users and users can contribute. For instance – if users see this Pizza shop rated ‘Good’ and it turns out that they have been calling to complain – then users can update that information (this works same as Amazon ratings). But the difference is – this information is seeded by the Telco from voice records. Once it is seeded by the Telco, it can be enriched by the users. This is classic Web 2.0

So,

a) Supply side: The ‘Long tail content’ could be lots of shops and stores(by postcode)

b) Demand side: The social search and recommendation tools can be created

What is missing

a) Profiles!!! At the moment, very basic user information is known to the Telco

b) External feeds(for instance feeds of restaurants etc)

c) A social network built from transactions i.e. the underlying data

Like I said, all this is currently possible through products like Xtract. I think Telcos need to address this space by engaging more with the end users and building the profiles(that’s the missing link!).

Traditionally, the Mobile Enterprise market has been the domain of the Blackberry . The Blackberry has always been focused on email – which seems to be fine for most people. Consequently, on first glance, it appears that not much is happening when it comes to Enterprise and Mobile devices. Indeed, much of the focus of the Mobile data industry itself is geared to the consumer market – further reinforcing that perception

But perceptions can be deceptive because there are significant moves being made both by the Web/Enterprise players to enter mobile space and the mobile players to enter the Enterprise markets.

Well, in most service industries, people appear to “work” by doing four things:

They look proactively for information. They search for things.

They receive information because they said they were interested in receiving that information. They subscribe to things.

They talk to each other using various forms of communication: letter, e-mail, audio, video, text, IM, blog, wiki, twitter, whatever. They are even known occasionally to talk to each other face to face without use of technology.

And they transact business as a result. Within the enterprise. In the extended enterprise and partners and supply chain. With customers.

<<<<

With this definition, the central theme underpinning the intersection of the Web, Mobility and the Enterprise appears to be the need for collaboration through smaller/more granular transactions which require greater synchronization within and across enterprises

We saw the ‘why’ but – How is this happening?

The implementation

The ‘how’ (implementation) of Mobility and Web 2.0 within the Enterprise is based on three key ideas:

a) The usage of the social network as a Meta layer above both the Web and the Mobile domains. The social network becomes the interface between various departments and also across enterprises

Web 3.0 will be “applications that are pieced together” – with the characteristics that the apps are relatively small, the data is in the cloud, the apps can run on any device (PC or mobile), the apps are very fast and very customizable, and are distributed virally (social networks, email, etc).

The other two ideas (Social network and unified address book/profile) can be illustrated by the launch of Nokia’s Mosh network

Mosh from Nokia is a social network which spans across the desktop and the mobile device. It enables you to upload audio, videos, documents, images, games and applications to your profile. For every object you are interested in (for instance the audio, video, documents etc), you can share, collect (tag) or download. Thus, Mosh creates a social network (spanning the desktop and Mobile device).

Thus, the social network could be the first point of contact – and a social network spans the Web and the Mobile domains.

All this is possible only if is trusted!

Do we trust Google with it’s cloud? Let me put it to you this way .. My email now resides on gmail(including my Futuretext email which can be aliased from gmail ..) but YET .. the gmail logo still shows ‘BETA’!!

Do we care? No. We think gmail will be around ..

For the same reason, I would trust Nokia ..(Mosh)

Contrast this with one more social network launched last week .. from a familiar name .. Plaxo.

Yes, everyone is getting into the act of creating a social network, including the dreaded Plaxo

However, do we trust Plaxo? Most people(including me) will not touch Plaxo at all .. based on painful memories of spamming the address book when it first launched ..

So, to conclude ..

a) Unlike the efforts of Nokia, Google and to an extent Motorola, the incumbent(RIM/Blackberry) seems to be very focussed on email only – which may be a mistake especially because devices like the Nokia E series could easily go for this market.

b) The profile(and consequently the unified address book) are the holy grail of Enterprise software. From the profile/address book, an entire social network could be built – as the Nokia/Mosh service is looking to do.

c) It is a mistake to look at Enterprise Mobility without taking into account the larger picture – for instance the ideas behind Cloud computing

d) The companies which will define this space will be the ones who understand the Web and the Mobile domains and who can be trusted .. and that may mean at the moment it’s a three horse race between Nokia, Google and Microsoft

e) Trust will be a key factor as social networks take on the role of ‘interfaces’ within and across Enterprises.

f) Finally, to recap: The central theme underpinning the intersection of the Web, Mobility and the Enterprise appears to be the need for collaboration through smaller/more granular transactions which require greater synchronization within and across enterprises

This concludes the four part series. I may add more articles later extending some of the ideas here. As usual, comments welcome.

These courses have an industry audience – i.e. not normally for the students of Oxford – and participants included senior strategists from Qualcomm, France Telecom, Nokia, Du, HP, Mobile Dhamal (India), Vodafone, BBC, three, Openwave, HP, Michael Page International and also a number of start-ups and communities

I always learn a lot from the participants and it was great to have so much feedback and many insights from the two courses.

Many thanks to Peter Holland for some great promotion of these courses and they seem to have become a permanent fixture of Oxford now.

6) Amazon is a commodity business on one hand (you can’t get more commodity than selling books!) but has implemented many small Web 2.0 innovations(like reviews) so that they are far away from the commodity. –

7) A new crop of companies like MySpace, YouTube and others are Web 2.0 from the outset.

8) Skype although not based on Web technology, is seen to be Web 2.0 because it is P2P.

9) Web 2.0 is all about building systems that get better the more people use them

10) It is not Ajax, mashups etc(I have often used the example of the blind men and the elephant for people who miss the part for the whole)

11) The principle of ‘Network is the platform’ is the uptake. Source of lockin is the ‘user enhanced database’

12) Competitive advantage goes to the owner of the largest database i.e. Amazon has an order of magnitude more reviews

13) Telcos – think so much in the old style (IT driven companies). Lock in via contracts – but if they thought like Google – then the lock in would be through mining and harnessing data since the historical data is there (in the system) – it is just not leveraged.

14) This means – If there are two ‘Tims’ in the address book, based on customer history, the one to whom more calls are made would be presented first.

15) Opportunity for Enterprise: Enterprise software that gets better the more people use it

16) For example: Information sharing around a supply chain

17) We are on a new platform. The platform is the Internet, On the Internet, the rules are different. Information sharing is actually better than information hoarding. With enough people sharing information – you build a database and the database becomes bigger and better with incremental users

18) A link is a vote .. so how people spend money(aggregating financial transactions) is a vote(in context of a Hispanic start-up – forget name)

19) People are sharing more – esp personal information.(ex Twitter)

20) Most disruptive technologies are often ones that appear to be toys ..

21) Twitter can be viewed as a presence platform where new applications can be built

22) Jaiku! I need to test that.

23) Don’t dismiss the toys .. They are the future ..

24) In an era of commoditization, people are looking to express themselves ..

25) What is the difference between a song and a ringtone: A song is something you consume vs. ringtone is something you display. Hence ringtone has ‘more’ value than the song even when it is a poor copy of the song

26) In an ‘Art market’, products are sold not on the basis of what they do but on the basis of what they mean. Apple has been doing ‘art market marketing’ from the very beginning.

27) As computers become commoditised .. people buy the Apple for what it means!(and less for what it does)

28) Twitter, avatars etc are all a form of self expression.

29) Online identity – next phase of web 2.0. Spock service searches people

30) Enterprise and pervasive computing are also opportunities

31) Privacy concerns are overblown in relation to the Web. Credit card companies in contrast collect a lot more information about us.

My views follow:

This is a fascinating discussion. Web 2.0, to me, is very clear. Sadly, many people don’t understand it because

a) Some don’t want to understand it

b) Some have their own agendas(dreams of defining Web 3.0!),

c) Some see it as ‘software and not data’ and

d) Some others see it as a part and not the whole

With some exceptions, in my view, Telcos are probably the last to understand Web 2.0 because they don’t understand network effects and are trying very hard to maintain the status quo. Many struggle to understand they are on the Internet. Even when they are, they use technologies like IMS to create barriers which run counter to the Internet.

This is partly a reason I follow the O Reily thinking so closely – because in defining Mobile Web 2.0, I see it as a sub meme of Web 2.0. It sounds pedantic, but I want to preserve the integrity of the original ideas. A more complete discussion on here Mobile Web 2.0 philosophy

a) Product development cycles (no longer sequential and silo big scale no iterative, testing and pilots. New services no longer siloed products – mash-up of products to make new services. Fail early and small to learn from customer feedback to succeed big.)

b) Business cases (current approach is not flexible enough to take advantage of fast moving world of User Generated Content),

1. One Web. The Internet is the Internet, and sites should run well on all devices. Optimization should be based on CSS and device detection, but should not change site function or content beyond the necessary.

2. Mobile Web. The mobile is a different platform with different capabilities and different user needs. Sites should be optimized for mobile in many (but not all) cases.

Most people will accept a half way viewpoint (which is valid in a sense)

However, we could take a different perspective. I like the perspective of ‘starting points’ as outlined by Dean Bubley (also at forumoxford)

I like it because it is technology agnostic, it is user centric and is not a simple ‘either or’ categorisation.

To summarise the concept of ‘starting points’ (as per Dean’s post)

Users could be classed by their prior experience of the web (and the mobile web) and their expectations of what a ‘mobile’ web is will depend on their accumulated prior experiences and what they want to do (i.e. starting point). Starting points include: regular PC users, intermittent PC users, age, prepay vs. postpay etc. Thus, the user’s experience of the mobile web will depend on who they are and what they want to do

In terms of one web vs. mobile web, starting points could include:

B2B Web content: optimise for PCs – most business people will have access to a PC, or a mobile device with a decent browser. Some parts of some sites (eg online airline check-in) should be more mobile friendly, but nobody’s going to browse for & buy nuclear power station components on a phone.

B2B Internet communication (esp. email) - mobile devices likely to be of similar importance to PCs, but may well have middleware on device or in the network to render things differently (eg Blackberry)

B2C Web content: depends on target audience and specific site purpose. If it’s browsing-heavy or dependent on lots of text entry (eg an estate agent’s houses for sale, or a travel booking website) then optimise main site for “One Web” and PCs, but consider that there might be separate bits which could be “mobile-optimised” – eg the estate agent’s mapping pages, or the travel site’s itinerary lookup. If it’s browsing-light (eg blogs) and more oriented to reading/viewing rather than text entry, then perhaps do mobile-optimised at a core level

B2C communication-oriented (email, messaging etc) – hugely dependent on “starting point” and demographics of user base, and availability of devices/networks in the relevant geographies at given point in time.

Government - probably needs mobile web versions of pages, as it’s likely to have to deal with “lowest common denominator” mobile users (as well as others who don’t even have mobiles).

I like Dean’s ideas because they put the user and the function in the spotlight. They are much more comprehensive than mobile vs. non mobile, Ajax vs. non Ajax etc. In mobile web 2.0, we took a similarly complex stance especially in terms of mobile devices and user generated content. Hence, I empathise with the ‘starting points’ methodology and it shall be added to my thoughts from now on!.

Since I have an interest in mobile web 2.0(and by extension with web 2.0) – I get some interesting reactions from people. Everyone has a view on web 2.0 – it’s almost that we can’t discuss religion, politics AND web 2.0

Another example of this recently was someone who said that their software is in ‘perpetual beta’ – hence they believed they were using some features of web 2.0. (My feeling is they have too many bugs!) .. But .. more seriously .. perpetual beta applies to data more than it applies to software .. think indexing when you talk perpetual beta ..

There’s certainly a lot of confusion and many bandwagon seekers out there!

Having been involved in creating mobile services for a few years now, I believe AJAX will replace both J2ME and XHTML as the platform of choice for developing mobile applications.

In this article, I will outline my reasoning.

Before I do so, a caveat – I believe that mobile web 2.0 is far more than ‘AJAX on mobile’. Essentially mobile web 2.0 involves applying all seven of the web 2.0 principles to mobility. I will be discussing mobile web 2.0 in subsequent blogs. For a more complete discussion see my article on mobile web 2.0.

Here, I am discussing AJAX only i.e. only one facet of web 2.0.

Overview

In this article, we will discuss

1) What is AJAX (an overview)

2) Current Mobile applications development models

3) Problems the industry faces (in other words shortcomings of the current mobile applications models) and finally..

4) Why AJAX will replace J2ME and XHTML as the preferred development platform

What is AJAX

AJAX is an optional addition to web 2.0. It is not a single technology. Rather, it’s a combination of a number of existing technologies acting together namely

• XHTML and CSS for standards based presentation

• Document Object Model for dynamic display and interaction

• XML and XSLT for data interchange and manipulation

• XMLHttpRequest for asynchronous data retrieval and

• Javascript to tie everything together

Until AJAX came along, it was not easy to replicate the rich and responsive interaction design of native applications. AJAX is different from other previous attempts in addressing this problem since it is based on existing, non-proprietary standards which are already familiar to developers.

In traditional web applications, most user action triggers an HTTP request. The server does some processing and returns the result back to the user. While the server is processing, the user waits! The ‘start-stop-start’ nature of web applications is good from a technical standpoint but not from a user interaction standpoint (since almost all user interaction is resulting in trips to the server and the user is waiting while the server is doing the work).

AJAX solves this problem by using the AJAX engine. At the start of the session, the AJAX application loads the AJAX engine. The AJAX engine is written in Javascript as a Javascript library and sits in a hidden frame. The user interacts with the AJAX engine instead of the webserver. If the user interaction does not require a trip to the server, the AJAX engine handles the interaction on it’s own. When the user interaction needs some data from the server, the AJAX engine makes a call asynchronously (via XML/XMLHttpRequest API ) without interrupting the user’s flow.

In this sense, AJAX is ‘asynchronous’ because the AJAX engine is communicating with the server asynchronously to the user interaction. Thus, the user gets a seamless experience(i.e. the user is not waiting)

There is a momentum behind AJAX at the moment. Developers are already familiar with the technologies underlying AJAX. All the technologies making up AJAX are mature and stable. AJAX is the foundation for many new applications on the web like Google suggest , Google Maps , some features of Flickr and Amazon’s A9.com

Mobile applications development models and their shortcomings

From the above discussion and from the articles referenced , we can see that – AJAX clearly solves two problems – namely a superior UI and a standardised form of data retrieval.

These two problems also apply to mobile devices and by extension, AJAX addresses them as well.

However, I believe that it does far more!

Specifically, it solves the following problems in the mobile context.

a) The problem of market fragmentation

b) Porting woes (specific to downloading applications like those built on J2ME)

c) Application distribution without ‘walls’

Besides, it has the developer community behind it – which is a significant plus!

Lets consider existing mobile applications development. There are two principal ways to categorise mobile applications – Browsing applications and Downloading applications. There are others(like Messaging applications, SIM applications and embedded applications) – but a vast majority of the applications we see today fall under downloading or browsing applications.

Browsing applications: Browsing applications are conceptually the same as browsing the web but take into account limitations which are unique to mobility (for example – small device sizes). Similar to the web, the service is accessed through a microbrowser which uses a URL to locate a service on a wireless web server. The client is capable of little or no processing.

Downloading applications (Smart client applications) : In contrast to browsing applications, downloading applications are applications that are first downloaded and installed on the client device. The application then runs locally on the device. Unlike the browsing application, a downloaded(or smart client) application does not need to be connected to the network when it runs. Downloading applications are also called ‘smart client’ applications because the client(i.e. the mobile device) is capable of some processing and / or some persistent storage(caching). Currently, most Java based games are downloaded applications i.e. they are downloaded to the client, require some processing to be performed on the client and need not be always connected to the network. Enterprise mobile applications such as sales force automation are often also examples of smart client applications.

J2ME is the most common mode of developing downloading applications and XHTML is most common way of developing browsing applications.

Let us elaborate on the problems I have outlined before and then discuss how AJAX will solve them – potentially making XHTML and J2ME less relevant.

Problem One – Market fragmentation

Mobile applications are primarily consumer applications. The mobile data industry is an emerging industry. As with many industries in this phase of evolution, it is fragmented.

To be commercially viable (especially considering the need for the network effect ), consumer applications need a large target audience.

This can come about either by a single proprietary standard such as BREW from Qualcomm (which obviously has it’s disadvantages) or through open standards not controlled by any one entity with few industry barriers.

To illustrate how market fragmentation affects commercial viability of a new service, I often recommend the following approach (Most of the figures can be easily obtained from the web).

The idea is to think in terms of ‘concentric circles’ in trying to find out the target audience for your application. A sample set of steps I use is as below

a) What is the population of the country where you are launching your application?

b) What is the percentage of handset penetration amongst this population?

c) Which operators are you targeting within this population? (Most countries have more than one mobile operator)

d) Which handsets are you targeting within this population (not all operators support all handsets)?

e) What is the technology of deployment for example Java, SMS, WAP etc?

f) Does the application have any special technology needs such as location-based services? How many people have handsets equipped with this technology?

g) What does a segmentation analysis of the subset reveal? (Simplest segmentation is male/female. Prepay/postpay etc)

h) What are the channels to market for the segments we are targeting?

i) What proportion of this subset do we expect to hit and convert to customers based on our marketing budget?(i.e. the conversion rate which can be typically 2% )

This will give you your target audience.

Thus, this target audience times number of potential downloads per month should give you an idea of your monthly revenue. This could then be tied against your cost base including your development costs, porting costs etc to arrive at a more tangible picture of success/failure of the new service.

The above methodology illustrates the problem of fragmentation and it implies that very few mobile services are profitable today. Thus, we have a proliferation of ‘broadcast content applications’ – ex ringtones, pictures but very few utility applications at a mass-market level.

Problem two – Porting woes

This problem is specific to downloaded applications (and more commonly J2ME). Write once run anywhere is a joke in the mobile context! – and through no fault of Sun ..

Consider the case of mobile games(a downloaded application) typically developed using J2ME.

First the good news ..

• Carriers such as Sprint and Vodafone report that mobile games and other data services now account for roughly 10 percent of their annual revenues;

• Industry consulting firm Ovum notes that there are now more than 450 million Java-enabled handsets globally, in addition to the 38 million and 15 million BREW- and Symbian-enabled handsets;

• Mobile-game publishers racked up $1.2 billion in global sales in 2004 and expect an even stronger year in 2005 as more and more consumers discover the tiny gaming consoles already in their pockets.

BUT then the pitfalls ..

Game porting generally requires developers to adapt to differences in screen resolution, processor speed, memory thresholds, and sound capabilities, all of which can vary wildly from device to device. For publishers, this can not only exponentially increase game development and asset creation time, but can also cause them to miss critical time-to-market windows in a hyper-competitive industry. As an example, imagine that you are a mid-sized game publisher with 30 games in your portfolio. To make your games available worldwide in five languages and on only 50 devices, you would need to create 7,500 different builds. At $2,500 per build, you would require a budget of nearly $19 million simply to handle porting.

This limits the business model severely and very few mobile games are profitable.

The predicament of using J2ME as per the preceding example shows that it’s not enough to merely set up a community process as Sun has done (which works fine as far as the technology is concerned). The technology and the applications built upon it must remain homogeneous and interoperable to enable the network effect and gain critical mass. The fewer the ‘choke points’ for a platform – the better it is for the industry as a whole.

We will discuss this more in the next section(where we talk of how AJAX could address this problem).

Why will AJAX replace J2ME and XHTML as the preferred development platform?Can AJAX solve the preceding problems?

In my view .. YES

AJAX is accessed through the browser. There are two ways a customer can get the browser – either the browser can be pre-installed on the phone by the manufacturer or it can be installed as a separate application

This means, all customers can potentially install their own browser and if enough people do – we have critical mass with few ‘choke points’ – such as specific restrictions created by mobile operators. In other words, a means to bypass the walled garden.

Further, AJAX offers a superior user experience and already has the developer community supporting it. The possibility of attaining critical mass (due to fewer choke points) means more chance of monetising the application – leading to a virtuous circle of better applications.

J2ME as it stands today, is seriously flawed(not the technology but the business model). XHTML will be an ‘also ran’ because AJAX will offer a superior user experience.

Hence, my belief that AJAX will be the preferred platform of choice for mobile applications at the expense of J2ME and XHTL.

Supporting notes

a) I have said ‘preferred’ and not ‘replace’ i.e. I don’t expect AJAX to replace any technology

b) AJAX won’t solve all problems. You still need to create a service which is useful for mobile customers

d) Not a lot of people are actually browsing the mobile internet. Although WAP usage shows phenomenal growth, these figures include the use of WAP as a transport mechanism – typically for downloading content. In other words, every time you download a ringtone, you implicitly create a WAP page impression. I suspect the real figures used by consumers to actually browse the mobile internet are very low

e) Very few mobile operators have tried to engage with the developer community as such. Practically the only example I can think of is source o2

f) The plight of small developers can be illustrated from my discussions with a Korean vendor when I spoke at imobicon in Seoul. The vendor had finally managed to get his game listed on a UK portal. However, that was because – a Korean aggregator managed to get a deal with a UK aggregator. Thus, he now had two aggregators and one operator taking a slice of revenue! Leaving him with very little. A sad state of affairs. Surely, there must be a way to create and distribute applications globally i.e. you write for the browser and anyone who uses that browser can download and run your application

g) Mobile operators often argue that they handle billing and location services etc. That’s fine – but let’s first worry about getting the numbers. Also, billing comes at a cost and there may be better billing mechanisms on the web.

Conclusions

To recap, Mobile applications are primarily consumer focussed. They need critical mass. Currently, the market is fragmented and the current commercial model is broken.

AJAX offers a potentially better solution in comparison to the incumbents (J2ME and XHTML) due to a combination of fewer potential choke points because of its distribution mechanism. The economic models do not favour J2ME and AJAX offers a superior user experience to XHTML. It has the support of the developer community.

Finally, note that I say AJAX will be ‘preferred’ model and not the ‘only’ model. I don’t expect AJAX to replace either J2ME or XHTML.