Sender 11

What's your developer story?

This blogger has moved!

I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs

 

Back in the old days, 3-4 years ago, mobile developers were concerned with fragmentation. Phones were very different, and where was the technology that was going to solve this darn fragmentation problem? Because, once that was solved, the path to the wallets of a billion mobile customers was surely wide open.

The merit of individual runtimes were hotly debated; Java ME, FlashLite, the browser-as-runtime, etc. The strength of each were measured by their installed base and their level of fragmentation. Java ME (J2ME) was practically ubiquitous, but a nightmare to code for. (The joke is: There is a billion Java phones out there. The bad news is that each runs its own version of Java.) FlashLite was comparatively less fragmented, there were only four different versions, but the the installed base was tiny compared to Java. Mobile browsers were getting great at rendering web pages, but offered no way to interact with the rest of the phone, so they could not really support applications.

Java ME primarily served the mobile games industry. There has been a decent amount of revenue in that business, but the majority of the money has been pocketed by operators who has kept raising the barriers to entry, thereby shutting out the bottom of the pyramid. To the point where the old mobile games industry is basically dead by asphyxiation.

The old landscape for consumer apps: A cross platform story

(By the way, this is about consumer apps, not enterprise development, so Windows Mobile for example is not in the picture.)

There is a new story to tell

Then the iPhone came along. In a typical "We're the best, forget the rest" fashion, Apple left out support for whatever operator network features they didn't like, like cross platform communication and interoperability features. Standards that the industry spent decades agreeing on and deploying. No MMS, no video call, no mobile TV, no Java ME, only the most rudimentary SMS. And for a reason. Why pay a dollar to send an image via MMS that the recipient probably can't view, when you can send an image via email, that is free and always work? features like MMS are poorly implemented on the handsets, poorly understood by consumers and basically broken. So why bother with them?

The unwillingness to follow standards is a cultural trait for the US I guess, where each operator tries to differentiate on everything. Less that ten years ago you could not send an SMS to a friend if he or she was on a different US network. In Europe there is a tradition for interoperability, the GSM standard itself is a good example. This is probably due in part to smaller markets and the cost benefit of common infrastructure.

Be that as it may. The state of the consumer app market has been broken up by new US entrants into the mobile space, most notably Apple and Google. They have opened up mobile app development to anyone, to "the bottom of the pyramid". They have decided to dance to their own tune. The iPhone and Android significantly dropped support for Java ME, the one cross-platform standard that were in place.

The ultimate fragmentation?

The result is the ultimate fragmentation. While previously there was only about 95% compatibility between brand X and brand Y, now there is precisely 0% compatibility.

But the strange thing is I don't hear developers complaining much about fragmentation any more. They may be too busy creating apps for the iPhone and Android. A straightforward, low barrier way to monetise your app apparently trumps standardisation any day. A way to make money is more important than a way to save money.

 

The emerging consumer app landscape looks native, and the incumbents does not have a compelling story to tell

 I have added RIM and the Palm (welcome back from the dead?) to the chart above. Apple, Palm, Android and now RIM have a developer story to tell. The incumbents does not. The story developers want to hear is: Yes, we have an app store, yes we have an SDK, and yes we have a really cool device that can run your app. Of course, only Apple has proven itself yet. The others are scrambling to emulate the runaway success of the App Store.

MIDP3, the upcoming version of Java ME has been in the works for 4 years, and right now it looks like it will never arrive. What will the world look like for MIDP3 when and if it launches sometime in 2010? No one seem to care enough to even think about it. Innovation in mobile is currently pretty much lead by outside entrants, and they don't worry much about Java ME. Why not? Because they provice door-to-door solutions. Why make cross-platform worries for yourself when your goal is to provide a smooth integrated experience, not to be a part of a fragmented and broken developer experience.

Cross platform is still there. Barely

That does not mean that there isn't a cross platform story to tell. There is, and it looks like this:

The new cross-platform story: Every vendor has their own standard.

You can develop cross platform web-based applications. If your code runs server-side and your mark-up simple, you can even expect your web–app to work across vendors.

