51–56 of 56 posts
Pretty good. Did they do an analysis of the NYT archives to ensure that their First Three Words Last Three Words technique is "good enough"?
I think v2 is trying to solve a problem it shouldn't have to solve. If the NYT made available previous (published!) revisions of their content, there would be no need to assign paragraphs with special IDs or the like. You'd simply say, "get me p2 for the story as it was on Jan 11 15:33". When you link to a specific piece of content, it's in the hopes that people will read or see the same thing you saw when you made t…
But is that going to happen? No. Why? Many reasons come from an editorial perspective (which I'm not knowledgeable enough to get into - but a simple one is: corrections), however the big one is also technical:
Providing previous revisions is not trivial feature. It would be a huge effort. There is no way to justify it from the perspective of deep-linking.
Earlier quoted context omitted.
RTFM? :) The difference is no 'href' tags. The 'tag' is automatically created based on the words in the paragraph, via Javascript, and decoded appropriately. It is also slightly neat in that you can highlight a specific sentence (multiple sentences actually, see the little tutorial at the bottom). I actually kind of like it, it would be a neat way to really highlight what you think is interesting in an article when s…
Highlighting is neat; but concerning deep linking, the parent has a point: since the NYT controls the source, why not simply generate anchors for each paragraph? The upside would be that there would be much less work needed to find edited paragraphs: a paragraph would be identified by its anchor and it could be changed completely, as long as the anchor is still there the link's fine. This approach has certainly been…
There would have been deep-linking on the site years ago if it were not such a big undertaking. It had been on my own wish-list for many years but nothing something I decided to do my self actively until I met Kellan at OSCON in 2006(?) and he brought it up too.
Since then, a colleague of mine, Eitan and I started digging into the CMS side, as well as looking at some highly optimized code that outputs the article body. A combination of development time, risk, resources, and testing didn't justify the result - especially since we were trying this on our own time.
There more to it than that. But thats the main point.
Earlier quoted context omitted.
I would add a convenient way for this to interact with already existing hashed links that are used for navigation. Rather than the #p[...],h[...] how about #p=...&h=...? EDIT: Or even #deeplink=p[...],h[...]
Its a fair point, and there were a number of ways it could have been done. Given that there could be a long number of paramaters included for Highlighting I felt the [] gave a sense of belonging. I like the #deeplink suggestion too, but in the end being as concise as possible was a factor.
I played around with this and got it so you can both highlight and have it move the view to the paragraph of choice. Seems pretty interesting. An issue with it though, when sending the link to someone, and then they click it, browsers (Chrome here) turn the #h[TArTWw,1] into #h%5BTArTWw,1%5D which then seems to be ignored by the script.
I noticed that just now too. I'll investigate and see if I can get a fix in the next update.
I think v2 is trying to solve a problem it shouldn't have to solve. If the NYT made available previous (published!) revisions of their content, there would be no need to assign paragraphs with special IDs or the like. You'd simply say, "get me p2 for the story as it was on Jan 11 15:33". When you link to a specific piece of content, it's in the hopes that people will read or see the same thing you saw when you made t…