Wikiwand has had this for years now, and with all the other improvements I still see no reason to not use it.
Why it took a long time to build the tiny link preview on Wikipedia
191–200 of 255 posts
Re: Why it took a long time to build the tiny link preview on Wikipedia
#192Why 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.)
I don't get it. Because only a sizable percentage of visits come from desktop browsers instead of most/all of them, then it doesn't make sense to improve things for them? Bizarre reasoning.
You've misrepresented the reasoning. The best practice is: if you're going to tackle a major web UI problem, you should choose an approach that works for mobile (including iPads), which is already about half the traffic to wikipedia and growing. Especially if you are going to invest years of effort.
Calling that reasoning "bizarre" is just being deliberately obtuse.
To wit, some browser vendors have already started recognizing this problem and solving it in a more general, mobile-compatible way.[1][2]
[1] https://appleinsider.com/articles/15/04/28/os-x-tips-preview...
[2] http://www.idownloadblog.com/2016/01/07/8-cool-ways-you-can-...
Re: Why it took a long time to build the tiny link preview on Wikipedia
#193Have to say, I'm pleased they created an algorithm to choose the right thumbnail picture here. So many other inplementations of the same idea just pick the first one on the page, and end up with someone's avatar being the featured image.
Indeed, as much as it took a fair bit of time, it seems the reasons behind it are all fairly logical; they actually thought carefully about the functionality and how it should work in various cases rather than just going with something that was 'good enough' to get it out quickly.
Not going to complain about that.
Re: Why it took a long time to build the tiny link preview on Wikipedia
#194Earlier quoted context omitted.
There's a rule against excessive negativity but respectful, constructive criticism is an important role that HN plays here. Here's a feature that wades into what is arguably browser vendor territory, rethinking the way that hyperlinks work.[1] Is it a good pattern we should adopt throughout the web? Does its on-by-defaut nature disrupt the reading experience? Does summarizing linked content have problems? What about…
Oh, I absolutely agree. I am in no way saying that constructive criticism (or hell, even warranted, non-constructive criticism sometimes) is fine and should be encouraged! The comments I was referring to (many have either been deleted or removed) were quite a bit less focused on constructive criticism than they were on just a barrage of insults towards the team responsible as if this decision was made intentionally j…
My criticism is actually about lack of mobile support. I think it's not a good practice to invest years of effort solving a problem in a way that's fundamentally incompatible with mobile. Already nearly most traffic to wikipedia is mobile, and the share is growing.[1]
Browser vendors seem better positioned to solve this problem. Indeed, my reaction to this was I've been doing this with Safari for years already (3 finger tap on macOS, light or long press on iOS). On wikipedia and all over the web. But I can see why Chrome/Firefox users would love this feature, if this is their first encounter with it.
[1] https://analytics.wikimedia.org/dashboards/browsers/#all-sit...
Re: Why it took a long time to build the tiny link preview on Wikipedia
#195Earlier quoted context omitted.
I'm seeing them in both cases.
Perhaps you had enabled the beta feature and when the feature went to production the setting was kept enabled? Check under Preferences>Appearance>"Reading preferences".
Hmm, that could be it, since it's showing up as enabled for me. I have "Automatically enable all new beta features" on, so I guess I was just betaing this feature for a long time.
Re: Why it took a long time to build the tiny link preview on Wikipedia
#196Earlier 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…
I hit the same thing recently, but that's basically what Wikidata was founded for - and I'm sure it has the latest version of macOS. It's really easy to fetch Wikidata data using the Wikidata API (my example: https://gitlab.com/Flockademic/whereisscihub/blob/master/ind... )
Unfortunately that data isn't granular enough for what I need: I'm looking for the build number, which Wikipedia somehow keeps up to date.
Re: Why it took a long time to build the tiny link preview on Wikipedia
#197Earlier 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…
Have you tried using the mediawiki API [1], or any of the alternatives?[2] I don't know how well they work, but the built-in parser should give you the text without markup. And since they switched to Parsoid [3] to support the Visual Editor, the've polished the wikitext formal specification so all instances of markup have a well-defined structure. [1] https://www.mediawiki.org/wiki/API:Parsing_wikitext [2] https://ww…
I've also had to parse Wikitext. The fact that there are 54 parsers in various states of disrepair listed here (and I have written a 55th) is not because people really like reinventing this wheel; it's because the complete task is absolutely insurmountable, and everyone needs a different piece of it solved.
The moment a template gets involved, the structure of an article is not well-defined. Templates can call MediaWiki built-ins that are implemented in PHP, or extensions that are implemented in Lua. Templates can output more syntax that depends on the surrounding context, kind of like unsafe macros in C. Error-handling is ad-hoc and certain pages depend on the undefined results of error handling. The end result is only defined by the exact pile of code that the site is running.
If you reproduce that exact pile of code... now you can parse Wikitext into HTML that looks like Wikipedia. That's probably not what you needed, and if it was, you could have used a web scraping library.
It's a mess and Visual Editor has not cleaned it up. The problem is that the syntax of Wikitext wasn't designed; like everything else surrounding Wikipedia, it happened by vague consensus.
Re: Why it took a long time to build the tiny link preview on Wikipedia
#198Earlier quoted context omitted.
I don't get it. Because only a sizable percentage of visits come from desktop browsers instead of most/all of them, then it doesn't make sense to improve things for them? Bizarre reasoning.
You've misrepresented the reasoning. The best practice is: if you're going to tackle a major web UI problem, you should choose an approach that works for mobile (including iPads), which is already about half the traffic to wikipedia and growing. Especially if you are going to invest years of effort. Calling that reasoning "bizarre" is just being deliberately obtuse. To wit, some browser vendors have already started r…
That is not a best practice when there are fundamental differences between mouse vs touch.
In fact, trying to smooth over both desktop and mobile experiences with the exact same UI brush is the main reason we're left with the worst of both worlds.
By the way, Facebook also has hover previews on desktop. :)
Also, force touch OSX UI isn't a replacement when you need to manually highlight multi-word selections for it to work. Wikipedia's and Facebook's previews don't require you to do this.
I don't recommend sitting around and hoping browser vendors solve your problems. They're stuck in one-size-fits-all world while you can develop custom solutions for your site and users.
Re: Why it took a long time to build the tiny link preview on Wikipedia
#199Earlier quoted context omitted.
How hard did you try? These are not hand-written pages, and their output is actually pretty clean compared to the crazy things I've tried to scrape. They have tons of APIs to access the backing data, and that should be your first stop. Even if you insist on scraping, in your case you're just looking for a whose immediately preceding contains the text "Latest Release", and that's something any XPath-based scraper can…
> Even if you insist on scraping, in your case you're just looking for a whose immediately preceding contains the text "Latest Release", and that's something any XPath-based scraper can give you straight out of the box Sure, until it changes. Here it is in Jan 2016 when it was included in the opening paragraphs as the text "The latest version of OS X is ". https://en.wikipedia.org/w/index.php?title=MacOS&oldid=69769.…
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 a proper API which cateloges that information. Even if it means having to buikd your own backend process which polls the websites for the 20 respective OSs individually so you can compile your own API.
Using an encyclopedia which is constantly being updated and is written to be read by humans as a stable API for machines is just insanity in my honest opinion.
Re: Why it took a long time to build the tiny link preview on Wikipedia
#200The step ups in API usage over the last year are rather dramatic: https://grafana.wikimedia.org/dashboard/db/reading-web-page-...
We're quite transparent about what we release and when - spikes can be easily attributed to events on https://www.mediawiki.org/wiki/Reading/Web/Release_timeline if you are interested in what caused them!