New Media Initiatives Blog

Some great conversation happening in the comments of my writeup of the Search session at MW2008, and it made me remember something I wanted to bring up at the conference but forgot. Namely, the concept of “master metadata”, or the idea that there’s one authoritative version of the metadata describing an object.

This came up for me in the session the MFA and MIT did on sharing their data for a new subsite: they mentioned the data was being “augmented” on the final site, and that someday they’d be interested in getting this extra information back into their main repository.

The problem’s immediately obvious: with all of the proposed sharing and opening up of our data, presumably to allow others to weigh in on it and add their voice, there are often situations where institutions would like to have some of this new data. For instance, we’re building a new version of ArtsConnectEd and intend to allow museum educators to variously tag, comment on, and draw relationships between objects. This will almost certainly be “good data”, stuff that would be valuable to integrate in our internal collection database.

The question is, how? Once your data is available for sharing, and someone actually builds something good with it and enhances it, is there a way to get that new data back into the source? Is there / should there be a way to tag metadata as “original source” or “augmented”? Should we be asking anyone harvesting our data to push back their changes for us to audit and possibly include?

Anyone solved this? Seb, are you getting info back from Flickr Commons you can then add to your internal database? Phil / Jenna, any thoughts on how to get that extra data back?

This video speaks for itself, but this guy obviously knows how to find a niche:

If you have animation
Use with moderation
Cause search engines can’t index the information
…
Dont use bold
Please use strong
Cuz if you use bold that’s old and wrong

Full lyrics here.

Be sure to check out m0serious’s other videos. Paid Search 101 and Link Building 101 are both funny and informative. m0serious would appear to fall into the web development branch of the nerdcore hip hop genre.

For some time, most Walker websites have been without an important branding element: a favicon. Most often, favicons appear in the location bar, next to the URL of the site. They can also appear when a site is saved as a bookmark and in a browser tab. For sites with RSS feeds, favicons also often appear in the RSS reader as an icon next to the feed name.

I find I don’t often notice when a site is missing a favicon, but do notice when it has one. Coming up with a 16×16 pixel icon that somehow encapsulates the identity or brand of an institution is difficult, especially when said institution doesn’t have an official logo. In discussion, we thought about using a W, but thought it looked bland. The Walker typeface has a nifty alternate W, which is what we ended up using:

Side note: I recall Matthew Carter, designer of the Walker Typeface, discussing the typeface and W at an Typecon 2003. I remember him telling a story about the W, so I contacted him to clarify:

I did the disjointed alternative W in the Walker type convinced that I had invented the form. But later when I was at the AIGA conference in New Orleans I saw the same W on manhole covers. Some of my type designs have been inspired by lettering I’ve seen in the everyday environment — Mantinia is partly based on lettering on the Boston Public Library, for example—I use the Walker W as a facetious example of the environment ripping me off.

We’ve made use of Walker’s alternate W for most neighborhoods. However, a few sites that have their own identities or are a bit more unique get their own favicons:

• Most Walker sites
• Walker Blogs
• New Media Initiatives
• Design
• Visual Arts
• Performing Arts
• Film and Video
• Families
• Teen Programs and WACTAC
• Art On Call
• Gallery 9

The simplest way to put a favicon in a page is to simply drop the favicon.ico file in the root folder of your site. Most browsers will automatically see the file and display it. An .ico file has some limitations, most notably it does not support transparency. Most modern browsers (e.g. not Internet Explorer) support using a gif or png file that supports transparency, and will display cleanly when in a bookmark menu or a tab. To satisfy both groups of browsers, we actually use two icon files, a favicon.ico for Internet Explorer and a png for everyone else. Here’s what the code that goes into the head of every page looks like:

<link rel="icon" type="image/png" href="/favicon.png" />
<!--[if IE]>
<link rel="shortcut icon" href="/favicon.ico" type="image/vnd.microsoft.icon" />
<![endif]-->

Curiously, my browser of choice, Camino, ignores the favicon.png file and instead uses the .ico with it’s white background. However, I’m part of a very small minority and the .png with transparency works fine for Safari and Firefox users.

