Fragmented Technology

I've been knee deep in my own world of fragmented technology: web servers, XML, iPhones, widgets, treos... the list just keeps growing. And these are just the technologies I use. If you take all of the core technologies used to develop networked applications and all of the applications and devices used to access *those* applications it gets complex really quickly.

In technology there is an idea related to growth and complexity that I consider somewhat classic: As any given layer of technology becomes overly complex to manage, a new layer will be created to manage that complexity. When the new layer is too complex, another layer emerges. Running a business with spreadsheets, then ERP systems, and then EAI is a great example. As our technology becomes saturated, we invent technology to manage or replace our existing technology.

We are seeing this same type of phenomenon on the consumer side with applications and devices. We have more services that we are trying to connect to with more devices. An individual case is not that complex but taken in the aggregate, across all users, devices, and services, we have a lot of technology that inter-operates barely sort of.

Three trends highlight what is happening. Network based service applications are competing to open their API's, internet connectivity from mobile devices has increased 25% annually over the last three years (PEW), and users are consuming streams of data rather than discrete documents updated daily. More applications, increased mobile connections, more data.

Users have more services that are open to access. They can be integrated with other applications and accessed from specialty UI's. Users are increasingly accessing their online services from mobile devices. PEW also noted that mobile access corresponded to a dramatic increase in overall time online. And there are more frequent informational updates to the services they are checking, creating a vicious 'always on' circle. Sounds complex.

In my own circle of technology I have medium access to services from my different devices. My corporate sponsored Treo can access my Outlook contacts, but not my personal contacts. Likewise with email and calendar. One of my personal email accounts has a great mobile interface, the other doesn't. The only way I can 'see' my wife's calendar is to call her on the phone or email her. SMS and IM isn't managed although increasingly I need it to be. I have no way of sharing or managing my Flickr photos or LinkedIn account from my phone unless I am willing to deal with a mobile browser. even on the iPhone, no thanks.

We have fragmented our technology. We use what we can wherever we can. But so far our technology does not appear to be 'Fragment Ready'. Sort of like 'Intel Inside' but externalized. Let me use my technology wherever I want to on whatever device I want to. Then I can stop wading through all of this technology and just use what I need when I need it... until the next wave of inventions.

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.

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.

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.