As you may know if you follow me on Twitter, a couple of weeks ago I started to investigate ways of producing graphs within a webpage. The driver for this was for a dashboard application to track progress against targets and was one of those “JFDI” projects at work that we all get sprung upon us from time to time.  The key requirement was for slick looking graphs  above all else.  For speed of development I decided I wanted a client-side solution so that quickly focussed my investigation around 3 approaches:

1. Images generated off-platform (Google Charts)
2. Flash (Fusion Charts)
3. Javascript (JQuery + Flot)

For my project we focussed on Option 2 and 3 and eventually setttled on the Javascript route. I’ve summarised below the factors that influenced our decision.

Images (Google Charts)

http://code.google.com/apis/chart

I’ve been looking for an excuse to use Google Charts for some time as it’s a very simple API for embedding an image in a webpage yet produces really good looking charts (far better than I’ve seen in equivalent comercial applications). To use GoogleCharts you simply generate a url like the one below, and use it as the src attribute in an image tag.

http://chart.apis.google.com/chart?cht=lc&chs=200x100&chd=s:ithankYouGodformostthisamazingdayforthel&chxt=x,y&chxl=0:|Apr|May|June|1:||50+Kb

Google Charts supports an extensive range of chart types beyond the regular bar, line & pie and the images can be annotated with custom text for the legend, axes and data series. Like all Google’s API services, Charts is free to use, and although there’s no hard rate limit Google do reserve the right to block any traffic that they detect as “abusive” beyond 250,000 hits per day (not an issue for my application but worth bearing in mind).

Flash (Fusion Charts)

http://www.fusioncharts.com/

For the type of slick interactive graphs that were needed for this project, flash was in many ways the obvious choice. Personally I’m not a big fan of flash, partly because I have zero flash skills but also because downloading flash files often bloats the page unecessarily and is littered with fancy effects that apart from being annoying are usually not accessible. However, after taking a look at the Fusion Charts gallery I had to give it serious cosideration becuase it ha’s support for a huge range of chart types (many of which I hadn’t even seen before I don’t really know what they represent!). There can be no denying that the charts themselves are really nice to look at and the tutorials show how easy it is to get set up and running.

Click the image to view working demo

It wasn’t until I created a quick prototype using some static data (click the image above) that I started to have a few doubts: When you embed a FusionCharts flash object on your webpage, you pass it a url where the source data will be retrieved from. This data must be in the FusionCharts prescribed XML format which is fine if you’re creating your own data sources, but not if you want to consume an existing csv/xml/json feed. There’s no Javascript API to the flash object so you can’t parse data within your page and then pass it to the flash to render. Also, if you wanted to allow the user to zoom in and out of the chart, or toggle series on and off, your chart would need to fetch a new dynamically generated data feed each time. This adds load on  the server, but also degrades performance because of the round-trip delay in requesting new data which seems unecessary when all the data is already held within the page and just needs to be filtered. I also discovered that although the flash file is only 60KB in size, that’s only for one chart type, if you want to switch to bar or pie you have to load another flash file each time.  For these reasons and also because FusionCharts is proprietary software that we can’t edit/enhance and comes with a (albeit very reasonable) licence fee we decided to rule out this option.

Click the image to view working demo

Flot is by no means perfect: it’s only at version 0.6 (and hasn’t been updated in around 12months)  and although the features are impressive, there are a few short falls.  It really only supports line and bar charts (there’s a patch discussed on the flot issue tracker that adds support for pie charts). Also, to get certain features to work (e.g. tooltips and zooming) you need to write you own implementation using the events generated by flot – there’s no chart.enableZooming() here! Having said that, these are only minor criticisms about features that aren’t even available at all in the alternative solutions.

Also worthy of a mention:

Sparklines

http://www.omnipotent.net/jquery.sparkline/

Toward the end of my search I found Sparklines (via @stevereynolds). It’s a nifty little jquery plugin for producing tiny little charts – similar to the “summary” charts on the Google Analytics dashboard page. I haven’t actually used it (yet) but it looks useful for times when you want several small graphs on a single page to give an indication of trends and to entice users to dig deeper for more in-depth analysis.

It’s taken me a while I’ll admit but I’ve just got around to releasing the sourcecode for the XBMChumby widget I wrote which displays the XBMC “Now Playing” queue on the Chumby. I decided early on that my very basic skills as a flash/ActionScript developer weren’t up to developing this to it’s full potential so now if anyone is interested in taking it further please checkout the code and get in touch if you have any problems building it etc etc etc.

