Month: April 2010

Palm: $1.2B Down the Shredder

[The acquisition by HP will not save Palm. Guest author Michael Valukenko explains why the sum of Palm and HP is close to zero]

As an old-time Palm user, I was always secretly hoping for resurgence of this familiar and trusted company. At a rational level however, I didn’t believe that the new Palm stands a chance in rapidly changing smartphone market. See my earlier analysis in Who can save Palm here at the VisionMobile blog.

HP’s acquisition makes Palm part of large and financially solid company, but doesn’t compensate for its other weaknesses. Smartphone competition today boils down to competition of service platforms with Apple and Google leading the way. Considering the realities of today’s smartphone market, there are very few real synergies between HP and Palm.

The three missing synergies
Today people don’t buy smartphones for their hardware, but for what they can do with them. This largely means software platform and services built around the phone. Both Apple and Google excel in this area, albeit using very different approaches.

Palm’s WebOS offers a slick UI and a promise of simplified app development by fully adopting the web paradigm. But it lacks a clear differentiation (a killer use case) and an ecosystem unlocking the device into hundreds or thousands different things people could do with it. Let’s face it: It wasn’t that WebOS devices didn’t sell well because Palm lacked marketing dollars. They didn’t sell because they weren’t good enough compared to competition. HP marketing money and distribution muscle won’t save the day.

Today’s leaders – iPhone, Blackberry and Android – all have clear differentiation: iPhone is all about entertainment and Internet and is backed by large iTunes user base. Blackberry sells mobile email and is backed by corporate IT adoption and a strong distribution network. Android seamlessly integrates with Google services promising free and open Internet. The vague notion of “HP Experience” looks pretty pale in comparison.

Critically important, app developers and Internet companies already have their hands full with iPhone, iPad, Blackberry, Android, not to mention the upcoming Windows Phone 7. What does HP have to offer in exchange for some mind-share? Any bright ideas?

Last, but definitely not least. Mobile operators/carriers take on the lion’s share of smartphone promotion and subsidy costs, hoping to attract new subscribers and increase ARPU of existing ones. What can HP/Palm offer to convince operators to take marketing and subsidy dollars from iPhone, Blackberry and Android, and put them into HP/Palm?  I don’t see much. Do you?

Clear differentiation, developer mindshare and operator subsidies  are all critical today for the success of a smartphone platform. All these were and remain Palm’s weaknesses regardless of its financial situation. HP does not complement Palm in any of these critical areas.

Chasing the Apple dream
A quick glance at HP earnings breakdown reveals HP as an electronics equipment company at its core. The company generates most of it revenues from selling printers, laptops, desktop PC and servers. Smartphone unit sales are catching up to laptop sales, while laptop margins are getting thinner and thinner. It is easy to see how tempting would it be for HP management to try to emulate Apple’s model of selling high-margin devices.

However Apple owes much of its success to its vertical integration, which allows blending hardware, software and services into iconic products. This vertical integration is ideally suited for breaking new grounds and creating new product categories. It is critical factor in Apple’s ability to create such products as Apple Lisa, iPod, iPhone and iPad.

As explained by Clayton Christensen in this seminal paper, vertical integration is an advantage in emerging product categories, where it helps to overcome technical challenges. Vertical integration however becomes a disadvantage in maturing markets, where flexibility, customization and modularity are of greater importance.

It is difficult to see HP successfully reproducing Apple’s model. The opportunity to be the first with iPhone-like product does no longer exist. 

Is this good news?
The deal doesn’t look particularly bright for HP shareholders. But may be in the broad scheme of things the deal is great news for many other people: Investment bankers will pocket multi-million dollar commissions, Palm’s investors and management will be spared from their misery, HP executives will boost their ego, business newspapers will sell some ads, and bloggers (including myself) will have something to write about.

How do you think the acquisition will shape up for Palm and HP?

– Michael

[Michael Vakulenko has been working in the mobile industry for over 16 years starting his career in wireless in Qualcomm. Throughout his career he gained broad experience in many aspects of mobile technologies including handset software, mobile services, network infrastructure and wireless system engineering. Today Michael consults to established companies, start-ups and operators. He can be reached at michaelv [/at/] WaveCompass.com]

