Category Archives: Yahoo

What is really Yahoo!GO 3.0 SDK?

Finally, we had a chance yesterday to access to Yahoo!Go 3.0 SDK. As a frequent reader of this blog, you should know that Widgets is a favorite topic, so I was curious and excited about achivement of Yahoo!Go 3.0 and his SDK.

The home screen is really good, looks great. Very nice theme, with a background image and a caroussel of “widgets”. Things become bad you start to dig into the content. In fact, what is Yahoo!Go3.0 is very similar to Yahoo!Go 2.0: an enhanced browser to the yahoo content. All pages are similar to wap page, but with some improvment in the navigation. There is however some specific part that have some higher capacitities, like the “map” part which contains a GoogleMap type navigation.What really kills the experience is that the answer to every keypress (and I’ve tested this on an N95, which is usually a very fast phone) takes too much time!

So now , let’s look at the widget part and the SDK: in fact, what is promoted as “widgets” is in fact some enhanced xml/wap pages created with the “BluePrint” language. The good thing is that pages can be easily integrated within the Yahoo!Go content, and can also benefit from the integrated advertising feature.

So Yahoo!Go 3.0 is more or less an enhanced mobile browser without Ajax capacities, and these widget are XML component that can be part of the page. One of the benefit of such basic approach is that these “widgets”, can be deployed even on simple Wap/xHtml pages. The bad thing, is that it’s quite impossible to do “real widget”: very little interaction possible between the application and the user, no local caching, no access to phone features…. Seems like a step back in the times “before ajax”. Does it really make sens to build a download app if you just provides a browsing experience?

Identificateurs Technorati : , ,

Yahoo opens his mobile widget SDK

According to Techcrunch, Yahoo is the latest entrant in the mobile widget race. Basically, the “big” part of Yahoo!Go 3.0 is the support of widget, and the availability of an SDK for developpers.

So it will be interesting to see this. Yahoo!Go was already huge and slow, so let’s hope that 3.0 won’t be too big this time.

It’s also interesting to notice that MyYahoo does not seems to allow (unless I’ve missed something) third party widget development, while Yahoo!Go mobile allows it…. ;-)

Let’s wait tommorow, and “a few weeks”, to get an access to the SDK. In the meantime, if you want to experiment mobile widget now, don’t forget to check webwag: and

Identificateurs Technorati : , ,

9 Month later: is Yahoo pipes a success?

Microsoft Popfly has been publicly released two weeks ago, I’ve played a little bit with it: very impressive graphically, but it’s hard to do something really useful beyond the usual “get flickr pictures and show them in a cool way…”…

I was wondering is it because of the limitation of such tool, or because I’ve just not see them. So I made a little bit of research on Yahoo!Pipes.
 First, I must admit that even if less impressive graphically, Yahoo!Pipes seems much more useful at a first step. Maybe it’s more programmer oriented, but connection and the rest seems easiest to manage.
But then, I’ve tried to find some  interesting pipes: I’ve been through the list of Pipes, and hardly find something really useful. The most used pipe seems to be the ‘ flavored web search”, by PashaSadri, which was run 45610 times. The second one, Badger, has been run 25654 times….

But for a so visible service like Pipes, by one of the top three internet companies, seems relatively low numbers, especially regarding the excitement generated at the launch time.

But the worst thing, is that it’s quite hard to find really useful stuff. Two options:

  • It’s not possible to do “real” innovative things using such technology
  • Service did not found his users yet. It’s just a question of time (and eventually user interface), and Microsoft Popfly could eventually take over this space.

My guess, it’s a little bit of the two: users don’t really interested by these, they already have plenty of tools, to do search, etc…So what is the value (fort them) to spend time to learn such thing?

Yahoo!Go 2.0 is out, but beta is already full

The new Yahoo! Go 2.0 is out, but it seems already impossible to download it, as the beta is closed due to too high number of downloads. The result seems quite impressive, and now it works also on J2me. So as predicted (yes, this is in my 2007 predictions, but they are not yet published!), Yahoo is following Google (and soon Microsoft) in providing high quality frontend in J2me to their services…

Technorati Tags: , , ,

The widget environment of the day….

During the Widget2.0 conference, Fox , the parent company of MySpace, just announced the launch of a new widget platform, based in Flash: SpringWidget
Well, another new platform! I see one issue with Flash widget from the content creation side: they requires a paying authoring tool (Flash from Adobe) and alternative are not really mature. Again, a good tool for designer, but not so easy to use for most of average users, as it require a learning curve (longer than HTML?).

W3C to standardize Widgets?

