Posts tagged "newsapps"
The other week, we published our latest interactive: ‘Male Plumage’ Then and Now: The Changing Face of Men’s Fashion. Now we don’t consider ourselves fashionistas, but one morning Michael got an email to upload a Newsweek article to Document Cloud. It happened to be an article from 1968 about men’s plumage, apparently around the time men first started to define a distinct American modern style via patterns and accessories. We looked at the article and started laughing at all the nostalgic memorabilia and vintage photographs.
The Newsweek cover containing the article depicts a Ron Burgundy-like character in a pink suit with some of the fashion items around him, depicted as cut-outs for a paper doll. In 1968 this depiction of changing outfits was for illustrative purposes, but in 2013 how could we re-imagine this cover? Could we see the cover come to life by having the pieces of clothing actually be changeable by the reader? It was fun to think about adding another dimension to print, and to look at something from the past and apply it to something current.
At the same time, Isabel Wilkinson, one of Newsweek’s fashion writers was doing a story on Men’s Fashion Week 2013 in Europe. We thought it would be a great idea to compare men’s plumage in 1968 to the plumage we see today as part of the fashion show.  And so we had a project.
Under the hood
To begin, we imagined the cover pieces as draggable items and the 2013 plumage items would be stored in a drawer to the side. It was a fairly simple layout, allowing the cover to stand on its own and then become transformed by the reader into the moveable pieces. Instead of hardcoding the individual elements, we utilized The Miso Project from GitHub to create JSON from a Google Spreadsheet via an API key, which gave us flexibility to add or remove pieces as we were designing it. We used Underscore.js as our templating engine to make our HTML elements. More about Miso is explained in this ++previous post++ but for this project, under a tight news schedule, we used the ease of filling out an excel spreadsheet to easily get our JSON needed for our template. In our JSON, each object has an id, image to load to the template, layer or z-index value, and a classification of either “then”(1968) or “now”(2013):



In our HTML, we added a script tag to identify our template and classes containing values from our JSON, something like:

In our Javascript, we grabbed the template markup by its id and turned it into an Underscore template function with _.template(). We then appended each row from the spreadsheet (now JSON) to either a div containing the the items of “then” or a div containing the items of “now”, either ‘#plm-canvas-then’ or ‘#plm-canvas-now’. The syntax looks something like this (slightly different than our deadline code, but slightly nicer as well):

To make the elements draggable, we used jQuery UI like this for all of the item elements, since they all had the same class:

Drag events don’t translate too well on mobile, however. To fix that we loaded the plug-in jQuery UI Touch , which translated the appropriate touch handlers for mobile screens.
Now we have all of our elements draggable and organized based on if they are on the cover or in the “drawer”. The drawer element is something Michael came up with to allow the reader to pull and drag items into one place. Further, once the reader makes the plumage combination they like, it could be possible to share their design via social media. I’ll pass it on to Michael now to explain the development of both of these features.
The Drawer and Shareable Links
Thanks Clarisa. This was a fun interactive to work on and had a few tricky details—this drawer was one of them. As Clarisa said, we wanted to mashup the old style with the new. We also wanted an option to remove items from the canvas once you were done with them so you could clean up your design. In addition to .draggable(), jQueryUI has .droppable(), which lets you drop draggable items.
This was a little tricky because we wanted elements to be absolutely positioned outside the drawer but relatively positioned inside the drawer so they would stack up on top of each other. We handled this through swapping classes on .mousedown() and applying different positioning for each class.
To make it all shareable, we used jQuery BBQ which is super handy. On item drag, we recorded the final x-y position of each element and whether it was in the drawer or the canvas. We used jQuery.bbq.pushState()with a merge state of 0 to accomplish this. On load, we checked to see if someone had a saved state in the hash and if so, drew the plumage to reflect that.
Cues to interactivity

One small detail is the rotation that happens when you start the interactive. We needed to rotate the items because 1) they wouldn’t fit on the model in their original positioning; and 2) we wanted to cue the reader that the hitherto static image was now alive. This was also the logic behind spinning the model’s pinks suit: we needed a way to tell the reader that the image was was in the 21st century.
 