Wholesale Applications Community: The Operator Love Affair with Developers

[The Wholesale Application Community has made big headlines in the last two months. But beyond the affectionate operator feelings and investments this signals towards developers, will the initiative succeed where JIL has failed? Guest author Simone Cicero digs behind the hype to see what lies behind the WAC buzz]

Despite its impressive line up of network operators, the Wholesale Applications Community initiative has been greeted with skepticism across both industry-insider and developer audiences.

Founded in February 2010, WAC is an initiative backed by 24 operators with the incredibly audacious vision of unifying apps distribution, packaging and execution. WAC’s mission is about realising “write once deploy everywhere” for mobile applications and enabling developers to “create applications for the long tail” (a concept that dates back to 2004)

So how does WAC plan to achieve such ambitions? The operator-backed initiative has indicated it will provide:
– a reference implementation for a web runtime environment as well as Network Operator APIs
– tools for development including an SDK and an emulator
– billing enablers and specifications for WAC compliant application stores (as mentioned in the FAQ)

WAC = BONDI + JIL
Like a phoenix, WAC seems to be born out of the BONDI and JIL initiatives and has committed to evolving BONDI and JIL into a common specification within the next 12 months.

OMTP’s BONDI has been the most-successful operator-backed initiative aimed at developers. BONDI is in essence a specification of Device APIs for securely accessing device functionality (incl. status, sensors, telephony and SIM APIs) and user data (incl. phonebook, location and gallery). BONDI APIs are accessible from widget runtimes and should (theoretically) also become available via browsers.

The BONDI project has attracted the interest of a few thousand developers and provided an official Windows Mobile reference implementation (with more unofficial implementation projects in the pipeline). We should also see deployment on commercial handsets by the end of 2010  with the first BONDI-compliant widget SDK already appearing from LG.

The JIL (Joint Innovation Labs) project was created by four mega network operators (Vodafone, Softbank, China Mobile and Verizon) to hook operators within the App Store game, and control the app submission, billing and distribution process. JIL  is a realisation that the standards route (read: OMA or GSMA) is a turtle-speed approach in a rabbit-speed market. As such, JIL embraced and extended the existing W3C widget specs, adding its own APIs and security model.  However, despite the operator investments and ambitions, to date JIL has not delivered much beyond a widget spec and SDK.

A third operator initiative that is part of the WAC scope is Network APIs, i.e. APIs allowing resources from the network (e.g. location, presence, user info) to be exposed programmatically to developers: in this area WAC will build on early achievements of GSMA OneAPI Initiative.

In essence WAC is an attempt to wrap BONDI, JIL and Network API specs and tools into a single operator-led initiative.

In parallel to the technical objectives, WAC aims to define a simplified distribution and deployment model for mobile apps. Rather than build its own Market WAC will probably seek to certify “associated WAC application stores” as well with third party markets offering WAC compliant applications.

WAC challenges ahead
To pragmatically assess WAC’s potential, we need to consider how it differs to what’s come before, the environment in which it plays in, and its stated ambitions and roadmap.

Some industry observers compare the Wholesale Applications Community with the JCP (Java Community process) and Java ME in terms of the challenges of standardising app development and distribution. Despite being still the most used and, for sure, the runtime with the largest installed base, the story of Java ME as a platform has been undoubtedly fraught with strategic and execution flaws.

Sun failed to see the opportunity of an app store; Java store is both a half-baked effort and a latecomer to the App Store market considering that Java ME was launched in 2001. Neither did Sun succeed at its main goal – promulgating a consistent runtime (open source or closed source) within the 1B-a-year device market by choosing to over-protect its traditional revenue streams coming from licensing and TCK testing. Sun also chose to license its reference implementation rather than impose a Sun-brewed, mobile Java runtime with consistency and compatibility as the first priority.

In parallel, the design of JCP proved too slow and bureaucratic. The JCP members spent too long entangled in preferred ballots, drafts, reviews, public vs private releases, resulting in specs that were just too late to market. The best testament to that was probably the MIDP3 saga, which arrived at the era of Android and iPhone development that doesn’t need Java ME any more. With 24 operator members behind the WAC initiative, it’s going to prove hard to reach consensus amongst competitors.

