Veeery diverse discussion. I guess that's good. I cannot touch on all the issues, but let me raise some up.

- Naturally I'm/we're not trying to say that there is no room for improvement. Things will improve, in Harmattan and in future. The original question was kind of phrased over what is right now available in the 1.0 Fremantle SW release, and I tried to answer that question, based on the realities at the same when that solution was designed. It's not "take it or leave it" for the future. Naturally the whole idea here is to be iterative, listen to customer feedback and react on it.

- On direct communication with customers. Well, there shielding designers is mostly a good thing. If we would do what everyone would ask of us to do, we would be going nowhere fast. We - as in Maemo, I cannot vouch one way or another for other parts of Nokia - have good processes in determining requirements for applications and features. I can come up with a thousand requests from thousand different persons on what more should be done. Having a process to manage these requests is a very good thing indeed.

- Yes, there would be good ways to provide filtering for the missed calls list. If it would be there, some people would use it. Don't worry, one day Maemo might be just as bloated as Symbian in terms of the amount of applications as well as the amount of features within each application. Symbian pays the price for having a great number of features. The more you build up, the bigger of a giant you turn up to be. It's an elephant, and elephants do not run as fast. Maemo hasn't yet been an elephant, or a nuclear bomb, it on some terms has tried to be more something like a cruise missile: agile and accurate strike, a one-size-fits-all rather than a all-sizes-for-all-targets solution.

- UI consistency. Naturally it has been a highly iterative process. The rulesets changed many times during the process. When new needs came up, they rulesets were altered. But no, I don't believe that the best process would be that each time one individual app. designer is not able to do something within a given ruleset, then the UI style or ruleset should be automatically adjusted. It's much harder to say no than to say yes in these scenarios, but only by saying no you can get some kind of consistency. Constraints in the UI style create consistency.

- +1 to benny1967's post.

- The end users are always right, in the same way as customers are always right. We have heavily invested in end user testing throughout the design process. Every app is tested, at the end of the day multiple times.

Forums like these are not end user testing. They are the opinions of a very vocal minority, in terms of the overall total user base. Please do not fool yourselves that there would be always an automatic link between the opinions of a vocal minority and the opinions of a mass silent majority. There is not. Sometimes there is, sometimes there isn't. That's an observation that comes after observing endless user tests (with the "real users") and comparing their results and comments to the opinions on forums like these.

This is not to say that the opinions here wouldn't be very important. They are, but more in the style of lead user data, tech. leader data, early adopter data. To simplify the whole topic a great extent, things become mass market after they are "extremely simple" (yet extensible and scalable) to expert needs.

- Yes, everything that you ask and every feature that we would have said yes to, things would have come out a bit later, and the device might cost more. Ask yourself the painful question of which is more important: getting the product out, or taking more time to do feature X. No, you cannot have both. Yes, I know it's painful. Yes, these were the questions that were asked here some year ago.