The UIQ Evangelist

..In which I introduce myself (hi), and describe the critical stages of a development process. (And then remembers to thank Asri and ares for the invitation to write on the blog).

Some things may be more inevitable than others in life. But if you’re a programmer, you tend to hate software- users. “Why,” you think, “don’t they understand how brilliant that solution really is - you just have to press ctrl+shift and…”. Because whatever you do the users, it seems, want the programs to do impossible predictions, and type out their thoughts on the screen (properly formatted and spell- checked).

So what type of solution will the programmer end up with? Do you convince the user to agree with your procedure, because that’s the easiest solution for you? Or do you try to make your solution as flexible as possible, impressing on your customers the need for extra planning. And then deliberately creating a framework that can easily be expanded and changed, if that’s what is needed later?

A Really Very Very Small Bug

In reality, for all the possibilities object- oriented programming give us, it’s the first solution you tend to choose most often. Because the easiest choice is simply to represent a direct abstraction of the program logic visually, or choose an isolated but functional approach to the problem (*cough*.. like the inline css for the image- caption just there..), and then explain that this - this is the limit of the system, and nothing more can be done with it. Any extra functions or capabilities - oh, they have to be hard coded into the system, and meticulously and specifically fitted at every entry point (..or at least they do now), and that will be extremely difficult and expensive - if not impossible (or at least it will take numerous extra hours).

But it’s of course a lie. We say that because from our perspective, the program does exactly what it’s supposed to do, and therefore it’s complete. If it’s not, it’s because the deadlines were too strict, and this is all the customer can expect. And to add something new - or attempt to rethink the program logic - well, that’s obviously impossible (or at least very difficult). After all, the system is designed from a specific procedure of key- presses from the prototype example - so how else can it possibly be programmed, anyway?! Stupid users.

Even so.. - sometimes the user is right. The program (however perfectly and to specification it is written) may not actually do anything useful from the user’s point of view. Or, certain program behaviour just doesn’t make sense, when not seen from the viewpoint of the internal program logic (..or, perhaps, while looking at the original specification at the same time).

Which is why that ordinarily, any of these issues between user and developer would be solved once the program would be used for a while by the customers (or in the case of more humble developers - a smaller group of testers), as they generate some useful feedback for the developer- team (..which is when they change their minds completely compared to when sketching the prototype).

And that simply has to be expected, if you want both happy customers, and a good product.

——

While the UIQ phones are pretty stable, and generate random program faults rarely compared to other platforms on the market - it’s still the case that SE’s stab at the menu- system have comparatively minor, but nevertheless serious flaws. Flaws that not only irritate a few power- users for a short while, but flaws every user will notice sooner or later.

For example: A user boots up their phone for the first time. They download gprs- settings, and Google maps for java. That user then adds a Wifi- account. It’s added to the default connection group. And it will be used to download maps, and the internal browser works over the wlan. However, when the phone is out of range from the Wlan, suddenly Google maps won’t work.

At this point, one of three things might happen.
1. The user thinks it’s a problem with the settings, and will download another set. And/or deletes all Wifi- accounts, and then adds the same account again. Somehow it works again, until a new wlan is added to the list.
2. The user thinks the phone is broken, and sends it on repair - they reset and flash the firmware, and it works again for a while. When it doesn’t, the user simply turns to other programs that do work instead, or think the problem must be with the operator.
3. The user knows that it should work, and sees no reason why it shouldn’t - and figures out how to change the connections the java- applications will use manually.

Unfortunately, in neither case anyone is likely to generate any feedback to SE about the UI problem, and the way the priority list is broken when using a java- applications with the “system group” setting. Either the user finds a way to get around the problem, or they assume it’s just not possible and then give up (after making angry posts on esato, and tell everyone they know how much SE smartphones suck).

So - why do not issues like these get the attention a serious program bug would? Certainly SE’s focus on “improving the SE experience”, instead of just the UI experience, has something to do with it. The same goes for having no official bug- fix department, or a public forum, or official change- logs for the firmwares. Or in other words, because the development process does not actively include customer or beta tester feedback.

——

Obviously, when issues like these are ignored, it also lessens the appeal the phones have in the market. Since these problems - which consistently show up in the largely unchanged firmware on all of SE’s UIQv3.0 phones to date (and which by all accounts will turn up on the new g- series as well) - will tend to help position the devices for the.. even more discerning and particular customer than it was obviously meant for.

Of course - just as there are no bugs that can’t be debugged, no program will ever be free of bugs, or faults. And it is not really reasonable to expect no bugs or problems of any kind - for either user or developer. No matter how strict and limited specification you have in a system - the variables are simply too many for that.

But theories on philosophical perfection from a technological point of view would probably be pretty far from anyone’s mind when observing the state of the mobile phone industry at the moment. Because the bar is not set that high. In fact, the UIQ3 versions from SE might be one of the better examples out there when it comes to smartphones - at this point, at least - if we focus on stability and reliability first.

Still - is it really too much to demand that SE should not recycle known problems on their phones, from one UIQ3 model to the next? Or that they should address concerns in the developer- community when it comes to unavailable APIs that only SE can provide. Not in the least because it prevents certain programs from being made commercially on UIQ?

Between the lack of response to petitions from the user- community, as well as lack of official acknowledgement that anything at all might have to be improved on the UIQ3 phones - it appears so.

——–

(next: OS upgrades for UIQ phones - is it possible? What are the upsides and downsides? Does it make sense economically?)

Categories: Comments
Tags: bugs, UIQ 3.0