Talk:Page Previews

Jump to navigation Jump to search

About this board

Page Previews solves the core problem of users opening multiple tabs to gain an understanding of a word in the context of the subject they are reading. Whenever a reader hovers over a link to another article, a short summary of the subject, including its graphical image, is provided to them so they can decide whether they need to visit that subject more fully before continuing the current subject.

Please give us feedback on your experience using this feature so we can change and improve it. Each language is welcome in this discussion!

You can read more about the feature here.

Known Issues

Salgo60 (talkcontribs)

I am working together with a vendor of a Swedish genealogy software to integrate Wiki context see Task T204229 and prototype (see is there any good code sample of previews of Wiki content done on e.g. jsfiddler/github....

TheDJ (talkcontribs)
Salgo60 (talkcontribs)

Excellent I have started to play around using Jquery and searching in Wikipedia... and have presented that for some people so all ideas are welcome...

All advice are welcome. I feel a little bit scare to use "mouse over" and performance "cost"....

Reply to "External previews" (talkcontribs)

I had to write to a friend of mine who works for Wikipedia to share my enthusiastic support for the new page preview feature--what a fabulous (albeit slightly ADD) addition to an already amazing learning tool. He pointed me to the page explaining how much thought you put into this, and detailing how aware you are already of "rabbit-hole"-style learning. The visuals in pop-ups are especially great and aid in the contextual flow of learning, making a visit to any topic a potential adventure in learning that's actually even more fun and probably really effective from an educational point of view. As a parent of a young son who will likely be surfing Wikipedia pretty soon, my sincere thanks for caring enough about effective learning and helping to make the pursuit of knowledge an entertaining, self-guided interactive adventure.

-Tom Sturm

Easthampton, MA

TheDJ (talkcontribs)

Thank you for your words (talkcontribs)

You're welcome! Thanks for putting in the thought & labor.

Reply to "Brilliant. Kudos to Wikifolk" (talkcontribs)

I really like this feature I really liked this feature... right up until it bugged out on me.

Before: Ctrl-clicking on a preview opened the page in a new tab.

Now: Same but also registers as having clicked the preview.

This is kind of annoying considering I use that shortcut so I can continue looking at the page I'm currently on.

CKoerner (WMF) (talkcontribs)

I'm a fellow ctrl/command clicker myself. Could you tell me more about what browser/OS combination you're using? I don't think the previews should be getting in then way of that browser feature. I am able to reproduce it though. I filed a task for the engineers to look into things. Thank you!

CKoerner (WMF) (talkcontribs)
Reply to "Extra click registered" (talkcontribs)

I don't find them intrusive, but the best thing to happen to Wikipedia since Wikipedia. I'm surprised you don't set the popup preference for anon users via a cookie, but I suppose people would complain about cookies then. Keep up the good work. You might want to take a look at the page preview for Pentecost though. Someone's been a bit naughty.

Reply to "Intrusive? Nope."
CSProfBill (talkcontribs)

I have to add my voice to the chorus of people who find the implementation of "page previews" too intrusive to accept. If I were cynical, I would say it was designed to force people to give up their privacy by beating them with page previews unless they log in. Part of the problem is the bad design of the pop-up itself. Instead of having a single click on the "gear" turn off the previews, it merely takes you to another popup, where you have to both click "disable" and click "save", then another pop-up to click "done" - 4 points and clicks in all. Even then, the attempt to turn off the harassing previews may not last through a "back" click, and is lost across private-viewing browsers or across restarts of the browsers, all of which I use quite frequently in the interests of avoiding "tracking" by various commercial websites that might share the browser with a use of Wikipedia.

In short, while I am quite sure there are some users who like the feature, and many who neither like or dislike the feature, there are some, including myself, who find it so offensive and so intrusive that it s worth while to log in to record my objections here. It seems that quietly cursing about how intrusive and offensive this "feature" is to some does not have any actual effect. I can, however, offer at least the suggestion above and another suggestion, below as an attempt to ameliorate the problem of the two opposed user communities,

The only way I can see out of the dilemma of faced by the developers of how to advertise a feature with such diverse reception to non-logged-in users, might be for wikipedia to implement an alternate url, or append start-up information in its url, so that the initial setting for such a feature can be embedded in the bookmark that accesses wikipedia initially and for the selected value to be propagated across clicks on links even when clicked as a new browser..

CKoerner (WMF) (talkcontribs)

Thank you for the feedback - and cynicism. :) Part of my job is to make sure project teams don't do anything purposefully disruptive to the reputation of the projects or larger movement. So, I hope with some faith you can believe me when I say there's been no attempt to use the feature in a manipulative way. There is a task to review the disabling of the feature for logged out users. There's also a larger discussion around settings for logged out users as mentioned below. (talkcontribs)

