As an internet tablet... not a client for an an app delivery system.
Again, it is a question of priorities.

Transition animations hide a lot as well...
EDIT: I see ARJWright pointed this out a page back. These are some of the tweaks and optimizations I spoke of earlier.



We are just now seeing other manufacturers and OS's embrace the internet tablet with mobile internet anywhere that Nokia focused on 4 years ago.
When it is all said and done pinch to zoom might not have been as necessary on a higher res display, the iPhones eventual shortcomings may very well become it's browser and screen resolution.

5 years ago a lot of the iPhones customer base still didn't fully understand the importance of, or utilize the potential of the internet in their own dang homes let alone a mobile device.
Nokia's 770 first provided the platform for a fully functioning browser. J2ME had been around for almost 10 years then as an app delivery client and it went nowhere.

What Nokia and anyone else didn't understand then was that the customers were there but the carriers and providers controlled what platforms the apps were to be delivered to. Sun as well as the carriers also wanted to big a piece of the revenue pie.
A fart app in JAVA would have sold just as well in terms of saturation 5 years ago to users of JAVA enabled phones as it does today on an iPhone. It would have pro'ly been easier to code as well.

I think this is what Jobs saw and the iPhone was designed as a client for iTunes. Nothing more.

The corollary to all this would be the question: How come my wifes iPhone can't display all the sites my N900 can and why is there no Flash?

Predicting what customers will want is a difficult thing. Giving them what you want is a hell of a lot easier.

BTW, I'll now try my predicting abilities:

I predict some knucklehead will follow this post with some sexist comment regarding my wife and her choice of phones.

How did I do?

YOU LET YOUR WIFE GET AN IPHONE??????????? wow, what a man

apple has the advantage of having their own OS they can mutilate to use on their different devices. and a smooth user interface is somewhat apples trademark, amongst others.

also, the iphone is not an open device like the n900, so they can fasten their seatbelts as much as possible to squeeze out the last bit of performance there is.

how is it a question of priorities?
are there any disadvantages of using transitions?
it makes things look better or smoother while hiding obvious loading times (or at least make them look non-existent)

i dont see why anyone would not want to use them.
maybe i'm missing something...

Have to admit I didn't read the whole thread, but I'd say iPhones fluidity has way more to do with software and how it's implemented than hardware. Wrt Nokia I'd guess it's not like they don't know _how_ to do it, the problem was how to do it without breaking everything they had at the moment and the bulk of third party stuff in the process. They are now making that break by moving to Qt with Harmattan(GTK+/Hildon to DirectUI) and Symbian^4(Avkon to Orbit). I'm pretty confident we'll see big improvements in "fluidity" in the future.

[QUOTE=msa;548364]The first line in my post is the question of priorities. Internet Tablet or iTunes client.
(I've now edited the post to make that clearer.)

To understand how transitions can make things appear smoother see ARJWright's post a page or two back.

So... if you want fluid over function you devote resources to it. Optimized transition timing is just one trick.

If you want function over fluidity, you devote resources to that. Judging by all the pre-launch videos we saw I think it was evident what Nokia devoted resources to. Every one of these videos spent a lot of time showing the screen with multiple apps running concurrently.

i love you guys at maemo and eventually MeeGo. really enjoyed reading this thread, very good points and well constructed too.
I really hope MeeGo succeed because everybody using an iPhone in 10years time will not be healthy.
As a beginner in developing i have found that apple make things for everybody involved (devs/customer/3rd party) very easy and i think Nokia is going that way too, just hope it isn't too late.
if Nokia can improve their awarness in the US we will see more devs for MeeGo and more people round the world talking bout Meego.. the US in effect own the Tech media.

back to the main point.. after ahving used phones on every platform i think MeeGo has a good future all it needs is a massive massive push. i mean every bloody second ad on every channel is an iPhone ad.

also way is Maemo so dark? while the iPhone is bright.. don't Nokia Know colours can effect moods.

i have goe of track sorry..

loving this thread and i hope Nokia is reading this.. there is some very clever people in this community really gunning for Meego to succeed Nokia all u have to do is make this much much easire so even the beginers can join in the Meego push.

sorry people for completly going of track, just got back from a night out, am abit tipsy and instead of shagging my bird am on my N900 ready the Meamo news and forums.

NOTE: sorry for the poor spelly. am tipsy, dyslexic and am posting the N900 which has no spell check in the browser

I won't speak to the finishing touches that give an iPhone OS device that silky smooth organic feel. If other optimizations are taken care of, certain things should just be a matter of parameter tweaking. Some of which Nokia just hasn't done yet. But even though 3/5 less pixels can't be swept under the rug, as well as the responsiveness of a capacitive screen, I'll forget about some of the differences and try to stay on topic.

A month or so ago I was doing some graphic stuff in Python and I wanted to see how often certain events occur. I was moving gtk.Images inside gtk.EventBoxes around a gtk.Fixed container, and on average, with normal movement, X was signaling about 40 non-linear gtk.gdk.MOTION_NOTIFY events a second. For what I was doing it looked and worked great. But if it didn't, I had plenty of room for optimization. All I have to do is fool the human eye. If I were to turn off gtk.gdk.MOTION_NOTIFY events and run my own linear timer at anywhere from 25 - 30 fps, I could reduce processing by somewhere near 30%.

Presently, I'm creating multi-column GTK scrolling tree views with mildly complex text and image rendering in C. Again, stand alone it's looking good, but because of the flexibility and power of these data structures, it's easy to get yourself into a compute intensive situation quickly. Throw in the frequency of the signaling I mentioned above, and it should be obvious that some default behavior might not be optimized.

If you know the history of the Macintosh, then you know it's always been about the UI. The original rendering code was assembly language put into firmware! Quite the opposite of X. To this day, a normal application on a normal Mac can't display it's output to just any ol' frame buffer. But X has been client/server based from the beginning. That too was 1984, yet philosophically, they've been polar opposites.

I also program in the iPhone OS environment. And I can verify how some of the application launching and monitoring work. There's good stuff going on there that has yet to permeate mainstream GTK development; I can't yet say for Qt. For example, the iPhone OS will proactively send signals to applications, suggesting they free up memory caches. Maybe something multi-tasking handheld OS's might want to do. Remember, we've inherited a desktop platform, but there's no need to cut corners. With the combination of MeeGo and Qt, these types of issues should become much higher priorities. But at the same time, we can't trivialize that some of this stuff might go all the way down to the kernel scheduler.

Out of respect for the OP, and there being no need for redundancy, I won't mention the trade offs of using an iPhone OS device. But as far as I'm concerned, the future looks bright for a silky smooth organic Linux. And as much as a resistive screen will allow, that should include the n900.

I've tried the multitasking on iPhone and its horrible. Firstly, let's get things straight, it isn't really multitasking but instead suspending the application until you get back to it, however after 2 or 3 applications open, performance really degrades, the phone heats up and battery drains ultra quickly. I would say twice as quick as the N900. I had to uninstall Backgrounder in order to get the phone back up to speed.

The N900 is a true multitasking monster vastly superior to any other pseudo-multitasking phone out there.

Oh, not sure if it's been mentioned, but there's no swap space in the iPhone OS. This is a major difference to the default configuration of Fremantle's 750 MB. Disabling swap could be an interesting place to start to try and get some apple to apple comparisons.

Yup, disabling multi-tasking too... because that will require swap.