The Symbian OS (779886), страница 87
Текст из файла (страница 87)
It wasa very interesting period. At the same time, the UI team itself was breakingEikon down into Uikon, so they were refactoring and separating things out,moving things around, and we were trying to understand the customization414ONE SIZE DOES NOT FIT ALL: THE RADICAL USER INTERFACE SOLUTIONrules. Otherwise, at that point we were trying to stick within modifying C++files in Eikstd and not touching Uikon at all. So we didn’t do something newfor notes, we didn’t do something new for queries; they were still pop-ups. Wewere using the FEP architecture. We were very much trying to be a DFRD.The DFRD approach required the separation of core GUI base classesthat were free of a look-and-feel policy; the separation, in other words,of those classes that had no intrinsic look and feel and were therefore common to all DFRDs from the policy-laden, look-and-feel-bearingderived widget classes (which implemented the look and feel of a givenGUI).
The core classes would be part of the framework; each DFRD GUIimplementation would create its own concrete derived classes.The UI team in the software engineering organization therefore createda design proposal for a refactored Eikon to be called Uikon and the workwas planned into Symbian OS v6.0, the first release which would supportthe DFRD model.As David Wood sees it, this was very much a natural continuationof the evolution of Eikon, just as the earlier factoring out of the CONEcontrol classes had been.David Wood:Just as we split out the control hierarchy and refactored Eikon, so later onpeople have sought to take other common elements into Uikon.The original idea was really quite simple, based on a simple implementation strategy.Murray Read:The original plan was that everybody would just customize Uikon throughwhat was called UikLaf – Uikon Look-and-feel.
This was the DFRD strategy.Uikon provided the core UI, and Eikstd and any bespoke UI libraries were thecustomizable bits that you could modify. UikLaf provided an interface whichyou would use to modify the look and feel of Uikon itself, and it was a simple,flat, monolithic interface which would allow you to tweak various parametersinside Uikon.But in practice, it just wasn’t rich enough to give you the customizationyou needed to implement a UI like S60, for example.Martin Budden is one of those who still feel that the Uikon architectureand the design choices that were made to support UI separation andcustomization were not always the best choices.THE DEVICE FAMILY STRATEGY415Martin Budden:Uikon was an attempt to resolve the conflict between Eikon, which wasthe Psion Series 5 UI, and the UI developed for the Nokia Communicator.Essentially the idea was to add a further layer of abstraction that would allowboth of those to sit on top of the same underlying UI.
In effect, we ended updropping Eikon, so that was how the conflict was resolved. Then Quartz usedUikon, but the so-called look-and-feel layers were just reimplementations; sothe fact that they were in a separate layer didn’t make any savings and youmight as well have just reimplemented elsewhere.What we could have done was standardize the APIs, rather than trying tomake a split; standardize the topside and bottomside APIs of the UI frameworkso that you could replace it and still be compatible.
That way you canrun any application on any UI. You could slot in a different UI framework,instead of having a customizable UI framework and trying to separate out thecustomizable bits, which is problematic because there are no clear separationsas to what is customizable and what is not. If you instead standardize the APIs,then you could just write a new framework to those APIs and things wouldjust run.Budden’s views are based on his experiences during the Quartz project,for which he became the first technical lead, commuting between Londonand Ronneby.Martin Budden:The experience of doing Quartz highlighted that there was a lot of code thatwas not easily separable. For example, the messaging code had UIs in theengine layer, which meant that to change the UI we had to redo a lot of theengine code as well.
There were lots of considerations that made it difficultto separate out the different bits. We rewrote a lot of the code, but withoutnecessarily preserving the APIs.The root of the problem was the UI fragmentation which dated back tothe early days of the Nokia Communicator and Ericsson R380 projects.The lesson, Budden thinks, is a simple one.Martin Budden:In retrospect, we didn’t do enough to support all those various UIs to ensurethat they were following the same rules and were compatible.Some degree of fragmentation was probably inevitable. Certainly, therisks of fragmentation were well understood on all sides and attempts416ONE SIZE DOES NOT FIT ALL: THE RADICAL USER INTERFACE SOLUTIONto avoid the worst consequences have been significant drivers of theUI evolution strategy.
For example, the history of the Nokia–SymbianUI split shows a repeated pattern of branching and reconciliation ofNokia and Symbian UI APIs; S60 1.0 branched Symbian OS v6.0 significantly, leading eventually to the ‘unbranching’ Symbian OS v7.0srelease, which restored API compatibility across the UI variants. Similarly, Symbian OS v9 has involved the unbranching of some UIQAPIs and will probably continue to include unbranching for both UIQand S60.Arguably, however, success is justification enough for the strategythat eventually evolved.
With hindsight, different design choices couldhave been made; but getting devices to market is ultimately the test ofsuccess.Murray Read:My strategy for UI development has always been to make it work. I knowpeople have this romantic idea that you can take one UI and turn it intoanother with a few tweaks here and there, but in practice to do that you’ve gotto design that into the core UI in the first place. And that’s not where Symbianstarted from. So my strategy has always been to just make it work anyway,write the new controls that you’ve got to write, adapt the existing code, branchthings if you have to. And it’s worked, I think S60 is the proof of that; we havea working UI in S60.
And if we’d stuck to the strategy and followed the rules,I don’t think S60 would ever have happened.16.5QuartzThe Quartz UI was developed at Symbian’s Ronneby site in Sweden,which originally had been Ericsson’s Mobile Applications Lab, a development lab working with Microsoft’s Windows CE operating system. IanHutton moved to Ronneby to replace Martin Budden as technical leadon Quartz.Ian Hutton:Certainly with Quartz, I think the biggest challenge wasn’t so much makingthat UI from the basis of EPOC Release 5, it was the question of working outwhat you want to do and then going out and finding something in Eikon todo it. The bigger challenge was really looking at the wider possibilities of thedesign, which was very challenging.
A lot of that was focused around usability,what are people going to do with this UI. A lot of work went into that andworking out what our underlying design needed to be to inform the UI design.PEARL417The view architecture inherited from the Ericsson R380 project, whichhad been migrated back into the Uikon framework, became a centralfeature of the Quartz application model, elaborated in the UI layer into amechanism named direct navigational link (DNL).Ian Hutton:That whole view architecture, which is now in Uikon, was very different fromwhat was being done by Nokia and it’s very clever. The design of the viewsand using DNL was completely new – there’s a whole new area of architecturethere – and this behavior had to be defined and designed. That was one of thebigger challenges with Quartz.Ian Hutton describes the DNL idea this way:In the phone application, you’ve got your recent calls, you’ve got the callers’names, now you want to see the details of this person, so when you tapyou switch to the contacts view, and now you can see that person’s details,their phone numbers, email address, and so on.
In the contacts view, whenyou tap on the phone number you switch to the phone application and itdials. So you’ve got some basic UI items and you want to make use of thatin another application, and the underlying mechanism which switches youbetween those views is DNL which is quite a powerful part of the UIQ userexperience.In contrast, to do the same thing in the original Eikon GUI would requirethe sequence: go to Contacts; copy phone number; task away; find thePhone Application; paste phone number into the Phone Application; tapDial.16.6 PearlThe Pearl team, meanwhile, was working flat out to meet Nokia’stimescales.Bob Dewolf:The plan was to get the project up and running, and then, about six monthslater, not exactly freeze the APIs but exert more control over them.
Thenwe would change the layout code so that it was resizable and more genericand customizable, putting in customization layers, and that would becomethe Nokia product. The DFRD would continue with that codebase and thoseAPIs. But the focus at that point was definitely getting rapid development oftheir concept. However, there was increased pressure to change Uikon, and418ONE SIZE DOES NOT FIT ALL: THE RADICAL USER INTERFACE SOLUTIONI remember certain changes that were made at that point, we had meetingswith the UI team and they said ‘We can’t do that.
We’ve got no requirementto do that’. I guess there was skepticism about how we could customize thisthing after it was created, and there was also I think a little pressure from theInteraction Design team, they weren’t so keen on the Pearl UI.The Symbian Interaction Design team was led by Scott Jenson who,before coming to Symbian, had been part of the original Newton teamat Apple. Interaction Design had been closely involved in the designof Quartz.
Pearl (or at any rate its concrete implementation) was athoroughly Nokia-flavored UI, its design driven by Christian Lindholmand the team in Tampere (Lindholm recounts some of the history in[Lindholm et al. 2003]).Bob Dewolf:I remember Scott Jenson coming up with some criticisms of the UI.
But youknow, finding user problems with a UI is like shooting fish in a barrel, as theysay, but Scott didn’t like two soft keys, he thought it was too complicated.And then, out of the blue, there was a meeting and it was decided that thereshould be no UI in Pearl itself, Pearl would be UI-less. At that point everythingchanged. There was to be no UI deliverable from Pearl, and we becameovernight the Nokia 7650 UI development team.In a new shift of direction, Pearl was redefined to be a DFRD withouta user interface, or what came to be called a ‘headless’ DFRD.
In effect itwas the first step towards the post-DFRD strategy of a headless operatingsystem. The Nokia 7650 (arguably the first true phone based on SymbianOS) launched what was branded at the time as the Nokia Series 60 UI.Pearl thus became Series 60.
Dewolf sums up the situation.Bob Dewolf:Crystal was a product which was elevated to a DFRD. We had a DFRD whichwas deflated to a product.16.7NightingaleSeries 60 (now rebranded as S60) was announced at Comdex, Las Vegas,in November 2001. The Nokia 7650 itself (rumors of its launch had beencirculating for several months8 ) caused quite a ripple of interest when it8For example see online articles in the Register around November 2001.NIGHTINGALE419was shown a few days later at Nokia’s Multimedia Developer Conferencein Barcelona, before its launch in February at 3GSM 2002 in Cannes.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
