Devices for Widgets for Devices

I spent the last two weeks on the Pacific coast of Mexico on a beach nestled alongside the jungle. The only "device" available where I was staying was an XM radio. Aside from the inherent fact that some folks consider radio and music the most important, most necessary, form of communication, I was intrigued by the XM radio itself.

It was about the size of a Palm Treo with a small black and white screen. It also had a remote control with even more buttons. The radio physically plugged into an amplifier. So there I was surfing radio stations on a small computer that was communicating with a satellite. The form factor, another device that fits widget sizing, was not lost on me amidst the relaxing environment. In fact, it seemed more pronounced as it fit seamlessly into that world. I didn't *feel* like I was communicating with satellites. I felt like I was using a radio widget on a "device" that was plugged into a stereo system.

When I got back a few days ago I saw a Widgify post that talks about physical widgets. Ricavision has announced a wireless device with a 3.5 inch screen that supports Windows SideShow (widgets). You can attach it to your refrigerator, take notes, and use widgets! Marketing silliness aside, this device makes a lot of sense. When there are devices that are portable, networked, and have applications that I use good things happen.

• the line between "desktop applications" and "widgets" blurs. Would I like a device that travels with me that works equally well as a touch point to my social networks, works with the latest communication mediums (phone, email, IM), a note taker on the road, a contact list manager, a calendar, remote control for my home media center?

• Would I like to be able to access these same applications and associated information in desktop appropriate versions from any computer using a full monitor and keyboard or other enhanced hardware available only on a desktop?

• Would I like to ignore calling plan minutes and have generic data access, using my IP telephony application of choice? Note to phone companies: drop packets not calls.

• Would I like to extend the physical functions of the device through plug-ins and then upgrade the entire device when the same functionality is built in? (satellite radio, cell, keyboard etc...)

There is an argument that there are some devices that are pretty close, and I agree. The iPhone is a great example, supporting a widget environment and smooth wireless capabilities. But it is the vision of one incredible company, still tethered to a closed cell infrastructure and other proprietary standards. Not to mention the fact that it is not seamlessly tied to my desktop applications.

What if we had wireless data connectivity, enough standards to make widgets platform and device compatible, and well thought out widgets and services that bridged that gap between quick portable device based interactions and longer desktop oriented interactions. Looking at the XM radios, Ricavision's device, and the iPhone I see the puzzle coming together albeit under proprietary silos. Here is one person's vote for open hardware and infrastructure, supportable software standards, and well thought out services.

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.

Google (Widgets) Gadgets

Google announced Google Gadget Ventures to fund the development of Wadgets (Widget+Gadget) for iGoogle. They offer two types of funding:

• A grant of 5k for those that have an existing gadget with at least 250k page views per week, in their gadget directory.
• Seed financing of 100k, in return for an equity stake, for companies that have already received the 5k grant.
  

A quick read will provide all of the details (really, the description site is only two pages):
- Google Gadget Ventures
- Google press release
- TechCrunch (where I first saw it) coverage

This is a quirky validation of webtop and desktop wadgets. Quirky because Google is using an incentive as blunt as brass knuckles to encourage developers; yet they need to have already established a somewhat popular wadget. Validating because they see that there is a wadget platform war brewing with Yahoo!, Apple, Microsoft et al and they are making an aggressive move.

It appears that the Wadget Economy still revolves almost entirely around the development of wadgets by internal teams or developers for hire. Clearspring has taken this to a new level, offering cross platform support and reporting, but nobody has stepped up with a pure wadget play based on the inherent value of a given wadget or set of wadgets.

Google cannot make this happen single handedly but they have raised the ante. Fuel for the fire. Looking forward to the next steps from competitive platforms.

Windorphins: when widgets lack a spine

I nearly collided with a colorful sign announcing Windorphins today. It looked like a cross between Tomaguchi and Spore. Friendly amoeba like creatures stared back at me as I tried to make sense of their name. In fact, they are an eBay marketing campaign.

The landing page is a fun tongue in cheek look at Windorphins: 'real' video footage of their discovery, an anatomical look at where they can be found in your body, and of course a lot of links back to eBay.

The fun begins when you make your own. Here is the embeddable widget you end up with:

Make your own Windorph

Windorphins are pure widget silliness. What I like about them is that the Windorphin itself is pure widget. Simple HTML makes it portable to any web page. What I don't like is that they are also pure silliness. A little silliness goes a long way when combined with at least a dash of functionality. Pure silliness remains just that, silly.

