JQuery IFrame Plugin

This article by Nick Zakas, covering some technical issues in iframe loading, triggered me to surface a JQuery IFrame plugin I made a little while ago, which supports loading IFrames. (I did tweet it at the time, though I’ve since changed the location.)

JQuery IFrame plugin

The plugin basically tells you, the programmer of the parent document, when your child iframe has loaded. It also has some other bells and whistles, like timing the load duration.

It’s inspired by the use cases of WebWait (http://webwait.com) and the Scrumptious trails player (http://scrumptious.tv). Both are applications whose whole mission in life is to open up an external page in an iframe, and do something when it has loaded.

There’s already an IFrame JQuery plugin, but it’s to do with controlling what’s inside the iframe, i.e. the situation which is only possible when the iframes are from the same domain. What I’m dealing with here is the parent knowing when the iframe is loaded, regardless of when it comes from and agnostic to what it does.

Modal Dialog JQuery Plugin

This has been a while coming, but I made a little “yet another modal dialog lightbox JQuery plugin” thing this week.

Demo and Download for Modal Dialog – JQuery Plugin

It was driven by TiddlyDocs, but I’ve been wanting one anyway for a while. Mostly because lightbox libraries generally do some hocus-pocus on page load, like applying to everything marked rel=”lightbox”, but don’t let you dynamically produce the lightbox yourself. That’s fine for pages that are just a static image gallery, but not useful to someone building a dynamic web app.

I’ve subsequently used nyromodal, on good advice, but wanted something smalller and with a simple API for my main use case, which is just showing some text.

The plugin also simplifies work by not requiring you to install a separate CSS file. Doing that, and linking to it, as well as installing any images, is something that always slows me down when I want to start using a graphical client. In keeping with the “happy path” You-Aint-Gonna-Need-It (YAGNI) mantra, I’d rather keep a library to a single Javascript file – be evil and do styling in the library by default, but still support users who want to put custom CSS in a stylesheet.

TiddlyWeb-JQuery Comments Plugin

TiddlyWeb-JQuery Comments Plugin – Screencast @ Vimeo

I’ve extracted from Scrumptious a nested comments plugin you can integrate into any POJA (plain ol’ Javascript app). You can find it here in the repo: TiddlyWeb-JQuery Comments Plugin.

As the README explains, usage is a one-liner once you’ve set it up. Just do $(selector).comments(“topic”). The topic is an identifier for the set of comments; so that when the UI loads, it pulls down all comments with that ID in its “topic” field. Internally, topic acts as the root of the comments tree…but you don’t really need to know that.

This plugin is a JQuery equivalent of the TiddlyWiki comments plugin, minus some of the more exotic options, and the ability to delete. Eventually, I hope to introduce those things, but only as the need arises – so if you’re using this, please let me know how I can improve it.

TiddlyWiki Drawing Plugin based on Project Draw

I’ve been creating a drawing plugin for TiddlyWiki (SVN trunk). It delegates the actual drawing editing to Project Draw (docs; demo), a browser-based drawing editor from Autodesk Labs.

Here’s a screencast:


TiddlyWiki Drawing Plugin based on Project Draw from Michael Mahemoff on Vimeo.

Autodesk Labs’ Project Draw editor looks like this:

… and the tool has a nice set of RESTful services we can make use of:

Project Draw doesn’t have any specialised cross-domain API, e.g. using JSON or OAuth, so normally you would have to proxy any calls via the server. However, a standard TiddlyWiki runs against a file:// URL and can therefore bypass cross-domain restrictions; hence, it was possible to build this plugin using the same kind of XMLHttpRequest calls as Project Draw does for its own RESTful services demo.

One likely use of Project Draw is in conjunction with TiddlyDocs, which will generally run as a standard website – off a http:// URL. Hence, we will need to do some proxying in order to get around cross-domain restrictions.

Also, the tool isn’t fully working in IE yet; I’m working on that.

You create a new drawing with the New Drawing menu item. This is simply a <<newDrawing>> macro and could appear anywhere in the page.

And you can set image dimensions in edit mode:

… which will cause images to be clipped depending on the dimensions:

By default, images are rendered as SVG, using the tricks I discussed earlier for inline SVG. However, this is only supported for non-IE browsers, or IE with Flash-based SVG support. I am still working on IE support. Without SVG, the image will fall back to a bitmap image (fortunately, Project Draw can output an image as SVG or bitmap). However, note that the bitmap image always shows the whole thing; so rather than being clipped, it will re-scale, which could lead to a lot of whitespace being shown in TiddlyWiki. For this reason, in Project Draw, you should set the page dimensions to avoid any whitespace:

More Adventures in Firefox Extension Land: Submitting to Mozilla

I recently explained how I created my first Greasemonkey script as an experiment, then converted it to a standalone Firefox plugin/extension/add-on using an automated tool. Official homepage here. The experiment continues, as I subsequently submitted it to Mozilla, and it’s now been approved as an official plugin.

I’ve been curious about the process people go through to submit an official extension, so here’s the rundown.

1. Upload XPI File

Standard upload of the XPI file, which contains all the plugin contents.

2. Provide Metadata

… such as my name, the extension’s homepage, and so on. (Why isn’t this info just packaged inside the XPI file? Actually, some of it is already in that file anyway.)

One interesting thing here is that I get to choose the category it goes in (although I guess the approver could change it later on). Note also that there’s no help about the categories on this page, so I think there’s a large risk that developers will probably be inconsistent. Not bashing Moz about this, but I do think they could make it easier for end-users to locate plugins if they encouraged consistent labelling – I’ve sometimes trawled through 5 or 6 pages trying to find a plugin within a particular category.

3. Wait for Approval

An official Mozilla person must now look it over, which is a reassuring security measure. (Complain all you want about Ajax and its tabloidistically alleged “security holes”, but the open-source nature of web architecture is extremely compelling from a security perspective.)

After about thirty hours, I received an email that the plugin had been approved. And now it’s available from Mozilla, ID 2816.

If you told me I was cluttering up the space of extensions with this trivial 7KB contribution, I’d say you’re probably right, but then what’s the harm in lots of extensions, as long as it’s easy to locate the one you want. (UserScripts.org, the GM repo, does that to great effect with the power of tagging, and a wiki would make it even more useful.) Not everyone wants to set up GM and maintain the scripts, even those who are savvy enough to know about extensions.

In summary, Greasemonkey and associated tools make it easy, bordering on trivial, for anyone with basic Ajax knowledge to create a standalone Firefox extension. Of course, it will be functionally limited to GM-type page munging, but it’s still a lot easier than I had imagined.

Flock: A Tribute to Unusability of Firefox Extensions?

You’ve probably noticed the buzz around Flock, a browser built on Firefox. Information’s limited, but it seems to pick up on the “social” buzzword – tagging, annotations, RSS etc. Thing is, all of these things are possible in Firefox too via extensions. But extensions haven’t really taken off, and the reason is, quite frankly, poor usability. Firefox is a great browser with a plugin architecture that’s pretty good too. The problem is at the last mile: helping users install and manage their extensions.

Sure, developers will install programming extensions and uber-geeks will set up mouse gestures, but it won’t get beyond that in its current state.

So here’s how a plugin architecture should work:

  • Installing plugins should be dead simple. Pull up a list of plugins and click to install … that’s it! Come on, you own the whole browser and the server too! Make them work together. The current task is something like “visit extensionroom, search for extension, jump into extension page, click Install, Notice security dialog box about this subdomain if you’re lucky, Allow the subdomain, Click Install again if you’re savvy enough to realise what just happened, Watch it download, Click Install, Restart the browser if you’re still interested”. If the version’s incompatible, you’ll only find out at the end of all that (except the restart). True, the version number’s shown when you install it, but that’s really making the user do something the computer should do immediately. Also, most users don’t remember what version they’re running, and I’ve even seen extensions with the version labeled as “Deer Park”.
  • The standard distribution should have a set of extensions pre-installed. Just because you’re using a plugin architecture doesn’t mean you have to ship with a bare-bones distribution. I know there are potentially licensing issues, but shipping with plugins seems to work OK for Eclipse and similarly for the Linux distributions. Satisfy the slashdot crowd with a minimal distribution too, by all means, but mainstream users would rather not spend three hours working out how to install extensions, finding out which are popular/useful, discovering incompatibilities between different extensions, etc. There are plenty of extensions that enhance basic functionality – e.g. All-In-One Sidebar, Adblock, the improved search bars, the improved RSS aggregators – why not take advantage of them? In addition, there’s great scope for specialised distributions, e.g. Developer, Socialite. I know anyone could probably make them and distribute them, my main point here is that Firefox itself should at least distribute a more powerful default distro.
  • Don’t rely on third-party extensions for fundamental functionality. Tabbed browsing works OK in the basic distribution, but the Tabbrowser extension gives it much more power – certainly it brings it up to Opera standard. Yet, it’s been unsupported for over a year, confusing, and buggy at times. Something like this is too important to leave to a third-party. Develop it as an extension if it’s architecturally convenient to do so, but make it mandatory, so that other extensions play nice with it.
  • Provide update notifications. Indicate when updates are present and offer to do the update automatically.

Greasemonkey took off so quickly because it’s so easy to develop, modify, and install GM scripts. Hopefully, the lessons of Greasemonkey and the imminent release of Flock will offer some lessons, and help make Firefox an even greater browser.