TomSoft

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…

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, w3c, springwidget

Add comment November 10th, 2006

Gmail for mobile: near perfect….

I finally had GMail client application working! The program was always complainging with the following error: “This program require a working connection. Check your settings“. My settings were good, and it was obvious that the connection was on-going between GMail and their server.
In fact, the problem was that my GMail account had a default language which was not english (in that case french). So switching it to english solved the issue. Surprisingly bad user experience for a Google application.

Anyway, the program is working fine, and already a hit. I will not go into the details, C.Enrique made a nice “review” on it…
Just some though:

- compared to all others mail program that I was able to test, it’s from far the most easiest to use, and the most readable. It shows how complex it is to create a simple to use UI (this is not a framework issue, but a usability issue)
- shows also that except from my small connection issue, most of the mobile are ready for mass deployment of connected applications. Mobile2.0 is heare, and it’s a perfect exemple of the power of synchronisation vs browsing (and for me, this is a mobile Ajax application).
- MIDP still have some works to do, especially on the ability to launch one app from an other. Today, no way to launch GMail client from Opera Mini, or from a Widget engine. You need to exit, and find the app by yourself. Should be solved by “JSR211, content handler API”, but there is still no handset implementing this JSR!
Technorati Tags: gmail mobile, google, gmail, j2me

8 comments November 6th, 2006

Widgets: the next portability nightmare?

The 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: widgets, mobilewidgets, standardisation

5 comments October 16th, 2006

OpenLaszlo for mobile….

Sun/Laszo announced this week that they will work jointly on a new project called “Orbit”:

“Orbit” is an exciting collaborative effort between Sun Microsystems and Laszlo Systems enabling OpenLaszlo applications to run on devices supporting the Java™ Platform, Micro Edition (Java ME) application platform. This project will be delivered as part of the OpenLaszlo “Legals” multi-runtime effort, with first demos available before the end of 2006.

Laszlo sounds nice, it’s a framework based on XML/JavaScript that allows you to create and deploy Web application on different technologies: mainly Flash but soon DHTML (and now J2me?).

The promise seems a little bit big, so I excpect that exported application will have some limitation, but it is a nice idea to follow. Could this effort help to solve the “Widget fragmentation” issue?

4 comments October 13th, 2006

Myths of mobile Web2.0 (and mobile Ajax)

One of the next buzzword these days is “Mobile Ajax“, as THE technology that will save mobile applications. This was especially true with the recent announce of “SoonR”, the first mobile enabled Ajax application. Looks good, but unfortunately, I have no Ajax enabled browser out of the thousands of handsets we have here at MobileScope….

But this generates some buzz, and as usual, some hype. So, in a “back to reality” attempt, I’ve tried to discuss a few myth of “mobile Ajax” here:

• Mobile 2.0=Mobile Web2.0 (and Mobile Web2.0 = Ajax on mobile). Wrong, as this imply a choice of technologies. The good thing (or is it a bad thing?) with mobile, is that there is a huge choice of  technologies. If mobile is connected, does not mean that it is connected only through browser.
• Ajax is the only technology to create mobile mashups: (this is the same wrong statement than in the web): No, basically ALL technologies can be used to create mashup, to access to existing Web services:
• J2ME (and not need to use “JSR172″ to do this)
• FlashLite can do it to
• Native OS of course….
• Even Wap/Html/Xhtml can be used to create mashups…
• A few example of personal mobile mashups (done in “plain J2ME”)
• Google Map+WikiMapia on mobile
• or Flickr Maps on mobile
• Ajax applications will run the same on mobiles than on PC, and this will save us some porting costs. Wrong! Seems that the Write Once Run Anywhere myth is back!! It was actually already not achievable through technology designed for this, so I did not see how Ajax app (which is basically designed for one or two platform) will be able to address suddenly thousands of different platforms….. And all the existing so called mobile Ajax applications are ALREADY specific for mobile. The SoonR mobile version is not the same one than SoonR on PC….
• Ajax applications are a way to by pass operators….There is
  absolutely NO link between operators and this. Java, Flash, Symbian
  applications can be acceded directly by end user as well as Ajax
  applications (and with a bigger installed base). In fact, there is a
  link: as an Ajax is an online application, it’s easiest for them to
  block certain site if they want too….And no way to install it outside
  the browser! The biggest issue is not the access, is the billing…Or
  the business model. How to make end user pay for services in an easy
  way….

