Talk:Page Previews/2014/10

Hovercards provide you with a short summary of an article whenever you hover over a link to it.

Please give us feedback on your experience using this beta feature so we can change and improve it. All languages welcome! You can read more about the feature here.

Archived discussion for this page are available at /Archive 1

Note: this page is using Flow; to give feedback on Flow, please use the Flow talk page

Stupendo / Wonderful

Ma sarebbe necessario aggiustare la quantità di testo incluso (almeno che sia significativo) e soprattutto se i wikilink puntano a sezioni e non ad intere voci, inserire queste e solo parte dell'introduzione Giudark (talk) 22:46, 1 October 2014 (UTC)

From Google Translate : But it would be necessary to adjust the amount of text included (at least that is significant), and especially if the wiki links pointing to sections and not to entire items, and only enter this part of the introduction

Right now we make the text snippet automatically pull from the article and do just a little cleanup to remove templates that might render strangely or no help people get the immediate understanding that they need to continue reading the article. We've certainly gotten the feedback that user might want to manually create the snippets, more as summaries, we can definitely investigate this in the future. However at the moment we want to get the automatic previews in front of people to see if it is useful, once we can validate that, we'd love to see how the content displayed could be better curated by editors.

Traduzione Automatica: Adesso facciamo lo snippet di testo estrarre automaticamente dal l'articolo e fare un po 'di pulizia per rimuovere i modelli che potrebbero rendere stranamente o no aiutare le persone a comprendere immediatamente che hanno bisogno di continuare a leggere l'articolo. Abbiamo certamente ottenuto il feedback che l'utente potrebbe desiderare di creare manualmente i frammenti, più come sintesi, possiamo senz'altro indagare questo in futuro. Tuttavia in questo momento vogliamo ottenere le anteprime automatiche di fronte a persone per vedere se è utile, una volta che siamo in grado di confermare che, ci piacerebbe vedere come il contenuto visualizzato potrebbe essere meglio curata dai redattori. Jaredzimmerman (WMF) (talk) 23:04, 2 October 2014 (UTC)

Enable by default in el.wikipedia

There is consensus to enable Hovercards for all users (and readers). Some users asked to increase the delay of the popup by 0.2 sec. Some changes to local templates (to prevent showing out of context icons) are ongoing. You can enable it immediately. Geraki (talk) 11:16, 5 October 2014 (UTC)

Geraki, thank you, we're working on some finishing touches. We'll sync up with you soon on figuring out a deployment. Jaredzimmerman (WMF) (talk) 18:12, 14 October 2014 (UTC)

Hovercards & Navigation Popups don't coexist well.

If I have Hovercards enabled, Navigation Popups don't work well. As an editor who uses his Watchlist a lot, Navigation Popups are more important to me.

But why not merge the two? Lentower (talk) 23:55, 10 October 2014 (UTC)

Re: Coexistence - you should only get one or the other (per the image of the settings panel, at Beta_Features/Hovercards#Settings). However, I think there's a bug that affects Firefox, causing that to not work properly. I've re-opened bugzilla:62952 to examine that.

Re: Merge - Long term, that's the goal. The underlying architecture of Hovercards should enable it much greater extensibility and maintainability, than the Navpopups gadget code. Sadly, Navpopups is in need of a complete rewrite (the volunteer devs who maintain it say so) because it's got so many years of cruft and quick-fixes layered on. Porting the functionality over for full (or damn-near) feature-parity will take a long time, because Navpopups is so complicated and is used in so many niche (but important) ways. Work hasn't started on that yet - they're still validating the solidity of the current simple&base-layer code.

HTH. Thanks for the feedback. :) Quiddity (WMF) (talk) 03:07, 11 October 2014 (UTC)

Thanks. i wish I could have the functionality of both NOW. Lentower (talk) 16:33, 11 October 2014 (UTC)

What aspect(s) of Hovercards do you most appreciate?

There are possibilities of adapting Navpopups-gadget somewhat, in the short term. Either via personal.css or even by tweaking the main gadget's code. Quiddity (WMF) (talk) 19:13, 11 October 2014 (UTC)

