You can read about how the map works on the How It Works page. To summarize, pink areas of the map are areas that have short walking distances to high quality playgrounds. Gray areas are those that are either far from playgrounds, or whose nearby playgrounds have a low quality rating (as determined by pollution from nearby truck routes).

The heat map was generated in Java using the Eclipse IDE with the Processing library. The playground list was taken from the NYC Datamine. The latitude and longitude coordinates of the playgrounds (as well as basic information like borough) were scraped from the NYC Parks Department website. I’ve made available a Playground CSV file which lists the playground’s name, geolocation and other supplementary data not available in the original Datamine version. I hope this will save some effort for others looking to generate similar visualizations. The borough outlines of NYC are also taken from the NYC Datamine. The truck routes were taken from the NYC DOT website. All of this data was processed in Java and rendered out as a series custom tiles at different resolutions for use in Google Maps.

The site experience is built entirely in HTML/Javascript. The custom generated tiles are loaded into a Google Maps instance using the v3 version of the API. Unfortunately, this was the first time I’ve worked with Google Maps and I wasn’t aware until late in the project that the v3 API has yet to implement many of the features which are commonly used in v2. One of the missing features for the Google Maps Javascript API v3 is the ability to layer custom tilesets over the existing map. As this is the core visual representation of PlayaroundNYC, it was a huge problem to not have this. Luckily, I was able to find tileoverlay.js by Chad Killingsworth, which solved this problem for me.

This project was developed during the month of November in the wee hours of the night (after my kids went to sleep) and during a couple of days I expressly took off from work to finish this project. I had a lot of fun doing it and learned a lot about Google Maps and custom tilesets that I hope to take advantage of in the future.

Personal projects can be hard to finish as the temptation to continually improve a project can become an irresistable Siren’s song, ultimately dooming the project by exhausting it’s creator long before it’s finished. By having a contest deadline, I was forced to scale the project to what I could do in the timeline. There were additional data sets and visual improvements I wanted to add, but ultimately I’m happy having something small that’s finished than something that’s large and incomplete.

Part of the contest involves a “User Choice” award based on public voting. Please vote for my entry on the BigApps website.

Screenshots

Below are screenshots of the site as it launched in early December 2009.

Evolving Prototype

I’ve included various screenshots that were captured during the prototyping process.

Figure 1. Evenly spaced grid in blue with playgrounds in red.

Figure 2. Evenly spaced grid in blue with truck routes in red.

Figure 3. Evenly spaced grid in blue. Playgrounds in red. Grid points are connected to nearest playground by green line.

Figure 4. Map containing all playgrounds and truck routes.

Figure 5. This was the first look at a calculated “quality” measure. Up until this point, I did not know if this idea would actually produce a visual worth looking at. Quality in these early renders was based only on nearest playground. Later versions would take into account all nearby playgrounds.

Figure 6. Same as figure 5 but with a higher resolution.

Figure 7. These early heatmaps were not snapped into specific levels. I find the maps less distracting and easier to follow when they’re broken into distinct levels rather than being smooth gradients.

Figure 8. The first version rendered and viewed in Google Maps. A low resolution was used to keep down render time while making sure the generated tiles were properly aligned and scaled.

Figure 9. A render that included truck routes and an outline of the boroughs. I would like to add the truck routes as an optional layer in the future.

Figure 1. Tinkerbell in Disney’s Peter Pan (1953).

Peter Pan, Cinderella and Sleeping Beauty have been in pretty heavy (i.e., mind numbing) rotation which has given me plenty of time in which to start focusing on some of the minor details in these movies. One of the things that caught my eye was the pixie dust effect used for the Tinkerbell character in Peter Pan. I did a lot of hand drawn animation in college, spending many hours hunched over a makeshift animation table (it consisted of a sheet of Plexiglas with a taped on registration board, two chairs, and a desk lamp for an under-light). I know first hand how labor intensive and frustrating hand drawn animation can be, and its difficult to fathom the amount of time and effort that was put into tracking and animating the various specks to make the pixie dust effects in Peter Pan.

Today, we can achieve a similar effect with just a few lines of code. My implementation lacks a bit of the human touch which gives life to the Disney work, but I think it’s still a pretty fun piece.

Figure 2. Move your mouse over the area above to spread some pixie dust.

Flocking behaviors are a lot of fun to play with, but simulating them can be fairly processor intensive. In an earlier post, I talked about using proximity grids to increase performance in this type of simulation. In the demo at the bottom of this post, I have employed a proximity grid and an implementation of verlet integration to control the particle dynamics.

