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.

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

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!

‘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.

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

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

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?

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.

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.