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.

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.

Nokia + Trolltech makes a lot of sense.

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

 

There has been a lot of speculation about why Nokia has acquired Trolltech (press release), and here is more.

It's not about mobile Linux

First, Qt is not an OS and its not a software layer. Qt is a devtool that generates native apps for different platforms from the same source. Nokia is most likely going to use Qt to create applications for S60 and Series 40. It will take some time for Trolltech to add S60 and Series 40 to Qt, so this is a long term thing.

There is not going to be a Nokia Linux OS for mobile. S60 and Series 40 will continue and Qt will be the cross platform devtool. (The Maemo OS used in the Nokia internet tablets will not be affected).

Nokia has some grand plans for Ovi. They are going to do what Apple does, take a Consumer Electronics approach and create an "integrated experience" (a door-to-door service). A tight integration with Ovi  means they need for of of new features on the phones. With Qt, they won't have to maintain two separate codebases, one for the feature phones and one for the smartphones.
Also, general UI development on Series 40 could benefit.

Java for the operators

Operators want Java based tools for customizing the handsets [shudder].
Trolltech has a Java wrapper called Qt Jambi that might fit very nicely with this.
(Btw: Motorola has given up trying to sell Linux based phones to operators and are now offering Linux+Java.)

The Qtopia product is of little interest to Nokia and might be sold off.

Defragmentation?

Actually, if you think about it, this has a rather interesting defragmentation effect! Nokia has always played nice and waited for standardization and so forth. If Nokia releases this to 3rd party developers and you could deploy on 40% of the phones in the world from a single codebase, that would certainly be revolutionary.

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.

Why mobile music subscription services will work

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

 

Nokias "Comes With Music" (CWM) announcement initially got a very positive reaction when it was announced at Nokia World. After details about the service became known, the service was poo-poo'ed by many, mainly because of DRM. I believe the negative reaction is more than a little elitist, and that music subscription services like CWM will succeed when offered to the general public. Here are some reasons why.

First, what is CWM? It is a subscription service tied to the purchase of a mobile phone. When you buy the device you get a voucher for 1 year "all you can eat" music download to your PC and your mobile phone. When 1 year is over, you can no longer download new music, but you can still play the music you already have on your phone or PC. There is no "renewal" apart from buying another "Comes With Music" mobile phone. Currently Universal Music is a partner, and more labels are expected to join before the service launches around mid 2008.

Do people expect music to be free?

CWM is criticised because the music can only be played on your PC and on your mobile phone. For example by ars technica who thinks that this service would only be interesting if, for the price of $60, you were free to download all the music in the world, keep it forever and play it back on any device you want. Sure, you got to keep your dream alive, etc. But does this sound naïve to anyone else besides me?

Most people do actually place a value on music - they don't expect "too-good-to-be-true" deals.

CWM comes with DRM. Putting DRM on music files that have been bought and paid for creates a lot of problems. When people pay money to buy a specific music track and download that file, they feel that a transfer of ownership has taken place. That they now own this file and can play it whenever they want.
But if people subscribe to a service they have different expectations. Its like a magazine subscription. When you stop the subscription you are not receiving any more magazines. But you can still read the old ones. I think the DRM criticism is irrelevant in a subscription context, and it will have no impact on sales if it is marketed as a subscription service.

Digital music services are more scarce than you may think.

It seems like there is a multitude of digital music offerings: Napster, Rhapsody, Yahoo Music, Zune Marketplace, Amazon MP3, Wal-Mart, eMusic, etc, etc. But try to buy from any of these. All of them are basically US only. None of them are available world wide. The main offers in the rest of the world are iTunes (buy DRM'ed music 99c a song) and mobile operator portals( buy DRM'ed music $2 a song).

How big is the rest of the world? Let's be generous and say that the US is 10%. This means that 90% of "the market for digital downloaded music" is under-served.

People and their record collections

There is an often heard argument that people don't want this type of service because they "loose" their record collection when the service expires.
This is of course an anachronism of sorts, but it may well be one of the main causes slowing the growth of music subscription services. Looking ahead, people may not build up a record collection, but instead build up a playlist and take that playlist to the music service of their choice. I am certainly aware of the "desire for ownership", but I also believe this to some extent is a cultural issue.

Subscription services make more money for the record labels

Each iTunes customer spends $1-$2 each month buying music. Each Napster or Rhapsody subscriber spends $10 per month. (source)
My guess is as good or bad as any, but CWM probably costs Nokia between $60 and $80 per customer per year. I don't think a markup like that for "unlimited music" will be any problem in most mature markets. If the phone is subsidized, the customer will most likely not notice the cost at all.
It is likely that a lot of other record labels want to come on board. A large catalog makes the service more interesting for customers. Currently music subscription services revenue is only 20-25% of music download revenue, but this may change fast.

