Sender 11

Appstores: Google and RIM don't want entertainment

Appstore developers: All our charts are pointing down and to the right
The price of apps is racing to the bottom. Apple could have turned that around, but it makes no sense for them to do so. Google and RIM tries to keep the prices up but throws the baby out with the bathwater.

What is the mental model?

There are two dominant mental models for the iPhone. The consumers and Steve Jobs agree that the iPhone is a consumer gadget. The early adopter/geek and programmer is that the iPhone is a computing device.

This is not specific to the iPhone, it applies to all of the new large-screen smartphones coming to market these days. And entertainment outsells productivity tools 10 to 1.

The people who buys them do so because they want a hip and cool "must-have" gadget. In case of the iPhone, they quickly discover that it allows them to take much of their behaviour mobile. Some of the things they did on a PC can now be experienced acceptably on a mobile phone.
And regardless of all the web 2.0 hype from the digerati, the primary behaviour of mainstream consumers is still media consumption. The iPhone is designed as a media consumption device, and it excels at that.
When mainstream iPhone owners enters the App Store, they do it as media consumers. They come to browse, to  be amused and entertained. The iPhone Apps compete with spending time browsing the web, or reading a newspaper or a magazine. Spending $0.99 seems to be below a treshold where people don't have to think about the price.

Most apps bought from the App Store is used 3 times or less. How many laughs do you get out of a fart app? One or two? That's ok for $0.99.
In light of this, the recent decisions by Google and RIM to discourage low cost apps is hard to understand. Don't they want the same success as the App Store? The lowest price for an app in the RIM store is $2.49. That's too high for fart apps. RIMs customers has clearly said that they want more and better multimedia features from their Blackberries. But RIM is cutting out the main portion of Apps from their store.

Android has decided on a 48 hour free return policy. That means customers can return any app within 48 hours for a full refund. Consumers can basically download and use as many light entertainment apps they want without paying. Anecdotal evidence suggests return rates between 30 and 60%. If developers have problems making money on the iPhone Apps Store, making money from the Applications Market seems doubly hard. Its like selling a movie with a 48 hour return policy. Simple entertainment may not have a place on the Android device.

Where are the yachts of the Apps developers?

These policies are probably attempts to establish a higher price point. Whether this leads to more revenue for developers remains to be seen. But from a pure handset manufacturer perspective it does not make sense at all. Having 25.000 - practically free - apps in your App Store is an invaluable asset. Whether the average developer makes money does not matter as long as one developer in a thousand hits the jackpot. Yeah it's cold. But that is the mechanics of the current iPhone Apps Store.

Make it inviting

Conundrum:
In order to sell something, it has to be different. If is is different, it is unfamiliar, and unfamiliar stuff is hard to use. Ergo, in order to sell something, it has to be hard to use.

Problems with this:
Something does not have to be different in order to sell. People buy the same old stuff all the time. Selling the familiar or following general industry trends then comes down to marketing muscle. Who has the biggest marketing budget?

Unfamiliar stuff is not always hard to use. Familiarity is a scale, its not either or. Is is a little unfamiliar? That's ok. Is it very unfamiliar, in fact completely alien? That's not so good. Affordance and learnability is more important that ease-of-use. Make something inviting, provide natural feedback and people will learn it quickly. In fact, they will enjoy learning it. The advantage of learning something is that it gives people a sense of accomplishment. Very important motivator, and one of the strongest indicators of happiness.

Don't worry about making stuff different. Try to make it inviting.

What's your developer story?

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.

Appstores: The blind marketeer

Promoting your app in the App Store

Say you are in the business of promoting a new unknown band. Nobody has heard of this band but they have just released their first new album and it's great! Ponder this:

A) Someone walks into a record store with no particular purchase in mind, just to browse around a little. What is the chance that they walk out with your album?

B) Someone walks into a record store with their mind set on buying your album. What is the chance that you make a sale before they leave the store?

Answer: In the first case you have a snowballs chance in hell. In the latter case, you are sure to sell.

That felt kind of obvious didn't it? If you sell apps on the iPhone App Store, the lesson is the same: Try to tell people about your app before they come to the App Store. If not, you won't sell anything. Trouble is, its not as easy as it sounds.

The third man

But wait, there is a third alternative you say: If you advertise inside the store, your chance of landing a sale is a lot better.