In the same time, the W3C started a draft about Widget Of course, from what I can see it will be totally incompatible with this new platform! The scope of this draft is very limited for now, and mainly speek about description of the widget itself. So it’s unclear how far this will go, and if some topic like cross widget communications, user preferences saving, authentification, access to native functions will be adressed.

Widgets families

In order to have a better view about the widget landscape, I’ve tried to find whath are the major difference between the various engines/implementations…

Name Rendering engine Scripting language Execution framework
Googe Gadgetl HTMLbased Java Script Desktop+Browser
Yahoo!Widget Custom XML based Java Script Desktop
Opera Widget HTML based Java Script Browser+Desktop
Dashboard HTML based Java Script Desktop (+Browser?)
Spring Widget Flash Action Script (ECMA Based) Desktop+Browser
VistaWidgets? ? Java Script? Dekstop+Browser

The obvious trend is about HTML+Java Script, with an execution environment being able to execute widget both on Desktop and within Browser.

Technorati Tags: , ,

Widgets: the next portability nightmare?

hyalo-weatherThe topic of Widgets standardisation will become a hot topic next year. We already haves so many different Widget framework based on browser (Google, Opera, NetVibes, WebWag), a few desktop based Frameworks (Yahoo!Widget and Dashboard), and now some emerging mobile widget framework (Widsets, and of course Mobidgets! ;-) ) that it’s quite sure that we can not continue into the same direction.
In this post, I will try to provide a view on the landscape of widgets in terms of interoperability (between platform) and try to explore the common part between theses framework.

First, I’ve been to “Widgipedia“, and from their FAQ, they already support these 14 platforms: (this was more than I was expecting)

  • Yahoo! Widgets (Windows)
  • Yahoo! Widgets (Mac)
  • Dashboard (Mac)
  • Standalone Widgets (Windows);
  • Standalone Widgets (Mac)
  • Microsoft Vista Sidebar (Windows)
  • Opera (Windows)
  • Opera (Mac)
  • Opera (Linux)
  • DesktopX (Windows)
  • Kapsules (Windows)
  • Samurize (Windows)
  • KlipFolio (Windows)
  • AveDesk (Windows)

I assume that some of them are interoperable, especially between the mac/windows version, but it seems that it’s not always the case.
Also there are some missing components, like Netvibes, or WebWag which have their own framework, and probably Windows!Live? Flash is also a probable candidate for a Widget environment….
Mobile applications have also their own frameworks, for instance Widsets or Mobidgets

So what levels of interoperability do they have. For now, none of them are interoperables!. When you do a Google widget, than you have to recreate it for Yahoo!Widget for instance.
The positive view is to say it’s not so hard to convert a widget from one environment to the other….
Is there any hope that this will change in the near future. I am not an expert of each of these widgets framework, but we can identify two major things:
the “representation/descriptive part ” generally XML based
the scripting language used is JavaScript/ECMAScript…

That’s a good start, but then you face all the little details: where are stored the user preference, how to access to some utility function, is it CSS/HTML based, etc….

So what’s next? Three options:

  • One of these framework become the de-facto standard, and all the others are either killed, or align to it….
  • A standardisation body (W3C?) take the lead on it and try to solve the problem….
  • Status quo, only a few widgets engines/framework are still alive and tools are created to “transcode” one widget into another?

None of this solution is perfect, but it will be interesting to see how this will evolve in the coming monthes, especially in regard of mobile who will bring new widgets framework, but who will be hardly compatible directly with other framework for many technical reasons….

I am sure that it will be an interesting topic to discuss in the upcoming “Widgets Live!” conference in SF! (which is the same day than this interesting mobile2.0 event, in SF too!)

And in the second part of this post, I will explore potential solution and direction for a common widget framework…Stay tuned.

Update: one the reader (Lindsey), pointed out this work on W3C about packaging deployment Web Application Packaging Format Requirement. This doc is a starting point, but contains a good table about various packaging format used between Google, Yahoo and others…

Read also this post from C.Enrique some monthes ago on the same topic….

Picture taken from the “hyalo-weather” widget….

Technorati Tags: , ,

Flickr got maps – good time to GeoTag!

Two interesting news for today:
First, Flickr introduced some mapping feature for geotaged picture. You can see where these picture has been taken. Of course, visualisation is done through Yahoo Maps, which is less accurate (outside U.S.) than GoogleMap, but that’s a good start, and probably a big incentive for Yahoo to correct this soon.
Of course, this feature is nothing really new, but it’s nice to see in integrated. Note that “Pikeo” is an Orange project that intent to do the same kind of things, but not as smooth as I would expect it…


The bad side seems to be that you need to do an extra step, even if your photos are already geotagged. You need to “import” them (go to “organize”, then “map”). This step is probably not needed and useless.
The other issue seems that YahooMaps seems to contains a lot of errors, as you can see on this snapshot….

