1,932 karma · joined November 23, 2011
@adamrpearce
github.com/1wheel
[ my public key: https://keybase.io/1wheel; my proof: https://keybase.io/1wheel/sigs/oiIWaeFlocOXCQTRs_2pfsieq2ldvt0hIwB9xoUwtbc ]
We went back and forth on this a lot. Just showing the top relationships by number would result in omitting all same sex relationships, which didn't seem right. Their inclusion seems to have caused lots of confusion though - maybe it should have been called out more prominently than in the methodology. Even better would have been to have a toggle to show the more distinctive relationships.
It looks like I forgot to check in the R script used to process the .dat files to my gist https://gist.github.com/1wheel/a8e65b1576b750c5e3e3, but I'll add it when I get home.
We also tried to use salary info like the magazine version https://twitter.com/adamrpearce/status/697844614754123776 did, but had some problems with slighty different occuptation categories: http://www.bloomberg.com/graphics/2016-who-marries-whom/sala...
Interested to see what people come up with! This is a super interesting, rich data set that deserves much more than what I've done.
Close to what happened! The magazine graphic (https://twitter.com/adamrpearce/status/697844614754123776) was finished before I started on the web version, and I just had a couple of days to make something that could go online. I initially tried a more sort of 538/scatterplot/analysis approach, but wasn't making a ton of progress. I started just sketching out different ways of putting all 500 jobs on the screen at once. The grid of jobs with lines showing up on mouseover was the most fun to play with and being pushed to finish before valentines day, I went with it.
Sorry it was hard to use!
Even with some R experience I didn't feel like I got enough information from the R Prog lectures to complete the assignments.
The original magazine presentation - 6 full page spreads with 8 or 9 charts each - is way more readable. The higher information density of paper lets you glance at 9 companies at once and spend more time with what looks interesting. We tried to preserve some of the serendipity online with the short preview sentences on the left column, but the linear scroll through the charts takes away from that and makes it feel a little too chore like.
Sometimes translating to digital invites amazing improvements through interactivity (see what is code), but here we had a tight deadline and too many charts to redo them all in an interesting way w/ d3 so the digital focus was much more on the design side.
We did discuss just publishing a .txt or .nfo file instead, but some of the charts required a bit of ASCII cheating and being able to adjust font size & weight of labels really made them a lot more readable.
http://www.nytimes.com/interactive/2015/10/27/world/greenlan...
http://www.theguardian.com/us-news/ng-interactive/2015/oct/1...
https://source.opennews.org/en-US/articles/how-we-made-homan...
>One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn’t saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts.
https://www.ampproject.org/how-it-works/
http://www.niemanlab.org/2015/10/get-ampd-heres-what-publish...
Yup. We set up a system for publishing git repos with static html/css/js to /graphics for our interactive charts.
When the features desk for the new site started up a few months ago it was much easier for them to piggyback on our stack.
The features desk brought the Krugman piece to life. We tend to pick up more of the data viz/interactive stuff, but we do work pretty closely with / sit next to them.
We're hiring a couple of Interactive Graphic Journalists. We're looking for people with some combination of data wrangling, design and storytelling skills to making interactive graphics and features for the web. Some of the cool things we put out last month:
http://www.bloomberg.com/graphics/2015-paul-ford-what-is-cod...
http://www.bloomberg.com/graphics/2015-whats-warming-the-wor...
http://www.bloomberg.com/graphics/2015-executive-pay-peer-gr...
We use lot of different tools; I think we spend the bulk of our time in d3, illustrator, R or QGIS.
If you have any questions, please get in touch! I didn't think I was qualified for this role when I applied last year, but I've learned a ton working with a talented, creative group. Programming on news deadlines gives you a chance to regularly try out new ideas/techniques and get them in front of millions of people days or hours later in a way very few other jobs allow for. - apearce19@bloomberg.net
http://jobs.bloomberg.com/job/New-York-Interactive-Graphic-J...
Yup. Each node comes with a significant amount of overhead. If every lineto command required a separate node, this map[1] would go from requiring a manageable ~3000 nodes to a laggy ~40000.
I ran into this while working on a population map[2]. To draw paths with variable stroke, I initially tried creating a path element for segments of different strokes. This was too slow to animate or even render without freezing the browser, so I ended drawing the path left to right then right to left, making the height offset smaller and larger to simulate a stroke.
They were definitely considering the rounded corners use case; the details of drawing a rect element with a path[2] make arcs sound much easier to use than they actually are most of the time.
[1]http://www.w3.org/TR/SVG/implnote.html#ArcParameterizationAl...
Chan's algorithms is actually able to combine both approaches and runs in n log h. It is a bit trickier though, so I didn't make an interactive for it.
Cynthia Brewer's work is currently the gold standard
https://canvas.uw.edu/courses/891359/files/25713244/download...