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 iPhone SDK limitations has real causes

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 huffing and puffing over limitations to iPhone 3rd party apps. Especially the "one app at a time" and "no background processes" rules. A lot of people claims that these particular restrictions does not apply to the native iPhone apps or to preferred partners that Apple lets under the tent. I would like to argue that this assumption is not correct.

Some even speculate that the reason is Steve Jobs' paranoia. I'm not privy to the mans mental state, but there is no need to search for psychologic explanations. There are real reasons for these limitations. Some hope for relief over the course of the beta period but it is unlikely that they will go away. At least on the current iPhone hardware.

 

Why no background processes?

The iPhone, as most smartphones, has a multi-chip architecture. OK, this is going to be oversimplified, but hang on. The iPhone has many CPU's and they are connected with and controlled by the central scrutinizer, the ARM 11 CPU that runs OS X. Each CPU has its own "OS", runs fairly independently and is optimized for very specific tasks. The baseband processor runs the signaling stack, the stuff that handles the communication to the cellular network. The audio codec handles the audio stream. The Wi-Fi transceiver deals with all the mechanics related to operating the Wi-Fi port. Etc, etc.

All high-priority real-time tasks run on dedicated CPUs. When needed, the main processor asks the other parts of the system to do their dance. When the music starts (!), the audio circuitry does all the hard work, and it does it much more efficiently than the general purpose ARM processor can.

When you are, say, calling, the main CPU doesn't really do much. After you have entered the number, it can pretty much idle until you hang up. (The chances of a 3rd party applications messing with the basic calling functions should be approximately zero unless they were allowed to initiate a new call or hang up in the midst of the current call.)

The system slows down, idle or shut down whatever CPUs that are not currently needed. The iPhones impressive battery life if achieved by carefully managing and slow-clocking the system. The internal hardware design philosophy in the iPhone is that the main CPU does as little work as possible and delegates tasks to specialized circuitry. If a 3rd party background process could run the main CPU constantly, this would drain battery in no time. Of course, a modern OS like OS X can deal with resources on a very detailed level, but the iPhone OS X is apparently not set up to police 3rd party apps.

 

Why only one app at a time?

Having several apps running at the same time would break the interaction paradigm of the iPhone. There is no way for people to handle multiple windows on the iPhone. iPhone apps does not have an Exit button. The way to exit an app is to press the home button which brings you to the home screen. This is the behavior that people expect and there simply is no mechanism to close an app and have the the previous app come to the foreground. The iPhone does not use the WIMP paradigm that desktop OS'es does. There are no Windows, no Menus, no Pointers. You can even argue that there are no Icons either (icons in the classic sense as "visual representation of objects you can manipulate"). This may be a bit strange for people new to mobile development.

 

Application silos

You can try the following experiments:

1. Send an SMS with a URL to the iPhone. In the SMS app, you can click the URL to open the browser, but the SMS application closes when you do. The only way to get back from the browser to the SMS app is to go to the home screen and open the SMS app again.

(Btw, Back is very rudimentary on the iPhone and there is no global history stack. See here for more about backstepping on mobile phones.)

2. If you open the Maps app from Contacts, the Contact list closes. In the Maps app, you can add to the contacts, but the Contact application is not really open, the Maps app has simply duplicated the Contact "view". The contact list view is recreated inside the Maps application. Maps can read and write data to the contact store, but Maps and Contacts are never open at the same time.

3. When you answer an incoming call, any app currently open is closed. When the call terminates, the app is brought back to the foreground but it has to reload any content. You can try this with Maps or the Safari browser.

If you pay close attention you can see that the native iPhone apps follows the same rules that are laid down for 3rd party apps.

I think its a bit unfortunate that the iPhone seem to have a strict "application silo" approach, but this architecture is probably the result of an overriding design goal of maximizing battery life. It is something 3rd party developers just have to live with. There is not really much multitasking going on on the iPhone. "One app at a time" is here to stay.

 

"The same API's as we use internally"

Any application running on a mobile phone should be prepared for immediate shutdown at any time. Best-case is you get a notification when it happens, but your app can be force-quit by the OS or by the user at any time. This is true for Symbian, Android, runtimes like Java ME, FlashLite, or WebKit. Windows Mobile may be an exception to this, I don't know WinMob too well.

If you want to create an IM application you need to store any incoming traffic on a server and any outgoing traffic on the phone. I guess we will see if my claims here are bogus when the AOL IM client ships.

It would be helpful if there was a way to request the iPhone to update the bullet for your application icon on the springboard (the home screen) with some regularity. There is obviously background processes running for receiving SMS and push mail notifications. (That does not mean that the Mail or SMS apps are running.) This notification mechanism ought to be available to 3rd parties also.

When Apple says that "it's the same API as we use internally to build iPhone applications" - this is almost correct :-) These limitations are based on hardware and software design choices and are not likely to go away during the beta period.

 

PS: Why not run everything on a single processor?

Apple could have chosen a different architecture where everything runs on the same processor. This is the architecture that Intel has been advocating for years (without much success). The advantage is lower chip count and lower BoM, but the main processor would have to run at a higher speed and the system would be less power efficient. Symbian has recently changed its architecture to allow single core designs and some low-end smartphones from Nokia now runs what is basically two operating systems on the same CPU.

DS

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.

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!!