Usability comparo: Nokia 6220 Classic vs. Sony Ericsson G700/G900

There have been a number of reviews of both the Nokia 6220 Classic and the Sony Ericsson G700/G900 twins. One of the better 6220 reviews is at The Register, while a comprehensive feature-list of the G900 is available at Mobile Me. If you want to read about the feature sets of these two phones, these are appropriate reviews. (Although Mobile Me gets the details of the G900's camera wrong, it is a 5MP autofocusing, fixed focal length camera with goodies like touch controlled focus area, and digital anti-shake. The G700 gets a 3MP fixed-focus camera instead.) However, I'm interested in usability, and it is on this basis that I want to compare the SE twins with Nokia's device.

Hardware and value

First, are these devices comparable? Certainly they are: in Australia I can get the 6220 on EBay for a little less than the G900, and for about a quarter more than a G700. How about in feature set? Well, the G700 is obviously the loser, but it's more than A$100 cheaper, too. The 6220 has a great camera, A-GPS, HSDPA and TV-out. The G900 counters with WiFi, and both SE's have a larger touch-screen. In terms of the physical packaging, I find the G700 easiest to use, with a good keyboard and joypad design, with the 6220 and G900 tying for second.

So in hardware terms, the 6220 seems to soundly beat the SE twins. However, this is where usability comes in. If you use even a subset of the 6220's capabilities (and I tend to use an awful lot of them), you'll find that the battery hardly lasts a work-day (ie. eight hours). This is borderline unusable for me, since the 6220 ends up not being a mobile phone. If you did a lot of driving and had a car-charger, this might be OK, but it's really an achilles heel for a mobile phone. It means I simply can't take my 6220 camping, or the like. For that I'd need the vastly bulkier N95 or the like.

There's another problem with the 6220: RAM size. After well over a year of large-memoried SE devices (P1i, G700/900), the 6220's limited RAM comes as a shock. Why do I have to go around and shut down applications to free up memory, anyway? Ridiculous. S60 is showing its seams here. The SE devices gain a huge usability advantage here (after the serious burning SE received on the P900 and then again on the P990).

Another shock was the network management. Why do I have to keep on telling applications which connection to use? And what on earth is this stuff about running out of connections? I've never seen that on UIQ, so it's clearly not a limitation of the OS. On the other hand, once connected, the HSDPA is fast, and has excellent reception (I use 3 here in Aus). But the G900's WiFi more than makes up for the lack of HSDPA. For a start, my ADSL connection is much cheaper than my 3 data cap, and for truly large things (like maps, podcasts, etc.) I really don't want to be paying for them. And the WiFi is faster (a bit). Finally, the G900 can automatically select WiFi when it's avaliable and fall back to 3G when it's not (something that requires 3rd party software on WiFi-enabled S60 phones).

So in terms of network connectivity the UIQ devices rule the roost (although the G700 probably ties with the 6220 due to the lack of HSDPA).

How about software?

System wide issues

S60 on the 6220 seems a little snappier than UIQ 3 on the G twins. This is particularly noticeable in, for example the Messaging app. While UIQ 3 takes a noticeable time to refresh its message list (about 0.5 of a second with a short list), S60 shows no refresh lag at all.

Both UI's have useless eye-candy effects that should be turned off immediately, since they don't help with usability at all. Both are deeply skinnable, which is both a positive and a negative.

UIQ allows each view of most applications to be zoomed (and the zoom setting remembered) to three levels. S60FP2 (feature pack 2, the version on the 6220), allows three levels of zooming across the whole UI. The UIQ approach is both theoretically and practically superior, though the S60 approach is better than previously (which had no zooming at all). In my experience, zooming is important to usability, since both eyesight and expectations vary considerably from user to user.

All of these phones have standard phone keypads, so a text input method of some type is required. The UIQ phones, of course, add handwriting and on-screen keyboards into the mix. The 6220 is limited to its T9 implementation. The superiority of the UIQ phones is amplified by the fact that many S60 applications inexplicably disable T9 in their input boxes. This drove me up the wall on S60 2nd Ed, and I can't believe such silliness hasn't been fixed! (For example, there are many input boxes asking for my name, eg. for an email account, which won't let me take advantage of the fact that my name is in the phone's T9 dictionary.)

Of course, UIQ isn't ideal, either. It's keypad input method has some truly frustrating quirks, such as the inability to guess at words (just refusing to accept more input, or reverting to digits), along with the crazy way the cursor won't go back into words (treating the whole word as an atomic unit and skipping over it). The 6220 also redeems itself with much better handling of a bluetooth keyboard -- the G twins force you to delve into Settings to turn off input methods all together. None of these devices is a patch on the SE P1i in terms of input.

Navigation and controls

Switching back to S60 after several years of using UIQ devices was not easy. S60's joypad/dual softkey navigation is clumsy, slow and frustrating compared to the richness of UIQ's navigation. It takes a while to remember all the S60 shortcuts (like the hangup key to go back to standby), and even then S60 is vastly inferior to the directness of UIQ. UIQ 3 really comes into its own on the G series phones, with their five-way joypad combined with the dual softkeys (which are present as both real and virtual keys on the G700 and virtual only on the G900) and back button.

Areas where I really appreciated the touch screen on UIQ 3, compared to S60, were:

• navigating around grid views (such as the main menu)
• marking items in a list (actually UIQ 3 implements this better even using just the keypad -- and S60 is worse than it used to be, thanks to the loss of the pencil key)
• scrolling through long lists (eg. emails), where touch allows dragging the scroll thumb
• activating on-screen status icons to bring up controls (eg. the bluetooth status icon on UIQ brings up the bluetooth app -- in S60 you have to dig into the menu, unless it happens to be on the standby screen; another good example is the camera applications with lots of on-screen controls rather clunkyly accessed in S60, but directly accessible in UIQ)
• Hierarchical menus (quickly navigated by finger, slowly via joypad)

In addition to these benefits of a touch screen, SE has added a very useful lock/unlock button.

UIQ 3.0's control set of two softkeys and a back button is much preferable to the lack of a back button on UIQ 3.3 (and S60). However, there's not much we can do about that -- SE's next devices where going to be lacking a back button, anyway...

Finally, in terms of controls, UIQ's method of always changing volume in response to the volume controls makes more sense to me than Nokia's "hidden" approach.

Screen layout, etc.

UIQ 3 and S60 have a lot of commonality when it comes to screen layout. They both use three softkey spaces (in S60FP2) at the bottom of the screen, a thin status bar at the top, and a thick application bar below that, containing icon, tabs or other view controls, and a title. Both can use these areas in various ways, though, as mentioned, UIQ can use them to initiate commands as well as showing status. (For example, DreamLife uses the application icon as a command button for a context menu.)

UIQ 3 introduced an incredibly flexible listbox framework (that I really hope makes into into the Symbian Foundation platform), which allows for two truly useful features:

1. Expansion of the highlighted selection. Thus the currently highlighted item in a listbox could have several lines of information, while the rest of the lines have only one (such as a title). This combines compact display of lots of information with details in the list view (without having to jump to the detail view). S60 has no equivalent, though the S60 application set try to compensate by allowing navigation between items in the detail view (using the left and right direction keys). This meets the second design issue (showing lots of details while being able to navigate between items), but fails at the first (showing many items).
2. Navigation within "slots" in the highlighted item. In other words, the highlighted item can show a slot which contains multiple items, which can then be navigated between using the left and right direction keys. UIQ 3 uses this, for example, to display all the contact details of a contact while still in the contacts list view. The user can quickly flick through the different contact details in the slot, and then action (eg. call or message) a detail right from the list view. S60 (in the latest E series devices) tries to emulate this with a right arrow "context menu", but this is a much more limited mechanism.

Apart from this difference, S60 and UIQ 3 end up acting fairly similarly (even though the underlying technology is quite different). UIQ 3 is a bit more consistent, but it needs to be, because its interface is a lot richer (and thus potentially more confusing).

Applications

Both platforms have a fairly extensive set of standard applications. The 6220 soundly trounces the G twins in application range, though, with the location-based apps adding a whole set of applications that don't even exist on UIQ yet. Nokia maps is pretty impressive, the 6220's GPS locks on within seconds from inside my house, and keeps a pretty good signal. So far the routing has been OK, though not as good as my car's GPS. S60 also supports podcasting natively (though on a WiFi-less device it's not really that useful to most). Finally, S60's web browser is pretty impressive, although the way that it interacts with Nokia's own services is severely sub-optimal (why does the dictionary app send me to a page that requires scrolling down and to the right in order to download what I wanted?).

