Talk:Page Previews

Jump to: navigation, search

About this board

The Hovercards beta feature 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 beta 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

Blocky side image/picture on the mouseover preview

3
The Equalizer (talkcontribs)

Blocky image/picture with the mouseover preview

Hi team, I've noticed what seems to be a recent change which appears as the above on these example pages:

Burton upon Trent

Oxford

Sunderland

That's when previewing on Chrome. In IE the preview image is blank. I am unsure this has been reported previously but did a search in the talk page archive, nothing directly related appears.

I get a view such as this link. Oxford example My Chrome is version 63.0.3239.132 (Official Build) (64-bit) and IE is 11.0.16299.15. Most curious as most mouseovers show the first image in the article correctly so hints at some wrong code on those pages above..

I mixed it up with Navigation Pop-ups and reported it there, and was advised to turn that on instead, but think I prefer Page Previews so am reporting it in case it's an issue.

Thanks for any suggestions. J

TheDJ (talkcontribs)

This is a temporary problem, tracked in phab:T187955

The Equalizer (talkcontribs)

Nice! Will wait it out, thank you.

Reply to "Blocky side image/picture on the mouseover preview"

Only one line of text is shown in link previews sometimes

2
SUM1 (talkcontribs)

Occasionally, only one line of text is shown in link previews, with the fade-out at the end of this line, instead of the usual 7 lines of text. This seems to occur mostly in articles with only two sentences in the lead, or an otherwise short lead, but most short-lead articles show correctly (it shows the full text of the lead, with no fade-out).

Example: pagelink preview

This is a response to CKoerner (WMF)'s reply on this topic.

P.S. It would be nice to be able to change the number of lines shown in a preview, or otherwise have more customisability with the gadget.

SUM1 (talkcontribs)

It may be related, but occasionally only one sentence of text is shown, without a fade-out.

Example: pagelink preview

Reply to "Only one line of text is shown in link previews sometimes"

Link previews are occasionally blank for pages with content

1
Summary by 197.218.84.254

Simply outdated cache or maybe a random intermittent error. Purging the pages fixes it.https://phabricator.wikimedia.org/T182953

SUM1 (talkcontribs)

Occasionally, link previews are blank for pages with content (including a lead), instead displaying the notice "Looks like there isn't a preview for this page". Despite searching the source code of the articles every time, I haven't been able to find any common element that may be causing this.

Example: pagelink preview

This is a response to CKoerner (WMF)'s reply on this topic.

Reply to "Link previews are occasionally blank for pages with content"
Alsee (talkcontribs)

I just wanted to point you to a discussion at EnWiki Village Pump: Recent_user_interface_change_discussion (permalink to likely-incomplete discussion).

I suspect(?) that they encountered the feature on a different language, and I assume they thought it would be most effective to contact us in Wikipedia's main/home language.

The key fragment is this: I just wanted to register how awful a change I think it is. I respect and commend the utility of the feature; my comments are solely about forcing it on people. Some of us specifically like the Wikipedia interface for its simplicity and lack of movement. An 80-year-old user I know specifically complains about "all that moving stuff" which prevents her using many sites.

I think it well embodies the prevailing editor view on EnWiki. The feature offers an obvious utility, but default gadgets&gizmos are awful. There's a broad view valuing a certain kind of simplicity for Wikipedia.

OVasileva (WMF) (talkcontribs)

Hey, @Alsee. Currently, the feature is deployed to all Wikipedias except for English and German. It is off by default for logged-in users and on for anonymous users. Its possible this user came from a different wiki and was logged out. Also, we’ve been running some tests on English and German wikipedias where we have been delivering the feature to a very small percentage of anonymous users as well. Each preview also has a settings option from which the feature can be disabled.

Reply to "Reader feedback"

Formulas are not properly displayed in link previews

5
SUM1 (talkcontribs)

Formulas ("math" markup) are not properly displayed in link previews. The formula is duplicated with "{\displaystyle }" shown around it, among other changes (like added underscores), powers are incorrectly shown as full numbers and bracketed letters are not shown.

Example: pagelink preview

This is a response to CKoerner (WMF)'s reply on this topic.

CKoerner (WMF) (talkcontribs)

@SUM1The updated code is on the beta cluster. Looking at some of the examples, things look much improved. I'll let you know when this reaches the actual wikis!

