Widget Standards

Over the last couple of weeks there has been a lot of news and blog discussion regarding widget standards. This was due to a requirements draft document being published on July 5th . After reading the blog posts I was a bit confused because I found references to two different but related documents . I found the source material, took a look, and am reporting back with top level information.

There are actually two documents that interested folks should take a look at.

• The first is the widget 1.0 standard. This is fairly slim document, with a lot of known gaps, and a lot of requests for comments. People should comment. I posted to the mailing list about using namespaces. The list is home to other standards discussions, widgets are not the prime focus, be forewarned. This document is from November 2006.
  
• The second document is more interesting because it is packed with the potential of the standard. It is the widget 1.0 standard requirements document. This is the document that was most recently released on July 5th, 2007. These are the requirements for the specification. While it is not close to complete, it is a robust outline identifying areas that need requirements. Reading through this document will get any widget developer thinking in a deeper way about widgets and widget engines, what they need to support, how they will evolve, as well as their current state. Post if you want to help shape your future!
  

A key take away from these documents is that they are focused on desktop widget platforms. This is a mistake. Desktop and webtop widgets share so much in common. In many cases they share the same technology infrastructure down to the scripting language. While desktop platforms can offer greater access to both local and remote functionality, webtop widgets appear to be a viable, and healthy, subset of desktop widgets. Why not make the convergence official and write a specification that will cover all of the widgets from the start?

Another important point is that the technology stack is headed towards web based technology. This appears to be a natural direction of all widget development. However, it does strike me as odd that a potential specification would reference requirements of other specifications that have not yet resulted in effective standardization. I don't have a great answer but it's not hard to foresee a point in time where a widget developer is creating a single widget with a lot of crufty code that is dedicated to allowing it to run in different 'standard' widget engines with differing 'standard' implementations of JavaScript ECMAScript. This is hard enough with the current browser situation, let alone widget platforms and application platforms. Not the fault of specification authors, but a major productivity problem no less.

Don't get me wrong. I am all for a widget specification and will continue to support it and provide comments. In the long run it will help. And I don't offer any specific answers (define a subset of ECMAScript that must be/is already supported?!?). But I am not holding my breath for write once run anywhere. I've seen that movie before, it didn't end so well... or rather it hasn't ended, it just keeps on playing and playing and playing, never quite delivering an ending. I hope the widget standard will bring the environments closer together, so developers can deliver more, and better, products to people who love to use widgets.

widget standard

Widget Prime(r)

The widget conversation continues. More activity around the 'what' and 'how' of teh modern widget. Just as the widget specification was released several people began posting retrospectives or primers on widgets. There are three posts that I feel are worth reading for anyone tracking this space.

The first two are by Niall Kennedy. Take a look through all of his posts, well worth it. He appears to put a fair amount of time and energy into each entry. They are substantial and filled with specifics. He has one post on widget formats and another on updating the data in widgets. As you might imagine these are on the technical side.

The last one is from R/WW. This post looks at the short history of widgets. It can certainly be argued as to the who/what/where/when of the origination of widgets, but this post starts at a practical place that is highly relevant and appropriate for the current conversation.

Bubbletop Beta and c0ding c4mp

The Bubbletop Widget Platform is about to launch their beta site and open it up to developers according to an invitation they have sent out.

From their email:

"Have you ever felt like your RSS feed aggregator was missing a social component? Want to see what your friends are reading? Then BubbleTop is for you"

Sounds fun. Note that the site still says alpha.

They are also holding several events, including a c0ding c4mp (c00l!), to generate widget developer interest for Bubbletop.

This is the same group that is behind Pikeo. It all looks promising, well thought out, and nicely designed. I am interested to find out to what degree they are offering a full fledged widget environment and how it differs from what is out there already. They did mention a social component...

Clearing the API Air

There has been a lot of talk regarding web site API's recently. Whether it revolves around the hand to hand combat that LinkedIn and Facebook are about to engage in or the ever present beat of the Googleplex with their mapplets API, the API is the cool kid in school. API is a serious kid though: a cornerstone of emerging web technology, driving mash-ups, wadgets, and generally connecting the dots between walled gardens. Lost in this talk though, dare I say hype, is what an API actually is. There are two parts of the prevalent API usage that are actually quite different.

Ye Olde Screen Scraper
The original web application API is the screen scraper. If you saw something on an application page that you wanted you could write a client to access that page, grab the specific piece of information you were after, and then use it. This has been used for everything from short term dynamically generated pages to long term storage in a database to enterprise integrations. There are many reasons *not* to screen scrape such as changing HTML and licensing, but it is a simple, powerful, and time honored way of accessing data and processes.

