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) |
|
Monday, December 11, 2006
Success for mobile information access requires more than flatrate data
Michael Mace at Mobile Opportunity lists what he feels is needed on top of flat rate to get a success in Will flat-rate pricing make mobile data take off?
A few comments on steps to success:
1. Provide a consistent architecture that works offline.
Michael starts off with access via Web browsers, but then also gets into downloaded applications. Many (most?) services will rely on a local application that will take care of the device feature access and possible local storage of information (like caching of maps etc). As local applications are designed together with the actual service, this can be optimized to achieve the best performance and reliability possible. The only choice here is of course Java ME / MIDP as that's what most phones support. Series 60 is an option, but is not enough for broad coverage.
2. Kill security certificates.
Independent applications don't need this anyway, so I don't see this as a major issue. Take e.g. Opera Mini: It's not certified, but still works fine on most networks. You get asked to allow access to the Internet, and for accessing the camera when photo-blogging, but that's it.
3. Unlock the user's data.
PIM, file etc info is accessible from Symbian and Java applications on modern phones, so it's not a major issue, except from a usability perspective, as e.g. file access in Java generates tons of warnings if the application is not certified. Hence, this is a much more important reason to certify. That Java at all generates warnings for "less than ordinary" accesses to phone features in uncertified applications is to lessen the risk of viruses, so it's not all bad.
4. Make it easy to discover new content and services.
Yes, this is a real problem, as people simply don't know what's out there. Don't expect people to randomly search the Web via a mobile phone. Instead present interesting things to the user in a portal, and not just what the operator offers. This is an opportunity for third-party as well. Also, for those services that have a Web presence for promoting the mobile service, use that presence to push down links to the phone for downloading the possible local application or a link to the mobile-adapted Web service. Instructions is not enough.
5. Get ready to go to a flat rate for everything.
For the pure data transfer, absolutely. For services, maybe. Selling ringtones on a subscription basis gave a very bad taste in the market, as especially young people were fooled into signing up for a service they believed was a one-off deal. Hence, service providers need to be very clear about the business model for the service.
Also I spot one overall flaw, that I've stated before: Let's face it, the operators are not the service providers, so what operators need to do is to make it easy to access those third-party services.
Take 3's X-Series for instance: All services offered are from third-party. What 3 has done is to bundle them into an attractive consumer offering.
Regarding X-Series not allowing access from PCs (not that I understand how they can check that): In the long run inhibiting business users from doing so will be detrimental to service uptake by those people, as open access from PCs is exactly what business people need (e.g. to access the corporate intranet). I propose that 3 provides another flat rate offering with business people in mind. Of course considerably more expensive than the consumer offering, as the companies will anyway gain from lower and more consistent monthly phone bills.
A few comments on steps to success:
1. Provide a consistent architecture that works offline.
Michael starts off with access via Web browsers, but then also gets into downloaded applications. Many (most?) services will rely on a local application that will take care of the device feature access and possible local storage of information (like caching of maps etc). As local applications are designed together with the actual service, this can be optimized to achieve the best performance and reliability possible. The only choice here is of course Java ME / MIDP as that's what most phones support. Series 60 is an option, but is not enough for broad coverage.
2. Kill security certificates.
Independent applications don't need this anyway, so I don't see this as a major issue. Take e.g. Opera Mini: It's not certified, but still works fine on most networks. You get asked to allow access to the Internet, and for accessing the camera when photo-blogging, but that's it.
3. Unlock the user's data.
PIM, file etc info is accessible from Symbian and Java applications on modern phones, so it's not a major issue, except from a usability perspective, as e.g. file access in Java generates tons of warnings if the application is not certified. Hence, this is a much more important reason to certify. That Java at all generates warnings for "less than ordinary" accesses to phone features in uncertified applications is to lessen the risk of viruses, so it's not all bad.
4. Make it easy to discover new content and services.
Yes, this is a real problem, as people simply don't know what's out there. Don't expect people to randomly search the Web via a mobile phone. Instead present interesting things to the user in a portal, and not just what the operator offers. This is an opportunity for third-party as well. Also, for those services that have a Web presence for promoting the mobile service, use that presence to push down links to the phone for downloading the possible local application or a link to the mobile-adapted Web service. Instructions is not enough.
5. Get ready to go to a flat rate for everything.
For the pure data transfer, absolutely. For services, maybe. Selling ringtones on a subscription basis gave a very bad taste in the market, as especially young people were fooled into signing up for a service they believed was a one-off deal. Hence, service providers need to be very clear about the business model for the service.
Also I spot one overall flaw, that I've stated before: Let's face it, the operators are not the service providers, so what operators need to do is to make it easy to access those third-party services.
Take 3's X-Series for instance: All services offered are from third-party. What 3 has done is to bundle them into an attractive consumer offering.
Regarding X-Series not allowing access from PCs (not that I understand how they can check that): In the long run inhibiting business users from doing so will be detrimental to service uptake by those people, as open access from PCs is exactly what business people need (e.g. to access the corporate intranet). I propose that 3 provides another flat rate offering with business people in mind. Of course considerably more expensive than the consumer offering, as the companies will anyway gain from lower and more consistent monthly phone bills.
Comments:
Post a Comment
Links to this post:
<< Home
The PIM data isn't uniformly, or even frequently, available via Java, at least in the US. The "PDA Profile" (I forget the JSR) is pretty rare, and most of my developer clients have shunned it as only applying to high end phones when they are targeting mass-market phones.
The RAZR line, for example, doesn't have access to PIM data. And many folks here focus on the RAZR due to its popularity.
The RAZR line, for example, doesn't have access to PIM data. And many folks here focus on the RAZR due to its popularity.
You are right, JSR 75 is definitely not in all phones. I think it's a bit better in Europe though.
I checked Sony Ericsson, as I have most information about their phones, and JSR 75 has been around since JP-5 (K750, V600 etc; I don't know if they are sold in US).
I try to avoid it in my projects, instead relying on files for reading on the server or as MIDlet resources, and files/data for writing in RMS or on the server. All that works even in the simplest MIDP1 phones.
I checked Sony Ericsson, as I have most information about their phones, and JSR 75 has been around since JP-5 (K750, V600 etc; I don't know if they are sold in US).
I try to avoid it in my projects, instead relying on files for reading on the server or as MIDlet resources, and files/data for writing in RMS or on the server. All that works even in the simplest MIDP1 phones.
Post a Comment
Links to this post:
<< Home