Well, you have two options for advertising in the App Store. You can either buy one of the four available ad spots. I don't know how much these spots cost, but they are most likely expensive.

The other way of in-store advertising is figuring on one of the lists. Apple gives you a few hours on the New list "for free" before you are pushed off the list by the next batch of 180 applications scheduled for launch every day. The New list will give you a boost, but you need to be on the Top 25 list to continue selling. In order to stay on the Top 25 list, you will have to slash your price to $0.99.

This may be even more expensive than buying an ad depending on how you look at it. If you believe your app should sell for, say, $9.99, that means a cost-of-sale of $9.33 for each app you sell. Is this more or less that other means of advertising? This is an almost impossible calculation of course. What should an app cost? There are a thousand answers to that question.

You are blind

If you advertise outside the App Store there is no way to know how effective your ads are. The App Store lacks a mechanism for tracking clicks. Even URLs, the most basic concept of the web, does not work with the iPhone App Store. There is no way for a review, or a promotion, or a blog post like this to link to the app itself in the App Store on the iPhone. (It works on iTunes on the desktop.) I can tell you about a nice little app like for example Instapaper. If you click this link on your desktop, it opens iTunes with the relevant page and that nice "Buy App" button. But you can't click the same link on the iPhone and buy the app. Even if you could, the source of clicks is not reported to you (in iTunes). If you market your app 3 ways, you don’t know which marketing activity was effective and not. (Same goes for "Tell a friend". No one but Apple knows how effective this is, and they are not telling.)

This means it is a costly affair to market outside of the App Store. It is better to use the "$0.99 marketing" technique inside the App Store. This of course has the effect that everybody lowers their price to 0.99 in order to stay on the Top 25 list because this looks like the only possible marketing mechanism currently.

Is this likely to change?

It would help developers if this changed and Apple gave developers a way to measure their marketing activities. But I'm not sure Apple feels that it is in their best interest to change this. As long as there is a flood of developers willing to fill the App Store with $0.99 applications, it is not in Apples best interest to share any information with third party developers. If will probably only change if keeping developers in the blind stops the flood of new applications and threatens the market advantage of being able to tempt new iPhone customers with thousands and thousands of practically free applications.

Appstores: The new ringtone business

The credit crunch grabbed the mainstream headlines, but 2008 brought us an equally fascinating display of market mechanics: Apple launched the App Store on the iPhone and the price of applications crashed.

In the six months of its operation, more than 10,000 applications have been launched. Every day about 180 new applications appear in the store. 70% of them are paid applications, and most of them costs 99 cents. Here is a chart from Charles Teague:

 

The low price of applications frustrate developers.

Be careful what you wish for

It is perhaps ironic that Apple never intended to have neither an App Store nor any application developers for the iPhone. iPhone Apps has come about as a result of pressure from developers. When the iPhone was announced, Steve Jobs clearly stated that the iPhone was a gadget, and no one could put applications on to it. Developers would have nothing of it and started jailbreaking what they saw as a very nice application platform. The developers raised such a stink that Apple decided to give the developers what they wanted: Tools, distribution and billing.

Since then, application developers has been hard at work creating useful applications, only to realize that the only way to sell anything on the App Store was to lower the price to $0.99. It seems like no matter how useful software you make, people value it at $0.99.

Mental model

There is a “mental model issue” at work here. Developers see the iPhone as a computing platform because it runs a proper OX, has developer tools etc. Most people don't see their iPhone as a computing platform, the see it as a fancy gadget. They don't expect to use it for typical computing tasks like word processing. They buy a laptop for that. People are ok with paying what they see as a reasonable price for an office suite for their PC. Say, $150 for a word processor, a spreadsheet and some extra apps. No problem. Millions of people buy a copy of MS Office every year.

Ask them if they are ok with paying $150 for MS Office for their phone and they say no. OK, but if the price was really low… say $50? That’s only 30% of the PC price, a fantastic bargain? No? $25? $15? No? When you cut 90% off the price and people are still not interested, you know you have a problem.

Do you really take the office with you?

An office suite is of course an extreme example, but its meant to prove a point. Almost no one will buy a word processor and a spreadsheet for their phone - at any price. But a laptop without a word processor and a spreadsheet is unthinkable. Office suites have been available for mobile phones for years, and they sell in very small volumes. Office tools for phones are not going to produce a new Microsoft Corp. Neither is any other sort of productivity application.

People are willing to pay for productivity features at the point of purchasing the phone, but not thereafter. They are willing to pay a premium for a phone with nice email, maps, music player, etc. while in the store. But they will not pay for the same features as downloadable applications when they come home. Maybe they will in the future, but not today.

Entertainment

On the other hand people seem more than willing to pay $0.99 to download an application that provides a little bit of amusement or entertainment value. I believe the current best-seller is an application that makes rude body noises. (Now you know what the iPhone demographic “31 year old affluent urban males” are into. In case you ever wondered...)

If you are a developer hoping to hit it rich, maybe you should stop developing that incredibly useful organizer application and get to work on the next iFart app. iOink perhaps?

Web Runtime APIs

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.

One-Two-Many

There is a common misconception that, because humans have ten fingers, they have the innate ability of counting to ten. People generally fancy that, if a child was raised by wolves, he would come to the idea of counting just by looking at his hands. (_)

Counting is not intuitive to humans, it is a learned skill. Or to be more specific, the human brain seems to naturally count objects as "one", "two", and "many". Our numbering system and number words emerged fairly late in the evolution of human society and was due to "socioeconomic factors" (Fancy word. But I for one believe it was the tax man.)

Counting is by no means important for our survival. In fact, entire societies has come and gone without having pretty basic math skills like the ability to count to more than 3, understand abstract numbers or the concept of zero.

Our brains has a pretty vague sense of numbers. Looking at a pile, is there seven or eight apples in that bowl? Hard to say without looking close and count. A simple thing like subtracting six from eleven takes a little bit of conscious effort.

Tons of research (scientific term) shows that our brain is content with this limited scheme. One-two-many may be the innate capacity granted to us for handling plurality. Language reflects our cognitive processes and examples of one-two-many is easy to find in most all languages.

 

Denise Schmandt-Besserat, Before Writing

Time flies like an arrow, fruit flies like a banana

I've noticed this one-two-many scheme seems to be dominant in other mental processes also. When we think past events, we seem to group events into "now", "near past" and "distant past". While we obviously have the (learned) ability to precisely specify a point in time (Friday 18th of May, 1987 at 12:34 PM), this is not how we mentally store of even think about events. When we think of some past event, we don't seem to store it on a timeline at all. We have an emotional anchor that enables us to recall the event, but it's not tied to a timeline, it is always anchored to a person or object. Unless you spend a lot of time thinking about your past, you probably have a pretty coarse notion of when, and in what order, past events occurred.

Time, as it is expressed in the grammatical machinery of language differs from Newtonian time in not being measurable in units. […] The imprecision in the way language expresses time is related to the imprecision in the way we experience and remember it.

(Steven Pinker, The Stuff of Thought)

As Jared Spool pointed out, and most usability testers can attest to, a test subject will claim a website loads quickly if he is able to find what he is after, but will claim it loads slowly if he can't find it. The passing of time is subjective. Time flies when we have a good time, but a minute feels like an hour in a dentists chair.

If I held you any closer, I'd be on the other side of you

Ok, we have trouble with counting, we can't keep time, but we are pretty good at estimating distance, right? Sadly no, the same effect seems to govern our notion of distance. According to our language, objects seem to be mostly either here, there or far away. That our perception of time and distance is similar should not be a surprise, as we often use space as a metaphor for time. We talk about the length of time, timeframes, the past is behind us, the future in front, etc.

So

So I think it could be worth exploring how our one-two-many thinking brain should influence user interface design. There is nothing in our nature that dictates that a timeline must be linear. On the contrary, the further in the future or past, the coarser our sense of time is. There is nothing that suggests that we need much precision when representing spatial relations either. Our mental image of our surroundings is probably more like a tube map with nodes for relevant places and nothing like a geographic map with correct scale and distance. And designers spread out objects in nice even grids floating in space anchored to absolutely nothing, when sometimes a big uneven pile on the floor would be better and more approachable.

Design by committee

Bjørn Rybakken has a take on design-by-committee in his excellent new book Formsans og Design. Enjoy:

 

Unfortunately the book is only available in Norwegian, I'm not aware of plans to publish it in english. (The shaky translation of the illustration is mine).

Mobile software with an attitude

It’s really hard to create polite software for mobile phones.

What purpose does your software have? Is it to enhance productivity, empower users, move stuff from the inbox to the outbox? Is it to keep its owner informed and up to date on the latest news? Is it to maintain a Bluetooth connection between the phone and the laptop?

Should your software be upbeat and helpful, should it be efficient and toned down, or should it simply be invisible and out of the way? Software has a predominant manner of representing themselves to the user. Programs whose appearance and behaviour conflict with their purpose will seem jarring and inappropriate, like a clown at a wedding, to quote Alan Cooper.

(I have quoted liberally from the iPhone Human Interface Guidelines and especially from Alan Coopers book About Face throughout this post. Both are necessary reading.)

 

Application posture

Cooper describes three application postures:

Sovereign posture programs takes over the entire screen, for example a spreadsheet or a word processor. Since Sovereign posture programs are used for extended periods of time, the users tend to be quite familiar with the program. Speed and efficiency is far more important than ease-of-use. Colours are muted and it's OK to display a large number of UI controls. Toolbars? Bring them on!

Programs having Transient posture come and go. They perform a single, high-relief function with a tightly restricted set of accompanying controls. A printing dialogue box could be an example. Transient posture requires clear, easy-to-understand appearance and use. Bold and large is good. Come and go quickly. The taxicab of applications.

Cooper also groups desktop widgets/gadgets with transient apps. The purpose of desktop widgets is to give easy access to changing information with zero interaction. A desktop widget should be easily glanceable while staying out of the way so you could argue it had more in common with the next posture:

Daemonic posture is a program that normally doesn't have a screen presence or lives in a control panel. It's mostly invisible, doing its thing in the background. Only when important events or errors happen does the daemonic program alert the user.

Mobile application types

Apple doesn't talk about postures but suggests 3 different application types; Productivity, Utility and Immersive.

A Productivity Application enables tasks that are based on the organisation and manipulation of detailed information. People use productivity applications to accomplish important tasks. Mail is a good example.
Data is often organised hierarchically and the user interaction model in a productivity application  typically consists of organising the list, adding to and subtracting from the list, and drilling down through successive levels of detail until the desired level is reached, then performing tasks with the information on that level

A Utility Application performs a simple task that requires a minimum of user input. People open a utility application to see a quick summary of information or to perform a simple task on a limited number of objects. The Weather application is a good example of a utility application because it displays a narrowly focused amount of information in an easy-to-scan summary.
A utility application tends to organise information into a flattened list of items; users do not usually need to drill down through a hierarchy of information. The user interaction model for a utility application is very simple: Open, scan information, close. Optionally, change settings.

An Immersive Application is what it sounds like; full-screen video, fun and games.

Mobile application postures?

Are Coopers postures relevant for mobile? Yes, to a large degree. Sovereign posture is relevant in for example email applications. Use the pixels efficiently and provide as many shortcuts as you can.

Transient postures are for all types of dialogs like “send this picture as an email”, and for the current crop of mobile widgets. Daemonic postures for the battery indicator and the SMS alert.

The trouble is of course that the choices 3rd party developers have when developing an application is the following:

A little bit exaggerated perhaps, but true in essence. All the iPhone application types have sovereign posture. The reason is because that it is the only way to build apps on that phone. The same goes for Nokia, Samsung, Sony Ericsson (albeit to a slightly lesser degree).

If you want to build a weather app and you think it makes sense to add it into the calendar? Or maybe add it to the idle screen? Sorry, you have to build a full screen weather app. Want to build a sync app and add it as a menu choice in the phone book? Sorry. Want to build an image manipulation app and plug it into the camera app? Sorry.

There is no basic human right that says that you should be able to plug your software into anyone else's. No one is required to open up their apps or data to others. But for smartphones, that is the smart thing to do. It is hard for one piece of software to serve all users’ goals. Let applications behave cooperatively. It works on the internet…

Efforts

There are some examples of efforts towards different behavioural stances in mobile apps. See for example a previous post about living icons (read the comments).

Google made a search app that is available from the idle screen.

Photo from www.allaboutsymbian.com

For the most part, current phones have siloed applications built with a Single Document Interface. Do you have examples of applications that successfully integrate or cooperates? Please share in the comments.

The Volkswagen of Mobile Phones?

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

Appstores: Google and RIM don't want entertainment

Appstore developers: All our charts are pointing down and to the right
The price of apps is racing to the bottom. Apple could have turned that around, but it makes no sense for them to do so. Google and RIM tries to keep the prices up but throws the baby out with the bathwater.

What is the mental model?

There are two dominant mental models for the iPhone. The consumers and Steve Jobs agree that the iPhone is a consumer gadget. The early adopter/geek and programmer is that the iPhone is a computing device.

This is not specific to the iPhone, it applies to all of the new large-screen smartphones coming to market these days. And entertainment outsells productivity tools 10 to 1.

The people who buys them do so because they want a hip and cool "must-have" gadget. In case of the iPhone, they quickly discover that it allows them to take much of their behaviour mobile. Some of the things they did on a PC can now be experienced acceptably on a mobile phone.
And regardless of all the web 2.0 hype from the digerati, the primary behaviour of mainstream consumers is still media consumption. The iPhone is designed as a media consumption device, and it excels at that.
When mainstream iPhone owners enters the App Store, they do it as media consumers. They come to browse, to  be amused and entertained. The iPhone Apps compete with spending time browsing the web, or reading a newspaper or a magazine. Spending $0.99 seems to be below a treshold where people don't have to think about the price.

Most apps bought from the App Store is used 3 times or less. How many laughs do you get out of a fart app? One or two? That's ok for $0.99.
In light of this, the recent decisions by Google and RIM to discourage low cost apps is hard to understand. Don't they want the same success as the App Store? The lowest price for an app in the RIM store is $2.49. That's too high for fart apps. RIMs customers has clearly said that they want more and better multimedia features from their Blackberries. But RIM is cutting out the main portion of Apps from their store.

Android has decided on a 48 hour free return policy. That means customers can return any app within 48 hours for a full refund. Consumers can basically download and use as many light entertainment apps they want without paying. Anecdotal evidence suggests return rates between 30 and 60%. If developers have problems making money on the iPhone Apps Store, making money from the Applications Market seems doubly hard. Its like selling a movie with a 48 hour return policy. Simple entertainment may not have a place on the Android device.

Where are the yachts of the Apps developers?

These policies are probably attempts to establish a higher price point. Whether this leads to more revenue for developers remains to be seen. But from a pure handset manufacturer perspective it does not make sense at all. Having 25.000 - practically free - apps in your App Store is an invaluable asset. Whether the average developer makes money does not matter as long as one developer in a thousand hits the jackpot. Yeah it's cold. But that is the mechanics of the current iPhone Apps Store.

Make it inviting

Conundrum:
In order to sell something, it has to be different. If is is different, it is unfamiliar, and unfamiliar stuff is hard to use. Ergo, in order to sell something, it has to be hard to use.

Problems with this:
Something does not have to be different in order to sell. People buy the same old stuff all the time. Selling the familiar or following general industry trends then comes down to marketing muscle. Who has the biggest marketing budget?

Unfamiliar stuff is not always hard to use. Familiarity is a scale, its not either or. Is is a little unfamiliar? That's ok. Is it very unfamiliar, in fact completely alien? That's not so good. Affordance and learnability is more important that ease-of-use. Make something inviting, provide natural feedback and people will learn it quickly. In fact, they will enjoy learning it. The advantage of learning something is that it gives people a sense of accomplishment. Very important motivator, and one of the strongest indicators of happiness.

Don't worry about making stuff different. Try to make it inviting.

What's your developer story?

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.

Appstores: The blind marketeer

Promoting your app in the App Store

Say you are in the business of promoting a new unknown band. Nobody has heard of this band but they have just released their first new album and it's great! Ponder this:

A) Someone walks into a record store with no particular purchase in mind, just to browse around a little. What is the chance that they walk out with your album?

B) Someone walks into a record store with their mind set on buying your album. What is the chance that you make a sale before they leave the store?

Answer: In the first case you have a snowballs chance in hell. In the latter case, you are sure to sell.

That felt kind of obvious didn't it? If you sell apps on the iPhone App Store, the lesson is the same: Try to tell people about your app before they come to the App Store. If not, you won't sell anything. Trouble is, its not as easy as it sounds.

The third man

But wait, there is a third alternative you say: If you advertise inside the store, your chance of landing a sale is a lot better.

Well, you have two options for advertising in the App Store. You can either buy one of the four available ad spots. I don't know how much these spots cost, but they are most likely expensive.

The other way of in-store advertising is figuring on one of the lists. Apple gives you a few hours on the New list "for free" before you are pushed off the list by the next batch of 180 applications scheduled for launch every day. The New list will give you a boost, but you need to be on the Top 25 list to continue selling. In order to stay on the Top 25 list, you will have to slash your price to $0.99.

This may be even more expensive than buying an ad depending on how you look at it. If you believe your app should sell for, say, $9.99, that means a cost-of-sale of $9.33 for each app you sell. Is this more or less that other means of advertising? This is an almost impossible calculation of course. What should an app cost? There are a thousand answers to that question.

You are blind

If you advertise outside the App Store there is no way to know how effective your ads are. The App Store lacks a mechanism for tracking clicks. Even URLs, the most basic concept of the web, does not work with the iPhone App Store. There is no way for a review, or a promotion, or a blog post like this to link to the app itself in the App Store on the iPhone. (It works on iTunes on the desktop.) I can tell you about a nice little app like for example Instapaper. If you click this link on your desktop, it opens iTunes with the relevant page and that nice "Buy App" button. But you can't click the same link on the iPhone and buy the app. Even if you could, the source of clicks is not reported to you (in iTunes). If you market your app 3 ways, you don’t know which marketing activity was effective and not. (Same goes for "Tell a friend". No one but Apple knows how effective this is, and they are not telling.)

This means it is a costly affair to market outside of the App Store. It is better to use the "$0.99 marketing" technique inside the App Store. This of course has the effect that everybody lowers their price to 0.99 in order to stay on the Top 25 list because this looks like the only possible marketing mechanism currently.

Is this likely to change?

It would help developers if this changed and Apple gave developers a way to measure their marketing activities. But I'm not sure Apple feels that it is in their best interest to change this. As long as there is a flood of developers willing to fill the App Store with $0.99 applications, it is not in Apples best interest to share any information with third party developers. If will probably only change if keeping developers in the blind stops the flood of new applications and threatens the market advantage of being able to tempt new iPhone customers with thousands and thousands of practically free applications.

Appstores: The new ringtone business

The credit crunch grabbed the mainstream headlines, but 2008 brought us an equally fascinating display of market mechanics: Apple launched the App Store on the iPhone and the price of applications crashed.

In the six months of its operation, more than 10,000 applications have been launched. Every day about 180 new applications appear in the store. 70% of them are paid applications, and most of them costs 99 cents. Here is a chart from Charles Teague:

 

The low price of applications frustrate developers.

Be careful what you wish for

It is perhaps ironic that Apple never intended to have neither an App Store nor any application developers for the iPhone. iPhone Apps has come about as a result of pressure from developers. When the iPhone was announced, Steve Jobs clearly stated that the iPhone was a gadget, and no one could put applications on to it. Developers would have nothing of it and started jailbreaking what they saw as a very nice application platform. The developers raised such a stink that Apple decided to give the developers what they wanted: Tools, distribution and billing.

Since then, application developers has been hard at work creating useful applications, only to realize that the only way to sell anything on the App Store was to lower the price to $0.99. It seems like no matter how useful software you make, people value it at $0.99.

Mental model

There is a “mental model issue” at work here. Developers see the iPhone as a computing platform because it runs a proper OX, has developer tools etc. Most people don't see their iPhone as a computing platform, the see it as a fancy gadget. They don't expect to use it for typical computing tasks like word processing. They buy a laptop for that. People are ok with paying what they see as a reasonable price for an office suite for their PC. Say, $150 for a word processor, a spreadsheet and some extra apps. No problem. Millions of people buy a copy of MS Office every year.

Ask them if they are ok with paying $150 for MS Office for their phone and they say no. OK, but if the price was really low… say $50? That’s only 30% of the PC price, a fantastic bargain? No? $25? $15? No? When you cut 90% off the price and people are still not interested, you know you have a problem.

Do you really take the office with you?

An office suite is of course an extreme example, but its meant to prove a point. Almost no one will buy a word processor and a spreadsheet for their phone - at any price. But a laptop without a word processor and a spreadsheet is unthinkable. Office suites have been available for mobile phones for years, and they sell in very small volumes. Office tools for phones are not going to produce a new Microsoft Corp. Neither is any other sort of productivity application.

People are willing to pay for productivity features at the point of purchasing the phone, but not thereafter. They are willing to pay a premium for a phone with nice email, maps, music player, etc. while in the store. But they will not pay for the same features as downloadable applications when they come home. Maybe they will in the future, but not today.

Entertainment

On the other hand people seem more than willing to pay $0.99 to download an application that provides a little bit of amusement or entertainment value. I believe the current best-seller is an application that makes rude body noises. (Now you know what the iPhone demographic “31 year old affluent urban males” are into. In case you ever wondered...)

If you are a developer hoping to hit it rich, maybe you should stop developing that incredibly useful organizer application and get to work on the next iFart app. iOink perhaps?

Web Runtime APIs

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.

One-Two-Many

There is a common misconception that, because humans have ten fingers, they have the innate ability of counting to ten. People generally fancy that, if a child was raised by wolves, he would come to the idea of counting just by looking at his hands. (_)

Counting is not intuitive to humans, it is a learned skill. Or to be more specific, the human brain seems to naturally count objects as "one", "two", and "many". Our numbering system and number words emerged fairly late in the evolution of human society and was due to "socioeconomic factors" (Fancy word. But I for one believe it was the tax man.)

Counting is by no means important for our survival. In fact, entire societies has come and gone without having pretty basic math skills like the ability to count to more than 3, understand abstract numbers or the concept of zero.

Our brains has a pretty vague sense of numbers. Looking at a pile, is there seven or eight apples in that bowl? Hard to say without looking close and count. A simple thing like subtracting six from eleven takes a little bit of conscious effort.

Tons of research (scientific term) shows that our brain is content with this limited scheme. One-two-many may be the innate capacity granted to us for handling plurality. Language reflects our cognitive processes and examples of one-two-many is easy to find in most all languages.

 

Denise Schmandt-Besserat, Before Writing

Time flies like an arrow, fruit flies like a banana

I've noticed this one-two-many scheme seems to be dominant in other mental processes also. When we think past events, we seem to group events into "now", "near past" and "distant past". While we obviously have the (learned) ability to precisely specify a point in time (Friday 18th of May, 1987 at 12:34 PM), this is not how we mentally store of even think about events. When we think of some past event, we don't seem to store it on a timeline at all. We have an emotional anchor that enables us to recall the event, but it's not tied to a timeline, it is always anchored to a person or object. Unless you spend a lot of time thinking about your past, you probably have a pretty coarse notion of when, and in what order, past events occurred.

Time, as it is expressed in the grammatical machinery of language differs from Newtonian time in not being measurable in units. […] The imprecision in the way language expresses time is related to the imprecision in the way we experience and remember it.

(Steven Pinker, The Stuff of Thought)

As Jared Spool pointed out, and most usability testers can attest to, a test subject will claim a website loads quickly if he is able to find what he is after, but will claim it loads slowly if he can't find it. The passing of time is subjective. Time flies when we have a good time, but a minute feels like an hour in a dentists chair.

If I held you any closer, I'd be on the other side of you

Ok, we have trouble with counting, we can't keep time, but we are pretty good at estimating distance, right? Sadly no, the same effect seems to govern our notion of distance. According to our language, objects seem to be mostly either here, there or far away. That our perception of time and distance is similar should not be a surprise, as we often use space as a metaphor for time. We talk about the length of time, timeframes, the past is behind us, the future in front, etc.

So

So I think it could be worth exploring how our one-two-many thinking brain should influence user interface design. There is nothing in our nature that dictates that a timeline must be linear. On the contrary, the further in the future or past, the coarser our sense of time is. There is nothing that suggests that we need much precision when representing spatial relations either. Our mental image of our surroundings is probably more like a tube map with nodes for relevant places and nothing like a geographic map with correct scale and distance. And designers spread out objects in nice even grids floating in space anchored to absolutely nothing, when sometimes a big uneven pile on the floor would be better and more approachable.

Design by committee

Bjørn Rybakken has a take on design-by-committee in his excellent new book Formsans og Design. Enjoy:

 

Unfortunately the book is only available in Norwegian, I'm not aware of plans to publish it in english. (The shaky translation of the illustration is mine).

Mobile software with an attitude

