Saturday, May 28, 2005

Vodafone Simply rethinks the mobile phone

I've already mentioned the Vodafone Simply phones (VS1 and VS2) because I thought that they could indicate a new strategy by Vodafone. This is also what Ovum's analyst John Delany thinks. he writes "Vodafone Simply is the most important example to date of a trend which, we have long argued, will be one of the main influences on the shape of the European mobile industry over the next few years."
Read John's comment here.

Thursday, May 26, 2005

Can you develop a mobile phone UI with Flash?

In this post, I try to show that it is not possible to fully develop a phone's UI with Macromedia Flash.

Can you fully develop a mobile phone UI with Flash? It's a question that manufacturers and designers often ask these days. I have been struggling with that one for some time. So let's give it a try.

Today, most manufacturers develop their UI directly in C, using widget components (a widget is a small piece of code that can be reused). But UI are becoming more complex to develop and can have many variations (see for instance Vodafone 3G phones and more recent VS1 & VS2), so this takes more and more time and resources; new approaches are needed.

Macromedia Flash is basically a way to create sophisticated graphics on a screen. It is based on a model that separates a file, describing the graphic result to produce, and a graphic engine that reads the file to execute it. The file itself is produced with an authoring tool such as FlashMX that now includes a mobile version of Flash. The good thing is that Flash does not just produce monolithic animations (a nice movie), but allows the creation of interactive graphics with objects such as buttons, menus, etc... and can also include scripting to handle actions from the "external world".

Does that feature make it a good candidate as the fundation of a phone's UI? I don't think so.
Every development tool is based on a model that offers a level of abstraction and a conceptual representation of the reality to describe. To answer this question, therefore, is to confront the model and the reality (ie. the requirements of the job to be done).

The conceptual representation with Flash is that of animated vector graphics. The model is the description of the screen with basic elements that are graphic objects. Flash is what I would call an universal model in the sense that its ambition is to do 100% of the job; it does that in a
graphic centric manner. In addition, Flash is a high-level model in the sense that it proposes a high level of abstraction (graphic concepts) as opposed to C for instance.

But it is very difficult (meaning costly and inefficient) in Flash to "escape" from the model if some function can not be implemented with the basic offer. Of course, Flash can be scripted and extended by external libraries, but trying to do things that are natively handled by the model may lead to a large bulk of script code: is the original model still useful then ? To take an analogy: you can go from London to Heathrow by metro and then take a plane to Dublin, and still claim you went from London to Dublin by metro.

My sense is that on a PC as well as on the mobile phones, Flash is the perfect tool to create stand-alone "cartoon-centric" applications but one should not believe that the easyness to create the graphic part is still there to implement a complex application logic.

Why so? I can think of a few differences

- First, on the Web, the "UI" is only a window onto a functionally limited world. However sophisticated, a Web site is always a subset of the total available features of the PC platform. It is used to interactively exchange information between the user and the external world. On a mobile phone, the objective of the UI is different. It is used to represent the complete platform with all its functions. To give a try at technospeak, I would say that on the Web, the job to be done is more limited horizontally than on a mobile phone.

- Second, the Web works with a sand box, in an extremely confined environment, with minimal interaction with the underlying platform. The job to be done is limited vertically. On a mobile phone, however, the situation is different. The very purpose of the UI is to integrate to the underlying stack and platform; the successul integration is key to the overall performance. A fully integrated mobile phone software may always be seen as a kind of "big and monolithic" application that needs to be reliable, maintainable and that must be developped by large and multidisciplinary teams. In that sense, the UI is the visible part of an iceberg that cannot be easily splitted.

- Third, in the past, the UI was specified by the developing team: it was code centric. Today, modern UIs are more and more specified by the telcos and the marketing team. Their culture is a graphic culture and they define the applications in a graphic centric manner. Even if the temptation is high to consider that the graphic part of the software is ruling: this is not compatible with the reality of the phone's internals.