the problem with navpop gadget is not the functionality, but the atrocious code (you can think i'm bad-mouthing it, but read what the maintainers themselves write in edit summaries when they have to modify the code and fix bugs...)

personally, the 3 enhancements i'd like to see in hovercards are:

1. when the link has an anchor, show some sentences from the anchor (typically a section), instead of the intro
2. learn to show diffs when the link is to a diff, e.g. from page history, recent changes or watchlist.
3. add to the "settings" form (the gear menu) an option for "text only".

peace. קיפודנחש (talk) 21:30, 16 October 2014 (UTC)

Yup, the Navpopups maintainers are happy for it to be fully rewritten and extensionized. That will take a while though, so in the meantime we've got to cope with the 2.

Re: 3 enhancements:

1. Filed as bugzilla:63792 (against extension:TextExtracts which Hovercards is using for that aspect)
2. The current plan is to have 2 levels of complexity: with Hovercards as the simple-version primarily designed for readers (so no diff link previews), and Navpopups as the advanced version for more editor-focused use-cases. (eventually having Navpopups' features ported into the new Extension, rather than in the old gadget, but still keeping those features separated as an "advanced" option.)
3. Hmm, interesting idea. That is already possible with navpopups, but I'm not sure whether it is with hovercards. I'll ask, and/or add it to the list of suggested options. Quiddity (WMF) (talk) 00:16, 17 October 2014 (UTC)

What about creating a wiki page comparing navpop vs Hovercards functionality? Then people could voice their opinions about the most sorely missed features in Hovercards which are available in navpop. Kazkaskazkasako (talk) 14:32, 10 November 2014 (UTC)

Image extraction ignores content in galleries?

For https://en.wikipedia.org/wiki/Pioneer_Race_Course the image used in the hovercard is the San Francisco seal, apparently from the Template:San Francisco template. This is weird, since there are four other images in the article that might be used. LuisVilla (talk) 18:14, 12 October 2014 (UTC)

I noticed this. It looks like "Extract" the code that pulls the image is ignoring content in galleries. Jaredzimmerman (WMF) (talk) 18:10, 14 October 2014 (UTC)

Extension:PageImages shouldn't be ignoring the first image, which is not (and was not) part of a gallery... Ping@Prtksxna: Are you familiar with this problem? Quiddity (WMF) (talk) 22:02, 15 October 2014 (UTC)

Captured in bug 72276 Jaredzimmerman (WMF) (talk) 20:53, 20 October 2014 (UTC)

3 issues

First off, hovercards are wonderful. I really like the design of them, and the way the images are cleverly fitted. However, I have noticed 3 suggestions/problems based off my use of them:

• View article rating in the hovercard: this would be very useful as an editor. Even if this is just shown with a colour, corresponding to those in the gadget that shows an assessment of the article's quality as its header.
• When opening a new tab, the hovercard stays open, which is annoying when you return to the original tab. This could be fixed with a time-out or something.
• 2 sentences minimum. Navigation popups shows more information, and the mid-sentence cut-off on hovercards is just plain annoying.

A big thank-you to the developers who are creating this tool; it's really useful! Thennicke (talk) 05:52, 17 October 2014 (UTC)

Thanks for the positive/constructive feedback!

1. Note to the developers, Thennicke is referring to the gadget documented at en:User:Pyrospirit/metadata (which I also use, and really value). However, I'm not sure how expensive the API call is for that, as the gadget itself has to manually search the article's talkpage and find the metadata given in the wikiproject banners. This idea might have to be punted for quite a while, until a better metadata storage system is implemented. (At least for Hovercards, which are intended to eventually become a default-for-all-readers feature, and need to work rapidly and scalably). Also because the gadget is only available on Enwiki (afaik).
2. That's filed as bugzilla:66261.
3. I believe the quantity of text is calculated based on the dimensions allocated to the Hovercard. The only way to fit more text in, would be to reduce the font-size. (Or to change the entire design scheme). There is bugzilla:65845 which is to add an ellipsis at the end of every excerpt - do you think that would reduce the annoyance of the mid-sentence cut-off? Quiddity (WMF) (talk) 20:20, 17 October 2014 (UTC)

Thanks for the reply Quiddity!

The mid-sentence cuts are simply the most annoying thing ever, because the flow of information is just truncated. Adding an ellipsis will at least show that the sentence has been truncated, and I fully support that idea. However, from a user's perspective, sentences need to be full, if possible (unless they are extremely long, in which case - ellipsis).

To achieve this, font size could be reduced a few stops without issue, because at present it's quite large (which is, of course, nice). The algorithm below could be used in tandem.

Repeat

If the picture is going at the top,

make the text area higher

If the picture is going at the side,

make the text area wider

Until the desired number of sentences fits

Where desired number of sentences = 2, ideally. One other idea which I just had is that the pictures themselves could be letterboxed to some extent for the preview.

If the picture is going at the top,

letterbox horizontally

If the picture is going at the side,

letterbox vertically

This would give a little more text space and would be relatively inconsequential, and I think I vaguely remember some websites doing similar things. Anyway, those are just ideas; the main complaint I have as a user is that I really don't want sentences cut half-way, and that just one sentence isn't useful enough.

Sorry to give you guys more work, but I'm sure that good will come of it. Thank you again! Thennicke (talk) 03:05, 18 October 2014 (UTC)

Too intrusive for my taste, but

I am a Wiktionary contributor.

1. It seems to show up when I don't want it to, so I've disabled it.

2. If I could specify the content that showed up, it might be worthwhile for me. For example, a regex, a heading and following content, specific templates. DCDuring (talk) 16:49, 17 October 2014 (UTC)

Getting Extension:TextExtracts to work with #section anchors was harder than expected. It's filed as bugzilla:63792, but I'm not sure of the details beyond that. Once it does work with section anchors, and also cross-wiki (both on the to-do list), this should prove to be marvellous for getting Wiktionary content more visible throughout the other projects.

Re: "specify the content that showed up" - could you elaborate on that a little, as I'm not altogether sure what you mean. Do you mean a per-person specification (user.js type thing), or a per-page/per-namespace specification, or a per-wiki specification? I know the latter has been considered (eg working differently for links to Wikivoyage, or Wiktionary, or Wikidata) but hasn't been researched in-depth yet. A few examples of what you mean, would help. :) Quiddity (WMF) (talk) 20:10, 17 October 2014 (UTC)

I'm interested in per-person specification. It's a question of speeding editing by looking for specific page content. I use categories, searches, dumps (with perl), now. Working through short lists looking for relatively transitory content would be expedited by such capability. I don't have a good sense for the resource intensity of such a capability. I suppose this is probably more in the nature of an enhancement of w:User:Lupin/popups.js, which sometimes helps, but often doesn't display what I need. DCDuring (talk) 16:06, 18 October 2014 (UTC)

Just enabled this new function, and pleased in the main. Thanks for the work behind it.

My thoughts;

-Yes, agree in increasing the time delay before the Hovercard pops up. I've found personally that the pop-ups appear when I'm simply moving slowly about the pages.

- I would like to see more content in the cards myself too, or a customisable feature to have say, "advanced", as well as "simple"; no images / text to 1000 characters / section choices perhaps.

Regards Jams Watton (talk) 12:06, 12 November 2014 (UTC)

Doesn't Work on Hebrew Wikisource and Wikibooks

I like this feature, it's very user-friendly and helpful :) I've noticed that it doesn't work on Hebrew Wikisource and Hebrew Wikibooks. Can you please check the problem? Guycn2 (talk) 16:38, 20 October 2014 (UTC)

Hello,

Thanks for your feedback. Hovercards are designed to work on wikipedia pages mostly.

We have not worked on formatting content for other wiki's. Although we would love to tackle these other projects, hovercards is a beta feature there is pretty limited development help on this. Vibhabamba (talk) 19:51, 20 October 2014 (UTC)

Ok, thank you. Guycn2 (talk) 03:23, 21 October 2014 (UTC)

Z-Depth Issue

Template error, not Hovercards

When on pages such as https://en.wikipedia.org/wiki/Wikipedia:Reference_desk/Computing the Hovercard is partially hidden by the navigation bar on the right of the page when hovering over a link. SDowns96 (talk) 08:41, 21 October 2014 (UTC)

There were z-index overrides at en:Wikipedia:Reference desk/header/nav/aux and en:Wikipedia:Reference desk/header/nav, for unknown reasons. I've removed those, and left a comment at en:Wikipedia_talk:Reference_desk/header/nav#z-index in case I overlooked something. Quiddity (WMF) (talk) 18:44, 21 October 2014 (UTC)

Bug: Does not inherit "size" property of SVG images in infobox

(might happen with non-svg images too - I haven't tested)

If an svg image whose default size is very small, is then embedded in an infobox and resized using |size=x property, the hovercard still shows the image in its small, default size. Haha01haha01 (talk) 12:00, 25 October 2014 (UTC)

Thank you for reporting this. Can you please provide the specific links for which you saw this, if you can remember them. Screenshots would be even better. Vibhabamba (talk) 19:05, 28 October 2014 (UTC)

It used to happen in all articles linking to "League of Legends World Championship" (https://en.wikipedia.org/wiki/League_of_Legends_World_Championship), however I fixed that by editing the default size on the SVG in the infobox and reuploading it. I don't really know how can I reproduce that without screwing with actual articles... If you have a working testing environment it should be pretty easy to reproduce, just take a small svg (the one that caused me problems back then is https://upload.wikimedia.org/wikipedia/en/archive/7/7b/20141025115506!League_of_Legends_World_Championship_Logo.svg) and set it as the infobox image for an article, then link to that article from somewhere else and watch how the hovercard looks. Haha01haha01 (talk) 19:38, 30 October 2014 (UTC)