I like Ajax as one of the technology that I could use to create a better experience, but as discussed in one of my previous post, I think that the complexity needed both in the browser and the application is unnecessary on mobile device, and we should take the mobile  opportunity to solve some of the technical issue raised by Ajax on the web. There is also an interesting article from Dioan Hincliffe raising a few of the Ajax issues: Seven things that every software project needs to know about ajax.
A few of his remarks:

• Ajax applications are complex applications (even if they are doing simple things). This leads to this comment: “Good Ajax programmers are hard to find”
• The browser model (of Ajax) haves some limitation: no way to access to some local resources of the handset…
• The browser was never made for Ajax. In other way, ajax developer used the installed base of modern browser to create something unique.

Now, back to mobile….Should we try to duplicate current ajax complexity to mobile, with one model, or can we try to solve some of the issues of Ajax?

I am a strong believer of the last option. There are already three technologies that will play significant role in the future: J2me, FlashLite, and Ajax. Only one is really deployed now and it’s J2me. FlashLite is on the way and Ajax far from being a reality yet. But these three are complementary, and could work together in a perfect way, in a different and better model than on the web.

Technorati Tags: ajax, mobileajax, j2me, flashlite

13 comments September 27th, 2006

Grazr: Easily display feeds within a page

 Since some time I was looking for an easy way to display RSS feeds within a page. For instance, for J2memap, all announcment are now part of an RSS feed. Thanks to TechCrunch, I discovered Grazr, which is basically an RSS browser that can be embeeded in other pages. The results looks like this:

It’s fine, but I think that this widget could have much more configurable elements (feed title for instance) to make it more contextual to the page where it is displayed…

Technorati Tags: grazr, ajax

Technorati Tags: grazr, ajax

Add comment September 19th, 2006

Waterfall Drives IT Engineer Over the Edge

Another discovery of the blogosphere: Innovation Creators (and at the same time I saw that there was an “Ajax Badge”)…Take a look at this post: Waterfall Drives IT Engineer Over the Edge (full of comics, so a good reading for everybody!).

I saw this happens too frequently (even in a startup!)! As you may know, I am CTO too, and I take the last quote of the blog:

“I do not blame the poor developer who was forced to stick rigidly to “the reqs doc”, but I do blame his CTO.”

As a big promoter of Agile methods, I must agree, but rais some point on why reality is not as easy as it’s described especially when the team started, 6 years ago. Things have changed a little bit since, thanks to the Web1/0 and 2.0 revolutions…But Waterfall has been teach in school, and in “serious” industry as THE method to do software development. Write requirement, than write functional specifications, than write technical specifications, then develop, test, etc… A document nightmare….I am so happy to see the “DRY” (Don’t Repeat YourSelf) concept emerging for software industry

The other issue that makes Agile development not so easy is customer involvement:

• The customer haves a job to do, so they expect finished tool, and usually don’t like to spend time with unfinished product. They expect the development team to understand their needs, and produce something “good”
• Development team expects some input from the customer. If his customer does not spend enough time with him, the natural fallback is to tie to the only input he haves, requirement….

There are not excuses not to import agile method, but more things to be aware of…But once things start, things are truly going much faster… It’s nice to see that current generation will be “agile aware”, and will be proud to reuse instead of recreate, to get gratification from his product usage instead of the technical cathedral that hass (not ) been build…

Technorati Tags: agile, software

Add comment July 25th, 2006

What is a (mobile) Widget