Is there somewhere I can add my name to a list of readers who are pissed off with preview and the fact that I can't turn it off. No matter how many times I click the settings and disable it, there they are again. I'm looking for a Firefox add-on to disable them. Anyone have any ideas? (talkcontribs)

I would like to add my voice to this too. I am forced to stay logged in at home so I don't have to deal with this very intrusive popup but at the office I can't be logged in and therefore I am forced to click the "disable" setting multiple times a day in an attempt to try and make it go away, which never works for very long. The preview is annoying, it obscures what I'm trying to read, and I'm generally not interested in what it has to say.

TheDJ (talkcontribs)

> I am forced to click the "disable" setting multiple times a day in an attempt to try and make it go away, which never works for very long

BTW. this shouldn't be needed, unless you using something that messes with the local storage of the browser. Do you use 'cookie' blocking or something ? (talkcontribs)

I'd like to be added to the list as well. (talkcontribs)

I'm also among the users who would rather not have them. I've never purposefully activated one, but they are often popping up to obscure the text I am trying to read. I guess I'll eventually learn to corral my cursor.

Reply to "Too intrusive, improvements proposed"

Page Previews configuration change for new accounts

CKoerner (WMF) (talkcontribs)

Hi all,

We wanted to let you know about some planned changes to the configuration of Page Previews for newly created accounts. Currently, the feature is off by default for all logged-in users and on by default for all logged-out users. When people create an account, the feature will appear to vanish which would be confusing.

We plan to change this configuration and enable the feature for all new accounts. [0] For current logged-in users, there will be no changes to the current configuration. If you have the feature off, it will stay off. If you have it on, it will stay on. If there are no major concerns raised, we plan on making these changes sometime in early July, 2018.


Reply to "Page Previews configuration change for new accounts"

Brackets containing IPA are not properly displayed

Summary by SUM1

Discovered the issue was a missing closing bracket, not an issue with hovercard.

Edit 17 April 2018: rediscovered that there is in fact an issue with the displaying of brackets containing IPA. Detailed below.

SUM1 (talkcontribs)

As I understand, it is hovercard's policy to remove bracketed content in link previews (which is a good thing). Well, it is failing to do this when the IPA template is used within brackets. It seems to end the omission at the end of the IPA template rather than at the closed brackets. As you can see in the example below, it correctly omits the next set of bracketed content after the first failed omission.

Example: pagelink preview

SUM1 (talkcontribs)

Update 17 April 2018: I have discovered that there is in fact a problem with brackets containing IPA being displayed in link previews. The problem seems to follow the exact same logic as described in my original post above.

Example: pagelink preview

@CKoerner (WMF)

CKoerner (WMF) (talkcontribs)

@SUM1 I wanted to let you know I saw this and have reported it to the project manager. We're looking into it. I'll let you know what I find out.

OVasileva (WMF) (talkcontribs)

Hi @SUM1 - thanks for reporting this! The issue you mentioned was actually happening due to a parenthetical that needed closing - note that the first parenthetical in the article right before the IPA was never closed. This has since been fixed now in the page and the preview no longer shows IPA. That said, we are aware that more edge cases with parentheticals might occur - please let us know if you've noticed any other issues.

2604:6000:120C:8033:7917:657F:8F12:F348 (talkcontribs)

Hovercard is displaying brackets and other punctuation if their are multiple IPA templates used. Examples [[w:Louisiana]], [[w:Scythian languages]], and [[w:Scythians]]

2604:6000:120C:8033:7917:657F:8F12:F348 (talkcontribs)

Those are supposed to be links to

