Live data from Hacker News

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

blog.wikimedia.org

31–40 of 255 posts

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

#31
post #24
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…

Also, is 5K hits/minute really that impressive? According to https://stats.wikimedia.org/EN/Sitemap.htm , English Wikipedia gets 88K views per minute.

That was also my first reaction, but I did not mention it because judging this (in relation to pageviews) would require more knowledge about the audience, e.g. how many users are using a mouse at all (vs. a touch screen, or pure keyboard navigation).

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

#32
post #23
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…

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

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

#33
post #27

Earlier quoted context omitted.

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…

Oh, I know. The markup is incomprehensible, but not to a render engine. It doesn't even seem to impact loading speed. It generates amazing machine-text. As for scraping... Parsing the hell that is wikitext is all you can do. Or apparently, pipe it through a text browser.

> pipe it through a text browser

That's an interesting idea, and one that I hadn't thought of, but I'd place it closer to matching HTML with regex than actual "parsing". I might use it if I'm really desperate though.

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

#34
post #15
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.

Last time I checked, their markup was pretty much nightmare fuel, but it should work fine with IE5, I'm sure :)

It works well for the latest (and last) version of IE, at least.

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

#35
post #23
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…

> 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.

> When you evaluate features using engagement metrics

No-no-no. Stop right there. "Engagement metrics" are the worst kind of metrics. Engagement means next to nothing. It just means that a user interacted with something. Was it good? Was it bad? Was it intentional? Was it by mistake? "Engagement metrics" answer none of that.

And yet... They are the easiest metrics to collect and too many companies use them as if they were meaningful.

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

#36

I had no idea what this was talking about, and it appears to be because they've defaulted it to off for existing logged-in users. Maybe that's a way of reducing pushback. In case you want to turn it on (or off), it's under Preferences->Appearance->Page previews. I think I'll probably leave it off personally. I like the previews that have already existed for a while in the mobile app, but on desktop not so sure.

> they've defaulted it to off for existing logged-in users

I see these even when logged out.

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

#37

Wow. Had just read that and then saw the feature first time while browsing over a list page. Was moving my curser down the list and when ever I wanted to click a link, the above link hat popped up the layer, highjacking my click and leading me to the wrong page. What a great way of destroying the user experience with a beautifully over-engineered feature that is utterly crap while actually trying to use the underlyin…

I have a habit to select some text in a page when I'm reading it. And I hate websites that trying to immediately interact with me when I'm selecting a text (usually it's "fix a typo" or something similar).

Same here. I hate even more website where you can't select the text.

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

#38

Wow. Had just read that and then saw the feature first time while browsing over a list page. Was moving my curser down the list and when ever I wanted to click a link, the above link hat popped up the layer, highjacking my click and leading me to the wrong page. What a great way of destroying the user experience with a beautifully over-engineered feature that is utterly crap while actually trying to use the underlyin…

"a [...] over-engineered feature that is utterly crap"

I'm not usually trying to police this kind of thing, but is there a way you could have phrased this without discrediting the work of a lot of people whose goal is to help others? I'm sure you'd get both a little bit hurt inside and defensive when someone in your team calls your code "utterly crap."

That said, I'm very sure they will be happy to hear about your feedback.

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

#39
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…

As far as I know the Lupin user-script was the foundation of the PagePreview feature. I guess the Reading group at WikiMedia rewrote the extension as part of MediaWiki core and tried to fix most edge cases on the way.
Post reply on HN