Microformats in Firefox 3

February 1st, 2007

I'm not sure if everyone has been following the recent Microformat work being done at Mozilla, but it's very cool - and exactly what the Microformat movement needs.

I was able to talk with Michael Kaply the night that he released Operator (Mozilla's, sponsored, Microformat extension). This extension is part of the new Mozilla Labs initiative that was just started (It's an attempt to sponsor and promote excellent-quality extensions, and other tools; a terrific idea).

We discussed Microformats in general - and both complained about the shoddy quality of most Microformat parsers. We agreed that in order for the Microformat initiative to move forward, a couple things had to be done:

1. A standard for parsing Microformats had to be clearly defined.
2. An excellent implementation of that standard needed to be implemented.
3. And an important player needed to adopt the use of that tool.

The reason why I'm so excited, right now, is that this is actually happening. In Firefox 3, it's looking likely that there's going to be native handling of Microformats. This would include a defined API for handling Microformats (most likely on the extension level) on any given web page.

This is a huge step forward for the Microformat movement.

Thankfully, Michael has already started developing the solid Microformat Parser, with Andy Mitchell, that will go into Firefox 3. And since this is part of the overall Firefox 3 Content Handling Requirements, it's a big priority for inclusion.

So, what could this content-handling API mean for you, the Firefox extension developer? It means that you would be able to write quick-and-dirty JavaScript to handle matched Microformats - and it'd be blazingly fast.

For example, here's some pseudo-code (any final result will, most likely, be very very different):

When it becomes this easy to handle Microformats, it almost becomes harder to not support them in your extensions. I suspect that once this feature hits the big time, we'll see a flood of Microformat-supporting extensions. And this is great for extension developers, the Microformat movement, and, most of all, end users everywhere.

This is a great time to be getting into Microformats.

Tags: api, javascript, firefox, microformats, mozilla, operator

7 Comments on 'Microformats in Firefox 3'

Playing With llor.nu

December 16th, 2005

A fun online game that I've been playing, lately, is llor.nu (unroll, backwards). It's written using Ruby on Rails, has lots of nice Javscript/AJAXy things, and is Open Source.

The game, in and of itself, is rather simple - you roll the dice, collect money, pay rent, build buildings, and get more money. Which can be rather tedious - however, being a programmer, I saw an opprotunity to automate a bunch of the tedium and maximize my profits - and according to the discussion boards, I'm not alone. Recently, the game had an overhaul changing much of the dynamics, and much of my code. One of the things on the developer's 'to-do' list is to implement a public API, but until then, I've pulled together a number of commands (e.g. REST-like URL and parameter combos) that can get the job done. So, if you're interested in writing your own bot, it's definitely a good place to start.

Logging In

POST /login
user[login]=USERNAME&user[password]=PASSWORD

This is the essential first step of any bot - logging in to your account. The username and password are the ones that you signed up with originally.

Rolling The Dice

GET /js/take_turn/

The most simple of bots can do nothing but login and then roll the dice to kingdom come - under the current version of the game, it is very likely that you will become quite rich.

Buying A Building

GET /deeds/buy/NUM?levels=LEVELS

The next step, is to generate some form of perpetual income (from other hapless players, rolling their dice) - this can be done by buying an available plot and hoping that it'll be landed on. However, you must first know if you've landed on a plot that can be purchased - the easiest way to do this is to take the output from 'Rolling The Dice' and to check and see if it contains the text "buy and build". Some psuedo code:

login();
while( 1 ) {
  data = GET('http://llor.nu/js/take_turn/');
  if ( data.contains( 'buy and build' ) ) {
     GET('http://llor.nu/deeds/buy/2?levels=1');
  }
}

The next important step is to determine what type of building and how many levels to buy - There are four types of buildings numbered 2 (lowest worth), 3, 4, 5 (highest) - and multiple levels (1 to 30ish). You'll probably want to focus on buying on particular type of building, exclusively - it'll make your code, and management, much simpler.

That should be sufficient to get you started hacking around - just make sure that you don't call their poor server too frequently - leave a couple second delay it, to be nice. (Otherwise there may not be any more game to mess with.) If there's interest, I'll be happy to delve into the following:

• Using ducks, Figuring out when to use a duck
• Using hard hats, Figuring out when to use a hard hat
• Figuring out how much money you have
• Renaming Buildings
• Upgrading Buildings
• and Selling Buildings

At the very least, be sure to check out the game, it's very slick, to say the least (and look for me up on the high score board!).

