Handset software is a fascinating topic in the mobile industry, albeit one that is often misunderstood. Application environments like Java, Flash Lite and Qtopia open the world of handset software to developers and allow the handset GUI to be customised. Here I introduce a new taxonomy for application enviroments and explain why seemingly distinct technologies like S60, Widsets, Maemo, Qtopia and Openwave MIDAS are essentially part of the same landscape.
[Note: I have updated this article in response to much feedback and comments (thanks Nick, Philippe and Malcolm). Thanks also to Judy Breck maintainer of the Carnival of the Mobilists for selecting this article as post of the week.]
Today there are 10s of different tools technologies for opening up handset software to developers and generally those who want to customise the handset GUI in some shape or form. These range from skins designers, to games developers, to operators who want to create a ‘signature’ look & feel spanning the entire user interface. I would argue that application environments include not only Java, as well as environments for creating skins, desktop UIs (a.k.a. idle screens) and core applications (dialler, menu system, email, messaging applications, etc which are entirely different to downloadable applications).
Contrary to popular understanding, openness is not an exclusive privilege of open operating systems (OSes) as I argued in a previous research paper. A range of technologies exist to ‘open’ access to the handset software internals, and can be divided in two categories: external and internal application environments.
The distinction between external and internal environments is down to several variables: level of functionality exposed to an application, who can access that functionality (certified apps only?), depth of integration (e.g. can you replace core apps such as the dialler and contacts application), when an application can be installed (at the point of manufacture, before the point of sale, or after the point of sale) and who can install the application.
1. External application environments, i.e. those which allow application development and handset customisation after the software has been embedded in the handset ROM. These are generally accessible to external developers, scripters and designers. Examples are: – Nokia’s S60, SonyEricsson’s UIQ, Microsoft’s Windows Mobile and Qualcomm’s BREW, which are advanced platforms. These can also be viewed as external application environments, in that they offer a rich set of APIs for application development and deployment post-load, in other words environments designed for developing downloadable but not core applications. For example companies like DreamSpring have created good contacts replacement applications for UIQ and S60. However such applications are not a complete replacement for core apps (such as the contacts app) since the can only hide the built-in app, and they are not able to access sensitive APIs such as the voice-dialling API as this is hidden by the handset manufacturer. See my comment on this post for further analysis on why S60/UIQ etc are designed as external and not internal app environments. – Open C (POSIX APIs on top of Symbian), which are C/C++ APIs aimed for use by application developers – Java 2 ME (in its myriad forms and extensions), Python for S60, .NET Compact Framework and AppForge, a range of application environments for developers or scripters – Adobe’s Flash Lite aimed at scripters and designers developing graphics-intensive apps. – S60 ActiveIdle, Windows Mobile homescreen framework and Nokia’s Widsets, a range of technologies for allowing developers to customise the UI desktop (aka idle screen) – Nokia’s Carbide.UI theme edition tool for deep skinning of the handset GUI
2. Internal application environments, i.e. those which allow application development and handset customisation before the software has been embedded in handset ROM (and in certain cases during the handset lifetime, too). These are accessible to handset manufacturers, network operators and handset distributors. Examples are: – Openwave MIDAS, a ‘deep’ scripting environment for creating operator-customised applications – SVG players from Ikivo and BitFlash for developing graphics-rich, interactive applications such as Vodafone’s Live! Cast. – TAT’s Cascades, Digital Airways’ Kaleido and Mentor Graphics’ Inflexion (previously NextDevice), which are rapid prototyping tools software frameworks for rapidly creating custom end-to-end user interfaces (i.e. the entire suite of core applications) from scratch. – e-SIM (now part of SKY Mobile Media) and Comneon’s APOXI, which are development tools for building suites of core applications (albeit tools which are more aimed towards engineers than designers). – Trolltech’s Qtopia, Maemo’s Hildon port, ALP’s Hiker, OpenMoko’s application framework, TTPCom’s Ajar and Windows CE app framework, which are sets of C/C++ APIs for creating core applications and managing application communication and lifecycle.
In the next diagram I attempt to classify the above application environments in terms of the extent of customisation which they permit and the time at which they can be applied.
The x-axes show, the time of customisation is directly related to the barriers to customisation; internal application environments are mostly accessible to the manufacturers and partners, whereas external application environments are accessible to all. Note that the chart is quite extensive but it is still work in progress.
The y-axis shows that there are four broad types of customisation that can be applied via application environments:
– change of themes and skins across the handset (e.g. Carbide UI theme edition)
– development and deployment of downloadable applications (using e.g. S60, UIQ, Windows Mobile, BREW)
– replacement of a core application (e.g. replacing the idle screen or contacts app)
– core application re-design (redesigning the entire user interface from scratch)
This landscape map is very revealing, but still it doesn’t do enough justice to highlight some important parameters of application environments: the cost of customisation, the part of the software stack which a technology provides, and the target addressable market in terms of breadth of device models. Another important parameter is why customisation is applied: this can be to re-enforce branding (and retain customers) or to provide easier discovery of, and access to, new services by operators and third parties.
A couple of noteworthy remarks on the map: – Flash Lite is moving from an application environment for downloadable, graphics-intensive apps, to an environment for creating other core applications such as the idle screen and the dialler (see the Samsung D900 implementation for example). – Java is also moving towards enabling development of desktop UIs (aka idle screens) and some core apps, thanks to the capabilities introduced in MIDP3.
So what are the trends in application environments? On one hand all ecosystem players, from operators to manufacturers and beyond are striving to reduce the high time-to-market impact of pre-launch customisation. At the same time, external application environments do not reach as far as core applications (desktop UI, dialler, menus, email/calendar/contacts applications, camera application, etc), due to the lack of modular design of most operating systems today (including Symbian/S60 and Windows Mobile, the so-called ‘open’ OSes).
Therefore, a number of technologies are being introduced to bring much-needed modularity within application environments, both pre- and post-launch. These range from rapid application creation tools from TAT, Digital Airways and Mentor Graphics, to Open Plug’s FlexibleWare modular software development framework and Red Bend’s Embedded Feature Delivery technology. These technologies will be impacting not only handset development practices, but also making an impact to the consumer market. Within the next year we should hopefully be seeing many more examples of unique GUIs such as Vodafone’s Simply range and B&O’s Serene handset.
Thoughts ?