It’s been out for a couple weeks now, but I wanted to point out a new Clearspring widget product I’ve been working on - desktop support for all widgets on our platform.

We support Vista Sidebar, OSX Dashboard (Leopard and above) and Yahoo Widgets for PC with a simple download from the widget service menu (which you can get to by clicking on “Get & Share”). Why not try it out with Radiohead’s new Clearspring widget that’s been burning up the internets:

Integrating mobile into the equation, we have a bunch of NBC-Universal widgets like the Top Chef widget below that can be sent to mobile from the web or from the desktop. Just click on “Grab It” to download to your desktop or send a link to your phone:

It has been an exciting process, getting widgets off the web and onto devices, and we’re just getting started. We’re lucky enough to have some of the best content on the web using our platform, and we want to empower the user to define how and where they want to consume it. If you have any feedback on where you’d like your content to go, let me know in the comments!

Man, someone please reply to this Apple job posting and make Exchange sync work on iPhone. Pretty please.

Zumobi, the Microsoft-backed mobile widget platform, has developer docs for the platform posted on their site. I’ve been curious to see how to develop for it, since they’ve come up with a unique “zooming” paradigm for navigation.

Really all the zooming does is transition between several canvas states made available as drawables to your “tile”. Zumobi calls these mini-applications “tiles”. Anyway, Zumobi takes care of the transitioning and navigation, you take care of setting up your canvases and what’s displayed on each.

You can do this using Zumobi’s XML markup. To get more sophisticated, you can give yourself a canvas to draw to and use Javascript and their JS calls to do the work.

One interesting tool they provide is SyncSet class that allows the content creator to define content that gets synced in the background with Zumobi’s servers. Yep that’s right. Their servers actually proxy, transcode and optimize the data for you and then host it. This is attempt at making live data update as quickly as possible with the lowest amount of bandwidth. What’s more, dedicated servers even out the QoS over all first and third-party tiles created for Zumobi. It’s a nice concept actually - the user experience will be more consistent, and developers with little hosting resources get the same performance as the big boys.

Devices with various screen sizes and layouts are handled with the concept of guaranteed widths and heights, and available widths and heights. You can restrict yourself to the guaranteed dimensions and dynamically render larger if you have more real estate. As you use Zumobi’s provided UI objects like images, lists, etc., you get dynamic scaling for free in some cases.

Generally, as an application framework, Zumobi works. It’s straightforward enough, and is an enticing package to create content for, given its built in ad-based revenue sharing model.

I’m also glad they call themselves an application framework, rather than a widget platform. Here’s where I get a little grumpy. The term “widget” is ambiguous enough. Some people think of widgets as third-party chunks of code that collect data and embed it in other places, like a web page, a desktop - wherever. Some people just call small one purpose applications “widgets” if they fall below some imaginary threshold of functionality that separates application from widget. Ugh.

My point is that collecting data from the web and displaying it on a mobile device somehow should not by default be called a widget. There are a lot of single-purpose apps for mobiles that collect data from the web and display them in an easy to access UI. They’re not all called widgets, and they shouldn’t be. Zumobi is the same. They are an application framework optimized for displaying data aggregated from the web in an easily-accessible mobile format. They know this, they use the right term, so kudos.

Widsets is the same. They’re another app framework. They kind of straddle the line though, because they call their apps “widgets”, but they do throw the term “mini-applications” around enough that I’ll forgive them.

What should be called a widget engine on the phone? Well, it needs to start with the definition of a widget on your desktop - which (if you’re not a UI designer that still calls checkboxes widgets) are the widgets you find on the web. Web widgets are mini-applications that can be embedded anywhere on the web, and (here’s the kicker) they use the same technologies that the web is based on to do their work. They are HTML/Javascript and Flash - the same stuff you see making up websites themselves. Because of this, they are able to flow naturally over the web and play nicely in many different environments. Desktop widget engines use the same technologies and frameworks to display widgets on the desktop, and have become a natural extension moving web widgets out of the browser.

In my opinion, a true mobile widget engine would extend this to the phone. Sure, Zumobi and Widsets use XML and Javascript. But they do not render web HTML/Javascript. You can’t take your code from the web and easily port it to these frameworks - there’s redesign and re-engineering involved, and a lot of proprietary calls and markup.

So the argument becomes “The phone is different from the web. There are different challenges and UI paradigms. We need something built specifically for mobiles.” Yeah, I won’t argue that you need to optimize for mobile accessibility, but right now above all else, mobile development fragmentation is a huge barrier to getting good content mobile. What we don’t need are more proprietary markups and toolkits to worry about. We need to make it easy to get content to mobile phones, and HTML/Javscript/AJAX as it exists on the web is a really close fit. Don’t fragment the development space more. Create bridges to adapt existing content.

So, as an application framework, Zumobi has some chops. Depending on how far they’re able to port it, it may be a real contender for mobile application development. But a widget engine it’s not. So news outlets and bloggers, stop calling it that.

I’ve written about my TomTom One GPS here before, but it’s cool how this thing just keeps being relevant.

You always see reviews for the One claiming that it’s just a basic device, and does the bare minimum. And sure it doesn’t have text to speech or mp3 playing (why?) like the more expensive ones. But having the online component and a user community really helps it out.

For example, it’s the only GPS I found whose interface I could skin to match the instrument cluster of my car. I just came upon it randomly in the big list of skins available online.

This Google maps integration is the latest to take advantage of TomTom’s desktop software. Tell Google maps to send to TomTom and it opens the desktop software and uploads the destination info.

What would take it to the next level though, is if it made use of its Bluetooth connection that it uses to obtain traffic. All TomTom needs to do is store your routes and POIs server-side - you can add them from Google or whatever - and have the device check for them when it connects. This way, you can leave the GPS in the car and still take advantage of the feature.

Regardless, even if I won’t use it all the time, I know someone who will. The TomTom and Google Maps are two things my mom has and knows how to use. The one thing she doesn’t like doing on the TomTom is searching for places, so this fills that gap nicely.

I love being in the era of connected, software-upgradeable consumer electronics.