Update: The 'can I buy' text has been changed to 'buy and build' (to work with today's update).

Tags: programming, api, rails, rubyonrails, games, ruby

13 Comments on 'Playing With llor.nu'

Google Homepage API

December 14th, 2005

Yesterday, I sat down and played around with the new Google Homepage API, which is interesting, in and of itself. I found the development to be most like developing a widget (for Dashboard or Konfabulator).

A couple observations:

• By default, your module is contained within a fixed height IFrame, but it's possible to actually embed your widget straight into the Google Homepage itself.
• My first worry was over the possibility of XSS attacks, but all modules run on a different domain, gmodules.com. (I'm not sure what happens if you embed it in the page, my guess is that they're far more restrictive, if you want your module to run free like that)
• The have a server-side proxy that's on the same domain as the modules - which means that you can do cross-domain XMLHttpRequests - a very smart move (at least from a developers perspective, not sure about security, though).

My first test module is rather simple, it's just the current list of links from del.icio.us popular, auto-updating every hour. To run it for yourself, go to your Google Homepage, click the 'Add Content' link and enter the following URL into the 'Create A Section' textfield:
http://ejohn.org/apps/igdel/
If you're worried about running foreign modules on your homepage, you can feel free to look at the source code - it's completely harmless.

The majority of the code, for the frontend of the module, was borrowed from two places:

• del.icio.us's JSON demo - I like how they load favicons in the background, a nice touch.
• I also borrowed a little bit from the On Demand Javascript article which does dynamic-loading of foreign Javscript.

The final bit, that made this module work, I'll discuss tomorrow - it's a dynamic RSS to JSON convertor, that's incredibly cool. (If you're feeling adventurous, you can look at the module source code and find it hidden in there.)

Tags: javascript, json, programming, api, homepage, google, rss

11 Comments on 'Google Homepage API'

One Week of Google Maps - Part 7

August 19th, 2005

This is the final part of a week long series featuring code for the Google Maps API.

For the last day of this series (don't worry, this isn't the end of me having fun with Google Maps - there's still much more to come!) I decided to implement two things.

The first new feature is a sane version of the afformentioned Mouse Wheel Zooming. This version is completely streamlined, tied straight into the GEvent API, and isn't limited to only zooming.

Moving the mouse wheel code over to the GEvent API was rather simple - what was more complex was attempting to fix a rather serious (in my opinion) usability issue with the mouse wheel zooming. My first intuition, when using the wheel-zooming, was to position my mouse cursor over where I wanted to zoom to then flick the mouse wheel up. However, moving the mouse wheel up causes the map to zoom in into the current map position - completely ignoring the position of the mouse. I've added the code to correctly capture the current lat/long of the cursor and pass it into the GEvent.

However, one issue still arises: Zooming in to the point you had your mouse over re-positions that point to the center of the screen - not where your mouse is. This means that you then have to move your mouse back to the center of the screen to continue zooming in. To fix this, I've written a method that can be used to properly scale the points to where they should be - this will even help the 'click zoom' code that I developed earlier this week. You can see this for yourself in this demo. In that demo I use the following code to capture the mouse wheel movements and zoom in correctly:

The next feature is purely fun: Map in Map Support. Similar, in concept, to having 'Window in Window' on a TV screen, this displays a small, zoomed out, map in the corner of your main map.

Really, a demo would probably best illustrate this concept.

This was a test, for me, to see how easy/hard it would be to 1) Embed HTML on top of a map and 2) Put a Map in that HTML. The answer to both is: Easy and Very Easy. It took a little bit of poking around in the API to try and figure out how to get the HTML onto the map (looking at the code for similar functions, such as GSmallMapControls, helped a lot) - but once that was solved, adding a Map on top was as easy as 'new GMap()'.

eJohn.org RSS Readers

06/01 153 to 08/19 305