For the installation of Worlds Away, we needed to find a way to show the YouTube videos in the gallery. If you’ve visited the show, you’d see the videos installed in a Rec Room in the center of the gallery, complete with green shag carpeting, faux wood-gain paneling, low ceiling and bean bag chairs. It looks very much like my grandparent’s basement, minus the musty smell. The videos are viewable on a CRT television set on the floor in the corner of the room. I built a custom interface to allow people to control the TV, play the YouTube videos over the internet, at a decent quality, without violating the YouTube terms of service, and being mostly mischief-proof.

If you want to be spared the details, here’s a video:

Or, view it in a browser. This opens a pop-up window, Safari suggested, since that what it was built for. Use the left and right arrow keys, enter and escape to navigate.

When we started the project, we looked into ripping the flash video files from YouTube and creating a DVD. Testing showed the quality wasn’t great, but passable on a standard-def CRT television. The big hang-up about a DVD based approach was that it’s expressly forbidden in the YouTube terms of service:

You agree not to access User Submissions (defined below) or YouTube Content through any technology or means other than the video playback pages of the Website itself, the YouTube Embedable Player, or other explicitly authorized means YouTube may designate.

While it’s one thing to just avoid agreements like this with a wink and a nod for one-off or personal use, it didn’t seem like a good idea to blatantly violate the terms of service for an installation that would be in the gallery for months.

We also discussed setting up a computer in the gallery and simply putting a web page on it thin a custom player and view the videos. We weren’t too happy with that idea either, since it didn’t really fit within the Rec Room concept in the gallery — my grandparents don’t have a computer in the basement. We also discussed putting a big plasma TV on the wall, more like a modern TV, and using a remote or some sort of a pointing device to select videos using a custom YouTube player. Again, this option seemed costly (no spare plasma screens sitting around) and not within the theme of the room.

What we wanted was something kind of like the Apple TV, except limited to the 12 videos we selected for the exhibition. Quick research revealed no way to lock down an Apple TV or limit it to a particular YouTube playlist, so that was out. But what about making a web page that worked in a similar fashion?

It is possible to make Safari work in fullscreen mode using Saft. And there are applications that work with the Apple Remote to set up custom events and keystrokes. A computer with the right video card can also go out to a TV. And a little javascript magic in the browser could pull it all together with fancy fade and scroll effects.

jQuery and Safari fun
I started with the web page. I already knew I wanted to use jQuery for this project, if possible. I’ve been using MooTools for a while now and I wanted to expand my horizons to include a second Javascript library (half kidding). Using a TV screen for a display limits the usable resolution to 640×480, so there is not enough room to display all the entries on screen at once. Instead, I found the jCarousel plugin that I was able to use to scroll the video information across the screen. JCarousel has a lot of hooks for various events, so it made it quite easy to plug in to. The second thing I’d need was something to show the videos on screen once selected. The thickbox plugin is a lightbox clone, and seemed to do the trick. I tied it all together with some custom event hooks for keystrokes and a some logic to keep errant keystrokes from triggering multiple videos, excess scrolling, etc. In the end, I found that using the arrow keys and esc and enter are the best. In Safari, if you use any actual letter keys, it will default to type ahead find functionality and interfere with the scrolling offset.

The interface is designed explicitly for Safari. Since this is a single computer installation under our control, I don’t have to worry about whether or not it works in IE or Firefox. I have no idea if it works in IE (ignorance truly is bliss), but it only half-works in Firefox. Firefox doesn’t want to load the flash player in Thickbox. I’ve experienced problems with Firefox ignoring the z-index on Flash elements in the past, so this is not surprising.

Remote buddy
Now that I had figured out how to deal with the browser, I had to figure out a way to have the remote interface with the browser by sending specific keystrokes for each button. After looking at several programs that do this with the Apple remote, I settled on Remote Buddy. It was the easiest to configure so that it would only work with specific applications. I configured it to send the left arrow key on left arrow press, right on right, enter on play and escape key on menu button press.

One problem with the remote was that our computer was an older mirror-door G4 tower, which does not have an infrared receiver. Thankfully, Remote Buddy supports third-party usb receivers, so I ordered one, and it worked like a charm. Microsoft does build good hardware.

Video out
Unfortunately, we weren’t able to track down a G4 that had S-video or composite out, so I also ordered a newer video card for that. We got an ATI Radeon 9200 which has an excellent control panel for TV-out settings, letting you manipulate all aspects of the size, stretch, overscan, etc.