But if you intend to interact with the phone itself - if your app uses the camera, the GPS, or any other internal phone feature - you are back to developing a separate app per manufacturer. Most of the above manufacturers has announced plans for their own APIs. See previous post for an overview of web runtime APIs. Samsung and LG uses different browsers on different handsets and its unclear how they will deal with the API issue. Apple may not bother at all.

So, while the powerful development platforms and Appstores are popping up like dandelions in springtime, the dream of cross platform development seems further away than ever. Maybe for ever.

Web Runtime APIs

This blogger has moved!

I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs

 

Back in the days when J2ME was the mobile development platform of choice, there was a lot of both ridicule and concern about how fragmented J2ME was. Pundits claimed that with the second coming of the Mobile Web all those problems would be over, and developers would live happily ever after in a world of True Internet Bliss. I wish it was true, I really do. But apparently it's not easy to agree on standards when all players struggle to differentiate from each other.

The current state of affairs is that everybody+dog is cooking their own solution. Here is a brief overview:

Nokia Web Runtime

Nokia was early with a plug-in for the Nokia WebKit browser that basically gave access to battery and signal strength. With S60 5.0, launched recently with the Nokia 5800 "Tube", Nokia introduced WRT 1.1:

AppManager Service API	Access and launch applications on a device
Calendar Service API	Access and manage calendar information
Contacts Service API	Access and manage information about contacts
Landmarks Service API	Access and manage information about landmarks
Logging Service API	Access device logging events
Location Service API	Access device location information and perform location-based calculations
Media Management Service API	Access information about media files stored on a device
Messaging Service API	Send, retrieve, and manage messages such as SMS and MMS
Sensors Service API	Access data from the physical sensors of a device
SystemInfo Service API of WRT 1.1	Access and modify system information on a device
SystemInfo Service API of WRT 1.0	Access system information and control certain device features

Motorola WebUI

Motorola WebUI runs on Motorola Linux devices with the first handset, MOTO VE66 scheduled to be out before Christmas. Here is the API's:

File system API	Read and write access to files in the file system
Location API	Information about the device’s location
Contacts API	Access to contacts database and native contact list picker UI
Calendar API	Access to calendar entries
Internationalization API	Language translation and language change notifications
Application launching API	Launching other applications and UI services
Event subsystem API	Subscribing to system events; publishing and subscribing to non-system events
System API	System settings and status information
Soft key management API	Getting or setting the soft keys and receiving notification when they are pressed
Media Finder API	Searching for files based on metadata tags
Download API	Downloading and storing files

ACCESS NetFront

With the announcement of NetFront version 3.5, ACCESS, who makes the Sony Ericsson browser, introduced a device API. I haven't seen the specs anywhere, but ACCESS says:

"DirectConnect, ACCESS' ECMAScript-driven interface, enables the creation of a entirely new class of applications which combine Web 2.0 services with device-resident capabilities. Such capabilities include location using GPS and other positioning methods, access to local content stored in the address book and calendar, sharing of music, pictures and movies made accessible by DLNA (Digital Living Network Alliance) technology, etc."

BONDI/W3C

BONDI is an attempt by OMTP bring order. To define a common set of interfaces for access to handset capabilities. BONDI will submit their work to W3C in order to establish an industry standard. Details will be finalized by years end and a reference implementation is in the works. Too late?

Telephony API	Place calls
Communication Log API	Access the call log
PIM API	Access contacts, calendar, task and notes
Messaging API	Send SMS, MMS and email messages
Media Gallery API	Store and retrieve media files
Persistent Data Storage API	Access persistent storage
Location API	Access location info
Application Invocation API	Launch native applications
Phone Status API	Access device status for battery level, network connection, orientation etc.
Camera API	Access the Microphone and Camera functions

Others

Microsoft will introduce a "RIA framework" in an "upcoming version" of Windows Mobile. Their strategy seems to be Silverlight, but it would make sense to support AJAX based applications as well. No?

The iPhone does not currently expose any device capabilities through the browser. What their plans are is anyone's guess. With the success of the AppStore, they are probably not in a hurry.

The BlackBerry recently added support for AJAX and exposes a location object that lets you access the GPS from the browser. It also has some nice push features, but no other capabilities through the browser.