I believe it is likely that other device manufacturers will offer hardware, both mobile phones and PMPs,  bundled with music subscription during 2008. It will be interesting to watch this space.

Series 40 and Series 60 converging

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

 

Our test-lab just got a Series 40 Edition 5 Feature pack 1 phone, the Nokia 6500 slide, and I had a chance to play around with it.

It used to be that the Series 40 phones was the easy-to-use feature phones and the Series 60 phones was the capable, multitasking but more complex smartphones. After the last couple of software iterations this is no longer so clear cut. You can also check out the Series 40 vs S60 article over at allaboutsymbian.

Smartphone Jr.

The Series 40 is playing catch-up to S60 smartphones like the flagship N95. (Would that be a pennant-ship?) Series 40 has evolved into a "Smartphone Jr." OS, complete with several S60 user interface components not previously seen in Series 40. Nokia has always claimed that Series 60 UI is the most thoroughly user-tested mobile UI in the world. It would be very interesting to know if this is true for the Series 40 Ed5 UI as well.

The Series 40 UI is built from bitmaps and is fairly responsive. The S60 UI is vector based, its built on SVG and that may be one of the reasons why it often feels sluggish. (SVG takes a lot more time to render than bitmaps.)

 

Example of Active Idle, S60 style. The design is heavy handed and not particularly elegant. Series 40 have had Active Idle since 3rd Edition, I believe.

 

Scrolling form with spinners and Save and Cancel buttons.

Ed5 uses spinners quite liberally. Spinners are used to select between items with the left/right arrow keys. The challenge with spinners is that the user sees only the one displayed item, so it have to be obvious what the others are. Spinners works when they are used to increment or decrement a numeric value for example. In Series 40 spinners are also used as binary switches or to select among very different items. It looks like spinners now basically replaces the previous popup lists. I prefer popup lists 90% of the time.

 

Unfortunately, with Feature pack 1, tabs are now a part of Series 40. Tabs are a very useful interface metaphor for the UI designer, they always seem to solve a lot of problems. But tabs are notoriously hard to use and understand for the user.

This particular use of tabs in the download section are just broken. They come and go as you select and they make little attempt to follow the tabs metaphor.

 

Part of the XpressMusic player. The visual style is quite different in some parts of the UI. Even the menus have variations.

 

Series 40 now has a 2-level three view. (I'm skeptical to three views, but I'm not going to whine about that now.) For a three view it works ok, but this one needs a much better visualization of the hierarchy in my opinion.

The Spinners, the Tabs and the Three view are all attempts to decrease the depth of the user interface. More information is visible at the top level.

 

An interesting failure

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

 

The Nokia Podcasting application makes an interesting case. It is an application that is developed by, or at least belongs to, Nokia's "Hear New" team. Hear New is located in the upcoming Services & Software business unit and is responsible for all audible entertainment on the Nseries devices; Music purchase and download, Radio and Podcasting. (Disclaimer: I'm not privy to the internal workings of Nokia, but I think this is fairly correct.) 

What is Podcasting? It is an application offered as a download on the entire range of Nseries devices. This is how Nokia describes it: 

"The Nokia Podcasting application allows you to find, subscribe to and download podcasts over the air with your Nseries device. After downloading a podcast, you can listen to or watch it when you want."

Sounds great, right? It happens to be exactly the kind of application I need right now. I listen to podcasts daily while commuting, and podcasts is the only reason that I kept my iPod Nano around. When the Nano broke down a few weeks ago, I downloaded Podcasting to a Nokia N95 and gave it a go.

So is it any good?