This is a translation of an article that I wrote for a French blog, about “mobile widgets”. It’s a general introduction and description of the widget, and especially mobile widget concept:

So, what is a mobile widget:

A widget is generally speaking a small application, a little bit of code, that does one simple thing but does it well. The second important things about a widget, is that they can be combined together. The last one being the fact that usually, it’s fairly easy to develop a new widget (comparing to developing a full application).

To be able to run a Widget, you need a “Widget Engine”, which is the framework needed to run these micro applications. On the PC, the most popular is Konfabulator, and Dashboard on Mac OS-X. Web applications haves also their own widget, that can run within the browser, like clock, web counter, etc….These applications exists since a long time, it was called previously plugins, components, extensions, gadgets, but the real innovation is that it’s now in user hands: they can combine these widgets to create their own unique application. Typically, the user can choose to have CNN news, Paris weather, a Flicker photo stream, a clock, etc….

This approach fits particularly well on mobile world, where space on screen is limited, and where it’s not easy to switch between applications. Some companies like Widsets, Bluepulse, mFoundry, Bling and Opera have developed some widget engines. Not all of them haves the same approach, even if all of them recognize the filiations with Widget. Most of them are for the moment personal news /RSS reader (Widset) but extremely well done, others allows some interaction with the user (plusmo, mFoundry, etc…). All of these engines -except Opera widget – are for now available on top of J2me. The interest of widget is both for users and developers:

• For the user, he can create his own application buy choosing and customizing his widget set.
• For the developer, he can easily develop and deploy application for end user. Of course, not all application can fit into the widget description, but I believe that in the future, a good combination of Web/Ajax based application and Widget will fill 80% of the needs.

I recommend particularly two applications: Plusmo, which is in my mind on of the most interesting one but with a poor UI, and Widsets, which is the opposite: a great UI but the application itself is lacking of maturity. Of course, I am not any more objective as we (Webwag) also have a mobile widget engine.
I believe that Widget will be the equivalent of “Web2.0″ app for mobile: adapted to small screen size, solving in an elegant way the portability issue, providing real interest for the end user it’s certain that this kind of application will become more frequent in the future months.

Of course, there is still a lot of open question: does a “standard” wil emerge (see C.Enrique post
on this)? Can Desktop be reused on mobile? (I think that the question
is more “is there an interest to reuse desktop widget on mobile”).

If now widgets are in most of the case a way to access to some RSS content in an easy way, I believe that their scope will extend to integrate more interactivity with end user, and conquer more space on your phone sceen!

Technorati Tags: j2me, javame, mobilewidgets, widgets

14 comments July 5th, 2006

Yahoo Hack Day (MashupOrShutup!)

Techcrunch made a short description of “Yahoo Hack Day“, where Yahoo employee can show the result of their work on their “personal project”. 102 project were presented, and nobody spend more than 24 hours on this project.
Most of the companies try to promote internal innovation like this, allowing people to spend 10% of their time on other project. What is really fascinating, is that with Web2.0 tools and approach it’s quite fast and easy to develop a prototype version of a new service (mainly mashup based), and make this dream of internal innovation possible.
I would loved to be in such presentation!

Technorati Tags: yahoo, web2.0, innovation

Add comment June 19th, 2006

Widsets review: just another RSS reader?

I’ve just played a little bit with the application, but on the emulator only, and here is my first feedback:
Basically, it’s a kind of RSS reader for mobile, where you select on the server side the feed you want to read. In that case, a feed is called a widget but does not provides any interactivity.

• The first level of UI is really well polished, and gives great hopes about the app.
• The web site is an high end Web2.0 site. From the Web, you can browse widgets, select one, configure it.
• When you have selected your widget set, just press update to update it on your mobile..

But:

