MeeGo: Two (M)onkeys don't make a (G)orilla. But they sure make a lot of noise

[What is behind the announcement of Meego operating system by Nokia and Intel? Guest blogger Thucydides Sigs deconstructs what Meego means and its importance to the mobile industry]

How much substance is behind the noise of Nokia’s and Intel’s announcement of Meego? A few points to consider.

Nokia, who feels threatened by Google’s Android and Chrome OS efforts, is putting significant  efforts in order to expand into other device categories and bring its Ovi services to more consumers in more places. So a move that brings Maemo – together with Ovi (and the underlying Web-runtime apps and Qt cross-platform) to Intel chipsets is a straightforward strategic win. It will allow OVI services – such as Maps – to get into non mobile devices, especially Automotive (which has been a strategic focus for Intel) and other connected (but wired – after all power consumption is Intel’s Achilles heel) devices such as home phones.

So is Nokia going to bet it’s future Linux devices on a group of Intel engineers? Nokia is smarter than that: Intel software engineering has never been something to write home about. And Nokia has always been careful in maintaining and winning control over strategic areas. So Nokia will either maintain a parallel internal effort or maintain tight control over the ARM port and the overall MeeGo architecture.

Is MeeGo going to really bring Ovi services & Maemo into the hands of tens of millions more consumers? Well, MeeGo open’s a door, but success will depend on the quality of Maemo and Ovi experience. Maemo v6, due late this year, will be catch-up to where Android and WebOS were half a year ago, and were Apple was a year ago. So it is still one or two years behind the rest of the industry. That said, Maemo does not need to be the best – it needs to be good *enough* for ‘mass market’ consumers, so that combined with Nokia industrial design expertise and marketing power, an “object of desire” can still be delivered.

It’s this consumer “Desire” that brings us to the Ovi Services angle – and the question of how good will Nokia Services offering will be. Studying the NexusOne, it is impressive to see how Google seamlessly connected it’s many service offering – creating a compelling integrated experience. From a photo gallery that is both local and web (Picassa), through Google Voice (low cost calls, transcribed voice messages) and an almost perfect navigation and mapping experience (including turn-by-turn voice instructions and maps). Contacts, Email, Calendaring are the basics that are a must have. And Google is quickly expanding into other services (note the recent Aardvark acquisition and Buzz launch). Yes, MeeGo gives Nokia a vehicle to bring Ovi to some other device segments, but can Ovi compete effectively with Google’s breadth of services?

What about Intel? It has been spending hundreds of millions of dollars on a software strategy which does not seem to show a clear path to recouping the investment. Moblin, has not been able to ship in any significant volumes, is inferior to either ChromeOS or Android from a software platform perspective, and lacks any kind of services offering (which is why they needed Ovi). If Intel thinks that software is another part of it’s vertically integrated stack that will differentiate the chipsets, then it does not make sense to open it up and make it an open industry initiative. If Intel truly believe that Moblin should be open and used by competing ARM chipset vendors, then what does it gain from spending those hundreds of millions of dollars on the effort?

Open Source: ChromeOS, Android and Maemo are creating a very different software ecosystem then the one Intel got used to with Microsoft in the 90s. None of the software players is going to generate significant revenues on the device side. Intel exec’s might  want to re-read Andy Grove book, step outside the box and ask themselves if their software effort still makes sense in the 2010 industry context.

And while Intel is spending time on building this software strategy, the chipset market is experiencing a disruptive change, shifting from computing power (where good enough performance is delivered by both Intel and ARM), to battery power and mobility where ARM is clearly superior.  It might be better for Intel to focus it’s efforts back on it’s chipset technology and fix its power consumption problems, because when it comes to wireless devices (either within the home or outside, anything that is not tethered to a power cord), their offering is inferior to ARM, and no amount of software will be able to cover this gaping hole.

What about the rest of the chipset industry? Would the other ARM chipset vendors, such as TI, Qualcomm, Broadcom and nVidia follow path and join MeeGo? It’s hard to imagine that any of those companies will want to entrust their software strategy in the hands of Intel: not only is Intel a direct competitor, it software skills leave a lot to be desired, and it’s long term commitment to the space (as outlined above) is not clear. Is Nokia’s involvement enough of a carrot to entice those vendors into MeeGo? Having Maemo running on top of MeeGo will make insertion into Nokia easier, but Maemo is open source and there is nothing holding the chipset vendors from porting Maemo to their chips on their own or with the help of other independent 3rd parties. So we suspect Nokia will give it a modest try, but when it comes to purchasing chips, power, performance and cost will still be the over-riding criteria for Nokia.

So, lots of noise that those two monkeys are making, but little impact. MeeGo seems to be cute (qt) and (h)armless, but not a big industry changer.

– Thucydides

[Thucydides Sigs – a pseudonym – has many years of experience juggling computing constraints, mobile software and consumers needs. With that said, imagine listening to a violin sonata not know who the artist is or who composed it. You end up having to listen more carefully in order to make a judgment. He can be reached at thucydides /dot/ sigs [at] gmail [dot] com]

