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.

Following up on yesterday’s post about widgets which wondered why anyone would try to build a business on a pure-play widget strategy, comes this interesting little nugget from VC Fred Wilson:

I have to be careful because I am in possession of confidential data from our portfolio companies. But I can assure you that these companies are making a lot of money on these apps

Do tell! Could they be using Fred’s favorite web business model to make money? Or maybe they’re using one of the other models on this list that Fred posted.

I don’t think these guys are using the “free+premium” strategy. Slide and Rock You appear to be advertising-only. Can you find any premium services to pay for?

Zynga is a bit more interesting. There’s this tidbit from Valleywag a few days ago:

[Mark Pincus] claims he hasn’t touched his $10 million in VC funding because he’s in the lucrative business of selling application referrals within Zynga’s Facebook games — a pyramid scheme if there ever was one.

We know web advertising can work. So maybe that’s the secret sauce behind these Facebook widget companies. But throwing eyeball-acquisition dollars around? That doesn’t make much sense to me.

Tell me where I’m making the mistake.

Blogged with Flock

Tags: FredWilson, Zynga, Slide, Rock You, Facebook, Widgets

From Mapping the Web:

Up until recently, it seemed like everyone and their dog was launching a widget-based start-up or a web 2.0 company that served up widgets. The hope was that these widgets would spur viral distribution, creating widespread exposure. In many cases, this did occur. But now what? Where is the monetization? How can revenue be generated via these eyeballs? Most held on to the hope that eyeballs would attract potential acquisitors. In other words, their revenue model was an exit strategy in disguise – the infamous “web 2.0 revenue model”.

My friend Nathan at nPost just released a new job widget into the wild.  It’s not a pure widget play, but an enabler of nPost’s main business model.  It seems like a great way to market and distribute his service.   Frankly, that’s the only way I’ve ever thought widgets (should) work; pure-play widget makers are an ephemera that are interesting only to the people who wear the web 2.0 undies.  If you can’t monetize your traffic, you’re going out of business.  Whether you shut the doors yourself, or let some sucker investor do the shutting for you, business without profit is, well….OK, I’ll give you General Motors, but the general rule is you need profit to stay in business.

Let’s keep widgets where they belong — as a distribution method, not as a business unto themselves.

You really should check out Sprout Builder at sproutbuilder.com. It allows you to build widgets for a variety of platforms (including plain-old web pages) using Adobe’s Flex platform.

Check out this one I threw together for Startup Weekend Portland in about five minutes: (requires Facebook account):

http://apps.facebook.com/wildfire/fbhandler.ashx?mode=side_nav

Some more data integration (such as the ability to call web services, based on user input or a timer) would make this product unstoppable.

(h/t Krishnan, via Marina Martin)

Blogged with Flock

Tags: Sproutbuilder, Sprout Builder, Widgets