Why it took a long time to build the tiny link preview on Wikipedia | Hacker News Reader

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

blog.wikimedia.org

677 pointssubset243 comments

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.

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

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!

The extremist view in this sense is that tabs in general are a bad model for navigation. If all the pages you choose to visit are first-level citizens in your environment (windows) then you think about them more actively. A browser like https://surf.suckless.org simplifies the browser abstraction well in these regards. I have found it is nearly impossible to get common browsers to work without tabs. This kind of endeavour probably begets a correct window manager like https://i3wm.org

I strongly agree. I had to stop using Surf because of its ancient rendering engine which butchers a lot of the sensible parts of the modern web, but I do miss the tabless part of it.

Edit: Also because it does not have Pentadactyl. My dream browser would be tabless and with sensible and powerful Vim bindings. Ideally built on an engine of Common Lisp too...

Have you looked at luakit? It's also based on webkit2gtk but it's extensible with Lua; I love the simplicity of suckless tools but when a functionality that seems good must be patched in it rarely ends well.

Also regarding Vi keybindings check out vimb maybe?

SO's hot network questions was so bad that I enabled my ad-blocker on SO and added a custom rule to hide that part of the page. At least now when I go to find an answer on SO without falling in a 30-60 min rabbit hole.

Please post this rule, it would be very helpful.

What’s frustrating is that this has been brought up as an issue on StackExchange and rejected as WONTFIX.

I'm using uBlock origin. The rule is:

  stackoverflow.com###hot-network-questions

I've used the selector tool of uBlock to do it.

Edit: more on this: https://meta.stackexchange.com/questions/222721. Linked in one of the answer is an extension: https://chrome.google.com/webstore/detail/sidebaroverflow/lh...

There are also other solutions on that page.

These rules work for me, using uBlock Origin:

    stackoverflow.com###hot-network-questions
    stackoverflow.com###feed-link

> Like all those workplace drama questions

They're like a soap opera for geeks

Omg, do you remember the milk boiled in electric kettle incident? That's the only time I've seen something get posted to Workplace and then have follow up questions go to (iirc) Interpersonal Skills and then Physics.

Been there. That's why I rarely comment on StackOverflow; it could easily become an addiction, and I can't exactly add it to /etc/hosts like I can other distractions!

Clearly you have too much free time at work ;-)

Just kidding, know how those rabbitholes are.

Back in the day I learned Javascript to create a Firefox extension called budaneki[1] that does basically that. It got quite popular but I abandoned it later since I no longer needed and didn’t have a business model.

Today I’m very happy with the Safari on MacOS as you’re can preview links. I like the Wikipedia implementation a lot, but as a Safari, I’m already used to have it everywhere.

[1] https://addons.mozilla.org/en-US/firefox/addon/budaneki/

<3 message received from //everyone// involved in its creation. Thanks!

As another person with ADHD I've found the Tabs Outliner extension works best for me - it allows you to view tabs in a tree, label/group them, search for tabs, open/close tabs/groups/windows in one go, and most importantly the tree of tabs persists across sessions, so it can be used for bookmarking, suspending, organising and locating tabs depending on your usage - you can export it as HTML, and for a fee you can have it backed up on Google Cloud.

My work tree has somewhere over 500 items and my home one has several times that many, but it's easy to find things and keep them for later :)

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.

Using IE11 with the emulator switched to IE5 I can assure you, it works in IE5. At least the main layout, no popup though :D Still equal parts scary and astonishing.

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 in IE5, lynx, w3m or Netscape Navigator. Really, it's just a webdeveloper's job done right.

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.

Try to read today's Featured Article in a text-to-speech program. The markup is so mangled it can't even read a complete sentence because it breaks anytime the text links out.

JAWS didn't have any issues for me, which reader are you using?

NVDA - aka the "2nd choice" - but I think it may have been a configuration issue on my end as the markup on the page, after looking into why NVDA was struggling with it, is just a <p> with some <a> in it which NVDA should handle fine.

NVDA can be difficult to configure, for sure. I couldn't get it to play nicely with Sublime, probably my fault. Reason I shelled out for JAWS.

Just taking a quick look at the MacOS article posted earlier in this thread, the whole page uses tables exactly as tables should be used: for tables. How do you suppose tables should be implemented?

I've seen plenty of idiotic examples of tables being implemented with a bunch of styled <div>, probably because people keep parroting the idea that tables are bad because table based layouts are bad.

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 because Wikipedia made it so difficult to get the text of an article without non-word entities in it.

[1] https://en.wikipedia.org/wiki/MacOS

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.

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://www.mediawiki.org/wiki/Alternative_parsers

[3] https://www.mediawiki.org/wiki/Parsoid

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.

Can't you use their API? https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_pag...

I haven't used their API in a long time, but I don't think there is a reliable way to get the sidebar that isn't worse than HTML.

For example https://en.wikipedia.org/w/api.php?action=query&prop=revisio...

returns

    {{Infobox website | name = Hacker News | logo = File:hackernews_logo.png | logo_size = 100px | type = [[News aggregator]] | url = {{url|https://news.ycombinator.com/}} | screenshot = File:hn_screenshot.png | registration = Optional | programming_language = [[Arc (programming language)|Arc]] | founder = [[Paul Graham (computer programmer)|Paul Graham]] | launch date = {{start date and age|2007|02|19}} | current status = Online | owner = [[Y Combinator (company)|Y Combinator]] | language = [[English language|English]] }} '''Hacker News''' is a [[social news]] website focusing on [[Computer Science|computer science]] and [[Startup company|entrepreneurship]]. It is run by [[Paul Graham (computer programmer)|Paul Graham]]'s investment fund and startup incubator, [[Y Combinator (company)|Y Combinator]]. In general, content that can be submitted is defined as "anything that gratifies one's intellectual curiosity".<ref>{{cite news | first = Paul | last = Graham | title = Hacker News Guidelines | url = http://ycombinator.com/newsguidelines.html | accessdate = 2009-04-29 }}</ref>

Which isn't very easy to parse either. From a cursory search, a better format doesn't seem possible without using a 3rd party like dbpedia.

https://www.quora.com/Does-the-Wikipedia-API-give-structured...

I tried it for OSX, and it actually just returns a redirect statement to MacOS. So expect your tool consuming the API to break if you don't handle that in advance.

https://en.wikipedia.org/w/api.php?action=query&prop=revisio...

And then when trying it for MacOS, I can't actually find the version info anywhere in the response data. So you couldn't even get that data without scraping the page.

https://en.wikipedia.org/w/api.php?action=query&prop=revisio...

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

If you're just interested in a single value, using the SPARQL endpoint[0] is probably still more simple, since you don't have to filter out deprecated statements, for example.

[0] http://tinyurl.com/ya957wem

I have a lot of goodwill toward wikimedia, but trying to use wiki data made me question my life choices. It doesn’t help that the official API endpoint Times out for anything mildly complicated. (As in a simple aggravation or sorting in the query)

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.

https://en.wikipedia.org/wiki/MacOS has a footnote after the build number. That led me to https://developer.apple.com/news/releases/. I guess that doesn’t do semantic markup, and I didn’t look at the html at all, but it looks like it could provide you what you want fairly easily (likely not 100% reliably if automated, but chances are Wikipedia‘s somehow keeps up to date involves humans, too)

Alternatively, buy a Mac, set it to auto-update, have cron or launchd reboot it reboot it twice a day, and read the version info from the CLI after rebooting (https://coderwall.com/p/4yz8dq/determine-os-x-version-from-t...)

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 <td> whose immediately preceding <td> contains the text "Latest Release", and that's something any XPath-based scraper can give you straight out of the box[1].

A more resilient choice, if you still insist on (or have to use) scraping, is use the underlying template data - a regex is good enough in that case[2]

[1] e.g. http://html-agility-pack.net/ [2] https://en.wikipedia.org/w/index.php?title=Template:Latest_s...

> Even if you insist on scraping, in your case you're just looking for a <td> whose immediately preceding <td> 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 <scrape here>".

https://en.wikipedia.org/w/index.php?title=MacOS&oldid=69769...

And here it is in June 2016 where that sentence was changed to "The latest software version is <scrape here>"

https://en.wikipedia.org/w/index.php?title=MacOS&oldid=72528...

Then around September 2016 it was moved into the sidebar using the template you linked. It looks like that template has been a consistent and reliable element for this since 2012, but then why was it only used in the OSX infobar in middle/late 2016? How else would anyone have known to find it?

And this is just OSX, what if OP wanted a web page that tracked the latest stable release for 20 different OS's? It ends up being pretty frequent maintenance for a small project.

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.

Agreed. It's some mix of the XY problem plus the self-entitlement of "if I had the idea, then it should work."

Yet the classic HNer confuses this for inherent weaknesses in the underlying platform that they then need to share lest someone has something good to say about the platform. And they'll often be using words like "terrible", "garbage", and "I hate..."

Please, no one said Wikipedia was terrible. You're taking statements out of context. The original comment said:

> Wikipedia's markup is just terrible for trying to do any sort of scraping or analysis.

I'd like to emphasize the "for trying to do any sort of scraping or analysis." Should we instead lie and say it's wonderful for scraping?

It's not an insult, it's the truth. If you want to build an app that automatically parses Wikipedia, it will not be easy.

But again, that's the wrong tool for the job so of course it's not going to be well suited. When it's that obvious of a wrong tool saying it's terrible is still kind of silly. It's like saying hammers are terrible at screwing things or cars make terrible trampolines.

> Even if it means having to build your own backend process which polls the websites for the 20 respective OSs individually so you can compile your own API

One caveat there, a page like that for MacOS doesn't exist. Scraping Wikipedia may be insane, but it's often the best option. You can scrape macrumors or something, but then you're still just parsing a site meant to be read by humans. You also still risk those 20 OS websites changing as much as Wikipedia.

Indeed but I was thinking of endpoints that have remained relatively static because they have been auto generated or a history of scraping. Some Linux distros have pages like that (even if it's just a mirror list).

But my preferred solution would be using whatever endpoint the respective platform uses for notifying their users of updates.

This strikes me as a solved problem but even if you can't find a ready to use API then I'd probably sign up to a few mailing lists, update my own endpoint manually and offer 3rd party access for a modest subscription.

Either way, scraping an encyclopedia for an English phrase to parse strikes me as the worst of all the possible solutions.

At the very least, parsing the Release History table seems way better than looking for a particular phrase in the text.

> I can't help feeling like there is a lot of tool blaming happening when the wrong tools were used in the first place.

Well, let's be fair: it's a bit surprising that a series of clear, readable key/value pairs in that Wikipedia "MacOS" infobox table can't be delivered by their API as JSON key/value pairs.

Using their API I can generate a JSON that has a big blob sandwiched in there. With the xmlfm format[1] that same blob has some nice-looking "key = value" pairs, too. Funny enough, those pairs for some reason exclude the "latest release" key.

Anyway, is there any case where a <tr> containing two columns in the Wikipedia infobox table doesn't hold a key/value pair? That just seems like such a valuable source of data to make available in simple JSON format.

[1] https://en.wikipedia.org/w/api.php?action=query&prop=revisio...

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.

I think some of your issues are just inherent to the fact it's a wiki rather than the design of the markup. I mean I could edit the page just now from "Latest release" to "Latest version" or some such - it's just how wikis are.

To me the remarkable part is that Wikipeda stills works great without javascript.

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:

  ! Disable link preview popups on Wikipedia
  en.wikipedia.org##.mwe-popups

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.

For Wikipedia in different languages, just change the subdomain in the filter.

Thank you! I found those things incredibly annoying and useless, and was just about to dig through the source to figure out how to get rid of them.

You can disable them by clicking the little gear icon on the pop up itself. I figured that out by googling aroung for half an hour.

It's just wretched, backwards UI all around.

As OP stated, that's tied to your cookies though and won't be a "permanent" solution.

I would expect the setting to persist if you're logged in but that's probably not something people do on Wikipedia.

I do, but that's only because I edit every once in a while.

A user stylesheet can also be a content blocker, and it doesn't require a third-party extension, and it works across all domains (Wikipedia languages): https://github.com/kengruven/config/blob/master/.calm.css#L2...

It's frustrating that every popular webpage nowadays is so full of distractions that I can't use the web without blocking a lot of it.

Also, they are javascript based. They do not appear when running NoScript set to blockk wikipedia's javascript from executing.

Or log in and click the box in preferences https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsec...

If you want to integrate this into your project: There is a nice API returning the JSON data of the popup

https://stackoverflow.com/a/48527419/4398037

Documentation: https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_pag...

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.

Yeah one of my first web scraping projects was using Wikipedia because I figured it would be easy to parse and have a fairly standard format, right? Well at least it was a good and sobering first lesson about cleaning data.

In UCG gardens — as with data structure and algorithm design — there are trade-offs among retrieval difficulty (friction, for humans; time complexity, for machines), update difficulty, centralization and skill set of contributors, and centralization and skill set of editors, and the complexity of the structures themselves.

IMDB, CYC, Wolfram, and various RDF data sets, sample this space differently, and have different amounts of data and richness, probably as a result.

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.

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.

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?

You're very much not alone, this comes up frequently here at hn, because other sites also frustratingly block this behaviour often by popping up "tweet this" links after highlighting.

At the bottom of every popup there is a cog icon. Clicking the cog icon gives a popup where you can choose to Disable and Enable the feature.

Thanks. I’ll do that!

There should really be some "hover intent" going on if there isn't already and it just needs tweaking maybe?

IIRC the delay value is set at 500ms before a preview is shown.

It seems like the timer starts as soon as the pointer enters the link area. I would be happier if it was 250ms that starts when the pointer stops moving.

Either way I love this feature.

I'd imagine at the scale Wikipedia is operating, they'd have to be sensitive about accessibility features. Some might find it hard to keep the pointer at a compete stop and the 500ms timer seems to do the job pretty well.

The bigger issue in my opinion, at least from the point that it's the wrong behavior 10/10 times, is that these previews pop up when you are just scrolling. Obviously I did not want to read a preview when page under my cursor changes. There should be a check if the cursor had actually moved.

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

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.

That's what I meant, the previews are on by default for not-logged-in users, but appear to be off by default for logged-in users (or at least the preference was set to 'off' for me).

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.

Yeah, they're default-on for logged out users, but default-off for logged-in ones. Was the same for me.

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.

That's easy (much easier than to get to Mars): Download your dump from http://download.kiwix.org/zim/wikipedia/ and extract it with https://github.com/dignifiedquire/zim

Now you have a fully static Wikipedia copy, running wherever you want it to :)

Wikipedia is, by my estimate, to 90% about animals, places, historic places, historic animals, historic people, "notable" living people, and so on. How's that going to be relevant on mars? And who's going to vet all the articles?

Maybe, but those 1% remaining (thousands of articles) about physics, engineering, and so on are a goldmine if you are stranded without anything else.

It would be dumb no to take it as the complete dump is < 1Tb

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.

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.

This was 2 years ago, and read the comments on the 39 votes it took to not release Hovercards - https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28prop...

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.

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.

>And the post seems extremely proud, and self-congratulatory about it.

Well, yeah. Doing anything successfully at the scale of Wikipedia is worthy of some praise - and I say that as a US midwesterner - a culture not exactly known as the epitome of hubris. :)

You might claim I have Stockholm syndrome or something since I worked with the team that developed this feature, but the discussion you highlight did have valid feedback. The process for respecting community governance and developing consensus is more complicated than any one person could imagine. It is frustrating and imperfect. Folks at the foundation like myself are trying to do better in how we approach, work with, and deploy software changes. I agree too that it took a long time to develop, but that's not on any one single community's shoulders.

For instance, after doing due diligence we approached the English community again earlier this month and the result of that discussion was quite boring.

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(miscel...

For a technical example that lead to the time it took, the team looked at how we were generating the previews and saw an opportunity to improve them. Previously we tried to parse a bunch of wikitext with a list as long as my arm of exclusions and edge cases. Then the team figured out a way to return HTML summaries from the source article. Not just something useful for this feature and a huge improvement to how information is rendered (like math formulas). Refactoring the code and implementing a new API endpoint took time.

I hope this doesn't come across as too argumentative, I wanted to provide an alternative perspective from someone who works daily with product teams and communities within the Wikimedia movement.

Thanks for engaging! To clarify my point, I do think that a the process was followed, and it did lead to some good points but if a process is taking 4+ years to launch something relatively simple (compared to what other companies with similar scale and teams might launch), then the process itself is flawed. I'm respectful of your work, but critical of the system that it operates under.

One could argue that Wikipedia has a broader responsibility to the readers than to just the editors, and such a process gives the editors undue weight in the process. The vocal minority cannot always represent the needs of the silent majority and that role would lie with the product team, which in my understanding hasn't been the case at Wikipedia (I say this, and having interviewed and turned down a Wikipedia PM offer and having a few friends worked in Design at Wikipedia and leaving disillusioned).

Wikipedia can exist without readers, but not without editors.

Well 4 years to officially release. It's been available as a beta since 2014 and I've been using it for ages https://lifehacker.com/the-best-wikipedia-features-still-in-...

How many of those readers would know that you have to create an account and then know to turn it on?

None. They don't need to know that. The feature is on by default without logging-in.

This is a great collection of comments! because it exposes a deep bias in the readers, who are mainly coders and dev-culture.

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.

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

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.

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

It's on a computer. It is a database. Are you also upset at people who smash the subtle beauty of music into unfeeling bits?

>It's on a computer. It is a database.

So if I print it out is it not a database anymore?

a strong theme in the comments here is that features and amenities are harder to build upon than .. something .. on WMF web pages because WMF internal content is not rigorously defined and enforced.. print is not the point at all, and would take considerations in yet another direction

not upset -- I am pleased .. many comments expose a naive point of view that I can easily contrast to .. seems fun

“Being on a computer” doesn’t define a database, just as “being a number” doesn’t define math.

What information could you not store in a database?

As the major other php wiki implementor, phpwiki, I can add my input to this.

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.

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.

> mediawiki on the other side is horribly undesigned spaghetti code

But like my mom's spaghetti, it's my favorite. :)

Think you can make it better? https://wikimediafoundation.org/wiki/Work_with_us

I work for the Wikimedia Foundation, but this subtle snark is my own, and may not reflect the views of the Foundation.

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

I don't mean to express dislike or downplay the hard work that went into this feature, just to add some context.

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

My point is that the metric is bad.

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

> If the metric is low, the feature can be safely removed (see: Windows Start menu).

That turned out really well...

Whoever is responsible for putting the touch start screen on Windows Server is responsible for 90% of my frustrations...

The best way to run Windows Server is without a desktop installed, using PowerShell to manage it. Even one-offs. You might know this but it’s worth saying just in case. Also worth noting that some server applications assume/require a desktop during install or operation (usually because they’re trash).

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.

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

If you hadn’t stopped right there, you might have seen the sarcasm in the rest of the post!

I'm case you were curious, WM has done more user testing than just the engagement metrics:

https://m.mediawiki.org/wiki/Special:MyLanguage/Wikimedia_Re...

Not sure what it says about them that they're mentioning worthless numbers instead of the way more useful data they got back during this survey.

But when the feature only needs you to hover over a link to activate (which people do anyway) you have no basis to claim that this is users "liking" the feature - it might just be noise from everyday regular navigation.

i was using wikipedia to with my son yesterday for a project and found it really annoying, so i'm in that list of people who hit the api but aren't in the list of people who seem to be "liking it"

Linked from the article is the final A/B test they ran: https://www.mediawiki.org/wiki/Page_Previews/2017-18_A/B_Tes...

They had better metrics than just number of API requests

Also, is 5K hits/minute really that impressive?

According to https://stats.wikimedia.org/EN/Sitemap.htm , English Wikipedia gets 88K views per minute.

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.

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

I imagine most people spend more time reading on Wikipedia as opposed to trying to hover over every link available?

That's less than one API hit per 17 English pages viewed - the overwhelming majority of the time, users do not use this feature at all, based on these numbers.

This response is pure sophistry.

I wouldn't be surprised if a lot of the pageviews are bots/crawlers. They don't hover over links.

but how many of those views are on mobile devices?

this is a desktop feature. in general, mobile traffic > desktop traffic.

we’d need wikipedia’s browsing statistics be sure, since some sites see different ratios than others. What if 1:8 wikipedia visits are on desktop? That would make the 5K/minute much more significant.

Number was very very very wrong. Actually it's 0.5 million. I've corrected the post.

it's still shown as 5.5k in grafana. what am i missing? the unit is events per minute.

The sample size for those graphs is 1% so you need to multiple that by 100. I personally checked the access logs to check they are consistent. That was where the confusion came from!

Ah, thank you.

I expect you're remembering User:Lupin/popups.js[1], which dates back to August 2005.

It soon became known as Navigation Popups[2], and is still available today.

The main documentation for Page Previews mentions Navigation Popups.[3]

[1]: https://en.wikipedia.org/wiki/User:Lupin/popups.js

[2]: https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_pop...

[3]: https://www.mediawiki.org/wiki/Page_Previews

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.

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

> I also have to wonder how much bandwidth Wikipedia is going to end up using to display unneeded previews.

This is interesting. There's an external arrow for external links, so I'm still good with this use case for inspecting links; for internal links I've found myself hovering where I previously clicked (and loaded) an additional page at least 50% of the time. Where I'm OK with a quick paragraph description and can then decide if the linked paragraph requires / inspires a deeper read, about 50% of the time.

I think this is a net reduction of bandwidth for my personal use-case. Wide A/B testing would reveal more, obviously.

I do mean to express dislike, as I'm one of the millions of users giving Wikipedia a false metric and sense of satisfaction. I've seen the pop-up hundreds of times, and have considered it a hindrance to my process every single time.

Something that just happens accidentally is a bug, no matter how useful it might be if it were not happening accidentally.

You can disable it either from the screen, or if you have an account, permanently from your settings.

I completely agree with this.

When you go from reading the Atlantic, The Economist, The Washington Post... any content site... then begin to read a Wikipedia entry everything you know about reading an article no longer applies. You are now forced to change what you do.

This is just the most basic no no in web design - unplanned interactions, forcing a user to interact, forcing a user to actually think about the interface.

The developers have just forced every person who wants to consume content on Wikipedia to do it differently than on every other content site.

And there are literally countless millions of people who will have no idea how to disable it, who use computers every day but have no idea how to change something.

Just an incredible UX failure.

>Uhm, no. It just means that people are hovering over links with their mouse.

in my case every single time was by accident whilst moving the mouse around, off of other text I was trying to read.

frankly, its bloody annoying

it covered the text i was reading

the search for yet another "disable" setting begins....

The popup has a little gear icon in the bottom right. You can disable it from there.

They put a small click button on the edge of a hover control? really?

I just tested it and it's trivial to click. Are you actually having difficulty or just pretending it's hard so you can be condescending?

I think the best place for these controls are usually on the feature itself. I don't want to have to search in some independent preferences UI every I want to see if something can be tweaked, but it makes sense to offer it there as well.

cheers!

> the search for yet another "disable" setting begins....

Your inability to figure out how to disable it was already counted as success!

> the rates of disabling the feature are negligibly low — a strong indicator that people find it useful.

https://medium.com/freely-sharing-the-sum-of-all-knowledge/w...

> To ensure that these rates were not artificially low due to usability issues, we also confirmed in a separate qualitative test that users were indeed able to find and operate the disable functionality if they desired to disable Page previews. (From their AB article)

“We thought the floating pop-up billboard showing you a preview of what’s inside when you glance at a building was a great feature as you walk down times square”

— bad UX designers in 2070

Hey! (author here)

I sincerely regret the use of that statement "people seem to like it" in my post. I've now removed it as I worry this confuses my message so thank you for pointing it out. This really trivializes all the work that went into A/B testing this and how we measured success. I really recommend a read of https://www.mediawiki.org/wiki/Page_Previews#Success_Metrics... Side note: the volume of traffic was also wrong by several magnitudes... actually 0.5 million)

My main motivation when writing this post was to share how small changes require magnitudes of effort not to express the merits of the feature. As a developer who works with product owners a lot and often get asked how I can build things quicker (I'm sure many can relate). I wanted to provide something useful to other developers that easy looking things are not actually easy to build, so thanks for flagging.

With regards to the user script, yeh that's been around for some time and was the seed for this idea. It's just taken a long time to get that from such a small audience to a mainstream one. It doesn't downplay it in my opinion, just shows how far we've come.

Thanks for reading.

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.

> if possible not in PHP

I'm not a fan of PHP as a language, but given the community has been working with PHP for 16 years, it would be odd to switch suddenly to an entirely new language and expect support and adoption.

The codebase is an absolute nightmare though, and a ground-up rebuild would be great. I wonder though about it having a similar affect to the Wordpress codebase: people who recognise the mess stay away completely, and people who don't contribute, leaving a contributor base who isn't really equipped (or extremely willing) to do a quality, maintainable rewrite.

I suspect any rewrite attempt would be doomed to end up being an unmaintainable behemoth.

A better approach would be to focus on secure integration tools and API entry-points, to make users less entrenched and solely dependent on the MW software.

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

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.

Absolutely agree.

To be honest, it's been like this for a long time. If you haven't noticed the negativity, you've been reading a different "hacker's news" than everyone else on the internet.

To be fair, I've been a regular user under this account for 6 years now, and before that would visit frequently. I know there's always been that component to this place (it's a site publicly available on the web, it's inevitable) but it seems like there has been, maybe just through my perception, a strong rise in the ratio of valid criticism/complaints and seemingly spiteful comments that don't seem to want to accomplish anything other than to incite anger. I have always really appreciated the discussions around here!

It's a very noticeable feature too. I was very delighted to recently discover it, and it really does help Wikipedia to continue to be the revolutionary platform it is. Kudos to those who implemented it.

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 mobile (now approx. half of traffic and growing)?

I see a few comments using the word "hate" but for the most part the negative ones are just critical, with supporting points. I think a fundamental design pattern like this is worth some scrutiny alongside the support.

[1] Case in point: Safari implemented a feature similar to this a few years ago. It works generally across all sites, uses reserved gestures (3D Touch on mobile, 3-finger-tap on desktop) to gives users full control, and sidesteps the whole summarization problem by using more screen real estate to just show a bigger preview.

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 just to spite them.

I think your criticism is a really good one though, especially if these link previews can be harmful towards accessibility/make basic interactions more difficult. Like I mentioned, I enabled a similar beta feature a while back that was a bit difficult to get used to, but I have grown to find indispensable. I think in the same argument, however, you can argue against any sort of hover effects on the web (drop down menus, hover animations, etc.) and to be fair, it would be hard for me to disagree with that point on many instances of that as well.

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

Mobile keeps growing indeed, but around 45% of our pageviews are still on desktop. Here's an overview on how this has changed in the last half decade: https://www.mediawiki.org/wiki/Wikimedia_Audiences#/media/Fi... (I'm the data analyst who has been working on this software feature, and also keeps track of Wikimedia's reader traffic in general.)

Responding to your edit on respectful commenting, I can't see any disrespectful comments in this thread (and generally find discourse on HN better than other places). Have some been deleted?

The top-level comments are mostly positive, with one or two constructively critical ones. There are one or two sub-comments with strongly worded criticism of Wikipedia's markup (the code holding the text), but none that mention people or are in any way ad hominem.

I'm a little confused as well. I skimmed through the comments a second time to see if I missed something but none of the negative comments look especially disrespectful or hateful. Mostly just people complaining that they don't like pop-ups or find the feature useful.

That said, I intentionally try to read text online in the most charitable voice possible, so maybe my perception is very different from others.

Charity in discourse, particularly online, is good policy for everyone[1].

[1] https://en.wikipedia.org/wiki/Principle_of_charity

I am not sure whether or not some have been deleted. When I made the edit earlier I noticed quite a few (some top level, but many secondary). I also usually find discourse on HN really a step above so many other sites I frequent! That's why it's been so disappointing to notice a rise in that kind of behavior for me lately (at least based off of my perception, of course).

Describing the comments here as "an echo chamber of hate" is inaccurate and serves to raise the temperature in itself.

It's inaccurate, it's distracting and it discourages people from contributing with criticism.

It's an appeal to emotion, too.

There are modding tools to make sure people aren't trolling or being too aggressive against other users but discourse shouldn't be censored due to offense.

> We couldn’t expect every single article to be edited to designate a thumbnail.

It wouldn't surprise me if they could. Not to say that automation isn't great, and for this purpose probably ideal.

But, selecting a thumbnail for every Wikipedia article seems like something the community could easily have done.

And what a completely senseless thing it would be. Reminds me of all the random stockphotos in articles wasting bandwidth and attention for no gain.

The 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!

I hate that preview feature. I always hover over links out of habit ready to click if I’m interested. But that pop up blocks me from reading the text.

This is useful feature, but do note for some class of wikipedia surfing this is a net-negative:

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.

Sometimes going down the wiki rabbit-hole is the best form of time-sink.

>"Through our analysis, we wanted to study user behavior towards the Page Previews feature to answer the following questions:
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.

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

https://www.mediawiki.org/wiki/Page_Previews/2017-18_A/B_Tes...

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.

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: https://grafana.wikimedia.org/dashboard/file/varnish-http-er...

The variety of metrics and the sheer volume of those is awesome to explore! (e.g. frequent peaks to 20M requests per minute)

We're very transparent (I work for the Wikimedia Foundation).

You can see the specific dashboard for the Page Preview feature here (Last 6 hours):

https://grafana.wikimedia.org/dashboard/db/eventlogging-sche...

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.

They do say they needed html to provide even a non-broken preview, and I expect the text summary was the most tricky thing to do in any case, just guessing a good picture can't have been too hard.

In any case, they had something 2 years ago but it was blocked by the community for not being good enough.

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 me choose where I want to stop reading, instead of cutting a sentence off at some arbitrary point.

You have to manually highlight phrases, even if it's already hyperlinked together, to force-click them. So I end up never using it.

Wikipedia's is simple. And you can just disable it. Win/win.

> You have to manually highlight phrases, even if it's already hyperlinked together, to force-click them

Huh, that's not the behavior I see with Force Touch. Hyperlinks automatically come together, and there's some sort of heuristic for detecting word clusters such as names or places.

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. This should spread...

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 the hardest 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 :|

Thanks for letting me know about WikiWand.

Came here to say the same thing about Wikiwand.

I've been using it about a year now, and it has radically improved my experience reading Wikipedia.

As you point out, it's had a smoothly working link preview feature all along, as well as a beautiful, usable reading experience. Not flashy or over-designed, just clean and elegant. I get a little caught off-guard now when I see a Wikipedia page without it.

Yup, I have a user stylesheet that limits wikipedia's article width for this reason

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.

https://chrome.google.com/webstore/detail/wikipreview/iioncm...

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.

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 commend Wikipedia for providing a configuration option to disable this feature. Netflix could learn a lot from Wikipedia.

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.

Here's the code: https://github.com/wikimedia/mediawiki-extensions-Popups.

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.

This could have been implemented entirely in the client.

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.

I worry about the impact for accessibility-oriented users.

Wikiwand has had this for years now, and with all the other improvements I still see no reason to not use it.

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

I can't thank you enough for this feature. Great work peeps!

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.

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.

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.

At least you seem to be able to disable them, click the cog in the corner of the card :)

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.

Hate is a pretty strong word and kind of irrational.

Textselection was probably not intended as reading aid, so don't be disappointed if it is abused to actually, you know, select text to do something with it.

I agree, user scripts can be presumptuous and what not. I used to read with text selection the same way, and even reacted repulsed at advertisement hover pop-ups. But somehow I don't do it anymore, so I don't care as much.

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

If the Wikimedia Foundation's goal was to help people, their time and money would be much better spent hiring professional / full-time editors to QC their content. Features like this hovering preview are peripheral to their goal of providing quality content that can also be updated by the general public

As someone who works on the team that built this feature, thank you for saying this.

As for feedback, we've had 4 years of it and welcome more. Check out the FAQ and if you have something constructive to say, leave a note on the talk page.

https://www.mediawiki.org/wiki/Page_Previews#FAQ

You’re welcome.

Have you tried this in a more text based article? I was reading through something lengthy last night and I thought these pop ups were a lifesaver. They're like a TL;DR, you can avoid the context switch of actually clicking through. Sometimes even just the picture was enough to go "oh ok!".

Also personally I'm prone to going down a wikipedia rabbit hole and if last night was any indication, I think these popups will help stop that.

Sounds like you hit an edge case. Personally in that situation of a list of links I would just move the cursor outside the list. For me at least a minor change in behavior in some edge cases is worth what is otherwise a really awesome new feature.

Just want to say I really like the new feature.

Replying from Turkey, and oh boy, I can't even load the Wikipedia website.

... joke, I assume?

:( We miss you! (context: https://ahvalnews.com/freedom-speech/wikipedia-starts-we-mis...)

How do you turn this feature on? I don't have it.

Enable js ?, Or if you are logged, must turn it on

Yak shaving?

I personally always use the mobile version

https://en.m.wikipedia.org/wiki/Main_Page

for desktop these days.

I much prefer it to the standard version.

I hate that I don't have the bar on the left to be able to switch to a different language conveniently. I use it all the time and I've no idea if it's even accessible at all in the mobile version. The mobile version also wastes a ton of screen real-estate but I guess that's fashionable these days.

I really enjoy Wikipedia but the #1 item on my feature wishlist is "redirect me towards the non-mobile version of the site when I click a mobile link on the desktop".

It's at the top of each page - click the icon directly under the article title (on the left) that looks like a Chinese character next to an A.

I'd snip a screenshot, but I'm on mobile...

> I'd snip a screenshot, but I'm on mobile...

If you've got a smart phone chances are you can probably take a screenshot, only hassle then is uploading it somewhere.

Yeah I know, I just didn't feel like going through all that while lying in bed at 4am. In any case I was thinking a cropped one would be better (hence the 'snip') — so here it is in all its desktop-edited glory:

https://i.imgur.com/XQKiEIp.png

Oh! I had never paid attention to this icon. This is going to be useful in the future I'm sure, thank you.

Don't worry, they've also removed the ability to switch to other languages on the normal Wikipedia.

The sidebar shows some major languages (German, Hindi etc), but not the ones I'm trying to learn. Clicking the "more" button then has the most ridiculous UI ever: "Suggested languages"! What is the point of suggesting Yiddish to me?!

What? It will remember what languages you have clicked and put them outside.

This feature is a godsend, I no longer need to scroll hundreds of languages to find the one I need.

Hmm, is that a recent addition? Or perhaps there was a bug.

I can see it sets uls-previous-languages in local storage, but if it had been working like this before today, I'm sure it wouldn't have annoyed me.

If you use the beta version (you should; it typically has useful features), you can swipe in from the right.

If you have a Wikipedia account you can set this theme as your default theme in your account preferences without having to visit the m. domain.

Thank you!

Mind giving a pointer? Would love to default to the mobile view, but haven't been able to find the setting you're referring to. Google hasn't helped.

When you're logged in, it's the "MinervaNeue" option here: https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsec...

Sidenote, if—like me—you actually prefer the desktop theme, and would like the opposite: to use it on mobile. There is a mobile-friendly version of it in the works, but not yet available. You can try the in-progress version on your mobile here: https://test.wikipedia.org/wiki/Main_Page?mobilaction=toggle...

That test mode of the desktop theme is actually live but super hidden away. https://en.m.wikipedia.org/w/index.php?title=Hacker_News&use... I've been trying to add a preference to allow user's to opt into it - https://phabricator.wikimedia.org/T186760 - if you can a token of support there might help this get prioritised.

Thank you! MinervaNeue worked perfectly.

Can I access this API externally, e.g. by sending a http get request to some endpoint, to get the summary content in JSON format?

You can get a similar effect by hitting Wikipedia for its extract. For example: https://en.wikipedia.org/w/api.php?action=query&prop=extract...

Yes you can, there is a nice API returning the Popup-data in JSON

https://stackoverflow.com/a/48527419/4398037

Documentation: https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_pag...

This thing is not exactly customizable.

I couldn't care less for the huge image in the popup layer, scrollability and extra content would be much nicer.

You can switch to the classic Navigation popups gadget,[1] which has a lot more configuration options (including links that shows the history or whole article text in the popup).

https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_pop...

Why 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 imagine it's because they see high readership on desktop browsers.

Just look at the traffic analysis. Mobile browsers have just about eclipsed desktop and they continue to grow.[1]

Mobile support is table stakes for major features these days.

[1] https://analytics.wikimedia.org/dashboards/browsers/#all-sit...

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

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.

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

Exactly the opposite is true. Browser vendors are able to customize the solution to the device and leverage new gestures. Case in point: Safari on desktop (3 finger tap) vs. mobile (3D touch). Even within page content, responsive design techniques can customize it to different devices.

> Also, force touch OSX UI isn't a replacement when you need to manually highlight multi-word selections for it to work.

There is no such thing as force touch on OSX (macOS). And we are talking about hyperlink previews, not selections. It sounds like you're a little confused here.

If you don't see any reason for a feature that benefits better than 50% of your users (according to the chart you posted), I'm really not sure what to tell you.

Reply on news.ycombinator.com