Fishpool

Earlier today Nokia announced their first handset based on what is likely to be their mobile operating system of the future - the Nokia N900 Maemo. I didn't think I would bother to pay attention, but somehow, I ended up doing so anyway, and this post is a result of that time spent thinking about it. I like quite a few things about it, but can't avoid being deeply bothered by other aspects. I hope by writing this I can make some small contribution to its future.

Why do I care? After the frustrations and disappointments with Nokia devices in the past years, I've tried not to. However, they're impossible to ignore in Finland, I have family reasons to hope this road leads to something good, and it's an attempt to make an open platform -- and I care about open platforms. Why do I feel qualified to comment? Well, because this is not really about devices, it's about software. And software is what I've always done, and managing software organizations is what I think about daily.

There's lot to like about the N900. I haven't seen, let alone played with one, but as far as the specs go, it's a pretty nice set of hardware. Same performance as the iPhone 3GS (which also makes it faster than any Android device announced), 3D acceleration, lots of storage (and a memory card slot), and, as a welcome change from many other Nokia devices, completely standard connectors (3.5mm audio, micro-USB tethering and battery charger). On the hardware side, the only thing not to like about it is the lack of a finger-usable, multi-touch display. This device, like all the other Nokia devices before it, require a stylus or at least long fingernails. It makes up for that by being really high resolution.

It's also based on an open source, Linux-based operating system Nokia has been developing for several years with community participation, Maemo. This makes it more attractive to me on a personal level than iPhone (which is way too closely guarded and controlled by Apple), Palm WebOS (open, but little track record), or even Android (open, but built out of pieces which have far less common with normal Linux than Maemo). It should be fairly clear that all four mentioned are way ahead of things like Symbian S60, which clearly needs to be taken behind the shed and put out of its misery, not matter what Nokia's representatives say about it official capacity.

On a more professional level, the inclusion of Flash 9.4 in the platform is a big deal. I'm anxious to get hold of one and see how much work it is to make Habbo work on it. This could be the first handset capable of technically running it (enough performance, enough resolution, good enough software), though obviously tuning our service to a mobile device would still need work on UI and other pieces.

However, like I wrote above, there's also plenty that bothers me. First of all, unlike most people probably realize, this is actually the 4th Maemo device in about as many years that Nokia releases. First was the Nokia 770 Internet Tablet, essentially an early adopter test device. Then came N800 -- running an updated OS which required applications to be ported to it, but which never was officially released for the 770 (putting the early adopter developers in a rather awkward position). Less than a year later N810 added a physical keyboard and an OS upgrade (which fortunately could be installed, with some difficulty, on the N800). That was quite a long time ago, though.

In the meantime, Maemo has been completely reinvented. The original UI toolkit has been switched to QT, which Nokia bought in the meantime, and all of the (rather limited quantity) applications require significant rework to be compatible with the OS release on the N900. The public reasoning for this compatibility break has been pretty weak -- "to ensure compatibility with S60", which also is moving on to QT framework. Why is this weak? Well, because the transition over on the S60 side also requires all of the (somewhat more numerous) applications developed for that platform to be significantly reworked. In other words, Nokia broke compatibility on both its old smartphone platform and the new platform at the same time, and offered little transitionary compatibility layers to either side. Not for the first time, either. S60 applications have been broken between upgrades several times before, too.

This track record is highly worrying. Despite their years of practice and ambitions to have a lively third party mobile applications market, Nokia has clearly not grasped the importance of a stable platform to the developers they mean to attract. This lack of understanding of one of the most basic requirements is enough to counter pretty much everything I wrote about Maemo versus its closest competitions a few chapters earlier.

Contrast the above to iPhone OS 2.0 to 3.0 transition. Sure, a few things did change. However, developers were given months of notice ahead of time, and the changes, apart from added functionality, were all pretty minor. Of course, Apple has a long history of making major upgrades while retaining forwards compatibility, with the Mac OS 68k to PowerPC, then to OS X, then to Intel CPU transitions.

It's also taken a LONG time for this device to be announced. I don't know, but I get the feeling it's something like a year late. The break in launch schedule between N810 and N900, the amount of changes in the Maemo platform, and the design of the device compared to for instance the N97 all scream "last year" to me. Besides, everyone knew this was coming ages ago. In the time between the launches of N810 and N900, Apple has managed to update the iPhone twice. This lack of predictability in the release cycle doesn't bode well for the next device in the line.

There is nothing more important for progress in software development than cycle time. The only cost-effective, productive way of making software today is to get feedback on it often, and the longer it stays unreleased, the more the feedback is late when it comes. This seems to be another area where Nokia has not been able to shake off their "we make hardware" mentality. Unline hardware, software can be updated with no extra cost. That's an advantage nearly everyone else has learned to make use of, and Nokia, if they truly desire to become a software and services powerhouse, has to finally take to heart.

