The Economist has a brief article about train operator C2C in London offering mobile-free phones by coating the phones in an RF-absorptive material. Basically it prevents cellular signals from getting into or out of a train car, and by doing so guarantees silence in the cab.
It's a little heavy-handed for a few reasons, though. Firstly, blocking RF transmission will just put phones into a wildly-seeking-signal state, meaning that many people will end their journeys into London or on their way home with batteries that have been drained more than they ought to. Also, it prevents people from using otherwise silent data services (eMail, SMS, web, etc.).
What might be a better solution? Well, yes, coat the trains such that they don't let phones connect to external base-stations. Then go ahead an put in picocells inside the train cars themselves, or repeater-like technology that Orange and Virgin have already deployed. Allow these systems to only allow services to work on the data channel, and you're done...
And the revenue model? Whoever owns these picocells can charge the operators for allowing their customers to use them. Not an unreasonable "roaming" charge, of course, but something akin to the charge operators charge for terminating calls on their networks, perhaps.
And what's next? Deploy this in the tube. In fact, wouldn't this be a great project for TfL to own, both on commuter rail and in the tube?
Thursday, October 30, 2008
Tuesday, October 28, 2008
Is RIM falling further behind?
A couple of days ago RIM released a software update to the new Bold. It turns out that the software stack on this device has been the cause of a lot of issues for RIM and it's partners: Some operators (like AT&T) have refused to ship the device with the previous software offering, and others have halted sales of the device until the fixes were ready. All in all a pretty miserable device launch for RIM (especially for a new flagship product).
Because RIM's got access to all of their devices on the network, I happened to get a notice on my BlackBerry telling me that there was an update available, and that I could get it by visiting a certain website. When I got there, I found that (unsurprisingly) I had to download a 93 MB file, launch Windows on my machine (sigh), and go through the update process.
Notwithstanding that having to use only a Windows PC to update my BlackBerry is pretty obnoxious, the entire upgrade process was far from uneventful. See, what happens is that the installer does a backup of your device, wipes it, reloads the new operating system, and then your old data.
Well, mine got half-way through the reloading phase and freaked out. So, I momentarily had a shiny brick instead of a BlackBerry. Great.
I managed to get the new operating system installed on my device... but of course, BlackBerry desktop was too stupid to realise that I'd done this because it had failed in the middle of the update the last time. Yippee.
It turns out that BlackBerry Desktop *does* leave a backup file around that you can use to restore all of your information... or so it seems. After restoring the backup I noticed that I had all my contacts, and settings... but no apps. All those applications I'd downloaded to my BlackBerry, that I *watched* getting saved in the backup process? Gone. Why? Guess RIM thinks it makes sense to store one half of your backup somewhere and the other somewhere else (and hidden). Brilliant thinking, here.
Why is this so upsetting? Well the Bold is supposed to have over-the-air update functionality. Does it? Anyone's guess... but if it does, RIM's sure done a terrible job taking advantage of it. What's worse is that my Kindle... a simple book reader, does OTA updates, and does them beautifully.
I was flipping through the "content manager" on my Kindle recently and realised the menus had a few new (and useful) features there. Where'd they come from? No idea. It seems my Kindle silently upgraded itself, and kept on working splendidly...
Even more a sign that RIM's tech is slipping behind is the fact that Android includes OTA update capabilities, and is actually using them. The first batch of G1 is supposed to get an OTA update, which, considering the device just launched is at once distressing and impressive.
Either way, anything's better than the invasive, time-wasting, multi-step, failure-ridden process that RIM's got going for it today... hopefully they've got some bright folks in Waterloo working on it.
Because RIM's got access to all of their devices on the network, I happened to get a notice on my BlackBerry telling me that there was an update available, and that I could get it by visiting a certain website. When I got there, I found that (unsurprisingly) I had to download a 93 MB file, launch Windows on my machine (sigh), and go through the update process.
Notwithstanding that having to use only a Windows PC to update my BlackBerry is pretty obnoxious, the entire upgrade process was far from uneventful. See, what happens is that the installer does a backup of your device, wipes it, reloads the new operating system, and then your old data.
Well, mine got half-way through the reloading phase and freaked out. So, I momentarily had a shiny brick instead of a BlackBerry. Great.
I managed to get the new operating system installed on my device... but of course, BlackBerry desktop was too stupid to realise that I'd done this because it had failed in the middle of the update the last time. Yippee.
It turns out that BlackBerry Desktop *does* leave a backup file around that you can use to restore all of your information... or so it seems. After restoring the backup I noticed that I had all my contacts, and settings... but no apps. All those applications I'd downloaded to my BlackBerry, that I *watched* getting saved in the backup process? Gone. Why? Guess RIM thinks it makes sense to store one half of your backup somewhere and the other somewhere else (and hidden). Brilliant thinking, here.
Why is this so upsetting? Well the Bold is supposed to have over-the-air update functionality. Does it? Anyone's guess... but if it does, RIM's sure done a terrible job taking advantage of it. What's worse is that my Kindle... a simple book reader, does OTA updates, and does them beautifully.
I was flipping through the "content manager" on my Kindle recently and realised the menus had a few new (and useful) features there. Where'd they come from? No idea. It seems my Kindle silently upgraded itself, and kept on working splendidly...
Even more a sign that RIM's tech is slipping behind is the fact that Android includes OTA update capabilities, and is actually using them. The first batch of G1 is supposed to get an OTA update, which, considering the device just launched is at once distressing and impressive.
Either way, anything's better than the invasive, time-wasting, multi-step, failure-ridden process that RIM's got going for it today... hopefully they've got some bright folks in Waterloo working on it.
Sunday, October 05, 2008
How can Android win developers?
The first production Android device (T-Mobile's G1) will soon hit the market, and the legions of Google faithful will no-doubt snap up many devices in short order.
Will that be enough to allow Android to be a real competitor in the smartphone wars? The G1 isn't a particularly attractive device, doesn't have as good a media player as the iPhone, doesn't have a browser that can best the iPhone, doesn't provide eMail that holds a candle to BlackBerry, and is locked to a network that's widely regarded as having lackluster coverage. It's unlikely that the G1 is going to be a hit with consumers, and it's not going to ship in volumes that will make anyone at Apple or RIM lose sleep.
That feeds a bigger problem, though: getting developers on side. Unlike the iPhone which got great consumer demand without any third-party apps just by having a sexy device, or BlackBerry which has thrived by providing a rock-solid communications "appliance" that nobody's yet rivaled, Android is going to need to differentiate on killer 3rd party apps.
When it comes to developer platforms, iPhone has a beautiful SDK and distribution mechanism that's sparked widespread adoration from developers. Sure, Apple's exerting far more control on the developer community than perhaps they should, bit they're still a whole lot better than the existing carrier / OEM ecosystem. Also, iPhone is a single, consistent platform... a developer can build one app and have it reliably run on the millions of iPhone 2G, 3G and iPod Touch devices in market. A great, powerful developer toolkit, robust operating system, ubiquitous distribution platform, and consistent device hardware? This is a developer's dream.
The BlackBerry developer platform isn't particularly elegant, doesn't have a great development environment (RIM just recently got decent Eclipse integration), and is a generally underpowered OS when it comes to doing anything involving graphics or media. It's also got a pretty significant number of inconsistencies between OS and hardware versions, which has proved to be an irritation for many RIM developers. It's particularly telling that RIM wrote the Facebook app for BlackBerry, whereas Facebook built their own iPhone app.
That said, BlackBerry provides a reasonably reliable and stable operating system, and millions of devices as an addressable install base (with users who have a disproportionately high usage of data and third party apps vs all the other platforms except iPhone). This makes it a no-brainer for many application developers to target.
So a developer just developing a new application will probably build their first app on iPhone, do a re-write in Java to support BlackBerry, and then give very careful consideration to whether they feel like building an app for Symbian or Windows Mobile. In a competitive marketplace, it's safe to say that if you can hit 30-40MM devices by targeting iPhone and BlackBerry, it's unlikely that you're going to spend anywhere near the same resources to target a platform like Android with <1 MM. Those resources are probably better spent on building either for a platform like Symbian (with broad reach), or towards building version 2 of the iPhone/BlackBerry app.
What's Google to do? Well, how about building a porting toolkit? If a developer decides to build a BlackBerry application, they're already going to be creating a Java version of their application. If Google provided tools to help more quickly port the BlackBerry Java app to an Android Java App, that could significantly reduce the time and effort required to get an app on Android, making the business case for doing so much more viable.
Sure, some classes of apps that are really glued to the hardware (e.g. games), aren't good candidates for something like this, but those apps are in the minority. Also, while Android's Java implementation has all sorts of great features like 3D graphics, rich sound libraries, and more, BlackBerry doesn't, so any app that was a straight port from BlackBerry to Android wouldn't really show off the full potential of the Android platform. Not ideal. But if the porting toolkit were extended to quickly and easily add some of these richer capabilities into the resulting applications, it could prove a powerful motivator for developers.
The name of the game is addressable market, and it's clear that as the new kid in town, Google's got an uphill battle. With a far-from-inspiring first device, the battle's just gotten a bit harder. Taking advantage of the current strength of BlackBerry as a platform is one thing that Google can do to more quickly bootstrap their own developer ecosystem... which would be great for the entire industry.
Will that be enough to allow Android to be a real competitor in the smartphone wars? The G1 isn't a particularly attractive device, doesn't have as good a media player as the iPhone, doesn't have a browser that can best the iPhone, doesn't provide eMail that holds a candle to BlackBerry, and is locked to a network that's widely regarded as having lackluster coverage. It's unlikely that the G1 is going to be a hit with consumers, and it's not going to ship in volumes that will make anyone at Apple or RIM lose sleep.
That feeds a bigger problem, though: getting developers on side. Unlike the iPhone which got great consumer demand without any third-party apps just by having a sexy device, or BlackBerry which has thrived by providing a rock-solid communications "appliance" that nobody's yet rivaled, Android is going to need to differentiate on killer 3rd party apps.
When it comes to developer platforms, iPhone has a beautiful SDK and distribution mechanism that's sparked widespread adoration from developers. Sure, Apple's exerting far more control on the developer community than perhaps they should, bit they're still a whole lot better than the existing carrier / OEM ecosystem. Also, iPhone is a single, consistent platform... a developer can build one app and have it reliably run on the millions of iPhone 2G, 3G and iPod Touch devices in market. A great, powerful developer toolkit, robust operating system, ubiquitous distribution platform, and consistent device hardware? This is a developer's dream.
The BlackBerry developer platform isn't particularly elegant, doesn't have a great development environment (RIM just recently got decent Eclipse integration), and is a generally underpowered OS when it comes to doing anything involving graphics or media. It's also got a pretty significant number of inconsistencies between OS and hardware versions, which has proved to be an irritation for many RIM developers. It's particularly telling that RIM wrote the Facebook app for BlackBerry, whereas Facebook built their own iPhone app.
That said, BlackBerry provides a reasonably reliable and stable operating system, and millions of devices as an addressable install base (with users who have a disproportionately high usage of data and third party apps vs all the other platforms except iPhone). This makes it a no-brainer for many application developers to target.
So a developer just developing a new application will probably build their first app on iPhone, do a re-write in Java to support BlackBerry, and then give very careful consideration to whether they feel like building an app for Symbian or Windows Mobile. In a competitive marketplace, it's safe to say that if you can hit 30-40MM devices by targeting iPhone and BlackBerry, it's unlikely that you're going to spend anywhere near the same resources to target a platform like Android with <1 MM. Those resources are probably better spent on building either for a platform like Symbian (with broad reach), or towards building version 2 of the iPhone/BlackBerry app.
What's Google to do? Well, how about building a porting toolkit? If a developer decides to build a BlackBerry application, they're already going to be creating a Java version of their application. If Google provided tools to help more quickly port the BlackBerry Java app to an Android Java App, that could significantly reduce the time and effort required to get an app on Android, making the business case for doing so much more viable.
Sure, some classes of apps that are really glued to the hardware (e.g. games), aren't good candidates for something like this, but those apps are in the minority. Also, while Android's Java implementation has all sorts of great features like 3D graphics, rich sound libraries, and more, BlackBerry doesn't, so any app that was a straight port from BlackBerry to Android wouldn't really show off the full potential of the Android platform. Not ideal. But if the porting toolkit were extended to quickly and easily add some of these richer capabilities into the resulting applications, it could prove a powerful motivator for developers.
The name of the game is addressable market, and it's clear that as the new kid in town, Google's got an uphill battle. With a far-from-inspiring first device, the battle's just gotten a bit harder. Taking advantage of the current strength of BlackBerry as a platform is one thing that Google can do to more quickly bootstrap their own developer ecosystem... which would be great for the entire industry.
Subscribe to:
Posts (Atom)