UI Technologies are trendy…but what are they really good for?

[UI development flow and actors: Graphical Designer, Interaction Designer, Software Engineer, classical technologies: GTK, Qt, next generation: Flex, Silverlight, WPF, TAT, XUL, SVG… guest blogger Thomas Menguy describes what are the main concepts behind all the UI technologies, what the new generation ones have in common, what those modern approaches are bringing to the product development flow…and what is missing for the mobile space].

A good UI is nothing without talented graphical designers and interaction designers: How the plethora of new UI technologies are helping unleashing their creativity? What are the main concepts behind those technologies?Let’s try to find out!

UI is trendy… thank you MacOS X, Vista and iPhone!







Put the designers in the application development driver seat!

Here is a little slide about the actors involved in UI design


UI flow actors and their expertize

What does it mean?

Different actors, different knowledge …. So different technologies and different tools!

Those three roles can be clearly separated only if the UI technology allows it. This is clearly not the case in today mainstream UI technologies where the software engineer is in charge of implementing the UI and the service part, most of the time in C/C++ , based on specifications (word document, Photoshop images, sometime adobe flash prototypes), that are subject to interpretation.

  • The technologies used by the designers have nothing in common with the one used to do the actual UI.

  • The technologies that allow UI implementation…require an heavy engineering knowledge.

  • Big consequence: the software engineer decides at the end!

The picture is different for web technologies where it has been crucial and mandatory to keep strongly uncorrelated the service backend from its representation : Web browsers have different API and behavior, backend have to be accessed by many other way than web representation…and above all data is remote and presentation is “half local/half remote”.

Separating representation, interaction and data has been the holly grail of applications and services development for years. It has been formalized through a well known pattern (or even paradigm in that case) : MVC (Model View Controller)


MVC pattern / source: wikipedia
From wikipedia:
The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating if today is the user’s birthday, or the totals, taxes, and shipping charges for shopping cart items).
Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.
Renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.
Processes and responds to events, typically user actions, and may invoke changes on the model.

All the UI technologies are offering a way to handle those 3 aspects and, as a consequence, are providing a programming model defining how information and events flow is handled through the MVC.

See below a simple schema I’ve made describing a GTK application: when you look at an application screen, it is made of graphical elements like buttons, lists, images, text labels, called widgets (or controls) .

Rmk: the term “widget” is used with its literal meaning : “window-gadget”, this term is now used a lot in web 2.0 marketing terminology and by Yahoo/Google/MS to represent a “mini application” that can be put on a web page or run through an engine on a desktop PC or a mobile phone, to avoid confusion I prefer the term of “control” over widget for the UI technologies, but will continue using “widget” in the rest of the GTK example as it is the term used by GTK itself.
Widgets are organized hierarchically in a tree, meaning that a widget can contain other widgets, for example a list can contain images or text labels. In the example below the “root” widget is called a “Window”, it contains a kind of canvas which itself contains a status bar, a title bar, a list and a softbutton bar. Then the list contains items, the title bar has a Label, the softbutton bar contains some buttons and so on.

A widget is responsible for

  • Its own drawing using a low level rendering engine, called GDK in the GTK case (GDK offers API like draw_image, draw_text, etc).
  • Computing its size according to its own nature (like the size of the text that will be displayed for example) and the size of its sons.
  • Reacting to some events and emiting some specific ones: the button will emit a “press event” when it is pressed with the touchscreen or when its associated keypad key is pressed.

The widget tree will propagate system events (keypad/touchscreen, etc) and internal events (redraw, size change, etc) through the widgets. The developer will register callbacks (in fact functions, piece of code implementing a functionality) that will be called when widgets will fire events (like the “press event”) .


GTK Widget tree structure: a phone screen example

The major GTK/gLib formalism is how those events/callback are handled: through what is called a “gloop” where all events are posted in the loop queue, dequeued one by one and “executed” in this loop, meaning their associated user callbacks will be called. This loop is running in one thread. This is what we call a programming model. In nearly all the UI technologies such a loop exists with various formalisms for the queue handling, event representation, etc.

To finish with the above schema the user callback will then access to the middleware services, the various databases and so on.

There is no clear MVC formalism in that case, the controller is mixed with the view …and even the model that is mixed … with the widgets! (so with the view)

Qt Model is really identical to the this one.

One last point very relevant for application development and design: the notion of states. Each application is in fact a state machine displaying screens linked by transitions, like in the example below where in the state 1 the user decides to write an SMS, it will open an SMS editor screen and clicking send will go to a selection of phone numbers.


Application State Machine: write sms example

Here is an attempt to formalize a modern UI framework with Data binding (for Model abstraction).


