How many fingerS ? I just have my index fingers on the back, middle fingers holding the bottom of the NIT, and since the keyboard is a little to the right, the right index is higher, hence no overlap.

I used to hold my N810 with my middle and ring finger partly curved and pushing their points into the back of the N810, my index fingers close to the top of the N810 (or the top of the back, if the device was open), and my pinky fingers sort of acting as a slight base for the bottom of the N810 to rest upon (but not a lot of weight on them -- they were more preventing incidental downward movement of the N810 to keep it form slipping out of my hands; the weight (what little there is) was largely supported by my palms along the sides of the back, and the sides of the device, pressing in a little). Which is also fairly similar to how I hold my G1.

But I never had discomfort with my thumb reach on it. My discomfort was from the fact that the keys were too stiff, and didn't have a decent tactile feedback/feel for when you had successfully pushed a key. Which is odd, because Nokia qwerty phones seem to get that part right (the E61i was decent, and the E71 is excellent, in this regard; but the N810 is awful in this regard).

E65 is not too bad, but its PVC skin layer is of POOR durability!
Peel off easily!

Rather unstable.

Sliding also poor strength and hang easily.

That's about my E65.

It was A COMPLETE FAILURE FOR NOKIA wasn't it?
I am so looking forward to my next better phone.

Many fabulous mobile gadgets in Korea and Japan, but not sold overseas. SAD!!!

Same screen size.

My reflection.

It's been a while.

Anywhoo.. Now that the hardware is final, I think there's still room for wishing on the software front. I won't go into the obvious wish about portrait mode. However, I will wish for something that I think is far more significant.

A Gears (formally known as Google Gears) extension for the web browser.

Gears is a technology designed to give online applications many of the same advantages shared of natively installed applications, in a very simple and non-intrusive way (similar to the upcoming HTML5 spec -- today). These include:

1) Offline storage of data. Data can be stored in an SQLite database offline as per the users permission.

2) System notifications. This allows the application to notify the system that something has happened.

3) Offline document/data serving. This mechanism can store the actual app, as html files and javascript files can be stored. Additionally it has expanded to include binary data (BLOBS).

4) Background worker pool. Basically a set of Javascript Objects that exist and execute outside of the page (for a given app/domain) and between page changes. Once registered, these can improve performance.

5) Geolocation. Using in-built hardware, or the estimated position based on the WiFi AP, location can be used as a part of any application.

When you mix all of these together, what you get is the potential to make an online application run very closely to that of an offline application. The major advantage here is an INCREDIBLY low cost to entry as applications do not need to be 'installed' in the traditional way, and can be tried as easily as navigating to a web page!

With the recent advances in the browser including the general javascript performance, the canvas element, etc. There are sufficient features to service a great number of applications. Including flash into this equation furthers the domain-of-usefulness.

Online development provides not only a low-cost for entry of the user, but the developer as well. Many apps can be prototyped rapidly, and improved gradually as time goes on. This equates to MANY MORE APPS and MANY MORE DEVELOPERS. Moreover, these apps are extremely write-once-run-anywhere apps. Lastly, while Javascript may be considered a muddled language, it is extremely powerful and very flexible if one adheres to good design principles (much like C).

It's of worth noting that online apps with gears do not NEED to be apps as services. In fact, a complete app can be contained in a set of pages, and the data stored completely offline. In this scenario, the app may be built to poll the the server for updates rather than requiring the server to run.

It's not all roses and bee-bottoms, though. There still are many things that native apps do better. However, when one considers twitter clients, messaging, maps, document creation, and a multitude of other apps that can be represented in this environment, its easy to understand that online development provides a very future-focused and attractive alternative to traditional offline tools.

I would *really* like to see Gears on the N900. It's a bandwagon worth jumping on.

}:^)~

I second that. I'd like to see Gears for Maemo.

And, on the "lets talk about software we'd like to see" front:

I'd still like to see a full SyncML implementation, _at_least_ for syncing contacts and calendar to SyncML servers/services out on the internet. GooSync for Google contacts and calendar, and Oracle Calendar for work calendar data are the servers/services that are particularly important to me.

I would like to see something like this as well.

I must be missing something. Assuming that SyncML is an XML based protocol, why is it so elusive on this platform? Certainly a user-program or daemon could be easily created for periodic manual/automatic syncing. Am I missing something? Is it just one of those things that should be done, but for whatever reason, is left by the wayside?

I see this being a tremendous value, and a very large selling point for the device.

}:^)~

Oh, Maemo 5 is going to have SyncML.

For syncing via USB and Bluetooth, to your PC.

Useful for syncing to your Windows-only Nokia PC Suite type application. Completely useless to anyone else.

Why would we not be able to use a 3rd party SyncML client (and even server) besides the default one? I had a look at SyncML at Wikipedia. Seems libsynthesis and OpenSync are the most complete, and open source (C/CPP). The nice thing about OpenSync is the many plugins, and given Qt is next and KDE has good PIM (Kontact)...