The Adaptable Client

Darwin noted that it was not the strongest species to survive, but the most adaptable. This proves true in nature as it does in the software arena. Software, for the most part, becomes isolated on a single client after an invasive installation process. Having the application solely based on a single system leads to many inherent issues with data that is collaborative in nature, such as a staffing report or financial information.

An Atrocious Example

Let us take Excel, for instance, as a static application. It provides an interface and gives you a grid, which many of us can think of as the "data model", and you can do fun stuff like calculate columns. But what happens when you have a team of financial officers making changes to a report and emailing them as a method of collaboration. You get a nightmare of version control; the data integrity is completely lost and merging is simply out of the question. How could we possibly avoid such a scenario with localized data? Synchronizing each client has been a common answer in the past but let's face it, that's just ludicrous in the long run in terms of cost and practicality. There must be a better way!

Accessible Data Storage

There are plenty of formats that can be used to send and receive data over the HTTP protocol. REST, SOAP, raw XML, JSON, YAML, etc. The list goes on, but the point is there are companies like Google, Amazon and many others that are allowing a means for accessing a specific account of information in a distributed and collaborative manner. Such as, in Google's case, calendar information, blog info and, back to the excel example, spreadsheets. With the spreadsheet, you can allow multiple accounts to access that sheet and manipulate it collaboratively, instantly. How is this even possible though, do we have to install Google spreadsheets first? The answer is no, your browser is ready to handle this right now.

A Chameleon Client

The revolution that has occurred underneath our nose is that the browser no longer serves just web "pages" but now web applications. It provides a seamless and interchangeable interface to any accessible data store. By simply navigating to a URL you're ready to engage the application. This idea of a globally accessible, light weight, zero installation application has the software world humming with activity and progress.

Fuel for the Future

This progression is merely the start. Where today everyone has their "island application", I think the true future of software is going to be determined by the interoperability of any application; the ability to indefinitely embed an application within a bigger or just plain different context will be the cornerstone of this next revolution. The result will be a platform to serve multiple applications and provide a manner for data migration/integration/communication across many boundaries, and which will enable individuals to build these applications easily and collaboratively.

Components vs. Widgets (or: Contextual Agnosticism)

When demonstrating our widget platform (WebWidgetry(tm) and MashupStudio(tm)), one of the first things most people ask me is, "what do you guys view as the definition of 'widget'?"

In another post of mine (Widgets are Applications without Boundaries), I offer a couple of very quick and dirty rules to answer that question. Here I will dive (however briefly) into one of those qualifiers while talking about the difference between the term 'component' and the term 'widget'.

Firstly, yes I will admit that in many ways the two terms are interchangeable (especially based on my criteria as outlined in the above referenced post). Both terms describe an encapsulated piece of functionality designed for reuse in various contexts. But I would say that there is enough of a differentiation to warrant the existence of a word such as 'widget', as buzzword-ish as it may be.

To me, the difference is this: a component is authored against a known target execution environment, therefore while the context it is consumed in may change based on the application, the range of possible contexts is limited to only those that apply to that target environment (java, .NET, php, etc...). For example, you have a favorite suite of UI components for X language or Y platform. In order to be consumed across execution environments, the code must be ported over, and in many cases it is not feasible to consume them in XYZ context therefore a hunt is begun for a comparable component that will fit.

A widget, if built upon what I view as a true "widget architecture", is authored either without regard to the potential context within which it may be consumed (i.e. with inherent support for consumption in arbitrary environments via UI rendering that adapts output based on the requesting agent/device and host environment, etc...), or in such a way that it could easily be extended or adapted for consumption in arbitrary contexts. The widget is responsible for pulling in its own required resources within whatever host environment it finds itself in.  This is abstract speak to some degree, in that the actual work of adapting a widget for consumption in a new context may or may not (in practice) end up being "easy". Also, it is still necessary in most cases to load some kind of "runtime" into the host environment first which will be responsible for managing the scores of widgets and orchestrating messages, etc...

But, what if the host environment is, say, the Internet, and the runtime is say, a platform for application development and deployment that exists as a series of connected services on said Internet? Widgets can be authored in many manners. XHTML and javascript can be a default pair of constructs to declare layout semantics and behavior, but widgets can also be authored with other technologies to render the UI and process behavior and interactivity... as long as there is a common way to express the widget's UI and behavioral interface to the runtime. A couple examples of this that I like are the Flex-Ajax bridge and Media Machine's Flux Player X3D-js bridge.

What I'm getting at is that something as micro as a "component" can not survive out in the wide open expanses of the "internets", at least not if surviving requires the component to be easily consumed/used under arbitrary conditions. The more macro "widget" on the other hand... well I guess I'll just leave the comparison here: widget is a wonderful word to describe a component that transcends traditional deployment limitations; one that has evolved beyond a component and can survive out there in the big, wide world's web.

Technorati Tags: widgets web2.0 web3.0 webwidgetry mashupstudio ryangahl nthpenguin

Widgets are Applications without Boundaries

There is a line between what is a widget and what is not a widget. That line, however, is not drawn in the sand - that is, it depends on who you ask. Some people will say that a widget is a little piece of code that you can embed in your website and nothing more (a novelty at best), or that can be virally propagated, or is a read-only view into some combination of interesting data. To me (and my team at Nth Penguin), the line is simply this: a widget is an application without boundaries. Simple, eh? OK, now let me explain what I mean...

First of all, there are some rules to what we view as a widget:

1. A widget is web-aware. That is something that sometimes goes without saying, but it's important. It doesn't mean a widget is limited to living in a website (as is evident by the presence of desktop widget platforms by Google, Yahoo, and Microsoft), but just means a widget must be able to live on the web, be distributed via the web (i.e. easily syndicated), talk to the web, get its data from the web, etc.
2. A widget is functional on its own. It can be delivered standalone with its own URI, or embedded in various contexts (a gadget in the sidebar of someone's blog is only one example) - which brings me to the next rule...
3. A widget can be embedded inside any context, which includes within other widgets. I know I mention this in rule 2 above, but this is really important. A widget can be its own sandboxed application or a pretty box of data, but it can also double as a component within a larger widget, or application - lending its functionality to a bigger (or just different) idea.
4. There is no upper bound to how many levels of embedding can be done, or to how many times a widget can be extended. Widgets are mutable. They are all able to be used as building blocks. This means that widgets must be discoverable and furthermore that their functionality be easily discoverable by both humans and other widgets.

So there you have it, four simple rules which together comprise the line that defines what is a widget and what is not a widget (to us).

Technorati Tags: widgets web2.0 web3.0 webwidgetry mashupstudio ryangahl nthpenguin