SUM1 (talkcontribs)

@CKoerner (WMF) Damn, that looks great. Looking forward to it.

Itamarcu (talkcontribs)

Possibly the same bug, not sure: page and link preview. The "O(log n) amortized time" text appears as "O amortized time" in the preview.

Perhaps this is a result of the "O" being a link immediately followed by parentheses?

SUM1 (talkcontribs)

@Itamarcu Yes, that would simply be a case of link previews removing brackets and their contents.

Reply to "Formulas are not properly displayed in link previews"

Similar browser extensions or add-ons to be inspired by

10
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

Chrome
Firefox

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

Chrome
Firefox
Tbayer (WMF) (talkcontribs)

Another one for Chrome, launched in August 2016: "LiveWiki" (https://github.com/mrusa/livewiki )

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

The fact that there are similar tools like this Page Previews feature shouldn't discourage 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 require 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 definitely agree that this feature would good for everyone outside beta testing, particularly as it is a fairly popular tool made by others, however this shouldn't happen super soon because it still needs to be finalised (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 to persuade users to 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 definitely see your point but we could still provide these editor only stats in Page Previews/Hovercards as opt-in features enabled on users' settings pages which would have the benefit of persuading 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"

Hatnotes which are not organised as templates are shown by mistake in link previews

5
SUM1 (talkcontribs)

Hatnotes which are composed of an indent (:) plus italic text are shown by mistake in link previews. However, the link preview correctly removes hatnotes which are made from the various hatnote templates, such as {{hatnote}}, {{About}}, {{For}}, etc.

Example: pagelink preview

This is a response to CKoerner (WMF)'s reply on this topic.

Quiddity (talkcontribs)

From an editor-perspective, this could be seen as a good thing (or at least a beneficial aspect), because it helps us notice things which need to be fixed! Admittedly not in the cleanest way possible, but...

I've fixed that instance.

SUM1 (talkcontribs)

@Quiddity You're right, and I fix it every time I come across it, but it's how often it comes up that made me consider it a problem. I can't count the times I've had to fix this format of hatnote. For this reason, I was thinking it could be easier to configure a way to not show it in link previews instead, but of course it's up to the developers.

Nihiltres (talkcontribs)

The answer here is definitely to fix the instances of incorrectly-formed hatnotes, rather than to hide the problem in any way. I've personally fixed thousands of these, and as far as I can tell this is really a problem that needs human effort to clean up: the badly-formatted cases are too inconsistent to cleanly handle automatically. Beyond showing up badly in previews, the bad :'' format also represents inferior formatting for accessibility.

I'd like to mention in particular some regex-based searches for these sorts of issues saved in my sandbox (permalink).

If we get more people together fixing them, we could reduce the problem significantly. If enough people are interested, we could even start a WikiProject to coordinate effort. I see hatnotes as a key part of the template infrastructure and have pushed a lot of effort into making them more functional and standardized (e.g. creating Module:Hatnote list, or umpteen TfDs to cut down on needless template sprawl).

Quiddity (talkcontribs)

Re: "we could even start a WikiProject [...]" - at Enwiki, this would best be handled by WikiProject Disambiguation. I suggest copying your great sandbox list, into a new sub-section at w:en:Wikipedia:WikiProject_Disambiguation#How_to_help.

(Also, kudos on your great "Notes from a survey [...]" table :-) Maybe that could become a WP:WPDAB subpage, or talkpage section, to enable collaborative analysis?)

Reply to "Hatnotes which are not organised as templates are shown by mistake in link previews"

Link previews are occasionally only one sentence long

1
SUM1 (talkcontribs)

Link previews are occasionally only one sentence long, not showing the full lead section of a page.

Example: pagelink preview

On many other occasions, I have seen them display the message that there is no link preview for a page even when the page has text in its lead. I cannot find any examples at present.

This is a response to CKoerner (WMF)'s reply on this topic.

Reply to "Link previews are occasionally only one sentence long"

Trying to implement on a private wiki (corporate intranet): doesn't work

3
204.174.222.21 (talkcontribs)

We use Mediawiki 1.29.1 for a corporate intranet, and I am trying to get Page Previews working on it. I have installed the mandatory extensions and verified that all are working. Yet after turning the feature "on" in my preferences, I do not see any previews at all.

Any idea what I am doing wrong, or not doing, or doesn't this work for a private intranet?

CKoerner (WMF) (talkcontribs)

Can you please see if the settings (now documented!) I replied with in this thread make any difference for you?

24.248.254.194 (talkcontribs)

Hmmm .. no they do not. The first setting has incorrect syntax, btw - a colon instead of semi-colon at the end.

What has now happened is that the option to enable Page Previews has vanished from Preferences for logged in users (the only kind we have).

Reply to "Trying to implement on a private wiki (corporate intranet): doesn't work"

No preview shown for a link to a redirect page??

7
Summary last edited by Kaartic 02:57, 17 January 2018 1 month ago
Kaartic (talkcontribs)

I think previews are shown for links even if they are just redirects. If my previous statement is true, I recently noticed an outlier. Hovering over the w:Core memory link in an image text (A portion of a core memory with a modern flash SD card on top) in w:Random Access Memory shows the Looks like there isn't a preview for this page message in the popup.

I specify this as an outlier because in the same image text there's a link to the w:SD card article which is also redirect. Hovering over it does show a preview!

Any reasons for this odd behaviour?

197.218.81.8 (talkcontribs)

It is likely due to the fact that the redirect is categorized (without a hidden category), making the intended behaviour ambiguous. Should the preview show the category or should it redirect, what about cases where it contains simple text?

In fact, a redirect is simply a page with a redirect markup. It could potentially be a full page with lots of content as long as the first section contains that markup. It is an unfortunate result of earlier developer's misguided decision to allow metadata inside a page.

Kaartic (talkcontribs)

In any of the following cases,

  • a redirect page (that only contains #REDIRECT ...)
  • a categorized redirect page
  • a redirect page with simple text (is it even possible?)

I might not care if the the preview of the page to which it redirects is shown. That's because, I expect the preview to give more information than I could get from the link text. I don't think the information such as,

  • categories to which the page that redirect page belongs
  • simple text in the redirect page (if it's possible)

shown in the preview would be more useful than the preview of the page to which it redirects.

197.218.80.253 (talkcontribs)

You're missing the point that mediawiki is an interface / software that is in a perpetual state of conflict. It attempts to cater to both readers and editors and can never really cater properly to both of them due to the inherent difference in the characteristics of those users.

Showing preview of the redirect itself may be sensible sometimes for an editor, but may not be so for a reader. Moreover, a redirect may be to the wrong target, and simply confuse both editors and readers.

Anyway, as far as this thread is concerned it seems to be a clear issue, because there are other redirects that have categories and work properly. Perhaps all it needs is a simple edit to refresh the cache.

Alsee (talkcontribs)

IP I think you misread. Kaartic wasn't asking to see categories or text on the redirect page. They were merely responding to your point that it would be plausible to show categories or content on redirect pages, acknowledging that showing-something is better than a "no preview available" showing-nothing. I think we all agree the best behavior is to ignore anything on the redirect page, and just show a preview of the redirect-target page. People expect preview to show whatever clicking-the-link will show.

I tested somethings, trying to fix it:

  • Purging the redirect page didn't work.
  • Purging the page pointing to the redirect didn't work.
  • Null-editing the redirect page didn't work.
  • Null-editing the page pointing to the redirect didn't work.
  • A dummy edit to the redirect did fix it!

Weird. This should definitely be investigated. It could be affecting other pages. In fact there is no clear basis to conclude that it's related to the page being a redirect. It could be affecting regular article pages.

197.218.80.253 (talkcontribs)

There will always be edge cases where it makes sense to show that dialog, e.g. if it can't possibly interpret the page such as the target page of a redirect being deleted, target page never existing in the first place, no first section on a particular page, and so forth.

"No preview" seems to be shown whenever it can't interpret or read the preview. It could be caused by any number of things, e.g. an error while reading the page, or storing the summary, or simply an inability to parse the content properly.

It is probably not worth overthinking it unless it can be consistently reproduced even after a simple page edit.

Kaartic (talkcontribs)
A dummy edit to the redirect did fix it!
Alsee

Now that's what I call surprising. Of course as large number of components might be involved in showing a preview, this might be something that cannot be easily tracked down. Anyways, it's up to the developers to decide. May be we should file a ticket on phab and let the developers decide for obvious reasons (they know a lot more than we do about how previews are shown).

Reply to "No preview shown for a link to a redirect page??"