Web Content Wizard for Google Calendar

Fueled by my curiosity in learning about AuthSub and my desire to promote web content events, I created a web content wizard for Google Calendar. I believe this will dramatically lower the barrier to entry for creating web content events. To see a screenshot of the wizard in action, check out its Help link, or if you want more information about what prompted me to do this, read the About section.

In the process of creating the wizard, I learned quite a bit about web applications, web security, and the state of free JavaScript datepickers. I plan to write up what I have learned in the weeks to come, but first I need to allocate some of my time online for Christmas shopping!

Honestly, there's a lot more I could post about this wizard today, but I believe everything is already there on the site, and I hate repeating myself, so like we [apparently] say back home in New Jersey: come and see for yourself.

New hacking opportunities with Facebook, Firefox, and Chickenfoot

Facebook just announced its own toolbar for Firefox, but interestingly, no toolbar for Internet Explorer. As they mention in their Developers News page, "[the toolbar is] open source, so if you’re interested in adding functionality (or porting it to another browser), join the discussion thread!" Sounds like we'll have to wait for a solution from "the community," whoever that turns out to be...

Now, although Firefox is gaining marketshare, it still has a long way to go before it can dethrone Internet Explorer, so why wouldn't Facebook focus on building a toolbar for the majority? My first thought is that building a toolbar for Firefox was just easier for the development team. For starters, there is already a plethora of toolbar extensions for Firefox that Facebook developers could have used to model their toolbar after as a starting point. Also, there are no Microsoft Visual Studio licenses to buy when developing for Firefox, and the structure of the browser is easy to learn and explore with free, built-in tools because it's one giant DOM. Or maybe there was just one crazy developer (Ari Steinberg?) who just happened to like hacking on Firefox that started prototyping a toolbar and ran with it. Lots of software projects start that way.

The one thing that I can't imagine is that a Product Manager at Facebook said, "Hey, I think we need to have our own toolbar. And instead of going after 80% of the market, I think we should focus on only 10% because having all those users would be too crazy." Unless, of course, the PM has a shiny new MacBook Pro and didn't want to see his or her developers working on something that he wouldn't be able to use. Either way, I'm excited to see new tools that promote Firefox.

Although I haven't looked at the source code for the toolbar yet, I'm curious how similar it is to the wrapper for the Facebook API that I wrote for the new version of Chickenfoot. My wrapper isn't mentioned in the release notes (though I assure you it is bundled in the extension), but the source code for the Facebook wrapper can be viewed online, and can be used by adding include("facebook.js"); just like any other library in Chickenfoot.

In my initial experimentation with the Facebook API, I was very frustrated that their client libraries did not come with good sample code to demonstrate how to use the library, so I promised myself that I would not make the same mistake with Chickenfoot's Facebook wrapper. As you can see, I have some sample usage at the top of facebook.js, but I plan to put something better together like I did for Chickenfoot's Prototype wrapper. Admittedly, I have yet to build anything with facebook.js, so until I have a sample application, I suppose I shouldn't promote it too heavily.

Nevertheless, you should still check out the new version of Chickenfoot because it now supports keyword commands! Both the keyword commands UIST conference paper and video of the tech talk at Google that showed them publicly for the first time are available on the Chickenfoot publications page. With keyword commands, you can write a script without learning JavaScript. For example, the following is a valid keyword command script in Chickenfoot for doing a Google web search:

go to google.com
type "chickenfoot MIT"
search

At first glance, you might think this is some sort of pseudo-natural-language programming like you see in AppleScript, but composing keyword commands is even easier than traditional scripting because keyword commands are not validated against a grammar. This is an important distinction, and I recommend reading the paper or watching the tech talk for more details.

JSON Inpsector (for GData)

Yesterday, I was very excited to announce JSON support for GData on the Google Data APIs Blog. Even though we provided some nice documentation and samples for this new feature, I thought it would be helpful to be able to browse the structure of the JSON returned by the feed in a standard tree widget.

In Chickenfoot, you can inspect a JavaScript object fairly easily by leveraging the DOM Inspector:

function inspect(obj) {
  // explore obj in Firefox's DOM Inspector
  window.openDialog('chrome://inspector/content/object.xul',
  '_blank', 'chrome,all,dialog=no', obj);
}

Unfortunately, this JavaScript does not work in a web page because it needs access to the browser chrome. Because not everyone has Chickenfoot installed, I decided to make an online JSON Inspector for GData feeds (shown below) where you can simply enter the URL for a GData feed and click Show me the JSON! to explore its structure with a standard XUL tree widget. (Because this web page uses XUL, it only works in Firefox.)

Hopefully this will help you write your first GData mashup over the Thanksgiving holiday! You'd rather hack on JavaScript than fight your way through the mall on Black Friday, right?

Update (11/22/2006): Mihai just pointed me to an existing JSON Inpsector targeted at JSONP (JSON with Padding), which lets you inspect JSON from sources other than GData.




P.S. If any of you decide to host XUL files on your own webserver, make sure to add the following line to httpd.conf or else your XUL trees may appear strangely:

AddType application/vnd.mozilla.xul+xml .xul

Introducing Gvite (a Firefox extension)

Okay, so I'm a little upset that Evite has links to add an event to both Outlook and iCal, but not Google Calendar, so I decided to write a Chickenfoot script to deal with the problem. My script adds the following when visiting an Evite invitation: (1) It replaces the "View Map" link with a link to Google Maps, and (2) it adds a button that lets you add the event to Google Calendar. I used Chickenfoot's packaging tool to package the script as a standalone Firefox extension (click this link to install it).

I have to admit that I really hacked this script together, and my only test cases were the two Evites that are currently in my inbox, so I haven't been very thorough. If you look through the source code for the Chickenfoot script, you'll see that I have some TODOs in the code, so I already know about some of the shortcomings. That being said, please feel free to email me with improvements to the script. (If there's enough interest, we could move this to the Chickenfoot Script Repository so we can leverage the power of Web 2.0 to handle all of the Gvite edge cases!)

Did I mention mitcalendars.com?

No, I don't believe I did, but it yesterday (my birthday, for those of you who forgot), mitcalendars.com appeared on the Google Code Featured Projects blog. I created mitcalendars.com with fellow Googler and MIT alum Mike Lambert a few days after the fall semester started at MIT.

So why didn't you post about this weeks ago?, you wonder. Well, here's what happened: Mike and I were eating lunch at Google, and I was expressing my disappointment that MIT would be an unlikely candidate for Google Apps for Your Domain because it has already invested a lot in its Athena computing system, and people would freak out if they couldn't use Pine or mh or whatever junk people who don't use Gmail use. What I really wanted, of course, was for every MIT professor to enter his or her syllabus in Google Calendar, which would save students the trouble of figuring out recurrence rules and determining which MIT Tuesdays are actually Mondays.

But then Mike raised the key question: "Why don't we create all the calendars for them?" Upon hearing this, I immediately realized that this was one of those ideas that was just so stupidly obvious that we needed to drop everything and just start building it. So we did.

We decided that the interface that would be most familiar to students would be one that paralleled MIT's online course directory. We would simply copy the HTML from the directory, and in the spirit of not being evil, would provide links to make it trivial to add the course schedule to Sunbird or iCal as well as Google Calendar.

As it turned out, Mike and I were already scheduled to fly to MIT that weekend for some on-campus recruiting. In many ways, it was fitting that we didn't sleep at all on the red-eye, discussing our design, and then went straight from Logan to the MIT student center (I got the first LaVerde's breakfast sandwich of the day!), and continued hacking until we had published the site.

Of course, we couldn't contain our excitement, and showed off our work to some MIT students who were passing by. One common reaction, which both excited and disappointed me, was, "Oh man -- I wish you had that a week ago! I already uploaded all of my courses to Google Calendar!" Clearly the early bird catches the worm, and the early bird was not us.

We sent the URL around, and the site got some uptake, but it didn't generate as large a response as we had hoped. There were definitely a number of things we did wrong (I hope no one accidentally goes to class on Thanksgiving because of us, or misses their final exam, for that matter), but now we know how we can do better (and that we should act earlier) next semester. Although we'll be sure to look out for that second-system effect we learned about in 6.033, you can expect a better version of mitcalendars.com for the spring semester, so be sure to check back in February!

GCalQuickTab for your Domain!

I released a new version of GCalQuickTab that works with Google Apps for Your Domain (GAFYD). It may not be that exciting for most of you, but if you use Google Apps, it's a lifesaver!

TargetAlert 0.8.9.8 Released

I received several requests to update TargetAlert so that it is compatible with Firefox 2.0. As 2.0 has been out for awhile now, this is a reasonable request, so I finally made a new version (0.8.9.8) available here on bolinfest.com:

http://www.bolinfest.com/targetalert/download.html

All I did was download TargetAlert.xpi from bolinfest.com, unzip it, changed some version tags, and reposted the thing. That means version 0.8.9.8 does not have the features that the 0.9 preview release has, and that the memory leak is still at large.

I do plan to figure out what's causing the memory leak and release a 0.9 version with support for custom alerts. I don't know when I'll have time to do it, though, because I'm caught up in a handful of other side-projects right now and I'd like to get those out the door. (New code is always more exciting than old code, isn't it?)

My 55 Minutes of Fame

Last week, I gave a Tech Talk at Google with Rob Miller about Chickenfoot. You can read about it on Chickenfeed, the Chickenfoot blog. If you want to get a higher quality copy of the video, check out the new Chickenfoot publications page.

I actually spent weeks preparing for this talk -- not so much for the presentation itself, but we wanted to have a fresh version of Chickenfoot with lots of new features available for people to download after the talk. And we did! Now you can create a Firefox extension in under a minute using Chickenfoot, which I think is pretty cool.

Speaking of Firefox extensions, maybe I can get back to TargetAlert 0.9 now that the talk is behind me...

TargetAlert 0.9 Preview Available

I have made a preview release of TargetAlert 0.9 available that finally lets you create your own alerts through the UI. Everyone has been asking for this feature since day one -- I'm sorry that my other projects prevented me from taking care of this sooner!

If you find any bad bugs in the preview, then please let me know so I can fix them before I make an official 0.9 release. Once I finish writing up the documentation for this new version, I will push everything to bolinfest.com, so this little beta test should not last very long.

I Swear I Fixed It This Time

If you read the comments about GCalQuickTab, then you'll notice that I have a lot of unsatisfied customers, and I admit that they have a right to be upset because GCalQuickTab 0.3 makes it easy to unintentionally open Google Calendar while composing an email. Most users probably think I'm a moron, but I assure you that it's not that simple...

When you type the letter L in Gmail, GCalQuickTab tries to figure out if you are trying to enter text in a box, or if you are trying to activate the GCalQuickTab shortcut for Calendar. Unfortunately, the heuristic that I was using to make this distinction involved checking frame names, but then the names of the frames in Gmail changed, breaking my extension. I just submitted GCalQuickTab 0.3.1 which has a more robust heuristic -- it traverses the DOM and looks for a document in design mode, which would reflect that Gmail's rich content editor is open and that the user is probably trying to type an L in his email, in which case Google Calendar will not be opened.

Unfortunately, there are often a lot of extensions in the queue to be reviewed, so I'm not sure when version 0.3.1 will hit the Mozilla Update site. For example, version 0.3 took a little over a week to be approved, so 0.3.1 may also take some time. I feel bad for those of you who are still using ones instead of Ls in your email, so in the interim, so I am posting GCalQuickTab 0.3.1 on bolinfest.com. The updateURL for the extension still points to Mozilla Update, so even if you download GCalQuickTab from bolinfest.com, you will still get future updates to the extension.

The Long-Awaited GCalQuickTab 0.3

If you still have GCalQuickTab installed (thank you!), then you'll be happy to know that I think I fixed the keyboard shortcut for real in version 0.3, which is pending approval right now. And even if I didn't fix the bug, at least I now provide the option to disable the keyboard shortcuts, or to define your own keyboard shortcuts if you have a problem with the defaults (G for Gmail and L for caLendar). Unfortunately, I was too lazy to build a UI for these preferences, so you'll have to go to about:config and filter by "gcalquicktab" to set the keycodes to your liking (or to -1 to disable them).

Some Screen-Scraped Calendars for Google Calendar

I noticed that there are some concert calendars for concerts in the Bay Area that do not have calendar feeds that you can overlay in Google Calendar. So sad. I decided to do some screen-scraping to create calendars for them.

I wanted to write something that would automatically screen-scrape the concert web sites once an hour. Unfortunately, since I don't know how to run Firefox headless (i.e., a Chickenfoot with its head cut off), I had to use something other than Chickenscratch, which is unfortunate because it turned out that doing it in Python was more tedious (JavaScript has better utilities for working with the DOM, and it's nice to be able to use literal regexps instead of having to "compile" them.)

I struggled for awhile to get mod_python working so I could serve a PSP or something that would generate the .ics on the fly, but that failed, so I decided to schedule a Python script with cron that would generate the .ics once an hour. Since I was no longer in Chickenfoot, I needed something besides Firefox to be a fault-tolerant HTML parser, and fortunately I found xml.dom.ext.reader which worked just fine.

I hit a pretty serious snag, though, when I discovered that my server has Python 2.2 instead of 2.4. I didn't think that it would be a big deal that I didn't have the latest version of Python; however, it turns out that date handling in 2.2 is abysmal. Instead of trying to figure out how to upgrade Python (since trying to install mod_python was so much fun), I found an open-source project that implemented the Python datetime library, so I had to download that and extract the appropriate file. Despite what I read about the backport, the implementation of pythonweb's datetime.py was far from complete (it implements the complete API, but its implementation raises many "not supported" exceptions). Nevertheless, I got things working (there are still some TODOs in the code where things could be improved), so I hope you check out the code and overlay my calendars on your Google Calendar.

Do a Blogsearch Instead

I wrote a simple Chickenfoot script to add a "Blogs" link among the "Images/News/Groups" links on Google Web Search pages to make it easy to Search blogs instead.

New Version of Chickenfoot (Finally!)

We finally got the new version of Chickenfoot out the door: [Release Notes] I'm really excited because we finally released our include() command which lets you import other JavaScript libraries into a namespace. Considering that JavaScript doesn't have native support for namespaces, I think this is a pretty big deal.

Oh, and for you Greasemonkey fans, we basically made it as easy as humanly possible to create Greasemonkey scripts in Chickenfoot. We provide a greasemonkey.js library and the option to create a new script pre-populated with the code: include("greasemonkey.js"). It doesn't get much easier than that.

Embarassing GCalQuickTab bug Fixed!

Thanks to Jon Stritar for approving GCalQuickTab 0.2.1 on short order -- there was a bad bug where typing l in the rich-content editor in Gmail would switch to Calendar instead of inserting the character. No more.

GCalQuickTab 0.2

Today GCalQuickTab 0.2 was approved and posted on Mozilla Update. The big change is the introduction of keyboard shortcuts -- now you can use g to switch from Gmail to Calendar and l to switch from Calendar to Gmail. Also, in response to a user request, GCQT now directs you to the https version of the site instead of the http one.

Introducing GCalQuickTab

I apologize that I haven't contributed to the Changeblog in quite some time, but now that my project finally launched, I should have some more free time. In all the excitement, I even made a new Firefox extension, GCalQuickTab, to take advantage of our new product. It was pretty easy extension to write (but only after prototyping it in Chickenfoot, of course!)

Calling Java from Chickenfoot

Oftentimes, I think it would be ideal if Chickenfoot did not depend on Java -- it would be a smaller download and simpler to install. Recently, we've been trying to break that dependency, but we haven't been successful yet. But then again, is it really so bad? With Java installed, you can call Swing from Chickenfoot.

I once had a 6.170 student who tried to use Jython to prototype Swing GUIs so he could script them and add components on the fly instead of rebuilding the app each time he wanted to add a component -- this is basically the same idea (though calling Java from Chickenfoot is a bit sluggish). This is mainly a proof-of-concept of calling Java from Chickenfoot -- if you really want a Java interpreter, I'd recommend BeanShell or DrJava (the Eclipse plugin, of course).

Chickenfoot Script: Dump current HTML

I wrote a Chickenfoot script that dumps the current HTML of a page to a file. This has been really handy at work, so I thought I should share it. Basically, when you want to work on the HTML of a web page that is dynamically created by JavaScript, it helps to be able to dump the the HTML of the page to a file so you can work with it offline. (I think it makes more sense to edit the HTML in Emacs and refresh the browser than it does to edit the JavaScript and relaunch the entire webapp.)

Other seemingly sensible approaches fall short:

1. Doing a "View Page Source," "Select All," "Copy," and "Paste" into an empty Emacs buffer doesn't cut it because you want the HTML that has been generated rather than the original HTML.


2. Copying the DOM as XML from the DOM Inspector gives you the current state in XML rather than HTML. I think you can get this to work if you add an XHTML doctype to your output, but it hardly seems worth it because then you have to work in XHTML instead of HTML


3. "Save Page As..." doesn't work on all pages, probably because it is trying to pull down all of the stylesheets and images in addition to dumping the HTML, which is something that my script does not do. Because I own the pages that I'm trying to dump with this script, I can copy all of the images and CSS into the folder that contains the HTML file that my script outputs. Since those are static files that do not change often, this works well, in practice, and is likely faster than "Save Page As..." would be if it worked, anyway.
   

My script also lets you scrub the <SCRIPT> tags from the HTML, which is often what you want in cases like this. Those tags often contain JavaScript to generate HTML for the page, but if the HTML has already been generated, then you don't want that JavaScript to run again when you load the dumped HTML in a web browser.

Birthday Module for Google Personalized Homepage

I decided to create a Birthday Module to learn the Google Homepage API. I think that it's a handy widget to have on your home page, but I admit that entering the birthday data is a little difficult because you have to enter all of it in one box. Even though Google-provided modules, such as the Stock Market module, allow you to support a variable number of items through the module's preferences, that capability is not available to modules created with the Homepage API. (Hence, one box with a lot of data delimited by semicolons.)

Also, I have bundled a small Easter Egg with the Birthday Module -- try to be the first to find it and figure out how I hid it!

Progress on TargetAlert 0.9

Last night, I made a considerable amount of progress on TargetAlert 0.9. In my last post, I mentioned that things were going slow because I was getting bogged down with XML serialization; however, I recently abandoned that approach for storing user prefs in favor of using JSON. This allowed me to dramatically reduce the amount of boilerplate serialization code I had to write, so hopefully I'll release TargetAlert 0.9 shortly after Chickenfoot 0.6 is out the door (which is more relevant than you might expect).

TargetAlert 0.8.9.7 Released

I've received quite a bit of email from Firefox 1.5 users asking me to restore the option to have TargetAlert icons appear after a link when a user mouses over it, so I have done so in TargetAlert 0.8.9.7. (In 0.8.9.6, instead of displaying the icon at the end of the link, it would transform the cursor into the TargetAlert icon, which a number of users found annoying.) Ultimately, I would like to provide users with the option of converting the cursor, but simply rolling back the change was the quickest fix. This option is now planned for TargetAlert 0.9.

From the TargetAlert Roadmap, it may appear that everything is planned for version 0.9, as it has been for some time. You may be wondering why there hasn't been much progress. Well, the main reason is that the bulk of the code that needs to be written is not very much fun to write. Serializing XML and error-checking user input just aren't my idea of a good time. (Please remember that I work on TargetAlert for free, as a hobby, and that will continue to be the case until some people start clicking on my PayPal Donate link!)

Besides, I've recently been working on some other things that I find more entertaining.

Google Web Search API in JavaScript

When I got back from India and started hacking on Firefox, I wrote a Python script to generate the JavaScript necessary to access the Google Web Search API as part of Google Dominoes. I never took the time to clean up the JavaScript code and publish it online before, but now that we have Chickenfoot, which makes it much easier to experiment with JavaScript APIs, I decided that it was finally time to make it publicly available. The Python script for converting the WSDL is called wsdl2js, and the JavaScript for the Google Search API is in Google Search.js. Happy hacking.