Last week’s S60 Summit from Nokia provided, as always, an interesting look into what the S60 team think are the important medium and long terms issues for the S60 platform. It’s not the short term “we’ve got a new phone” sort of conference, although Samsung did take the opportunity to announce the rather spiffy L870, but rather a chance to explore topics around the current and future development of S60 as a software platform.
It’s clear that expanding the opportunities for developers and communicating their availability is a key area. This ongoing effort goes much further than nurturing the existing developers, it aims to enable new technologies and developer environments on the platform (Web Run-Time, Flash Lite, Open C++, Python) to make it easier to get applications onto the S60 platform.
Notable mentions at the S60 summit included the expansion of Open C with 'Open C++', further building on the cross platform standard (Linux alike) C/C++ APIs. There was a seminar on Adobe's Open Screen Project, which outlined the strategy of a cross platform software development environment built on Adobe's Flash and Air technology. In the expo hall, Flash Lite started to show signs of real maturity with several companies showcasing applications and service solutions. Python, which has gained a strong following in academic institutions, was also mentioned as popular option for rapidly prototyping applications. However what S60 were pushing hardest, and for which they have the highest hopes for the future, is Web Run-Time (WRT). This is a browser-based run-time environment that allows developers to use key web technologies (HTML, Javascript and CSS) to create applications (also known as widgets) for the S60 platform.
There’s every chance that all these names and soups of initials will mean little to the average user – and to be honest that’s exactly as it should be. Developer environments and runtimes are really only of interest to developers - what matters to the consumer is the experience. The last thing S60 needs is end-users having to add in environmental variables, packages and extensions. That's the advantage of building these technologies into a platform-aware way. It means the right elements can either be packaged in the installation files, e.g. the Python run-time, or present in the phone’s firmware, as is the case with WRT. With all the run-time environments on S60, the intention is that, to the end-user, they should look the same - they all have application icons and behave in the same way.
Two example WRT widgets.
As we mentioned, WRT is powered by a number of web technologies; in essence, as with all web-based applications, HTML and CSS provide the application UI and styling while Javascript provides the application engine. In the case of WRT there are a few extra components to tie into into the S60 platform. Firstly, there are a number of custom Javascript API calls which allow access to phone services and functionality, secondly there's a 'plist' file and icon which describe the application and govern the way (name and icon) it appears in the S60 application launcher.
The first iteration of WRT, announced last year, had relatively few Javascript API calls - access to keypad tones, vibra functions, network status and battery status - and consequently the resultant widgets are little more than a web page accessed via an S60 application icon. There are some good uses cases for this type of widget, particularly as a simple access client for web services (e.g. returning stock quotes or train times), but there are some fundamental limitations. The key advantage provided by this first version of WRT was to enable developers to put an icon into the S60 application launcher rather than existing purely as a bookmark in the browser.
The second iteration of WRT, announced at Web 2.0 this year, was a key focus at this year's S60 Summit. It greatly expands the number of Javascript API calls available. WRT will be able to access numerous phone services, such as the camera, GPS (for location), and the calendar and contact stores. This means that it will be possible to create widgets that are much more tightly integrated into the phone to the extent that they start to become much more like applications than individual web pages.
Nokia was keen to stress two key areas that the new version of WRT would enable. The first is context awareness - this is the idea that phone can make available additional information (context) to web services. The most obvious example of this is location information (e.g. location-aware cinema search), but also extends to presence (calendar information) and contact information (who do you know). Combining these together, you could create a widget that looked up film times at your nearest cinema, checked you were available at the appropriate times, offered to book the tickets and then alerted friends to join you. Secondly, the new version enables the creation of mashups between the phone and web services (as distinct from mashups between web services), or put another way, web services that can interact with, and insert information into, the phone. Building on the example above, a widget could insert the film times into your calendar and the contact number into your address book.
A key point in favour of WRT is that it changes the economics of development. At the S60 Summit, several demo stations had widgets on display and there was a clear consensus from the developers that WRT enabled faster development. In the case of Muzeeker, a prototype was up and running in a few hours with a more polished version taking just days. This compared to the Java version that had taken several weeks to put together. Also of note was the fact that WRT will not require certification through Symbian Signed. Instead a similar model to Java ME will be adopted - user prompts will be displayed before accessing phone services or private information. This can potentially run in several modes (controlled by a security policy file): ask once, ask once each session or ask every time. The exact policy implementation will be dictated by each manufacturer on a device by device basis.
WRT will likely continue to develop indirectly too. Since it's browser-based, some of the plug-in browser teachnology will be available to WRT. This is already the case for Flash Lite and future possibilities include future Adobe run-time developments (Air) and, when it arrives on S60 later this year, Microsoft’s Silverlight.
WRT is not without its problems - possibly the most important is that of fragmentation. Mobile widgets are a young technology and consequently there are no standards. Both OMTP and W3C are working in this area, but there are already a number of mobile widget platforms out there: Opera Widgets, Widsets, Plusmo, Yahoo Go Widgets, and so on. Although these are all based on the same web technologies, they often take different approaches. This means the web as a platform on mobile faces fragmentation issues. The use of Javascript API calls, which are currently specific to S60 within WRT, only adds to the problems in this area. Arguably S60 makes up a big enough chunk of the market on its own for WRT development to be viable, but it does feel like a missed opportunity. It is worth bearing in mind that there's not really anything that S60 or the WRT development team can do about this - reality dictates a 'build first, standardise later' approach.
Widget with standard menu and showing up in S60 multi-tasking.
But in the end what it comes down to is that WRT may be the right technology and released at the right time.
In principal there’s nothing fundamentally different to building a WRT widget than there is in coding a web site. Put another way, if you can put it on a web page, there’s no reason why you can’t make it an S60 application. How many S60 Symbian OS developers are there, and compared to how many Web Developers? The answer now is that the numbers are the same! - They just don’t know it yet. There is a strong argument to be made that it is tapping into this resource that will significantly help drive a mobilisation of Web 2.0 content and services.
The architecture of Web 2.0 (open APIs) makes it easy for third parties to access and utilise content and services. For example, why open the web browser, go to your bookmarks, log in to Twitter, type in your latest message and hit send, when you could create a Twitter post widget? This is a rather simple example, but that’s the power of the web-based widget, and that flexibility, scale, and ease of development is what Nokia are targetting.
Existing developers should not feel threatened by all these new tools. There is of course ongoing support for the ‘low level’ languages of Open C and Symbian C++. It will remain the development environment of choice when looking for maximum performance or lower level integration and API calls. It is no different between the relationship Symbian C++ and Java ME have had over the years. In contrast to the early days of Symbian, Java ME has greatly matured and, thanks to JSRs, now has much richer functionality. The situation between the two languages is always something of a moving target - if you want to use cutting edge technology then C++ is the only choice, but what is considered 'cutting edge' changes. Today's cutting edge C++ is tomorrows JSR. That said, it's also possible to see a progression of technology throughout an application's life-cycle. Google Maps is a good example; it started as web service, was made available as a Java application and later made the move to Symbian C++.
Ultimately, each language or run-time environment is suited to certain tasks. WRT is just one more post in a continuum of developer options. You will not see WRT used to create full blown word processors or complicated 3D graphical games. However, with the web as an application platform becoming ever more prevalent, having a quick and easy way to bring them to the mobile world has great potential benefits. At the S60 Summit, Lee Williams underlined this when he talked about how the Internet is driving innovation in technology and creating compelling user experiences and how this matched up with the challenges ahead for S60 (enabling innovation and creating compelling user experiences). It is this convergence between Web 2.0 and Mobile that has provided much of the impetus for WRT and explains why Nokia is heavily promoting it.
Widget for acessing MuZeeker, a music search web service.
For all this enthusiasm for web technologies, it is still early days for WRT. There are currently only fourteen devices which are WRT-enabled (and some of these need firmware upgrades), so it’s not yet the global option for developers in the same way that Symbian C++ or Java ME are. However, this will change quickly. WRT is a standard part of S60 3rd Edition Feature Pack 2, albeit in its first iteration. Given its capabilities, I suspect, the second iteration of WRT will be what really drives uptake. It will be a standard part of the next version of S60 and seems like an ideal candidate for a back port to FP2 phones.
Developers should therefore watch this technology carefully; this is a hot area which is rapidly evolving, but it is also important to keep expectations realistic. Of course, for the end user, the reasons for Web Run-Time are much simpler – better experiences and more applications. For manufacturers, it’s another potential differentiator and platform advantage provided by S60. It seems to be a win-win situation all round.
Ewan Spence and Rafe Blandford, June 2008
Related All About Symbian Podcast (#77)
In the podcast, Rafe and Ganesh cover...
- The new version of the S60 web runtime and what this means to developers and users.
- Accessing functions on the phone, and the security models being used.
- How to make money with web runtime applications.
- "Intelligent" and pro-active Widget design.
- Can widgets aid the discovery and distribution issues of mobile applications?
- The business models of application development.
- Subscription model.
- Premium model.
- Affiliate Transaction model.
- Advertising supported model.
- The Web Runtime is enabling new user experiences.
- Current and future devices with the Web Runtime.