But that's where the good stuff on the 6220 ends. Everything else is inferior to the G twins. The standard PIM apps are inferior (poorer displays, inferior usability, inferior feature set); messaging is inferior (no HTML rendering, no push IMAP, no way to forward bluetoothed files); applications are scattered in mysterious places on S60 and fragmented into pieces (eg. Nokia Maps, GPS data, and Landmarks are all separate applications, in two different folders); UIQ's browser works better at least half the time, especially with mobile sites; the G twins' office suite allows editing without spending another A$100; and S60 can't import multiple calendar entries or contacts in a single message, and neither can the PC Suite's editor, so how do you transfer data without loosing information to a sync database?

The overall impression I got from the 6220 was a profusion of features presented in a confusing and slightly flaky fashion (especially with how it interacted with the numerous Nokia services). Add to that the fact that the 6220 has frozen about four times in two weeks, compared to the G twins' two or so times in the last four months, and things don't look so good.

However, Nokia's PC Suite is much better than Sony Ericsson's, both in terms of features and in terms of performance.

The 6220 has some pretty impressive third party software, however much of what I've installed has equal or superior UIQ 3 versions. S60 is probably better in this area, but it really depends on your individual needs.

I was initially very impressed with Sports Tracker from Nokia, which uses the GPS in a very useful way (to track your movements allowing analysis). However, so far I haven't been able to get it to complete a trip without dropping the GPS signal. And once it's dropped the signal, it can't pick it up again without ending the trip and starting a new one (meaning that you have lots of chunks of incomplete data). Very frustrating, and this needs to be working before this is really a useful tool.

The lack of WiFi has really constrained me in many ways with the 6220, so I imagine the N95 would be much more useful to me, personally.

Conclusions

The differences between UIQ 3 and S60 FP2 are not merely cosmetic. There are some real usability issues with S60 that remain after several generations, which points to poor design understanding on Nokia's part. However, Nokia is able to put together impressive hardware at a good value price. They just need to work on battery life and RAM size, and learn a few lessons from UIQ (such as its listboxes and a straight-forward touch interface), and the Symbian Foundation will have a good foundation to work from (no pun intended).

Providing a clean, coherent set of applications for a Symbian Foundation phone shouldn't be too hard, but is an important oversight on Nokia's part. Apple's example of a simple, clean set of applications should be emulated, not ignored, and UIQ 3 does better at this at present.

In terms of which phone to use, I'm torn between the 6220 and G900: the 6220's A-GPS and location app's are wonderful, but its battery life and clunky UI are really annoying. The G900 is a lot easier to use, and much more flexible. I'll check back in a month and say what I've ended up doing.

Update: Music Player

Having lost my borrowed iPod 20GB, I've decided to switch to the G900 as my MP3 player. Thus I've explored the music player on these two phones a bit more. Here are my findings. This is actually a three-way comparison between iPods (mostly the non-Touch versions), the G900, and the 6220.

The G900 has two weaknesses in music playback:

1. Like all flash-based players, it has limited capacity, in this case to 8GB. Still, the 8GB is only A$90 or so, so it's quite cheap assuming you already have the phone (an 8GB iPod Nano is well over A$200). The 8GB can also be used as a memory stick later.
   The 6220 is exactly the same as the G900 in this area, except its card costs A$80.