The other good news of the day is the announce that I am involved in the “mobup” project since some monthes now. Mobup is a free open source Flickr uploader. Now mobup haves some geotagging capacities: if you have a connected GPS to your mobile phone through bluetooth, Mobup will add Geotags to this. Of course, the geotagging picture capacities of J2memap are based on Mobup…

Technorati Tags: , , , ,

SyncML is a reality?

One of the most interesting things from the Yahoo!Go connect announcement from Yahoo, was the ability to use SyncML to synchronise your account with your address book, calendar, etc…
Waoow I was thinking, at least it happens….. Let’s try it…

And big disappointment:

What is really strange and weird is that the server seems to filter only to a subset of ten supported phones! Do not really understand why, as SyncML should be standard…. The users who are able to configure SyncML (which is in fact the real challenge) then are blocked because they do not have the right phone. What is the point here? Is there a technical challenge that we do not know?
But let’s assume it’s just a temporary situation, I really believe that SyncML then will be huge. Of course, there is a lot of remaining issues, like settings as usual. So Operator position on this topic will be quite interesting.

Can Ajax save mobile development?

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 [30] 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…

Update: see C. Enrique Ortiz

Short feedback on Yahoo!Go client for Serie60

Review of Yahoo ! Go client for Symbian :

Yahoo just provided the ability to download their client on numerous serie60 handset.. So here are a few comments from usage point of view:

  • First surprise, size: it’s huge, 1800kb……especially regarding the fact that it’s native code, and according to functionalities! And it seems that a lot of other stuff is downloaded at the first connection.
  • Once installed, I had very rapidly an “out of memory error”, and I had to start the application again” (I am using a Nokia6680)
  • What you can do: basically, provide an access to MyYahoo from a mobile. More concretely, this mean that:
    • Your address book is synchronized with your MyYahoo address book accoun
    • Your calendar is synchronized with your MyYahoo calendar account
    • You can read your Yahoo email (and being notified when an email is received)
    • You can send photo to your MyYahoo account
    • You can browse the same information than the MyYahoo pages: typically weather, quotes, rss feed you’ve subscribed, etc…
    • You can chat with others users
      • While in a chat session, you can send voice messages
      • While in a chat session, you can send photos
    • You can customize the phone with a yahoo skin (but does not seem that this skin can be updated).
  • From a usability, there is some good things and some bad things:
  • It’s a native symbian application. So no numerous security warning. An SMS is sent to identify yourself.
  • Synchronisation works quite well with, and all the internal address book has been filled with my Yahoo contact base.
  • But some of the menu yahoo categories (news, quotes, etc…) just open the web browser on the selected page. No way to browse off line for instance. Even worst, one page (stock quotes) you are asked again your password/id. But this might be more a bug.
  • The photos album is managed by Yahoo! Photo (and unfortunately not by Flicker, ☺ ).
  • Some more comments and view:
    • The synchronisation is really useful, and it might be a sufficient reason to switch from one service (ex: msn) to another, especially for people who use more IM than Outlook!
    • The link with the camera is also very nice! Might be an “mms killer”: why should a costly MMS to share my picture with others users.
    • And lastly, the chat with picture and photo are really easy and convenient to use!

    So it’s probably one of the first complete “WebToWireless” application.

    Next challenge will be to put such application in the Java world. Not impossible, but will be hard o achieve the same level of integration with the rest of the phone.

    MicroWidget is on the way

    Mobile Widget 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”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[3],":")[2] 	secCl.angle =-toint(hour[2])*360/60+180 	minCl.angle =-toint(hour[1])*360/60+180 	hourCl.angle=-toint(hour[0])*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…

    Technorati tags: JavaMe J2ME Ajax Widget Micro Widget

    Predicition for 2006!

    I will go also through my little prediction for 2006. Most of them are based on my previous post, and yes, it’s Christmas break:

    • Google will buy a Opera(if not already done): the “OS” of Google is the browser, so they need to provide one on platform who does not have one, or a good one. That’s why I predict that they will buy a browser company typically Opera. The interest of Opera for Google is that they also have a good mobile offering.
    • But Google will move from the “Good side” to the “Evil Side”. Too powerfull, too big, too smart….
    • The “big three”, Yahoo, Google and Microsoft will enters more strongly into mobiles. All will provides much better access to their service to everybody mobile.
    • Location based service will increase, especially in North America, thanks to GPS enabled mobiles. In Europe, such mobile will start to appear

    Google is going to Widget, and compete with Konfabulator

    Google just introduced the ability to add Widget in your starting page. The first widget are not very numerous (see the
    directory ) but I guess it will increase rapidly. The “date and time” widget seems very similar, in terms of look and feel (and functionalities) to a Konfabulator widget.

    May be somebody in Google read my previous posts about writing Konfabulator widgets and write something in a couple of days! ;-)

    More seriously, this’s a quite good and smart approach, as it uses the browser model. So all rendering is done using HTML, JavaScript, etc… and widgets are stored on the server side. So the only missing thing, to compete with Konfabulator, is the ability to put theses Widget on your desktop…. Should not be a too difficult task, just extend Google desktop to provide the ability to open some “web pages” that contains each one a Widget, and you’re done (and ultimately, Google Desktop could finally be useful and sexy!).

    Also, I would like to mention this interesting view from C.Enrique Ortiz: Google – The Best Thing That Has Happened to Yahoo! I totally share this view, and it’s a very positive proof of the utility of competition (and of course, this comment can be extended to Microsoft, hopefully).

    Technorati tags: Google Yahoo Widget Konfabulator

    My first Konfabulator Widget

    I’ve just make my first Konfabulator Widget…

    The good things, is that took me just ten minutes to understand how to do it and to make it run (I just wanted to display the number of registered users to J2memap as a widget).
    It also took these 10 minutes to realize where were the limitations of the framework…

    • No HTML or XML parsing. For something that is frequently used to display in a specific way Webpage, XML data or RSS feed result, and that rely so heavily on XML internally, it’s incredible to see that there is no built-in parsing engine. You have to do you’re own.
    • Basic rendering engine: all graphical elements need to be pre-rendered (with the exception of text). No layout feature, just good old bitmap, the only fancy stuff is transparency.

    So even if you start to build something very rapidly, it requires a huge maintenance effort each time you want to do a modification. It would have been great to have a better Web awareness, by including an XML parser, and a kind of HTML/CSS rendering engine. This would have made things much simpler….


    Konfabulator settings

    Just a small suggestion for Konfabulator (but it might be already in the loop for the future): is to store all your settings on the server side, so then, just log into another computer (with konfabulator already installed, and probably you’re yahooId) and you get magically all you’re settings, as well as the widget, downloaded and installed… Sounds cool?

    End of the browser?

    During a recent discussion with one of our partner, this one predicted “the end of the browser”, before two years, as opposed to the emergence of specialized applications like messenger, or Google earth. His point was that the crucial part was integration between applications, something that was in his view impossible to do using a Web Browser.

    In a time of a complete renewal of the Web, I was a little bit puzzled by this remark. That’s true that the obvious evolution of messenger (or any other chat client) is a better and better integration with the rest of you’re environment…
    So should we oppose loosely integrated “web application” to highly integrated local apps…
    Not sure that there is an opposition here:

    • If it was possible to do Google Earth using a standard browser, I am sure that Google would have done it. It’s just a question of availability of the techno (in fact, I can predict that in two years, Google Earth will be available as a Web application).
    • The Web is probably the best platform for integration. In fact, it much easiest to share application between web app than to share locally, most of the time. And a good example is Msn messenger. The sharing (of information) is mostly done on the server side, not on the client. And it seems that the evolution of messenger and hotmail, is to a be a full web/Ajax based application.

    So the Web is probably the best platform to do component integration, and the best integration tool is the Browser.
    Of course, there is some need for some vertical and specific application, but most of the people do not really need it. The few specific needs can be solved by a “Widget” approach, similar to Konfabulator or Safari: still browser (ok, it’s not 100% the case), but this browser is skinned and just displays a single web page, but in a very good way…

    Again, as stated in one of my previous post, “The end of the OS“, I think that in the future, the operating system might be a detail, as long as you have a very good browser…So I think that browsers will be here for a long time, see you in two years….

    New Yahoo Maps beta

    I’ve just played a little bit with the last version of Yahoo Map beta.

    First, my comment is that the application is big, in size! It tooks literraly more than 10 minutes at home to download. Yes, I am one of the few without DSL, so I still have to use a modem! The beauty of GoogleMap was his simplicity and the use of standard Web Technologies. I guess that being late in the race, Yahoo had to find something to differenciate…
    The application is fancy, but not really innovative. For instance, you have three text string for your request (one for finding place, the others two for directions) while Google had just one box for all of these…
    The other strange thing, when you look inside, is that all tiles are predefined Flash elements. But these elements just seems to contains a bitmap..sounds strange (look at;col=1308&row=923&z=5 ).
    One the other hand, the AJAX interface seems to work quite well. The good news is that if you use it, all tiles are png images, but with some strange choice: they are 258×258 (256×256 seems much more simpler! :-) ). But anyway, it should be quite easy to use them in other mapping application, like the good J2MEMAP! ;-)

    Technocrati tags: YahooMaps