Keith Dyer examines how operators are redefining the user interface to deliver applications and services to users in a customisable way. In the following section Steve Baker says the software platform is crucial.
Matts Nilson is ceo of OMTP, (Open Mobile Terminal Platform Ltd), a grouping of mobile operators formed to drive forward standards for the specification of the user interface and application execution environment of mobile handsets.
The body defines the requirements for look and feel customisation of a handset, defines the common operator requirements for hardware components and defragmentation and defines the application platform requirements for logical user experience customisation.
What this means is that in functions like a message composer, browser interactions and basic phone functions, an operator should be able to tailor the look and feel of the device menu structure to its own needs and requirements. This includes setting wallpaper, colour scheme of menus, selection of applications accessible from the top menu list, and applications accessible from the stand by screen. In terms of device management OMTP is defining specifications so an operator can download, configure, and update a client based (off line) operator menu structure over the air to a device.
An actual example of this user experience customisation would be to add branding across the terminal UI in a consistent manner across all terminals, combined with application integration that defines menu structures across all terminals, including the addition of links to operator applications and services.
The overall goal is to reduce the number of variants and take unnecessary costs out of the industry without stifling innovation.
“The user interface and the execution environment is subject to differentiation, and operators would like to take control by being able to link the user interface element to their service facility,” Nilson says. To this end the OMTP has been working on several deliverables – producing customisation requirement documents that take all the functional elements and defines them, as well as saying how to do that technically, representing them in declarative data in an XML file structure.
“We are also looking at the execution environment level. Operators want to be able to download their own application like a messaging client, so we are driving requirements for that. If you have a common structure for the elements you want to customise then it simplifies things for handset vendors.
“Now we are in a situation where operators are producing 1000 page documents on customisation for their vendor partners. Instead we want to get the basic elements and the data structure and XML files for any terminal platform.”
So does Nilson think such an approach will be too restrictive for handset vendors?
“We’ve seen operators with full control over the user interface and it has been something some branded manufacturers have said no to, they feel the end user still must be able to override the operator customisation. We’ve also seen a situation where perhaps operators have the requirement to lock the user interface where it is sold and then in a given time period they can release it. That is a matter for commercial discussions between the operators and the terminal vendors.
“It will be a trade off but what we are talking about is a tool box or customisation and building the look and feel that really enables the uptake of data services.”
Nilson says that having such specifications in place will also greatly simplify the device management space, where a mini-industry has been formed transcoding content and reshaping it for different terminal platforms and displays.
“This simplifies the process of device management significantly, the codes take out the transcoding boxes and all that stuff. With automatic UI management you don’t need to be handling each and every phone on the market.”
Handset software is central to branding, ARPU and customer loyalty challenges, says TTPCom’s Steve Baker.
Network operators are promoting services heavily as they look at ways of taking advantage of the very wide bandwidths suddenly available from 3G. The challenge for the handset manufacturer in meeting demands of this market is two pronged. One is to deal with the increased complexity and functionality of the handset needed to handle some of the new services enabled by 3G, and the other is how to provide distinctive offerings that suit market segmentation— taking into account the economics of developing these handsets in high volumes.
It’s no longer simply a case of providing a customised splash screen and logo — the operator wants deeper customisation. However, the growing number of applications required makes integration and testing of each new application expensive and adds to the risk factor in getting a handset to market quickly. In order to address the rapidly changing needs of different markets and regions, the manufacturers themselves are keen to use multiple baseband platforms to serve different application needs.
The development flow in creating a new handset involves five key steps:
1) sourcing software, applications, and setting up the tools; 2) integration and development; 3) validation and debug of the software platform; 4) customisation of multiple applications and the UI (user interface) with multiple tools; 5) acceptance testing
Taking this flow into account, greater customisation can be achieved but then the manufacturer needs to maintain a large portfolio of product variants. It’s clear that this can be economically unjustifiable — especially when deep customisation requires applications from many different vendors to be combined and it is necessary to integrate each vendor’s proprietary API and software tool-chains. It also becomes difficult to re-use applications across multiple platforms because manufacturers typically maintain separate user-interface design teams, which becomes costly and highly inefficient. There are many UI tools around but these are focused on the narrow visual aspects of the UI design.
It is also a myth that 3G handsets must
all be ‘smart’ phones in order to exploit the advantages of the new services available on the network. The majority of users tend to want only ‘feature’ phones rather than smart phones — all they need is something that can take advantage of the extra data pipe.
Feature phones (as well as smart phones) for 3G networks tend to have the same base features as those designed for 2/2.5G. So if the handset manufacturer is already developing handsets using a platform that allows an entire set of pre-integrated and pre-tested applications, then there is no reason why it is not possible to re-use the same applications and add new customised applications specifically intended for use on 3G networks.
The idea of a platform-based approach is very important in meeting both the needs of rapidly adding new features as well as allowing manufacturers to mix and match different features and customise the UI in order to differentiate and provide distinctly different offerings based on the same base model and across different basebands. The basics of this approach are to create an applications and methodology framework that can be used for 2G, 2.5G and 3G. Manufacturers can then select from best-of-breed third party applications, and add in-house functions to increase differentiation. The tools available would enable application development, UI customisation, and product test and validation, in a way that shrinks the development cycle significantly.
The user interface can be customised to whatever extent required using specially developed UI tools (see above picture) and a common UI resource database created. Using a PC-based simulator, real handset code can be run to simulate network activities (such as making calls, sending SMS, signal strength) as well as hardware events (such as key presses and battery status).
The use of an application-platform can thus improve application developer productivity by 50% and reduce development costs as a result of PC-based simulation.
In conclusion, the manufacturer’s ability to build new handsets on an accepted application framework will be key to the operators’ ability to respond rapidly to market needs. This is especially so as they try to entice users to convert to 3G services. The extended services that 3G provide don’t need completely new handsets, but added features. So if an appropriate applications platform is available, manufacturers should be confident in being able to meet the operators’ demands by re-using software and applications from existing handsets, rather than embarking on a costly new product development programme. This applications platform will not only allow new handsets to be introduced to market quickly, but it will also enable customisation of the user’s experience according to the operator’s own brand and unique features.