It’s also worth realizing that whereas Java ME has been loosely governed by Sun Microsystems (an entity external to the mobile value chain) the WAC consortium is led by operators who play a critical role in the mobile value chain and can, at least in the developed mobile markets, drive the product customization phase – and as such WAC is better positioned at – for example – mandating WAC runtime specs to be preloaded on an Android handset. At the same time, operator specs are seen by handset OEMs as long wishlists with the device compliance index being on continual decline for European operators.

The timing of WAC is another challenge. Given that it will take (at least) 12 months to merge BONDI and JIL, the first WAC-compliant device won’t hit the market before mid-2011. Where will iPhone, Android, Windows Mobile and the other competing platforms be in the next 12 months? What features should a developer expect from a runtime hitting the market in 18 months’ time? Not to mention that developer choices are already being set in stone as the major platforms lock-in developer mindsets (just look at how fast iPhone/iPad apps are ramping up now that that OSX is the number one choice for many mobile developers).

Is there a future for WAC?
The apps market is showing worrying signs for operators: mobile app stores are depriving operators from new revenue streams and pushing them further away from the customer front – only leaving operators with the cost burden of supporting customers in the post-sales phase and building out bigger, fatter bit pipes to carry the app-induced traffic.

Once upon a time, operators were responsible for most technology innovation like voicemail, the 2-line-in-1-SIM, premium SMS and Multimedia MMS and high speed networks.

Operators are still in the driver seat with 70% of the mobile trillion-pie flowing through the networks. In Europe, North America and the Far East, network operators still play the dominant role whilst in control of product ranging, subsidy, distribution and retailing decisions.

Yet during the last few years, the ownership of innovation in mobile services and handset products is migrating from the operator hands to Internet/PC players, with operators left to play the role of bureaucrats, support providers and handset subsidization agents.  The latest operator innovation like RCS, JIL and network-exposed location seems only to reinvent the wheel. All this, while players from the PC/internet industry like Apple exploit the rivalry between operators by soliciting major subsidies.

At the end of the day, the Wholesale Applications Community initiative is a knee-jerk reaction on the part of operators – an effort towards embracing developers and seizing the community of value-adding actors away from the likes of Nokia, Apple and Google. Now the question is how well and how quickly can WAC execute on the ambitious declaration of intents that WAC is today.

WAC should exploit its stronghold to add value where gaps exist at present, rather than reinventing the wheel. As such, instead of specifying runtimes or gating (and chocking!) the application submission process, WAC should focus on mandating an affordable and consistent revenue sharing policy across operators. By facilitating micro-payments WAC could enable new service charging models such as pay per (single) use, giving developers important alternatives to the free, ad-supported or paid app options.

Another key focus for WAC should be to empower developers with unique network-based APIs like user demographics and targeting and provide decent usage analytics (as mentioned by O2’s James Parton) and a recommendation engine to allow developers to better target the user audience and their application features based on the vast amount of demographics and usage information the operators/carriers hold in their network.

Finally, rather than specifying a web runtime spec based on a lowest-common-denominator approach, WAC should embrace existing runtime specs as much as possible, and consider embracing HTML5 which seems to be unanimously adopted by the major players of the industry, including Nokia, Apple and Google.

[Update: On May 5, WAC held an analyst webinar outlining a few important points. Specifically, Tim Raby, CEO of OMTP is acting as the interim CEO of WAC, while a formal Board for the non-profit organisation will be elected in July 2010. Secondly, WAC indicated it’s planning to standardise the commercial model (perhaps extending to the revenue share formula) for developers and ‘compliant’ app store owners. Developer documentation, developer events and further details on the mission and deliverables of WAC are planned for the second half of 2010.]

What are your thoughts on WAC and the role of operators in mobile apps?

– Simone

[Simone is an mobile strategist, innovation specialist, technology addict and open source enthusiast, having followed the disruptive changes of the mobile industry over the last few years. Simone has served at Three’s Global Device and Application group and at as a consultant at Altran. You can also follow Simone on his personal blog at meedabyte.wordpress.com]

Is Android Evil?

[Is Android really open? Research Director Andreas Constantinou uncovers the many control points behind Android and explains why Android might be the most closed system in the history of open source].
The article is also available in Chinese and Greek.

