staringmonkey

Yes, good point! There's a lot of crossover there and also with digital humanities folks.

Journalists have some problems that tend to be somewhat peculiar to their jobs. Some examples:

* A mix of heterogeneous and often internally inconsistent data.

* A lot of data that is categorical, free text or otherwise non-numerical.

* A need to be robust that is not always accompanied by the time necessary to become an expert programmer.

I'm sure some other folks have these problems too, though I can't think of any other industry where folks would touch as diverse a range of data as we do.

If works for other niches, great! But I'm a journalist and I had journalism problems in mind when I built it. I can't speak to the needs of folks in science, finance or what have you.

Hello! Author of the library here. Just want to point out that I am a journalist and very active in the data journalism community. (6+ years) Both the sites you name-check have journalists who do production online graphics that don't go through the traditional Illustrator workflow and news organizations are increasingly discarding that antiquated pattern. (I've made a hundred graphics for NPR and I don't even have a copy of Illustrator installed.)

To your second point, that's fine. The most common feedback I've gotten is "I don't see what purpose this serves that X doesn't already fulfill!" Well okay then, you don't gotta use it. But given the fact I've done this job for years, working with the very folks who it's targeted at, I think it's probably safe to assume I've got some reasons. (Which you will find enumerated in the blog post and documentation.)

Hey, (I'm the original author of copytext at NPR) this looks like a really nice lib. FWIW, we specifically don't do it this way, because during development we're probably refreshing our page thousands of times and we don't want the delay of hitting the Google servers for every request.

Incidentally, that's also why we don't request the spreadsheet in Javascript--the lag time to render the page is too high.

We've found our approach gives us a nice balance of "real time" and "practical".

Thanks for the comment.