The UIQ Evangelist

In which we look at everything that can and did go wrong, while making sure to end on a cautiously optimistic note.

Part III: “Complications”

All right - so modular programming is superior. And Symbian with UIQ has a huge potential. In fact, few things truly seem out of reach when considering the architecture and the current technology. So what went wrong? Why do we still not see every single phone- company embracing these devices as the holy grail of mobiles, and cry tears of joy at the very thought of another UIQ phone release? Why do we lack integrated flash? Why is OpenGL ES not an integral part of the user interface? How come there are so few applications? Why, oh why, do we not have animated backgrounds on the home- screen?

The truth is that while the technology used in the current pocket- PCs and smartphones is relatively old - the smartphone line of devices is not, and cover a small market segment (at least so far). It is also complicated compared to the general mobile market, both in terms of development as well as sales - it introduces a series of challenges (and opportunities) that are not existent on feature mobile sets. And because of the increased development time, and often lack of interoperability between the devices, the market for mobiles are being fragmented further. Add rapidly changing standards to that, with difficult problems when it comes to backwards- compatibility in between versions, and even between phones with the same architecture and chipset type - as well as licensing issues preventing some standards from ever being deployed - and the disaster is complete.

Example: when the first UIQ3 devices launched, and UIQ2 was effectively abandoned due to changes both in Symbian versions and new functions and conventions in UIQ3, what really happened? In practice, any code written for UIQ2 with UIQ2 conventions became obsolete. Either of the two systems could still run on the same physical architecture with some work - but the higher- level implementations from Symbian OS and upwards turned onto two separate tracks, one of which stopped completely.

From a developer’s point of view, the programs you had developed suddenly had no possibility of expanding to more users, and some pretty serious adjustment would’ve had to be made to transfer the efforts to the next platform. Whether that may have been a good thing, is possible to argue for, but the inconvenience was real. So it would stall the development of new programs for the previous platform, so neither developers or UIQ2 users would have much reason to celebrate the new version right away. And the momentum, if any, was lost.

So - was /all/ of that really necessary? Looking at the not entirely inaccurate diagram in part I, we can point out that what we’re dealing with here is not a platform- breaking change from the hardware- point of view - or when looking at the OS level implementations. Meaning that while the platform versions would be incompatible with each other, and would require changes in the programs, it would not be impossible to fit the new symbian versions onto the old devices. Something which would expand the user- base for the new platform, as well as encourage developer participation early on.

But this was never done. And that is the result of old- fashioned thinking that still prevails in Symbian smartphone development now. And causes solutions that are more dependent on specific separate underlying development, and therefore becomes more fragmented than necessary. Because at some point in the development process it will turn out that a necessary change in the underlying architecture breaks the implementation further up. And if that renders the current phone and the current standards obsolete, then the problem is not whether those solutions were needed or not - instead it’s the lack of good abstraction from the beginning of the process.

The UIQ/s60 split is another good example, where common elements and UI elements are completely different, but where there’s no real reason they should be, as they do the exact same functions. Once again, history and ingrated conventions win.

But this type of solution is chosen because the idea never was to create a factory- pattern style development for the smart- phones - where each part of the process could be refined independently from the others. And where improvements in the OS could then be implemented - on the device, in practice - without that breaking the code for the programs running on it.

Instead, the idea was to fit every part of the solution to the other, with little thought of expansion later on. And if expansion was thought possible, it would have to be dependent on specific implementations with the next project, and limited to that single device in the future. (Perfectly analoguous to the Roman GPS system in part I.)

Because of this, not only is not Symbian and now UIQ used to it’s full potential, but the underlying architecture becomes, as demonstrated, more fragmented almost automatically. Which causes complications in the development process that could’ve been avoided. And valuable time would be spent on unnecessary digressions.

Thankfully, with UIQ3 and Symbian 9, it appears things are at least moving ahead according to plan.

Part IV: “Application”.

Categories: Comments
Tags: