Archive for the ‘Screencasts’ Category

February 9th, 2009 4 Comments »
Tags: , , ,

Category: News, Screencasts

iGoogle-like drag-and-drop for Shindig (ala Dojo)

My consulting firm has been spending a good bit of time augmenting and providing developer advice for a really interesting startup based out of Berkeley, CA called Life360; in case Life360 sounds familiar, it might be because they were one of the first place teams in Google’s Android Developer Challenge a while back. In short, the crew out in Berkeley is developing an incredible developer platform for “taking care of your family’s what-ifs”, and it’s been a lot of fun getting to be in on all of the discussions and working with the amazing talent on board there to see it happening.

One of the most recent tasks we’ve been working on is an iGoogle-like drag-and-drop container for gadgets. There’s a really nice project out there called Shindig that implements the gadget specification, but there’s little to be had in the way of a nice sophisticated container that gives you drag-and-drop operations, a custom title bar, and a maximized view. Well, after getting chunks of the new application platform wrapped up for some investment pitches in the coming weeks, we decided that it would be really cool to give some of this code back to the OSS community since we’ve benefited so much from Shindig, the LAMP stack, and a number of useful utilities here and there.

90 sec (6.4MB) QuickTime file of dnd in action across multiple browsers

4 min (13.5MB) QuickTime file of installing Shindig and using the container extensions

You can read the blog post on Life360.com for the details as well as watch some screencasts that walks you through downloading Shindig and putting the files to use, but I did want to take just a moment to make brief mention of a couple of the technical considerations that immediately come to mind:

  • When doing anything like this, you need infrastructure. For this part of the project, Dojo streamlined tons of things like setting up event handlers, styling nodes, getting coordinates on the screen, abstracting a lightweight fabric for drag-and-drop operations, and so forth. Currently, the code uses AOL’s CDN to keep things nice and simple, but you’d definitely want to use the build tools to consolidate and minify the code when it’s game time.
  • When an IFRAME is inserted into the DOM, it (re)loads. So, when you’re dragging an IFRAME all over the screen, its location in the DOM doesn’t change and it doesn’t continually reload because it’s just being positioned absolutely. It’s when the drag event ends that you’re faced with the reload event because you want to move it into its new column (versus trying to maintain the geometry of never manipulating the DOM tree and keeping track of everything in a snap-to-grid fashion.) Anyhow, that’s the approach we took. The one reload event that takes place when the gadget being drug reaches its final destination seemed more reasonable than all of that geometry. Other than the frame getting drug around, no other IFRAMES ever get removed and reinserted, so they never have to reload.
  • For security reasons, Shindig renders gadgets inside of their own individual IFRAMEs versus rendering gadgets in an element like a DIV. That may not sound like a big deal, but it does bring up a few more implementation details worth noting. The first one that comes to mind is that when you’re dragging a DIV that contains an IFRAME, it’s not uncommon for the mouse to occasionally slide ever so slightly into the IFRAME. Unfortunately, the IFRAME then captures mouse events, and then drag-and-drop starts to get choppy and wig out a bit. You can work around this by creating a transparent overlay and placing it on top of the IFRAME during drag events so that the IFRAME can never capture those mouse events. Overlays also come in handy when you popup menus on the titlebar and want them to disappear when the user clicks anywhere else on the screen (including in other IFRAMEs.) One day, hopefully, Caja will kill those IFRAMEs, which will also probably help performance a bit (especially on IE.)
  • There are a few peculiarities that arise when you remove the last element from a container like a DIV, so one way you can deal with this is to ensure it always has a minimum height and width by placing an element in there that spans the width of the column and has a minimal height so that it can accept drag events.
  • As always, there are always a few special cases, so you have to do a little extra bookkeeping here and there. Hopefully the code is commented well enough that it’s not hard to follow. All in all, it’s only about 150 lines for the drag and drop mechanics, including whitespace.

Life360 would love to have you go take a look at their site and rate some of their ideas, so why not head on over there, browse around, and leave some feedback on what they’re doing. Helping startups that have good intentions is the cool thing to do, right?

January 28th, 2009 9 Comments »
Tags: , ,

Category: Screencasts

Becoming More Productive With Dojo and Vim Screencast

Update: I’ve uploaded an mpeg-4 (~63MB) video of the screencast that you can access here if for some reason QuickTime’s H.264 format isn’t an option for you. I’m still a bit new at encoding video, so I’ll try to get the filesize down for next time.

I’ve been doing some reflecting this week on how I can work smarter (instead of harder), and one of the things I came up with was adding a few more tools to my Vim repertoire. I spend more than half of my engineering time in Vim (the other half usually being in a web browser), so I figured that a few minutes here and there would eventually add up in a big way.

In hopes of inspiring you to do the same, I put together a short screencast (~4mins; 14.5MB QuickTime file) that talks you through how to generate a custom tags file for Dojo’s API and the keystrokes to put it to work. Although I’m specifically using Dojo, I think this technique should probably apply to a lot of other toolkits as well assuming that they define API call in a consistent manner that can be approximated by a regex.