Net connection
In this configuration, the videos stream in real time from YouTube’s servers. Our galleries have pretty good wireless saturation, and an airport card in this tower allows the machine to connect to the network. I spent some time looking into using Squid for caching the youtube videos, but it appears YouTube recently changed the way videos are embedded, using some sort of a time-based token in the URL, making caching difficult if not impossible. Another option would be to keep the videos loaded in the browser, but in a hidden element. However, since there’s no interface for controlling the YouTube embedded player with javascript, starting and stopping the player is not possible.

Putting it together
After connecting all these things, I cleaned up the interface a bit, changing the typeface to Avenir, choosing colors that worked better on the Television (don’t use white). I configured Safari to start in full-screen kiosk mode, which Saft enables. Safari and Remote Buddy were set to launch on login, and the machine is set to automatically log in. Additionally, I set up a simple shell script that checks each of them to make sure they’re running and if not, relaunches them. With relaunching the applications, it’s important to use the command-line version of Applescript, since that will cleanly deal with backgrounding the process and giving correct screen focus.

Doc Czypinski, who was the lead tech for installing the show, was able to figure out a way to glue a white plastic strip to the back of the remote. He was then able to cable the remotes to the gallery furniture so that they don’t walk away during the show.

Post-mortem
Now that the computer has been in the gallery for about a week, there are two things we’ve learned. First, visitors tend to expect things to be playing automatically on the TV, since that’s the way most media things are in galleries. When they do figure out they need to use the remote, they tend to click the big play button and not cycle through the videos to choose. I’ve attempted to help this by putting arrows on the screen to indicate left and right so that visitors know to use the arrows on the remote to scroll.

The second issue is that the wireless hasn’t been 100% reliable. As anyone who uses Wifi on a regular basis knows, it’s not always up 100% of the time, and the wifi in our gallery goes out once in a while. I’m looking at writing a script that will cycle the Airport card off and on if it looses connectivity, or displays a message on screen if there is extended connectivity loss. A wired connection would certainly be better, but the convenience of Wifi cannot be beaten.

Gallery photo by Cameron Wittig. Arm of Justin Heideman.

In the research process for Worlds Away: New Suburban Landscapes, Design Director and Curator Andrew Blauvelt uncovered many interesting words invented to describe suburbia. Andrew enlisted now-former Design Fellow Jayme Yen and Visual Arts Fellow Rachel Hooper to assist in the research for the exhibit, and to further research the lexicon of suburbia. To make the collecting of the terminology easier, we set up a private wiki for them to use.

The wiki of terms has transformed into the lexicon found in the Worlds Away exhibition catalog (soon to be found in the Walker Shop). We thought the lexicon would make a great resource, so it was decided to build it into a larger exhibition website.

Site URL: http://design.walkerart.org/worldsaway/

The exhibition website is still a wiki, and you can help enhance and add to the terms in the lexicon. Each entry in the lexicon consists of a definition, a section for images, and a google map. You can modify or enhance the definitions, or add new terms we might not know about. Images can be added to better describe the term. And map locations can also be submitted to give a satellite overview for terms that may best be seen from above (cloverleaf, for instance). We also added bios for all the artists in the exhibition, as well as a few sample essays and excerpts from other essays found in the catalog. Additionally, the selected videos from our YouTube competition can be found on the video section of the site.

The design of the site is drawn from the exhibition catalog design by Senior Designer Chad Kloepfer. The book uses different paper and ink colors in different sections to compartmentalize the types of content (essays, interviews, lexicon, and topics). The site also takes the book or paper metaphor and uses it as the navigation mechanism, allowing you to always see the index for the other sections of the site.

I wanted to enforce a rigours structure on the wiki, not let it grow out of hand, and only allow public edits in the lexicon section. Like our other wiki sites, this one is based on pmwiki, which allows for a rigorous permissions system. We’re using a few extensions, extended markup (for footnotes), Google Map API, NewPageBoxPlus, and DictIndex (for the lexicon list). Pmwiki is quite hackable, and the skin we constructed makes good use of that hackability. For the animation and accordion, I’m using my favorite javascript library, MooTools.

Please take some time to explore the site and enhance the lexicon of terms.

A few days ago Microsoft announced their standards compatibility plans for IE8. It starts off talking about how IE8 passes the Acid 2 test, and then goes on to talk about the viewing “modes” in the various IE browsers.