• The application does not work on my mobile! (big problem for a mobile app). Still waiting from feedback from the Widset team, but it seems that it’s linked to the usage of TCP which is not open on all operators network, instead of plain old HTTP.
• The first level just show you the icons, gives very few feedback about “whats new”. The onlylinformation that seems to be displayed – and not on all feeds – is the number of new articles in the feed. Once the first “waooow” effect is gone about the UI, you realize that it’s not so user friendly: the button are big but does not carry so much information.
• The “preview” widget from the web is just a static one. In fact, it’s a picture provided with the widget set. It would have been interesting to have a “real” preview
• When digging in, the second level of UI is not very useable too. For instance, on the weather widget, you see a list of days, and you have to select that specific day to see a two line information about the weather…
• The widget can not be configured on the mobile. Needs to go on the web site! Even if I really l ike the Web site, I think that there is plenty of uses cases where you need to configure such app without any access to the web site, for instance, when you have changed your location and want another RSS feed.
• No picture is displayed when reading the feed, except for the Flickr one.

There is an “SDK” available, where you can change the look and feel of the feed: color, icon, etc…

Widset haves a good Web2.0 site, but an average RSS reader: no picture display, lack of browsing methods….

So if I have to compare the three on this race up to now, Plusmo, Widsets and Bluepulse, Plusmo is still ahead of the others….

Upadate: Thanks to some information coming from widsets guys (see the comments), I was finally able to configure my handset. I had to change the default Orange access point to another one – which is strange, as all the other app worked well. Anyway, it works, and I must say that UI is great on mobile. Does not change most of my remarks, but this put another level in the  level of polished UI in J2ME….

Technorati Tags: mobilewidgets javame j2me plusmo widsets rss

18 comments June 9th, 2006

Reality Checking the Web2.0 Architecture

Some great comments about Ajax in Steffen Meschkat talk at Web2.0 summit: “Reality Checking the AJAX web application architecture” . I especially like this slide:

The bad thing about doing something right the first time is
that nobody appreciates how difficult it was.

Web technologies give us plenty of opportunity to
appreciate how difficult it was.

But this confirm my view about the fact that even if Web2.0/AJAX architecture is a great improvment, the level of complexity and layer is increasing rapidely, and mobile should learn of this…

Technorati Tags: ajax, web2.0

Add comment June 5th, 2006

Web2.0:back to the roots

Google just released
recently his “Google Web Toolkit”:

Google Web Toolkit (GWT) is a Java development framework that lets you escape the matrix of technologies that make writing AJAX applications so difficult and error prone. With GWT, you can develop and debug AJAX applications in the Java language using the Java development tools of your choice. When you deploy your application to production, the GWT compiler to translate your Java application to browser-compliant JavaScript and HTML.

So basically, it’s a toolkit that can be used to write Web2.0 application in
Java, and then translate it into some JavaScript+librairies.
It’s quite nice, writing client web applications in Java that execute in a
browser..Hey, but stop, this reminds me something: yes, the applet, and these
small pieces of Java running in a Web Browser? Yes, sounds very similar,
however, the Applet failed in their objective to be the technology for browser
application. Maybe it was too early and browser / pc capacity were not ready,
but also it suffered from a lack of interaction with the rest of the browsing
experience, while this is much better with Ajax2.0 app.
But basically, were are here: JavaScript/Ajax was just a technical way to solve
previous issue. Honestly, result is great from the end user point of view, but it’s
horrible from the engineering point of view. Writing complex Web2.0 app is a
nightmare, with a lot of different layers (Java, JavaScript, Ruby, Sql, HTML,
XML, etc…), translators, etc…

May be a message for the mobile community, could be also to learn from our
previous mistake, and make what was initially planned for web happened on
mobile: rich client app that can be downloaded and run within a browser, and
avoid this complex multiple layers.

We already have the technologies available on mobile (XML, J2ME, SVG, etc…)
we just need to tight them together in the right way.
I hope that this ideal scenario will happens (through JCP? 3GPP?) but I am
afraid that once again, the fight between standards, companies, etc… will
lead to a situation where nothing will really emerge, and we will leave again
in a world of translators, layers, and complexity…

