MNB RG: Meltemi Story – Part III

The final and closing chapter to the Meltemi story. Thanks to our anon source for this piece and also bugging as after many missed emails.

___________________

After previous parts it would be best to explain how the Meltemi UI looked like. On devices there were no buttons in front, only volume and lock buttons (like in N9). Camera worked via touch screen UI. On the actual UI the idle state was kept pretty much the same throughout the project. It consisted of pages that you can browse with swipe gestures like in N9. Namely they were:

-“apps” (icon grid with squircle shaped icons like in N9)
-“recent” (similar to the Asha UI fast lane)
-third page was not the multitasking view familiar from N9 as multitasking view came from a swipe up from below the screen. (And as said previously, there was no multitasking per se.) The third home screen was one of the things that was changed along the way. Early version of Meltemi UI had location-sensitive “nearby” page as the third page and if I recall correctly, the third page was completely dropped before end of project.

What was surprising is that in the app level the UI looked a bit like Windows Phone, although this was late 2010 – before the Microsoft alliance. UI had thin white font on black, lots of text-only UI elements, back and search icons rendered at bottom of touch UI, and so forth. This UI style was called “Breadcrumbs UI”. Name came from largish header texts that worked similar way as in WP8 OneNote app: The header shows where you are in hierarchy. Except in Breadcrumbs UI the header gathered stuff as you moved deeper in the UI and these “breadcrumbs” told you where you were and provided quick access backwards in the UI. So e.g. In gallery the header could be (after opening few folders and an image):

From nokiacollections on facebook

Folders > summer photos > midsummer festival

A tap on “Folders” would take you back to initial gallery level. Tap on “summer photos” would take you back to that folder. Long-tap on “Folders” would open drop-down list where you can choose different view, e.g. “Timeline” or “Social”. The drop-down list was only way to access the other views. (Drop-down list feature was also limited to first level only as it was impractical to e.g. have full list of folders from “summer photos”).
Key thing is that every app had different views (in this example “Folders”) and one of them was “Social” which was the access to social networks.

This was the design in late 2010 but – unfortunately – it was not the design at summer 2012. The one thing I learned about Meltemi project is that you must always keep your variables at minimum. (And I’m not talking about programming here.) If you plan to use new OS, do it on previously used and proven HW. If you plan to use new HW, use the already existing OS. If you plan to add new features, keep the rest of the OS as it was. If you plan to modify the OS, keep the features same. And at last, if you need to do several of these, do them one by one, not all at once. This way you have a stabile checkpoint after every modification.

As previously said, Meltemi proof-of-concept originally ran in S40 full touch HW. That was the situation at the time Nokia chose to use Windows Phone for their high-end phones (and Meltemi for their feature phone replacement). So why was I talking about the variables? Meltemi changed everything and all the time.

Schedule for Meltemi was roughly: Phone will have basic features (call, messaging, browser) implemented and working in hardware by end of July 2011. At that point the entire project crew can start using Meltemi phone as their daily phone, which enables fast feedback for implementation (idea was that people could update their phones as often as daily, but at least weekly). By end of year 2011 phone would be feature complete and final testing and verification would start. Public launch would happen around there, 3rd party developers would get devices right after and phone would be in shops few months later.

Then – and unfortunately I don’t know exact reason why – the HW was changed. The new HW was something that had not been used before and it had GPU to ensure that UI would meet its requirement of 60fps smooth-as-silk scrolling. It turned out that Qt 4.8/QML 1.2 did not support this, so the whole development was switched to Qt5 and QML 2.
New HW was awesome. It had single molded polycarbonate frame that had steel cover at the back granting access to SIM card(s) (yes, Clipper was dual-SIM), SD card and battery. Front was almost completely covered by display, with quite modest bezels. Portfolio-wise Lumia 610 was supposed to be the “big brother” and Clipper looked exactly the same except it was smaller and didn’t have extra four keys (WP UI and camera). I believe original plan was to launch them side-by-side. Outside the cool looks the change of HW was nothing short of a disaster. We got first two (yes, two!) prototypes at end of July 2011, the time we were supposed to start using Clipper as a daily device. SW was running in the protos only after long fight (perhaps in September) and even then it was run from SD card as we couldn’t flash the phone itself.

Remember what I said about keeping the variables at minimum? As if the HW change and Qt version change were not enough, the Nokia Design team redesigned the UI.

