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.

The Volkswagen of Mobile Phones?

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

 

Google co-founders Larry Page and Sergey Brin appeared on rollerblades at the G1 announcement. Being true nerds, this is of course not random. Maybe a bit far fetched, but my guess is that it’s probably a poke at Apple, saying “You have turned into a bunch of elitists. Android is the phone for ‘the rest of us’”.

 

Bill Verplank tells this story:

25 years ago we asked Apple: If the Macintosh was a car, what kind of car would it be?

"Oh, it’s a Beetle (a Volkswagen Bug) who thinks it’s a BMW."

What will it be in the future?

They all agreed that it was going to be some kind of rollerblades.

 

(Volkswagen is German and literally means “[The] People’s Car”.)

PS: If you don’t know about Bill Verplank, you should check him out. For example this podcast: Bill Verplank interviewed by Jared Spool

Come to the Dark Side. We have cookies.

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 have accepted an offer from Vodafone Group to work in their User Experience team in London.

Crazy, I know. I've certainly done my part of operator-bashing over the years and expressed healthy and loud skepticism on how operators have acted arrogant and clumsy. Now, I'm meeting myself in the door with a resounding thump! (I'm not sure how well that proverb translates... you get the Zen of it!)

But, I got to admit it, I'm excited about this! It's going to be interesting to be sitting on the "other side of the table". And working on applications and services that goes out to 260 million users certainly has its appeal!

Ecosystem

Speaking of tables, a lot of musical chairs is going on at the moment. The current "Internet ecosystem" looks like this (simplified):

Hardware	Network	Applications
Commodity	Commodity	Unique

A lot of value is generated in the "Applications" box. This is where Google, Ebay etc. resides. However, for the majority of the players, the value of their software can't be monetized directly. It is monetized indirectly via advertising. (Advertising revenues is also the driver for most innovation on the Internet and this can be troublesome if we are facing a global recession).

If we compare this to the mobile ecosystem:

Hardware	Network	Applications
Unique	Commodity	Not much here, really. Core applications are embedded in the handset.

In the "Internet ecosystem", after people have bought a computer and a broadband connection, they go out and buys software and uses services that generates revenue. In the "mobile ecosystem", after people have bought their phone and their subscription (often the same purchase in most countries), they don't buy anything else. The core functions are already in the phone and they can't be changed. Android promised to change this, but they have hit a few bumps in the road.

But what about the App Store, you say? Back in March I predicted a $22 per user turnover and now that seems likely according to Apple. And this is direct monetization. People are actually paying for software.

For the "Internet ecosystem" to work in the mobile space the operators and phone manufacturers has to be commoditized, meaning that they have to support standardized common runtimes like web browsers. Or do they? Many seem to believe that the mobile platform that attracts the most developers will win. A complete reversal of the current model is required for this to be true.

Not only is there a battle rising over that third "Applications" box, over the last 8-10 years we have seen half-hearted and failed attempts to create a working mobile ecosystem. So forget the value-chain, now the thing is to provide door-to-door services ala Apple. Environments that looks "open" but is run by a benevolent dictator.

Is it the manufacturers  like Nokia with Ovi, Apple with AppStore that are going to win? Is it the operators with their portals and pre-installed software that are going to win? Or will the winner be Google and the "mobile web" guys?

What I think? Call me wide-eyed, but I believe the end users are going to win.

The usability of Gmail for mobile

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

 

Hey Google, now that you have Google on the iPhone out of the way, could you take another stab at Gmail mobile? Here is a couple of issues that needs to be addressed.

Mobile User Experience according to Google

Leland Rechis presented Googles Mobile User Experience Strategy in a talk in NYC last year:

1. Understanding users, anywhere, anytime 
2. Fits in your pocket 
3. More personal than the PC 
4. Consistency across modes 
5. Localization is intensified 
6. Integrated devices, modes, products

Nothing revolutionary, but mostly sound principles. For a utility application like email the core is: Can the user get the information, and fast? Answer this question and you're far ahead of everyone else.

Gmail mobile is the kind of application that lends itself to a Activity-Centered Design. It certainly don't try to make the experience fun or interesting, the approach is: get the job done with a minimum of hassle. Gmail should be evaluated on these premises. Btw, I'm using version 1.5 on a N95.

The positive

Gmail mobile in general is a great app. Its a painless install, it starts reasonably fast, it is responsive and does not freeze your phone while it's retrieving mail. This is good. If you know Gmail from the fixed web, you recognize it immediately. Gmail organizes your mail in conversations. This is great, way better than organizing emails in folders. Gmail carries this over to mobile. The primary activities for most users are checking and reading email, and this main use case is well executed.

I managed this only once

The not so positive

The bad news is that Gmail stumbles when it comes to the secondary use cases: Searching mail and Composing mail.

Don't lose my text

Text entry on a mobile phone is hard for most users and one of the most important rules in mobile development is: "Thou shalt not mess up thy users data". Mobile use is fragmented. Suddenly the phone rings, the cab arrives, your bike tilts, you mistakenly hit the red button because a velociraptor bumped into you, whatever the reason.

It's easy to close Gmail. Hit the red button (End Call) and its gone. If you receive a phone call and hit the red button twice when you hang up, Gmail closes.

This is fine. What is not fine is that Gmail also loses the mail you were in the middle of typing. I think Gmail tries to save, but it's buggy. I managed to recover the mail once out of 10 tries.

Composing mails

Adding recipients is clumsy with several screens, a lot of clicking and separate functions for entering email addresses or selecting from "most contacted" or "all recipients". All of this could be done much more elegantly in a single screen with a continuous filter.

The built-in Address Book on my phone is full of email addresses, but there is no way add recipients from the Address Book. This not a technical problem, and it would be a useful feature in my case.

It's only possible to have a single draft. Mobile drafts and drafts in Gmail on the web is not related. I'm not sure I understand the reason for this.

Search don't work

Search Results Page

Conversations can grow long, especially if you subscribe to mailing lists, you can easily have 100 emails in a conversation.

If you search for something Gmail will return the conversation, not the individual email containing the word. It will tell you that "somewhere in these 100 mails we found your search term". Gmail does not highlight the hits in the text either, so you have to manually open each email and look for the text. Sort of ironic that Google can't get search right, but there you go.

A basic rule of an SRP (Search Results Page) is that it should display the results in an easily scannable way. The SRP uses a dual line list, and one improvement could be to display the search text in context on the second line. Another could be to use triple line lists. And the results should show the actual mails, not the first mail in a conversation.

Inconsistent use of UI controls

Adding recipients is clumsy

Who sets the standard anyway? If you make a desktop application, you are wise to follow the UI style of the OS, be it Mac, Windows or something else. The assumption is that users are familiar with how buttons, menus, windows etc. behave elsewhere on their computer so you are doing yourself and your users a disservice by introducing a different behavior.

The same goes for mobile. Many developers goes to great lengths to make their application behave consistently across different handsets. This is misguided. You should make your application consistent with the mobile OS it runs on. That means that your application will behave slightly different on different handsets.

Google tries to be consistent across handsets, and that means that Gmail won't feel completely home for anybody.

One example of this is that Gmail uses the left arrow key as a Clear key. Instead of using the Clear key that exist on the majority of phones, and implement a multimode right soft-key on phones that does not have it like Series 40. There is no phone in the universe that uses the left arrow key as a Clear key. Lazy mans solution, I say!

I guess a verdict would be that reading emails works great, the rest needs work.

Color me silver: The Android mobile OS

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

 

Insanely great news today. Google announced Android and the Open Handset Alliance.

Not earth shattering for those who have followed the rumor mill. The biggest news is actually that they are offering what the rumors said! That, and the long list of Open Handset Alliance partners.

Why is this great?

Android does not differentiate between the phone's core applications and third-party applications.

Don't think the built-in address book is any good? Don't think that SMS, MMS, email and belongs in separate in-boxes and not connected to the address book? With Android you would be able to replace the application on your phone - just like you can on your PC. A totally open platform was the rumor and the Open Handset Alliance has promised to deliver on it.

Wired: User-friendly, Tired: Mobile Web 2.0

One very interesting thing to note is that Google is not going down the RIA route. No web applications. This jives with what they have done before, The current Gmail mobile is a native or Java ME (depending on handset). Current mobile web-browsers are just not up to delivering a satisfactory user experience, and it does not look like the Android browser will be either, at least not in its first incarnation.

The joint press release states:

This alliance shares a common goal of fostering innovation on mobile devices and giving consumers a far better user experience than much of what is available on today's mobile platforms.

The press release is sprinkled with references to users and consumers, and barely no mentioning of operators. In fact, the press release mentions the word "user" 16 times. User-friendly is the new Thin. Lets all rejoice! :-)

Will it ship?

Four handset manufacturers have committed to deploying handsets in the second half of 2008. Two of them, Samsung and Motorola, have joined just about every Linux alliance under the sun. They are both going to ship phones with 3-4 different Linux versions next year if they are going to keep their promises to everybody. They are obviously going to have to break some hearts. Is Android the OS to end all mobile Linux woes? Yes it is. Open software initiatives is notorious for producing half baked barely usable software. It needs a benevolent dictator who funds the effort and pays people to lift a product from nerd stage to a usable product. Google has the money and the will to make this happen.

The swedes are everywhere it seems

Without brilliant engineers we would still be living in caves. But without brilliant designers, we would long to go back to the caves (substitute elegant English wording here).

This is exciting times for mobile software development. The phones are getting touch screens and all sorts of motion sensors enabling new interaction paradigms based on gestures. It was fun to see the "Introducing Android" video. I expected the traditional Silicon Valley menagerie of T-shirt clad uber-geeks and hip turtleneck middle management. But there it was, a couch full of Interaction Designers and User Experience people! (All European. Scandinavian even, most of them.) The current mobile flagship product Gmail mobile is not exactly a usability poster child. (Maybe I should write a blog post about it). I am looking forward to see what those guys can come up with!!