When the job is both horizontally and vertically limited, a universal and high-level model can work, because the universe is finite, which makes it easy to know whether the model will apply or not. So indeed you can perfectly develop the client side of a full Web site with Flash and be happy with it.

On a mobile phone, the job is not limited, either horizontally or vertically: the UI must represent all the phone's functions, and be tightly integrated to the platform. At some point, the high-level universal approach loses its efficiency as each step become more costly to implement as the
model is stretched further. You don't actually go to Dublin by metro. What happens is that the part actually written in Flash will be overwhelmed by scripts to "patch" the limitations of the model. Any universal model will reach inefficiency at certain point, and with Flash it will be when one wants to go beyond the purely graphic parts of the UI. This has been confirmed by some mokups made by manufacturers and research centers (see IBM)

This is a problem of course, because the era of programming UI purely in C, a low-level universal model, is more or less over. But one thing is clear: the UI cannot be programmed only with a high-level universal model; that, by the way, means that pure XML-based alternatives are a dead-end I think.

So there are three solutions:
  • You use a universal, but low level model for the UI layer: this means reverting to pure C programming, not much future in this.
  • You use C for the UI layer but implement high-level models for limited jobs (vector graphics, MP3, etc.) With this approach, Flash is used as a vector graphic component part of the overall UI layer. This is the common approach today, and it remains costly: programming is still in C and integration of components is costly.
  • You find a high-level meta-model that is able to combine high-level (Flash players) and low-level components (C code)
To conclude, like SVG, Flash offers vector graphics and animations that will be more and more needed. Vector graphic players will become a standard feature of future mobile phones. But instead of rendering the full UI, it will be a component. The search for the right UI approach is on.

Monday, May 23, 2005

Software module providers: winning at the first pass the post system*

In this post, I try to define a few rules to determine the probability of success for vendors of mobile software modules given the market conditions.


I would like to try to clarify an idea I have been discussing around about the strategic game that a software vendor can play. Let me explain. In the mobile industry, various vendors compete to offer software modules to manufacturers and ODMs, such as MMS clients, WAP browsers, vector graphics engines, network stacks, Java VMs, etc. I tend to think that in each category, the number of players who are eventually successful must be very small, probably 2 to 3.

