..out of the dark

Usually, when a product fails to live up it's expectations, it's probably the case that your expectations simply were too high. On various gadgets, where it's difficult to really read out what it can do from it's specifications alone, this is typically more true than usual as well - whether it is because of manufactured hype, or just your own weakness for bluetooth watches, phones with nice lights, or electric pocket- horoscopes with nose- trimmer.

Of course - afterwards, people tend to want to justify their purchase, and not focus on the negative aspects, because the last thing people are going to say is "wow, I'm such an idiot, falling for the hype and buying this unit believing it was anything else than a glorified Donkey- Kong game console with more elaborate beeps and lights - what was I thinking". Or they simply are happy with the $500 donkey- kong game, and wear it proudly (flailing out in anger at anyone who dares to suggest it's a useless piece of crap that cannot, unhappily, cure tonsillitis and the water in your knee after all).

Nevertheless, some times the problem with high expectations is not the customers fault - but the manufacturer's underhanded re- drawing of their definitions. For example by defining "developer" into "non- royalty paying thief" and "customer" into "betatester". In this case, I am of course talking about SE's UIQ based phones, and SE's magnificent customer- relations strategy - which can be summarised in two words: Screw You.


But I'm getting ahead of myself, as usual. From the outset, it must be understood that UIQ is a symbian- based platform. Symbian is the OS with the various common hardware- layout interfaces needed to communicate with your average risc- processor, and the mainboards typically used on smaller handsets. This is naturally a two- way street: the phone- manufacturers build their units loosely to specification, so they are certain to allow an efficient use of the functions deemed necessary for driving the various functions on the phone - from display to processing and input.

The existence of that OS then allows platforms of various kinds to be built over it, such as S60 and UIQ, which provides more useable and general apis(application program interfaces), with various filesystem and OS- related functions included that are not necessarily basic or easy to maintain for your average programmer. In the same way that a class- collection in c++ would provide you with an abstraction of various low- level programming, and allow you to forget about specific memory handling on the program level. Something that of course is extremely useful, specially when many handsets do essentially the same operations as the next one.

Something like UIQ also allows for very efficient use of code, since it allows you to simply focus on layout and input- scheme on the phone, and forget about the inner working of the phone once past a certain minimum level of worry, once the hardware platform is chosen and made compatible with the low- level Operating System, in this case Symbian. Simply because it would be up to UIQ technologies to rewrite their core to conform with the new Symbian version, while your UIQ programs - using the UIQ apis - would most likely require little change to continue to run successfully. I.e., no need to reprogram your program's specific use of memory- blocks in order to make it run. And no redrawing of the way the lists are read, in order to conform the program with different hardware and OS functions.. (Although of course there are examples of that exact thing happening with well- known OSs such as Windows, but we don't talk about that.)

In other words - having this platform to develop on is a tremendous asset that in theory would help usher in a new era of useable handsets with nice tools and all sorts of things. In fact, unlike all other platforms, UIQ promises to be open for developers of all kinds, and not just the phone- manufacturers and the phone- companies - in the sense that if you program a program for UIQ, you would have apis for all kinds of things available to you, allowing you to write complex programs using the inbuilt risc- processor, the graphics, the input, etc., without worrying that your program would be second rate compared to the programs made by the phone- maker.

However - however. The case is that UIQ fails to deliver on the apis. They are largely undocumented - there's a serious lack of briefs and documentation on structure- related issues dealing with what apis to use in certain situations: it's in many ways very similar to working with an undeveloped java- library that you cannot circumvent by simply writing your own heap- class, or your own gui. You need to go through the motions - but you cannot really tell the exact behaviour of the program within those constraints. Can I, for example, program a gl- window to be displayed inside one of the UIQ views? If so, how? If not, why? What about drawing in the main view, and mixing gl- engine code with the existing view- port? What about a work- around and a transparent view- port? Would I be able to program this and detect the events on the underlying viewport, so I don't have to constantly update the background? What about the processor- activity? Are the libraries supported in that way? I don't know - I cannot tell before trying, and even then it's extremely difficult to truly detect the exact behaviour - simply because I did not write the Platform myself, and I do not know what the expected limitations of it is. None of which is helped by the fact that the gl- emulator doesn't actually work due to a licensing issue between PowerVr and Symbian.

