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

81–90 of 255 posts

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

#81

Post by azeirah »

fapjacks wrote: post #11

That preview window has been a lifesaver. Honestly, as someone with ADD (or ADHD or whatever it's called these days), Wikipedia is a fucking minefield. I regularly have many Wikipedia articles open in sometimes ten or twenty different windows, each with anywhere from twenty to fifty tabs (I open a new window to delineate a completely new tangent, or if opening a new tab will cause the tab icons to disappear, otherwis…

Wikipedia's a minefield for people with ADD, yep.

But oddly enough, I found that Stackoverflow's "hot questions" or whatever thing is equally distracting.

I'm on a professional software developer network, and then I see a super interesting and legitimate question aaaaaannnddd... I'm in a rabbithole.

Don't know if it's helpful or not for you, but I found an extension that limits the maximum amount of tabs you can have open at a given moment, I set it to 3-4, it forces me to decide what link I do or do not want to click on. Makes me conscious of my unconscious browsing habits, might be useful for you too: https://addons.mozilla.org/en-US/firefox/addon/max-tabs-web-...

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

#82

Post by maxerickson »

saagarjha wrote: post #19
shakna wrote: post #9

I am continually impressed by the markup Wikipedia generates. They've managed to pull in pretty link previews, scientific notation and a grid layout, whilst building a highly nested markup structure? The remarkable part? Wikipedia works great inside a text browser like elinks. It works great in a modern browser. Without sacrificing the interactivity people have grown to expect.

Wikipedia's markup is just terrible for trying to do any sort of scraping or analysis. I once tried to write a script that pulled the latest version of macOS from the sidebar of this article[1] and I gave up because it was difficult and brittle in a way that made it nearly impossible. I'd probably have better results parsing the HTML with a regex. Likewise, I know a friend who literally had to scrap an entire project…

The grand vision seems to be that you would retrieve it from Wikidata (https://www.wikidata.org/wiki/Q14116 ).

Of course that is out of date and not in sync with the Wikipedia article. But there's public query services you can use to fetch stuff from there, you wouldn't need to parse html.

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

#83

Post by nkozyra »

majewsky wrote: post #66
foota wrote: post #28

Earlier quoted context omitted.

I'm thinking it has to be heavily cached.

"5000 hits to our API per minute" does not say anything about whether they're measuring in front of or behind the cache. For all intents and purposes, the cache's endpoint is the API endpoint.

And uncached hits only would be an even more worthless metric.

I, too, think either that number is wrong or this wasn't a feature available to all users.

I also agree that using this metric as affirmation the feature is liked is dangerous; count me among the many here inadvertantly contributing without enjoying the feature.

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

#84

Post by mezzode »

I opted into the beta for this way back and have been using it for ages, it was pretty surprising finding out it only just went into wide release. Given how useful I found it I'd have thought it would have been released pretty quickly even when not perfect, but given the results can't complain. https://blog.wikimedia.org/2014/03/26/Hovercards-now-availab...

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

#85

Post by mavidser »

johnchristopher wrote: post #2

I remember seeing those preview for weeks (months) but the article publication date is 20th of April. It's pretty cool :).

I too was surprised by the date, given that I've been using it for the past year, at least, or more.

Apparently, it went into beta in 2014[1].

[1]: https://blog.wikimedia.org/2014/03/26/Hovercards-now-availab...

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

#86

Post by worble »

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 :)

And what exactly is not "done right" about that? If it displays the information it's supposed to in a clean and organised way, and loads as fast as any other website, then I couldn't care less if it's a '90's table layout' or using whatever the hot new JS framework is.

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

#87

Post by chiefalchemist »

mappu wrote: post #32
panic wrote: post #23

Earlier quoted context omitted.

> Uhm, no. It just means that people are hovering over links with their mouse. It does not imply any opinion about the previews. When you evaluate features using engagement metrics, there are only two possibilities. If the metric is high, users love the feature. If the metric is low, users don't know the feature exists, and more alerts or "unread" badges must be added to help them learn.

Alternatively, if it's a feature you don't like: If the metric is high, users are spending too much time on it. Also, it is responsible for every single frustration that users have with your product. If the metric is low, the feature can be safely removed (see: Windows Start menu).

Yeah. Time on site, for example, might mean they can't find what they need; as opposed to getting what they need and staying for more.

Numbers are helpful, but sometimes they can be misinterpreted to mask the why.

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

#88

Post by tuukkah »

Crontab wrote: post #62
majewsky wrote: post #8

> People seem to like it — we are seeing 5,000 hits to our API a minute to serve those cards that show when you hover over any link. Uhm, no. It just means that people are hovering over links with their mouse. It does not imply any opinion about the previews. > The original idea was conceived four years ago When I was active at Wikipedia/Wikibooks 12 years ago, there was a user script floating around that did the sam…

I personally do not care for the link preview feature as I am one of those people who like to hover over a link so I can see the url leads (which is also why I detest URL shorteners). I also have to wonder how much bandwidth Wikipedia is going to end up using to display unneeded previews.

> I personally do not care for the link preview feature as I am one of those people who like to hover over a link so I can see the url leads

But that's exactly what these preview popups are for! A bit heavier than the plain URL, but much more useful and friendlier.

(EDIT: I see there's a bug in that it displays the preview even if you don't stop the mouse there. Still, this can be lighter than requiring people to click through to the full articles, considering the preview can tell you what you need or that the link is not relevant for you, and slows you going down the rabbit hole to more links. Maybe it should be located at the bottom of the screen like the plain URL popup though?)

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

#89

Post by fapjacks »

azeirah wrote: post #81
fapjacks wrote: post #11

That preview window has been a lifesaver. Honestly, as someone with ADD (or ADHD or whatever it's called these days), Wikipedia is a fucking minefield. I regularly have many Wikipedia articles open in sometimes ten or twenty different windows, each with anywhere from twenty to fifty tabs (I open a new window to delineate a completely new tangent, or if opening a new tab will cause the tab icons to disappear, otherwis…

Wikipedia's a minefield for people with ADD, yep. But oddly enough, I found that Stackoverflow's "hot questions" or whatever thing is equally distracting. I'm on a professional software developer network, and then I see a super interesting and legitimate question aaaaaannnddd... I'm in a rabbithole. Don't know if it's helpful or not for you, but I found an extension that limits the maximum amount of tabs you can have…

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 things from exploding down the line. Thanks!
Post reply on HN