As long as the market is not mature enough, all candidates compete. As soon as it matures, the market coalesces around two or three players, and that's the end of the game for the others. Once the top spots are taken, it's almost impossible to open new slots, because buyers are very conservative and tend to buy from the leader: success is self-reinforcing (see Geoffrey Moore's Inside the Tornado book). Why then isn't there only one player? The reason is probably that very often, all clients open the competition roughly at the same time: this industry is amazingly synchronized for that, and this makes it almost impossible for a single company to address globally and immediately. So my hypothesis is that there will always be at least two or three players in each category, but not more.

Now what does that mean to the vendor, the analyst and the investor? It means that it should be possible to define a few questions to analyze a vendor's potential for success. Let's take a crack at it and define the questions to ask...

Question 1- Has the proposed function already been identified as necessary on a platform? For instance, everybody knows what a SVG player could bring to a platform, but does that mean manufacturers see it as an opportunity? Or do they look at it as yet another annoying feature to implement? Similarly, a TTS (Text to speech) engine is nowhere talked about (as far as I know, I would love to be proved wrong...). Not that it is technically impossible (there are efficient engines available) but that it's just not in the map right now.

Question 2- Has the proposed function the ability of being implemented fairly autonomously, or does it have to be part of a greater module? Does it depend on another technology or module to be implemented? The idea here is to check any dependency that might hinder the deployment of the technology/function/product. For instance, a MP3 player is independent from other functions, but a MIDP game needs a Java VM. A WAP browser is also dependent on the platform, which allows some vendors to extend their offering, and therefore their stickiness: this is what Openwave has done with its browser by adding a stack layer that ties it to the platform; it becomes difficult to change the browser without important changes to the platform.

Question 3- Can the function easily be outsourced by the manufacturer? For instance, the graphic toolkit is too core to be outsourced. A tight integration to the hardware platform will bring too many benefits to be disposed of.

Question 4- How many suppliers are there for this function?
  • 0: this never happens; if the manufacturer needs it, it's because it does exist somewhere. Manufacturers are now used to buy independent functions from third party vendors. This reduces the development time and the technical risks while minimizing the organisational impact. Not that they are not innovative, but they are not proactively looking at integrating new stuff because they, unlike many suppliers, know what it costs.
  • 1: in this case, manufacturers will evaluate the supplier, but will be looking for alternatives; this might mean that there is no urgency yet for the function, and that manufacturers can wait and extend the "let me think about it" period (the valley of death for the suppliers). For the suppliers, however, it means that the race is open and can heat up anytime. If a vendor is not in the game by that time, it might be too late unless it has a really good go-to-market strategy.
  • >1: in this case, the manufacturers will choose from the existing offer and tend not to look outside this group for alternatives. The game is already over for a new entrant, and even if some sales can be achieved, it will certainly only be on the periphery of the market and hence be not very profitable and growth generating.

Question 4 can be considered by looking at the maturity of the vendors:

1- Vendors whose product has already been integrated by a at least one important manufacturer - and even better, deployed - clearly are in a different category. Only they can have the credibility to race ahead for the leadership. This also has the effect of ackowledging the importance of the function for the whole market.

2- If no manufacturer has deployed such a function, the market is still open. Until a manufacturer has implemented it, the function does not seem so critical, and the sales cycle is very long. When it is, all manufacturers consider it. That is when the market accelerates and the race really starts, the sales cycle shortens dramatically. Vendors who are not in an advanced stage in terms of integration and deployment are in trouble.

The implication of all this seems to be that there is a "first deployer" advantage. The vendor who deploys first can win because it will be seen as the future leader. Alternative offers will be evaluated, but they will face an uphill battle, each sales becoming more expensive.

So the "rule of thumb" might be: on any give market, if two vendors already have deployed, the game is over for the other candidates, unless some disruption re-opens the game.

In a next post, I will try to apply this framework to a few sectors...

Thursday, May 19, 2005

European mobile phone manufacturers, an endangered species?

In this post, I speculate about possible futures for French mobile phone manufacturer Alcatel, and some European manufacturers in general.

We've just learned that French vendor Alcatel confirmed plans to exit its handset joint venture formed with Chinese manufacturer TCL in August last year. Under the agreement, Alcatel will swap its 45% stake in TCL and Alcatel Mobile Phones for 5% of parent company TCL Communications, following which the handset unit will become a wholly owned subsidiary of TCL.
Alcatel said TCL would continue to develop handsets in China only, while the European site, based in France, would refocus on sales, marketing and support.

I should indeed have quoted the above text, because that's the official story. Now, what's behind this? We know that Siemens is in trouble and tries to exit the business. We also know that Mitsubishi announced the closure of a design center in France a few weeks ago.

Let's look at the Alcatel case, which is the most clear-cut. From now on, I'm in full speculation mode, so be warned.

From the news release, it seems that there are two options for Alcatel.
- Option 1, Alcatel can hand over to TCL, cut its losses, and disappear as a brand. Alcatel is a big telecom equipment company, so they will refocus on that and forget about mobile phones altogether. They will promote the TCL brand, or at best sell standard TCL phones under the Alcatel brand.
- Option 2, The Alcatel brand is maintained, the design is transferred to China, but Alcatel keeps a strong marketing unit in charge of specifying phones for the European market: operators, countries, etc. In this option, Alcatel becomes a virtual vendor in a way.

Let me explain why I think they should go for option 2.

They won't save money with option 1 - I don't know what they will do, but to me Option 1 doesn't make any sense, even if I take an accountant's hat, Option 1 won't save them much money.

Second, chinese manufacturers are not strong in Europe (that is an understatement) under their own brand. Alcatel is not a tier-1 player, it has a small market share, but can we imagine TCL jettisoning Alcatel's market presence, relationships and networks to save a few pennies to start all over again? Penetrating the European market requires excellent relationhips with operators, which need to be built over time. Why would operators want to start working with a new brand? For cost only? I don't think so. Operators are looking for flexibility, not so much pure cost.

Is there a market outside the operators' realm? TCL would probably not go for the retail market. They could look at the MVNO market in general (such as Virgin Mobile for instance). But there the average run will be much lower; how many devices would a typical MVNO order: 50,000 units? 100,000 units? You don't go for niches unless you're specifically organized for that, which I think TCL is not. TCL's value proposition lies in its ability to mass produce standard phones. Niche markets require customization, which in turn requires intimacy between the manufacturer and the client. The physical distance precludes that, not to mention the fact that few chinese manufacturers' executives correctly speak English.

So to finish this speculative post, to me the logic would be to transform Alcatel into a virtual vendor to produce highly customized mobile phones for the European market.

Wednesday, May 18, 2005

Where has Java gone on the mobile phone?

I'm suprised we don't hear much about Java in the mobile industry these days. Why?

Remember a few years ago when Java was all the rage? The technology was seen as the next big thing on the mobile. Recently, I noticed something strange: at the last 3GSM in Cannes in February, and at the World Handset Forum, there wasn't any talk of Java at all. Does that mean that Java has failed in the mobile space? I don't think so. If my observation that Java has gone silent is indeed correct - I think silence is both better and worse than the failure.

It's better, because the number of mobile phones shipped with Java is larger than ever. Java has indeed become a standard feature of phones, from entry-level upwards. But it's worse, because Java has been marginalized in the MIDP area, to be used to download games. That's about it. This despite SUN's efforts (see the promotion of the JSR185 as the cornerstone of the Java-centric phones to come.)

Today, the number of Java-centric platforms actually shipped or even being designed is almost nil. Very few players are still in this segment. SavaJe has been promising to introduce its Java OS for years now. To my knowledge, one of the very few successful shipement of a phone is Danger's hiptop. A beautiful toy indeed, which shows what a Java phone can be. That doesn't mean there won't be Java phones, but so much time has passed that competitors and substitutes have worked hard to catch up and actually deliver phones.

My explanation is that if people don't talk about Java, it's not because it failed, but because although it succeeded, it did so in a much restricted function of the phone. Will it go beyond that? I'm note sure. The extension from a "Java-game" phone to a Java phone is not natural. The years 2002-2003 ware the years of painful integration of Java VMs for the manufacturers, and my guess is that they don't want to open the Java Pandora box anytime soon. People want to download Java games? So be it, but don't even mention doing anything more with Java.

RIP. Because one day, there will be a better way to download games - I'm sure Bill think about it every day - and Java will slip away without anybody noticing. Bill hasn't been very impressive with its mobile efforts so far, but in true Microsoft fashion, he trying and trying again, and never gives up. Microsoft's persistence could succeed where Sun's lack of persistence and strategy seems to be failing.

Friday, May 13, 2005

The unnecessary path towards more power on mobile phones

If one looks at the strategy of the manufacturers, and particularly the platform manufactuers (ODM), one can't fail to notice that everybody assumes mobile phones will have more and more CPU power. The implicit model here is that of the PC, whose growth path is based on the exploitation of Moore's law, and the "virtuous" interaction of the chip and operating system: any increase in the power of the chip is used by the OS, which in turns calls for another increase in the chip's power, and son on. The reason why this was possible is that, for a long time, power was the bottleneck, and hence the source of value added, in the PC world. In the mobile world, it is rather different.
  • On a PC, applications are chosen by the user, and the level of integration is very low. Which means that the overall performance (or yield) is low as well. Because, in absolute terms, a lot of power is available, and because programers (rightly) assume that ever more power will be available in the future, they don't bother optimizing their code, which further reduces the yield, further fueling the need for more power.
  • On a mobile phone, more CPU power means more battery power, thus less autonomy. Saving CPU cycles allows to save the battery, and the autonomy of a new device is still a very important commercial argument. In addition, on a regular mobile phone, the user does not choose its applications, and they don't change. The fact that the OS and the applications are tightly integrated makes the platform relatively efficient (high yield). You don't change applications, you change your device.
Because the device is not supposed to anticipate a higher use of resources, it does not need to be so powerful. The virtuous circle, on the mobile phone, works towards a reduction in the increase rate of CPU power.

My experience suggests that a mid-range 2004/2005 mobile phone is able to run almost any kind of application as long as the application is optimized for the platform. More available power sometimes means less necessity for quality code. I remember Bill Gates saying at a very early age of Windows3 : "we can make that from a PC because our developers are able to write assembly code when assembly code is needed."

Indeed, you can play a perfect video on a Game Boy Advance (ARM @ 17Mhz, yes seventeen megahertz). Why then would you need a ARM11 at 200Mhz on a 3G phone to do the same, unless you mistake the mobile industry for the PC industry?

Thursday, May 12, 2005

Macromedia Flash vs. SVG: Adobe's future strategy in question

There was a big question at the World Handset Forum recently and that was about the future of Flash following the acquisition of Macromedia by Adobe. So far, Adobe has not had a mobile strategy, and its support for SVG, an alternative, open standard clearly conflicts with its "new baby", Flash. It's difficult to imagine Adobe keeping both standards as they are so clearly redundant. So they could decide to stop their support of SVG, or could kill Flash and replace it with SVG.
  • if they stop supporting SVG, they leave the door open to somebody else endorsing it, which would become a real "open source" threat in this important area;
  • if they stop Flash, the cost regarding the installed based is huge. They would have to convert their authoring tool (which are their cream and butter) to the SVG format. But then what happens if/when open source authoring tools pop up everywhere?
Am I missing something? The information on the Adobe site seems quite vague (see the acquisition FAQ pdf) but industry participants are worried and this uncertainty hurts Flash. The kind of participants to this forum (mostly very big players) can usually ill afford such uncertainty.
To a certain extent (I'm speculating here, so you can stop reading), it might be that the acquisition is - in part - motivated by the recognition that Flash and SVG have a big overlap, so it's better to swallow the competition. If Adobe keeps SVG, it might mean that they see their future in the graphic world (primary purpose of SVG) rather than in the application development world (the trend with Flash).

Wednesday, May 11, 2005

Who wants an open operating system on a mobile phone?

The manufacturers? The telcos? The users?
*The manufacturers: yes to cover their bets, but not really to sell it; an open OS reduces their differentiation, which makes them more vulnerable to low-cost manufacturers.
In addition, an open OS
- increases the cost of hardware for the same service,
- allows the user to add third-party applications, which makes technical support almost impossible
- forces manufacturers to rewrite their legacy applications
The Linux case is slightly different: manufacturers need an OS in any case, so it might as well be Linux, for which there is a momentum right now. Because it is open source, they can have complete control over the software they develop with it. In addition to the hype effect that comes with Linux, that is probably the reason why almost all manufacturers have an internal project based on Linux. That doesn't mean the device itself will be sold - if it is ever sold - as an open platform.
In this regard, the Mobilinux initiative, launched by embedded Linux specialist Montavista, is interesting. Mobilinux is a consortium whose objective is to define reference platforms to facilitate manufacturers' job when they look for a complete software platform. It is a response to the issue that very often, Linux is only a starting point, not a complete environment. Such an initiative should also help integrate legacy applications. While technically appealing, however, the risk with the Mobilinux approach is that it tend to reduce the differentiation of each manufacturer, as is the case with Symbian or Microsoft Windows. As a result, one would expect that Mobilinux would be more successful with emerging asian manufacturers than with established players.

*The telcos: Again, they might want to cover their bets and leverage the marketing of some powerful open OS vendors, but is it really in their interest? An open OS decreases the switching cost for the users, reduces the possibility to create exclusive applications (e.g. Instant messaging) as this would violate the "rule" that the OS should be the same on all platforms. In addition, the integration of such functions is not very good, which means the user experience is poor, which in turn limits the usage.
- As in the case of the manufacturers, the addition of third party applications will make technical support difficult and expensive.
- The cost of the devices will reduce the rate of renewal, generating frustration among users as the obsolescence rate will not diminish. In turn, ARPU will be hurt.
Telcos have been involved in defining industry standards through the OMTP initiative. The evolution of the specs will soon give a good indication on what telcos have in mind with regards to open OS...

*The users: having a universal device modeled on the computer is appealing, but are the users ready to pay the price? Such a device is inherently multi-purpose and is not optimized for telephony anymore. As anybody who has played with a smartphone has noticed, each function becomes more difficult to use, and key features are gradually buried under several layers of menus. The increasingly large number of functions reduces the quality of the user experience.
- the devices are more heavy and more power hungry, which reduces the autonomy
- the cost per device is higher and more difficult to recoup for user
- the risk for bugs increases probably to the square of the number of features offered.
- the responsibility of the telco is diluted as the user doesn't know where the buck stops anymore: at the telco, at the OS vendor or at the device manufacturer? Who is accountable for the user experience? Who gets the brand effect?

As long as the mobile telephony remains a closed environment, it seems it can only run on a closed platform. If it chooses to become open, much like the PC where the provision of the device and the Internet access are done by two separate players, then an open platform would probably make sense and operators could loose their dominance. To say the least, that is not the way the industry seems to be heading now.

Tuesday, May 10, 2005

Interesting industry newsletter by Informa

Informa produces an interesting - a free - newsletter on the mobile industry. News cover operators, manufacturers, and the market in general. If you want to have a look, click here.

Monday, May 09, 2005

Is the SAGEM VS1 an indicator of Vodafone's strategy ?

A few web sites have been showing an interesting phone called the VS1. It is produced by Sagem for Vodafone. What is interesting is that the phone seems to have been optimized to target a new segment: Vodafone is going to fight the so-called Ultra Low Cost phones by the Ultra Targetted Phones ! The tendency is always to go up market with ever more sophisticated phones, and
the talk is usually all about smartphones. Here we have a manufacturer and an operator going the opposite way. Is it a one-off or a new strategy? How come this phone is actually produced by a French manufacturer? You would have expected a chinese one, if cost is so important. The key to such phones is of course to get the economics right while preserving the marketing value.
We don't know where it is manufactured, but either this phone will be produced in very large quantities, or Sagem found a way to reduce the design cost for short series.
We don't have many screen shots, but the user interface seems intriguing.
So many questions! The VS1 should be available in Q2, which is about now...
If you want to see it : slashphone. Or Google.

Sunday, May 08, 2005

World Handset Forum Europe

The World Handset Forum (Europe) will take place in Amsterdam on May 10-11th. It is a good place to discuss handset development issues with key industry participants. For more information, visit http://www.ibctelecoms.com/worldhandsetforum/europe/

Friday, May 06, 2005

Welcome

Welcome to mobilephoneTech. The objective of this blog is to discuss various technology approaches to the development of mobile phones. This is not a technical site; the point of view is rather that of technology strategy. It should interest anybody who is involved in the design and marketing of a mobile phone (or a mobile device in general) as well as those who have an interest in the evolution of mobile phones.
I am a strategy consultant working indirectly for a large European telco, hence my interest in the industry, but I try not to be biased towards operators! If I am, shoot at me. Your comments, suggestions of topics and more generally any input will help me make this blog a place for exciting discussions about the industry's issues.