> 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.
Why it took a long time to build the tiny link preview on Wikipedia
31–40 of 255 posts
Re: Why it took a long time to build the tiny link preview on Wikipedia
#32> 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.
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
#33Earlier 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.
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
#34I 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 :)
Re: Why it took a long time to build the tiny link preview on Wikipedia
#35> 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.
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
#36I 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.
I see these even when logged out.
Re: Why it took a long time to build the tiny link preview on Wikipedia
#37Wow. 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).
Re: Why it took a long time to build the tiny link preview on Wikipedia
#38Wow. 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'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> 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…