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.

Based on coincidental recommendations from both Daryn Nakhuda and Mark Foster on the Seattle Tech Startups mailing list, and Douglas Crockford of JSON fame, I installed the YSlow plugin for Firefox.  This is a Yahoo-developed plugin that runs within the Firebug environment, which I already know and love.

My  immediate need was for something to help debug a couple JSON problems I’ve run into lately.  YSlow includes (a version of) JSLint, which Douglas Crockford politely informed me might help debug my aforementioned JSON code.  Unfortunately, my initial tests were negative: JSLint didn’t barf on my bad test JSON returned via XHR; Firebug threw the same exception as before; Firebug continued to happily deconstruct the improperly-formatted object as if it were OK.  Hmm.  Maybe I’m missing something obvious.  The only JSLint errors I see are, ironically enough, in the JQuery core library and — *zing*! Douglas’ own json.js file.

Even if JSLint is inconclusive, YSlow does appear to have a lot of valuable performance-assessment information, which is why it was mentioned on the STS list.  So for that reason alone I’m going to start using it.  I think the simple grading scheme is a bit restrictive — why use a CDN if you don’t have the traffic to support the costs? — but it’s meant to be a guess and a guide, not a thorough analysis.

This tip will definitely help some of you out.

When creating JSON-formatted data, it seems as if you can omit quoting the keys:

{ name: "Anthony", reading: "The Wisdom Of Crowds" }

…although technically this is not JSON, as the key values are not quoted. However, you’ll see lots of examples floating around that use the non-key-quoting system. And it works in a lot of cases.

However, I ran into this code in Douglas Crockford’s JSON library for Javascript that was failing:

if (/^[\],:{}\s]*$/.test(text.replace(/\\./g, '@').
replace(/"[^"\\\n\r]*"|true|false|null|-?\d+(?:\.\d*)?(?:[eE][+\-]?\d+)?/g, ']').
replace(/(?:^|:|,)(?:\s*\[)+/g, ''))) { /* ... */ }

Ha! Ha! Ha! Figuring out the error in this code is sort of like figuring out what smells in a landfill. But, it was easier than I thought. What was happening was that the string I was sending in to parse to JSON did not have the keys wrapped in double quotes, so the Crockford script failed, thinking it was not a valid JSON string.

Morals:

1. Firebug is your friend.
2. Type safety is your friend.
3. Generic “syntax error” exceptions are not your friend, particularly when you’re chaining four calls together in one line.

Can be found in the book RESTful Web Services, by Leonard Richardson, which I’ve been reading at Safari Bookshelf. It’s short, sweet, and puts JSON into perspective against all the other AJAX/XML technospeak that bubbles through the tubes.

Go to Section 2.5.  If you have a Safari Bookshelf subscription, it’s here.