
Why it took a long time to build the tiny link preview on Wikipedia - subset
https://blog.wikimedia.org/2018/04/20/why-it-took-a-long-time-to-build-that-tiny-link-preview-on-wikipedia/
======
publicfig
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.

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

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

~~~
le-mark
Charity in discourse, particularly online, is good policy for everyone[1].

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

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

~~~
azeirah
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-...](https://addons.mozilla.org/en-US/firefox/addon/max-tabs-web-ext/)

~~~
fapjacks
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!

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

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

~~~
baud147258
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](https://meta.stackexchange.com/questions/222721).
Linked in one of the answer is an extension:
[https://chrome.google.com/webstore/detail/sidebaroverflow/lh...](https://chrome.google.com/webstore/detail/sidebaroverflow/lhieihmjhlbhpjkamdjfjldcapnmhddp?hl=en)

There are also other solutions on that page.

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

~~~
saagarjha
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](https://en.wikipedia.org/wiki/MacOS)

~~~
Vinnl
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...](https://gitlab.com/Flockademic/whereisscihub/blob/master/index.js#L122)
)

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

~~~
Someone
[https://en.wikipedia.org/wiki/MacOS](https://en.wikipedia.org/wiki/MacOS) has
a footnote after the build number. That led me to
[https://developer.apple.com/news/releases/](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...](https://coderwall.com/p/4yz8dq/determine-os-x-version-from-the-
command-line))

------
anotherfounder
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...](https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive_131#Proposal:_Enable_Hovercards_by_default)

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.

~~~
ckoerner
>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...](https://en.wikipedia.org/wiki/Wikipedia:Village_pump_\(miscellaneous\)#Page_Previews)

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.

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

~~~
scrollaway
Wikipedia can exist without readers, but not without editors.

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

~~~
yjftsjthsd-h
> 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?

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

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

~~~
mistrial9
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

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

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

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

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

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

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

~~~
panic
_> 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.

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

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

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

------
Findus23
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](https://stackoverflow.com/a/48527419/4398037)

Documentation:
[https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_pag...](https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_page_summary_title)

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

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

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

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

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

~~~
vermontdevil
Thanks. I’ll do that!

------
mezzode
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...](https://blog.wikimedia.org/2014/03/26/Hovercards-now-available-as-
a-beta-feature-on-all-wikimedia-wikis/)

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

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

I see these even when logged out.

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

~~~
saagarjha
I'm seeing them in both cases.

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

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

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

~~~
contoraria
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?

~~~
F_r_k
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

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

~~~
ckoerner
> 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](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.

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

~~~
lucideer
> _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.

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

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

------
mschaef
The step ups in API usage over the last year are rather dramatic:

[https://grafana.wikimedia.org/dashboard/db/reading-web-
page-...](https://grafana.wikimedia.org/dashboard/db/reading-web-page-
previews?orgId=1&panelId=2&fullscreen&from=1480245159889&to=1524481960401)

~~~
jdlrobson
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](https://www.mediawiki.org/wiki/Reading/Web/Release_timeline)
if you are interested in what caused them!

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

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

------
nonbel
> _" 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...](https://www.mediawiki.org/wiki/Page_Previews/2017-18_A/B_Tests)

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.

------
Artemis2
Learned from this article that they make their Grafana dashboards public:
[https://grafana.wikimedia.org/dashboard/file/varnish-http-
er...](https://grafana.wikimedia.org/dashboard/file/varnish-http-
errors.json?from=now-12h&to=now)

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

~~~
ckoerner
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...](https://grafana.wikimedia.org/dashboard/db/eventlogging-schema-
jumbo?orgId=1&var-datasource=eqiad%20prometheus%2Fops&var-
schema=VirtualPageView&from=now-6h&to=now)

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

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

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

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

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

------
8bitsrule
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..._

------
JorgeGT
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 :|

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

------
joelcornett
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...](https://chrome.google.com/webstore/detail/wikipreview/iioncmbmegjiadkijjkmockilogpplhg)

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

------
erkose
I commend Wikipedia for providing a configuration option to disable this
feature. Netflix could learn a lot from Wikipedia.

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

------
niedzielski
Here's the code: [https://github.com/wikimedia/mediawiki-extensions-
Popups](https://github.com/wikimedia/mediawiki-extensions-Popups).

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

------
z3t4
This could have been implemented entirely in the client.

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

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

------
johnchristopher
I remember seeing those preview for weeks (months) but the article publication
date is 20th of April.

It's pretty cool :).

~~~
mavidser
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...](https://blog.wikimedia.org/2014/03/26/Hovercards-now-available-as-
a-beta-feature-on-all-wikimedia-wikis/)

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

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

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

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

~~~
ckoerner
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](https://www.mediawiki.org/wiki/Page_Previews#FAQ)

------
mfoy_
Just want to say I really like the new feature.

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

~~~
jdlrobson
:( We miss you! (context: [https://ahvalnews.com/freedom-speech/wikipedia-
starts-we-mis...](https://ahvalnews.com/freedom-speech/wikipedia-starts-we-
miss-turkey-campaign))

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

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

------
ryanpcmcquen
Yak shaving?

------
Numberwang
I personally always use the mobile version

[https://en.m.wikipedia.org/wiki/Main_Page](https://en.m.wikipedia.org/wiki/Main_Page)

for desktop these days.

I much prefer it to the standard version.

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

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

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

~~~
rory096
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](https://i.imgur.com/XQKiEIp.png)

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

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

[https://stackoverflow.com/a/48527419/4398037](https://stackoverflow.com/a/48527419/4398037)

Documentation:
[https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_pag...](https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_page_summary_title)

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

~~~
TuringTest
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...](https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups)

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

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

~~~
abalone
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...](https://appleinsider.com/articles/15/04/28/os-x-tips-preview-
links-in-safari-with-a-three-finger-tap)

[2] [http://www.idownloadblog.com/2016/01/07/8-cool-ways-you-
can-...](http://www.idownloadblog.com/2016/01/07/8-cool-ways-you-can-be-more-
productive-in-safari-with-3d-touch/)

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

~~~
abalone
_> 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.