Now, a question to my readers (and if my recent analysis is correct, there's over 300 of you): Did you enjoy this week long feature - looking at Google Maps? If you did/didn't what specifically did you like/not care for? Any input would be greatly appreciated! Thanks in advance - I'm looking forward to do this again, very soon!

Tags: maps, javascript, google, programming, api

28 Comments on 'One Week of Google Maps - Part 7'

One Week of Google Maps - Part 6

August 18th, 2005

This is Part 6 of a week long series featuring code for the Google Maps API.

The theme for today is Animation (per the request of Ralph). For programmers who want to make a walkthrough of their town, or a tutorial - play-by-play animation is an important feature to have - and one that is missing from the default API.

I've added the functionality to the API such that you can animate the user's map view based upon:

• An array of points.
• An array of markers.
• An array of markers and points.
• A Polyline.

In addition to this, if you wish to use markers in your animation - and if you've bound a function to the "click" event of the marker - then that click will be triggered, displaying an info window (for example).

Using all of these features together, in tandem, you can create a pretty convincing slideshow. To see a demo of the animation at work, click here.

To interface with this, here is the function that you need to call:

points - is a GPolyline or an Array of GMarkers and/or GPoints.
closeFunction (optional) - this function will be called whenever the animation has been completed.
pointWait - this is the amount of time to wait at a point (or a marker without a 'click' event). The default is 3000 milliseconds.
markerWait - if you've bound a function to the click event of a marker then this is how long you wish to wait (for example, if you want to give a user time to read an Info Window). The default is 6000 milliseconds.

To use the above code, simply include this file in the header of your code - after you've included your Google Map API file - and you should be ready to go! Happy animating!

Tags: maps, javascript, google, programming, api

5 Comments on 'One Week of Google Maps - Part 6'

One Week of Google Maps - Part 5

August 17th, 2005

This is Part 5 of a week long series featuring code for the Google Maps API.

After loading address latitude/longitude information, the next most desired feature for a Google Maps developer is the ability, for the end-user, to link to a particular map that they're viewing. I've taken this concept one step further:

• A link, to the current view of the map, can be provided to the user. Additionally, the link can be automatically updated everytime the user moves the map or zooms in/out.
• The last view that a user was looking at, on your map, is automatically loaded the next time they visit your site.
• A new info window is available which, when revealed, provides the user with a way to link to that specific marker's coordinates.

These features, once combined, add a lot of much-needed usability to the API. Using this code is fairly foolproof too. Below is a chunk of code taken from the demo, demonstrating all the important features of this addition to the API.

To view a demo of these features, please click here.

The Javascript file can be downloaded here

Tags: maps, javascript, google, programming, api

68 Comments on 'One Week of Google Maps - Part 5'

One Week of Google Maps - Part 4

August 15th, 2005

This is Part 4 of a week long series featuring code for the Google Maps API.

An incredibly common function, for most Google Maps applications, is the ability to 'add a new point' to the map. I've seen a lot of implementations where they force you to line up a crosshair to where your point will go - or even worse: Make you enter a latitude/longitude for the point.

In my opinion, the easiest way to add free-form points is to add some sort of 'click to add a point' functionality. For example, using the double-click capturing code that I wrote yesterday, a new point could be added wherever the user double clicks.

The second part of this operation is to collect information from the user, to be added to this particular point. The Google Maps API provides the very nice Info Window funcionality so why not display the data entry form right in one of those?

I've set up a demo to demonstrate the above, here.

From my demo, there arrise a couple points to ponder:

• In my demo, I create a new marker where the user has double-clicked - if a user cancels adding a new point (by exiting out of the info window) then I remove the point that was created - you should be sure to do the same.
• Google Maps are embedded directly in your web page - there are no IFrames - this means that if you write some CSS to render a form that you've written, it will take effect in the Info Windows that you display - this is very handy!
• The handling of CSS floats in the GMap info windows is very poor, to say the least. The best way to work around them is to provide a wrapper, for example:
  
  <div style="width:400px;height:200px;">Your normal Info Window content...</div>
• This brings up another point - if you have an info window that is particularly large, it is trivial to be able to add scrollbars to the content, observe:
  
  <div style="width:400px;height:200px;overflow:auto;"> ... </div>

The more I use the Google Maps API, the more I realize that Google is really giving the developer a lot of power to be able to make these Maps behave in a way that they want - I highly recommend reading through the raw javascript files sometime - they're very informative, and full of new un-documented features.

Tags: google, programming, api, javascript, maps

Comment on 'One Week of Google Maps - Part 4'

One Week of Google Maps - Part 3

August 15th, 2005

This is Part 3 of a week long series featuring code for the Google Maps API.

When I was planning tonight's post I was having all sorts of fun looking at optomizing the addOverlay function. This function, when used again and again with hundreds of points slows things down very quickly. The code, which is all the rage on the Google Maps API mailing list, can be found at the above page (copied below for completeness):

One problem, though - this feature is no longer going to be needed in the new version of the API. Which is a very good thing. So, that killed my original article for tonight. However, a new topic just so happened to fall in my lap: Advanced Mouse Control.

The one hack that I really like, that was posted to the Google Maps API mailing list, was the ability to zoom in using your middle scroll wheel. It feels incredibly natural and is a lot of fun to play with - you can view a demo here.

After doing some more digging around I realized that no one has built any sort of good, natural, support for the following mouse actions: Double Clicking, Right Clicking, and Middle Clicking. So, I went about to do just that. I waded through the API code for a while and finally acheived a result that I like. All of the events can be used with absolutely no extra code, observe:

As you can see, the events behave exactly as a 'click' event would - except no overlay information is passed in the arguments. The only argument passed along is the current lat/long of where the click was made - from which a lot can be done.

One functional change that I made was to disable the 'pan' animation that occurs when you normally double-click. If you attach any listener to "dblclick" then that 'pan' will no longer fire - which is a smart move, in my opinion.

To make the above code work, all you have to do is include this file in your header, just after you include the Google Maps API, like this:

And that's it - you'll be ready to go from there! If you're interested in viewing a very quick demo, using the above code, click here.

Tags: programming, api, javascript, google, maps

7 Comments on 'One Week of Google Maps - Part 3'