Breadcrumbs UI was found not to be intuitive enough so it was replaced by “Facets UI”. The facets tried to keep the hierarchy level idea. It removed the long header text (which had already proven to be difficult as screen resolution was low so there was no way to show full hierarchy even three levels deep). Instead Facets had header bar that showed where you are (e.g. “Midsummer festival” in previous example). By pulling down you would get more items that were hiding off-screen above the header: first “Summer photos” and finally “Folders” (yes, I believe Jolla took some of the pull-down menu idea from Meltemi). You could swipe left and right to different views or then long tap on header item to get the drop-down menu (as in Breadcrumbs UI).
Facets UI didn’t live long. Mostly because it was even less intuitive than Breadcrumbs. Before the end of year 2011 Facets UI was replaced by Tabs UI which is very simple to describe: go to N9 dialer app. You’re done.
Yes, tabs UI had tabs at bottom of screen (both implying about the multiple views and providing a way to access them). Gone was the browseable history in header. Meltemi UI had returned to its roots at least a year too late.

During this time SW development had rewritten the UI twice. Now our signal to project management was that if they ever want to see a working product, they’ll have to ship this UI and deserve any future UI innovations to post-launch SW releases. And even then there were some smaller parts of UI that were redesigned several times all the way to summer 2012 when project was cancelled.

That much for HW and UI, next we get to the actual OS. Meltemi was probably the most agile SW project in the history of Nokia. Elop wanted it to be so as did other management. As the goal was to have a product that could have its UI redesigned without preparation, that was essential.
Teams were essentially the highest technical authorities what came to their own area of expertise. Definition was “empowered and accountable”. Teams were empowered to define how they do their work. The teams gave their commitment on what content they can deliver and were accountable for delivering that content in time.