The first Android device, G1, features Google Gears. Gears gives access to location plus local storage. In theory anyone could write a browser plugin to expose most any phone feature, that goes for S60 and iPhone as well as Android. The only problem is that there is no friendly way to the the plugin onto the phones.

Doom or gloom?

None of the above API's are compatible. Not only are the methods different and located in different classes, the capabilities are only partly overlapping. The security mechanisms are different, with different policies and different certificates.

Standardisation efforts notwithstanding, this emerging chaos probably has to be solved through technology. Somewhere in here, there is a business opportunity for an enterprising developer.

Dead icons must die!

This blogger has moved!

I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs

 

I recently spoke at Handsets World in Berlin about what specifically Apple has done to make using the iPhone a good user experience. The take away is that there is no secret magic to it. It is simple demonstrable, understandable principles and when a companies tries but fails to create good products, the primary reason is often organizational. It is not because the company does not have the right "rock star" design talent. It is because the organization has layers of management above the designers who has other priorities than creating great products and who wouldn't know a great product it it jumped up and bit them in the behind. Managerial talents are most often political and financial and they have the "yes, but" veto. Design priorities has to be driven from the top dog, or it will have limited effect.

According to some comments afterwards, I managed to annoy most of the audience who were high ranked people from the leading handset manufacturers and operators. Well, that wasn't my original intention, he-he, but I'm happy that the talk stirred some controversy and discussion.

Dead icons

The panel discussion afterwards was about "Achieving End User Delight" and one of the panelists, Sofia Svanteson from Ocean Observations had a great comment. She said said something along the lines of "Dead icons must die". Instead of static icons just symbolizing a function or some content, icons should reflect the content it represents. This jives with "using the content itself as the interface" something I have written about before.

IIRC she used the Sony Ericsson Xperia as an example. The Xperia home screen has "panels" that are live(?) miniatures of web pages, the calendar, music player, etc. The panels are user configurable.

She also used iPhone home screen icons as example. The icon for the Weather widget displays the actual weather for the default city, the Calendar icon shows today's date, etc. (Interestingly, the icon for the Clock does not show the time. The reality of power consumption. A constantly ticking clock would probably drain battery.)

Should the Stock widget icon show the stock price? Should the Maps icon show your position? Should the Notes icon show your lates notes?

Muscle memory

This blogger has moved!

I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs

 

This is the main entrance of the building I work in. Eh, to be precise it's the user interface to the door lock. (There are actually 2 user interfaces there. The door bell for the first-timers, and the panel below for "experienced users"). It's standard issue: Swipe your ID card, type in your code and the lock opens with a bzzzzz.

As you can see the numbers are worn off. They can't be read. How do people get in through the door? No they don't ring the door bell. But if they can't see the numbers, how can they enter their code? When I get to work each morning, there isn't a queue of 150 people outside failing to get the door to open. So they must be able to get the door to open somehow.

Muscle memory

We don't enter numbers, we leave it to our hand to type in the code. If we do it often enough, the hand learns the code, an effect called Muscle Memory. The hand does not remember the numbers, it remembers a movement pattern. Many people, when asked what their PIN code is, have to type it on a real or simulated keypad and look what numbers their hand type. In fact, when I asked my colleagues about the panel at the main entrance, none of them had even noticed that the numbers were missing!

The brain-to-hand connection is very well developed in humans. Manipulating something with our hand does not take much mental effort. As a result, direct manipulation feels effortless. The flip side of this is of course that if your software is inconsistent with learned behavior, your users will be frustrated.

Mobile menus

It's worth repeating that you should not design your software to be consistent across devices. You should design your software to be consistent with the device it runs on. Your users are unlikely to use your software on many different handsets. When your software runs on an old Sony Ericsson phone, it should use the hardware Back key down to the left. When it runs on a Nokia Series 40 it should use the softkey back to the right. Here are some common key layouts:

 

(Click to enlarge)

Common ground

Thankfully the handsets are converging towards this common behavior:

More on mobile screen size trends

This blogger has moved!

I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs

 

I recently wrote about screen size trends and the trend is clear: 240 x 320 (aka QVGA) is the new baseline screen size, both for feature phones and smartphones. Smaller screen sizes like 176 x 220 is disappearing and the 128 x 160 size is pushed down into basic phones.

