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.

Mobile Design Showcases

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

 

 

Nokia has just published a document with 10 examples of what they consider good mobile design. It is a mix of applications and mobile web sites. Many of the usual suspects, but also a couple of lesser knowns. 

I do not necessarily agree with everything. (Surprise, right? :-)) One of the criteria is "Visual WOW" and Jaiku Mobile is considered "stylish". To me Jaiku Mobile looks like its designed by a MySpace user high on banana peel and bad Klingon poetry. The application runs on top of whatever Theme the user has chosen for their phone, so maybe unfair to criticize it. Anyway, "lively" was probably a design objective. Jaiku was acquired by Google last year and they closed new sign-up. So unless you know an existing Jaiku user, you won't be able to check it out. 

Fring is another of the examples. I tried it quite a while ago, but I just couldn't figure it out. Setup required me to configure my "IP telephony signaling protocol", so I backed out, thinking "maybe next version". Fring makes calls and messaging over WiFi and is a way cool concept. Maybe it's time to give Fring another try. 

Good examples and interesting evaluations. Definitely worth having a look, as the examples are some of the most used 3rd party mobile applications out there today. You can find the document here.

2D navigation on a mobile screen

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

 

Navigating large information spaces can be disorienting even on a large screen. On a small screen it should ideally be avoided, but that is not where we are headed. Increased storage capacity and higher bandwidth mean that you can have thousands of songs, images, messages and whatnot on your phone. We need good ways to interact with all this data. This post looks at 2D navigation and investigates what techniques good mobile browsers employ to make it easier to interact with large web pages.

2 dimensional content

When designing for mobile phones you often encounter situations where the content you need to display exceeds what can be shown on a single screen. For example an email message. The obvious solution is to format the text to the width of the screen and allow people to scroll the text up and down (vertically). You may choose sideways (horizontal) scrolling to let people interact with image galleries or wizards. Vertical scrolling works, horizontal scrolling works. But horizontal and vertical scrolling at the same time does not work. People get lost almost immediately.

There is one case in particular where this 2-way scrolling problem raises its ugly head, and it's called the Web. People want to be able to browse the Internet on their phone, but most web pages are meant to be displayed on much larger screens. Human eyes just can't read a page designed for a 19" screen when it's displayed on a 3" screen.

From an interaction perspective solving the "web browsing problem" is particularly hard. As pointed out elsewhere, a web browser is not exactly a natural for a mobile phone. "It would be hard to create a computing architecture more inappropriate for use over a cellular data network." (Michael Mace)

Good examples

I think it would be interesting to look at two approaches to the 2D scrolling problem. The Safari on iPhone because it currently offers the best web experience on a mobile phone and Opera Mini because it has some interesting tricks up its sleeve and it works really hard to make the web usable on very small screens.

The two browsers represent different philosophies:

Apple: Adapt the phone to the web.
Opera: Adapt the web to the phone.

Apple makes both the hardware and the software and has only one screen size to worry about. The iPhone uses direct manipulation, the user controls the browser directly with finger gestures like tap, double tap, drag and pinch. This gives a great sense of control.

Opera arguably has a harder job. Opera Mini runs on many different screen sizes, and it works on phones that has indirect manipulation. Since it's a Java ME application there are additional technical restrictions, for example the size and type of fonts Opera Mini can display.

Direct vs. indirect manipulation

On a direct manipulation device like the iPhone, you just tap anything directly.

On indirect manipulation devices, one item on the screen always has focus. You use the joystick as an intermediate device to move the focus to the item you want and click it. If the screen has 20 focusable items, for example 20 links, you may have to step through 19 links to get to the one you want.

Because of this, prioritizing is very important on a indirect manipulation device. You want to put the most important or most used stuff on top so the user has to do as little clicking and scrolling as possible.

But as we know, web pages are not designed in such a prioritized manner. The top area is usually filled with a number of links for general navigation, ads, search, etc, etc.

Example: The New York Times page shown to the right. The top headline is the 73rd link on the page. There is about 350 links before you come to the "subscribe to RSS" link. There is about 375 focusable items in total including images, forms, buttons etc (yes, I counted them).
No one is willing to step through hundreds of links. You need a strategy that makes it possible to reach any link on the page without stepping through them all.

Lesson 1: Zoom instead of scrolling

The main trick to solving the 2-way scrolling problem is to avoid it entirely. Both Safari on iPhone and Opera Mini encourages you to zoom in and out instead of scrolling. Scrolling both vertically and horizontally is disorienting. But if you shrink the content to fit the width of the screen the user won't get lost.

On the desktop, a browser usually has size and resolution enough to both display the entire width of the page and show the text in a readable size. In a phone browser it is necessary to zoom in to read and zoom out to navigate. There is basically two views for each page. The "Overview" where you navigate around the screen and the "Detail View" where you read or click links. The purpose of the Overview is avoid getting lost. Its like in a film. A scene often starts with an establishing shot, an overview of the scene before going to a close-up. The establishing shot tells the viewer that "we are now back at the mothership" and "here are the people in the scene". Without the establishing shot, the viewer might think that we were still down on Caprica.

Dual views of course require additional user interaction. In addition to scrolling, reading and clicking links, the user has to zoom in and out as well. You would be mistaken to think this bad a thing. This zoom in/out mechanism is greatly preferred by users compared to a keyhole experience. Just check how people are praising Safari and Mini. The number of clicks is not the most important parameter for user satisfaction.

Lesson 2: Throw pixels at the problem

The iPhone screen has twice as many pixels as a typical smartphone. (The screen is not physically twice as big. It is bigger, but the pixel density is also higher than most other phones.)

Pretty much all other mobile browsers are "keyhole browsers". They show a tiny part of a bigger page. Even Nokia's version of the WebKit browser takes this approach by default. You don't want the keyhole effect. Both Safari on iPhone and Opera Mini avoids the keyhole effect by showing you the entire page as default. The more pixels you have the better you can do this. Thanks to the high resolution of the iPhone, you can often read headlines and this makes it easy zoom in on what you want to read.

Safari on iPhone also attempts to provides a "pixel perfect" rendering of the page. (I know, there is no such thing as pixel perfect when it comes to browsers...).

Opera Mini runs on any screen size and can't depend on pixelcount, so it displays a rough representation. Even though you can't read the text, you see headlines, images, text columns etc. Enough to know approximately where to zoom in. This works because after two decades of conditioning, people know what the usual elements of a web page is. They have a "web page schemata".

Opera Mini renders most all text and images in columns that will fit the width on the screen when you zoom in on it. Actually, it narrows text and images that is too wide and leaves the rest as it is.

This sometimes results in "gaps" in the page overview. The iPhone displays the layout perfectly, but sometimes the text is too wide and does not fit the screen when you zoom in.

We have another philosophy difference:

Apple: If we need to sacrifice anything its certainly not going to be the web designers work!
Opera: Never mind the pixel-police, readable text is more important!

 

Lesson 3: Render for a small screen

How wide is the World Wide Web?

• The Web is currently 1024 pixels wide 
• The iPhone is 320 or 480 pixels wide 
• Smartphones are 240 pixels wide 
• Small Feature Phones are 128 pixels wide

Small Screen Rendering basically means creating a version of the web page in one single column and as wide as your mobile phone screen. Here is an example of how Opera Mini reorganizes the web page to make it easier to consume it on a small screen. 

The page has a fairly simple structure, chosen for clarity. As you can see, Mini decides what the header is, what the footer is, and what the main column is. It stacks the content to the best of its ability and scales images to fit the phone screen. (I you want a closer look at Small Screen Rendering, press Shift-F11 in the desktop version of Opera to view any web page with Small Screen Rendering.)

Safari on iPhone does not reorganize the screen, it simply zooms in on the area of the screen that you double tap on. If the column is wide and the text is to small to read, you can tilt the phone to horizontal.

Lesson 4: Follow the flow

Both Opera Mini and Safari on iPhone "snaps" to the column. Opera Mini even has this cool effect where it follows the column even when it's not straight. The browser slaloms or snakes down the column.

The magnetic or "gravitational" effect is especially important on the iPhone where you scroll by dragging or flicking. Without it, it would be very easy to scroll outside the column and lose a bit of the text on one or the other side. None of the browsers prevents you from scrolling away from the column, they just help you stay on track.

Other Zoomable User Interfaces

There is a number of other approaches to the problem of navigating large information spaces. There is an amazing demo of Photosynth at TED. Mobile examples are Deepfish, Google Maps, Zumobi, etc.