Meaning that already it's starting to pay off being cautious about the ambition of your projects, and choosing to use recycled code from other platforms that disregard the integration with UIQ altogether - simply because of the uncertainty, if not excessive extra work it would mean to make use of it. Resulting in that instead of restructuring your code a little bit, you end up simply using a couple of standard views to display the program, essentially porting it to UIQ. And any optimisation and useful drawing options are limited to only the extremely dedicated UIQ gurus alone. And that treshold is difficult to get past, either if you're just a part- timer, or if you're working to sell your program to as many as possible.

So far we've been talking about the program- level functions. And then we come to the global functions on the platform. And it turns out that contrary to belief, claim and insistence from PR dudes, the global api functions are only available to the phone- manufacturer. Meaning that not only are their programs shielded from being extended or used by your average developer (which would be understandable, if not very nice), but also genuinely useful functions that affect all programs are locked to exclusive use by the phone- manufacturer alone. And it is the choice of UIQ, at the insistence of SE, that caused this.

As an example: I want a profile- application that reads two databases - one that I make up myself in the program, and the internal one with the calendar. When specific conditions occur - such as a meeting with a high priority, a class, or whatever - I want the phone to become silent. Also, I want a particular colour to be displayed on the status- bar, to indicate that the meeting is in progress, where I could for example hit a button to drop the setting back to normal. Etc.

At the moment, I am limited to mute sounds triggered from the program at specific moments in time, for example dependent on the calendar. But since the global api is either hidden or non- existent, I cannot program a real profile- application. So while I can draw all kinds of useful things to hover on the main view - I cannot actually access the global settings for muting sounds, changing volume, and so on.

And why? All kinds of other system- level apis are put in the telephone- manufacturer class only available to signed applications - so why this oversight? Noone knows. Repeated inquiries to SE yields no result, but is met with silence. No wish exists, it appears, to make the platform more accessible for developers - and by god, if noone else can make the program, then SE is certainly not going to listen to their customers and implement it themselves. No - let's just proudly proclaim that it's time to switch brand, platform and so on, for anyone who wants answers other than: "Screw You" from their manufacturer.

Because what is the real problem here? It is that SE treats their smartphone- platform as any other phone- platform. Expecting people to buy feature phones, and have no interest in any of the options available to that OS. I.e., they expect people to buy a smartphone just for the gimmick, and for the programs initially "given" to the users of the handset. When this is coupled with the less than well- made, or half- made solutions for programs, then you of course have a winner.

And anything that might compel SE to consider focusing on even the tinyiest fixes for their platform that falls into the category of "minimum support for any other platform, closed or open", is therefore out of the question.

Of course, what irks me more than anything else, is the way UIQ plays along with this.

A combined effort which naturally creates a self- fulfilling prophecy - smaller developers just don't want to try using the platform - and the solution for earning money is not to sell more handsets - oh, no - but to sell exclusive rights to phone- companies and phone- manufacturers in order to piss the actual customers off and keep the evolution of the handset in check as long as possible. Or more to the point - focus on the idiotic business- user segment of the market, who buys anything as long as it's expensive, regardless of functions.

Instead of - as was thought to be the idea behind UIQ - launching a useable platform that would create revenue based on the amount of handsets it would help sell - which would conform with the phone- maufacturer's interests. Which again would create a platform on which the phone- companies might also provide services, along with other developers of various kinds.

But oh, no. Let's instead force the customers to use our ad- driven bug- ware that ruins the battery life on the phone, while giving me aneurisms in the brain. If even any programs turn up at all, of course - in favour of simply NOTHING HAPPENING FOR YEARS, while the technology necessary on both hardware and software now enters it's ten year anniversary. Really, it's so fantastically done you could almost believe it was done on purpose to ensure that both SE and UIQ is punching themselves out of the smartphone- market.

And all that, while they are so infinitesimally close to being able to choose the complete opposite direction? It would after all be done by just responding to simple, easy, requests from an increasingly engaged user- community. Who will in fact abandon SE in the future because of these things - which again will cause less programs to be written for the platform - and again which will transform the phone into a glorified feature handset, both unecessarily expensive and resource- hungry, without any real return. Which again will cause, as it has before, the smartphone market to dry out, and once again become the niche it is today, where only the "useless business- user with too much money" segment will have any interest. And where of course every other platform in existence, including the donkey- kong game, is more interesting for all of the customers.

Really - SE and "innovation".. It's simply a fabulous example of how not to do business - for all times, in any circumstances. Truly astounding how it's even possible to accomplish such a thing.