Clarisa Diaz and Michael Keller
 

The other week, we published our latest interactive: ‘Male Plumage’ Then and Now: The Changing Face of Men’s Fashion. Now we don’t consider ourselves fashionistas, but one morning Michael got an email to upload a Newsweek article to Document Cloud. It happened to be an article from 1968 about men’s plumage, apparently around the time men first started to define a distinct American modern style via patterns and accessories. We looked at the article and started laughing at all the nostalgic memorabilia and vintage photographs.

The Newsweek cover containing the article depicts a Ron Burgundy-like character in a pink suit with some of the fashion items around him, depicted as cut-outs for a paper doll. In 1968 this depiction of changing outfits was for illustrative purposes, but in 2013 how could we re-imagine this cover? Could we see the cover come to life by having the pieces of clothing actually be changeable by the reader? It was fun to think about adding another dimension to print, and to look at something from the past and apply it to something current.

At the same time, Isabel Wilkinson, one of Newsweek’s fashion writers was doing a story on Men’s Fashion Week 2013 in Europe. We thought it would be a great idea to compare men’s plumage in 1968 to the plumage we see today as part of the fashion show.  And so we had a project.

Under the hood

To begin, we imagined the cover pieces as draggable items and the 2013 plumage items would be stored in a drawer to the side. It was a fairly simple layout, allowing the cover to stand on its own and then become transformed by the reader into the moveable pieces. Instead of hardcoding the individual elements, we utilized The Miso Project from GitHub to create JSON from a Google Spreadsheet via an API key, which gave us flexibility to add or remove pieces as we were designing it. We used Underscore.js as our templating engine to make our HTML elements. More about Miso is explained in this ++previous post++ but for this project, under a tight news schedule, we used the ease of filling out an excel spreadsheet to easily get our JSON needed for our template. In our JSON, each object has an id, image to load to the template, layer or z-index value, and a classification of either “then”(1968) or “now”(2013):

In our HTML, we added a script tag to identify our template and classes containing values from our JSON, something like:

In our Javascript, we grabbed the template markup by its id and turned it into an Underscore template function with _.template(). We then appended each row from the spreadsheet (now JSON) to either a div containing the the items of “then” or a div containing the items of “now”, either ‘#plm-canvas-then’ or ‘#plm-canvas-now’. The syntax looks something like this (slightly different than our deadline code, but slightly nicer as well):

To make the elements draggable, we used jQuery UI like this for all of the item elements, since they all had the same class:

Drag events don’t translate too well on mobile, however. To fix that we loaded the plug-in jQuery UI Touch , which translated the appropriate touch handlers for mobile screens.

Now we have all of our elements draggable and organized based on if they are on the cover or in the “drawer”. The drawer element is something Michael came up with to allow the reader to pull and drag items into one place. Further, once the reader makes the plumage combination they like, it could be possible to share their design via social media. I’ll pass it on to Michael now to explain the development of both of these features.

The Drawer and Shareable Links

Thanks Clarisa. This was a fun interactive to work on and had a few tricky details—this drawer was one of them. As Clarisa said, we wanted to mashup the old style with the new. We also wanted an option to remove items from the canvas once you were done with them so you could clean up your design. In addition to .draggable(), jQueryUI has .droppable(), which lets you drop draggable items.

This was a little tricky because we wanted elements to be absolutely positioned outside the drawer but relatively positioned inside the drawer so they would stack up on top of each other. We handled this through swapping classes on .mousedown() and applying different positioning for each class.

To make it all shareable, we used jQuery BBQ which is super handy. On item drag, we recorded the final x-y position of each element and whether it was in the drawer or the canvas. We used jQuery.bbq.pushState()with a merge state of 0 to accomplish this. On load, we checked to see if someone had a saved state in the hash and if so, drew the plumage to reflect that.

Cues to interactivity