2. The sound performance is not great. There's a distinct hiss behind all music (no high-frequency components, but it's quite loud). This is borderline, but given the benefits I'm prepared to put up with it (especially considering that my listening conditions are rarely ideal anyway). Also, there's no "gapless" music playback, which irritates me.
   The 6220 has better sound quality, but falls down by having a pretty weak volume level. Gapless playback is not supported by the 6220, either.

The strengths of the G900 are:

1. The music player component of the media player are excellent. The only missing feature is playlists based on genre (with the S60 player has). The ability to view, edit, and navigate around the play queue while it's playing (and even save it to a playlist) is brilliant. The cover view works at least as well as the iPhone's cover view. Other navigation is all quick, intuitive, pretty, and takes advantage of the keypad to allow searches, etc. I like the way you can operate on whole artists or albums, or drill down -- it's very powerful and flexible. Much better than the iPod interface (at least the pre-Touch version), and better, too, than the 6220's competent setup (with the exception of genre playlists).
2. The ability to use a headset from the W960 with my own earphones is great. The remote control headset from the W950 is even better. An adapter for third-party headphones is just as easy to get for the Nokia -- not so sure about remote controls, though. The two are equivalent in terms of bluetooth solutions (and substantially superior to an iPod).
3. The SE media manager software allows recoding when transfering files to the phone, which is very handy (esp. since AAC+ can get much better quality at the same bitrate than the iPod's AAC, and better also than WMA). Nokia's music transfer solution can do the same, but is substantially less polished (unlike the rest of Nokia's PC Suite), and less flexible. Apart from the encoding issues, neither solution is as good as Apple's iTunes (though iTunes inability to sync with multiple computers and its encoding limitations limit its usefulness).
4. Just carrying the G900 (or 6220) is much more compact than even a Nano plus my phone.

The Potential of Smartphones

So often in the mobile phone business, people have approached these devices as merely mobile versions of immobile technology. Thus the "mobile web", "mobile mail", "mobile phone", and so on. But what if we approached smartphones from the perspective of what they are, what they can do, and what we could do with that?

An example of a technology that is completely "home grown" to the mobile community is SMS. This was not a planned service in the same way as MMS or WAP -- the operators and handset manufacturers did not carefully design and market SMS. It was simply a capability available on the phones and network that suited people's needs, and so it took off. (Note that SMS was not "mobile instant messaging", it was simply a messaging facility for operator use which turned out to work wonderfully peer-to-peer. It's mode of operation is, in fact, quite different from IM, and it is only recently that efforts have been made to fit it into an IM type of UI, such as on the iPhone.)

So what could we come up with in the future, and how do we go about it? Or do we have to rely on accidents?

I think the first thing we need to understand with this approach is exactly what a phone is, and how it fits into people's lives. So let's tackle that one first.

What is a smartphone?
If you are intimately familiar with smartphones, you can skip this section. Still, it's fascinating to take stock of just how much functionality modern smartphones pack into them, and to think about the uses of that technology independent of the actual features.

A smartphone:

• Is a small computer with substantial CPU and memory resources
• Carried almost everywhere

Smartphones have:

• Relatively small screen (sometimes touch sensitive)
• Small keypad or keyboard
• Built-in phone, for telecommunications with other people
• Microphone and the ability to record from it
• Speaker and the ability to play music and sounds
• Usually a camera (or two) with the ability to capture stills and video
• Internet connection which is usually, but not always, available
• Bluetooth connection which can detect and communicate with neighbouring devices
• Infrared connection which can communicate with neighbouring devices
• Positioning information, available via cell ID or built-in GPS
• Databases for contacts and calendar information

Some smartphones have:

• Light sensor
• Motion detectors (eg. iPhone, Nokia 5500)
• Near field RFID units (eg. mobile Suica)

What can we do with this?

So, the question is then, what can we do with the (fairly impressive) bundle of functionality that millions of users carry around with them every day?

Well, some ideas are pretty straight-forward:

• Use it as a PDA (to keep contacts, calendar, and notes)
• Use it as a mobile web browser (slowly starting to become viable as screens get bigger and, more importantly, CPUs get fast enough to present the web in readable ways on a small screen)
• Use it as a mobile email terminal (RIM has been particularly successful in this area, although something like an E61 or P990i/M600i on an operator-provided IMAP push service is just as good, and much cheaper)
• Use it as a constantly-updated weather chart
• Use it as a navigation unit, with maps, current location (via GPS), dynamic routing, and even dynamically updated traffic status
• Use it as an e-book reader

What's obvious about these ideas are that they have all been transferred from devices that already exist. PDAs, web browsers (on desktops and laptops), email, online weather, GPS navigation, and e-book readers are all technologies that have been around for quite some time. Putting them on a smartphone certainly makes them more accessible, and thus more useful, but doesn't really transform the way they integrate with people's lives.

Are there other ideas that can be built from the smartphone's capabilities itself? Yes, of course there are, and here are some we've seen:

• Lifeblog: using the camera, location and time information, and recording snippets of your life along with some comments on it, creating a multimedia "life blog". http://www.nokia.com/lifeblog
• Sensor: using bluetooth and a personalised profile to discover and meet people in your
  immediate vicinity with matching interests. http://www.nokia.com/sensor
  

The problem with these ideas, and why they haven't taken the market by storm, is that there really just curiosities. They don't meet a real need. How many people complain that they don't have a sufficiently rich record of their lives? Not many.

New ideas

Are there other ideas that take advantage of the capabilities of a smart phone and meet a real need? I think there are many, and I'll talk here about one, which I would love to see implemented.

Imagine a service on your smartphone which took advantage of its computing ability, its knowledge of your location, and its connection to the internet. Imagine that you could specify a destination and a desired arrival time, and this service could go off and discover all the ways you could get to that destination at that time, then present you with the options, and then book your chosen options, and finally remind you about when you needed to get moving to get there, and guide you through the process.

For example, I might want to fly from my home on the Gold Coast, Australia, to a hotel in Hong Kong. The software would start by attempting to find a route from start to end. Once it knew this, it would attempt to find services on this route, starting with the most irregular and expensive (ie. the flight from Australia to Hong Kong), and then work down to the simplest (eg. getting to and from the airports). Then it would present me with a range of "best-case" options (no point confusing me with lots of almost-identical options), and I would choose what I wanted for the various legs. Remembered preferences (for example, I prefer the train over driving) would make the choices easier by prioritising them so my most likely choices are the first ones I see. Finally, it would take my choices, book them for me, and keep the e-ticketing information.

Then, when the time came to make the trip, the software would remind me when to start (maybe by putting appointments in my calendar), would present the e-ticket information when I needed it, and would guide me through the confusion of interchanges, and so on.

All of this information is available on-line today. All of the technology required to do this is available. Much of the infrastructure, such as mapping and routing technology is freely available for this type of "mash-up".

What's missing is a good UI running on the phone, which integrates well with the phone's capabilities (its small keyboard and screen, its calendar database and positioning technology), and provides fluid, friendly interaction.

There are obvious add-ons to this service, such as the ability to find and book accommodation given your parameters and choices. An even more powerful addition would be the ability to carpool with others who are heading in the same direction. Sharing aggregate data with transport providers could even allow them to improve the quality and efficiency of their services.

Mass market?

The question is, are these types of services useful for many people? Do they have mass market appeal?

If the purpose is to plan large-scale trips like Austalia to Hong Kong (or even interstate within large countries), the answer would have to be no. However, if the technology can handle small-scale trips like meeting someone in an unknown pub at a certain time, then this is far more useful to the general user.

The tipping point is based on usability and price. It has to be easier to use the phone to discover, book, and schedule your trip than it is to do it yourself. If you are looking at a regular trip (such as a commute), it's unlikely that you'd use such technology, unless it gave you benefits such as carpooling or a discount ticket (from the transport provider to encourage use of such services so that they could better implement their services). But an irregular, but still planned trip using public transport -- such as a weekend outing, or a meeting with the mates or for work -- presents planning and information gathering demands that a smartphone could easily perform.

Personally, the idea of being able to quickly and easily find my way to a meeting, without wasting time at connections or stressing about figuring out the best way there, sounds like a dream come true.

The key to these ideas

Perhaps the key to this approach is to understand the smartphone as an "invisible" tool. A tool that is simply the conduit for desires and information. The idea I've mapped out can include peer-to-peer functionality (with carpooling), which many believe to be a key to success, as well as information and service delivery.

This is the beauty of smartphones: they can span so many "worlds" that they can do all sorts of exciting things. Let's not just create "mobile" versions of existing, desk-bound services, let's try to create truly unique services with the capabilities available right now!

A Future for Symbian Smartphones

Come dream with me for a while. Dreaming about technology, especially when those dreams are firmly rooted in currently reality, is a truly helpful way to determine what trends and features are important to the big picture.

Imagine it's ten years in the future.

The mobile internet is a given, devices are tightly integrated, with precise positioning available, along with sophisticated mapping information, routing, and so forth. RFIDs (radio frequency IDs) abound, allowing RFID readers in smartphones to detect what is around them at any time. Business have moved much more of their catalogs online, encouraging richer consumer-level e-commerce.

But your smartphone is no longer the monolithic device we're used to. It's functionality has now spread much farther. Your watch alerts you, shows simple information (such as what this alert is about), and allows simple interaction (for example, accept, reject, or delay). Your headset now sits inside your ear, offering noise cancellation or transparency, depending on context, as well as voice recognition. Your glasses offer a large, high resolution heads-up display. A lightly textured piece of cloth on the side of your leg is pressure sensitive, allowing discrete, chorded input (pressing different combinations of fingers together to indicate a single letter). All of these are networked via a low-power personal area network (the descendant of Bluetooth) to the phone which you hardly ever take out of your pocket.

Your phone itself roams from network to network, using whatever resources are available to it at the time, depending on your preconfiguration. It has Terabytes of storage, a powerful CPU, and the various high-speed wireless data connections. But you rarely take it out of your pocket, except to take a high-resolution photo or video.

Imagine grocery shopping

It's grocery shopping time. Can't remember what to buy? A few quick commands brings up your phone's memory of the RFIDs it detected in the fridge that morning (you have an old fridge which isn't on the internet), your Food Management software compares that to your observed weekly requirements (the average of your requirements each week), and makes a tentative list.