You thought Android was open? The Android governance model consists of an elaborate set of control points that allows Google to bundle its own services and control the exact software and hardware make-up on every handset. All this while touting the openness rhetoric that is founded on the Apache permissive license used in the Android SDK.

[updated in response to reader comments]: Whereas Android is completely open for the software developer ecosystem, it’s completely closed for the handset OEM (pre-load) ecosystem. There is no other platform which is so asymmetrical in terms of its governance structures.

Indeed, Google’s mobile platform is the smartest implementation of open source designed for driving commercial agendas. But before we dig into why, it’s worth discussing why Android’s success has very little to do with open source.

What makes Android tick
Despite early skepticism, Google’s Android operating system has been unequivocally supported by the mobile industry, including more network operators and handset manufacturers than one can count – with the stubborn exception of Nokia. Android managed to ramp from 1 handset model in 2008 to 50+ models announced for 2010 launch, leaving most industry observers in awe.

The Android success has nothing to do with open source; it’s owed to three key factors:

– Apple. As strange as it might seem, Android owes much of its success to one of its arch-rivals. Let me explain. With the unprecedented success of the iPhone and the take-it-or-leave-it terms dictated by Apple to network operators, the carriers have been eagerly looking for cheaper alternatives; as such the tier-1 operators have been embarking on Android projects to produce iPhones for people who can’t afford the iPhone and more importantly, without forking out the 300EUR+ subsidy needed to remain competitive in an iPhone market.

– Network operators/carriers around the world are eager to differentiate. Android provides the allure of a unified software platform supporting operator differentiation at a low cost (3 months instead of 12+ months offered by SavaJe, which was also aimed at the MNO customisation market). For larger operators with a software strategy, Android also presents a safe investment, as the mainstream option for bringing down the cost of smartphones. That’s why most Android handset projects are backed by a commercial bipoles of operator + OEM deals, with purchase commitments and NRE fees coming from the operator.

– Qualcomm. The $10B chipset vendor has been paramount to Android’s ramp up; manufacturers can take Qualcomm’s hardware reference design which is pre-integrated with Android and can go to market within an estimated 9-12 months (down from 16 months for the Motorola Cliq handset and 24+ months for the HTC G1). Besides Qualcomm we should also mention TI’s OMAP3 platform (on which Moto Droid is based) and ST Ericsson and Broadcom who are ramping up to offer chipsets with out-of-the-box support for Android.

In other words, in an Android handset, most of the OEM budget goes into differentiation; compare that to Symbian where most of the OEM budget goes into baseporting (radio and functional integration of hardware) due to historical choices made by Symbian in 2001. All-in-all, Android allows OEMs to reduce their R&D budgets and invest in differentiation, which is mana from heaven to manufacturers.

We should also not forget the ‘free factor’ (technically zero per-unit royalties for the public SDK) which stirred the emotional hype around Android handsets.

All in all, the ‘open source’ marketing moniker has been very successful at triggering major industry disruption – incl. Nokia ‘s acquisition of Symbian and the derailment of Windows Mobile. Perhaps more importantly, the openness rhetoric and the Google aura has attracted thousands of developers on the platform, at a time when the money equation is sub-par; consider that – compared to the Apple devices – Android handsets are around 9x less in volume and paid-for apps are available in 6x fewer countries.

Behind the Open Source facade
What’s even more fascinating is how closed Android is, despite Google’s old do-no-evil don’t be evil mantra and the permissive Apache 2 license which Android SDK source code is under. Paraphrasing a famous line from Henry Ford’s book on the Model-T, anyone can have Android in their own colour as long as it’s black. Android is the best example of how a company can use open source to build up interest and community participation, while running a very tight commercial model. [updated in response to reader comments:] Again I ‘ll emphasize that the closed aspects of Android apply to the handset OEM (pre-load) ecosystem, not the software developer (post-load) ecosystem (see the comments section for a deep dive into pre-load vs post-load].

How does Google control what services, software and hardware ships in Android handsets? The search giant has built an elaborate system of control points around Android handsets.

To dig deeper we spent two months talking to industry sources close to Android commercials – and the reality has been startling. From a high level, Google uses 8 control points to manage the make-up of Android handsets:

1. Private branches. There are multiple, private codelines available to selected partners (typically the OEM working on an Android project) on a need-to-know basis only. The private codelines are an estimated 6+ months ahead of the public SDK and therefore essential for an OEM to stay competitive. The main motivation for the public SDK and source code is to introduce the latest features (those stemming from private branches) into third party apps.

2.  Closed review process. All code reviewers work for Google, meaning that Google is the only authority that can accept or reject a code submission from the community. There is also a rampant NIH (not invented here) culture inside Google that assumes code written by Googlers is second to none. Ask anyone who’s tried to contribute a patch to Android and you hear the same story: very few contributions get in and often no reason is offered on rejection.

3. Speed of evolution. Google innovates the Android platform at a speed that’s unprecedented for the mobile industry, releasing 4 major updates (1.6  to 2.1) in 18 months. OEMs wanting to build on Android have no choice but to stay close to Google so as not to lose on new features/bug fixes released. The Nexus One, Motorola Droid, HTC G1 and other Experience handsets serve the purpose of innovation testbeds for Google.

4. Incomplete software. The public SDK source code is by no means sufficient to build a handset. Key building blocks missing are radio integration, international language packs, operator packs – and of course Google’s closed source apps like Market, Gmail and GTalk. There are a few custom ROM builders with a full Android stack like the Cyanogen distribution, but these use binaries that are not licensed for distribution in commercial handsets.

5. Gated developer community. Android Market is the exclusive distribution and discovery channel for the 40,000+ apps created by developers; and is available to phone manufacturers on separate agreement. This is one of the strongest control points as no OEM would dare produce a handset that doesn’t tap into the Android Market (perhaps with the exception of DECT phones, picture frames, in-car terminals or other exotic uses of Android). However, one should acknowledge that Android’s acceptance process for Market apps is liberal as it gets – and the complete antithesis of the Apple vetting process for apps.

6. Anti-fragmentation agreement. Little is known about the anti-fragmentation agreement signed by OHA members but we understand it’s a commitment to not release handsets which are not CTS compliant (more on CTS later).

7. Private roadmap. The visibility offered into Android’s roadmap is pathetic. At the time of writing, the roadmap published publicly is a year out of date (Q1 2009). To get a sneak peak into the private roadmap you need Google’s blessing.

8. Android trademark. Google holds the trademark to the Android name; as a manufacturer you can only leverage on the Android branding with approval from Google, much like how you need Sun’s approval to claim your handset is Java-powered.

In short, it’s either the Google way or the highway. If you want to branch off Android you ‘re completely on your own and you need resources of the size of China Mobile (see their OMS effort) to make it viable (hint: China Mobile is the biggest network operator bar none).

The Open Handset Alliance is another myth; since Google managed to attract sufficient industry interest in 2008, the OHA is simply a set of signatures with membership serving only as a VIP Club badge.

Another big chapter in the Android saga is the CTS (compatibility test suite) which is the formal testing process by which a handset passes Google requirements. According to our sources, CTS extends significantly beyond API compliance, and into performance testing, hardware features, device design, UI specs and bundled services. CTS is based on the principle of ensuring baseline compliance, so it’s ok to add features, but it’s not ok to detract; compare this with Apple’s no-Flash policy. Note that beyond CTS compliance, there are additional commercial licensing agreements that OEMs have to sign for Google services and private line access.

CTS hampers Android’s progress as well, as it precludes OEMs from creating stripped-down versions of Android that would fit on mass-market phones – those shipping in the 10s of millions. CTS – and forward compatibility to the pool of 40,000+ apps – is Google’s main challenge for hitting a 2-digit market share in the smartphone market. These restrictions – and frienemy relationship between Google and its OEM partners – have stirred up discussions of an ‘Android foundation‘ within OEM circles

The Google Endgame
With Android, Google aims to deliver a consistent platform to its own revenue-generating services. For now, this is the ad business. But in the future, Google is aiming at voice (reaching the billions who don’t have a data connection) and Checkout (i.e. becoming the Visa of mobile).

Yet whatever the endgame, it’s worth realising that [from the manufacturer perspective] Android is no more open – and no less closed – than [licensable operating systems like] Windows Mobile, Apple OSX or PalmOS, Symbian and BREW; it’s the smartest implementation of open source aimed at driving commercial agendas. Android is much less about the do-no-evil rhetoric that the PR spinners in Mountain View would like us to think.

[Updated in response to readers’ comments:] so, is Android evil? No, it isn’t. It has done no harm – quite the contrary, Android has boosted the level of innovation on mobile software. The point of the article is not to vilify Google or concoct visions of Darth Vader; but to balance the level of openness hysteria with a reality check on the commercial dynamics of mobile open source.

– Andreas
you should follow me on twitter: @andreascon

[we are running on-site business workshops for companies who want to understand the commercials behind Android and OHA. Contact us if you ‘re interested. Or, if you are a mobile developer, voice out your views on Android and other mobile platforms in the biggest mobile developer survey to date. Join in at visionmobile.com/developers]

Why handset OEMs shouldn't mess with UX and other lessons from the automotive industry

[Why are so many phone manufacturers trying to develop their own branded experience? Guest author Thucydides Sigs argues that there should be a limit to UX innovation and looks at what the phone industry can learn from how car manufacturers differentiate]

In Mobile World Congress, during a special panel on “New Devices” Motorola’s VP of software, Christy Wyatt, made an interesting statement: “I don’t want the same phone as my teenage daughter“. This was followed by Ari Jaaksi, Nokia VP of Maemo – nodding his head in confirmation.

Hmm. Last I checked, most soccer moms in the US either use an iPhone or want to get one. Most of their teenage daughters either have one or beg for one. And a surprising number of dads do as well. So why is it that Apple is doing quite well without customizing their iPhone, while Motorola and Nokia make a “Signature experience” such a core components of their strategy?

Before we start, half of the challenge is due to terminology, so lets setup some definitions. For years, OEMs have been trying to create a unique “Branded Experience” that spans multiple dimensions: how the device feels, which functions and services are bundled, how polished the graphics look. Part of this “Branded Experience” is also how consumers launch or switch between tasks, i.e. the “User Interaction model” which is largely dictated by the underlying “Software Platform”.

Most of the major consumer electronics brands have made significant efforts to establish their own “branded user experience”. Lenovo just showed their new U1 Tablet with their own OS and UX during CES, and Dell have been playing with “Dell Experience” on their Linux devices as well.

Nokia, which could have been shipping millions of Android phones today, felt compelled to do their own thing and have been spending hundreds of millions on building their own software and services platform – included the user interaction model, consumer services and branded user experience; making an almost life or death bet that they can become a ‘real’ software company.

The Phone Industry vs the Car Industry
So why are so many device vendors chasing this illusive goal? What are they trying to gain? What kind of user experience customization that makes sense for an OEM? And what doesn’t?

To crack this challenge, lets use the car industry as an analogy. Car vendors compete on industrial design, engine and performance, cost, colors, finish, entertainment, comfort and many other factors. But they don’t try to move the gas pedal to the other side just to have their own “Driving experience. Ford or BMW don’t say “We need to create our own driving experiences so we will use a joystick in the center panel and throttle on the door.”

Why is it that the Car industry competes on “overall user experience” but mostly refrain from touching the “User Interaction” model ?

Design constraints
Any interaction design is driven by three constraints: (i) The human body physical constraints, (ii) the task at hand constraints and (iii) the established paradigm constraints

First: the human body constraints. How many legs we have effects how many pedals we can use simultaneously. How we sit effects what we can do with our hands vs. legs. Same applies to the phone; the size of our palm, the number of fingers. These physical constraints limit the possible variations of both physical design and interaction design. Sure, you can come up with five pedals but you can’t reach them all at the same time. Or in the phone case, you can create a design with twenty main choices – but you don’t have enough fingers. And then there are the mental constraints of the human mind; how many choices we can effectively deal with at the same time, how we scan from right-to left and top to bottom, etc.

Second: the task at hand constraints. You need to drive the car: control speed and direction simultaneously so you need to access both the steering wheel and pedals at the same time. Same with phones; when phones were used mostly for voice calls, you needed to easily access the 0-9 digits with your right thumb and all phones ended up with the 3×5 key matrix. Nobody thought to customize the experience by providing 0-9 keys in a single row.  Well – Nokia did decide to try a circular keyboard with the 3650 – and it didn’t go that well.

