by Malcolm Rowe

The new shiny

I finally got around to picking up a decent phone recently. No, not one of those, nor, cool though it would be, one of those. I went for something a bit more mainstream: a Nokia 6120c. And it is shiny.

My last phone was a Nokia 6822, with a gull-wing QWERTY keyboard. I really liked being able to enter text at a sensible speed, but I didn’t like the basic and slow (though stable) Symbian Series 40 operating system. I also didn’t like the way the flip-out keyboard part broke a few weeks ago, so I decided to do something about it, and get myself onto a decent data plan while I was at it.


The phone itself is really nice: it’s small, light, does 3G and HSDPA (though realistically I don’t get anywhere near the quoted data rates, more like 500–900Kbps). There’s been a fair amount of discussion about battery life for 3G phones (compared to EDGE/EGPRS), but I can’t say that I’ve noticed that the battery life on this phone is particularly short: I am charging it roughly ever two or three days, but then I’m also making what I’d consider pretty heavy use of it — I’ve downloaded nearly 300MB in three-and-a-half weeks (though about half of that was (re-)downloading a couple of large podcasts, I think).

There’s a bunch of little features on this phone that I’m probably not going to use, like syncing, multimedia messages, or video calls, but one of the things I will be using it for is as a storage device: it comes with a regular mini-USB socket. Plug it in and the microSD card appears as a USB mass storage device, no messing.

There’s also a camera (two, actually). I’m not sure why they bother, but apparently you can’t sell a phone without a camera nowadays. The pictures it takes are okay (see below), but I think I’ll be sticking with my Canon.

A view from the railway tracks; Ansel Adams I’m not


Unfortunately, you can’t (cheaply) get hold of a phone in the UK without getting it via the carrier, which gives them a chance to mess the phone up so that it’s unusable when you get it (or, as they would call it, “branding”).

On the whole, T-Mobile’s customisation isn’t too offensive, with one exception, which I’ll get to in a second. They’ve replaced the “web” icon with one called “web’n’walk” (their data plan), and they’ve defaulted to a theme that’s actively hard to use; I can live with the first and switch off the second.

What I can’t fix is their abuse of the browser’s bookmarks. They’ve added 20 pre-defined bookmarks to the list. 13 of these relate to various points on their t-zones mobile portal, to a Google search, and to what they’ve set up as the default home page. Anyway, these bookmarks I can manage as usual. However, seven of the predefined bookmarks are immutable: I can’t delete them, and I can’t even move them out of the top-level bookmarks folder. These also point into the t-zones portal, to the parts that allow you to download content (for money).

The fact that I’m stuck with a bunch of useless bookmarks that take up an entire screen makes me rather annoyed. What possible benefit to the customer is there for creating bookmarks that can’t be deleted? It reminds me of something from the original mozilla/browser manifesto (for what would eventually become Mozilla Firefox), referring to Netscape’s then-practice for filling the bookmarks and toolbars with access points to their properties:

6. The personal toolbar is the personal toolbar, not the whorebar.
Blake Ross, Firefox README-1.1.html

Even AOL/Netscape never went so far as to create undeletable bookmarks, as far as I remember.

Surf the web

Anyway, the main thing I’m using this phone for so far has turned out to be not voice calls, not text messages, but web browsing. So I was pleasantly surprised to find that the built-in Nokia browser is based on a Series 60 port of WebKit (the same engine used by Safari), rather than one of the less-standards-compliant browsers that have been present on mobile phones I’ve used in the past.

All’s not perfect, though. While Nokia and Symbian have inherited a great web engine from WebKit, they haven’t spent as much time making a great mobile-phone web browser. The browser isn’t bad: it supports a nice ‘overview’ pane that fades in when you scroll around the page (demo here), you can rotate the screen to view pages in landscape mode, and you can use it as a feed reader if you desire. It’s the things it doesn’t do that are annoying.

In the spirit of trying to “Experience true Web”, Nokia (like BlackBerry before them) have tried to stick a desktop web browser onto a 240x320 screen, rather than provide features that are useful on a mobile phone (Adobe are also guilty of this: the bundled Acrobat reader would be great if it weren’t for the fact that it offers nothing more than a big scrolly window to read documents in).

So there’s no support for access keys, which aren’t really used on the desktop web, but are used heavily on mobile-optimised sites (see e.g. YouTube Mobile; scroll to the menu at the bottom). Perhaps more critically, the browser doesn’t make use of ‘handheld’ CSS stylesheets, so if someone has bothered to make a stylesheet optimised for display on a small-form-factor device (as I’ve done for this site, for example), you won’t see it.

There are other problems that are exacerbated by the mobile context: there’s no cache of any kind, so going back reloads the entire page (and HSDPA notwithstanding, it takes at least a second, maybe two, before any page starts to download, so this is a real pain). Finally, there’s no way to resume a download, so if you are planning to download a large file (like a podcast), you better hope you have a reliable connection.

It’s a pity, because it could be a really nice mobile browser. Interestingly, it even pretends to be Safari in the user-agent string. Check out this monstrosity of compatibility tokens:

Mozilla/5.0 (SymbianOS/9.2; U; Series60/3.1 Nokia6120c/3.70;
Profile/MIDP-2.0 Configuration/CLDC-1.1) AppleWebKit/413
(KHTML, like Gecko) Safari/413

Bundled applications

So one of the things I have tried to use the phone for is listening to podcasts. It’s actually not too bad — the built-in music player is quite smart, and it displays a status line on the idle screen to show you what’s going on.

There’s a small oddity in that the music player has the concept of a ‘Music Library’, and you can’t see new audio tracks until you’ve refreshed the library (and doing so is far from obvious: Options⇒Music library, then Options⇒Update Music library); this is true even if you’ve just downloaded the track via the built-in browser, which opens the music player itself to play the track (the player even says “so-and-so saved to Music library” as it’s exiting! It lies!).

But the biggest roadblock to using this player to listen to podcasts is that it doesn’t support any kind of seeking, so if you’re halfway through a 30-minute podcast and hit stop by accident, you’re screwed (unless you really liked listening to those first 15 minutes).

Another thing I’d like to to is keep track people’s birthdays and anniversaries, since I’m rubbish at remembering them. Annoyingly, the standard applications are almost able to do this, but not quite: you can record a birthday against each of your contacts, but it’s not visible to the calendar application. Even more annoyingly, you can enter an anniversary date for someone (say, 1976-02-14) and it will remind you every year, but it won’t provide any way to find out how many years have passed since that date (it just shows the event with the current year).

Third-party applications

If I was just using the phone for the web browser, calendar, and music player (oh, hey, and making phone calls), it wouldn’t be nearly as much fun. Fortunately, the phone can run downloaded applications too: either Java MIDP2 applications or native Symbian applications.

There’s not a lot of difference between the two types, by the way, since both have access to a lot of the underlying phone capabilities — the Symbian applications natively, and the Java applications via a variety of extensions to the MIDP2 basic platform (JSRs).

The one really noticeable thing that shows up a Java application is the use of full-screen text input boxes: it seems that MIDP doesn’t provide any way to get a ‘native’ (T9/user-dictionary-aware) embeddable text input widget: as an application developer, you have a choice of either a full-screen TextBox or an embeddable TextField, except that the latter can only be used inside a full-screen Form, which is limited to using simple controls — so you can’t use it on anything but the most basic of screens.

Anyway, these are the applications I’m currently using on a regular basis: