I’m going to start looking closely at widget technology.  Not widget as in “doodad: something unspecified whose name is either forgotten or not known”, but widget as in “a live update on a website, webpage, or desktop.”  I have been thinking for some time about using widgets as part of a distribution strategy for Crowdify, and a recent phone call convinced me to jump on the ball and get the tech done.

So, what’s a widget, really?  It’s something that:

a) publishers (using that term VERY broadly) can get;

b) runs on a webpage;

c) dynamically pulls content at render-time from a source location;

d) (optionally) uses JavaScript to do snazzy UI effects;

e) (optionally) allows website visitors to interact with them

The user views the widget contents, interacts with the widget by clicking or what-have-you, and hopefully does whatever the widget provider wanted them to do in the first place.  For Crowdify, that will mean clicking on terms and submitting them.

You can think of banner ads as a widget, using definitions (a) through (c), above.  I’m more interested in examples of fully-interactive widgets, since that’s what I’ll need for Crowdify.

So what sorts of architectures can one use for widgets?  (I’m talking the display of the widget on the publisher’s site, not the getting of the widget code in the first place).

• Well, <IFRAME>s are deprecated all to hell, and for good reason.  Next.
• I see a lot of <script> tags that pull HTML content back from a dynamic source, i.e. PHP or ASPX code.  This is the “server proxy” approach.
• I also see lots of widgets that use a <script> tag that pulls from a remote .js script.  Similar deal as the above, but makes heavier use of JavaScript to render results.  This is the “script tag” approach.
• You can make Flash widgets that load from a remote host.
• I’m sure, without checking, that I could do a Silverlight widget.
• What is this JSONP business?  It’s a way to do Ajax calls without getting drilled by XSS restrictions.  I’m not sure what advantages this has over the server proxy approach, other than the “cool factor”.  Maybe performance?  Agility/more flexibility for API callers?  I need to look into this a bit more.

Enough for now.  More widget research later.