Saturday, September 27, 2008

Wanted: Virtual Smartphones

High end cell phones such as the iPhone, the recently announced Android G1, and the about to be released Xperia X1, sell themselves in part on their software, in particular their differing user interfaces. But for most customers, the only practical way of evaluating the software is to actually get their hands on the phone—a little difficult for the two of the three that have not yet been released—and spend a fair amount of time playing with it.

There is a simple solution to this problem. A smartphone is, among other things, a computer, and most of us own computers much more powerful than any smartphone. One of the things a more powerful computer can do is to emulate a less powerful computer. I gather that (at least) Google and Sony-Ericsson have provided, as part of their software developer kits, emulators for Android and the Xperia.

My suggestion is that they should provide emulators, on the web or downloadable, targeted not at developers but at customers. I want an Android G1 on my desktop. Ideally it would not only emulate all of the software, it would also make at least a reasonable effort to emulate connectivity, not for phone calls but for the internet. And, ideally, it would make a reasonable effort to emulate the performance of the actual phone.

Some time back, I bought and then returned a high end smartphone, a Nokia E90. Part of the reason I returned it was the discovery that its word processor would only permit one document at a time to be loaded and took about ten minutes to load a book length document. Two of the things I do with my current smartphone are to read books and to go over my own manuscripts while noting on them things I want to change. That does not work very well if it takes ten minutes to change what book I am looking at. The E90 was supposed to be a much improved version of my current 9300, but in fact had strikingly inferior software, at least for my purposes. If I had had access to a reasonably realistic emulator of the E90 I could have saved myself and the seller the cost and trouble of my buying a phone and then returning it.

I am not sure if the companies producing the phones would want to make emulators available pre-release or not. On the one hand, it lets customers try for some time before they buy, and it might make possible useful feedback. On the other hand, it reduces the excitement of the release. But I can see no good reason why they would not want to make emulators available when the phone is released. Doing that should increase the excitement, since it lets customers get something close to a hands-on experience on the day of release.

Is there a technical problem I'm missing, some reason why it isn't practical to produce a reasonably accurate emulator for a smartphone?
---------------

[Added 10/6/08]

It almost looks as though someone was listening. Not a full implementation, but a step in the right direction. Thank you T-Mobile.

21 Comments:

At 12:37 PM, September 27, 2008, Blogger Mark said...

The Android SDK includes an emulator.

 
At 1:24 PM, September 27, 2008, Anonymous mjg said...

The iphone SDK also includes an emulator.

I remember a few years ago using a free emulator from Palm for a small piece of software I developed there.

Generally an emulator is a fundamental tool for any kind of embedded application development, since the hardware may be difficult to work with, or may not even exist at the the time development is being done. They are usually not targeted at consumers however, though perhaps you're right and they could be a useful marketing tool.

 
At 1:24 PM, September 27, 2008, Blogger Steamboat Lion said...

Well one thing you are missing is that user interface is also a function of the hardware. Without a touch screen (and not just any touch screen, but one that can receive multiple simultaneous inputs like the iPhone touch screen) it would be impossible to emulate the most critical and unique aspects of the iPhone user interface.

Similarly with other portable devices the user interface is often seriously compromised by the hardware choices made to reduce size and weight.

 
At 1:59 PM, September 27, 2008, Blogger David Friedman said...

Mark and mjg mention existing emulators, as did I. Do any of them attempt to emulate performance--how fast things happen? Does the Android one let me emulate the G1, or only some sort of generic Android phone (I should probably download it and see)?

I agree with Steamboat lion that an emulator wouldn't perfectly replicate the experience, but it would get a good deal of it. The MacBook touchpad can receive multiple simultaneous inputs; I don't know how it compares in that to the iPhone.

 
At 2:15 PM, September 27, 2008, Blogger David Friedman said...

I'm curious as to whether Mark has actually used the Android emulator. I just downloaded the SDK and so far as I can tell there is no way for someone not an Android programmer to do anything with it. The instructions largely assume you have Eclipse, and there is nothing I can find that you simply double click and run--just bits and pieces for building applications.

Am I missing anything? As it stands, it appears to be absolutely useless for the purpose described in my post, however useful it is for people who want to write applications.

 
At 2:24 PM, September 27, 2008, Anonymous mjg said...

Benchmarking the performance of code on the target from the development environment is pretty essential. I only have direct experience on Palm, which did a good job of simulating the timing behavior of the actual hardware.

I would be surprised if other production emulation environments didn't at least have a mode attempting to match the characteristics of the target hardware.

 
At 2:37 PM, September 27, 2008, Anonymous sportember said...

I think there is economical rather than technical problems with such "previews", emulators of smartphones. People who return electronic appliances because of bad software or usability must be quite rare. I think that most people who buy a smartphone and find it unfitting do not return it, but keep it or give it as a gift to a close relative... :-) Therefore, letting the possible users to try before buy is a bad decision economically. It is much better for the phone provider to make large noise around the phone, and sell it to as many people as possible. Some will return it occasionally, but most will keep it.

On the other hand if a company manages to make a really good smartphone, it could be a clever advertisement...

 
At 2:57 PM, September 27, 2008, Anonymous mjg said...

I just downloaded the SDK and booted the emulator. See:

http://code.google.com/android/reference/emulator.html

 
At 3:01 PM, September 27, 2008, Anonymous mjg said...

This comment posted from the browser running on my virtual Android 5554, running on my Mac desktop! :)

 
At 3:19 PM, September 27, 2008, Blogger David Friedman said...

mjg has run the emulator; I have failed to do so. Following the instructions on the page he gave, I used the Terminal on my Mac, navigated to:

[Davids-Desktop:~/Desktop/android-sdk-mac_x86-1.0_r1/tools]

