#takingstuffapart

[electricricecooker]

Taking stuff apart: “How ISIS Expands”, a simple multi-platform graphic story

Great technology allows for great storytelling, which seems to be the motto for the always excellent NYT Graphics team. In their newest graphic, How ISIS Expands (Hannah Fairfield, Tim Wallace and Derek Watkins), the Times looks at strategies of ISIS' expansion, published on the day the ancient city of Palmyra fell. One of the great technologies underlying each project at the NYT: ai2html. Since March 5, the Illustrator script was made available to the public. What it does is convert AI files directly to HTML, which I've described last summer before actually seeing and using the script (some guy even went as far as creating his version of it, which of course doesn't handle all the options the NYT ai2html has). Again, you need to know how to use it, and for that is another challenge for every modern graphics desk in media organisations. When integrated well into your workflow, it aims to provide a tool that lets your designers design the way they always had using Illustrator and produce an output that is for the Web. It segways well into the other point that makes something like the ISIS piece so great. Inside the "ai2html" script (which reads like JavaScript?) is a part where some "NYT break points" turn up, circa line 668 of the script's version 0.54: It turns out that when you create multiple artboards in your Illustrator file, they will be generated with different HTML classes for the size they are optimized for. We leveraged that for our own graphics, like the third runway piece. You can even force the artboard to work for multiple break points, by adding the size it's meant for after the colon (see screenshot before). This is what it looks like when you squeeze it to a mobile screen size: The next "technology" in this piece: Swiper. Presenting a topic in the form of "slides" (on the piece's mobile version) is something that I find very interesting and would like to try out someday. We don't often get the chance to do it in our newsroom, where print is still king, but at least we know that it's possible to integrate elegantly. In this case, when you're on a mobile screen, first of all, you are given the narrow width artboard that was created on Illustrator via ai2htm. For instance, this is the PNG background of the first "slide": http://graphics8.nytimes.com/newsgraphics/2015/05/15/isis-next/db6b19f7946afe46e0f01b83b7acb5575eab2aeb/isis-next-isis-control-map-hed.jpg Then, the Swiper script encloses your graphic div as a slide, so that touch, click and mousewheel events trigger going to the previous or next slide. That's incredibly simple, and yet I'm a bit impressed by it. The next thing that I like a lot from NYT maps (other media like WaPo do it too on breaking news) is the addition of relief. I know it's been done on print for many years, but I wish we had the ability to have it in our map library. As a smaller newsroom, lightly mechanized one, we often still trace our maps by hand. I'm going on a segway, but last week, I helped my colleague colour this map of congressional districts (for Chinese investments in the US). I learned on deadline that QGIS is a hassle to export from (and you can't export in vectorial formats that are stylized). The solution wasn't perfect and originally in the wrong projection. But print media approximations made things look smooth in the end (but I don't really like the feeling). So, again, when you have the tech ready to be used, your team can focus on doing journalism.

[electricricecooker]