IE handled these modes like most of the other browsers. There was “quirks” mode, which is invoked if no doctype is set (or a deprecated doctype), and “standards” mode if you used an appropriate doctype. Safari and Firefox work the same way. This gives a bit of flexibility to those who may have some older site with nonstandard or old spec code, and still follows general web standards for new code like you would expect.

Microsoft however decided to change things again in IE8. One would think the new and better standards that came about through the Acid 2 test would work in “standards” mode in IE8 given they follow the standard. But that is not the case. If you use “standards” mode in IE8, the browser will instead render the page like IE7 did, you will not get the new up to date standards fixes. And “quirks” mode will still render in IE8 like IE6 did.

Instead, to get the “super standards” mode, web developers will need to add a special meta tag to their sites to tell IE8 to render it in the new mode. This is just short sighted. It’s a band aid fix us web devs will have to live with for another 5 to 10 years.

The biggest problem here is the fact that standards compliance means “opt in”. Standards compliance should be determined by the doctype of the page, like the standards say, not some random meta tag. Microsoft’s comeback is that adding in standards means many pages build specifically for IE6 or 7 will break, and expecting everyone to rewrite their entire websites to standards compliance is not feasible.

Which is why I want to know why standards compliance can’t be an “opt out”? The meta tag idea is fine, but it should be the fix for the old, out of date, non-standard content, not new content. Microsoft can (and should) save companies the time and effort in having to rewrite all their sites, but that saving should come at the cost of adding a simple meta tag in the header of your old pages.

If you look at Microsoft’s OS’s they do similar things. XP broke some of the Windows 2000 programs because the API changed. Same thing happened in Vista. Microsoft rightly gave developers notice of these changes and gave them time to implement fixes for compatibility, so that when the new OS came out, the old programs could already be updated to run on the new OS. I’m not sure why a browser should be any different. Give legacy site devs the meta tag to add now, so that when IE8 comes out it “just works” like it used to. But leave the standards compliance the way it should be, the way the spec says.

This also has the added benefit of allowing legacy code and this fix to die off faster. If meta tags are only put into old code, as those sites are replaced, we can get rid of this “fix” much quicker. Making developers put it into new code just means we have to deal with this for that much longer, which is a pain.

I’m happy that Microsoft has finally decided to embrace web standards for a change. But in their quest for legacy support, their decision to slap an ugly band aid onto future code is a bad one. And it opens a slippery slope for future versions of IE that I’m not looking forward to, and that is unfortunate.

There are two great events happening this weekend in the Twin Cities if you’re a hardware hacking or development geek. The first is Bentfest MN. The three day festival (starting tonight) consists of demos, workshops and concerts all centered around circuit bending, happening right down the street at Intermedia Arts. What is circuit bending? This youtube video describes better than I ever could:

The second thing to check out this weekend is MinneBar. What is MinneBar?

minnēbar is an ad-hoc gathering of technology enthusiasts born from the desire for people to share and learn in an open environment. Participants work together and try to create something exciting by being in close proximity to lots of smart people. Each person contributes in some way by leading discussions, demos, asking questions, or volunteering.

The conference/gathering is going on in St. Paul tomorrow, is totally free, and will feature many sweet demos, workshops and networking opportunities. Brent and I are both planning on attending.

Photo Credits:
Circuit Bending Photo from salimfadhley.
Minnebar Photo from alt text.

One of the bloggers over at Daily Kos has an interesting analysis of the age old Mac vs. Windows decision, but this time with an eye towards how that may correlate to political leanings:

…the share of the market held by Apple’s OS X operating system looks tiny beside Microsoft’s behemoth. It’s even smaller on conservative web sites. When it comes to visitors to Instapundit, OS X visitors make up only 2-3%, suggesting that conservatives are less likely to go for the Apple brand than the general public. On the other hand, Daily Kos statistics show that between 15% and 25% of visitors to this site are using Macs — an astounding 5x times the general population of these computers. If you were at YearlyKos last time around, you could spot more Macs at breakfast than you’d find in an Apple store.

We see a similar phenomenon here on the Walker site. Roughly a quarter of our visitors are on a Mac, which is quite high compared to the general browsing population. There are a couple likely reasons for this, (all speculation, mind you). There is a booming design culture here in the Twin Cities, and the Walker is a cornerstone of it. Designers use Macs. We have an extensive educational outreach program, and education tends to use the Mac. And we have gallery 9, an online gallery of internet-based art, which appeals to other internet-based artists, who also tend to use the Mac.