I believe most people will have an experience similar to mine. Check out the site, laugh a little at the corny, sort of classic, marketing jokes , make a Windorphin, and move on.











What if...

• There was some functional backbone behind my Windorphin?
• It started to look a little lean if I hadn't been back to eBay in a while?
• I could add more kooky items to it if I bought or sold something on eBay?

That would add another dimension to the Windorphins and amplify the impact of the campaign. I would be more engaged with the technology and hopefully follow an inherent 'call to action' to use eBay. As it stands I had a few minutes of silly fun, spent more time on blogger.com than eBay, and am left uncertain as to what the grand auctioneer was trying to accomplish.

As we are more thoroughly inundated with these 'viral' campaigns based on lightweight widget technology the payoff needs to be greater. Widgets need a spine. While silliness abounds and is fun, Windorphins have not met their potential.

Random Widgets?

Alex Iskold of Read/Write Web has a great post in which he dissects the Random House book widget. What I like about his post is that he looks at the whole picture: the widget, back-end service, and the strategy. My short attention span summary is that a widget is only as good as the service behind it. Random House has an outstanding service.

Other points of note:
- Provides full search and thumbnail browsing of book contents
- Service behind it offers even more including full-size page views
- Branding widget delivering useful end user functionality
- Instance of the widget is on his post

This left me thinking... If I can have a widget on my web page that lets me promote and preview a book, why not a widget accessible from any of my devices that lets me read book and keeps track of my place? Or, as Alex mentions at the end of his post, it would be great to see aggregated comments from people that have interacted with the widget. Combine them and you have an instant and portable book club.

Read his post at read/write web.

widget, widget, widget

Widgets have been making a lot of noise recently. Impressive for a word that traditionally was used in reference to a hypothetical product. Only in the last twenty years or so did widgets graduate slightly in meaning when used to refer to software user interface controls. In the last several years their meaning has suddenly solidified. At least in the world of software, and particularly the web. Widgets can be found everywhere from desktops to websites. They are developed by hobbyists for fun as well as professional developers in support of well orchestrated advertising and brand campaigns. Today’s widget is no longer hypothetical.

The widget still enjoys a broad definition even as it has become more grounded. In the last six months widgets have been caught in the act of counting page visits, displaying RSS feeds, keeping track of to-do lists, playing Sudoku, reading email, and even placing a phone call or two. The widget appears to be defined more by its form factor, small, and location, a widget environment, than its' specific functionality.

Given this broad functionality, however, there seem to be three primary types of widgets:

Embedded Widgets
The most popular widgets are embedded on an existing web page. Whether it is a personal page a la myspace/facebook (myspacebook?) or a corporate site, there appears to be an endless array of widgets from varying sources that can be embedded on a web page by cut and pasting some HTML. Heavy on the fun and branding, light on the back-end functionality.

Webtop Widgets
These are web based widgets found on a page that contains a personal collection of widgets. Netvibes is one example of a "personal home page" based on widgets. Users place selected widgets on a page and then configure them. The widgets are provided by the website or developers that have worked with the specific website widget API.More functionality than their embedded counterparts, less media play.

Desktop Widgets
Finally, there is the desktop widget provided by Yahoo! Konfabulator, Google Gadgets, Apple Dashboard, and now Microsoft. These widgets are nearly identical in terms of the functionality you would find on webtop widgets, although they are generally much easier on the eyes. In some cases they enjoy a little more functionality, like integrating with desktop applications, because they are operating on the desktop. I find these to be on the extreme end of offering the most functionality while being right in the middle in terms of branding interjection.

There is a lot of energy pouring into the widget world across the different types of widgets. This is creating opportunity as our interaction with widgets takes on new meaning. Here are some of the questions I have encountered while trying to navigate these widget waters.

- Where are widgets going in the long term? Trendy branding tool or a new form factor for computing?

- How will widget functionality evolve? Information couriers or de facto multi homed interactive front end to applications we use every day?

- What types of businesses will start around widgets? There are already some businesses that appear to have legs, like Clearspring.

- Where else will we see widgets? cell phones, cars, smart homes, airplanes?…

- Where are we headed in the widget platform wars? Yahoo!, Google, Apple, and Microsoft have all lined up? And those are just the noisiest players.

- Will they ever have a more descriptive name?

I don’t have the answers but I am looking for them… and promise to share what I find on the trail of the evolving widget. This should be fun.