Dissecting Java Portals
- 0
- Add a Comment
- No Related Post
After reading this article at The Feature, I am beginning to think that it might just be a good time to be in the Java development field in the mobile market. Apparently, there a number of companies that are looking to have branded Java apps, but without having to sell their souls to make them happen. Best solution, get a good development company to help you? Could be a wise idea…
Lots of media companies see Java portals as a great way to establish a solid foothold in the mobile market. It sounds perfect: a branded application that sits on a user’s phone, taking them to your content, where you’ve got total control over what they see and how to charge for it, with no interference from an operator and no revenue sharing.
But it’s not a straightforward process, and Tom Hume does a nice job of pointing out some of the problems. His first point is a salient one — can content providers convince users to put their brand on their phone? This might be easier for news outlets, where if I read a certain newspaper everyday, I’d be okay with having it on my device, if it makes getting to its content easier. But the phone is an immensely personal object, and one that people use to project an image of themselves, hence the market for ringtones, faceplates and backgrounds — and how many brands have the cachet to speak for their users via their mobiles?
But Hume’s main argument undermines a key assertion of content providers using Java portals and the companies selling them: that they offer a better user experience. He’s pointed out before that a Java app can be better for the user than WAP, but that can is very different than will. He tried one particular application that’s a Java storefront for games and ringtones and the like, which was beset with usability issues: it took three tries to open properly, it was slow and it had to connect to the network to display anything beyond the name of a Java game it was selling.