QVGA will be the new small size, but it is not clear what the new dominant large screen size will be, or if there is going to be any.

What is pretty clear is the trend towards widescreen and landscape orientation for high-end phones. QVGA and larger phones are getting automatic screen rotation. Landscape is often preferred for media consumption and handheld movie consumption has been "promising" for quite some time.

The primary design objective for the iPhone (in my opinion) was to make the optimal video iPod. When you have 70% marked share you need to grow into new markets. Several new phones from other manufacturers seem to have the similar design objectives.

I have compared some available and coming devices that could represent a trend. LG and Samsung seems to be partial to the 400 x 240 screen size. They have released several devices with this screen size the last year or so. Nokia has recently tipped their hand with the Nokia Tube. The name obviously refers to a video use-case. At MWC in Barcelona in February they showed a demo that ran on a 360 x 640 screen. This gives a 16:9 resolution, the same as HDTV. 640 x 360 is also called QHD for "Quarter HD".

The Sony Ericsson Xperia has been developed for the US market specifically. It runs WinMob 6.1 on a 800 x 600 screen, a resolution not supported in any official Microsoft documentation, but I guess Microsoft saw fit to go the extra mile in this case :-) The Xperia has an extreme resolution, it has more pixels on 3 inches that a good ole VGA desktop screen. I'm not sure that the Xperia exact screen size and resolution represents a trend, is kind of an extreme case. But it underscores the general high-end widescreen trend.

Pixel dimensions and aspect ratios

I used 9 as lowest common denominator for ease of comparison.

Physical screen size

Most of the devices uses 3–3.5 inch screens, something that does not leave much space for a keyboard. The phones are either clamshell or pure touch. They are also fairly similar in physical size.

Gestures, pixels and bandwidth

After years of designing for really small screens and always in portrait orientation, these devices sure feels like drowning in pixels. I absolutely expect to see some great and innovative user interfaces coming out of gestures, pixels and bandwidth!

[Note:] No mention of Motorola here, for the simple reason that I have no idea what they are up to.

[Edit] Just to be clear, the reason I'm exited is because the phones above makes it possible to design for a wide screen. I'm aware that many or most of the standard functions in most of the phones above is intended for vertical use.

Fonts for prototyping mobile UIs

This blogger has moved!

I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs

 

I've seen many prototypes of mobile UIs that can't be built and if they could, would not be legible on a small LCD screen. So I thought I'd provide some pointers that might help those of you that is starting out. Often, people starting out prototyping mobile phone UIs get the size of the display right but the size of the font wrong. They try to stuff way too much in there, and they use a font size and font family that is not available in the phone.

If you design applications, you can make pixel perfect designs. If you design mobile web pages, you go for a rough estimate. Having the correct font is important if you design applications, less important if you make mobile websites.

Most current phones use anti-aliased fonts and many of these are available in TrueType versions that you can use on your PC. I've provided links to "official" sources, you may find more if you search the web, but quality may vary.

Font families

Below is an overview the OS fonts used by Tier 1 manufacturers.

Nokia Series 40 and S60

• Nokia BW fonts 
• S60 Sans (Monotype Inc.)

You can get a TrueType version of the S60 Sans font by downloading and installing one of the Nokia S60 SDks. The fonts currently used in Series 40 devices are the same (or close enough). Note that Series 40 and S60 does not use the same font size for the same screen size however.

Prior to 3rd edition, Nokia used BW fonts, one font for S60 and one font for Series 40. I handmade TrueType versions of these fonts 3 or 4 years ago. If you need them for the purpose of mobile UI prototyping, send me an email.

Sony Ericsson OSE and UIQ

• Sans-Serif (Monotype Inc.)

You can get a TrueType version of this font by downloading and installing the UIQ 3.0 SDK from the UIQ website.

Motorola (various proprietary OSes)

• SynergyBasic (Bitstream Inc.)

I have a Bold only version that I once found somewhere on the intertubes, but I can't locate it anymore. The font is similar to Univers and you might get by with that.

Samsung and LG (proprietary OSes)

I don't have information on what fonts their feature phones uses. If you know, leave a comment or send me an email and I'll update it here.

