Showing posts with label digital news media. Show all posts
Showing posts with label digital news media. Show all posts
12 March 2022
Slugs...
...are one of the terms that have acquired multiple meanings in my shop. Beyond the traditional journalism meaning—a short, reusable, almost arbitrary, traditionally ALL CAPS handle for a story making its way through the editing process—we've also used "slug" to refer to the friendly label above the headline that sets some context for the reader. In What's making us happy, it's the "SPECIAL SERIES" tag. The main topic of the story is often used as the slug, unless we're on the landing page for that topic... and that's a long story. To avoid confusion, we're introducing the jaunty term "eyebrow" as a replacement. The new CMS that we're on the long road to adoption uses "slug" for the semi-legible part of a semantic URL, the "whats-in-a-slug" bit in the case of the Times article linked above. "Permalink text" is the suggested replacement, but I think we'll still have to slug it out.
24 April 2018
Links roundup: 6
- Sophia Ciocca trots out the New York Times's new text editor, Oak. Track Changes and Comments. Color me green with feature envy.
- The OLPC project isn't quite dead. Yet.
- John Cook lucidly explains posits, a possible improvement over the current floating-point standard.
- Linkrot? The Times is fighting Flashrot, trying to shrinkwrap 10-year old pages in its archive.
24 September 2017
Kafkaesque
Boerge Svingen walks us through the log-based architecture that powers digital publishing at the New York Times. Now that we are in the era where disk isn't just cheap, it's effectively free, a storage-heavy approach like this can make sense.
24 November 2016
Links roundup: 4
- Flavio Ribeiro et al. have released components of the video processing workflow at the New York Times to the open source community.
- Adam Conner-Simons describes Gitless, developed at MIT. The tool is intended as a gentler introduction to the Git mindset—no stashing required.
- Phil Sturgeon makes a succinct comparison between REST- and RPC-based APIs. One isn't better than the other; they're just different.
- RPC-based APIs are great for actions (that is, procedures or commands).
- REST-based APIs are great for modeling your domain (that is, resources or entities), making CRUD (create, read, update, delete) available for all of your data.
19 May 2016
Block that button!
David Sleight provides some inside-baseball info about ProPublica's revamped mobile apps, including the yogic contortions required of this non-profit to satisfy Apple.
01 February 2016
Imbrications
Jane Cotler and Evan Sandhaus describe two neat tricks that the New York Times used to bring a recent 20-year block of articles into its TimesMachine service. First, an image tiling and rendering procedure that minimizes download requirements. Even more interesting, a fuzzy-logic string-matching algorithm that lines up a batch of texts taken from OCR with their counterparts from a digital archive. The trick to reducing the search space depends on dividing each text into blocks of overlapping tokens called shingles, a/k/a n-grams.
21 November 2015
Save the tapes
Is your suite of CMSs hooked up to a searchable, durable digital archive? Probably not. Meredith Broussard walks us through a couple of examples.
16 August 2015
Collaborative Topic Modeling
The Times revamps its recommendations engine, allowing for a little serendipity.
15 February 2015
What's new?
Melody Joy Kramer and some of her folks re-imagine how a home for digital news works. My favorite idea from the brainstorming session: News Based on News People Far Away from Me Have Read.
08 July 2014
Compare and contrast
Luke Vnenchak gives us an update on Scoop, the in-house CMS in place at the New York Times. It's really interesting to see how (or even whether) a CMS solves certain problems. Among them:
- Scoop provides for multiple versions of draft/published stories: this blows the doors off CQ5's simple (but effective) author instance/publish instance model.
- Automatic smart cropping of images, given a master and a thumbnail. I've had clients that would love a feature like that.
- Locking body copy independently of assets like images and multimedia. Yep, that's also something that my guys demand.
- Tagging to an open standard: I haven't built any production code to support this, but it's something we have explored. Generally the stumbling block is the question of who owns the tags.
09 January 2014
New suit, new underlayers
Reed Emmons provides some technical details behind the New York Times's recent redesign.
22 February 2012
News item
Evan Sandhaus announces the New York Times's implementation of rNews, a semantic markup scheme for news articles. Curiously, the blog post itself doesn't carry the markup.
24 October 2011
Two for one
With Zach Brand as co-author (and curator of penguin images) (and editing by Kim Bryant and Wright Bryan), I put together a post that describes the team's recent forays into low-impact skunkworks, known as Serendipity Days. Siteworx graciously accepted the material as a cross-post.
11 August 2011
Not many happy campers
Erin Griffith surveys media companies and finds very few of them that are successful with the CMS (content management system) they use—be it open source, proprietary, or purpose-built.
(Link via The Morning News.)
“When you try to build a product that works for everybody, it works for nobody,” a former AOL employee says.
(Link via The Morning News.)
12 January 2011
Close enough
Michael Donohoe describes an update New York Times's Emphasis feature, which enables readers and bloggers to deep link to individual paragraphs within a story.
What's most interesting is the solution that the team devised to automatically assign durable keys to paragraphs of text, in a dynamic news environment when grafs are being added, subtracted, and moved around post-publication.
The matching process uses two means to perform a fuzzy equality match between the key derived from the current story text and the key on the hyperlink. If there is no perfect match, the 3-character partial keys for the first and last sentence are compared, in hopes of a match on either one. In the event that rewriting has changed the text that affects both parts of the keys, the Levenshtein distance between the linking key and the text's key is computed. If it's small enough, it's considered to be a match.
The Levenshtein metric makes perfect sense in this context, because the two keys have moved away from one another precisely because of insertion, deletion, and substitution. Andrew Hedges supplies a web app and JavaScript source for computing Levenshtein distances.
My only qualm with this strategy is that the keys it generates are not evenly distributed. There will be a lot of 3-character partial keys that start with "T" and "A."
What's most interesting is the solution that the team devised to automatically assign durable keys to paragraphs of text, in a dynamic news environment when grafs are being added, subtracted, and moved around post-publication.
Each six-character key refers to a specific paragraph. Keys are generated by breaking a paragraph into sentences. Then, using the first and last sentences (which are sometimes the same), the key-generation code takes the first character from the first three words of each sentence.
* * *
For example, let’s look at this paragraph — the relevant characters for key generation are [set off as code]:
Lastsummer,after 10 years of debate and interagency wrangling, a prestigious committee from the National Academy of Sciences gave highest priority among big space projects in the coming decade to a satellite telescope that would take precise measure of dark energy, as it is known, and also look for planets beyond our solar system.Theproposedproject goes by the slightly unwieldy acronym Wfirst, for Wide-Field Infrared Survey Telescope.
The result is this key:LsaTpp
The matching process uses two means to perform a fuzzy equality match between the key derived from the current story text and the key on the hyperlink. If there is no perfect match, the 3-character partial keys for the first and last sentence are compared, in hopes of a match on either one. In the event that rewriting has changed the text that affects both parts of the keys, the Levenshtein distance between the linking key and the text's key is computed. If it's small enough, it's considered to be a match.
The Levenshtein metric makes perfect sense in this context, because the two keys have moved away from one another precisely because of insertion, deletion, and substitution. Andrew Hedges supplies a web app and JavaScript source for computing Levenshtein distances.
My only qualm with this strategy is that the keys it generates are not evenly distributed. There will be a lot of 3-character partial keys that start with "T" and "A."
Subscribe to:
Posts (Atom)