To be honest: No. (I'll go through the design problems later in this post.) The application is so poorly designed it makes a grown man want to cry and stomp his feet. It is bad by any standard. I probed around some and I managed to find three people who had used it - and they all love it! Wanna know something? These guys don't count. They are not the customers you design mainstream services for. Why is that? Hear me out:

Alan Cooper talks about dancing circus bears in his book The Inmates are Running the Asylum. We are not amazed by how well the bear dances, we are amazed that the bear dances at all. Cooper claims that modern technology consists largely of dancing bears. Clumsy products that work, but don't work well. Some people don't mind that the products are clumsy, they just love the fact that something is possible at all. These people are the early adopters.

Geoffrey Moore coined the term "Crossing the Chasm" in his book by the same name. Moore claims that there is a chasm between early adopters and mainstream consumers. Early adopters tend to be visionary, they get excited by disruptive technology, they see a potential to leap ahead. The mainstream consumers on the other hand are only interested if technology offers a better way to conduct their day to day lives or businesses.

The three guys I talked to who liked Podcasting are serious geeks. They had tried it a couple of times, they were not daily users. Early adopters and mainstream consumers have very different expectations. Is Podcasting aimed at early adopters only? It could seems so, but why is it offered on a mainstream device?

Services and mobile devices often live or die on the little details of usability
Michael Mace: The war between Nokia and Apple

Why did Nokia make this podcasting application in the first place?

Software development usually starts with a phase where the purpose of the software is defined. What goals do the people who use the software have? What goals does the company that produces the software have? One of the techniques used for this is use cases. Simply stated, a use case is a description of how a user performs a task in order to achieve some goal.

The only use-case Podcasting supports is: Nokia salespeople demonstrating high data traffic podcasting to operators at conferences. (Nokia seems to produce a podcast episode at major conferences.) This is not Design for Use, its Design for Demo. Mainstream customers are not going to use it for demoing, they expect to use it for everyday tasks. Now there is nothing wrong with demoware and proof-of-concept. But turning around and offer leftovers like this to your end customers?

Should Nokia make a better Podcasting?

In this presentation at Symbian Smartphone Show 15 October 2007, Nokia’s senior VP for software platforms, Lee Williams said that according to Nokia's own studies, 4% of its S60 user was active podcast listeners.

Nokia is redefining itself as an Internet services company so I would expect podcasting to be a service Nokia was going to do a stellar job on. But I'm not a business analyst so I don't know if worrying about 4% of your customers makes business sense. But I would think it does for the following reasons:

• Podcasts are showing continuing strong growth. 
• Nokia has stated, not surprisingly, that it is firmly in the Convergionists camp. One device to do it all. You can't leave a growing segment to your arcrival. 
• At this scale, 4% means 16 million customers each year.

If Nokia wants to build an ongoing relationship with its end customers, it needs to build services for its end customers. 

What is the problem with it?

Let's look at where Podcasting stumbles when viewed as a mainstream consumer service:

Problem: It assumes the user has an understanding of the internal application structure
This is a classic problem. Here are a few examples:

Search fails - unless you do a manual update first
The app has two ways to search. Both are called "Search" and they  look identical. In reality they are very different. They can only be told apart by their hierarchical position in the application structure. Neither of them offer any clue to what will be searched. "Search" on the initial page will use the online search engine provided by DigitalPodcast.com. 

"Search" in the folder named Directories will search locally within the list of directories. But only those directories that have been manually updated by the user prior to searching. If you search without first updating the directories, your search will return zero hits. This is not mentioned anywhere, you find out by trial and error. 

Browsing podcasts
You can browse podcasts from a section called Directories. It is a collection of fairly deep folder structures where each has different organization. Some are organized by popularity, some thematically, etc. Nokia is clearly not in the business of organizing the worlds information. Fair enough. What is worse is that there is no information about the podcast except for the URL or the occasional name. What is the purpose of presenting a list like this?:

feeds.feedburner.co...
feeds.feedburner.co...
feeds.feedburner.co...
feeds.feedburner.co...
feeds.feedburner.co...
feeds.feedburner.co...

Is there a particular one you would like to subscribe to? It obviously better to drop stuff like this.

Automatic download is broken. Manual download is broken.
The application can automatically download new episodes at a set time. Unfortunately you have to start the application manually first!And should you be listening to a podcast when Podcasting checks for new episodes, Podcasting will terminate your listening, close the player without warning and mark the podcast episode as read. Since Podcasting does not remember how far you have listened, you are on your own trying to find your way back to whatever you were listening to.

There is no simple way to manually download all new podcast episodes. You have to first check for new episodes by selecting a podcast, go into the menu and select Update. Do this for every podcast, wait for Update to finish, and then go into every podcast folder and download every individual episode.

(Downloading is non-modal and this is a good thing about Podcasting. You can continue doing stuff in the app while it downloads episodes. Sounds obvious? It is not obvious in mobile context.)

Settings
You are supposed to enter some settings before using the application for the first time. The application should ask for this information the first time it runs instead of leaving it to the user to find out for himself.

If you change update interval to something else than Manual Update, the application issues a warning: "Define an access point to enable automatic updates". The user is left to figure out for himself how to "define an access point". Instead of a warning message, the application should offer the user a list of access points to select from. As it is now, the user must select a default access point (not define a new access point) from a different menu.

Functions are spread out on 3 different levels.
This is logical from a programmer perspective, but makes little sense for most users' goals with using the app.
The app has several levels. On the top level is functions like Settings, Search, Directories and Disconnect. On the next level down is Podcasts with features like Update, New podcast. On the third level is the individual podcast episodes with features like Download and Play.
There is a forth and invisible level where the audio files themselves reside. This is responsible for the odd behavior where you can mark an episode and hit Delete - and its still there. To make it go away you have to mark it a second time and hit Remove. Podcasting assumes you knows what the developer thought was the semantic difference between the words Delete and Remove. (There is none in this context.)

Poor integration
An typical use would be to visit a web site in the browser, find a podcast there and subscribe to it. This fairly innocent use case is not supported. There is no way to get an RSS feed on a web site into Podcasting.

No housekeeping

Podcasting does not care much about housekeeping. It does not remember how far you have listened into a podcast episode. It does not attempt to keep your subscriptions organized. It does not delete old podcasts.

Podcasting does however offer you to use a podcast episode as a ringtone...

Problem: It is designed and built to low standards.

The help text refers to features that does not exist in the application. Terminology is haphazard and inconsistent. You select "Subscribe" to subscribe, but "Delete" to unsubscribe. A manual Update means "check for new episodes" while an automatic Update means "download new episodes". The sign "New" does not differentiate between a feed and a downloaded episode. It does not differentiate between fully or partially downloaded episodes. You have to go to every episode and make sure its actually there. There is no auto-resume on lost connection.

The app does not crash, the programming is probably fine. Its the user experience and the usability that is the problem.

To quote Nokia's own usability advice to software developers:

"There is a crucial window of opportunity that opens up, usually soon after the user has purchased a new device, when the majority off application downloads are made. It is at that point that a poorly designed or implemented application can have a huge impact on the initial experience that the user has. Getting the "Usability Issue" right or wrong will influence many future buying decisions – a positive experience encourages the user to purchase applications again."

Nokia may build some of the best phone hardware in our part of the galaxy. But now, with the introduction of Ovi, the company is going to expand from hardware design to systems design. Nokia has not shown that they know how to create compelling mobile applications. And I still need a good podcasting application!

Nokia's new touch UI

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

 

Mobile, open development platform with touchscreen, haptic feedback, presence, GPS location, VoIP and an AJAX capable web browser. Only Google Gears is missing.

Who is this good news for?

Symbian developers rejoice, the big question is: what about Java and Browser developers?

As Dean Bubley observes; "normal people don't download applications to handsets". S60 Symbian development is a all about enterprise applications. In order to access these great new features in consumer applications, Nokia has to provide OS bindings from the browser and from Java ME. All Nokia’s senior VP for software platforms, Lee Williams said about this in his presentation yesterday was that support for cool stuff would come in an "iterative way". And if Java ME support goes thru the Java Community Process, it will take a couple of years to agree on a JSR.

Well, its certainly cool stuff here:

Nokia showed a touch UI as you have probably already seen elsewhere. It is not multi-touch, darn! The touch screen in the demo was a resistive type single point touch screen. The UI changes are evolutionary. Nokia still sees the phone as a single-hand device and they are keeping menus, they are just making them finger-sized. Nokia said they wanted to be backwards compatible, keep old application working. There is no iPhone style finger keyboard, you need to use a stylus for writing.

The new phones will support haptics. Probably by using the vibration motor. Nokia licensed this technology from Immersion earlier this summer. This is fairly primitive so don't expect any religious experiences. But its a start.

Cool gestures!

They introduced a "Sensor framework" and mentioned both motion, orientation, proximity and light sensors. They showed both motion and acceleration. A video showed a woman diverting a call by flipping over the phone while it was lying on a table. All these sensors makes gestures an additional UI component. This is very exciting and certainly opens some new opportunities for application and game developers!

You may have seen the crazy guys who made it possible to use a Wii remote to control a Nokia phone, next year you may be able to control the Wii with your Nokia phone!

Gestures are going to be user configurable.

ScreenPlay and FreeWay

ScreenPlay and FreeWay are Symbian 9.5 technologies for video acceleration and network access. Snazzy names! Something must have happened since the iPhone. Symbian used to call their stuff something like "Host Controller Transport Layer" or "Logical Link Control and Adaptation Protocol (L2CAP)".

ScreenPlay goes hand in hand with Symbian's recently announced support for Symmetric Multi Processing (SMP). SMP is basically a Duo Core processor on your phone. Current Symbian phones are painfully slow and desperately needs faster drawing speed. Thanks, iPhone!

Symbian Freeway architecture. Nokia has promised UMA devices next year. The promise is that you can move seamless between networks. It you are on the phone and move into a known WiFi zone, the call seamlessly switches to VoIP. Almost sounds too good to be true.

Flash Lite 3 was announced, that means Flash Video in the browser and will cater to all your YouTube entertainment needs. Potentially a better solution than today's awkward video playback.

Links:

Official S60 touch UI info

Video