Pacific Side

News Video Map

The most natural way of presenting world news content to me is on a map. Even without one presented to me, a geographical schema is my mind’s automatic way of visualizing a list of world news articles or videos. My goal was to take a collection of world news video from providers like the AP, Reuters, and AFP, associate the content with geographic locations, and plot the results on a map.

This started as a one-day project I worked on for one of the Yahoo! Hack Days last year, and I’ve been playing with it since then when I have time. Hover over video clip thumbnails for a full second to open a preview of the associated video clip. Click on the play button in the preview to view the video.

The mashup combines data services and tools from the following Yahoo! providers:
Yahoo! News
Yahoo! Video
Yahoo! Maps
Yahoo! Placemaker
Yahoo! User Interface Library

It also relies on SWFObject for Flash embedding and this free image resizing proxy called Images.weserv.nl.

On the backend, there’s a cron job that executes the PHP layer every hour. The PHP layer takes the Yahoo! News video feed for the World News category from the past seven days and runs all the video titles and descriptions through Yahoo! Placemaker to assign geographic locations to each one in latitudinal and longitudinal coordinates. The PHP layer then creates a JavaScript array of JSON objects from the data. For production use, it then rolls up the JSON data with the required JavaScript libraries and initialization script. The JavaScript layer creates the map and plots each video with a degree of randomization to prevent video clip thumbnails from stacking on top of one another.

The major issue to overcome in development was the amount of time required for data processing. Initially, the mashup fired an AJAX request to the PHP API that returned fresh data per request. It was taking over ten seconds for the page to load each request though, so I added a five minute cache to the API. The unfortunate user who hit a stale cache still had to wait over ten seconds for the page to load. In the end, I decided that since the purpose of the service is to provide a snapshot of videos from the previous week, it’s not particularly important that the data be fresh to the minute. I switched to a cron-driven script that updates the JavaScript every hour, making it available in native JSON at page load rather than via a delayed AJAX request for XML. I also made a number of optimizations to the frontend — removing duplicate scripts loaded by the Yahoo! Maps API, rolling up all required JavaScript into one file, deleting data from memory when it’s no longer needed, etc. Before putting this into full-scale production I would want to use an enterprise-grade image resizing proxy to scale the video clip thumbnails before they are loaded. As it is, it’s faster to load the larger thumbnails directly from the cache server than to pass them through the free image resizing proxy.

Update: Have switched to enterprise-grade image resizing. It’s more reliable than the free proxy and makes everything a lot faster. :)

Until today, I’d never really delved into when and when not to use a semicolon to close a line in JavaScript. I used to use them excessively, which is safe, but recently tried abandoning the semicolon after all closing brackets (“}”). This apparently broke some of my code today though, and I discovered that I need to keep the semicolon after the closing bracket of function expressions, while it is safe to leave it out after the closing bracket of a function statement. The different usage being illustrated here:

// Function expression

var myFunction = function(...) {
    ...
};

// Function statement

function myFunction(...) {
    ...
}

One of the projects I’ve been working on does a lot with communication between JavaScript and Flash. The ExternalInterface available in ActionScript 3 makes this a lot easier, and I’ve been wanting to do something cool with it. For now, I’ve worked on this example to illustrate the basics of how ExternalInterface works and its simplicity.

The relevant portion of the ActionScript:

// Add an ExternalInterface callback for communication from JavaScript

function flashCallback(data:String):void {
    textBox.text = "JavaScript: You clicked " + data + ".";
}
ExternalInterface.addCallback("flashCallback", flashCallback);

// Add listeners to communicate to JavaScript via ExternalInterface

circle.addEventListener(MouseEvent.CLICK, function(event:MouseEvent):void {
    ExternalInterface.call("jsObject.callback", "Green Circle");
});
square.addEventListener(MouseEvent.CLICK, function(event:MouseEvent):void {
    ExternalInterface.call("jsObject.callback", "Red Square");
});

The relevant portion of the JavaScript:

// Create a JavaScript object containing the callback for communication from Flash and triggers to communicate to Flash

var jsObject = (function() {
    var triggers = document.getElementsByTagName('a');
    var init = (function() {
        YAHOO.util.Event.addListener(triggers, 'click', function(e) {
            YAHOO.util.Event.stopEvent(e);
            YAHOO.util.Dom.get('mySWF').flashCallback(this.innerHTML);
        });
    })();
    return {
        callback: function(data) {
            YAHOO.util.Dom.get('flash_response').innerHTML = 'Flash: You clicked the ' + data + '.';
        }
    }
})();

View source on the example for more details.

• Example
• Download the FLA

Been working on some layering issues with our Yahoo! Finance interactive charts:

http://finance.yahoo.com/echarts?s=BRK-A

Making HTML/CSS/JavaScript content appear above the Flash portion is tricky in some Mac/Linux browsers. Today I fired up Firefox in my Ubuntu Linux virtual machine and went to Adobe’s homepage. It seems that even the people who make Flash don’t know how to fix all the browser layering issues because the dropdown menus there fall behind the Flash in the Linux/Firefox combination rendering them unusable:

http://adobe.com/

A survey of doctype and encoding usage across a couple of Yahoo and Google’s international locales:

Yahoo!
- Doctype? Yes. HTML 4.01 Strict.
- Encoding specified? Yes. UTF-8.

Yahoo! Taiwan
- Doctype? Yes. HTML 4.01 Strict (but mixes in some XHTML syntax).
- Encoding specified? Yes. BIG5 (legacy traditional Chinese encoding).

Yahoo! Japan
- Doctype? No.
- Encoding specified? Yes. EUC-JP (legacy Japanese encoding).

Yahoo! China
- Doctype? Yes. XHTML 1.0 Transitional.
- Encoding specified? Yes. GB2312 (legacy simplified Chinese encoding).

Google
- Doctype? No.
- Encoding specified? Yes. UTF-8.

Google Taiwan
- Doctype? No.
- Encoding specified? Yes. UTF-8.

Google Japan
- Doctype? Yes. HTML 4.01 Strict (but mixes in some XHTML syntax).
- Encoding specified? Yes. UTF-8.

Google China
- Doctype? No.
- Encoding specified? Yes. UTF-8.