SUM1 (talkcontribs)
Jdlrobson (talkcontribs)
Reply to "Brackets containing IPA are not properly displayed"

Similar browser extensions or add-ons to be inspired by

Quiddity (WMF) (talkcontribs)

I'm moving these here, from the project page where I originally listed them. Feel free to edit this to add any you find.

No endorsement of a particular extension is implied.

Browser extensions/addons that show mouseover popups within Wikipedia


Browser extensions/addons that show Wikipedia/Wiktionary content at any external site

Tbayer (WMF) (talkcontribs)
This post was hidden by Quiddity (WMF) (history)
Edwardj 123 (talkcontribs)

There are similar tools like this Page Previews feature, however that shouldn't stop our community from making ours. Having one official tool providing the best features in a simple way for everyone is a great idea which doesn't need installing browser extensions.

Listing the other extensions and add-ons is useful because we can review their design and features to improve our version.

Quiddity (WMF) (talkcontribs)

Yup, that's exactly why I started/researched the list. To show how popular the idea was (proving we ought to implement something) and to glean good ideas/designs from. :-)

EoRdE6 (talkcontribs)

Think this means this feature really needs to be globally rolled out to non-registered users then... Maybe leave as an option for registered users though because some prefer third party gadgets like Popups on english that give you way more details (for editors)

Edwardj 123 (talkcontribs)
To EoRdE6: I agree that this feature would good for everyone outside beta testing (it is a tool made by many others), however this shouldn't happen too soon because it needs to be finished (main problems fixed, features added). Also an option for users to disable it on their account could be a good idea but it would be better to make Page Previews/Hovercards have the popular features of other third party tools so users would use our official tool.
EoRdE6 (talkcontribs)

My issue with that is that editors still have very different requirements to readers therefore a reader centric tool will never function for editors... Third party tools allow editors to view page history and editors and block logs and protection and tons more all from the pop-up. It's messy and ugly but for editors it's useful. Readers have no use for that information so I would support giving them this basic version that is currently available...

Edwardj 123 (talkcontribs)
To EoRdE6: I see your point but we could have these editor only stats in Page Previews/Hovercards as opt-in features enabled on users' settings pages which could get some editors to use our tool instead of competitors' ones to keep ours supported and popular.
This post was hidden by Quiddity (WMF) (history)
Reply to "Similar browser extensions or add-ons to be inspired by" (talkcontribs)

I don't like this, too in your face, so disabled it.

Take a look at Google Earth. You can click on a little button by cities, towns, restaurants, places of interests, campsites, etc. and up pops a card (what you call page preview) with information about it.

Go to Paris and see all of the buttons you can click to find out about stuff. Now imagine browsing through Paris and every one of those little buttons can pop out a preview if you stay over one too long. It would be unbearable. That's what this is.

The user activated button is so much more user friendly than your mouse pointer happening to rest over a link or word and it pops up. The user has the control which is the way it should be.

CKoerner (WMF) (talkcontribs)

Interesting feedback. Thank you for the consideration. I think the crucial difference is that Page Previews activate on a hyperlink. Folks expect that when you click on a hyperlink it takes you to another page. Making the preview appear upon a click (or other interaction) would fundamentally change the way hyperlinks work. That seems counter to readers expectations on how hyperlinks should behave. (talkcontribs)

Don't make the hyperlink a page preview, put a button next to the hyperlink to activate the page preview. The hyperlink would still function as expected and the button would give the user control.

You mention what readers expect. I'd bet a princely amount that what readers don't expect from hyperlinks is to scroll over them and have them pop out at you. That is not the way hyperlinks have ever worked. So you've fundamentally changed the way hyperlinks work compared to the entire rest of the content delivery world.

Alzi24 (talkcontribs)

@ That is not true. Having a small popup nearby e.g. an icon, or any other visual object on the desktop, is a well-known standard feature, existing since Windows 95. Look at what is shown on your browser when the extension is disabled and the mouse cursor hovers beneath a hyperlink: there IS a small popup window showing the address where the hyperlink will jump to. All this extension does is expanding that popup to an article preview. It is a cool and heavily used feature within our wiki; when editing an article, it enables us to check if the hyperlinks are correct without clicking all links, and it allows us to do so in the article preview, i.e. BEFORE saving the edit. The proposal of an additional button nearby the hyperlink is not a good idea because that will extremly disturb the reading process of the article text. The feature is cool. Anyone that doesn't want it, shall switch it off. (talkcontribs)

