Mythbusting Meltemi: Part 2 – The Purpose of Meltemi, Nokia Clipper, Qt

Here’s part 2 of the Mythbusting Meltemi series. If you missed it, here was Part 1.

– Just some clarification from the last post.

In 2010 the Nokia strategy was to use QML (very high level Qt framework) for 3rd party apps. That would have solved the fragmentation issue Nokia had as they were either using or planning to use Series 60v5, Symbian^3, Symbian^4 (that got cancelled) and MeeGo parallel. There was not going to be app compatibility except that Symbian^3 could run older Series 60 apps. The vast majority of the phones sold and in the field were running and were going to run older versions of Symbian.

In the squeeze of Android and iOS Nokia had an issue with app development. It was not enough if 3rd party developers made Qt app for one platform as apps should have been available for all of them. Symbian^3 solved the issue with binary compatibility, but with MeeGo that would have been too much. Qt app could be recompiled and deployed on new platform but past had shown that not all developers did that, especially old apps were rarely getting any attention when new OS version was launched.

Symbian^3 was just getting out of the door. Maemo Harmattan was not yet there. Intel MeeGo (yet another binary incompatible OS to mix) was yet to come. Meltemi was at concept state. Apps made in 2010 were needed to be available for all future platforms but history was full of examples of that not happening.
QML was supposed to be the silver bullet that would have solved ALL of this.

 

That was “my best understanding why Nokia pushed QML as the default choice for app development”, not a stone-carved fact. Nokia management was really bad at communicating large scale strategy so I don’t have first hand knowledge whether this was the truth, the whole truth and nothing but the truth. 🙁

Meltemi was supposed to run QML apps by default whereas C++ apps were possible but not recommended unless performance required it. That’s a fact.
Meltemi apps were originally wanted to run also on the N9 “as is”. That’s also a fact. (This requirement was dropped after Feb 11th, also a fact.)

And the app gap from Symbian to MeeGo was nothing short of a public secret and there really were no good solutions to that. In early 2009 it would have been rather easy to convince developers to write Qt apps. In 2011 it was “iOS first, Android second, others after that if needed”.
Just wanted to say this.

What was the role of Qt inside Meltemi?

Meltemi started on top of latest public Qt/QML version. In summer 2011 it shifts to Qt5/QML2 which both were publicly announced in December 2012 (by Digia). There could not have beenMeltemi 3rd party SDK before that. There should not have been launch of a Meltemi product before 3rd party SDK was out.

Is Sailfish influenced by Meltemi?

Yes. The Qt5 components made in Meltemi are widely used there. They also hired several ex-Meltemi workers in summer 2012. So many of the swipe/pull gestures used in Sailfish UI exist since Meltemi development already had UI using those. The UI itself looks different from Meltemi.

Are there similarities with the new Asha UX and M

Yes. Asha UI and also some deeper levels of Nokia X UI have been mostly copied from MeltemiUI. The same design,team has worked on all three AFAIK so they try to be consistent.

Could it have evolved to a single strategy across all tiers solution

Meltemi (had it been completed) would have scaled up rather well. It was the technical solutions that would have hindered it. I’ll write more of the Meltemi history so that we get to it but I’ll put it to another mail

[A little bit more info again from the anonymous source about Meltem]

Meltemi was more like a feature phone than a smartphone. There was no multitasking, applications were killed when put to the background. That’s killed, not frozen. Some very modest state data was preserved. Only some native background tasks like music player were allowed. The 3rd party APIs were limited. If you have used Windows Phone 7.0 you know what I mean.

From the start Meltemi project had defined criterias to meet and those were that apps needed to launch in 1 second and UI had to be smooth scrolling at 60fps.
The key selling points were in fresh, appealing UI and social integration. Phone was supposed to link social networks everywhere in the UI. E.g. if you browsed through your photos and encountered a photo you had shared in Facebook, you would see the likes and comments with the picture even though you were not in Facebook App. Target group were young people in Asia-Pacific. What comes to UI, Meltemi was probably most design-driven product that has ever existed in Nokia. Nokia Design had free hands and also often the got to say the last word.

That’s pretty much the starting point. Then to technical side:

Due to price level the first product (Clipper) would use single core processor and have only 128MB of memory. I remember when MeeGo people came to project in summer 2011 and wondered how this was supposed to be achieved: in N9 it took about 100MB of RAM to just launch a QML app (taken by the framework that parsed and loaded QML apps). In Meltemi app would be mercilessly killed if it used over 50MB of RAM (with the exception of Web Browser that was allowed to use 60MB). People from Meltemi had assured Nokia management that this could be achieved.

The key component in Meltemi was the JSON database. Everything was supposed to be stored there so that the wanted interactions could be achieved. In example you could go to gallery app and “social” section. There the list of pictures would have needed just one database call “get all photos that have reference to social networks, sorted by date”. Getting amounts of comments and likes would have been in lines of “for each photo in the list get number if likes and number of comments. There was no need to know which social networks were supported in the phone. No need to request lists from several services and parse through them to remove non-photos. SMS conversations were one request away (“get  all messages of type SMS or MMS where sender is this contact or recipient is this contact, sorted by date”).

App development for Meltemi was supposed to be easy for a reason: the goal of the project was to create a platform where phone UI, features and functionalities could be easily modified by Nokia Design. As QML is very straightforward language, UI designers could try layout changes and dummy features by themselves, speeding up the prototyping and development. Nokia wanted to be able to react quickly to changes in market and Meltemi was supposed to be easily modifiable.

UI was designed to be made out of widgets that would be reused and if there would be a wish to change UI style, it could be achieved by modifying the widgets and leaving the actual OS code untouched.

For this reason the OS had to be easy to update (which of course would be the case due to QML). Plans were that any product will get OS updates 18 months after the end of production. So if we assume first devices had been launched in Q2 2013, and manufactured for 18 months, their last OS update would have taken place in Q2 2016. The updateability was crucial. Meltemi needed to get out as soon as possible and as it was supposed to appeal to feature phone buyers, it didn’t matter if it was “feature phone-ish” at first. OS updates would fix things in time.

That I believe is pretty much all that Meltemi was supposed to be: Smartphone OS by definition, but with very limited capabilities at start. 3rd party developer offering, but with limited APIs at the beginning. Fancy, fluid, fast, cheap, appealing, social. Later used punchline was “twice as good as N9 but for quarter of the price”.

Next we would get to “what Meltemi turned out to be.

____

Thanks again to our source and thanks you guys for the continued conversation! The posts in the series so far will cover what was discussed behind the scenes and we shall ask them questions that have been highlighted as a result of your discussions.

Category: Nokia