Another “new” company in the “ODP” business (on device portal), Everypoint. Interesting is that just got more funding (a total of 10m$). The product is J2ME based, but hard to see what will be the key differentiator with the others (SurfKitchen, Streamezzo, etc…)…One more on the watchlist….
There were some reviews of this new SE phone yesterday. But I’ve just notice a few interesting features, that have not been heavily highlighted (and I am not talking of this direct Google link):
- Identify Music: while listening radio, you can identify the current song. The phone will record a few seconds of the songs, and send it to a server, and you will get back the song name. Next step is probably to link this to an “iTune like” system (from Sony?). But interesting first step approach
- The second interesting innovation, for me, is the fact that it seems that you can lunch at least two instance of the VM. Not yet truly multitasking, but good enough to create new application, and have the notion of a background app….
Source: Mobile Review
I had an interesting meeting during 3gsm with Ikivo CEO, Stefan Elmstedt and of Ikivo engineer, Sebastien Ruggeri. Ikivo provides some SVG implementation for mobile and some related tools. SVG was covering mainly the rendering part of vector graphics (or that was my understanding). So if you compare to Flash(Lite), it was just the vector graphics rendering part, and not the ActionScript part . Now TinySVG1.2 include some interactions and scripting capacities that can be embeeded into the file. In fact, it can contains a Jar file (and then interaction is done through JSR226) or some ECMA script. That’s quite interesting, and is a challenger for FlashLite. Unfortunatly, SVG content is quite poor yet, for two reasons in my view: lack of good tools (and I do not talk about Ikivo product, but of an equivalent of Flash), and lack of experimented designer with the technology. This still require some investigation (is scripting mandatory? thats unclear for me). But what if this happens, this is a great way to go into the path of integrating several component around J2me. So the SVG vs FlashLite battle is about to begin….
There was several interesting discussion, about what is equivalent of “Web2.0″. Some call it “Mobile Web2.0″. My perception is that it will be more “Mobile 2.0″, as the mobile does not imply the same approach as Web. Why? There are fundamental differences now between mobile and web (and mostly from a tech point of view approach):
- User Interface on Mobile is Key: that’s one of the main difference between a PC and a mobile. On a PC, you have primary a keyboard, and a mouse. These are the two main input components, and a big screen to display user interface. On mobile, you have a very limited display, but much more input possibilities: audio, video, picture, movement, environment (Bluetooth), location, but very limited keyboard and mouse equivalent. So the best user experience will probably tightly link to the multimodal capacities of the phone.
- Mobile is more about synchronisation than browsing. The trend now, on the web, is to provide you most of the user experience from a browser. This happens for two reasons: most of the people are now connected with high speed connection, and the emergence of high quality web browser. On mobile, we do not have these two components: connection is not always cheap, not always available, and not
always fast. Browsers are very limited and not really full featured….
So what are the conclusions:
That Mobile2.0 will be in my view a smart mix between several components, able to
- connect to a server to update local content, or to update server content from local data (synchronisation)
- execute locally some complex task, mixing several inputs (local, web, etc…), and store this result locally (to be later synchronized)
From the end user perspective, this will be transparent (no need to care about installing an application). I think that technically speaking, it will be a combination of browsing based technology (typically XHTML) and some smart client like J2me, FlashLite, or just plain voice call or DTMF….
There won’t be any single technical answer to the frangmentation problem, as mobile is an innovative media, and then innovation generate fragmentation…
The 3gsm will happens this week. I usually do not speak a lot about what we are doing here, at MobileScope or In-Fusio, especially in my team, the “advanced technology” one. I am doing an exception, as this will be publicly presented to the 3gsm. We will demonstrate our “ProjectX” technology.
ProjectX is a game and platform prototype, exploring three topics:
- Accelerated 3D on mobile
- UMTS/3G data connections
The demo will show a racing car game, with a “Capture The Flag” concept; that can be played both from a Web Browser, from a mobile with a 2D version, or from a mobile with an accelerated 3D version.
The challenges are numerous: how to provide a reasonable consistent playability with both 3D and a 2D version. It helped us also to understand the expected latency with GPRS and UMTS on real networks. Finally, we started also to work on these new 3D accelerated chipset. Unfortunately, on this last topic, there is still some work to do…
So if you are interested, just come and see me at the 3Gsm, Hall2. I will be here mostly in the morning.
Also, thanks to Stephane De Luca, who was behind most of the achievement of this demo
I am following Macromedia (and now Adobe) efforts in the mobile since several years, and FlashLite became more interesting recently. Not due to the introduction of FlashLite2.0, which I do not think is the key point, but due to the support -even partial- of SonyEricsson after Nokia.
That’s why, in this entry, I will try to analyze what could the key success factor (and of course, weaknesses) of FlashLite.
Strengths of FlashLite:
- Good development environment. The Flash authoring tool is a good tool for designer, and allows them to create quickly great animation, very hard to achieve in a non vector graphic based environment.
- Good graphical performance: easy development of UI, etc… A Flash Based UI is easy to do, with great features, fun feedback, especially for mobile phone. I usually do not like Flash based UI on the web, as designer tends to recreate their own metaphor, but one the mobile, there is still a lot of room for UI creativity.
- Proprietary technology. That’s the good side of being proprietary: you can do what you want, include feature without asking the community, making mistake, solve them, choose to support something, etc… very quickly. But there is a downside!
What could slow down or eventually kill FlashLite:
- Macromedia/Adobe just start to really experiment the issues of platform interoperability. For instance, reading the notes from FlashLite1.1 documentation , and from the experimentation I have on my phone, I have realized that even in the Flash world, things are not so easy…
- On most of the phone, player CAN NOT be updated! So if shipped with million of phones, then it will remains for some time. No nice screen asking you to update to FlashLitex.x if a feature is not present.. Thatâ€™s the same problem with MIDP* Proprietary technology! And operators do not like this. If the choose Flash, and then it became a market request, than they are stuck with Macromedia.
- FlashLite, in my view, is still a Designer technology. I recently do another attempt to do something useful using FlashLite, and no doubt, development environment is still designer oriented, and not developer oriented. No doubt that’s a clear choice, and one of the strength of Flash, but this means also that this will restrict general usage of the technology. Learning curve will probably be bigger for developers.
- A success of SVG/J2me…SVG just manages the animation part, and the spirit is that J2ME manage the behaviour. On the paper good, but there are several issue: first, there is not yet a good environment development (like Flash) to enable this. Then, J2me app must be downloaded and installed. Then can not add downloaded code on the flight. This limits a lot the possibilities. I guess that something like a SVG+a scripting language (with a J2ME based interpreter) might solve the solution.
Don’t take me wrong. I think that 2006 will be a big year for Flash, and I will try to investigate more the technology, as it provide many great advantages today, compared to alternative.
My ideal whish is to see the emergence of a better â€œcross technologyâ€ compatibility/communication, between the major ones: JavaMe, which is the clear leader, FlashLite, a true challenger, and the new generation of mobile HTML (the Opera Mini trends, Mobile Ajax, etcâ€¦.). This does not happens yetâ€¦..
Just got an information that some GoogleMap tiles jave been greatly enhanced. And that true. Check these two snapshots, left the old version, right the new one. I will modify J2memap to take in accound these changes. Even better, maximum resolution has also been improved! A little bit more complex to do for me, but update on the way too…
Just for fun, I have developped a small Widget to access to the XBoxLive Gamer Card. You can download the app, it contains the full Widget framework but with just this card, so not really optimized…
The widget is code around 45 lines, thanks to the rest of the framework….
Usage: start it, and select “Configuration” from the menu and put your tag, or a friends tag, and press ok….
If you follow my blog, you have probably seen that I’ve started to look at the concept of “Widget on Mobile”, Micro Widget (or Mobile Widget) with this: MicroWidgets is on the Way.
That’s why this BluePulse announce seemed to me quite interesting. The ideas seems to download “widget”, on your mobile, and get revenu from this. But after trying it, I’ve been a little bit disapointed. The so called widget seems to like more as Web pages. I did not take a look at the SDK yet, but seems to me more an attempt to surf on the Widget wave than a real innovative product. Yes, just like other said, I might be missing something but this is definitevly not Konfabulator for mobile phones.
One of the issue is that there is no caching between sessions, so you do have to reload each time the “pages”, and “pages” are not grouped together, so it really gives the feeling of a browser, without the features!
Regarding business model (which is from what I see not really in place, but planned), it seems subscription based par “channel”, similar to what others are doing (typically imode).
But it’s an interesting example of one of the numerous game that game be done using google map API. I did not see a lot yet, there is this one, a Golf game (nice idea, but bad interface)….
An update for J2meMap: it seems that Google changed recently the result of the “search” and “direction” requests, moving from XML to HTML.
Not sure if it’s an attempt for third party app (like J2meMap) to stop using their result. But in all case, the “search”, and “direction” feature of J2meMap does not work anymore.
I will try to fix it ASAP, hoping that they won’t do any change in the near future.
In this post: why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development, Ajit Jaokar explains his view on this topic.
And like Tom Hume in this paper, I disagree with most of his conclusion.
I am a big fan of Ajax (even if I think it’s totally over hyped), and I also personally think that it haves a great potential on mobile, but this kind of statement can only make me react….
His argument is based on the fact Ajax will solve the three following issues:
a) The problem of market fragmentation
b) Porting woes (specific to downloading applications like those built on J2ME)
c) Application distribution without â€˜wallsâ€™
That’s true that market fragmentation is a big issue on mobile. But he did not give any clue why Ajax (so browser based application) will do better than J2me to solve market fragmentation.
The porting woes are also a real problem in mobile world. But this statement is totally false:
To make your  games available worldwide in five languages and on only 50 devices, you would need to create 7,500 different builds. At $2,500 per build, you would require a budget of nearly $19 million simply to handle porting.
First, this is totally wrong. Usually porting costs represent around 100% of the price of the game development (in the Java world, excluding different version like 2D/3D). It’s already incredibly huge, but way below this!
But can Ajax solve this issue? For instance, is Ajax used today to do games? Except very simple casual concept games, not really. And on PC there is usually one binary for a game (and one per platform, PC, Xbox, PS, etc…) . While on Ajax there are already several variant depending of the browser (IE,FireFox, etc…). So if Ajax fragmentation appears already on PC, how can it be better on mobile? Ajax developer will face the same issue of usability, screen size, bugs, etc…on numerous mobile platform. Just like J2ME: it’s easy to write a simple cross platform proof of concept. It’s much harder to have a real application running on all devices.
I predict for “Mobile Ajax” the same pattern than for other mobile technologies:
- first phase: the dream! (write once/run anywhere)
- second phase: the deception (it does not work as expected except on developer device)
- third phase: manual porting/adaptation for every different device
- fourth phase: maturity (a mix of automatic porting with process, devices knowledge and improvements of client )
It happened with Wap, it happens with Java, and it will happen with “MobileAjax”….
- Ajax can not be used to do all the application (and especially not games)
- It will NOT SOLVE the fragmentation issue
Last argument was about application distribution: again, I have no clue why a browser based app would be more widely spread than a downloaded app? The issue is not how to get the application, but how to make it visible: deck placement, advertising, etc… Again, Ajax,J2ME, Brew, etc…issue remains the same…
And do not forget one things also very specific to mobile: even if it’s a very connected device, it’s not always connected to the internet. The difference between offline/online content (through preloaded things, download, caching mechanism, etc…) is much more important than on a desktop. That’s also partof the intelligence of the application, specific to mobile.
Another interesting comment, is why Google (the one who put Ajax in the spotlight) and Yahoo did not choose Ajax to do their mobile client? (if you’ve ever tried to run Google Map on OperaMini, you know why! ).
And may be there are more creative way to evolve. I really think that Ajax and J2ME offers a perfect mix of technology to create much more creative application, Ajax for the purely “web based” part, J2ME for the more “client based” approach… Again, the MobileWidget experiment is another example of attempt to use this mix between J2ME, XML/HTTP request, and a scripting language in a different way…
I’ve just decided to start to work on something called “MicroWidget”. MicroWidget will be the equivalent for mobile of Widget, Gadget, or other inspiration source on the mobile….
Basically, it’s an XML based rendering engine with a tiny scriping language. I’ve used FScriptME as a basis for the scripting language. FScriptME is very limited, but it’s a good start. I’ve added some pseudo object oriented faciclities, like myText.data=”some text”, and some usefull xml parsing function.
As an example, here is the widget code for a Clock like widget:
<img src="/clock2.png" /> <script>< ![CDATA[ func onTimerFired() timeArr=explode(time()," ") hour=explode(timeArr,":") day.data=timeArr secCl.angle =-toint(hour)*360/60+180 minCl.angle =-toint(hour)*360/60+180 hourCl.angle=-toint(hour)*360/12+180 repaint() endfunc ]]> </script>
The code is pretty short and can be easily understood. The only difficulty is the function “explode”, who create an array from a string.
Of course, there are plenty of other usefull function to retrive some xml data, to parse them, etc….
First result are really encouraging, but generate some interesting issue about interface design…
As I’ve explained, I’ve created also this J2meMap application to play and experiment with most of the J2ME JSR’s….
After SMS (JSR120), Bluetooth (JSR85), Location Api (JSR179), I’ve played with JSR75 (PIM). The objective was to be able to use the file system of the phone to cache most of the image downloaded from Google. This work fine, except that some phone implementation ask permission to the user EVERY TIME that you access to the file system.
So, when starting the application, after the first warning (do you allows the application to access to the network), you have another warning (do you allows the application to access to Bluetooth), and a third one (do you allows the application to access to the file system). Fine, unless that on SonyEricsson (my favourite target phone), the right are checked at EVERY access. One check for reading, one check for writing!
So now, I have numerous user requests that make the usage of file system API impossible…
How to solve this? Ideally, the midlet needs to be certified, but it’s a long a costly process. And there is no way for the user to say “once for all” that he grant access to the file system.
So what is the conclusion: the JSR75 is a nice JSR, but current implementation (at least on SE phones) makes it impossible to use it right now….When too much security kill innovation..
SPMark now available on mobile… Not sure is it’s a great thing, but you can check by your self. I’ve downloaded the “high end” version, a jar file of around 500kb! I even did not know that it was possible to do such big app! The application by itself is not yet as impressive at it should be, and others benchmakrs (like www.jbenchmark.com/ ) are already doing some good job.
And this one need to improve. It reported that my phone did not head the bluetooth API, which seems to bo obviously wrong (see below…)