The Symbian versions uses the S60 Sans font, the WM versions uses Segoe Condensed or Tahoma.

HTC, Motorola, Samsung, etc running Windows Mobile 6

• Segoe Condensed (Monotype Inc.) 
• Microsoft Nina for East Asian

Available in Regular, Bold, Italic and Bold Italic.

TrueType versions of Segoe and Nina are installed with Vista and Office 2007. If you don't have the Condensed version of Segoe, you can get it by downloading the Windows Mobile 6 Standard SDK.

(Windows Mobile 6 Professional or Classic includes Tahoma and Courier.)

Others

Google Android

• Droid (Ascender Corp.)

The Droid font family has a sans, a serif and a monospace version. Strangely, the sans version does not have italics.

Sans (Regular, Bold)
Serif (Regular, Bold, Italic, Bold Italic)
Mono (Regular)
Sans Asian (This is also the fallback font. Meaning it includes a glyph for all Unicode characters.)

[edit: link is corrected] You can extract the fonts from the system.tar.gz file here.

LiMo and other Linux variants

• Vera (Bitstream Inc.) and DejaVu

Bitstream gave the Vera font to the open source community. Vera has been modified and evolved into DejaVu. You can find these fonts a number of places, just google them.
 

RIM Blackberry

Did you know that Blackberry typography is the universally accepted definition of the word "awful"? I would prefer to just put my head in the sand and pretend it didn't exist - or at least looked better. But let's put the pixel policing aside, here are the fonts you have access to from Java:

• Millbank 
• Millbank Tall 
• System

All are available in Regular, Bold, Italic and Bold Italic, AFAIK. I have not found TrueType versions of these fonts anywhere.

iPhone

According to John Gruber, these fonts are included in the iPhone OS X:

• American Typewriter
• American Typewriter Condensed
• Arial
• Arial Rounded MT Bold
• Courier New
• Georgia
• Helvetica
• Marker Felt
• Times New Roman
• Trebuchet MS
• Verdana
• Zapfino

