The Symbian OS (779886), страница 85
Текст из файла (страница 85)
Eikon was re-engineered around this separation and thechanges were then integrated back into a new version of Eikon.David Wood:‘Nokie’ is Eikon backwards. It’s just the kind of black humor of developmentteams.404ONE SIZE DOES NOT FIT ALL: THE RADICAL USER INTERFACE SOLUTIONEikon, in its time, was a complete concrete implementation of thePsion Series 5 GUI. Architecturally, it fitted into a complete UI frameworkcomprising:• Eikon: widget classes with look-and-feel policy and custom behavior• CONE: generic control classes with no look-and-feel policy andgeneric behavior• Application Architecture: the application model, broadly MVCbased,6 although the detail of the implementation depends on thelicensee GUI (UIQ3, for example, delegates most command handlingto views).This is a classically good object-oriented design, with two independentclass hierarchies (Eikon and CONE) and an underlying framework exposing some generic behavior (common to all GUIs) directly to applications,with GUI-specific behavior brokered through Eikon.16.3Eikon Design PointWindows, then as now, was the dominant consumer-oriented GUI whenEikon was first being designed, although both Macintosh and evenAmigaOS (the Commodore Amiga operating system which includedthe Workbench GUI) had strong followings.
(The line from Microsoftwas then and still is ‘Windows Everywhere!’, from handhelds to datacenter servers.7 ) In the small device space, although Windows CE ran onsome HP handhelds, there were other potential UI models too: Newton,for example, which was a strong influence later on the Palm UIs andPenPoint from GO! Corporation was an innovative and interesting, butcommercially unsuccessful, UI.
But as the adoption of MVC suggests,there were also other explicitly object-oriented influences.David Wood:Windows was one of our reference points, but we were aware of otheruser interfaces too. We saw what people were trying to do with Taligent forexample, which was a combined effort between IBM and Apple that failed inthe end but, like many failures, there were lessons to be learned from it. So weread avidly the books produced by people working on Taligent and we lookedat that as a reference.
Charles Davies was familiar with X-Windows, the Unixwindowing system and that influenced us a bit also, though to be fair it moreinfluenced the design of the window server than the UI.67The model–view–controller pattern and framework is discussed in Chapter 14.See the comments in [Petzold 1992, p. 4], for example.EIKON DESIGN POINT405One critical design point for Eikon was usability – simplicity, naturalness and fitness for form factor of the GUI and the applications whichshipped with it. Robustness and an intuitive user experience were the keyprinciples.Geert Bollen:There was a logic which dictated that ultimately it is end-user benefit thatis important, and therefore any abstraction at all can be broken for the sakeof delivering something which delights the end user.
And there was anotherimportant value, almost a law, ‘Thou shalt not lose the user’s data’.Although Psion always practiced a strongly decentralized designregime with almost complete autonomy for the separate teams (sometimesto a fault), a lot of care went into ensuring that the shipped applicationswere consistent and well-designed from a user perspective. There was aUI Board, for example, which vetted the designs for all the application UIs.Howard Price:Bill Batchelor and Nick Healey would run the UI board and you’d go in andshow them your design. There was a lot of attention to detail and pretty quicklythey would be counting key presses, going down into the details of the lookand feel.
There was a lot of counting of key presses!Another critical design driver was ease of application development.David Wood:One common principle behind the creation of Eikon was to make the jobof writing applications easier and require less code, so that the applicationswould get more things for free provided they conformed to the framework.So that was a common theme: put the complexity in the system code andallow the applications to get the rich UI without having to do lots of detailedprogramming of that themselves.The point perhaps needs some elaboration, because Symbian OS issometimes perceived as being hard to write applications for. As discussedin Chapter 14, frameworks are a powerful object-oriented concept andthe Eikon framework approach did indeed deliver a lot of power toapplications.
However, the Eikon programming model is considerablymore sophisticated than a simple procedural one. Application developershave also recoiled from the complexities of the embedded systems-like406ONE SIZE DOES NOT FIT ALL: THE RADICAL USER INTERFACE SOLUTIONtoolchain (develop under emulation, then cross-compile for what is, ineffect, an embedded hardware target), as well as from the disciplinerequired to develop robust software for devices on which a software errorin an application freezing or crashing the system is simply unthinkable.For some, the development experience is a little too far from the desktopexperience to be comfortable at first.At the time, though, the big issue seemed somewhat different.
Eikonwas evolved together with the system software beneath it and the application suite above it. This approach continued the Psion tradition.David Wood:Eikon was created in an incremental process. As more applications werewritten I looked to see what the problems were that the applications hadto solve so when people created a toolbar, for example, then we thought,‘Well, actually toolbars should be in the Eikon framework’, and then people did more complex things with toolbars and we thought, ‘Well, actuallyother applications would like to take advantage of this as well’.
So systematically things that started their lives in applications moved into Eikon. Andthat made things a bit tough for the application developers because theyhad to rewrite things as we went along, but it did mean that with only asmall amount of code in the applications, very rich user interfaces could beachieved.The goal was to maximize the power of the framework to enablegraphical applications to be developed with minimal new code andtherefore to get the most from the small hardware footprint.Of course, this didn’t make things easy for the application teamsworking on the built-in applications. Peter Jackson recalls the frustrationfrom the other side, compounded by the time-to-market pressures fromthe project.Peter Jackson:It was changing under your feet the whole time, and you knew that if you puteffort into working on something that was based on that framework you weregoing to have to change it again.Iteration was the natural model in the company at the time, and therewas a long history of evolving from one product to the next.
Evolving theEikon GUI for the phone projects which were starting up in the wake ofthe Series 5 launch was in some ways just more of the same. Adaptingthe Eikon GUI to the very different form factor of each different phonewas clearly a critical task and Eikon had been designed with adaptationin mind.EIKON DESIGN POINT407The reality, however, was that there was no clear understanding ofhow that should be done. Martin Budden moved from the applicationteam to become technical lead on one of the very first phone projects,the Philips phone ‘companion’ (see Chapter 2).Martin Budden:We were still a way from forming a portability strategy for how we woulddevelop and deliver the operating system for all these different manufacturers,so we were learning as we went along.The Philips phone was the first adaptation of the Eikon GUI.
Theapproach was straightforward and pragmatic, a straightforward branchingof the components that needed to change. The Philips project developeda bespoke UI and a dedicated application suite with a small team, in notmuch time.Martin Budden:We did the UI but we also did the applications in there: we did the messaging,the contacts, and all those kind of things. To customize Eikon, we essentiallyrewrote the drawing code and the code for things that we needed to drawdifferently and we wrote new UIs for the new applications as well, using theunderlying engines without change.Murray Read joined the project in its early days, initially working forOrigin, a software consultancy part-owned by Philips and later acquiredby Symbian, but at that time supplying specialist software engineers toPsion.Murray Read:The UI design Philips wanted was quite different from the Series 5 design.
Itshared some similarities. I think we had a task list and the major parts of the UIwere still there; there was a menu application; there was Window Server andCONE; and they were all there doing the same basic things. But when it cameto the UI library itself, we had a much simpler set of controls to work with;one type of button, no keyboard, so we had to make the system work with theon-screen keyboard only, although it had handwriting recognition as well.When the Philips project ended (disappointingly, without a productcoming to market) most of the team moved on to start up the project forthe Ericsson R380 and applied the same approach. Meanwhile the first408ONE SIZE DOES NOT FIT ALL: THE RADICAL USER INTERFACE SOLUTIONproject with Nokia, for the new Nokia Communicator was in full swing(see Chapter 2).Martin Budden:The model of doing a bespoke UI was there, and then we did another bespokeUI for the Ericsson R380.
The other big project at that time, going on in parallel,was the Nokia Communicator, and again, that involved doing a new UI toNokia’s specification. We swiftly recognized that there was a fundamentalconflict between these UIs and it became clear that if we did a UI for everysingle phone that wasn’t going to be sustainable.The basic problem was clear enough.Martin Budden:We weren’t thinking about generic problems. We were dealing with specificproblems for specific projects that came up.Each project was in effect a customization project, which created acomplete, custom variant of the operating system as required for eachdevice, from the base port to the operating-system services to the bespokeapplication suite to the UI, including modifications (at whatever levelof the system) needed to support bespoke hardware such as dedicatedphone keys or the R380 phone flip.For all these challenges, the first phone projects were genuinelytransformational for the company.Ian Hutton:The early projects were in fact extremely visionary, not just the Nokia Communicator, but also the Ericsson R380.
The Ericsson R380 was a really advancedphone. The fact that it didn’t sell in huge numbers, nor the Communicators forthat matter, is largely irrelevant. There were really huge advances in design,both in what a phone should do, and how you could do those things ona phone.Key features of the Ericsson R380 – the flip, for example, and its interaction with the screen modes, flip-closed and flip-open landscape – weregood enough to be picked up by the next generations of phones and arestill central to the design of phones such as the Sony Ericsson P900 series.EIKON DESIGN POINT409Ian Hutton:The Ericsson R380 was very much an innovative design.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