The REST style API changed everything...well, sort of. What a REST API offers is often the same data and process access capability via an authorized interface. The data access typically goes far beyond what is presented on a page and processes are much more convenient to kickoff. There are concrete methods, data structures, and security. From a high level though not a lot has changed. We have essentially had the ability to pull information from other web applications since the first HTML page was presented. As Yoda, I am certain, once said "An open API an IPO does not make."

Along Came the Plug-in... and Facebook
Now mixed in to this API discussion are another set of API's. Rather than let developers pull data or kick off processes, plug-in API's allow developers to embed their functionality into in existing application... as if their functionality was native to that application. This changes the game. And that is what Facebook has done to much publicity recently, but the plug-in has been around longer than the web page. It is great that they have finally become friends although it is not an easy friendship. API's are challenging to get just right, plug-in API's are even harder. Not to mention standards.

An API that includes a plug-in component enables developers to not only build integrations, but to extend applications in a direction they deem worthy. Take a look at all of the widget platforms. They are essentially dedicated plug-in architectures. Together they have generated thousands of small applications.

So the next time someone says they are going to offer an API, ask them what kind. You'll be able to tell if they are just trying to get one more man on the moon or looking to orbit a distant star. And we should all be wary of any promises 9 months out, that's just long enough to forget.

They Are Beautiful Coglets

A quick note on two promising widget related releases.

They're Beautiful (They Are!)
The first is the well covered flower widget from They're Beautiful/Jackson Fish Market. The application lets users send a bouquet of flowers to someone via email. The flower designs are striking and each arrangement in one of a kind. However, once you have some flowers you need to water them otherwise they will wilt. Simple, compelling, the interactive functionality missing from the Windorphin fun... and most widgets for that matter.

The second part of the service is the widget itself. It simply let's me show off my flowers on a page. This widget reinforces the interactive nature of the flowers. Now that they are on public display I have a greater incentive to keep them looking great by "watering" them. Simple, compelling... uh, Beautiful anyone?.

Excellent execution of an idea that has much more potential. I am curious to see where they can take this.

Here is the widget:

Coglets
The second item is Cogheads announcement of Coglets. Users can now embed Coghead apps in a page. While not providing the most compelling front end, Coglets are one example of a back end data service that can drive a widget by providing state and interactivity. The video demo is stale, but the idea is compelling. The service is fee based.

There are several example sites, including a presidential race tracking site. This example was incredibly slow when loading the application from Coghead. I assume they are getting a lot of traffic this morning... right? At any rate, the examples I looked at were based on creating a full website with embedded functionality, but the exact same model can be applied to a smaller form factor, like a widget.

Again, a lot of potential, looking forward to seeing what adventures users are taken on with this technology.

The World's Greatest (Almost) Widget Platform! The iPhone...

The world of widgets and cell phone applications are inherently linked by a simple trait: their form factor. A small box on the screen with "just the right amount" of functionality packed in to it. The iPhone approach to the web bridges the world of widgets and mobile devices in one sexy package. Introducing a tres cool and powerful widget platform. Although there is not a full fledged API available, it is already shaking up the widget game through it's built in features such as touch screen, html tags for dialing a number, and accelerometer that developers have been able to access.

There is a lot of energy going into developing all types of widgets on web/desk/device-tops. For the most part widgets, often read only, do not need to distinguish between what platform they are being used on as long as the underlying software is compatible. The iPhone presents a platform that offers some well placed features front and center that are not necessarily compatible with any other widget platform. How do I emulate a touch screen with *two* points of contact? Use two mice?

Now I assume this is actually a problem. For me it is: I love the idea of a widget that I can use seamlessly across all platforms. If I save a feed on my desktop widget I want to be able to access that same widget with the same feed from any connected device. For me this means having the same user interface as well, or pretty close to it. maybe I use a mouse as a pointer on my desktop and touch a screen on a mobile device. If I have access to all of my information across platforms I want there to be as little friction as possible. I'm sure Apple is thinking about this with respect to their Dashboard.

Which brings us back to the iPhone: How do widget developers handle cross widget platform support when some of the important features become deeply tied to the platform. I can't 'squeeze' my screen on my desktop. It's also a bit strenuous to rotate the monitor quickly. But I want access to the same information, with the same features, across very different devices. When I looked at some of the applications developed at the iPhoneDevCamp this last Friday it was clear that most of the apps are viable on my laptop but tend to depend on iPhone features. Some more than others.

Web based services provide the data storage, retrieval, and processing. Widgets define the form factor. Platforms define what can and cannot be done when combining those two. Apple is not known for it's open nature. I don't mind if I can't change the battery on an iPhone but I hope I can least develop cross platform widgets for it.