Third: the established paradigm constraints: once a working interaction model is accepted, it reinforces itself as more and more consumers use it. It does not – and often is not – the best possible interaction model. It just needs to be good enough so consumers will keep on using it. And once they do – and more and more users do – it becomes very hard for others to transition to a different paradigm. So even if you have a better user interaction model, it is often impossible to change the dominant existing interaction model (the Qwerty keyboard is a great example here: suboptimal arrangement, but impossible to change the established paradigm). Small tweaks here and there (a la Manual vs. Automatic cars, Mac vs Windows, or Android vs iPhone) are possible – but there is only so much that makes sense to customize.

Android didn’t really copy the iPhone – they are similar because of the human and paradigm constraints involved in small touch devices. Once you design an interface for a four inch touch device, there are not too many different choices. The designs just converge on similar concepts. Attempts to customize the UX beyond that are futile – they result either inferior user experience (because the human or service constraints are ignored) or just don’t get adopted for lack of critical mass.

What actually matters
What actually matters for a “branded experience” and where differentiation makes sense – is the services & features. Audi can compete by adopting their automobile industrial design language to the latest fashion, bundling “Services” like  infotainment system or features like ABS. In a similar way, phone or computer vendors can differentiate on slicker industrial design, bundled music or navigation services (Nokia attempts to do with Ovi) or features like inductive charging (Palm).

Instead of OEMs focusing on strengthening their brand by building their own interaction model, they should focus on the consumers (what a novel concept) and what consumers want: which means empowering the consumers to personalize the device to their own needs. This is the powerful role the application store fills and why Apple can ship the same iPhone to the teenage girl, the soccer mom and the business daddy.  Not only is focusing on the services and app store good for consumers, it is also good for the OEMs: making consumers happy is the best thing you can do to strengthen your brand. And – there is a lot to gain by selling real-estate on their app stores: turning them into “Malls” and renting out sections. Turning the OEM into a ‘landlord’ who can ‘auction’ this ‘real-estate’ statically or dynamically to all application developers. VisionMobile have been covering this trend in their annual Mobile Megatrends report.

So why are so many OEMs going down the slippery slope of “Branded User Experience” and end up with their own flawed user interaction model and a large software team needed to keep the effort alive?

The faulty OEM logic
First, because they are looking at Apple and getting envious. We industry insiders hate to admit it, but there is a strong Apple envy syndrome in the industry. The OEM false logic is something like this “Apple has high margins, branded user experience and owns the user interaction paradigm. So if we develop our own user interaction and create a branded user experience, we will have high margins”

WRONG: Just pure faulty logic. The fact that lions have a mane does not mean that if you bought a mane wig you will become a lion.  There is much more to Apple’s high margins than owning the user interaction model.

Second, when new usage paradigms emerge, and there is no dominant user interaction model, there are opportunities to innovate and be the first to build the new paradigm.  When the world was dominated by closed source software (the Microsoft era) this offered significant revenue upside.

But we live in a different era – “Open Source” has changed the dynamics of the game. All it takes is that at least one of the software solutions be open sourced, and the upside from controlling the basic interaction model and underlying software platform is minimal or none. The company who leads this effort gets industry recognition, establishes itself as a thought leader and strengthens its brand – but it is no longer a sustainable source of revenues or competitive advantage.  To the contrary; quite possibly, they can turn into the “mule” which guides the rest of the industry and can be embraced and extended.

Motorola’s Sanjay Jha realized this when he made Motorola embrace (and extend) Android. Nokia on the other hand could have been selling millions of fantastic Android phones with Ovi services if it wasn’t for their Finnish pride.

When Microsoft had to fight Netscape in the mid nineties, it has done so by an “Embrace and Extend” strategy. It would be beneficial to many OEMs to remember this and put an end to their mediocre attempts to invent new interaction models. Instead focus on what matters to consumers; great app store, superior services and overall compelling device experience.

– Thucycides Sigs

[Thucydides Sigs – a pseudonym – has many years of experience juggling computing constraints, mobile software and consumers needs. With that said, imagine listening to a violin sonata not know who the artist is or who composed it. You end up having to listen more carefully in order to make a judgment. He can be reached at thucydides /dot/ sigs [at] gmail [dot] com]