“Possibilities”
Where we take a theoretical stab at justifying OS upgrades on smartphones in general, and didn’t forget to announce Part II, of the series in many parts.
Part II: “Possibilities”
The first question when taking a look at OS upgrades in general could be about what sort of content or capabilities we’re really talking about. Would an upgrade be simply tweaks on the existing platform? New content used on the existing system? Would it be possible to enable new capabilities for the existing hardware? What about new functionality within the system?
But more often, the question tends to be if it’s doable to add anything at all. Something that, due to overuse of technical jargon (”flash enabled”.. what does that mean?), might be difficult to point out definitively. But, as we explored in part I, we can see what sort of capabilities might be added, and whether they are possible or not, depending on which part of the system is involved. And which parts require hardware changes, as well as which ones would break backwards- compatibility, or require new components.
In other words, the next (and most likely) question, has to do with what may or may not be effectively implemented in a cost/revenue scenario. Can it possibly be justified to develop a new set of apis for a device that is already on it’s way out, for example? Shouldn’t the newer devices take priority?
Obviously, looking at the development in this way makes it plain that upgrades in itself are not cost- efficient, because they are tailored to a specific phone- model and project. And there are other problems with the projects as well - is it reasonable to expect independently developed solutions to have any value in the long run? What sort of restrictions would need to be put on these practically, in order to achieve any results in the existing systems? When is it no longer portable? Would it really be worth the effort at all? Would it pay off to create a solution for only this small market- segment - one single phone out an already small general user- base?
All good questions at one time or another. But the thing is, that because there are so many different standards available (as well as fleeting requirements and interest from the suits with the low pockets), any engineering team will typically find a particular and portable programming language, or a typical model, themselves - and then require any new “suggestions” from higher up to be steered onto that framework. And this is inevitable at every level of the process. Because recycling the competence and the existing solutions is necessary.
The real question is simply what sort of breakage and fragmentation it’s efficient to end up with between the models and versions.
—
It is strange if the modularity of Symbian, and the obvious possibilities it brings with it, is not used to it’s full potential. After all - we’re talking about a possibility here to completely split development of UI- enhancements from tweaking and improving the OS- level implementations. And split the development of OS implementation from hardware- level capabilities. And in the end exploit this system, the flexibility and portability of it - in order to produce very good and wholesome solutions. While also minimising the costs of introducing new technology, while extending the usability of the programs written for it.
Since if we look at the economical argument - before even beginning to talk about branding and marketing presence, we can already establish that developing solutions in this framework will be beneficial. Because it will improve useful competence on the necessary levels over time - when the hardware changes radically, and the software evolves.
(next: part III, “Complications” )
Leave a Reply