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, otherwise I open a new tab in the current window -- I like tabs and make heavy use of Session Buddy and The Great Suspender). The preview window has really cut a lot of the extraneous BS out of my evening-destroying rabbit holes. I figured it was probably a difficult thing to develop, but if anyone involved with its creation passes by this lowly post, please know that you have my sincerest gratitude for making such a meaningful, useful tool.
I am continually impressed by the markup Wikipedia generates.<p>They've managed to pull in pretty link previews, scientific notation and a grid layout, whilst building a highly nested markup structure?<p>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.
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:<p><pre><code> ! Disable link preview popups on Wikipedia
en.wikipedia.org##.mwe-popups
</code></pre>
It's just a div with the class ".mwe-popups", and using your ad blocker will persist the change after clearing cookies, which the preference setting (mentioned elsewhere here) does not.<p>For Wikipedia in different languages, just change the subdomain in the filter.
If you want to integrate this into your project: There is a nice API returning the JSON data of the popup<p><a href="https://stackoverflow.com/a/48527419/4398037" rel="nofollow">https://stackoverflow.com/a/48527419/4398037</a><p>Documentation: <a href="https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_page_summary_title" rel="nofollow">https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_pag...</a>
Not to criticize the hard work that went into doing this feature (I worked on a project using wikipedia/wiktionary data), all the things that had to be achieved to come up with a "simple" preview features are just made hard because the data in wiki media is not machine friendly. Things like the obvious priority order of fields and bizarre templates that one needs to implement to parse the data makes the job unbelievably hard in the first place.
Have 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.<p>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.<p>Not going to complain about that.
One downside is that when I move the cursor along while reading an article all sorts of links now pop up at me. What I mean is using the mouse or trackpad to keep my place in the article; sometimes I drag the cursor to highlight the text, especially when skimming. Surely I'm not the only one who does this?
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.
<a href="https://blog.wikimedia.org/2014/03/26/Hovercards-now-available-as-a-beta-feature-on-all-wikimedia-wikis/" rel="nofollow">https://blog.wikimedia.org/2014/03/26/Hovercards-now-availab...</a>
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.<p>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.
When we do finally send people to Mars I think they'll appreciate having a local copy of Wikipedia with them. This would be one of the top 10 resources beyond what's required to produce air, food, water, and heat. Otherwise, something comes up and any question you have could take almost an hour to get a response from someone on earth.
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.<p>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.<p>This was 2 years ago, and read the comments on the 39 votes it took to not release Hovercards - <a href="https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive_131#Proposal:_Enable_Hovercards_by_default" rel="nofollow">https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28prop...</a><p>This meant that the silent majority didn't get these features for 2 years because some considered it 'intrusive'. A feature that you could objectively argue as being a useful utility.<p>If anything, I think this is an indictment of the complaints against Wikipedia from those observing it and ex-employees. While a benevolent dictatorship might be going too far, such a community process where only the loudest voice wins (over considering what is best for MOST of the users), is surely a broken process. I am surprised that product & design people work there at all in such an environment.
This is a great collection of comments! because it exposes a deep bias in the readers, who are mainly coders and dev-culture.<p>Guess what ? perfectly machine-readable data is called a DATABASE, and it works well in its scope.. and if you think that all of human knowledge, history, arts and culture are perfectly represented in a DATABASE, then congratulations, you are already more computer than human in your preconceptions.<p>There are several important layers to this onion.. lets call one "participation by non-specialists" .. a second "human factors, aesthetics and publishing arts" .. another is "imperfect intermediate products enable evolution" .. yet another is "taking rules before content" ..<p>Each topic might be an essay in itself.. Generally, I am happy to see XML essentially proposed as the answer to all human information challenges, because it takes less time to blink than to refute it, for me.
As the major other php wiki implementor, phpwiki, I can add my input to this.<p>I've implemented such an ajax page preview and also a page inliner (for expanding page trees via ajax) about 10 years ago. It was major work, because you essentially send a stripped down page in xml, so it needed some architectural changes to separate the various page templates properly.
In the end it needed 2 months work. phpwiki has a proper template design and its plugins cannot ever destroy a page layout or harm security.<p>mediawiki on the other side is horribly undesigned spaghetti code, with no proper templating and plugin integration, so it needed a few years more. It's like parsing html with regexp.
> 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.<p>Uhm, no. It just means that people are hovering over links with their mouse. It does not imply any opinion about the previews.<p>> The original idea was conceived four years ago<p>When I was active at Wikipedia/Wikibooks 12 years ago, there was a user script floating around that did the same thing, except I'm not sure if it included an image. (Mediawiki allows a user to define custom CSS and JS that get embedded in every page of their user session.)<p>I don't mean to express dislike or downplay the hard work that went into this feature, just to add some context.
Not to mention another probable reason: Mediawiki's codebase is a mess and should be rebuilt from the ground up, if possible not in PHP. I once had to build an extension for it and it still gives me the creeps.
There's a lot of negativity in these comments (which is to be expected, as it is still HN after all) but I've been using the preview boxes for a while now and have to say that I absolutely love them. I use Wikipedia a LOT for primative/secondary research and being able to even just figure out the dates someone lived, the very basic information, or even sometimes just a photo saves me from so many instances of new-tab opening of links that I have to remember the context of after I'm done reading the passage. Really happy to see this is more available now<p>EDIT: This is unrelated, but after reading more of the comments, I legitimately can't believe how absolutely disrespectful and hateful so many of these comments are in here. I appreciate this site as a place where you can express your opinions, even if they aren't just placid support of whoever the OP is, but I really don't want to see this community dive further and further into the echo chamber of hate that it seems to be becoming.
> We couldn’t expect every single article to be edited to designate a thumbnail.<p>It wouldn't surprise me if they could. Not to say that automation isn't great, and for this purpose probably ideal.<p>But, selecting a thumbnail for every Wikipedia article seems like something the community could easily have done.
The step ups in API usage over the last year are rather dramatic:<p><a href="https://grafana.wikimedia.org/dashboard/db/reading-web-page-previews?orgId=1&panelId=2&fullscreen&from=1480245159889&to=1524481960401" rel="nofollow">https://grafana.wikimedia.org/dashboard/db/reading-web-page-...</a>
This is useful feature, but do note for some class of wikipedia surfing this is a net-negative:<p>For the case when I came across a subject I knew not a lot about I would keep queuing them up, leading to an array of pages I'd read about a topic, leading to a deeper understanding about the topic/domain. With this feature, the probability that a page would be queued up would go down.<p>Sometimes going down the wiki rabbit-hole is the best form of time-sink.
><i>"Through our analysis, we wanted to study user behavior towards the Page Previews feature to answer the following questions:<p>How often do people use the feature to preview other pages? We set a threshold of 1000ms (one second) for a preview card to stay open before we counted it as viewed.<p>How often do people disable the feature? It can be disabled by clicking on a settings icon at the bottom of each preview. A high rate in disabling Page Previews would indicate that this is not a feature users want. A low rate indicates users like the feature and would continue using it."</i><p><a href="https://www.mediawiki.org/wiki/Page_Previews/2017-18_A/B_Tests" rel="nofollow">https://www.mediawiki.org/wiki/Page_Previews/2017-18_A/B_Tes...</a><p>My experience was that suddenly something popped up over what I was trying to read so I was confused for a moment (hitting the first metric), but I did not notice the settings icon or expect I would be able to so easily turn these off (thus not hitting the second metric). After reading this I did turn it off.<p>I am definitely not at all a fan of this feature yet would be counted as positive by two different metrics.
Learned from this article that they make their Grafana dashboards public: <a href="https://grafana.wikimedia.org/dashboard/file/varnish-http-errors.json?from=now-12h&to=now" rel="nofollow">https://grafana.wikimedia.org/dashboard/file/varnish-http-er...</a><p>The variety of metrics and the sheer volume of those is awesome to explore! (e.g. frequent peaks to 20M requests per minute)
Or they could have started with an MVP without thumbnails and html and improved it over time, would have been more valuable then having no preview at all.
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 <i>me</i> choose where I want to stop reading, instead of cutting a sentence off at some arbitrary point.
Those summaries are a -big win-. Just hovering over an unfamiliar term gives you enough to get the gist. Greatly improves the value of the hyperlinks, without any injury to their utility if you want more. <i>This should spread...</i>
TL;DR: they had to choose a thumbnail and summary. I have been using WikiWand for years, which not only did that but also makes reading Wikipedia much better. Maybe I'm the only one but I have <i>the hardest</i> time reading paragraphs with lots of words per line. Previously I had to resize the browser each time I had to read something in Wikipedia :|
I wrote this as one of my first HTML/JavaScript projects. It’s far from perfect, but it served me well for 4 years. It was not difficult to make and uses MediaWikis existing APIs.<p><a href="https://chrome.google.com/webstore/detail/wikipreview/iioncmbmegjiadkijjkmockilogpplhg" rel="nofollow">https://chrome.google.com/webstore/detail/wikipreview/iioncm...</a>
They sunk four years of time into this, with developers, UI people, A/B testing... all of it. So they could have thumbnails when you hover over links. And they can't pay the people actually writing the encyclopedia.<p>I hate our current web sometimes. The only skill it seems to know how to reward is writing code. 99% of the value of Wikipedia has nothing to do with code at all. Yet nobody gets rewarded for that.
I know some people don't appreciate it, but I really liked the preview. I feel it lets you get the gist of ancillary topics so you can understand the main article better, without having to switch contexts completely.
I discovered the feature by mistake, and I thought it was cool. I usually browse Wikipedia on my phone, so I don't know if I'd still think it was cool if there are constant false positives on it.
I dislike the "popup" UI metaphor, where some content obscures other content from view. I also dislike when passive action such as "hover" causes stuff to jump around the screen. I think these are distracting and confusing. It makes me cautious for where can I "rest" my mouse on the screen.<p>I worry about the impact for accessibility-oriented users.
This is great actually! Thanks a lot for implementing a quick preview feature, perfect for reading an article in one sitting without getting distrcted with side tabs.
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.<p>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 underlying page.<p>Thanks an awful lot for breaking the ability to use the site as I am used to and making it impossible to scan with the curser as anchor for my eyes.
I personally always use the mobile version<p><a href="https://en.m.wikipedia.org/wiki/Main_Page" rel="nofollow">https://en.m.wikipedia.org/wiki/Main_Page</a><p>for desktop these days.<p>I much prefer it to the standard version.
This thing is not exactly customizable.<p>I couldn't care less for the huge image in the popup layer, scrollability and extra content would be much nicer.
Why so much effort on a feature that doesn’t and probably can’t work on mobile?<p>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.)