One of the problems I ran into when combining flocking behaviors with proximity grids is that flocking tends to subvert the ways in which proximity grids optimize. A proximity grid reduces processing by making it easy to skip any inter-agent reactions on agents which are far apart. Flocking on the other hand tends to take agents and clump them together into small areas, thereby thwarting some of the benefit of a proximity grid. This is not to say that the proximity grid doesn’t help, because it does, but a proximity grid is more effective in cases where particles are scattered somewhat evenly across an area. I was unable to simulate as many particles in this demo as I did in the proximity grid demo partly because of the clumping nature of flocks, but mostly because of the need to examine the direction in which a particle is heading (a costly operation).

Figure 1. Agents react to near neighbors according to the basic priniciples of flocking. The length of an agent’s tail is based on its current velocity.

The core principles of flocking are alignment, separation and cohesion. Each individual agent (e.g., particle, sprite) operates autonomously by following these 3 basic rules. Each agent can only “see” agents near them (their neighbors). Agents will avoid close contact with neighbors (separation), they will attempt to travel in the same direction as their neighbors (alignment), and they will attempt to navigate towards the average position of their neighbors (cohesion). By employing these 3 basic rules, a wide variety of complex group behaviors emerge.

I’ve built a simple demonstration of flocking in Actionscript which you can view at the bottom of this post. This demo requires Flash Player 9 or later.

Figure 2. Holding the mouse button down will attract the agents, releasing the mouse button returns them to their regular behavior.

I put this demo together as a way to test the linked grid concept, but I liked the test enough that I cleaned it up visually and added mouse interaction. Below are a couple of screenshots followed by the actual Flash demo you can interact with.

Figure 1. There are 450 invisible points bouncing around the screen. As they come close to each other, a line is drawn connecting them.

Figure 2. Result of points being repelled by a mouse release action.

Figure 3. Clicking the mouse causes the points to head towards the mouse, while releasing quickly repels them.

Proximity grids are not new and have been utilized for a long time as an optimization technique in video games (search for “tile based collision detection” for further reading) and have also been explored thoroughly in Flash by developers such as Grant Skinner and Keith Peters (August 2005).

After creating a shoe, designers can submit their creations into the Kicks Creator Battle, a head-to-head competition where the general public gets to determine the best designs.

The Nike Dunk: Kicks Creator was developed in Actionscript 3 and uses Papervision 2.0 to render the shoe model in real time. You can view one of my entries 3D.

Figure 1. A sample of the various styles of arrow that can be easily created with GraphicsUtil.drawArrow

Creating a Simple Arrow

You need only provide a graphics instance as well as the start and end points of the arrow. The GraphicsUtil class can handle the rest. This is the simplest arrow you can draw. It will take on whatever lineStyle and fill properties you set on the graphics instance. In this regard, it functions similarly to the graphics.drawRect and graphics.drawCircle methods.

Code Sample 1. The simplest use case for GraphicsUtil.drawArrow

import com.dncompute.graphics.GraphicsUtil;

//Create a display object to draw into and set the colors
var shape:Shape = new Shape();
shape.graphics.lineStyle(1,0x000000);
shape.graphics.beginFill(0x999999);

//Draw an arrow from 30,30 to 100,100
GraphicsUtil.drawArrow(
		shape.graphics,
		new Point(30,30),new Point(100,100)
		);

Figure 2. The Actionscript shown in Code Sample 1 will generate this arrow; it is the default arrow that will be created if you don’t pass any styling parameters.

Styling the Arrow

If you need to customize the look of the arrow, you can do so in Actionscript by passing in a style object. This can be done using the shorthand generic object notation (i.e., an associate array). You can also style the arrow using the more OOP friendly method of creating an instance of the ArrowStyle class.

Code Sample 2a. Shorthand Styling Using Object Notation

import com.dncompute.graphics.GraphicsUtil;
import flash.display.Shape;

//Create a display object to draw into and set the colors
var shape:Shape = new Shape();
shape.graphics.lineStyle(1,0x999999);
shape.graphics.beginFill(0x000000);

//Draw an arrow from 30,30 to 100,100
GraphicsUtil.drawArrow(shape.graphics,
		new Point(30,30),new Point(100,100),
		{shaftThickness:5,headWidth:40,headLength:60,
		shaftPosition:.25,edgeControlPosition:.75}
		);

Code Sample 2b. Style Using the ArrowStyle Class

import com.dncompute.graphics.GraphicsUtil;
import com.dncompute.graphics.ArrowStyle;

//Create a display object to draw into and set the colors
var shape:Shape = new Shape();
shape.graphics.lineStyle(1,0x999999);
shape.graphics.beginFill(0x000000);

//Set the arrow style
var style:ArrowStyle = new ArrowStyle();
style.shaftThickness = 5;
style.headWidth = 40;
style.headLength = 60;
style.shaftPosition = .25;
style.edgeControlPosition = .75;

//Draw an arrow from 30,30 to 100,100
GraphicsUtil.drawArrow(shape.graphics,
		new Point(30,30),new Point(100,100),
		style
		);