Organization was very well built around this setup. Looking back now makes it rather easy to point out that central coordinating authority was missing. Back then the importance of it was not all that clear. I already said before that the key component in Meltemi was the JSON database. The JSON is existing standard (see http://en.wikipedia.org/wiki/Json ) so there is nothing magical there. However the actual database SW component that was supposed to make all the magical things happen was not a ready product. In fact,Meltemi was the first platform to deploy it and – frankly – that was easy to tell. There were dozens of times when we came to office, just to see that the database no longer worked as it previously had or that the object namings had been redefined or whatever. The team responsible of JSON DB might have seemed as if they were totally unaware that there was entire R&D using their services…
…until you got to see the test environment that was supposed to verify that there was no regression in the changes made.

One morning we got to work just to see that none of the apps could be launched because the DB keys for apps in launcher grid did not match to actual apps. I repeat this so that it sinks: a phone flashed from the master code line which everyone was supposed to do their work on could not start a single app. Not even dialer. Not even a “Hello world”. Nothing.

We were all wondering where that bomb came from and it turned there had been (once again) a change in the database code. And ALL test phases from unit tests in DB team to module tests to integration tests to product-level release verification tests were green. Not a single one test level noticed that the phone is incapable to start any apps. NOT ONE. So automated release system made a nightly release out of it and spread it to R&D across the globe.

Can you imagine developing SW platform across several continents and not having a single regression test that actually notices if the SW is so badly broken that none of the apps start? To me that day was a real eye-opener. The project had a deep-rooted problem in testing efficiency and by the end of the Meltemi project this problem was never properly fixed.

Then there were the problems with 3rd party apps. 3rd party apps such as WhatsApp needed access to some of the phone internal data (in case of WhatsApp that’s contacts and photos). Some of the content like photos were seen as “OK” to use. Some content like text messages were not (due to privacy issues). Originally the idea was that 3rd party APIs will be limited and that creates the barrier behind which the 3rd party apps operate. Very similar to Windows Phone 7 were e.g. 3rd party apps could not delete photos and photo selection was done using the OS provided photo picker. But then it turned out that the JSON DB would need to be open to 3rd party apps. Reason for this I do not know, apparently someone in management was worried that the APIs would not be good enough. All hell broke lose. First proposal was to have access levels in the database and therefore 3rd party apps would have been able to e.g. read photos but they wouldn’t have been able to read texts. 3rd party apps could read calendar events but not write them, etc.

However due to the hurry the project was in, this idea of complex access control of database was dropped. As a result the JSON DB objects lost the transparency of their origin. Apps would not see any difference between native app originated object and 3rd party app originated object. That situation was unacceptable: third party malware could e.g. create SMS message that is targeted to a paid number and store it directly to outbox and the OS could not detected that but would send it. Or if 3rd party app would have flooded the database with small calendar events, there wouldn’t be a way to clean it up as there was no way tell which were the fake ones and which were real ones. So a workaround was created:

By the original design database was supposed to split its data into separate memory areas called “partitions”. Partitioning was designed to make database faster. Performance was its only purpose. Now the 3rd party apps access was planned to be limited via the partitions: 3rd party apps would not even see certain partitions and this way data in private partitions could not be compromised whereas critical data would never be stored in public partitions.

That solution was a disaster. First of all the solution turned out to worsen the performance in application side as we needed to do separate database calls to get data from different partition (e.g. if we wanted to see 3rd party calendar events in the same view as calendar events from OS internal calendar). But it also killed the performance benefit in DB side as same data types could indeed be in different partitions – just contrary to the original intent of the partitioning. And due to the requirement of 3rd party support the partitioning could not be reverted to its original state either.

And then the widgets. Remember the widgets? The original idea was to use widgets as “visual representation of database entities”. That wa supposed to be THE thing in Meltemi app creation. Few examples:

-Do you want to show grid of photos? Put thumbnail widgets into a grid, query a list of photo ID’s from database and throw the returned IDs to widgets. Done!

-Do you have a calendar entry you want to show? Date/Time widget shows the date. Location widget shows location. You can throw contact widgets to show list of participants. And so forth. Programming made easy!

This worked out to certain extent. e.g. time/date widget makes sense. When everyone uses it, time/date representation is consistent across the UI. On the other hand, e.g. “Social image” widget makes almost no sense at all. In original plan that was a combination of other widgets: Social network icon, number of likes, number of comments and so forth. Having few of these on screen and throwing an ID to each would mean that each widget passes the ID to smaller widgets and then each of THESE widgets query the database for the data it needs. By using widgets you wrote minimal code but slowed down the UI via these multiple database calls. By writing the UI by yourself you did ONE database call and wrote all the code yourself (since it was your app that spread the results to corresponding elements in the UI). People creating the widgets sounded like they came from desktop world. I heard that one of the location widgets was so massive there could be only one of them visible at any given time or the device ran out of memory. Only one.

Eventually we were told not to use widgets at all as the original performance goal (60fps, 1 second app startup) could not be met. And to my knowledge teams mostly did not use widgets from that day on.

Thet’s pretty much the technical issues. Then few words about the project itself:

In December 2011 week 49 Tuesday we had SW which was quite stable and we could make phone calls even though those got cut off after 30 seconds. On Wednesday the same week the SW was broken again. Calls could not be made. Apps kept crashing. Internet connections did not work (neither Wi-Fi or cellular data). Meltemi management woke up to the bad state of the project and the message from above was that project needs to deliver results to prove itself viable. Meltemi management made quite extraordinary proposal: people from every part of the project (database, QML framework, middleware, OS, apps,…) would be flown to one of the Meltemi sites for 3 month coding camp. The goal was to remove the silos from the organization, speed up the development and bring the project back to schedule. This must have cost a fortune, yet it was approved by higher management (all the way to Elop AFAIK).

Meltemi program was given a clear warning: failure was no option and this needs to happen. Ulm was chosen as the site due to its central location. And starting from late December people were traveling to the “Ulm3” camp. To my understanding it was three steps:

January: Fix the OS (get data connections working etc.)
February: Get the basics working (Call, Messaging, Browser in a shape that device could be used as a daily driver).
March: Optimize performance and catch up the features.

Well that was the plan. And with all this in place I think it was week 5 before the SW was in the same shape where it was on that one nice Tuesday. And we still could not connect to Internet over cellular data. By the end of Ulm3 the good news came in that they had included cellular data too. The whole Ulm3 initiative made the project take giant leap forward – yes -but there were still too many leaps to be taken and management did not want to burn any more money on that coding camp. People returned to their sites and tried to keep the new pace that was introduced by Ulm3 event.

In February 2012 Clipper was cancelled. Reason was that when it would finally get to market, it would look outdated. As the production capacity existed, Clippers were supposed to be shared to 3rd party developers (similar manner as with N950).

The next two products – Goa and Zhora – would be used for launch. Launch was planned to take place late 2012 right after Windows Phone 8 Lumias. Goa HW design was later copied to Asha 501, except that in the Goa corners were sharper, similar as with Asha 503 (that also inherited its HW design from Goa) it’s just that in Goa the polycarbonate was not transparent. Zhora was larger, most likely sharing looks with Lumia 920 as it was rumored to have N9 form factor.

I’m saying “most likely” as I never got to see a real prototype of Goa or Zhora. And let’s try to make that sink: I worked in Meltemi R&D all the way to June 2012 when Meltemi by some rumors was “almost ready”…

…and never got to see a single prototype of the device that would go to market first. The only physical object I held in my hand was a dummy phone that was used to demonstrate what Goa will look like. For Zhora I didn’t get to see even that.

Far in the future was a product that would have had HW QWERTY keyboard and landscape UI, like Asha 302. It was impossible to estimate when development would have time to actually make required changes to support the landscape UI and HW QWERTY but the product would have hit the shelves in 2014 the earliest. That product did have a code name too but unfortunately that never came to my ears.

So what killed Meltemi?

Well it was a massive pileup of several things. We have now heard changing design, untested hardware, repeatedly broken database, lack of central coordination, poor testing,… but those were just the internal issues. There was another mess outside that.

February 11th 2011 Stephen elop said that Nokia would eventually ramp down Symbian and would not pursue MeeGo. It killed the developer interest in Qt literally in one week-end. People I had seen reading Qt guide in previous week were studying Silverlight on monday. I’m not kidding. The ecosystem Meltemi was supposed to ride on got shot in the leg so bad it never recovered. And since Meltemi project got delayed by additional year, the mobile Qt ecosystem eventually pretty much vanished.

Another problem was Android: it outgrew Symbian as the largest smartphone OS in Q4 2010 or Q1 2011, depending on the source. When Meltemi was killed Mary McDowell said that Nokia management was unable to predict the speed at which cheap Androids were going to eat away the feature phone market and that caused many parts of the Nokia’s early 2011 strategy to fail. The book “Operaatio Elop” quotes Carolina Milanesi from an interview. She said that Meltemi phones at price of $100 would have been too expensive as there already would have been cheaper Android phones with full Android ecosystem available.

Also according to the book “Operaatio Elop” Nokia management did some queries on Meltemi state and schedules after the Ulm3 was over and its results were visible. I can confirm this. The query results were that in its current state project was not going to ship a single phone before first half of year 2013.

Nokia Board weighed their options. Results can be guessed from the fact that at the end of May several higher level managers stopped attending project status meetings. Two weeks later, June 14th 2012 Meltemi wiki pages were locked, source code version control frozen. We came to work and realized that we cannot access any of the project data. Info session from that morning told us that the project will be killed. Meltemi was employing over 1000 people around the globe (all parts of the chain combined) and collective cost of the project (personnel, equipments, travel, premises, marketing that should start soon etc.) was coming close to a million euros per day. On top of that Nokia would have needed to build a new ecosystem from the scratch and that had already been proven extremely expensive by Microsoft/Lumia. Meanwhile Smarterphone investment was going to produce improved feature phones soon and with less costs so Meltemi was killed and Smarterphone was kept.

I have mentioned the mandatory 1 second app start time requirement often during this text. There is a reason: as said, there was no multitasking for QML apps in Meltemi. So I present you quite normal scenario:

My friend sends me a text while I’m browsing a web page. I’ll swipe away the browser and go to recents where I tap on the notification. Wait 1 second to open messages app. Decide to reply with a photo. Tap on “attach” icon. Wait 1 second to start Gallery. Pick a photo. Gallery closes. Wait one second to load back the message editor (it got killed when I went to Gallery, remember?). Choose to add another recipient. Tap the plus icon. Wait one second for contacts. Choose a contact. Wait 1 second that editor reopens. Press send. Messaging closes. Swipe up for “multitasking bar”, tap on browser. Wait 1 second for browser to load. Continue from where you were.
With proper transition animations those seconds are not as bad as they sound and the UI feels fluid.

However there is a limit. Ask yourself: How long delay you can allow before it becomes annoying? From experience I can tell 2 seconds is already too much, but would 1.5 seconds be too much already because the phone would feel laggy?

At end of May (two weeks before the project was axed and most probably the time the decision was made) I had in my desk the performance test results from Clipper HW. 60fps graphics had been achieved in scenarios where database was not used (unfortunately it usually WAS used). QML app containing only one rectangle – simplest app that you could make – got started in 2 seconds. I repeat: empty application with no functionalities or database calls whatsoever took 100% too much time to start. The fastest of the “real” apps got to its opening screen on display in just a bit over 3 seconds. It was Music app and it probably achieved it thanks to the music player task that was running in the background feeding it the data. The worst performer managed to take over 6 seconds to start.

I know some disappointed people later said that Meltemi was “almost ready”. With all due respect to their disappointment: the prototypes of the product to be used in launch were not available in required quantities, the app times needed up to 80% to be cut off and the actual features sure as hell were not all there. Teams were asked for the estimates for feature complete. Those extended to end of December 2012 and even beyond for some teams. After that there would have been bug fixing and optimization period.

In the end it was Mary McDowell who was seen responsible of the failure and who had to resign. When she kept her farewell speech she thanked all the hard working people across the globe and literally cried. Stephen Elop said to us in an info session thatMeltemi had evolved into a project that tried to create a new smartphone OS and that was not the original goal. (I assume Nokia management would have wanted a upgradeable feature phone in one year, not a platform in 3 years.) Elop also said that it was a difficult decision for Management because by abandoning Meltemi they knew they won’t have cheap smartphones in their portfolio to fill the gap between feature phones and cheapest Lumias. He said they did a conscious decision to abandon that market becauseMeltemi failed and no plan B existed.

Now all the fans ask if anything was saved? Oh yes:

Asha OS stole a lot of the Meltemi UI. So did Nokia X. As did Jolla, by acquiring Meltemi employees and using Qt5.

One of my favorite apps (and one of the key selling points in first Meltemi phones) was called “Journal” (although it probably would’ve been publicly named different). It was ultimate employment of the JSON DB: Take a period of time – e.g. last weekend – and the app will automatically create a timeline consisting of everything you did within that time: Calls, texts, photos, calendar events, social network status updates, contacts you added,… You can then remove unwanted content and after that you can export a “postcard” – photo consisting of random content from the timeline out into a very artistic layout. Profile photos of the few people you interacted with the most, some of the most shared photos, perhaps the social status update that got most likes. You could share it to social networks or regenerate it (you never would get two identical postcards due to randomness of it).
Some of that evolved to Lumia Storyteller, except it generates videos instead of postcards.

As a closing I’d like to straighten out some myths I’ve encountered relating to Meltemi. The conspiracy theorists present Meltemi as some kind of small side project that big bad Elop killed just weeks from the launch when he found out it would be a threat to MSFT/Windows Phone. That theory needs a lot of tin-foil to your hat.

Let’s start by the fact that Elop really sucks as a Microsoft-planted mole. The book “Operaatio Elop” already pointed it out that they interviewed over a hundred Nokia employees from bottom to top and met NOBODY who would’ve implied Elop was Microsoft mole. My observations on top of that:

• -Elop did not push MeeGo out in early 2011 with Dali UI and N950 form factor but instead let it develop to the award-winning combination of polycarbonate shell and swipe UI. If he wanted Windows Phone to shine he would’ve done exactly the opposite.
• -In 2012 Elop refused the Microsoft proposal the Nokia would brand their WP8 phones with “Windows Phone” branding and demanded that Nokia sticks with Lumia. (Seriously, what kind of Microsoft man is he?) Afterwards Microsoft made the same deal with HTC as Nokia refused.
• -Under Elop Nokia rejected MSFT original buying offer for Nokia D&S because the price was too low and demanded that Nokia will keep the patents. If nothing else, that tells Elop is the worst double-agent in the history.
• -Elop gave Meltemi a high priority in Nokia strategy. The best and smartest of Nokia minds were hired to the project.
• -While other projects tried to cut costs and personnel, Meltemi increased both and it was fine.
• -Every time there were layoffs, Meltemi got instant and automatic immunity from top management.
• -When everyone else tried to decrease travel budget, Meltemi didn’t seem to have any cap on its own travel budget.
• -And as a last straw: Elop visited Meltemi R&D several times, always eager to see latest progress.

I said it earlier that when Meltemi was killed, Elop said there was a gap in portfolio. Nokia did not lay off all of those smartest and brightest of Nokia minds – instead in the same summer 2012 they hired some of those to two internal projects. One was the Smarterphone initiative that produced Asha OS. Other was Nokia’s first Android project that produced Nokia X. Nokia knew that after 2013 they would be free to ship Android phones so Elop wanted to have a lineup ready. I’ve also heard rumors that these people already had stock Android booting in Lumia HW by the time MSFT finally bought Nokia D&S.

So Elop definitely sucked as a CEO, but he was even worse as a planted Microsoft mole. 😉

I said that the best and smartest of Nokia minds were hired to the project. That can be seen from the fact that Meltemi employees were quite sought after resource. After the layoffs they got quite quickly employed by BMW, Google, Jolla, Rovio, Samsung,… The people laid off from Symbian had much harder time to find employment.

Category: Nokia