Previously... Symbian^4 and UIEMO
To understand the changes taking place now it is worth recalling the plans in the roadmap that was published shortly after the Symbian Foundation came into being. There was a clear aim of moving the platform to open source, with the primary effort being around code clean up, legal hurdles and management and release processes. At the same time, platform development would continue with the core OS, largely following plans laid down by Symbian Ltd.
However, it had also been apparent for some time, reinforced by the emergence of iOS and Android, that a UI renewal was required. Responsibility for UI had previously lain outside of Symbian Ltd - with Sony Ericsson's UIQ Technology and Nokia's Series 60. In hindsight it seems obvious that UI development had been significantly under-resourced, but at the time the importance of UI in competitive differentiation was not as clear as it is today. The end result was that the UI layers were not only fragmented, but they were also lagging behind core OS development. This gave rise to the situation we have today with a technically sophisticated and mature core OS, but a UI that is widely perceived as lagging behind.
The old UIs: Series 60 UI (N73) and UIQ UI (M600)
The Symbian Foundation plans, in reality dictated by Nokia but universally backed by its board members, essentially called for a two stage platform development timetable. First would be the delivery of a number of core OS updates, with only minor UI modifications (Symbian^3) and second would be a UI renewal with only minor core OS updates (Symbian^4). This is, of course, an over-simplification, but the broad brushstrokes are correct. Out of context, this plan might seem to be the wrong way round (core first, then UI), but in reality the plans were largely dictated by existing development schedules.
Symbian^3 is a major technical milestone. It is sometimes characterised as an intermediate step between S60 and the new Symbian. That's certainly true of the UI, but grossly understates the importance of the core OS updates. Just because they cannot be seen, it does not mean they are not important. Of particular mote are the new graphics and communication engines. Symbian^3 also maintains and enhances the platform's previous characteristics, such as resource and power efficiency. As a result, the core OS of Symbian is comfortably the most sophisticated and technically capable of any of the major mobile platforms, primarily due to its maturity, experience in use and a heavy level of investment over the years.
Symbian^4 called for a renewal of the UI. This would be achieved by introducing a new Qt-based widget engine (UI toolkit) called UIEMO (originally referred to as Orbit), which together with Qt would replace the existing AVKON application framework. A whole scale replacement of the widget engine would break the binary compatibility of the platform, meaning that AVKON-based applications, including all the standard and third party ones, would not run on the new UIEMO based platform, and would need to be rewritten.
Symbian^4 UI concept screenshot (UIEMO-based, now defunct)
UI Extensions for MObile (UIEMO), as its name suggest, is an extension for Qt, but is not part of Qt framework. Qt extensions are used to extend the Qt framework when the necessary capabilities do not exist in the framework itself. In itself this should not be a major problem (but see MeeGo connection below). However UIEMO itself was not as architecturally elegant or resource efficient as a pure Qt approach. Incidentally this meant that Symbian^4 was likely incapable of running on Symbian^3 hardware (at an acceptable rate).
When UIEMO was first conceived, Qt did not have an obvious mobile widget engine capability. However, at approximately the same time, the Qt team was laying the foundations for QML, which arguably did have the potential to do the same job as UIEMO. This kind of dualism is not unusual in Nokia, or indeed, any large company. Moreover the Trolltech acquisition was relatively fresh and internal communication lines had not been established. By the time they had, the commitment to UIEMO had already been made and development was well underway.
UIEMO and Symbian^4 were all set to deliver a much needed new UI to the Symbian platform, but the questions was, at what cost?
New Future (Symbian)
So what happens now? We've confirmed with a senior Nokia source that UIEMO has been cancelled. This does not mean that there will not be a new UI for Symbian, but it does mean that it will not be delivered via Symbian^4 and UIEMO. This is how Nokia are getting around the previously announced compatibility break.
Instead, a 'pure' Qt approach will be taken, with Qt Quick being used as the widget engine (UI toolkit). An important element of this will be Qt Quick components, which will (likely) be a set of standard components/widgets (e.g. buttons, titlebars, list items, and so on). This will allow for a level of consistency between applications and will mean developers have a standard set of widgets from which to build their applications. Developers will also be free to build their own UI elements, either using Qt Quick or using QGraphicsView, to create unique user experiences.
Early example of Qt Quick components implementation
Qt Quick, as part of Qt 4.7, is available in a developer version. However, it is not yet available in a consumer/release version (Symbian^3 phones are running Q4 4.6.3). The Qt Quick component building blocks are also not yet available. Currently, developers using Qt on Symbian need to create many of these elements themselves. This has been one of the reasons that the adoption of Qt of the Symbian platform, despite its many advantages, has not been faster. It will be important for Nokia to both bring Qt 4.7 out and create the necessary Qt Quick components as quickly as possible so as to encourage developers to start using them.
Also important will be the provision of the Qt Mobility APIs. These provide a set of functionality, not found in the core Qt framework, which are usually associated with functionality associated with mobile devices (e.g. access to Contacts and Calendar data stores, sending text messages). Version 1.02 of the Qt Mobility APIs have been released, as part of the move to Qt, but they are still under active development and it will be important for Nokia to make these available to developers in a timely manner.
AVKON is still being deprecated, especially in future devices, but it is unlikely to disappear as quickly as previously envisioned. However, it will not be officially supported as a way for third party developers to create applications. As such, developers of new applications should focus their efforts on Qt. There will, inevitably, be a transition stage (in effect Symbian^3), but there is no guarantee it will be present in future devices. While Nokia are doing away with Symbian version numbers, there will of course continue to be underlying changes, with AVKON's disappearance, from sight at least - a question of when, not if.
Nokia has not disclosed any precise details on how or when a new UI will be delivered, or what it will look like. Some of the UI design work for Symbian^4 could be reused. Indeed, rewriting UIEMO applications using Qt Quick may be the fastest way forward. After all, much of the Qt code could be reused, with only those portions calling UI widgets needing a complete rewrite. On the other hand, one of the key benefits of Qt Quick is that it allows closer co-operation between UI designers and coders, enabling a faster and more iterative design process. This might allow for faster UI refinement and easier testing than would have previously been the case.
Nokia has said it will move Symbian to a model of continuous improvement, which may mean there is more of a gradual change than the previous single step approach. In one sense, this has already started happening. Consider Ovi Maps and Ovi Store, which both have a notably different look and mode of operation when compared to the standard applications. Another good example is the homescreen; it is a specialised application and it is entirely possible to deliver an update just to this, which could add additional functionality (e.g. double height or free form widgets). It will be important for Nokia to retain as much consistency as possible (e.g. standard UI elements/chrome), but it is achievable.
The fact that Nokia says that it will deliver many of the improvements scheduled for Symbian^4 to Symbian^3 devices is also interesting. Not only does it express Nokia's confidence in its Qt implementation on Symbian^3 (and its ability to upgrade it), it also suggests that the new UI improvements will be less 'heavy' (resource intensive) than Symbian^4. It's good news for consumers, as devices will be perceived as having a longer shelf life and will receive real extra value through software updates. It should also help Nokia address the perception, which is generally over-played, that it does not deliver significant software updates to existing devices and does not care about existing customers.
Symbian^3 devices, like the C7, are in line to receive more software updates than previously expected.
While Symbian^4 was almost entirely focused around the UIEMO story, there were some updates to the core OS. Most notable was the initial support for SMP (symmetric multi processing) in the kernel. This and other core OS development will continue as before. Looking further ahead, more general SMP support and the results of the SHAI initiative are particularly important to the future of the platform. One of the earliest new features to make an appearance will be support for NFC (Near Field Communication), thanks to the inclusion of a NFC chip in the Nokia C7.
The MeeGo connection
Related to the Symbian^4 UI story, is the story around the Maemo/MeeGo UI. With the switch from Maemo to MeeGo, Nokia announced that the primary development platform and UI would be based on Qt. This made sense as it would share a common application framework, Qt, with Symbian. Consequently developers would be able to target both platforms from a single development environment.
As with Symbian^4, it was felt that a widget engine was need for MeeGo. This led to the development of MeeGo Touch, which is one of Nokia's major contributions to the MeeGo project. However, MeeGo Touch and UIEMO are not compatible with each other, despite both being extensions to Qt and aimed at creating mobile widget engines. This duplication seems unnecessary, although the UI of each platform was envisioned to be sufficiently different so as to provide some explanation. However the bad news for developers was that this would have somewhat spoiled the cross compatibility promise between MeeGo and Symbian. Porting between the two platforms would still be easy (much more so than porting to another platform), but it was a wasted opportunity.
Initial MeeGo Handset UX
However the plans have now changed for MeeGo too. MeeGo Touch will remain a part of MeeGo, but, at least for Nokia, will be deemphasised in favour of a pure Qt approach. MeeGo Touch will definitely be in Harmattan (code name for the platform to be used in Nokia's first MeeGo device, which uses the MeeGo UX, but Maemo core), but it will not be the recommended toolkit. In the future, a QML and Qt Components approach will be favoured (for example, note the meenotes demo release in the Qt Components project).
This will mean that it will be easier for developers to write applications that run on both Symbian and MeeGo, which clearly has benefits for both platforms. MeeGo, as it becomes established, is likely to benefit significantly from developers who are already targeting the numerically superior Symbian market, deciding to port their applications to MeeGo as an additional market point. It is also good news for Symbian as it makes it easier for developers to justify investing in a project, because two platforms offer the potential for greater financial rewards.
Future of the Symbian Foundation
In recent days, the speculation around the future of the Symbian Foundation has continued unabated. It now looks very likely that Symbian Foundation will be wound down or re-organised, but, at the time of writing, there has been no official announcement. There are plenty of unanswered questions around how this will work, and what will be the situation going forward. We'll look in more detail at the problems around the Symbian Foundation in a future article and cover any news as the story develops.
However, the future of the Symbian Foundation should not be directly linked to the future of the Symbian platform. Indeed, at this point, with Nokia the only user of the complete stack (the Japanese manufacturers currently use just the core OS), it is, arguably, more of a hindrance, than a help, to future development. The potential closure of the Symbian Foundation has far bigger implications for current or future potential non-Nokia users of the Symbian platform, than it does for Nokia itself.
People may also question Nokia's commitment to the Symbian platform, but if anything, these announcements underline Nokia's commitment to it. Looking further forward, Nokia is moving towards a more OS-agnostic approach, with Qt as the unifying, cross platform layer. However, Symbian has a lot of life left in it and for the foreseeable future will remain Nokia's primary smartphone platform. We'll address this further in a future feature article. Put briefly: together with MeeGo, Symbian will continue to make Nokia a force to be reckoned with across the full breadth of the smartphone landscape.
Conclusion
The death of UIEMO does mean that a lot of effort that has gone into Symbian^4 platform development has been wasted. However, the price for Symbian^4 was too high. The hardware resources required to run UIEMO and the compatibility break itself would have led to a major fragmentation point, something Symbian could not really afford in the context of the current competitive environment. Perhaps more importantly, it was technically inelegant.
The use of Qt and Qt Quick (QML) should allow for both greater flexibility and a faster rate of development in user experience innovation. The Symbian UI still needs to be refreshed, but with last week's announcements, both Nokia and third party developers should have a better set of tools to do this with. There may be some short term delays (or perhaps not, Symbian^4 was already running late) as Nokia get the necessary technical components (Q4 4.7, Qt Quick Components and related tools) in place and UI evolution is likely to be more gradual than sudden.
The extent of the UI split between MeeGo and Symbian, despite both being based on Qt, puzzled many observers and was most definetely storing up trouble for the future. The new plans rectify this and provide a much better cross platform integration story for Nokia to tell developers. How well this works out remains to be seen, but in general it must be seen as a positive move.
Future Symbian devices will still be delivered with a UI that will look different from what we have today, but the route to get there has changed for the better. In addition, Symbian^3 devices, such as the N8 and C7, will greatly benefit from a greater than expected pipeline of software updates.
Related reading
Qt Quick components project page
Qt Labs blog on Introducing Qt Quick components
Symbian is dead. Long live Symbian - analysis from visionmobile
The End of Orbit and MeeGo Touch Nokia UIs - Simon Judge's thoughts
My boss asked me to use Orbit UI and I said No - linked from Simon's blog above
Building Orange Wednesdays in Qt (Symbian Blog) - good example of current Qt situation