But like anything else with Vim, there are always multiple ways of accomplishing the very same thing, so I make no guarantees that there aren’t simpler ways of getting this done — but I can say that this way gets the job done, and is pretty easy to get working on your own system.

By the way, here are links to the generateTags.sh script and the tags file (for Core) mentioned in the screencast. I’ve slightly tweaked the tags file to remove duplicate tag names and a few things that weren’t really parts of the public API (regexes are obviously imperfect heuristics). I can’t say that the tags file may not be missing a few API calls, but tags are easy enough to add in manually if you do notice any omissions.

As time allows, I’ll try to get the Dijit API and DojoX API churned out and post back here with a consolidated tags file for the entire toolkit — that is, unless someone beats me to it, in which case I’d be happy to host or link back to the tags file you come up with if you send it over.

September 15th, 2008 8 Comments »
Tags: , ,

Category: Screencasts

A Simple, Degradable Reflection Widget

A nice, shiny apple

Dojo makes creating a reflection of a nice, shiny apple like this one quite easy!

This post is the first of many screencasts for this site, so please bear with me as I get more skilled at producing video, developing my big boy voice, and those sorts of things. I’ve chosen QuickTime’s H.264 format as my default for screencasts, but if there are other (or better formats), I can always re-encode or provide alternatives. Just let me know!

Viewer discretion is advised.

Reflection has been in vogue for a while now in user interfaces, and it wasn’t long ago that I saw a headline about a JavaScript library that streamlined a number of useful effects such as reflection — but alas, without the benefit of Dojo. Well, being the Dojo fanboy that I am, I immediately started to ponder how to accomplish some of these same effects using the dojox.gfx module, and a couple of hours later, I had prototyped a nice, degradable widget that seemed to do the job. By the way, that’s one of the things I love so much about Dojo: once you have a reasonable grip on it, you seldom, if ever, have to look somewhere else. More times than not, a great deal of your work is already done for you, and you just have to connect some of the dots. Remember: it’s all about the frameworks

But there’s always a catch: in this case it’s that IE users must have Silverlight installed for the widget to work; otherwise, it degrades back to the plain image. The reason is that VML, IE’s default gfx renderer, doesn’t support transparency in gradients. No transparent gradient, no nice fade out effect. Likewise, if JavaScript is not available (honestly, who does that?), it degrades down to the bare image. If you didn’t already know, the gfx module exposes an API that works across browsers by using whatever drawing engine is available. At the moment, renderers are available for canvas, VML, SVG, and Silverlight. That pretty much covers it. Adding support for another one should be straightforward: follow the API guidlines and write it.

Watch the Screencast

I’ll briefly step through some of the interesting slivers of the widget in the next section for those readers who want to skim a written synopsis and put it to work right away, but those of you who have a the time and inclination to have me talk you through it should watch the screencast (~26M, mov file.) I don’t particularly cover basic aspects of the widget lifecycle or anything like that in this post, so if you’re interested in some screencasts on those kinds of basics, please leave a comment and let me know.

Skim the Synopsis

So you’re still reading…alright, once you download the example code, you should be able to unzip the archive, open up the html file, and everything should just work. Well, unless of course you’re using Internet Explorer and don’t have Silverlight installed. Unfortunately, it doesn’t appear that VML supports transparency in gradients (the very mechanism which gets us the faded out reflective effect), so there’s not a lot that we can do there. But the good news is that it’s degradable, so the image will appear as usual on IE.

The markup required to put it to work is simply something to this effect:

<img id="apple" dojoType="dtdg.ImageReflector" src="apple.png" />

And just like any other Dojo widget, you could opt to create it programmatically with something to this effect:

var niceShinyApple = new dtdg.ImageReflector({/* props could go here */}, "apple");

If you take a look under the hood, you’ll see that it’s surprisingly simple to pull this off. First, you create a surface to draw on that is some fraction of the image’s height and place this surface just below the image itself. Then, just draw a reflection of the (clipped) image on the surface using the standard 2D matrix transform for reflection and apply a linear gradient that becomes more transparent as it approaches the bottom. That’s really it. The rest is just a little bit of software engineering.

But do note that this would be a lot harder if the dojox.gfx API (yes, it says that it’s version 0.9, but it’s up to date as far as I can tell) wasn’t so fricken’ awesome. Serious kudos to Eugene Lazutkin and all of the committers who have worked so hard on making it this good. Having full-blown 2D matrix operations at your fingertips in such an accessible way for arbitrary backends is so powerful.

Download the Goods

Just in case you weren’t paying attention, you can use the links in this very sentence to download the example code and download a copy of the screencast (to watch in the privacy of your own home.)

Leave Feedback

Again, this is my first screencast, so if there are things that you particularly liked or things that I can do to make the next one a lot better, please leave a comment and let me know!