N900 is not an "iPhone killer". I don't think it's meant to be. When its development started, it's unlikely the iPhone had even been announced. However, it's the best chance for Nokia to ever develop a device better than an iPhone. I hope they will - the world needs competition, and I would like to see Nokia be part in that. However, at this rate they will never catch up - Apple will have released two more major updates before the next Maemo device unless Nokia gets their act together.

I'm still hoping.

Maemo Mapper has a few displays in addition to the primary map information. It can overlay the map itself with routes, tracks, and points of information, and show the current speed as well as way-point directions over the map. It also has a secondary display of GPS position information, including altitude and compass.

However, it's missing a couple of critical displays; the distance to the next way-point as well as to the end of the route, and an estimated arrival time to the end of the route. The first two are simple to provide, and in fact are available through the menus, just not as a constantly displayed overlay. The third one can be tricky; the travel time may not be included in the route information, or it may be inaccurate. Estimating it from average speed is the other alternative, also vulnerable to errors when travel conditions change. However, providing some kind of estimate is still a useful service to the user.

The readability of the overlaid information is not quite ideal in the challenging in-car circumstances. The blue dot signifying current position is small on the high-resolution display, and difficult to see in sunlight. Making larger and animated (I would suggest a rotating symbol of some sort; keep in mind also the suggestion about scaling its size according to position accuracy estimate) would help. The speed indicator flickers; whether this is due to lack of double buffering or otherwise, it's distracting. Finally, the route direction dialog also changes shape about once per second, sometimes laying out the direction on one line, sometimes needing to place the last word on the next. Not surprisingly, this draws too much attention to it (hopefully not from the driver!) as well as requiring extra effort to read.

Maemo Mapper currently has three methods of downloading map data; the immediate, "show map of current area and detail level", and the two ahead-of-time modes, "download multiple detail levels of this region" and "download multiple detail levels along a route". The routes themselves are also downloaded over the Internet, from a gateway server performing a format translation.

The drawback of these methods is that along practically any route, especially one that takes the user through municipal areas as well as countryside or highways, any one fixed selection of detail levels is either going to be a big download and memory requirement, or leave the user with lack of detail in critical intersections.

I think it should be possible to improve from this accuracy while reducing the number of decisions the user is required to make. The route information contains a rich level of data about the general shape of the route. In particular, there are the way-points and the distance between them, and the route data on a turn-by-turn basis for display purposes.

Just by using the way-points, downloading detail maps on the way-points themselves, and a level of detail relative to the distance when between way-points, is this selection already made not just automatic, but also richer for the end user. By also utilizing the route shape data, detail level could also be increased when the route takes sharp turns.

Finally, if any points of interest fall close to the route chosen, it would make sense to download a more detailed map around that point.

If Mapper is used in the same area for an extensive period, it might benefit of keeping records of the tracks taken (with significantly lowered resolution), and utilize a similar logic to the above for also keeping detailed maps of the frequently visited places and nearby locations. Of course the user is already likely to be able to navigate in such an area without the help of extensive maps; perhaps this information could be augmented with data about where has she tried to access the maps.

As I mentioned previously, I bought a bluetooth GPS receiver for the trip so that traveling in Portugal wouldn't need to be a constant peering of maps. Since I feel much more comfortable with things I can tinker with, and because such an alternative to closed GPS software exists through Maemo Mapper, I chose not to purchase a commercial navigation software package at all.

For those unaware of it, Maemo Mapper is a program for the Nokia 770 and N800 Internet Tablets that interfaces with OpenStreetMaps, Google Maps and Virtual Earth to provide an Internet-connected map browsing and navigation package. It depends on (gateway-translated) Google Maps for route information, and otherwise functions by downloading maps to a memory card cache.

This is a pretty cool program, showing what might be the disruptive future for navigation and location guides in a cooperative, Internet-connected world. It's also one of the more usable applications for the Nokia platform. I wish the platform in general was as well designed for its primary purpose as Maemo Mapper is. If a way to share the track records and point of interest data with others is found, I feel this application might become a category definer. Great work by just one author, John Costigan.

We've spent the last week walking about in Lisbon, driving in the countryside hill roads, and navigating around in the Atlantic coast. While I've used Mapper on and off before to consult maps, on this trip, thanks to the GPS receiver, it's finally become a constant companion instead of a curious diversion. With this experience, I've also seen where it currently (in version 1.4) falls short of a perfect experience. As I write those findings down, I will post them here as suggestions.

Google Maps POI

I wrote a tiny Perl program to process Google Maps' new My Maps KML files to a Maemo Mapper POI database (download). This should probably be converted to Python to be easily installed to the tablet itself, but for now I simply ran it on my laptop and then transferred the database over.