As you walk through the supermarket shelves, the heads-up display brings up alerts when you approach items you want (as the phone detects their RFIDs), even showing you what they look like, and emphasizing if they're on sale (as specified in the stores online catalog).

While shopping, your list suddenly gets some urgent updates. Your spouse, Kris, has just added some triggered shopping requests for you, and since you're already in the shop, the trigger has added the items to your list. At the same time your watch buzzes subtly. A quick glance shows that those shopping items have a purpose: friends are coming to dinner in two hours, the recipe will take an hour to prepare (according to the online database it was snarfed from), and you're half an hour from home. Not much time to waste. You accept the alert.

Imagine travelling

As you leave the shop, pushing the trolley through the RFID reader, and typing your PIN in acceptance of the charge to your account (offered by your phone), your schedule suddenly changes, though you're not yet aware of it. Your friend's flight has been delayed and their phones have informed yours.

You become aware of the extra time you have when you walk past the newsagent, and a triggered event reminds you that you want to check out the range of birthday cards. Surprised, you actually look at your schedule, and note that the dinner has been delayed by half an hour. Still, you're not in the mood to look at cards, so you reject the suggestion and continue home.

On the way home you listen to the latest e-book on your phone, read out over the car's sound system. Close to home you need to make a detour to avoid an accident. The e-book is interrupted with a gentle request: "Jenny's going to be ready to go home from school in four minutes, the detour could go by the school, would you like to take her home with you?"

You query the system, "Where is Kris?" And it responds that your spouse is still at home.

You accept the opportunity to share journeys with your daughter, and stop at the school, listening to the e-book for the couple of minutes until Jenny gets into the car. Then on the way home you talk about your days. Waiting at a set of lights, Jenney unfolds her phone's display to show you a diagram she drew at school -- it's clarity of layout impresses you, although Jenny points out that it works even better on a display bigger than the unfolded A4 display of her phone.