The sourceforge project page is: https://sourceforge.net/projects/xbmchumby/

…or you can point your CVS client at xbmchumby.cvs.sourceforge.net

Intro
I’ve created a Chumby widget to act as a basic remote display for XBMC. I’ve been using it and reworking it over the last couple of weeks and I think it’s now in a state where I can make it available for others to try. It works by retreiving an RSS feed from the Xbox that contains a list of the next 5 tracks in the music playlist. If no music is playing, the RSS feed will be empty. To achieve this I’ve written a simple web page that sits on the Xbox and uses the XBMC API to retreive information about the current playlist. The widget also uses XBMC’s http API to provide basic controls to play, pause and skip tracks. This is my first attempt at using ActionScript so the functionality is fairly basic, but if others find it useful I may add more features, or release the sourcecode.

Installation
To get the widget running, download this zip file and copy the contents to the “web” folder on your xbox (usually /e:/apps/xbmc/web). The zip contains the web page to generate the RSS and a crossdomain.xml file to make the RSS accessible from the Chumby. You may need to edit the playlist.asp file to configure the IP address of your xbox which defaults to 10.0.0.5 – you can find this from the Settings > Network Settings screen in XBMC. Also, from the settings screen in XBMC make sure that the web server is enabled and doesn’t require a password.

Next, just log in to your profile on chumby.com and add the XBMChumby widget (in the “Entertainmnet” category). The configuration widget will prompt for the IP address of your Xbox. Then just start playing some music on the Xbox and when the widget loads on the Chumby it will retrieve the RSS feed from the Xbox and show you the next 5 tracks in the playlist (along with album art for the first track). At the moment the widget only retrieves the RSS feed when it first loads so make sure that it isn’t the only widget in your channel otherwise it will never refresh.

I’ve been monitoring the Chumby project since I first saw the device on an episode of Diggnation over a year ago… Kevin had been given one of the alpha prototypes at FooCamp and gave a quick description. I’ve been waiting since then for the device to get a public release – I guess that shows the power of product placement even though I’m sure no cash had changed hands for it to appear on the show. People who know me or have read my thoughts on this before will know that I think there’s a lot of potential for an “ambient” device that provides up-to-date information from the online world without the user having to be sat in front of a PC. I was disappointed with the Nabaztag because of limitations with the user interface, but eager to get my hands on a Chumby as it seemed far more advanced. The Chumby was originally pitched as a new take on clock-radio for the internet enabled 21st century but I think that description groslly undersells it (and at $179, it’s an epensive way to wake up in the morning).

Put simply, the Chumby is an always on device with a 3.5″ touchscreen and a wifi connection to get online and is manufactured by Chumby Industries. It runs Linux (but without the user having to know anything about Linux), has (stereo) speakers, 2 USB ports for future expansion (or for connection to additional storage or an iPod) and built-in acelerometer that can be used by Chumby software as an input device. It’s all packaged in a padded leather housing so is squishy to hold. In fact the housing contains a “squeeze sensor” as an additional input. The great thing about the whole Chumby project though is that it’s OpenSource – that’s both software and hardware. If you’re really keen you can download the parts list and schematics and build your own Chumby from scratch!

The Chumby runs flash-lite widgets (aka gadgets, aka portlets in old money). Users log in to their account on the Chumby website, select & configure widgets from the catalogue and the device connects to Chumby.com to download it’s configuration and the actual widget swf files. Widgets can be grouped into “channels” so that the user can easily switch between widgets, and in operation the device cycles through all the widgets in the current channel (I currently have News, Games, Photos and Test channels). There’s also a “VirtualChumby” on the website so you can get a feel for the widgets before downloading to the device. The only software that’s included in the firmware is the Control Panel used to set alarms, switch channels, etc everything else is downloaded each time the device is switched on so without an internet connection it’s pretty dumb.

The device hasn’t been launched outside the US as yet (it has FCC aproval for the US but needs the equivalent for other territories) so I got mine from eBay. First impressions were very good – it comes packaged in a branded canvas bag rather than the usual moulded plastic/polystyrene and upon turning it on for the first time plays an animated flash movie with voiceover by the development team that explains exactly how to get it connected to your wifi and activated on the Chumby site. I know this experience has been rehearsed and revised through an invitation only trial launch that’s been running for a couple of months. You definitely get the feeling that this is a small dedicated company run by people who are passionate about the device rather than a big faceless corporation. I’m not normally one to read instruction manuals anyway, but the Chumby really doesn’t need one anyway – the setup was super simple and worked flawlessly.

There’s a wide range of widgets from the basic clock (I was happy to find that the obligatory binary clock widget is present) and RSS news reader to streaming audio widgets, to personalised widgets that display the latest status updates/notifications on your facebook account and the number of bids/current price of any eBay auctions you’re watching. Although Chumby Industries do provide some widgets themselves, the majority are contributed by the community so they cover a very broad spectrum from useful, to fun, to perculiar (hypnotoad?). Because the widgets are flash based they generally look very slick – probably better than could be achieved with html/javascript widgets but for me as a developer, being flash-only is a barrier to entry. I don’t know how to write flash and I don’t want to invest hundreds of pounds in Adobe Flash tools so that I can learn. There are open source compilers available that will take ActionScript source code and convert to a Flash swf and I’m playing around with those at the moment (more on that soon, in a future post). The Flash sandbox also comes with its own cross-domain policy that prevents a Flash movie on one domain from retrieving content from another domain unless the content provider hosts a crossdomain.xml file to explicitly allow it. Potentially this is harder to circumvent than the JavaScript XmlHttpRequest cross-domain policy which could be a pain for developers but is better for end users concerned about security of their data.

Chumby Industries have stated that their policy will be to roll out all software updates and new features as automatic downloads for free so that the device “will be even better next year than it is now”. This is a highly commendable policy and I applaud them for it, though it does make me wonder how they ever plan to turn a sustainable profit. The software and hardware are opensource, but the company exists to make money. They don’t charge for software updates and there’s no subscription for using the service or widgets. In theory Chumby Industries could release “premium” widgets for which they could charge but I’m sure the community would quickly develop free alternatives. Chumby Industries could inject adverts into the channels for playback between the widgets but I suspect there would be a big backlash to that approach if they introduced it now because it wasn’t part of user expectations at the start. I’m not sure how else they can monetize the Chumby except for a small overhead they might make on each device sold.

If there has been any compromise with the device it’s that its forever tethered to mains power. It has a small 9V battery just to preserve its settings but cannot operate without mains electricity. So far I’ve found that I want to move the device around: in the kitchen to catch up on news and friend statuses while cooking in the evening, in the spare room next to the computer while working, in the living room on the coffee table when listening to music etc. If it could run from an internal battery, even if only for 30-60 minutes, it would be a lot more convenient. After about 2 weeks of use, I’m still very impressed with what the folks at Chumby Industries have managed to achieve: the novely hasn’t worn off yet, I’m still using it every day and it attacts a lot of interest from everyone who sees it (though I think most dismiss is as just another of my geek toys!). Only time will tell whether the Chumby and devices like it have mass market appeal but this is the best attempt at this category of device that I’ve seen so far, and I hope it catches on.

So I’ve been messing around with various different widget frameworks on and off over the last few months as preparation for a workshop I’m going to be involved with. I started out with Yahoo Widgets (née Konfabulator) mainly because the examples that I’d seen looked the prettiest. Although perhaps not strictly widgets, I’ve also started to look at facebook applications, but that’s a subject for another day. My favoured widget framework at the moment is Google Gadgets for a number of reasons:

• The barrier to entry is low because it’s pretty much standard javascript and html with an xml descriptor.
• You write a gadget once and can view it in iGoogle, GoogleDesktop, Blogger or in an iframe embedded in any webpage.
• As with all Google APIs the documentation is great and there’s a lot of developer support.
• It plays nicely with other Google APIs.
• …finally, if you’re going to back one widget framework, who would bet against Google?

I find the best way to learn is just to get stuck in so I created a couple of simple examples, one to display a user’s timeline from twitter and another to display recent announcements made on another site I wrote, Tell’M. They both follow very similar principles: pull down an rss feed, parse it for interesting fields and render the display. Both also have a few user preferences that can be set to customise the feed.

My interest had moved on to other things recently but this week I started to look at gadgets again because the workshop is coming up soon. I found my two gadgets in the google directory and was disheartened to see that my twitter gadget had received two negative comments – one because of a security restriction of ajax (cross-domain policy) and twitter (which will only accept a POST to update status so I can’t use script injection). After a bit more digging around I found that Google now display average weekly page views for gadgets and my twitter gadget is receiving 14,546 page views per week! I guess it’s easy for a developer to do something just to satisfy their own curiosity and think that nobody else will ever use it. I’ve now added Google Analytics to both my gadgets just to check that all those page view are not generated by me!