In response to Lauren Sarno’s post on this blog, …what you really, really want, Nick Healey asked, Where does UX live in the Symbian Foundation organisation? My role at Symbian Foundation is “UI Technology Manager,” and I look after the user experience of developers and consumers, covering our web sites and the Symbian operating system. I also chair the UI Council (UIC).
The UIC, governed by the Council Charters, provides vision and votes on proposals for contributions that affect the UI. We also provide user interface guidelines, which will take the form of a pattern library—one of my action items from our most recent council meeting. Today, the UI Council is made up of representatives from Nokia, NTT DOCOMO, Sharp, and Sony Ericsson—with more to come. Board member companies are each entitled to a seat, with two additional seats to be nominated by the Symbian Foundation Board of Directors.
User Interface is considered one of the highest Symbian Foundation priorities, and the way I plan to do this is by increasing the differentiation opportunity in the UI rather than focusing on getting a single UI right. The reason for this strategy is that a single UI with critical input from so many sources is likely to be less innovative than a UI created by a small creative team. Today, creating a novel user interface for a Symbian handset requires not just graphic and user interface design, but extensive C++ coding. My vision is to reduce the barrier to UI creation down to XML, a standards-based mark-up language familiar to anyone who has created a web site. Such a UI strategy enables amazingly easy tools creation, such as a Mobile User Interface builder that could even run in a web browser.
I am also responsible to solicit contributions to fulfil this vision. We are fortunate that there are a number of potential user interface contributions that will make it easier for designers to create user interfaces for the Symbian operating system.
Of course the Symbian Foundation will offer a reference UI that is sufficient to create a good mobile phone. However, true excellence will come from creativity, innovation, and differentiation.
Be wary of the performance impact of using XML transforms on a mobile device.
I think it would be useful, if the application UI creation was decoupled from the underlying core, to the extent that the UI is create by UI designers and the core by C/C++ developers. Similar to what you see in web based apps. This is so its easier to refresh the UI without having to re-write the whole app, and doesnt require hardcode programming skills. This should reduce make the application/platform more agile and reduce TTM to get new innovative UI to market.
I am not sure if QT provides such de-coupling.
@ Ash, No – QT as on date doesnt provide such a decoupling either.
Windows Presentation Foundation does to an extent. At the cost of an interface layer which translates across the layers.
Ummm guys. Saying xml is standards based is no more useful than saying ascii is standards based or sql.
How you define your schema is where the big hard desicions come in. There are already dozens of Xml based declarative UIs. Mozilla’s xul being a good example.
Qt stores the UI design in xml and then compiles it down to c++ code. This is what you want from os level framework.
Having xml on the device is not instanly virtuous. It’s a tired old argument. Svg was a stupid format for mobile…incredibly inefficient.
Decoupling is good up to a point, but we have also seen disasters like flash lite which just exit on out of memory.
i really hope that some specific lovely ui designs are used first before creating the general framework otherwise we will end up with another travestly like s60. Playing with 5th edition devices made me dispair about the usibility of the platform.
The least ballsy ui decision is to ‘allow that feature to be customised’
I would echo Stringer’s comment above – XML-declared UIs are fine for creating the UI but ideally you want to avoid the parsing overheads at runtime. UI responsiveness and speed is crucial factor and Symbian/S60 in particular has a reputation of being on the slow side. Please don’t make it worse.
As for the overall UI/UX design – I think you’re quite right that a small, dedicated team will almost definitely produce something better than a design by committee (and if they can start with a completely blank canvas I think it will be better still!). However, I think ideally there would be one such team that designs a next gen Symbian UI and then everybody uses it. If you let each handset vendor / network op / whoever make their own UI flavours you’ll just end up with fragmentation which in turn means a world of pain for app developers (let’s not repeat having S60, S90, S80, UIQ, MOAP & Techview at the same time, eh?).
Sure, device manufacturers should have the ability to differentiate but IMHO bundled apps, themes, services and homescreen customisations offer plenty of opportunity to do so.
In any case I think there’s exiting times ahead so I’ll be watching what the SF does in this area with much interest! Good luck!
Oh, while we’re on the subject of UX, does anyone else here think that those site previews that pop up when you hover over a link on this blog are really annoying? I vote for switching them off – who’s with me?
(Sorry for hi-jacking this thread, but I didn’t know where else to put this)
> My vision is to reduce the barrier to UI creation down to XML
Like XUL (http://en.wikipedia.org/wiki/XUL)?
I echo the speed queries but these could easily be laid to rest by posting ongoing results of ONB performance tests (we already do that for a number of tests in Nokia).
My main concern is how this long term roadmap fits in with what the contributor companies (esp Nokia) have on their roadmap. Nokia is heading down a solidly Qt railroad at the moment and moving that would be extraordinarily difficult at this point.
Hi James,
They annoyed me too. For me, they offered an option to turn them off. But maybe we should turn them off for everybody…?
Hi David,
Yes, that’s what I meant: turning them off centrally. You can do it on the WordPress dashboard. Go to Appearance > Extras and then untick the “Enable mShots” option. HTH
Whatever you do, please don’t invent another XML format for declarative UIs. Every toolkit already has one: Qt, GTK+, Microsoft WPF, Adobe Flash… It’s a mess, and you shouldn’t introduce another me-too option that can’t stand out.
Mozilla’s XUL is nice in many ways because it enables more dynamic applications than most of the others. However that also makes it quite resource-intensive. Furthermore, XUL is currently tied to Mozilla’s Gecko rendering engine, which is not the best fit considering that you seem to be betting on Qt+WebKit.
Instead of XML, why don’t you go with its youthful and popular nephew HTML 5? The Palm Pre has shown that it’s possible to build a compelling mobile experience using a WebKit-based presentation layer. You could do worse than follow their example. This approach would allow you to leverage all the world-class work done in WebKit and would get you started on the important stuff immediately instead of spending the next year abstractly thinking about XML schemas.
[...] Scott is championing the idea of an additional new non-touch UI and a XML-based alternative to Nokia’s Orbit and [...]
Many justified concerns and comments above about the use of XML as part of UI strategy and how it can affect mobile application performance. Today, the importance for flexible, fast and low cost UI customization techniques is very high, so the idea of user interfaces defined using XML should be examined. Providing first class tools for heavy UI differentiation will make Symbian platform more attractive to device manufacturers.
Parsing an XML file on mobile device can be a time consuming task. Slow response time on application launch or when UI layout is changed on runtime will of course affect the user experience. However, there are strategies to minimize these issues.
The Mobile UI XML format should be designed mobile device limitations in mind and the actual scope of UI customization should be defined very carefully. XML structures and schemas can be optimized and data parsing should be made simple when parser is called. Creating too generic format usually makes the runtime performance optimization harder.
XML file can be converted in to a (plugin) component which provides an API for retrieving UI data structures. This design removes the task of XML parsing from the mobile device while still separating UI design process, UI integration and functionality implementation.
In any case, more strict separation of appearance and behavior is needed. For an open mobile software platform, using XML for MUI creation is an attractive solution.
I don’t object to XML per se. But I think it’s silly to start discussions on a new UI framework with the statement “We must use XML because its standards based”.
It seems like the wrong focus. We do need to start with the notion of what makes a good responsive UI and as a secondary priority how we can enable developers to rapidly utilise the UI.
From earlier Symbian posts. Symbian/Nokia are committed to rewriting the applications in Qt based on the elusive Orbit widget set. This will naturally lead to APIs for 3rd parties based on the same widgets.
This blog talks about the top down UI design/look and feel, yet the balls already seem to be in motion with Qt from a bottom up piece wise approach. It’s a very confusing message at the moment. Are the UI requirements from these councils directly feeding Orbit based requirements?
This discussion is extremely valuable. Can we move it to the forums so that it is more easily accessible? I’ve posted the blog posting there to kick things off. The forum thread is linked here:
http://developer.symbian.org/forum/showthread.php?p=5281#post5281
Please keep this topic live on the forum, as it is very important to the future of the platform and all of your input is extremely helpful.
-scott
Scott,
Is there any reason why Symbian Foundation should not attempt to make its Reference UIs (and overall “Reference UXes”) absolutely world-class (Apple level), in the first place?
It’s not a big project. It’d only take a very small team of people, under the leadership of someone like yourself.
The UI corps at the giant lumbering phone companies would still be free to change that UI as and if they wished (eg to retro-fit “Nokia Heritage” into it…) meaning you can hopefully avoid them getting too involved, as you can guess the effect that would likely have.
Lean & mean…
Nick
Nick,
‘dadurant’ has replied to your posting here: http://developer.symbian.org/forum/showthread.php?t=2226
Symbian Foundation looks after the UI but does not design, nor code the UI. We certainly hope for and plan to have a world-class user interface, which will require innovative and excellent contributions from the community–hopefully including you!
Contributions from the operators and the manufacturers is key to Symbian Foundation’s success. However, their contributions will be evaluated equally with contributions from other SF members: Every member is entitled to contribute, and contributions are evaluated on their merits. Each member of the councils has a single vote, so no single member can dominate the decision making process.
Members who contribute to the platform will have a significant impact. Those who do not contribute to the platform will have little or no impact.
>> Members who contribute to the platform will have a significant impact. Those who do not contribute to the platform will have little or no impact.
I guess that sums up my main concern.
As with Jazz – the notes you don’t play are as important as the ones you do., a UI can be vastly improved by removing or de-emphasising certain elements.
A lot of UI customisation is done for purely commercial rather than aesthetic gain, which is ok up to a point but completely fails if the sum of the parts end up as a steaming pile of manure.
As a concrete example. The notifications area on MS windows is just full of rubbish now because every OEM and third party wants their app to sit there – why does the iPlayer need to be there for example?
What might have been a useful feature is rendered totally useless when i have to fight through the crud just to find my volume control slider.
Here is a less black and white scenario to consider:
If OEM codes up UI feature A and another OEM codes up feature B, and each feature is great in isolation but lets just say that feature A and B don’t really gel well on a real device – they use two different UI concepts to achieve the same thing.
.
The options for the platform are
1. Ignore both – let the OEMS develop their own code (fragmentation)
2. Adopt one or the other (but can you really reject A if it was from Nokia)
3. Take the best elements of both in a new, even better solution
4. Construct a sickly chimera which works worse than both A and B individually.
5. Decide it’s all too complex and settle for a very abstract framework such as X and let warring of toolkits to develop which fragment the platform to bits. (as with linux or S60/UIQ).
A very interesting management problem!
XML to design UI is the way to do. But how to do that in a standardized way and efficiently for limited devices (textual XML isn’t optimized for fast parsing/low memory)?
- lot’s of format XUL, XAML, XFORM, Android XML Layout, iPhone XIB, …
- only Android XML is packed to binary for better efficiency on device
- use a radical HTML UI as WebOs does
I did several XML UI to binary for J2ME/Symbian and that was ever the best solution. It also gives the control to designers.
Just my 2 cents
@Stringer Bell: Very eloquently put – I like the Jazz analogy. If I understand you correctly, you broadly agree with Scott but you have concerns about how a flexible UI would turn out in reality.
The level of abstraction is a key area. As you correctly point out, abstract too low and you end up with binary incompatibility. Abstract too high and you can render a well thought out UI concept useless as everyone tries to claim their stake in the few customizable elements.
The reward if you get it right, is binary compatible applications that can work across a variety of paradigms (touch, 12-key, hybrid, other future UI) without compromise in usability.
Sure, some device/application creators will make bad implementations above the abstraction, but as app developers and end-users become more UI savvy they will vote with their feet and the best implementations will prevail.