What does it mean to us in the end? Not a whole lot. We design all our sites to be platform agnostic, which is what any good web developer should do.

A little over a year ago I described AJAX and the work I was starting to research into it. Back then I was calling it RPC (Remote Procedure Call), since I thought it made more sense than the term AJAX (Asynchronous Javascript and XML) as we techincally weren’t using XML.

Since then AJAX as a term has become pretty widespread and ubiquitous, as has its impact on the web. Now we can add the Walker to the large list of sites using this technology.

If you head over to our Art on Call website, you may notice a few changes to our stops list. Gone is the long list of stops, and in it’s place is a searchable, sortable, paginated view of our info. All of this happens dynamically without refreshing the page.

The way I went about writing this is a bit different from normal AJAX. With typical AJAX, you request XML data and load it into memory. Then you parse the the XML by various means, either using Javascript to pull data out of nodes, or an XSLT processor built into many modern browsers. The result of course is HTML, which you output to the page to update content when a user requests it.

There are two benefits to the normal approach. One is that it takes any translation processing off the server load and puts it onto the users machine, allowing the server to be more responsive. Two is that it gives you some flexibility in placing lots of data changes all over a page.

But it also has a large downside. Design and implimentation of normal AJAX usually means designing with Javascript. Since you’re front loading everything onto the users computer, actually designing and making changes to data means not only do you need to get the HTML right, but also the Javascript or any other parsing agent you use. This greatly adds to development time and makes maintainability a challenge.

Instead I chose to go a different route, something more in line with the AHAH (Asynchronous HTML and HTTP) method. AHAH could be thought of as a subset of AJAX. There is still asynchronous data exchange, the difference lies in the fact that the data parsing is done on the server and spit to the browser as fully formatted and designed HTML.

This saves a ton of time on coding and mainenance. And given that we’re already using XML/XSLT processing on our servers here at the Walker, it keeps our design process the same as well. Now I don’t have to worry if a display bug is because of badly written HTML or badly written Javascript, I can just design and build the way I normally do and have the page pull in predesigned HTML for the browser to render. It also alows others in our department to update and change the look and feel of our site without having to weed through a bunch of frontend Javascript programming to do so.

This does however make the data slightly less flexible. It’s harder to pull out one tiny bit of data to display in a remote spot on the page (though it still can be done). Our servers are also doing a tad bit more work (however most of the server work is generating the XML from the database, which would happen with either solution). But from a time, maintenance and budget standpoint it’s the right approach.

There’s still a few kinks to be worked out on the Art on Call page, as well as new features to add. These will be available in the coming weeks and should greatly enhance the usability and features of the site. And because we’ve taken this modified approach to AJAX, we’re able to deliver these features in a timely manner.

More on that and some things to watch out for when coding AJAX at a later date.

[Now that our main blogger is leaving, we’ve got to start picking up the slack and posting. I promise eventually to not just post about hardware and software bugs, but today that’s what I’ve got…]

Porter continues to be a rockstar hardware-wise, but I’ve been having some trouble with the proxy/caching webserver running on it. Sure, it’s caching, but every so often it would grab a version of page and decide to keep it for 3 days instead of the directed 1 hour. At first I thought it was a one-time deal from switching some cache settings on the server, but it kept happening… Walker staff would make a change to some content, wait, but it would never show up on the live page. Trouble.

The problem was caused by a line stored in the cached HTTP header: Cache-Control: max-age=259200. (that’s three days worth of seconds) (I’m including details so google can pick this up and hopefully save some poor guy a frustrating morning.) After some serious digging it appears the mod_cache module we’re using was taking whatever Cache-Control header was being sent by the browser and saving it in the cached header! In other words, I had configured the server to cache things for a maximum of 1 hour, but all it took to blow that up was a browser (or spider?) sending a request saying it didn’t want anything older than 3 days. Our caching server held on to that “3-days” part and decided the whole page should be valid for that long. Totally. Wrong.

I debated making changes to the mod_cache source and recompiling, but I finally found an easier answer: “CacheIgnoreHeaders Cache-Control". This tells the caching module to ignore the problem lines, and it seems to be golden. I’ll let it run for a while and see…