Figure 3. The Actionscript in Code Sample 2a and 2b will generate the same styled arrow you see here.

Arrow Style Editor

While it’s relatively easy to style the arrows, the style parameters may seem unintuitive at first. To help alleviate any confusion, I’ve provided the following arrow style generator which will allow you to interactively create an arrow style and print out the generated code. You can also use the “randomize” button to morph the shape into a randomly styled arrow.

The drawArrow method uses a line intersection function based on Erik Gustavsson’s tutorial and sample code. I recommend Mr. Gustavsson’s tutorial if you are interested in the math involved in drawing the arrow outline.

The best part of BrowserCanvas is that it requires no external JavaScript in the page to function. Deployment involves putting a single Actionscript class into your classpath and adding a couple lines of code to your project. That’s it. There is no messing around with JavaScript imports, there are no extensive Actionscript libraries. It is as clean and simple as possible.

Example Code

The following example shows you everything you need to do to randomly resize a flash movie every time the stage is clicked.

package {

   import flash.display.Sprite;
   import flash.events.MouseEvent;
   import com.dncompute.canvas.BrowserCanvas;

   public class DemoMain extends Sprite {

      private var canvas:BrowserCanvas;

      public function DemoMain() {
         canvas = new BrowserCanvas(stage);
         stage.addEventListener(MouseEvent.CLICK,randomSize);
      }

      public function randomSize(event:MouseEvent=null):void {
         canvas.width = String( Math.random()*500 + 200);
         canvas.height = String( Math.random()*500 + 200);
      }

   }

}

Live Examples

Below are links to different examples of BrowserCanvas in action. All of these examples are included in the browser canvas download file at the end of this post. You will note that none of these examples have additional javascript code embedded in them, all of the code is embedded in the Flash movie.

• Advanced Controls Demonstration (Basic Embed | SWF Object)
• Random Resize (Basic Embed | SWF Object)

Caveats

While using BrowserCanvas is really simple, the code itself does have a little bit of complexity to it. Unfortunately, simple and cross-browser are rarely in the same sentence.

I’ve tested BrowserCanvas in a variety of modern browsers on both OSX and Windows. I have not tested BrowserCanvas in any of the golden oldies (IE 5.5 or less, Firefox 1.5 or less, Netscape anything, Safari 2.0 or less, Opera 8 or less) and don’t plan to add support for them.

The execution speed seems to be incredibly slow in Safari, and min/max behavior in Safari seems to only work in the SWF Object version of my demos. For most applications this shouldn’t be an issue, but I plan to investigate this further if I find the time.

I also have not tested BrowserCanvas in sites with complicated CSS layouts and AJAX interaction. If you have issues in any current browser, I’d be eager to hear about them. BrowserCanvas attempts to do a bunch of clever things in JavaScript, but I wouldn’t be surprised if some of these tricks don’t work in a few fringe cases. You can turn the browser specific hacks off, this is discussed in the comments for the BrowserCanvas class.

Also note that if you want to run the examples locally, you may need to make changes to the Flash Player security settings. You can find instructions on how to do this half way down this article from Adobe . You can access the Global Security Settings Panel by doing the following:
Right Click Any Flash Movie > Settings > Privacy (Tab) > Advanced (Button) > Global Security Settings Panel (Link)

History

Packaging up Flash based components for use across a large variety of websites is a regular challenge for professional Actionscript developers. With the release of Flash 9, Adobe has made this easier to accomplish with innovations such as SWC Actionscript libraries. SWC libraries work well when you are deploying components which are self contained, but don’t cover situations where a component requires external elements such as JavaScript libraries. Documenting and deploying all of the various pieces necessary for a component like this can be an onerous task. I’ve often longed for a way to package all of a component’s various pieces together into a single, easy to deploy package.

One way to do this is to insert the JavaScript directly from Flash, rather than embedding it in the HTML page. I spent some time when Flash 9 was first released looking into ways to accomplish this. My understanding at the time was that ExternalInterface only worked to call existing JavaScript functions on the page, so I focused my JavaScript code insertion efforts on the use of navigateToURL("javascript:XXX"). While this technique works to a limited degree, I abandoned my efforts because I found the results incredibly unwieldy to use with large codebases.

However, I recently discovered an article devoted to JavaScript injection by Peter McBride. Mr. McBride has dispelled many of my misconceptions surrounding ExternalInterface. He also demonstrates some clever techniques for embedding JavaScript into your Actionscript code. I highly recommend Mr. McBride’s article, it is a thorough and easy to follow introduction to the JavaScript injection techniques used in BrowserCanvas.