entered the word "emulator" (without quotes). And got:

tcsh: emulator: Command not found.

What am I doing wrong? ls shows emulator in the directory.

 
At 3:21 PM, September 27, 2008, Anonymous mjg said...

"./emulator" Because "." is probably not in your PATH.

 
At 3:58 PM, September 27, 2008, Blogger David Friedman said...

I tried ./emulator

[Davids-Desktop:~/Desktop/android-sdk-mac_x86-1.0_r1/tools] ddfr% ./emulator
2008-09-27 15:54:23.411 emulator[1606] *** -[NSBundle load]: Error loading code /Users/ddfr/Library/InputManagers/HotService/HotService.bundle/Contents/MacOS/HotService for bundle /Users/ddfr/Library/InputManagers/HotService/HotService.bundle, error code 2 (link edit error code 0, error number 0 ())
Cannot create data directory: /Users/ddfr/.android/SDK-1.0
Please specify a writable directory with -datadir.

I have a very slight familiarity with unix, but it looks to me as though this may require more than that.

 
At 5:39 PM, September 27, 2008, Anonymous mjg said...

Try:

"./emulator -datadir /tmp/ddfr"

 
At 5:50 PM, September 27, 2008, Blogger David Friedman said...

./emulator -datadir /tmp/ddfr

Thanks. That finally worked.

 
At 6:01 PM, September 27, 2008, Blogger David Friedman said...

Thanks to coaching by myg, I now have an Android emulated on my Mac. It's cute, but doesn't provide me as much information as I would like. There are only a few applications, and I don't see any easy way of downloading more from the app store.

Which suggests one more feature that an emulation targeted at consumers should have--aside from being a double clickable application rather than a program that has to be accessed via the command line.

 
At 8:28 AM, September 28, 2008, Anonymous Anonymous said...

And, ideally, it would make a reasonable effort to emulate the performance of the actual phone.

the iphone emulator definitely doesn't do that, as all the developers discovered when they finally got to put the apps on their actual phones, less than a month before the store opened.

I'm not sure how useful an emulator would be for experiencing the touch-screen interface, which is probably what concerns more people.

 
At 5:35 PM, September 28, 2008, OpenID hudebnik said...

sportember writes:

People who return electronic appliances because of bad software or usability must be quite rare. I think that most people who buy a smartphone and find it unfitting do not return it, but keep it or give it as a gift to a close relative... :-)

It is a well-known phenomenon that people who have made expensive purchases tend to be satisfied with them, and to believe that buying a competing product would have been a mistake. Not because people actually make good decisions, but because the alternative requires admitting that you made an expensive mistake. There's an emotional bias in favor of excusing the shortcomings of what you bought, while exaggerating the shortcomings of competing products that you didn't buy. (See Dan Ariely's Predictably Irrational.)

Tying this back to the original post, there are probably not many returns of smartphones, and of those that are returned, many are probably exchanged for the same model without a crack in the screen, or for updated versions of the same model. If so, then manufacturers don't have much incentive to provide emulators for a mass market (as opposed to the absolutely-necessary emulators for programmers).

 
At 6:02 AM, September 30, 2008, Blogger Lex said...

As far as I can tell it's a good idea, David. I don't see why not to offer a way for users to try before they buy.

http://www.t-mobileg1.com/

There are two technical challenges I can think of, though.

First is that the main usability differences are in how the device functions as a phone, not as a smart phone. How a device functions as a phone depends crucially on hardware details. Further, it's a kind of thing you can't understand just by looking at any description or depiction of the phone. You need to put it in your hand, dial some numbers, make some calls.

I notice that both T-Mobile and Apple have made efforts to get across these feel issues in their ads. They both show floating phones that are being used. This information is not fluff! It shows you what it will be like to use the phone.

The second issue is that, as you say, the available apps are also important. Leaving aside the fact that new apps are written all the time, there is also the issue that many of these apps are DRMed and only available for pay. That adds some complication. In particular, you have to avoid people downloading the emulated version and then finding a way to transfer it to the phone. There are ways to make it work, but it adds complication. One interesting way I've heard of would be make the apps free but increase the usage fees. Then, pay programmers proportionally to how much users use their app.

 
At 12:47 PM, October 01, 2008, Blogger Justin said...

Just one comment to add to those already posted: it may well simply be more expensive than it's worth.

I mean, you're talking about consumer-grade software. That adds a lot of expenses that most open-source projects don't have: good documentation, support, a polished wrapper UI, one-click installers, and so on.

Providing that is a non-trivial chunk of effort and expense -- not enormous, but I'd bet it's on the order of $100k when you add it all up. Heck, some large companies can manage to spend $20k just authorizing the *decision* to build it.

Also, I think you overestimate the number of consumers who would make use of it. While people do *some* research before making purchase decisions, most (I believe) don't go to anything like that level of effort for a purchase of a couple hundred dollars. Instead, they typically rely upon word-of-mouth. I don't see much reason to believe this case would be different -- I'd guess that the vast majority of consumers would simply ask their friends about the device, rather than going to the effort of installing an emulator, installing the apps they want to use, and playing around with them. Seriously, I think that you're an edge case here.

Putting that together, I just don't see the bang-for-the-buck as worth it: it's moderately expensive for the phone companies to provide, and would probably only influence a small number of buying decisions, some of them negatively. So it's a poor investment...

 
At 10:43 AM, October 08, 2008, Anonymous Anonymous said...

http://gizmodo.com/5060441/blackberry-storm-emulator-available-for-download

 
At 5:09 AM, December 20, 2008, Blogger shollypee said...

This comment has been removed by a blog administrator.

 

Post a Comment

Links to this post:

Create a Link

<< Home