Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why it took a long time to build the tiny link preview on Wikipedia

blog.wikimedia.org

Post reply on HN
Print view View original

231–240 of 255 posts

Re: Why it took a long time to build the tiny link preview on Wikipedia

#231

Post by tim333 »

anotherfounder wrote: post #176

I feel like this is some dystopian alternate reality post. It took 4 years to release a hover popup! Take that in for a second. And the post seems extremely proud, and self-congratulatory about it. From the post: > Our initial version wasn’t good enough. Our community asked us not to go ahead with it. We answered by listening to them and making it better. This was 2 years ago, and read the comments on the 39 votes it…

Well 4 years to officially release. It's been available as a beta since 2014 and I've been using it for ages https://lifehacker.com/the-best-wikipedia-features-still-in-...

Re: Why it took a long time to build the tiny link preview on Wikipedia

#232

Post by failrate »

icc97 wrote: post #132
fapjacks wrote: post #89

Earlier quoted context omitted.

Oh, yes, SO's hot network questions is a hardcore distraction for me, too. Even for things I really don't care about! Like all those workplace drama questions (do so many people really think going to HR is going to do them any good at all?). The extension you linked is a very interesting concept, something I hadn't thought about using before. But I like the idea of paying a little bit of thought up front to help keep…

> Like all those workplace drama questions They're like a soap opera for geeks

Omg, do you remember the milk boiled in electric kettle incident? That's the only time I've seen something get posted to Workplace and then have follow up questions go to (iirc) Interpersonal Skills and then Physics.

Re: Why it took a long time to build the tiny link preview on Wikipedia

#233

Post by shakna »

Nadya wrote: post #226
shakna wrote: post #204

Earlier quoted context omitted.

JAWS didn't have any issues for me, which reader are you using?

NVDA - aka the "2nd choice" - but I think it may have been a configuration issue on my end as the markup on the page, after looking into why NVDA was struggling with it, is just a with some in it which NVDA should handle fine.

NVDA can be difficult to configure, for sure. I couldn't get it to play nicely with Sublime, probably my fault. Reason I shelled out for JAWS.

Re: Why it took a long time to build the tiny link preview on Wikipedia

#234

Post by PhasmaFelis »

abalone wrote: post #137

Why so much effort on a feature that doesn’t and probably can’t work on mobile? Were they happy enough with Safari’s 3D Touch preview which does more or less exactly this? (Only with a full screen preview so they don’t have to get into the messy business of summarizing pages.)

If you don't see any reason for a feature that benefits better than 50% of your users (according to the chart you posted), I'm really not sure what to tell you.

Re: Why it took a long time to build the tiny link preview on Wikipedia

#235

Post by laumars »

squeaky-clean wrote: post #215
always_good wrote: post #201

Earlier quoted context omitted.

Agreed. It's some mix of the XY problem plus the self-entitlement of "if I had the idea, then it should work." Yet the classic HNer confuses this for inherent weaknesses in the underlying platform that they then need to share lest someone has something good to say about the platform. And they'll often be using words like "terrible", "garbage", and "I hate..."

Please, no one said Wikipedia was terrible. You're taking statements out of context. The original comment said: > Wikipedia's markup is just terrible for trying to do any sort of scraping or analysis. I'd like to emphasize the "for trying to do any sort of scraping or analysis." Should we instead lie and say it's wonderful for scraping? It's not an insult, it's the truth. If you want to build an app that automaticall…

But again, that's the wrong tool for the job so of course it's not going to be well suited. When it's that obvious of a wrong tool saying it's terrible is still kind of silly. It's like saying hammers are terrible at screwing things or cars make terrible trampolines.

Re: Why it took a long time to build the tiny link preview on Wikipedia

#236

Post by tim333 »

tombrossman wrote: post #97

One of the best things about ad blockers is that they are really just general purpose content blockers. Want to disable this permanently? Here's an Adblock Plus-compatible filter to block the div if you find it annoying. Tested and working on uBlock Origin: ! Disable link preview popups on Wikipedia en.wikipedia.org##.mwe-popups It's just a div with the class ".mwe-popups", and using your ad blocker will persist the…

Or log in and click the box in preferences https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsec...

Re: Why it took a long time to build the tiny link preview on Wikipedia