At home

When you arrive home, your spouse asks you to prepare the dinner. You find the activity for cooking already tentatively in your schedule, with a link to the recipe. The cooking schedule is linked to the ETA for your friends, and needs to start soon (they travelled a little earlier than expected). So, you put away the food you don't need, and start cooking, following the instructions and pictures on your glass's heads-up display (even for things you don't need glasses for, the heads up display is so useful that you tend to use what used to be called "cosmetic spectacles", ie. glasses that have no corrective function).

While waiting for a particular stage you check out the afternoon's headlines (who wastes time sitting down to watch the news anymore?). As you approach the last stage, you see that your friends are scheduled to arrive in a few minutes, and so they do. You spend the rest of the evening happily offline, catching up. Your phone withholds all but emergency alerts (of which, thankfully, there are none).

How does it work?

This sort of scenario seems so much science-fiction to us, doesn't it? And yet there's not much there that current technology can't manage (the prevalence of RFIDs, the integration of data systems, and the more advanced interfaces to the phone are the major advances).

The point is that this seamless integration, of phone software and services with online services, and of phone hardware and systems with other interface systems, is the way that smartphones are heading.

For example, doing voice recognition in a headset has significant advantages in keeping personal area (or near field) communications to a minimum. Having glasses with heads-up displays capable of running substantial chunks of software has the same benefit, in addition to ensuring smooth animations without high network bandwidths or embarrassing dropouts.

Achieving this type of distributed, highly integrated software requires a system that is both a light user of resources (glasses have very little space or weight for CPUs and batteries, and native software, rather than resource-consuming software layers will be required) and able to be distributed (i.e. a microkernel based system with strong Inter Process Communications). That's Symbian (but not Windows or Linux).

And note what happens in the scenario: there is little need for a PC for most everyday tasks. Rather than desktop OS's scaling down, it seems likely to me that powerful device OS's will scale up.

Is this possible? Yes. Is it likely? Well, that depends on the vision of the handset and accessory manufacturers, operators, ISVs, and even retailers. Open interfaces are critical to this vision, and are the most likely thing to never come true.

Let's all hope that there are enough people with vision to help make this a reality.

State of Play for Symbian ISVs

This article is a quick summary of the state of play for Independent Software Vendors creating software and services for Symbian OS devices. Each section contains a short history, current situation, and likely future directions (including suggestions).

Issues tackled include why ISVs should be supported at all, the range of devices available to Symbian ISVs, the possibilities for the ecosystem in ISV-provided services, the channels to market for third party software, the range of technical documentation available to support development, the process of Symbian Signing, the state of APIs available to ISVs, and the development tools available for software creation.

While not all of these may be of concern to you, certainly one or two will be of interest to anyone involved in the Symbian ecosystem.

1. Development tools

Development tools are critical to ISVs -- they can make the difference between being able to make an application profitably and being unable to do anything at all.

In the Symbian world, we've had three "preferred" development tools over the last seven or so years:

Visual C++ -> Metrowerks -> Carbide

Carbide has finally become usable in v1.2, and is a quite reasonable IDE. However, it still has some serious limitations that are very obstructive in terms of developing Symbian apps.

1. On device debugging doesn't work properly (very clunky with static DLLs, which Symbian encourage developers to use, and doesn't work at all for memory shortage debugging)


2. RAD development for UIQ 3, there are simply no tools, and given the complexity of UIQ 3's very powerful resource files, this would be a great help.

2. Application Program Interfaces (APIs)

Until recently Symbian support three separate APIs, S60, S80, and UIQ. In the last year or so that has narrowed down to two: S60 3rd Edition and UIQ 3. This is obviously an improvement.

However, getting here has been very painful. Constant changes to S60 (including breaking compatibility in many areas) in addition to radical change between UIQ 2 and UIQ 3, has necessitated serious porting effort for many vendors. This effort would have been better spent improving the products.

At least with UIQ 3, the effort spent on porting now works on two classes of phone (touch screen and soft key).

In the future, this should be able to be better managed, and it seems as if this will be the case. Nokia has a "platform evolution" page which shows that future editions of S60 have a "Compatibility promise". So long as Nokia stick to this, ISVs will be much more productive. As far as UIQ is concerned, they seem to be inherently more careful about compatibility than Nokia, and took the opportunity of the forced platform incompatibility caused by PlatSec to totally revamp their APIs, ready for the future.

3. Signing

The whole Platform Security (PlatSec) issue, which requires application signing for certain purposes, started out as a bit of a nightmare. Signing was expensive, clumsy, and non-trivial. The simple fact of an application requiring resigning on even a change to text resources prevented many developers from signing applications due to the way it "locked in" the release version, preventing incremental fixes and improvements. Furthermore, the expense of signing versus the potential return was all out of whack.

Symbian have been slowly working on this, introducing initiatives such as freeware signing (very slow and quite heavily restricted though it is), cheaper Publisher certificates, cheaper test houses, and so on.

They have just announced a new set of proposals, which are very encouraging, especially new signing methods such as the "Express Signed" process (which allows instant signing with the submitted apps being audited later). It seems that Symbian recognise the limitations of the signing process, as well as the strengths, and are making sincere efforts to minimise the pain while maintaining the advantages. I think Symbian are doing a good job here.

However, automated test tools must be delivered (UIQ 3's automated test tool hasn't worked for well over a year, preventing developers from pre-testing their applications before submission), and more precise test plans must be available (or how can you prepare an application for testing?).

4. Documentation

Back in EPOC days, Symbian started with very poor documentation but this was partially mitigated by the availability of much of the UI source (which also helped in debugging).

With the release of S60 and UIQ SDKs, we were moved on to slightly better (but still poor) doco with no UI source -- a significant (and very frustrating) backwards step.

The current situation is certainly much better, with more complete documentation and a growing set of examples. However the SDKs are still incomplete. (For example, where is the UIQ 3 documentation describing how stand-in controls work? This is a fundamental UI concept in UIQ 3, and yet there is nothing to assist an ISV to create their own stand-ins.)