[In further bad news, the US got creamed 3-0 by the Czech Republic in their World Cup opener. Not unexpected, but it doesn’t bode well for getting past group play…]

We’ve been looking around for a while at which of our current projects could benefit most from adding some AJAX pieces like sorting, dynamic sub-refreshes, quick menus, etc. The jury’s still out, since we don’t want to do it “just to do it”, but now I know what tool I want to use: the just-released Google Web Toolkit.

The toolkit basically lets you write and debug(!!) your AJAX application using your favorite Java IDE (they provide nice hooks for Eclipse). While developing you can test it in an integrated “browser” in the JVM — access to debugger — or in a standalone Javascript/HTML web browser. Also important, they integrate support for manipulating the back/forward button stacks so those finally can do the right thing in your AJAX page. Sweet.
Lots more reading and investigating to do on my part, but this is huge. I’ve had some exposure to Google Maps API and been impressed with the functionality, and it seemed obvious that something like this was going to follow. It’s different than I thought (Java) but makes sense. They claim comparable code sizes and speed compared to hand-written AJAX, but the development / debug cycle will be so much quicker it makes some performance hit worthwhile.

We recently launched a site for the design exhibition Some Assembly Required. We put it together a bit differently than most of our sites. Here are some of the details of the products and tech used for it.

We started the site with a design concept already defined by the design department (Andrew Blauvelt, Design Direction and Chad Kloepfer, Design). The design example we had to work with was a postcard with a dotted outlined type that split the page in half. We approximated that feeling with a large horizontal stripe and the same dotted logo in our design.

When deciding what tool to use for the site build we considered creating it on our own admin but instead we decided to use a Wiki software called PmWiki. That program allows pages to be edited easily by a group of authors. Each author can create, edit and delete whole pages or any section of a page. The software sets up a flexible organic structure that allowed us to add pages or whole groups of pages to the site easily and with out prior planning. That was extremely helpful since we were under time constraints that didn’t allow for a large amount of time spent planning an information structure. A wiki could be accessed by anyone in the Walker or outside to edit and add content. And finally the Wiki being a prefabricated software product itself seemed a good conceptual match for a show about prefabricated architecture. There are some formidable downsides to using a wiki. There is a limited range of styles and layouts you can use. It does not tie into our existing database so content reuse later will be more difficult. We decided the good outweighed the bad for this application.

This wiki is skinable through the editing of several files. Most of the design is handled in the CSS files with only a few graphics. Any image graphics are added by authors. We had to turn on HTML in the PmWiki settings because the design needed a couple of DIVs dynamically filled above the logo. Typing HTML into the wiki text window runs counter to the wiki philosophy of keeping authors away from code and layout so they can focus on writing. Unfortunately I couldn’t contain all of this design in one PmWiki template. I’m considering doing a little clean up on the skin and releasing it to the wiki community but we may have hacked it just past the point of being useful to anyone else.

If you are interested in seeing how our wiki skin works I put the source up:
blogs.walkerart.org/media/prefab/prefab.zip

In our set up each wiki page generates a corresponding wiki page to fill the top row. To make full use of the prefab skin you will need to look at the markup to see what HTML was added to the wiki content. We have txt versions of the top row content online for the homepage and a content page.

Here is one to read over before we give our talk on blogs and RSS next spring.
Make your nonprofit more effective with RSS aggregation

source:Beth’s Blog

If you want to slow your downloads and your on a Mac I don’t think there are to many options but Charles, a small shareware app just got an upgrade and now works very well with almost no setup. At $50 per individual license it’s a bit expensive by shareware standards but it delivers reasonably on expectations, Charles slowed our blazing fast internal network down to the crawl of a 56k modem with no problems and it lets me monitor exaclty what files my Flash movies are downloading and how fast they are doing it.

Samuel Wan has a lot of very helpful Flash demos on his site. He has taken the time to solve a lot of problems that many of us Designer/Developers come across over and over. I was particularly interested in Xilhouette 1.0 project. It is a live XML visualizer written in Flash. If your interested but don’t have an XML file handy try pasting the source view of this page into it. Quite a nice simple radial layout.

Also anyone who is was a fan of the Smart Money Market Map or the News Map might like to see Samuel Wan’s Blog Tree Map. It is the same graphing concept executed in Flash with Creative Commons licensed FLA files available for download.