#237

Post by laumars »

squeaky-clean wrote: post #213
laumars wrote: post #199

Earlier quoted context omitted.

I can't help feeling like there is a lot of tool blaming happening when the wrong tools were used in the first place. Wikipedia is pretty easy to scrape general blocks of text (I'm the author of an IRC bot which did link previewing, inc Wikipedia) but if you need specific, machine readable, passages which aren't going to change sentence structure over the years then you really should be getting that information from…

> Even if it means having to build your own backend process which polls the websites for the 20 respective OSs individually so you can compile your own API One caveat there, a page like that for MacOS doesn't exist. Scraping Wikipedia may be insane, but it's often the best option. You can scrape macrumors or something, but then you're still just parsing a site meant to be read by humans. You also still risk those 20…

Indeed but I was thinking of endpoints that have remained relatively static because they have been auto generated or a history of scraping. Some Linux distros have pages like that (even if it's just a mirror list).

But my preferred solution would be using whatever endpoint the respective platform uses for notifying their users of updates.

This strikes me as a solved problem but even if you can't find a ready to use API then I'd probably sign up to a few mailing lists, update my own endpoint manually and offer 3rd party access for a modest subscription.

Either way, scraping an encyclopedia for an English phrase to parse strikes me as the worst of all the possible solutions.

Re: Why it took a long time to build the tiny link preview on Wikipedia

#238

Post by saagarjha »

always_good wrote: post #180
saagarjha wrote: post #22

I think I have these turned off, since in Safari I can Force Touch on links to preview them in a similar fashion. This has the benefit of letting me choose where I want to stop reading, instead of cutting a sentence off at some arbitrary point.

You have to manually highlight phrases, even if it's already hyperlinked together, to force-click them. So I end up never using it. Wikipedia's is simple. And you can just disable it. Win/win.

> You have to manually highlight phrases, even if it's already hyperlinked together, to force-click them

Huh, that's not the behavior I see with Force Touch. Hyperlinks automatically come together, and there's some sort of heuristic for detecting word clusters such as names or places.

Re: Why it took a long time to build the tiny link preview on Wikipedia

#239

Post by kqr »

jgtrosh wrote: post #103
fapjacks wrote: post #89

Earlier quoted context omitted.

Oh, yes, SO's hot network questions is a hardcore distraction for me, too. Even for things I really don't care about! Like all those workplace drama questions (do so many people really think going to HR is going to do them any good at all?). The extension you linked is a very interesting concept, something I hadn't thought about using before. But I like the idea of paying a little bit of thought up front to help keep…

The extremist view in this sense is that tabs in general are a bad model for navigation. If all the pages you choose to visit are first-level citizens in your environment (windows) then you think about them more actively. A browser like https://surf.suckless.org simplifies the browser abstraction well in these regards. I have found it is nearly impossible to get common browsers to work without tabs. This kind of ende…

I strongly agree. I had to stop using Surf because of its ancient rendering engine which butchers a lot of the sensible parts of the modern web, but I do miss the tabless part of it.

Edit: Also because it does not have Pentadactyl. My dream browser would be tabless and with sensible and powerful Vim bindings. Ideally built on an engine of Common Lisp too...

Re: Why it took a long time to build the tiny link preview on Wikipedia

#240

Post by boomlinde »

xab9 wrote: post #78
seba_dos1 wrote: post #55

Earlier quoted context omitted.

Wikipedia is a content-heavy website first, webapp only second. If it's written correctly, then of course it's going to work in IE5 - maybe with some parts of the layout looking ugly, maybe with some margins being wrong, some media not being embedded, but generally should be usable. Nowadays it's fine for a webdev to not test their pages on IE5, but when the page is done right, there is no reason for it not to work i…

Nope, it's not "done right". It's a table layout from the nineties. But probably there's an api so noone would have to scrape a wiki page, I never needed to do that fortunately :)

Just taking a quick look at the MacOS article posted earlier in this thread, the whole page uses tables exactly as tables should be used: for tables. How do you suppose tables should be implemented?

I've seen plenty of idiotic examples of tables being implemented with a bunch of styled , probably because people keep parroting the idea that tables are bad because table based layouts are bad.

Post reply on HN