The SDKs need serious work to complete them. The S60 and UIQ developers need to remember that this is an OO framework, so deep knowledge of the framework is needed for subclassing, etc. It seems that none of the OS/UI providers fully understand this.

Microsoft is still the role model in this regard.

5. Channels to market

Symbian development started with no official channels to market. Developers simply sold on their own websites. Over the years, independent resellers (such as Handango) have popped up. Some of these have been adopted by operators or handset manufacturers as official channels (and some have lost that official status).

The situation now is that premium channels (vendor and operator) have higher requirements (eg. signing), making it more difficult to get quick, light product to market, or to provide incremental updates. Generic channels (such as Handango or Mobile2day) offer significantly less barriers, but still demand a substantial cut of the sale (often almost half) for relatively little effort on their part (they do no front-line or Level 1 support for example, merely sales support). Furthermore, agreements between these distributors are often incompatible (for example, Handango requires no references to anything but Handango in software they sell, which, combined with signing required for textual changes such as that, places a premium on dealing with Handango). Finally generic channels don't always have great results, anyway, since they are pretty much invisible to the average smartphone user.

Premium channels now starting to be promoted on phones (such as Sony Ericsson's move to put their application shop on the home screen of the P1i), but this still needs more work.

I think that, in the future, we need time-of-handset-sale channels. Many users still don't realise smartphones are extensible, and so don't try to improve their user experience even though they may want to if presented with that option at time of sale. Operator's shops could do this, but have been very poor at implementing this.

SE (with their choice program in Asia) and Nokia (with their Downloads facility) seem to be attempt to improve this situation, but these initiatives need plenty of promotion and some retail-level training (ie. by the operators) would probably help.

6. Services

In the past there has been no provision of a services platform by the operators or handset manufacturers, so any services provision (such as Mobimate's weather downloads) have been purely ad-hoc and provided by the ISV themselves.

Nokia's Ovi may be the first approach to making service provision easier. Hopefully Ovi will be open to ISV's, providing a framework for services, including access to infrastructure such as mapping, routing, etc. This would allow much richer provision of services, which benefits everyone: users, operators (service provision has to travel over their networks), and handset manufacturers (their handsets have more, richer features).

SE needs to mirror this with a UIQ services facility.

Important service infrastructure that would be very beneficial to provide in such offerings would include: better sync platforms, including open support for sync plugins (at both ends); generic databases for data storage; web-scraping engines for collating information; location, mapping, and routing tools; and so on.

7. Devices

In the area of device availability and capability, the Symbian licensees (at least Nokia and SE) haven't made too many mistakes. Certainly Nokia's proliferation of devices with minor compatibility issues has (and still is, judging from the new N-Gage issues) caused some problems, and SE's struggle to produce new devices has caused it's own problems. But compared to the other platforms, Symbian has been well served.

Some real improvements that I would like to see in the near future would include features like video out that scaled to a larger screen and other features to help the phones double as PCs. Symbian OS is a powerful, real OS (even theoretically capable of being distributed across multiple devices thanks to it's microkernel and IPC model), so there's no reason to limit it.

Of course, better development tools would be helpful here, too, as well as remote testing capability such as already provided by Nokia.

8. Why should ISV's be supported at all?

Now, given how demanding ISV's seem, given the article so far, handset manufacturers may just be asking themselves, "What is the point of all this? Why bother with these demanding ISV's?"

It's not hard to provide an answer. Just look at Microsoft.

How successful would Windows be without it's vast ecosystem of ISV's? Even when MS has been predatory towards particularly successful types of third party software (such as office applications and web browsers), MS have still benefited enormously from all that innovation that they simply cannot do themselves.

In fact, considering how unexciting PC's and Windows are by themselves, could you ever imagine their extraordinary level of success without ISVs? The phone manufacturers have devices that are, inherently, much more exciting than a PC, but ISV's are capable of multiplying that wow factor, transforming these cool little camera/music-player/phones into devices that co-ordinate, communicate, track, instruct, protect, inform, educate, capture, assist, remind, and guide your life.

As for the operators, well, they stand to benefit even more -- what use is a data network without useful applications to use that data?

Causes of piracy in the Smartphone market

Some time ago, Alex Kac of WebIS wrote an appeal to users of cracked software.

From DreamSpring's perspective, the same issues are very significant. Despite the smartphone market being so large, the market for third party applications seems woefully small. Why is this?

Certainly the prevalence of cracked software is one contributing factor, and a very major one at that.

Our own research has uncovered cracker forums where people gather, praise DreamConnect (our major product and money-maker), and ask when the cracked version is coming out. Can you imagine how galling it is for people who have spent bucket loads of money and months of effort crafting a product to see users praising a cracker for his crack of that product! What are these crackers, and more to the point, those who use the cracked software thinking?

And that's a valid question. Do people really think US$25 is too much to pay for software that they'll freely praise on a cracking forum? It seems so. It seems that they'd rather run the risk of installing trojans on their phones than pay a lunch or two to support the product (and to get product support).

Trying to understand why people do that is critically important. I'm not going to pretend that I have the answers, but here's a few thoughts. If you have anything to contribute, such as your reasons for hesitating to buy software, please leave comments.

My own attitude

Before I get started, I should make it clear that I find myself reluctant to pay money for software to run on my smartphone (a P990i, which I am very happy with). So I can sympathise with those who are reluctant to buy software. However, long ago, I made a decision to not copy software (or CDs, etc.). If I'm not willing to pay for it, I don't deserve to have it (assuming "it" costs money).

As a result, I try to find freeware to do what I need, or just get by without it. On P990i, I use the free version of Swiss Manager, for example, because I don't feel I can justify the pro version. I also use Mobipocket because it's free. I currently only have free Bibles in Olivetree (although I plan to buy a modern translation). I own a copy of Documents To Go (because I finally gave up on QuickOffice and it's buggy Bluetooth keyboard interaction), and that's about it (apart from DreamConnect, of course, which fixes several fatal flaws in the Contacts application).

So I understand a bit of where people are coming from, and these thoughts come from my attitudes as much as observing others.

Volatility of the platform and device

A major factor in my reluctance to spend money is the volatility of the smartphone platform, and the limited working lifetime of the phones themselves.

Take a look at this page from nokia: S60 Platform Evolution. Note that in S60's short life so far (up to S60 3rd Edition), we've had two compatibility breaks (one fairly major, and one complete). (UIQ has had only one break, but that was huge. Our porting effort from DC 2 to DC 3 was equivalent to porting from UIQ 2.1 to S60!)

Add into this the fact that people change phones regularly, and you can see that, even if they remain loyal to the platform, there is no guarantee that their current investment in software will transfer to their next phone. In fact, with such major breaks in compatibility, vendors will almost be forced to charge again for their new versions (as we did, due to the huge effort involved).

And people don't remain loyal to one platform, since these devices are more than just computing platforms. People make decisions on which handset to buy based on lots of features, not just their software platform.

Phones differ vastly compared to PCs. Just think how different an N95 is from an M600i:

• Different OS


• Totally different pointing mechanism (nothing -- a joystick is just arrow keys arranged in a certain pattern, it is not a pointing mechanism, unlike IBM's keystick, or a touchpad -- vs. a touch screen)


• Lots of application-specific buttons (music) vs. one (internet button)


• Numeric keyboard vs. Qwerty keyboard


• Thick vs thin (this is the trivial sort of difference laptops manage, but it's more important with phones, because you carry them in your pocket)


• GPS vs. none


• Wi-Fi vs. none


• 5MP camera vs. none


• Different included applications

These differences are huge compared to the differences between a MacBook Pro (which our marketing department uses) and a Dell laptop (engineering -- how stereotypical, eh?). The main differences between these two is the different platform, different included apps, and different thickness. They both have virtually identical technology included. Oh, the MacBook has a built-in webcam (which is utterly pathetic compared to even the most basic modern cameraphone), but newer Dells have that too.

So, given these differences, platform and software compatibility are almost swamped in the decision-making process.

The end result of all this is that a user of smartphone software only has a very short period to get a return on their investment. This leads to a very tight market for ISVs.

User Attitudes to Phones

Another contributing factor, which is related to the volatility of phone platforms, is the general attitude of users towards phones. Very few users think of phones as software platforms. In fact, most people I talk to view a phone in much the same way they view a washing machine: it's an appliance that does what it says on the box (or not, depending on quality).

So the vast majority of smartphone buyers simply don't look for add-on applications. The only way to change this attitude is by a concerted effort from both the handset manufacturers and operators. The handset manufacturers have finally started doing this, through various measures from branding to prominent positioning of a link to the software shop, but the operators are still bumbling along.

From my observations, it seems likely that the user needs to be presented with the opportunity to extend their phone while they are in the process of purchasing it. This would require the operator's shops to have some form of mechanism (along with limited training for their staff) which would profile the user and present them with applications that they would be likely to find useful. If they could then purchase these apps included in the price of the phone and plan, then I would expect much better uptake. At the very least, a range of applications should be visibly available for purchase at the retail shop.

But I have never yet seen this done, and I've searched across several continents.

Conclusions

Piracy is a serious issue for mobile software developers. The nature of the hardware platform encourages it, and the nature of the retail process discourages proper purchase of software.

Moves to make pirated software easier to detect are only useful so far as users desire to avoid pirated software. Currently, there is not a great desire to do so, and large-scale promotion is required to remedy this.

So, ISV's simply have to hope that the operators and handset manufacturers wake up to the value that independent software adds, and try to protect and encourage the industry before it gets starved to death.

Addendum (27th Sept)

I've just bought a new phone in Hong Kong, one of the most open mobile phone markets in the world (almost all phones are unlocked and the vast majority of new phones are sold SIM-free). It was a new Sony Ericsson P1i, which has just been released here and seems to be selling well. During the sales process I was allowed to see the phone working, shown the IMEI number on the screen and on the box (for guarantee purposes), and given gifts consisting of a box of Chinese add-ons (a third party battery, USB battery charger, and phone case) and an Adidas cap. At no point was I offered any extra software for the phone. At no point was it even hinted that this devices could be used for features beyond what came in the box.

I bought this phone at one of the largest retailers in HK: Broadway (the big shop in Mong Kok, on Sai Yeung Choi St N). So that's the situation in one of the more progressive markets. What hope do we ISV's have elsewhere (apart from very close relationships with the operators or handset vendors)?

Carnival of the Mobilists #80

Carnival #80 is up over at mobilejones. As always, it's worth checking out. While you're there, have a browse around the blog.

Unfortunately, mobilejones mischaracterises my piece by implying that I condemn all web apps on the basis of a sample size of two: Google Gears (which isn't even an application) and Blogger. It's likely he read in a hurry, so he didn't pick up on two important points:

• Google Gears is a framework, and I analyse how it will impact the reliability of web applications in a mobile context
• Google Blogger is used for illustrative purposes -- it's always easier to talk about concepts by using a concrete example, and that's what Blogger was for my purposes.

Obviously I was a little too subtle in these points for a hurried read, but then these analyses have not been intended for quick reads (unlike earlier posts), but rather for careful consideration. Hopefully most readers will understand that.

Note that I'm not claiming that I am 100% right -- that would be rather arrogant of me. Still, at least I've worked through the matter, and even presented some models for evaluating how and when to choose the different software platforms. Hopefully this is useful.

Why Web 2.0 won't work on smartphones -- Part III of Smart Phone or Mobile Browser

Since I wrote Part II of Smart Phone or Mobile Browser there has been a bit of activity on the Mobile Web 2.0 front:

• Google Gears has been released (I noted this in an addendum)
• Apple has announced that the iPhone's only development platform is its Safari browser.

This has stirred up the silt of online commentary, but hasn't really changed the lay of the land at all. Mobile Web 2.0 is still a poor cousin of native clients. And here are the reasons why.

The Story So Far

In Part I, I looked at the history of web applications, and the special character of markets (or the Japanese market, at least) where they've been arguably successful. In Part II I presented three factors that are required for applications to be enjoyable and practical to use and that Web apps are, by nature, poor at: responsiveness, reliability and privacy.

Has the Story Changed in the last month?

Google Gears changes the reliability equation a bit, but the equation is still in favour of native clients:

R(native clients) = R(client app) * R(client OS) * R(client HW)

while a Google Gears based app has a reliability of:

R(GG app) = R(client SW) * R(browser) * R(client OS) * R(client HW) * R(GG framework)

It's easy to see that a GG app adds the (un)reliability of the browser and Google Gears framework into the equation. Thus, given the fabled instability of web browsers, and unknown stability of the GG framework, the client application code must be vastly more reliable in order to equal a native client application's reliability.

As for Apple's iPhone announcement, this has no impact at all. Some (presumably) ignorant commentators have waxed lyrical over how the delivery channel problems faced by mobile software vendors are magicked away by Apple's approach. I assume these commentators are merely ignorant (as opposed to plain dumb), since smart phones have supported this approach for some time, through recent releases of Opera mobile and Nokia's Safari-based web browser.

In any case, neither of these announcements really shifts the playing field much. Web apps are still much easier to deliver, but no easier to advertise or promote. And Web apps still have significant responsiveness, reliability, and privacy issues.

Is that the end of the matter, then? No, it is not. There is still one more critical factor to consider.

Usability

A major factor that I didn't talk about in the last post is usability. Anyone who has struggled with a complex web application like SugarCRM or even a simple one, such a Google Blogger, which I'm using now, will be aware of the peculiar user interface that Web APIs force on application developers.

Let's take the simple case of Blogger, as an example. Basically, Blogger is a text editor which saves to a type of bulletin board instead of a file system. Frankly, it is a terrible text editor. It has no styles, only two types of lists, no table editor, extremely primitive layout capabilities, and a very old fashioned spell checker (press a button to get your spell checking done). The problem is, Blogger doesn't allow you to use any old text editor, since the text editor is tightly integrated into the whole blogging framework. Tch, tch.

Even with its primitive features, the Blogger editor has terrible usability. The only shortcuts appear to be Ctrl+B, Ctrl+I, Ctrl+S, Ctrl+Z for bold, italic, publish (not save), and undo. There are no shortcuts for changing the font, there is no way to insert a hyperlink which has text different from its target without editing the raw html (shocking, I know). The editor is not even WYSIWYG! To access the various critical parts of the user interface, such as saving a draft, previewing (yes, previewing: no WYSIWYG here) the text, running a spellcheck, starting a list, etc. there are buttons to click with your mouse.

There is no menu bar, so any menus need to be attached to one of these on-screen buttons. Menu items have a very limited range of shortcuts to choose from, because the browser itself has already claimed many of the shortcuts.

In other words, what we end up with is a user interface with very constrained models of interaction, mostly point and click. There aren't even context menus to make interacting with objects easier. All of these useful UI mechanisms (keyboard shortcuts, menu bar, context menus, drag and drop) are either not available to the Web 2.0 developer, or they are very difficult to code (and thus lead to unreliable software).

How does this affect Mobile Web 2.0? Badly, as it happens.

The preferred UI interaction method for Web 2.0 app's is the on-screen button, clicked by a mouse. For touchscreen smartphones, this method of interaction may seem quite natural, until you look at how much screen real estate is needed for all these buttons. Ever tried to use Blogger on a VGA screen? It requires a lot of scrolling about, since Blogger only scales down to a certain size. This transforms simple movements of a pointer and clicking/tapping into the much more time consuming action of scrolling, pointing, clicking, scrolling.

Mobile devices have created whole different device interaction models (such as the softkey model), which Web 2.0 apps simply have no access to at all. (How does a Web 2.0 app register commands on the softkeys, or place commands in the browser's menu?)

Maybe the iPhone's touch interface will work with carefully tuned Web 2.0 apps, but I can't see them getting very sophisticated without becoming quite clunky. And all the cools effects of the iPhone's UI (zooming and sliding and scaling) will presumably be very difficult, if not impossible, to achieve.

The Alternative

So what is the alternative model to a Mobile Web 2.0 application? Clearly the "mostly connected" nature of a smartphone should be exploited, but so too should its native capabilities. So the obvious model is a native client application that synchronizes, when needed and as possible, with online services.

The native client application, with smartphone-resident data silo, has the benefit of:

• Responsiveness
  Native client applications don't require bulky frameworks to start up or be kept in memory before they can run. I was reminded of how demanding this can be lately when using Google Maps on my P990i. It is a Java application, and Java takes quite a long time to start up, and chews up a phenomenal amount of memory. Of course, on some devices (such as Blackberrys) Java is the native framework, so it doesn't have such a hit. But on devices where it is not, it is a very poor choice of API. And so is a web browser.


• Reliability
  I think I've demonstrated pretty clearly why native applications are better at this, assuming that they are written with even a little attention.


• Privacy
  Native applications, with a local data store, can keep information private to the device. When information is sent to the online service, it can be encrypted (if it is merely to be stored) or anonymized (if it is to be used to generate a reply). Whether this is being done can be validated by a third party, which is something that is simply not possible with an online software service of any type.


• Usability
  Native applications can be developed to exploit the UI methods of the device. I was reminded of the importance of this, once again, by Google Maps. For some reason, Google Maps uses a UI that mixes its own menu style with the built-in style. It leads to constant cognitive dissonance as things react in unexpected ways. Even Opera Mini 4, which is a model of usability in its scrolling and zooming behaviour, suddenly gets weird when you tap on an input field or the like. (Oh, and it consumes a truly shocking amount of memory.)

When native apps have benefits in all these areas, which all have a direct impact on the end user, it's merely laziness or a very cavalier attitude to the user experience that encourages people to use the Web 2.o platform for serious application delivery.

Having said that, where the main focus is browsing, rather than manipulating, non-critical information, Web apps are great. And this is where Web apps belong: in making a better Web.