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

Need a magic word to change default image

2
Bilorv (talkcontribs)

I've had two conversations on enwiki in the last few months where it has been desirable to change the image shown in a page preview to something that is not what the tool identifies as the first image in an article. For simplicity: imagine that we don't have an image of Actor X, but midway down their article we talk about their comedy duo work with Actor Y (pictured) and so Actor Y is shown in the Page Preview, clearly misleading as the person doesn't match the name. The only solutions are getting a picture of Actor X (could be literally impossible) or removing all images from the article (could be very undesirable). At least, those are the only solutions I'm aware of.

To me the obvious solution would be a magic word or something that we can encapsulate in a template so that I can write {{PagePreview|None}} to have no image in the page preview, and ideally I can also write {{PagePreview|Image.jpg}} to override the first image as preview and instead use Image.jpg.

It is hugely undesirable for the only solution to be changing the primary rendered article layout in order to accommodate for a secondary layout feature like Page Previews.

I'd be delighted, of course, if there is any other solution and I'm just not aware of it, so please correct me if I'm mistaken.

(Please ping me or do something that gives me a cross-wiki notification so I'll notice replies to this.)

FMM-1992 (talkcontribs)

@Bilorv: another solution is only use the infobox image

Reply to "Need a magic word to change default image"
2600:1008:B150:2F09:E0B5:7116:DB1C:3DF0 (talkcontribs)

I'm sure this has been mentioned before, but what about article titles which contain parentheses that actually are part of the name of the subject? The page preview seems to work with chemical elements that have parentheses in the title, but looking at the preview for Brandy (You're a Fine Girl) leaves out the remainder of the song title which is in parentheses.

Niedzielski (talkcontribs)

I think this has been discussed previously but I'm not sure what the current thoughts are on it. I've opened a ticket for discussion with the maintainers: T226323.

W.andrea (talkcontribs)

Currently anything in parentheses is hidden in the preview, but I think anything in bold should be shown.

Sparkie82 (talkcontribs)

This could be implemented generally as a LocalSettings variable containing a list of terms, which when found within the text of a page, cause the parenthetical stripping to be disabled. Another solution is to have a LocalSettings variable containing a RegEx for parenthetical text that should be included in Page Preview. ~~~~

Another user case where this is a major problem is with Bios. The subject's DOB and DD are usually within parentheses immediately following their name. e.g., John Doe (26 BCE - January 1, 1955). When I come across an unfamiliar name while reading WP, I almost always need to know the time period when the person lived (and most of time that's all I need to know about them), however, Page Preview doesn't show the dates. Maybe when fixing the other parentheses issues you could fix this too (or make sure the fix addresses this user case. ~~~~

Reply to "Parentheses as part of title"

Help - Cannot enable Page Previews on my wiki

2
178.235.2.148 (talkcontribs)

I just updated my mediawiki from 1.30 to 1.34 (including database upgrade and PHP version upgrade) specially for this extension. I did check if the dependencies mentioned on the extension's page are enabled and installed (one was commented out). Checked Preferences - no option to turn it on/off. I've added lines proposed on the extension's page to LocalSettings.php (not sure if in the correct place as I know nothing about php):

wfLoadExtensions([

   'TextExtracts',

   'PageImages',

   'Popups'

]);

$wgPopupsHideOptInOnPreferencesPage = true;

$wgPopupsOptInDefaultState = '1';

$wgPopupsReferencePreviewsBetaFeature = false;


Page Previews do not appear. What to do?

Here's the wiki - wiki.mrowki dot ovh

178.235.2.148 (talkcontribs)

Somehow it started working on its own. This is probably the only translated Extension name on my Specia:Version list... (I can't ask "why?" enough).


The next problem is, popups do not display images (its a white rectangle space instead of an image). Most of my pages have images put in infoboxes made of HTML code, not sure if this does break things. Is there a way to hide images?

Reply to "Help - Cannot enable Page Previews on my wiki"

Page preview for institutionalized racism

2
174.82.109.48 (talkcontribs)

I was browsing and noticed the page preview for institutionalized racism is currently fairly offensive and racist but I don't know how to go about editing it.

Niedzielski (talkcontribs)

Page previews are derived from the opening content of the pages they point to. I have seen, but been unable to track down, caching issues where the preview shown is for an older page revision. This is especially problematic for vandalized revisions. These caching issues are usually resolvable by manually purging the cache for the given page. E.g., https://en.wikipedia.org/w/index.php?title=Institutional_racism&action=purge

Reply to "Page preview for institutionalized racism"
JamesLucas (talkcontribs)

I noticed that the preview card for w:en:Bohol displays the markup of the infobox template rather than the first sentence(s) of the article proper. Aside from the infobox contents including a relatively large number of sub-templates, I'm not immediately seeing anything too far out of the ordinary. I didn't want to try troubleshooting by testing on the live article, and I thought I'd check for answers here before taking this to a sandbox. Anyone have a sense of what's broken? Cheers.

Quiddity (WMF) (talkcontribs)
Niedzielski (talkcontribs)

The template is in the page previews summary endpoint response, no surprise. It's my understanding that the summary endpoint uses Parsoid and it's in that too. I manually bisected the article's diffs (being mindful of possible caching and purging concerns) to see when it occurred and was able to narrow it down some, I think. My guess is T197523 which I've left a comment on. If you think it's a priority and you agree with the assessment, please consider awarding the task a token.

Reply to "Preview shows template code"

Preview text too short (user feedback from en-wp Help Desk)

1
Tigraan (talkcontribs)

[https://en.wikipedia.org/w/index.php?title=Wikipedia:Help_desk&oldid=945998562#New_page_preview_system Original post]. The complaint says (in summary) that the preview text will often look like "Foo is a game published in YEAR_I_DONT_CARE by COMPANY_I_DONT_CARE on PLATFORMS_I_DONT_CARE (...)" and so the information they want (summary of game story, etc.) is below the fold. There is not much we can do on the Wikipedia side unless we change radically how the lead is written, but maybe the settings (which currently contain only a activate/disable switch) could include a "max length of preview" setting. (I am not saying it is easy especially across various displays, I am just saying that some could find it useful, at the very least the person who complained.)

Reply to "Preview text too short (user feedback from en-wp Help Desk)"
39.53.66.173 (talkcontribs)

I am getting empty page previews if page starts from a heading. Is there any way to resolve it?

Bdijkstra (talkcontribs)

Can you give an example where starting from a heading is a good idea?

39.53.187.80 (talkcontribs)

Let me give you an example. Every research article begins from an "Abstract". In academia, abstracts are compulsory. I want to publish a journal on mediawiki. Therefore, every article in my wiki will start from an "Abstract".

131.104.23.215 (talkcontribs)

Hi there, I am having a similar issue. Can someone please help to resolve this? All my pages with a Header serving as the title show "..." in the preview instead of the article content. The only way I have been able to fix this, is to remove the header. I would rather not do this though- any suggestions?

Reply to "Empty page Previews"

Text summaries are clipped awkwardly sometimes.

9
Connor Krammer (talkcontribs)

Most times the hover cards do a good job of ending after an appropriate amount of content, but on longer excerpts text gets truncated, often abruptly. (Example: The link to the flow extension at the top of this talk page.) This is opposed to just ending at a sentence boundary.

This wouldn't be so bad if ellipses were at least appended to the text, but in either situation it badly triggers the zeigarnik effect. This leads to clicking on the page to finish reading the excerpt... and then you've left the page and lost your original reading context.

As a designer/copywriter/programmer, this just stuck out at me -- I don't know if it bothers anyone else. Overall though, I think hover cards are a great idea. The project page states that the goal of the feature is to provide readers with an excerpt so that they "can make the decision about whether they want to read the full article" or not, but it strikes me as being just as useful for getting a quick idea of what a term means. (It's kind of the idea pondered here.)

I have a couple other suggestions, but I want to turn those over in my head for a bit first. For most of the project though: looks good!

Vibhabamba (talkcontribs)

Connor, I completely agree with you, we should truncate sentences. Say we have to truncate after 250 characters. This would be very different for different languages. What counts as a character in Hindi is much less than an actual alphabet. So we are struggling a bit with this technical limitation.

Its a great insight that once the user lands on the target page, the transition is lost. I have some ideas, but would also like to hear of how we might be able to solve this.

This post was hidden by RandomDSdevel (history)
Vibhabamba (talkcontribs)

I believe we have some language engineering folks who can help figure this out. Pau Giner?

Pginer-WMF (talkcontribs)

Showing some partial content in a way that works well across multiple languages is a hard thing to do. Depending on how you want to deal with it, you may need to take into account how each language separate words, use a different line according to their script, or the very notion of "character" and how those are counted.

It would be useful to have a generic component in MediaWiki that let's you just show a given number of lines, or whichever content fits in a given space. This is something that the Language Team may consider to support in the future.

An alternative to cropping with an ellipsis, could be to make the last part of the text to fade out by applying a transparent-to-white gradient on top of it (covering the last line).

Regarding the continuity problem mentioned by Connor, that can be solved if when reaching the article though a hovercard, the first sentence of the article gets highlighted for a second (e.g., background could fade to grey and back to white again). In that way, the user could guess that the text is the same and continue reading where he/she left.

Santhosh.thottingal (talkcontribs)

Breaking the sentence after a certain number of characters is not i18n safe. It can cause lot of issues with complex scripts. Complex scripts require grapheme boundary detection or word boundary detection for finding out sensible line break positions. That is defined in TR29 of unicode standard and very difficult for the context. Pau's suggestion about fading the last line looks good to me.

TheDJ (talkcontribs)

Santhosh.thottingal: I think you are making it a bit too complicated here. You are looking for solutions to fix an imperfection, but your workaround is also not perfect. Don't trade the one imperfection for another imperfection too easily.

Santhosh.thottingal (talkcontribs)

TheDJ: I was just pointing out the i18n aspect. I did not propose any solution or workaround. Thanks.

LuisVilla (talkcontribs)

As an example of somewhat awkward cropping, mousing over a link to https://en.wikipedia.org/wiki/Bernard_Zakheim gives "Bernard Zakheim, Apr.", presumably because it treats the period as a sentence termination rather than an abbreviation. Not the end of the world but something else to consider while improving this.

Reply to "Text summaries are clipped awkwardly sometimes."

Page preview feature requirements?

2
EchoBlu (talkcontribs)

Hi, are there any requirements (in size and dimensions) for images to be visible with page preview feature? I have updated logo of one page, but image is still not visible in page preview, only text, like before.

TheDJ (talkcontribs)
Reply to "Page preview feature requirements?"

Suggestion: End Preview Text At End Of Sentence

4
182.57.86.135 (talkcontribs)

IMHO, a much-needed improvement to the Page Preview feature would be to have it end at a complete sentence instead of at an arbitrary word limit. Here's an example for the entry Uffizi :

The Uffizi Gallery is a prominent art museum located adjacent to the Piazza della Signoria in the Historic Centre of Florence in the region of Tuscany, Italy. One of the most important Italian museums and the most visited, it is also one of the largest and best known in the world and holds a collection of priceless


This preview text would be so much better if it included the full sentence, like so:

The Uffizi Gallery is a prominent art museum located adjacent to the Piazza della Signoria in the Historic Centre of Florence in the region of Tuscany, Italy. One of the most important Italian museums and the most visited, it is also one of the largest and best known in the world and holds a collection of priceless works, particularly from the period of the Italian Renaissance.


Could you please pass on this suggestion to the developers? Thanks.

Alsee (talkcontribs)

That sounds like a nice idea when you assume that you will be gaining the end of the sentence. However in reality there's going to be a maximum preview text length, which essentially changes this into a proposal to drop the first half of any sentence that would be incomplete. When viewed that way, displaying the partial sentence is almost surely preferable to not displaying it.

182.57.75.4 (talkcontribs)

Thanks for the reply. I agree with your assessment of the issue, and I had thought about it too. The reason I still believe it's an issue though is because I observed that a large part of the time, the incomplete sentence actually caused me to open the link in a new tab to see what the next word was, thus defeating the very purpose of the preview. If many other users have also experienced this same behaviour, it might be worth fixing it.

To explain better, considering the example provided in my original comment, the preview ends with "holds a collection of priceless", which immediately begs the question: priceless what? Whereas, using the rule of only including complete sentences but not crossing the word limit, the preview would reduce to:

The Uffizi Gallery is a prominent art museum located adjacent to the Piazza della Signoria in the Historic Centre of Florence in the region of Tuscany, Italy.

IMHO, this brief extract fully serves the function of a link preview, without the added "discomfort" of having a broken sentence. An ideal compromise might be to add a setting to "Include full sentences only" in the page preview preferences, but I'm guessing this might unnecessarily complicate matters.

Essentially, I suppose it boils down to seeing which option more users prefer: a shorter but complete paragraph, or a longer but broken one?

HappyDog (talkcontribs)

Completely agree. I've been using the link preview gadget for years, and I don't recall this being an issue there.

With this new implementation we get cut off in the middle of the sentence, with the text just fading out. The reaction is to try and scroll or to try and find the 'expand' link that will complete the sentence - basically to try and get the rest of the sentence to appear. As per previous poster, this kind of defeats the point of the preview, if you need to click through to finish the sentence.

I really appreciate the design work that has gone into this, but it nevertheless feels like a step backwards, due to this issue. Looks pretty, works less well.

Please take a look at what the previous gadget did, because that worked well.

Reply to "Suggestion: End Preview Text At End Of Sentence"