Since there is no official iPhone SDK available yet, you can only use these fonts in the browser. The way to get these fonts is of course to own a Mac. (Btw, I have a really, really nasty case of MacBook Air lust and I'm trying to convince my wife that we need yet another computer in the house.)

Font sizes

In Java ME you have 3 set font sizes Small, Medium and Large. With the new anti-aliased fonts, you have to measure what font size matches what phone screen size for the different manufacturers.

Get some screen dumps from the phone, open them in Photoshop and Visio (or whatever software you prefer) and measure what point size equals the font size on the phone. For example: a 240x320 screen Series 40 phone uses font heights of 16, 20 and 24 pixels. This equals a point size of 16, 21 and 25 in Photoshop.

In a phone web browser you can specify the font size, but how its rendered is dependent on the capabilities of both the phone and the browser. It ranges from a single font size for all text to continuously variable size. I don't think it makes sense to spend a lot of time in Photoshop designing mobile web pages.

The entire mobile font size/screen size issue is somewhat complex and I'll try to cover it in a future blog post.

iPhone will attack Sony Ericsson but lose out to Nokia in Europe

This blogger has moved!

I want to invite you to my new gig over at Light Thinking. We are devloping light gadgets for photographers. You can't be a designer and not be into photography at some level. Maybe you know about the whole off-camera strobe movement that originated over at at strobist? Maybe you even know about the new HDSLR cameras and all the amazing stuff people are doing with them? Visit Light Thinking

 

The iPhone is called a Smartphone by the US press. This is a misnomer, but it doesn't really matter. When the iPhone is introduced in Europe in a few months, its is initially going to compete with Feature Phones from Sony Ericsson and Nseries "multimedia computers" from Nokia. My prediction: The iPhone will give Sony Ericsson a severe beating, but will eventually lose out to Nokia.

This is what the manufacturers are thinking about their high-end phones:

• The device philosophy of Sony Ericsson is: Phones with one additional feature. Sony Ericsson have their "Walkman" series of music phones and their "Cybershot" series of camera phones.
• The device philosophy of Nokia is: The mobile phone is the new computer. The Nseries phones are "open platform devices" where you can connect to any network and install whatever software, service or life hack you need to support your digital lifestyle.
• The device philosophy of Apple is: Phone, iPod and Internet device on a closed platform.
  

The iPhone is currently a closed device with very basic functionality, but it has turned the "mobile phone world" on its head. Its a beautiful but expensive device. It does not do a lot, but what it does, it does better that anyone else.
Sony Ericsson makes a lot of money from their Walkman branded phones, phones that are marketed as music players. The only problem is that they are truly miserable music players compared to the iPhone. The iPod and the iTunes ecosystem has set the standard for portable music players and Sony Ericsson does not even come close.

The trouble with the Sony Ericsson Walkman phones is not the phones themselves. The trouble is that Sony Ericsson depends on the operators to deliver the music to the phones and the operators are messing up. The experience of putting a song onto a handset , whether it is by downloading over the air or by side loading from a PC, is just poor. This has led to speculations recently; people buy phones for their music playing capabilities, but are they actually playing music on them?

Apple does not suffer the same operator dependence when it comes to user experience for the music player. Any customer who want a phone + music player device is likely to select the iPhone over a Walkman phone. This may force Sony Ericsson to lower prices.

Nokia on the other hand is taking steps to avoid the operator trap that Sony Ericsson currently sits in. How? Well, by copying Apple. According to Anssi Vanjoki (the guy with the $103,600 speeding ticket) Nokia will "copy with pride". And why not? As Russel Beattie points out in his (too busy but otherwise excellent) blog:

...it will take Apple several *years* to come up with a competing product that has anywhere near these level of features. Apple just doesn't have the mobile hardware chops to do it themselves. [...] They don't have the experience, know how or partnerships to get it done and still be profitable.

As I have pointed out before, the iPhone ease-of-use is nothing magic. Apple has done a fantastic job, and the most fantastic part is that here is a company that has the balls to actually do it.

But Apple has created a closed walled garden product and who wants to live in a walled garden? Tying the device to a particular operator, not letting anyone install as much as a small Java game or a ringtone on the device without Apples consent?? Please! Do you think we live in Albania or the US or something?

Nokia have to do 3 things right to rule the universe:

1. Get their user interface together and
2. deliver an operator independent experience as delightful as iTunes
3. on a open device

EDIT: fixed the loose/lose typo.

News on the softkey front

This blogger has moved!

I want to invite you to my new gig over at Light Thinking. We are devloping light gadgets for photographers. You can't be a designer and not be into photography at some level. Maybe you know about the whole off-camera strobe movement that originated over at at strobist? Maybe you even know about the new HDSLR cameras and all the amazing stuff people are doing with them? Visit Light Thinking

 

Things are finally shaping up on the softkey front. Motorola, Nokia and Sony Ericsson is converging on the context aware default action for the middle softkey.

Sony Ericsson

Sony Ericsson recently announced that they will introduce a new softkey layout and a different menu scheme for the upcoming JP-8 phones. JP stands for Sony Ericsson Java Platform and JP-8 is the most recent. It is notable for JSR 248 (Mobile Service Architecture) support. MSA aims to dramatically lower the device fragmentation issues that has plagued Java ME from the start.

(image: Sony Ericsson)

Note the entirely new menu scheme

(images: Sony Ericsson)

Compare the Z610 (old layout) to the Z750 (new layout).

Motorola

Motorola has launched the Z8. This phone runs Symbian and UIQ. The user interface was developed by UIQ and Sagem their UK Sendo team.

(image: Motorola)

As you see from the image, the phone uses 3 softkeys and the context aware default action. (They proceed to mess it up right there on the first screen by adding "Camera" on the right menu button. Using a softkey to do a mode switch is completely misguided and a standing invitation to usability problems. Its probably added by some ignorant in the marketing department.)

For all my Motorola-bashing, I still think the Z8 looks like a great phone and I'm going to try to get my hands on one.

Nokia

Nokia did get its menu system for Series 40 into good shape after a couple iterations.

Now, it looks like Series 60 also will be taking full advantage of the middle softkey in addition to a number of other UI enhancements. Series 60 3rd Edition feature Pack 2 will be released in Q3 2007.

(image: Nokia)

Screen dump from Series 60 3rd Edition feature Pack 2.