One small detail is the rotation that happens when you start the interactive. We needed to rotate the items because 1) they wouldn’t fit on the model in their original positioning; and 2) we wanted to cue the reader that the hitherto static image was now alive. This was also the logic behind spinning the model’s pinks suit: we needed a way to tell the reader that the image was was in the 21st century.

 

Clarisa Diaz and Michael Keller

 

Google Docs + Miso-Powered Apps: a note on collaborative workflow

Working both collaboratively and efficiently on deadline, needless to say, is important. For our fastest-paced interactives and news apps, we’ve come to use a combination of Google Spreadsheets and Dataset.js from the Miso Project in a way that we’ve come to really quite like. We figured we’d share it with you here.

Essentially, we use a Google Doc as a temporary database for our text or numeric data. When we go live, we download that data to a local CSV, change the path, and deploy.

We’ve used this workflow on the Obama Haters Book Club, the sidebar to our election coverage page (which doesn’t exist on our site anymore but which looked like this), our Meet Romney’s Bundlers interactive, a variant of it for HavingTroubleVoting.com (where we had a Google Form power a Google Spreadsheet) and the Olympic Medal Tally among others. 

Note: This post is a bit more technical than usual.

The first step is getting everyone to put the information they gather into a structured spreadsheet. Here’s what the Obama bundlers spreadsheet looked like.

From there, we “Publish the spreadsheet” from the File menu — the crucial step when running an app off of a Google Spreadsheet — and import the data into our app. The Dataset.js documentation has a very simple tutorial on that step: http://misoproject.com/dataset/tutorials/googlespreadsheets

With this setup, reporters can be writing text and the photography department can be adding links to images at the same time the interactive is being built. What’s particularly great is an editor can edit the text in the spreadsheet and it will be piped into the interactive without his or her having to edit any HTML. The order of the rows can also be swapped if some elements need to appear before others on the page.

Mother Jones’s Tasneem Raja has written about this workflow as well, using Tabletop.js. Her post is definitely worth a read. 

So Why Dataset over Tabletop?

I’ve come to like Dataset.js over Tabletop.js for two main reasons. The first is that powering a live news app from a Google Spreadsheet can cause a lot of problems—so we download our data from the cloud onto our servers before going live. Dataset.js makes this transition really simple.

Jeremy Singer-Vine at the Wall Street Journal has written about the dangers of running live apps from Google Docs and he has a strong argument: 1) Google can rate-limit you, killing your live app; 2) If Google changes its API in the future your app may go offline; 3) Google can add extra data to your API request that can slow down your readers; 4) Sometimes you want to make a bunch of changes all at once, like add a complete row of information — with Google, incremental changes cell-by-cell are immediately reflected in the app, which will create broken elements until you’ve finished a full row; 5) Security and data privacy — sometimes you have columns in your data that you want to use internally but shouldn’t be public facing. We ran into this with HavingTroubleVoting.com where we collected ready contact information to later verify reports but we didn’t want to make that info public to the world. 

By making a local CSV whose columns we’re picking for public view, we solve a lot of these problems. We get the benefit of working collaboratively in development and can switch to something more archivable and robust for production. I have some other scripts that could be improved that will download a spreadsheet automatically and turn it into a clean CSV. If I can clean them up a bit we can post them as well. 

The second reason is Dataset.js gives your data a lot of functionality, such as the ability to group, query, and turn your columns into arrays (which is particularly useful for hooking it up to libraries like HighCharts). In fact, being able to hook up a Google Spreadsheet to your app is just an extra feature of Dataset.js — as the name suggests, it’s built to work with data and it can do some fancy things regardless of whether you’re working with a local CSV or a spreadsheet in the cloud. 

If you have any suggestions, I’m at @mhkeller.

-michael

Notes and images from an ever-growing digital newsroom.

Newsweek & The Daily Beast

Contributors:
Brian Ries & Sam Schlinkert

Formerly:
Michael Keller, Andrew Sprouse, Lynn Maharas, & Clarisa Diaz

view archive