UI engines formalization
Control: equivalent to a widget but where the MVC model is fully split. A Data Model as to be associated alongside with a Renderer to make it usable.
Control Tree: equivalent to the widget tree: aggregation of Controls, association of the controls with a Renderer and a Data Model. Possibly specification of Event Handlers.
Data Model: Object defining (and containing when instantiated) a set of strongly defined and typed data that can be associated with a Control instance.
Data Binding: Service used to populate a Data Model.
Control Renderer: Object that is able to graphically represent a Control associated with a Data Model, using services from a Rendering Library.
Rendering Library: Set of graphical primitives, animations, etc.
Event Handling (and Event Handler): code (any language) reacting to events and modifying the current state machine, the Control Tree, etc.
Standardized Services: Interfaces defined to access middleware directly from the event handling code.
Server Abstraction: Possibility to transparently use Data Binding or any service call locally or remotely.

Ok if you are still there, and your brain is still functional, here is what’s happening today in this area….

In traditional UI frameworks like GTK, Qt, win32, etc the control tree description is done with a C/C++ description … a little niche technology have paved another way: it is called HTML: after all an HTML web page description is defining a tree of controls, W3C use a pedantic term for it : the DOM tree. JavaScript callbacks are then attached to those widget to allow user interaction. It is why all the new UI technologies are based on an XML description for this tree, it is muuuuuch more easier to use, and allow a quicker description of the controls, and above all it allows nice design tools to manipulate the UI….Apart from this XML representation the majority of the UI technologies are coming with:

  • An animation model, allowing smooth transitions, popularized by the iphone UI, but it was already there in MXML (Adobe Flex Format), XAML (MS format), SVG, TAT offer….
  • Modern rendering engines (Flash for Flex, MS has one, TAT Kastor).
  • Nice UI tools for quick implementation: Adobe Flex Builder, MS Expression line, TAT Cascades, Digital Airways Kide, Ikivo SVG…
  • In many case : a runtime, to be able to run a scripting language.

Here are some quick tables, really not complete, of some of the most relevant UI technologies in the PC and mobile phone space.

Just to explain the columns:

  • RIA : Rich Internet Application, delivered through a browser plugin
  • RDA : Rich Desktop Application: delivered through a desktop runtime
  • Runtime: ok, galvoded name here, just a name to represent the piece of technology that allows the UI to run
  • UI: Technology to describe the control tree (you know what it means now!)
  • Event Handling: the dynamic UI part, and how to code it (which languages)
  • Tools: UI tools






Embedded rich UI technologies

So its time to answer the main point of this post: How those technologies are helping unleashing designers creativity? By defining a new development flow, allowing each actors to have a different role.

Here is an Adobe Flex “standard development flow:


Adobe Flex&Air tools flow

In the next schema I try to depict a more complete Adobe Flex flow, adapted to the mobile world, where, for me, a central piece is missing today: it is not possible now to expand “natively” the adobe air engine, this is mandatory for mobile platform with very specific hardware, middleware, form factors.

So I take the adobe flow more as an example to demonstrate how it should work, than as the paradigm of the best UI flow because this is not the case today (same remarks for MS flow, less true for TAT for example)




An Adobe UI design flow for embedded

This shows clearly that the “creativity” phases are clearly uncorrelated: different tools are used between the designers, they can do a lot of iterations together, without any need of the software engineer. This one can focus on implementing the services needed by the UI, optimizing its platform, adding middleware features.

  1. Interaction Designer defines the application high level views and rough flow
  2. Graphical Designer “draws those first screens”
  3. Interaction Designer import it through Thermo
  4. Graphical Designer designs all the Application graphical Assets
  5. Interaction Designer rationalizes and formalize what kind of data, events and high level services the application needs
  6. Interaction Designer & Software Engineer are working together on the above aspects HINT: A FORMALIZM IS MISSING HERE once done:
  7. Software Engineer prepares all the event, data services, test it unitarily, in brief: prepare the native platform
  8. Interaction Designer continues working on the application flows and events, trying new stuffs, experimenting with the Graphic Designer based on the formalism agreed with the Software Engineer.
  9. Once done … application is delivered to the Software Engineer that will perform target integration, optimization…and perhaps (hum certainly) some round trip with the other actors 🙂

So this is it! this flows really focus on giving power to the designers…taking it from the engineer hands. Some technologies are also missing to really offer a full Mobile Phone solution:

  • All the PC technologies are about building ONE application and not a whole system with strong interaction between application. With today technologies, the designers are missing this part….leaving it to the engineer: How to cleanly do animation between applications?
  • Strong theming and customization needed for:
    • product variant management: operator variants, product variants (with different screen sizes and button layouts for example), language variant (in many phones 60 languages has to be supported, but in separated language packs).
    • A not well known one: Factory line fast flashing of those variants. It is very long to flash the whole software of a mobile phone while on the factory line … so if you are able to have a big common part and a “customization” part as little as possible but with the full UI…you gain productivity…and big money 🙂
  • Adapted preset of widget or controls (try to do a phone with WPF or Flex…all the mandatory widgets are missing)

Anyway an UI technology is only the way to interact with a user…to offer him a service. Most of the technologies presented above are about service delivery and not only UI…My next post will be about this notion of service delivery platforms.

[Update] Replaced the term “ergonomics specialist” by “Interaction Designer”, thanks Barbara, see comments below.

Thomas Menguy