Opinionated comments on mobile phone industry news
|
All entries are written by Anders Borg, CEO and Consultant of Abiro, that has a long experience in strategic planning, developing embedded and Java software, usability aspects, and the mobile phone industry in general. You can also read the latest Mobile News entries on your phone via wap.abiro.com, and we provide many News Feeds from popular news services. For advertising and contribution queries, please use the feedback form. News feed (local) FeedBurner Feed
|
|
Saturday, October 21, 2006
Mobilizing information services, not that easy
The PC market is relatively consistent when it comes to methods for enabling of Internet-based information services compared to the mobile market, due to the complete dominance of Microsoft and due to the few providers of browsers (that anyway need to be IE compatible) etc. There are many things you could say about the negative consequences of Microsoft's dominance, but I don't think anyone can deny that consistency is a good thing for service providers.
Not so for mobile phones where there are several ways to mobilize services, both via the phone's native functionality, like SMS, MMS, email, browser etc, and via downloaded applications for Java ME / MIDP, Symbian OS, Windows Mobile or similar.
Pragmatically it's easiest to make services that rely on the phone's native functionality, and if the service needs some level of interaction then the phone's browser is a reasonable choice, as it's possible to achieve good consistency over phones without having to test on all phone models (which is practically impossible). This approach has been taken by e.g. SoonR, and tools like WURFL and similar help smooth out the edges.
Java ME / MIDP is completely dominating in after-market mobile application platforms, but is suffering from the many providers of Java ME implementations with different interpretations of specs and different bugs/features. One would think that Sun would some day realize that they need to become the only provider of Java ME implementations to secure a higher degree of compatibility, but when reading information originating from Sun it seems they still think Java ME is Write Once Run Anywhere, and the decision to make Java ME open source will not increase consistency, despite other values of open source efforts.
Java ME is certainly still a good choice, and often the only choice, if you need to access the phone's functionality, like the camera, audio, location, file system, PIM database etc, and if you need to display interactive information including graphics.
Of course the camera (both for photos and video) can also be accessed via native functionality as photos/videos can be sent via MMS or email to the service, yet there's really no interaction with the service this way. It's more like "send and pray", yet the use case is very easy to explain, and has been deployed by mojungle and others.
ShoZu requires a special application installed on the phone. As I mentioned in
Web 2.0 not for phones? ShoZu would gain from also supporting MMS/email transfer of photos.
Advice to those that want to get into mobile services:
* Select client solution based on whether you want to reach the whole mobile market or you can survive by targeting users of specific devices (and application platforms); revenue doesn't need to be less if you limit the scope, as e.g. corporate users will pay way more for services and applications than the average consumer would; also you can start with a limited scope and broaden later (like ShoZu did)
* For maximum coverage with no interaction with local phone functionality, use an SMS-based approach
* For services that need some level of user interaction and look-n-feel yet reach a very broad audience, use a browser-based approach
* For interaction with the camera, yet with no need for other service interaction, use MMS/email
* For close interaction with the service, including advanced graphics and access to some local functionality, use Java ME / MIDP
* For the most advanced and broad access to local functionality, yet where it's OK that only a smaller part of the market is accessed, use Symbian OS and/or Windows Mobile
Here's another note with a slightly different angle on the subject:
Internet leaders: Mobile is tough nut to crack | InfoWorld | News | 2006-10-20 | By Nancy Gohring, IDG News Service
I question the control of operators mentioned here. At least in Europe you can do pretty much what you want via the mobile network, yet the operator is of course always the middle man charging you for the transfer of SMS, data etc.
Not so for mobile phones where there are several ways to mobilize services, both via the phone's native functionality, like SMS, MMS, email, browser etc, and via downloaded applications for Java ME / MIDP, Symbian OS, Windows Mobile or similar.
Pragmatically it's easiest to make services that rely on the phone's native functionality, and if the service needs some level of interaction then the phone's browser is a reasonable choice, as it's possible to achieve good consistency over phones without having to test on all phone models (which is practically impossible). This approach has been taken by e.g. SoonR, and tools like WURFL and similar help smooth out the edges.
Java ME / MIDP is completely dominating in after-market mobile application platforms, but is suffering from the many providers of Java ME implementations with different interpretations of specs and different bugs/features. One would think that Sun would some day realize that they need to become the only provider of Java ME implementations to secure a higher degree of compatibility, but when reading information originating from Sun it seems they still think Java ME is Write Once Run Anywhere, and the decision to make Java ME open source will not increase consistency, despite other values of open source efforts.
Java ME is certainly still a good choice, and often the only choice, if you need to access the phone's functionality, like the camera, audio, location, file system, PIM database etc, and if you need to display interactive information including graphics.
Of course the camera (both for photos and video) can also be accessed via native functionality as photos/videos can be sent via MMS or email to the service, yet there's really no interaction with the service this way. It's more like "send and pray", yet the use case is very easy to explain, and has been deployed by mojungle and others.
ShoZu requires a special application installed on the phone. As I mentioned in
Web 2.0 not for phones? ShoZu would gain from also supporting MMS/email transfer of photos.
Advice to those that want to get into mobile services:
* Select client solution based on whether you want to reach the whole mobile market or you can survive by targeting users of specific devices (and application platforms); revenue doesn't need to be less if you limit the scope, as e.g. corporate users will pay way more for services and applications than the average consumer would; also you can start with a limited scope and broaden later (like ShoZu did)
* For maximum coverage with no interaction with local phone functionality, use an SMS-based approach
* For services that need some level of user interaction and look-n-feel yet reach a very broad audience, use a browser-based approach
* For interaction with the camera, yet with no need for other service interaction, use MMS/email
* For close interaction with the service, including advanced graphics and access to some local functionality, use Java ME / MIDP
* For the most advanced and broad access to local functionality, yet where it's OK that only a smaller part of the market is accessed, use Symbian OS and/or Windows Mobile
Here's another note with a slightly different angle on the subject:
Internet leaders: Mobile is tough nut to crack | InfoWorld | News | 2006-10-20 | By Nancy Gohring, IDG News Service
I question the control of operators mentioned here. At least in Europe you can do pretty much what you want via the mobile network, yet the operator is of course always the middle man charging you for the transfer of SMS, data etc.
