The Symbian OS (779886), страница 84
Текст из файла (страница 84)
2003, p. 15].INTRODUCTION399Naturally all players in the phone market are seeking competitiveadvantage, but there is something else at work: avoiding commoditization. For both operators and phone vendors, commoditization is anever-present threat and is one part of the complex dynamic which drivesthe exponential pace of technological advance and feature growth. ‘Commoditization’ means the cheap and ubiquitous reproduction of what wasonce expensive and unique. Commoditization reduces margins becauseit reduces competitive advantage to price competition.
Commoditizationnaturally centers on hard technologies and features – ‘do more, go faster’.Softer product qualities – ‘do better, be easier’ – are therefore criticalpoints of defense against commoditization.In the battle to maintain differentiation, the user interface has becomea key competitive element for phone vendors. Indeed for phone vendors,design philosophy and style (‘cool’ is an important selling point forphones) and properties such as usability have become almost as importantas features. Since these are all properties which touch or are touchedby the user interface, the phone UI has turned out to be a key businesscompetitive edge that drives market segmentation and, as a result, brandleadership.As Christian Lindholm, the creator of the original S60 user interfaceputs it, the UI ‘is one of the key elements in the fight for customers’,creating pull from both end-users and networks, an essential ‘competitiveasset in the race for market dominance.’4What’s in a User Interface?The user interface is where the phone software and the specific hardwarefeatures of a particular phone meet to enable the user to access thefeatures of the device.
In large part, ‘usability’ reduces to questions aboutthe user interface and the myriad decisions made by its designers andimplementers about such things as one-handed versus two-handed use,pen versus keyboard input, feature richness versus interface simplicity,file-centered versus task-oriented application design, and so on. At onelevel of detail down, these become decisions about such details as screencolor schemes and fonts, menu structure and sequencing, how hard andsoft keys interact with on-screen items, and so on.At first glance, user-interface style may seem to be a slender threadto hang market aspirations on and a tenuous driver for market share oreven dominance, but of course it is not the only driver.
But the criticalcontribution it makes has to some extent become a reality for all consumerproducts (think of the iPod without its click-wheel), and it has certainlybecome a reality for phones.4Kiljander and Jarnstrom [Lindholm et al. 2003, p. 15].400ONE SIZE DOES NOT FIT ALL: THE RADICAL USER INTERFACE SOLUTIONThe Multiple GUI Operating SystemTo succeed in this complex context, Symbian’s solution is to supportmultiple UIs and to engage with others to create those UIs.
Licenseeseither buy in the platform pre-integrated and tested from a Symbian OSUI vendor such as S60 or UIQ Technology or they buy in the operatingsystem ‘headless’ and develop their own GUI.In architecture terms (see Figure 16.1), the topmost layer has beenremoved from Symbian OS. The operating system does not provide theUI layer; instead it provides the infrastructure (frameworks and primitives) for UI creation.
Beneath the UI, the common frameworks and theunderlying services of the operating system itself ensure substantial platform compatibility at the application-engine (i.e. application-logic) level.Indeed applications can be targeted at the different available user interfaces by customizing the application UI without changing the applicationengine. A Symbian licensee either creates a bespoke user interface fromthe frameworks (although this is not a trivial engineering effort, it is theoption chosen by DoCoMo in Japan for its FOMA platform, for example)or buys in a UI from a specialist vendor (both UIQ Technology AB, whichwas spun out of Symbian as a separate company, and Nokia license UIsand supply a pre-integrated platform to phone vendors).Symbian OS on a Sony Ericsson phone or a Motorola phone withthe UIQ GUI – the P910 or P990, say, or the Motorola A1000 – looksand feels very different to Symbian OS on a Fujitsu or Mitsubishi FOMAphone or to Symbian OS on a Nokia, Samsung or LG phone with anS60 GUI.
And yet the underlying operating system is the same and thevery same applications can run on all of these different phones, sharingidentical source code at the application-logic and data-model levels.While Symbian OS is tightly integrated to the GUI which runs on topof it, by way of the UI and application frameworks, it is designed tobe GUI-neutral. For application developers and from the applicationVariant UIsUI LayerS60UIQMOAPUI FrameworkSymbianOSFigure 16.1Symbian OS user interface architectureTest UIINTRODUCTION401perspective, although Symbian OS applications are intrinsically GUI innature, applications are only loosely coupled to a particular GUI variant,since the application model and the application-event loop are enshrinedin the operating system itself and in the UI Framework support, and notin the variant user interface.Symbian’s solution contrasts with that of other operating systems targeting mobile phones.
Windows Mobile, a Windows CE derivative, isarchitecturally a monolithic UI, like its desktop parent. All phones that useit, from whichever phone vendor, share the common Windows interfaceand its Microsoft signature branding. Whatever the other opportunities forvendor differentiation, phone vendors supplying Windows Mobile phonesare, to all intents and purposes, Microsoft OEMs.
Windows Mobile is certainly a platform operating system, but what has so far made it unattractiveto many phone vendors is the fact that it is Microsoft’s platform.The situation with Linux is somewhat different. To date, the Linuxphones which have shipped (in large numbers in Japan and China)are not Linux platforms because they are not natively programmable.Instead, they are closed phones exposing only limited Java APIs. Furtherundermining the platform potential of Linux phones is the proprietarynature of the Linux distributions on which the phones are based, with thephone vendor typically directly owning the distribution.
To some extentnew ‘open’ user interface toolkits supplied by independent vendors forLinux-based phones (such as the Qtopia QT user interface toolkit fromTrolltech) may open platform potential to Linux phones if they becomewidely adopted. However, it is something of an irony that the questionof openness still remains a significant challenge for Linux on phones.Qualcomm’s Brew platform, which so far has been limited to CDMAmarkets but which is now migrating to GSM, offers device vendors achoice between creating their own bespoke UI, or adopting Qualcomm’scustomizable uiOne user interface.The early decision that Symbian made was that the phone marketwould reward UI diversity based on a common underlying platform.Thus far, certainly, the market has found Microsoft-style homogenizationresistible.5 Linux, fast emerging as possibly the strongest challenger toSymbian OS, has not yet solved the platform challenge.
So far SymbianOS remains the only operating system which is open to third-partydevelopers across multiple phone vendors, across multiple operators,and in all geographies and all markets (GSM, CDMA, 3G), while alsooffering vendors strong opportunities to differentiate.However, the market is still barely in its infancy. The currentlycompeting platforms – most visibly Symbian OS, Windows Mobile andLinux – have until recently been restricted to the high-end, less than 10%segment of the overall market. Symbian’s strategy – of ‘leaner, faster,5To the surprise of some.
But since homogenization in the phone context equalscommoditization, it is perhaps not so surprising.402ONE SIZE DOES NOT FIT ALL: THE RADICAL USER INTERFACE SOLUTIONfitter’ – is based on a drive towards the mid-range, boosted by naturalmomentum from increasing market acceptance plus a little help fromMoore’s law (which continues to drive hardware specifications up andBOM costs down, so narrowing the gap between the middle of the marketand the top). Meanwhile, the incumbent operating systems in the midrange are proprietary, for example Nokia’s NOS/Series 40 combination ofoperating-system and UI or the operating system which drives Sony Ericsson phones.
These can only be considered ‘platform’ operating systemsin the sense that they support third-party programming in Java. It is in themid-range that the next rounds of the battle for common operating-systemplatforms will probably be fought.Looking further ahead, there are also possible competitive threats inthe user interface area from alternative technologies which potentiallyoffer UI alternatives either to the existing incumbents or other embedded operating system alternatives. Examples include building embeddeddevice user interfaces directly in Macromedia Flash, more commonlyknown as a web-content display technology but proving itself as a UIsimulation tool and jumping the gap to become a potential user interfacetechnology. Similar disruptive approaches include possible ‘declarative’user interfaces based on XML-defined interface-description languages.
Itis not yet clear whether, or how, these technologies will eventually playin the market.16.2Background to the Eikon GUISymbian OS originates from the desire to create the perfect usableoperating system for small handheld devices.The original GUI – on the Psion Series 5 – was known as Eikon. Eikonitself, at least in the design sense, was an evolution of a previous generation of GUIs written for Psion’s earlier 8-bit and 16-bit machines, althoughin concrete terms it was all new work, a second – or third or fourth,depending on where you start counting – attempt at mastering the GUI.David Wood:There were several UIs for the 16-bit software. In a way, it prefigures what’shappened to the 32-bit software.
For the MC400 which was a full laptop-sizeddevice with a large screen, we designed what we called WIMP, standingfor Windows, Icons, Menus, Pointer. And then for the handheld version wecreated something called HWIM: ‘H’ for handheld; we took the ‘P’ out becausethere was no pointing device. And then we did a new version called XWIMwhen we increased the screen resolution and it was actually binary compatiblewith HWIM, which again prefigures something that’s happening nowadays,because the applications that ran on the original Series 3 also had to run onBACKGROUND TO THE EIKON GUI403later versions of the Series 3.
So they ran in a compatibility mode with eachpixel being doubled up.The basic ideas about how a UI should work on a pocket-sizedmachine had been well worked through before any code was written forthe Series 5. The iterative approach, however, was quite deeply a part ofthe Psion culture and scaled well to the size of the company at the time.David Wood:HCIL was the first version of the UI for the Series 5 and that was also quiteWIMP-ish. For example, you used to tab your way around dialogs. However,after a while we decided that was too complex for most handheld users, so weabandoned having two-dimensional dialogs, we had one-dimensional dialogswhich you navigated using the up and down keys.
And that change led tothe creation of Eikon, actually through two phases. After a while we decidedwe needed to refactor. After the first implementation we split it into two.We separated out the CONE control hierarchy as something that would becommon for all user interfaces on the handheld devices because we viewedEikon as just the particular interface for the Series 5. And CONE persists to thisday. No doubt, it has evolved quite a lot but essential features of CONE arethe same as in the 1996 version when CONE was first created.From the beginning, even though the project was very specificallytargeted at the Series 5, design decisions were taken with the laterplatformization of the operating system in mind, assuming a family ofpossibly different devices.David Wood:Splitting out CONE is a good example of the need to refactor. The need torefactor is an important principle that comes through architecting any largescale system.A so-called ‘Nokie’ variant was created and the CONE classes wereseparated out.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