4 comments May 19th, 2006

Cool feature of map.ask.com

map.Ask.com provide a service similar to Google Local/Map. At a first view, nothing really new. But what I really like is the “add location” feature. Just click on a point in the map, and this will put a marker on the map, with the street location on it. Technically speaking, this is reverse geocoding, but it’s not provided by Google. If you put more point, then ask.com compute the direction between these two point. You can even move the point by dragging them, and the direction is recomputed in real time. No more that what a navigation system does, but for the first time avail from the web!

Technorati Tags: maps, googlemaps

Add comment May 12th, 2006

BluePulse: widget or browsing?

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).

Technorati Tags: mobilewidget, ajax, javame, j2me, widget, microwidget

4 comments January 23rd, 2006

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”….

So:
- 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 ajax wireless javame

2 comments January 8th, 2006

MicroWidget is on the 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:

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

5 comments December 28th, 2005

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

Add comment December 15th, 2005

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….

Tags: Konfabulator widget Yahoo

Add comment December 11th, 2005

Next Buzz: Mobile AJAX

2005 was probably the most exciting year since 2000 for the Web, thanks to the thousands of new projects, most of them based on the usage of AJAX to create a new and compelling user experience. One interesting question for me, involved in mobile, is what will be the impact of this revolution for mobiles?

Well, seems that the Ajax buzzword will be in all mouth in the coming months, and Opera is already surfing on this.

Thirst thing, is do we need Mobile Ajax?

I think that with the generalisation of data network (GPRS,EDGE or 3G), the services will be more and more interactive. But the current technologies are far from providing a compelling user experience on mobile. Wap (or even HTML) applications look like ’99 Web app (for the best ones). So I believe that looking at what’s happening on the web, many people will provide these improvements to mobile, and this will be an improvement.

And one side note: Google local for mobile IS NOT a Mobile Ajax application (just like J2MEMAp). It’s just a monolithic application created for mobile, which can not be updated, or changed OTA (unless you reload it). I guess that I should define what I think is mobile Aj

So what are the various technologies available, or do we need new ones?

A first answer is to say that we already have one technology that could fit to Ajax requirement: be able to execute locally a small program downloaded remotely to add interactivity in “web pages”. J2ME (oh, sorry Mr Sun, JavaME) seems to be perfect for this. It’s a small bytecode, cross platform, web oriented, etc… However, J2me (in fact CLDC) failed in one important topic: the inability to download OTA some new byte code. So an application, once downloaded, can not be easily changed, modified, etc…. And even worst, you can not jump from one app to the other: from a calendar to the address book for instance. So if you want to do something great, you need to create a -relatively- big monolithic J2ME application. And I do not speak of security issue (see below).
One the other hand, there are plenty of advantage to J2me, and this could be a good candidate for being the scripting language for mobile Ajax application, or the framework basis for this, but it needs to evolve a lot if he wants to achieve this level.

One option (the one used by Opera) is to write a browser in J2ME who contains some Ajax component. Honestly, I did not take a deep look at the opera mobile (the J2ME version) right now, but I doubt that the have a scripting engine in this version…And what will we have at the end: an interpreted VM being able to run interpreted scripting language… And I am sure the several other initiatives are one the way.

The alternative is not numerous. Flash lite could be a candidate, but the first issue is the deployment: very few handsets yet have it right now. But technically speaking (and here, I am not a FlashLite expert) it seems that many of the J2ME limitation does not exist anymore, especially the one concerning the limitation of an application to one single binary. And probably the first truly mobile Ajax experiment will come from here.

But whatever is the option, I except a lot of buzz on this, conference, announces, etc for the second half next year! So let’s be ready for the Ajax wave on the mobile,….

Technocrati Tags: J2ME JavaMe Ajax MobileAjaxFlashLite

Add comment December 4th, 2005

Next Posts Previous Posts