Update 26 Feb 2009:
I recently updated this class to v2 which should correct the IE issues which some users noted in the comments below. Internet Explorer does not properly handle min/max settings on object tags. To work around this, browser canvas was reparenting the object tag and swapping it’s id. Unfortunately, changing the ID of an object appears to break Flash’s External Interface calls. I’ve adjusted the class to account for this. If you are not setting min/max sizes, I would also recommend that you simply turn this hack off altogether when instantiating the class.

Update 07 Jul 2009:
There have been some issues coming up in the comments that I wanted to bubble up if those of you who may not read all the way down. First, the main reason BrowserCanvas fails for some people is due to issues with the id attribute of the embed/object tag. It’s important that the id attribute is set, otherwise the JavaScript code which resizes the flash movie has issues finding the element in the page. Other issues which people seem to face is failure while using the “static publishing method” of SWFObject. The “static publishing method”, while standards compliant, results in a double nested object tag which wreak havoc on the JavaScript resizing. Stick with the “dynamic publishing method” (the tutorial on the swfobject site gives step-by-step instructions for both methods).

When AIR was initially announced I was not particularly impressed. It appeared to ape the Java/.NET deployment models and was now apparently competing against these tools which are vastly more powerful and offer a much broader feature set. More importantly, I believed AIR flowed in the wrong direction. For the past 10 years (and especially in the past 2) desktop applications have been slowly getting replaced by web/browser based ones, and I fully expect this trend to continue.

Ultimately, AIR does not bring much to the table that web applications do not already offer. Local file system access is nice, but it is limited and not nearly as flexible as storing data in the cloud. The “sometimes connected” capability of AIR apps is a pointless feature in a world where we expect to always be connected. The “native”-ness of AIR apps is nice, but I would guess that most people are more familiar with web apps like Facebook/MySpace and GMail than they are with most local apps on their computer.

Most of the current uses for AIR have ranged from mediocre ports of existing websites (an AIR version of EBay? Who wants this?) to the kind of dreck usually reserved for widget libraries (skinned clocks? egg timers?). Needless to say, the current set of AIR apps is not doing Adobe any favors in differentiating Adobe AIR as an application delivery framework.

After my recent experiences with AIR, I have to say that I’m not won over, but I do see a glimmer of potential that I didn’t see there before.

If I had to point out Adobe AIR ‘s best feature and the one feature that I think differentiates it from its competitors it’s this: The install process for most AIR apps and the AIR framework is managed through the Flash Player and is fairly seamless.

Now, that may not sound like much to get excited about, but I think it’s the part of AIR that makes it a worthwhile product. If you have not installed an AIR application, I suggest you give it a try. The install process is fairly well done.

I think it’s a mistake to think of AIR applications as competitors to desktop applications. They are not. AIR apps will never be as powerful or as capable as native applications. On top of this, Adobe has gone a long way towards crippling AIR apps in the name of security; pursuing tight security is a good idea if it helps AIR get deployed in restrictive workplaces, however it remains to be seen if this will pan out.

I think it’s more appropriate to think of AIR apps as enhanced web applications. In this view, Adobe AIR isn’t competing against desktop applications and is not directly competing against local java and .net applications. Instead, I believe AIR is actually competing against web based applications, including those built for the Flash Player. The ease of install makes it relatively painless to run Adobe AIR apps, the tight sandbox makes them somewhat secure like web apps, and the “native”-ness of them can make them more useful in some instances than web apps.

I still don’t have much enthusiasm for Adobe AIR in its current state. However, the easy install process makes Adobe AIR applications accessible to a mass audience in a way that regular downloadable software is not. The question is whether or not this mass audience will have interest in downloading apps which offer very little over their web based cousins. The answer to this question may change over time, but I have a good guess as to what it is now.

Out of this experimentation, however, I created the following Flash prototype of “curious” robots. The robots will watch and approach the mouse cursor, but will flee in fear if the mouse cursor gets too close. You can single out a robot and chase him around with the mouse while the others watch. This is both cruel and fun.

This site’s current three circle logo comes from the design of these robot’s “eyes”. The current logo, however, reuses the Trade Gothic “o” instead of a filled circle.

Figure 1. A screenshot of Pestilence. Red is newly created life, black is life that has been alive for at least one step, white is empty space.

That same year, I created my first Life simulation in Flash 4. Unfortunately, Flash was not quite fast enough at that time to make much more than a small grid that slowly crawled along. The result was not particularly impressive.

Today however, Flash is a bit faster, as are most of our computers. I spent some time yesterday creating a life simulator in AS3. I applied a couple of bitmap filters to it in order to make the appearance more dramatic. You can view the real-time simulation at the bottom of this post.

Pestilence. Use your mouse to paint new “live” pixels onto the screen. The simulation pauses while painting.

If you have never heard of Life or emergent behavior, I highly recommend Mitchel Resnick and Brian Silverman’s Exploring Emergence as starting point for understanding what Life is and why people like myself continue to find it interesting almost 40 years after it was devised.