Aizi24 - those are called tooltips and balloons help and you're right, they have been around for awhile. Balloon help first appeared in Apple's OS around version 7. Tooltips are usually a small bit of information related to a button, etc. Balloon help was more information again used for help, like how a function worked in MS Word.

Tooltips remain but balloon help has slowly faded away simply because it's too intrusive.

Wikipedia's implementation is not a tooltip, it's more like balloon help on steroids.

You're using your particular needs - having your own wiki and editing it - and applying it to Joe public. It's really not the same thing at all. Sounds like for your needs it is pretty handy but for someone who just wants to read an article it's intrusive.

"...button nearby the hyperlink is not a good idea because that will extremly disturb the reading process of the article text."

If you read the complaints that is exactly what people are annoyed with, how it extremely disturbs the reading process of the article text. Without focusing on your curser at all times (tracking your cursor changes the very way one is browsing through an article) these can popup by simply coming to rest over a link.

For the average user having control of that popup would give them control without having to turn it off if they're annoyed by it. A small button (like a ? button) would put control in the users hands. It's the only solution whereby the feature can be used by everyone.

People who don't want it don't necessarily think it couldn't be useful, they don't want it specifically because it's annoying. I can certainly see its usefulness and would use it but as is it's too annoying to use for me. I want to use it - and this is a key arguement - ONLY WHEN IT'S USEFUL. When it's not it's just annoying.

Wikipedia is saying it's either on or it's off.

And no other content delivery site functions like this. You wouldn't read a WSJ article and expect to have to focus on where your cursor is at all times so you can avoid things popping out at you.

Alzi24 (talkcontribs)

Thanks for your answer. I just stated my own single private opinion because when browsing through the discussion topics, one can see lots of complaints but rare acceptance. I do not consider speaking for Joe everyone (as some of the local hypercritics do) nor did I intend to offend you. Sorry if you felt so.

Reply to "Disabled"

Page Previews Harm the Wikipedia Mission of Disseminating Information Effectively

2 (talkcontribs)

Here is a story about Page Previews:

I was using Wikipedia to research a wildlife refuge in Texas. A picture popped up and I ignored it, moving my mouse to some other area of the screen. But I saw the picture and it left an impression on me. It showed a path leading through a lush green area into a forest. In any case, I finished reading the article and put the wildlife refuge on the short list of places to visit during an upcoming trip.

Later, when planning the trip, I did some deeper research. In doing so, I learned that I had the completely wrong idea about the wildlife refuge. It isn't a lush and forested place; in fact, it has no fresh water and no trees. I went back to Wikipedia to figure out how I had formed such a misguided impression. There, I discovered that the image I associated with the place is really a picture of someplace else. It is an image that pops up automatically whenever a Wikipedia page links to the article on nature trails and the mouse moves over that link.

I now know that this feature which causes potentially unrelated images to pop-up is called "Page Previews" and is intentional.

I know that the people who administer Wikipedia are extremely smart and conscientious, so I'm fairly certain that when they planned this feature, they considered the possibility that attention-grabbing pop-ups might actually detract from their mission, making it more difficult for readers to concentrate on the article at hand, or (as in my case) misinforming readers by presenting images which, in the context of the article, lead to misguided impressions. I'm fairly certain they considered this possibility, but perhaps they regarded it as only theoretical, and they are waiting for feedback from Wikipedia users before they attempt to judge its real impact.

Thus, I wish to state that in my experience the Page Previews feature makes it more difficult to read and understand Wikipedia articles. Please take this into account when planning the future of this feature.


PS: This page is very hard to find.

Alzi24 (talkcontribs)

We do have this problem too, in our wiki. Sometimes there are unrelated images showing up in the page preview. I'd suggest to add an additional wiki tag that allows us to define an image as related or unrelated.

Reply to "Page Previews Harm the Wikipedia Mission of Disseminating Information Effectively"