Taking stuff apart: Full-screening an iframe from inside (as seen on The Guardian's WWI multimedia feature)

Problem: you made a multimedia interactive and would like to embed that inside a regular page of your CMS (for whatever reason, like "SEO"). Solution: Provided by The Guardian (that subcontracted Kiln) in their new WWI multimedia feature.

The iframe containing the interactive is created at run-time from inside the "figure" element. A boot.js script is called, which sets things up. Aside from code that creates the iframe according to your type of device, boot.js includes an "expand" function to be called later when you first click on the moving image. boot.js sets up an eventListener of type message that gets called from inside the newly created iframe. So now, as a user, when you click on one of the triggers (the big yellow or pink discs), you are calling a function named "enterInteractive", which is found in app.js, which is minified, but shown here:

window.parent.postMessage is used to send a message back to the container of the iframe, where our event listener is listening. The message is "expand" and the expand() function in boot.js is called. This is what expand() looks like:

That triggers a bunch of stuff: saving of the elements such as the iframe with the multimedia, nuke() to delete all the non-necessary elements, maximise() to expand the iframe to fill the screen. There you go! Nice trick to keep a single URL for sharing around and that is within your CMS' infrastructure and template. But sounds like many hoops to go through for just that.

[electricricecooker]

Taking stuff apart: Nice maps on breaking news (MH17 crash) by the NYTimes

The NYTimes.com is impressive in many way. Their maps of the MH17 crash in Ukraine are equally so.

They seem to have an internal tool called “ai2html” that generates text over a PNG image (in HTML) from an Adobe Illustrator.

Those maps are probably then pasted into a responsive template that lets them go from a two-map arrangement (top picture: Ukraine and Europe + Eastern Ukraine) to a three-map one (bottom picture).

There seems to be a generated CSS that holds all the parts together (map and intro text). The news broke a bit before noon in Eastern Time, and they had the maps up within thee next two and half hours.

[electricricecooker]

Taking stuff apart: The NYT's Russia Left Behind

In October 2013, the NYT published two superb multimedia packages: A Game of Shark and Minnow (27 Oct 2013) and The Russia Left Behind (13 Oct 2013). Both were technically and artistically impressive in their own way. The former probably took more man-hours to make (and in our part of the world, is a lot more memorable), but the latter has perhaps elements that I personally found more intriguing and interesting. The Russia Left Behind was made by Mike Bostock, Shan Carter and Leslye Davis (the first two are known as the power duo of the NYT's Bay Area office), and tells the story of the small towns lining the road between St. Petersburg and Moscow. Not unlike Riding the New Silk Road (taken apart), Russia had a side map that changed as you scroll down the page. Under the header image is a map that beautifully reveals itself as you proceed below.

The labels over the map are in fact SVG elements. The base map looks like this: http://graphics8.nytimes.com/newsgraphics/2013/10/13/russia/207ffeebeb08f93156b7a4be9b0c17863de3143a/map-overview.jpg The base map itself is part of the SVG as an image tag.

I wonder why the points on the map were not also SVG circles, rather than being part of the base map. Advantages of using SVG? You can do the visual trick of stretching the map reliably with the scale (I wouldn't feel safe doing it with jQuery). And when you stretch, naturally the text scales. After experiencing this, hardcoding text into maps definitely seems sacrilegious. And also naturally, the map data is raw: http://graphics8.nytimes.com/newsgraphics/2013/10/13/russia/207ffeebeb08f93156b7a4be9b0c17863de3143a/map-overview.json Every scroll binds to the function "render" (line 1382). What you see is that as you scroll down, the map enlarges while staying centered on St. Pete and Moscow. Inside render, there the variable t that is computed as: t = (availHeight - top) / (availHeight + height) The two cities stay in the middle of the view because the map centers on them. The position of the map and visible space is determined only by them being in the middle. It's interesting then that the width of the scale is calculated dynamically. I didn't go into the calculations, but they are all at the beginning of render.

[electricricecooker]

Taking stuff apart: FiveThirtyEight's NCAA Tournament Predictions

Nate Silver, under the auspices of ESPN, relaunched FiveThirtyEight on Monday as a full-fledged news organisation. As part of their launch package, their team created FiveThirtyEight’s NCAA Tournament Predictions (Matthew Conlen and Nate Silver, March 17, 2014). The interactive forecast the chances of every team of winning in each round, and ultimately the tournament. When you highlight an arm of the bracket or the name of a team, the path of the most likely winner or the selected team is being drawn on the bracket. Silver explains their model here.

I had to poke around a little before I found the app's code. I feel that they voluntarily made their code more difficult for people to reverse engineer their stuff. I think that for JavaScript, it simply is not a nice thing to do, speaking strictly about etiquette. You know for sure that it is an iframe containing the contents. But when you try to open the iframe directly, you get to some site named wpcomwidgets.com. It's some kind of protected iframe, I think, that must load the contents of an iframe dynamically using a service provided by Auttomatic (the makers of WordPress). The contents of the iframe are all the team logos, percentages, pre-generated into a big block of HTML. In the code, there's a PNG placeholder, that's a copy of what's to be generated. It is my belief that everything cool nowadays is made in D3.js, and this interactive made by Conlen is no exception. In the iframe's code, you find links to JS and CSS files on projects.fivethirtyeight.com, and that's how you deduce that the origin of the iframe is at: http://projects.fivethirtyeight.com/march-madness/ And indeed, it is. I'm not going to read the code, because it has been minified/obfuscated. But essentially when you look into app.js, you find that the D3 code has been included into the same file (I quickly know by searching for "version", and whether it matches a current version of D3, now at 3.4.3). If I'm not mistaken, all of the app's information is pregenerated in HTML in the page. It seems that the D3 is for generating the bracket. Without really being able to confirm, because unable to clearly read the code, it might be that some of the information on the graphic is generated from data towards the middle of app.js, where team information and chances of winning each round was included. The result of FiveThirtyEight's work is indeed incredibly elegant in the end, but I can't fully appreciate the code as such. I'm looking forward to see more from those guys!

[electricricecooker]

Taking stuff apart: The NYT's Silk Road

In the first of this would-be series, I write notes on how I try to look at the code of developers from other news organizations.

Riding the New Silk Road by The New York Times

Silk Road (Shan Carter, Hannah Fairfield and Derek Watkins, July 21, 2013) is one of my favourite 2013 pieces by the Times. It's visually stunning and does not require a lot of reading (it's certainly more of a visual one).

...taken apart

The Map

The map on the right side is made out of different layers.

First, it's a raster map in background, with a satellite view of Central Asia and the rail line that crosses through it, between China and Europe.

Then, it's there is a classic HTML div that contains all the text going above the map: names of cities, legend. It's not part of the SVG.

Finally, comes the SVG, which contains the circles around the stops on the rail line.

Those are hardcoded into the page. On the other hand, what is not are the curved lines ("callouts") that link the media to the points on the map. Those are generated in D3.

So, after reading the code for a while, I see that the following serves to define the path of the curved line:

(line 328) // http://bl.ocks.org/mbostock/3960741 kazak.callouts.line.interpolate(function(points) { var x0 = points[0][0], y0 = points[0][1], x1, y1, x2, path = [x0, ",", y0], i = 0, n = points.length; while (++i < n) { x1 = points[i][0], y1 = points[i][1], x2 = (x0 + x1) / 2; path.push("C", x2, ",", y0, " ", x2, ",", y1, " ", x1, ",", y1); x0 = x1, y0 = y1; } return path.join(""); });

Further down, there's a refresh function inside the containing object that is called every time the browser window is scrolled or resize.

(line 523 and after) refresh: { callouts: function() { d3.selectAll('.g-callout').each( function(d) { if (typeof d.slideLoc === 'undefined') d.slideLoc = [0,0] var slideloc = kazak.data.slidelocs[d.id], ptloc = [d.loc[0],d.loc[1]], _opacity = kazak.callouts.opaque(slideloc[1]); // compensate for current map div offset at the callout start point Y position // (necessary because offsetting shifts svg 0,0 in relation to the page) slideloc[1] -= kazak.v.mapoffset // compensate for radius of point halo at the callout endpoint ptloc[0] -= 7; d3.select(this) .attr('d',kazak.callouts.line([slideloc, ptloc])) .style('opacity',_opacity) d3.select('.g-pt-halo-'+d.id).style('opacity',_opacity) }); }, ...

In it, there's a call to the previous function, with arguments specified as the location of the slide (the image or video) and the location of the point.

Those locations are determined in function kazak.refresh.slidelocs at every call of window resize or scroll.

The media

The information about the images and videos are all contained in this TSV file. 11 rows, one for each media element, with 6 columns. dateTimeOriginal and gpsPosition are not used. id, filename and type are used to generate the video elements.

The video elements are generated in jQuery. Empty placeholders exist in the page already and are populated in JavaScript when the page is ready.

The page also keeps track of the active media element in the page by listening to the current page position. When a change is detected, the kazak.interaction.highlight function with the numerical identifier of the media/slide is called. There, the given slide is activated. If its type is "video", we pause the previous one and start the new one. The new slide is highlighted, while the old one returns to rest state.

There is also a kazak.interaction.scrollto function that help jump from one slide to the other. It is bound to the key presses on up and down, but also when you click on a slide (if it's out of focus, then the function brings it to the middle of the screen).

Code structure

The code is organized in a single self-contained object, kazak. It's divided in sub-objects for the sake of compartmentalizing, I believe.

In all, the code for the graphic is just shy of 300 lines (there are a few dozen extra lines for social media sharing).

It's one of those elegant works of code that I'm excited to "read", like well-conceived clockwork. And it's a beautiful design to bring everything together.