It’s really hard to create polite software for mobile phones.

What purpose does your software have? Is it to enhance productivity, empower users, move stuff from the inbox to the outbox? Is it to keep its owner informed and up to date on the latest news? Is it to maintain a Bluetooth connection between the phone and the laptop?

Should your software be upbeat and helpful, should it be efficient and toned down, or should it simply be invisible and out of the way? Software has a predominant manner of representing themselves to the user. Programs whose appearance and behaviour conflict with their purpose will seem jarring and inappropriate, like a clown at a wedding, to quote Alan Cooper.

(I have quoted liberally from the iPhone Human Interface Guidelines and especially from Alan Coopers book About Face throughout this post. Both are necessary reading.)

 

Application posture

Cooper describes three application postures:

Sovereign posture programs takes over the entire screen, for example a spreadsheet or a word processor. Since Sovereign posture programs are used for extended periods of time, the users tend to be quite familiar with the program. Speed and efficiency is far more important than ease-of-use. Colours are muted and it's OK to display a large number of UI controls. Toolbars? Bring them on!

Programs having Transient posture come and go. They perform a single, high-relief function with a tightly restricted set of accompanying controls. A printing dialogue box could be an example. Transient posture requires clear, easy-to-understand appearance and use. Bold and large is good. Come and go quickly. The taxicab of applications.

Cooper also groups desktop widgets/gadgets with transient apps. The purpose of desktop widgets is to give easy access to changing information with zero interaction. A desktop widget should be easily glanceable while staying out of the way so you could argue it had more in common with the next posture:

Daemonic posture is a program that normally doesn't have a screen presence or lives in a control panel. It's mostly invisible, doing its thing in the background. Only when important events or errors happen does the daemonic program alert the user.

Mobile application types

Apple doesn't talk about postures but suggests 3 different application types; Productivity, Utility and Immersive.

A Productivity Application enables tasks that are based on the organisation and manipulation of detailed information. People use productivity applications to accomplish important tasks. Mail is a good example.
Data is often organised hierarchically and the user interaction model in a productivity application  typically consists of organising the list, adding to and subtracting from the list, and drilling down through successive levels of detail until the desired level is reached, then performing tasks with the information on that level

A Utility Application performs a simple task that requires a minimum of user input. People open a utility application to see a quick summary of information or to perform a simple task on a limited number of objects. The Weather application is a good example of a utility application because it displays a narrowly focused amount of information in an easy-to-scan summary.
A utility application tends to organise information into a flattened list of items; users do not usually need to drill down through a hierarchy of information. The user interaction model for a utility application is very simple: Open, scan information, close. Optionally, change settings.

An Immersive Application is what it sounds like; full-screen video, fun and games.

Mobile application postures?

Are Coopers postures relevant for mobile? Yes, to a large degree. Sovereign posture is relevant in for example email applications. Use the pixels efficiently and provide as many shortcuts as you can.

Transient postures are for all types of dialogs like “send this picture as an email”, and for the current crop of mobile widgets. Daemonic postures for the battery indicator and the SMS alert.

The trouble is of course that the choices 3rd party developers have when developing an application is the following:

A little bit exaggerated perhaps, but true in essence. All the iPhone application types have sovereign posture. The reason is because that it is the only way to build apps on that phone. The same goes for Nokia, Samsung, Sony Ericsson (albeit to a slightly lesser degree).

If you want to build a weather app and you think it makes sense to add it into the calendar? Or maybe add it to the idle screen? Sorry, you have to build a full screen weather app. Want to build a sync app and add it as a menu choice in the phone book? Sorry. Want to build an image manipulation app and plug it into the camera app? Sorry.

There is no basic human right that says that you should be able to plug your software into anyone else's. No one is required to open up their apps or data to others. But for smartphones, that is the smart thing to do. It is hard for one piece of software to serve all users’ goals. Let applications behave cooperatively. It works on the internet…

Efforts

There are some examples of efforts towards different behavioural stances in mobile apps. See for example a previous post about living icons (read the comments).

Google made a search app that is available from the idle screen.

Photo from www.allaboutsymbian.com

For the most part, current phones have siloed applications built with a Single Document Interface. Do you have examples of applications that successfully integrate or cooperates? Please share in the comments.

The Volkswagen of Mobile Phones?

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