Talk:Page Previews/2016

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

• Current blockers to turning this on for anonymous uses by default are captured here: https://phabricator.wikimedia.org/T70860
• All issues with potential work attached to them tracked here: https://phabricator.wikimedia.org/project/view/765/

Hovercards - Exponents do not display

For example, the English Wikipedia article Earth mass has 10²⁴ at the beginning. In the hovercard, this displays as 1024.

Edit: Why didn't the sup work? Numbermaniac (talk) 00:57, 6 January 2016 (UTC)

This issue is documented in Phab:T112137 and being discussed there. Prtksxna (talk) 23:26, 6 January 2016 (UTC)

Wrong thumbnail on Ambrosini SS.4

When hovering over Ambrosini SS.4 in see also https://en.wikipedia.org/wiki/Kyushu_J7W the image shown on hovercard is different than the one from the article. Oxmaster (talk) 23:52, 15 January 2016 (UTC)

We use Extension:PageImages to get thumbnails for Hovercards. In this case, for some reason, it is getting the image under the Operational History section rather than the image from the infobox. Prtksxna (talk) 01:02, 17 January 2016 (UTC)

Extra bolded words

I don't know the extent of the issue, that I rise from a single observation: I use the feature in the catalan Wikipedia and I realized that the hovercard on the ca:Montellà link puts in bold the three occurrences of the word "Montellà" while only the first one is bolded in the "original" page. Furthermore, in the second and third occurrences the word is part of a more complete expression, namely "Montellà de Cadí" and "Montellà i Martinet", thus creating a strange appearance. Is this a general "extra bolding" problem that should be addressed? FranSisPac (talk) 16:49, 19 January 2016 (UTC)

The extra bolding is actually a feature. As we show only the plain text excerpt of the article, we manually bold the title. You can read more about it on Phabricator - https://phabricator.wikimedia.org/search/query/Ud8o6SM3t_uP/#R Prtksxna (talk) 23:58, 19 January 2016 (UTC)

Expand images when hovering

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I'd like see it expand images in a hovercard when you mouse over them. Currently images are a bit of an all-or-nothing. Thumbnail or fullscreen.

Even just a hovercard containing direct links to the images sizes available on the image info page would be a handy shortcut. 14.2.61.33 (talk) 19:14, 27 January 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

How can IP users enable this?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

How can not-logged in users enable this feature? I'm especially referring to the German wikipedia.

If it is currently not possible for IP users to enable you can take this as a suggestion. :) rugk (talk) 13:45, 30 January 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Last edited

A lot of people are talking about the last edited feature. It was discussed here. Cole128 (talk) 20:25, 15 February 2016 (UTC)

Interwiki hovercards?

Apologies if this has been mentioned but it'd be great if hovercards worked cross-wiki. So that hovering a :de:something link on EN wikipedia would still bring up a card. SSneg (talk) 17:45, 17 February 2016 (UTC)

I fully support this idea. The work-around is to individually register with Hovercards on each language you might use. As an editor and researcher who constantly needs to refer to non-EN wikipedia articles which simply don't exist in English, I came here to make to make just that point. - but found you had beaten me to it. (Great minds think alike, eh?)

A bigger question this poses is why can't all preference and choices made in one language wiki be applied across the board to all of them. I have no idea where that suggestion would best be posed. Anyone? Nick Moyes (talk) 12:10, 18 February 2016 (UTC)

@SSneg@Parkywiki Thanks for this idea! I just created a phabricator ticket for the first (interwiki hover) and second (interwiki settings). I don't see it as a blocker for rollout, but they are good improvement ideas.

Since you both seem to be interested in hovercards, I'd be curious to hear your thoughts around starting a community discussion raised her: Talk:Page Previews/2016#h-Discussion_and_consensus-2016-02-22T15:28:00.000Z Jkatz (WMF) (talk) 18:44, 25 February 2016 (UTC)

I'd be happy to follow the discussion and contribute, as appropriate. I'm more of a practical editor than a 'wiki-nerd' so rarely understand the extreme and often pedantic viewpoints expressed by editors here. There is clearly concern that sudden rollout will elicit a loud "turn it off" response, which would be a shame with Hovercards being so useful to everyday users.

Is there not a middle ground (which no-one seems to have suggested yet, as far as I can tell)? I've only myself discovered the joys of changing Preference settings in the last few months (after a year of serious editing and 5 years here in total). Why not use the banner advert, normally reserved for annual fund-raising - to promote the equivalent of 'Wikipedia tooltips'. It could encourage non-logged in users to join up and login to Wikipedia to gain better functionality. And for those who are logged in, it could advertise the benefits of proactively selecting their settings. (A bit like the regular Facebook 'check your privacy settings' reminders - but so much more useful than that!

I keep a log of all my suggestions for improving Wikipedia. Should you be interested, they're added to here: [[User:Parkywiki#Feedback_and_Suggestions]] Nick Moyes (talk) 00:21, 28 February 2016 (UTC)

@Parkywiki Thanks for showing your suggestions! I can't wait to review and might reach out to talk about 1-2 of them--at first glance a few look really interesting.

I totally sympathize with your choice to stay out of the dialogue, but also hope you get involved from time to time. Practical editors' viewpoints are really, really important and we benefit from more perspectives.

Interesting idea around the banner as a means to drive feature adoption. We used it on the much-reviled "collections" feature which is currently in mobile web beta (but being disabled tomorrow), and it drove a lot of feature adoption. Unfortunately, asking our readers to login will create a huge stress on our infrastructure due to one of our major cost-saving efforts we use (we serve the same page to everyone unless you are loggedin). So unless we have a really good reason for readers to login (like having saved bookmarks or interactions), we need to avoid it. So for now, we are stuck with all or nothing. Jkatz (WMF) (talk) 19:43, 29 February 2016 (UTC)

Glad to be of help with the suggestions.

Interesting explanation about serving up the same page to non-logged in users. I can appreciate the issue now. But why not still consider using the banner as a way to serve up just two optional page formats? (One 'standard', plus one 'feature-enabled') Whether it's a per session choice, or memorable by means of a cookie probably isn't too important. But you would soon get an idea whether or not the vast numbers of real-world users like the feature, and whether they choose to use it. You'd then have the evidence that could inform the decision whether or not to include it in full deployment.

Either way, I hope the sticking cards in Windows gets resolved first. It doesn't put me off at all, but I suspect most people probably expect Wikipedia to work smoothly every time. Nick Moyes (talk) 12:55, 1 March 2016 (UTC)

interwiki links in user's preferred language

this request/idea was raised in hewiki technical village pump.

the requested feature is to allow users to define "preferred language". when hovering above a link, where the linked article has interwiki to this preferred language, the hovercard content will be generated by the "preferred language" wikipdia rather than the local one, and natually, it will also link there.

peace. קיפודנחש (talk) 16:16, 21 February 2016 (UTC)

Sorry- This sounds interesting, but I am having trouble understanding what is being proposed. Can you show an example? Thanks! Jkatz (WMF) (talk) 21:33, 11 March 2016 (UTC)

i will try to explain the behavior and illustrate a use case to justify the the rationale, at the same time:

Judy has language skills of de-N and en-4.

since enwiki has more articles than dewiki, there must be at least one article in enwiki with no interwiki in German. (say, en:Marauna abati ). for one reason or another, Judy reads this article.

this article has internal link to en:Beetle, which *does* have dewiki interlink: de:Käfer (it's even a featured article!) Judy would prefer to get the hovercards for de:Käfer, instead of en:Beetle when she hovers above "beetle".

She is willing to "pay the price" of slightly longer wait for the extra api call when hovering above a link ( action=query&list=langlinks&lllang=de&titles=Beetle , receive "Käfer", then execute the call to build the hovercard against dewiki. if langlink does not return any article in dewiki, build the hovercard by calling the local wiki, same as it's done now. this is one extra api call over present workflow).

use global preferences (meta? or maybe clicking the little gear symbol on the hovercard?), so Judy can get the same behavior on frwiki (Judy has fr-3 skills), arwiki, fawiki, and even fiwiki (she uses google translate to occasionally read articles in Finnish).

small extension of the above will allow Judy to say "whichever wp i read, give me the dewiki article if there is one, otherwise the one from enwiki, if this doesn't exist then frwiki, and none of those interwikis exist, give me the local hovercard"

of course, if such substitution occurred, the hovercard will also *link* to the target wiki, so judy can decide if she wants to read "beetle" on enwiki by clicking the link, or Käfer on dewiki by clicking on the hovercard.

i hope i did not bore you by this long and tedious explanation - apparently the short and succint i was going for with the original message was not clear...

peace. קיפודנחש (talk) 22:20, 11 March 2016 (UTC)

That is really helpful and a use case I, at least, had not thought of. On the one hand, this would be tremendously useful. On the other hand, it might be very confusing for users who then see different languages on hovers while on a single Wiki and for whom the hovercard behavior changes. From a cleanliness perspective I am not a fan, but it sounds like it could be really valuable to everyone who reads more than 1 language.

I created a ticket for it to gather other input: https://phabricator.wikimedia.org/T129909 Jkatz (WMF) (talk) 18:54, 14 March 2016 (UTC)

Add the page in the Watchlist just with the Hovercard view

Hey !

It would be nice if we had the possibility, by a little button, to add the article in our watchlist, like the title said.

I don't know if it had been already said before, sorry for the spam in this case... :) GrandCelinien (talk) 17:20, 21 February 2016 (UTC)

I think this is useful just at first glance: I don't think anybody wants (or should be motivated) to add articles to the watchlist without having at least viewed (note: that doesn't equal read) the full article at least once. What instead would be useful is a to-read list (or alike) that one could add articles to like described. Here's the relevant extension: Extension:Gather

Would be interested what you and especially the developers would think about adding support for it to hovercards. Fixuture (talk) 19:31, 7 March 2016 (UTC)

I think this is a good concept, but agree with @Fixuture that watchlist probably should only come after viewing the article. One thing we have implemented on the android app is a similar feature that makes a little more sense to me. There is a link preview similar to hovercards on the app, and on that you can choose to 'save the article' for later reading. This is something we have on iOS too on the new feed--you see a preview and can save for later.

I think there is an important distinction between wanting to bookmark and article and wanting to track the diffs. We don't have a great bookmarking feature (the recently pulled gather collections experiment was a failed effort in that direction), but I hope we can keep moving in that direction. Jkatz (WMF) (talk) 21:32, 11 March 2016 (UTC)

OK well it's true. I was thinking like a patroller, but most of the contributor doesn't need it. The idea of a "read latter" button is good. Thanks for the answer ! And sorry for my bad english :( GrandCelinien (talk) 16:36, 13 March 2016 (UTC)

@GrandCelinien Your english is great! ;) Jkatz (WMF) (talk) 18:45, 14 March 2016 (UTC)

Discussion and consensus

Does the plan for deployment of this feature include getting community consensus in advance?

I ask because I was considering starting a discussion on this at the English Wikipedia, but I don't want to mess up anything if someone with more involved here was planning to do it. If it's not planned, I'd also like to avoid a situation of this being started too early, causing discussion to circulate around remaining major bugs, instead of the real merits and issues of the feature as a whole.

In my experience, these kinds of discussions are far easier to have in advance of deployment, as the community atmosphere tends to be not at all conducive to calm discussion regarding the pros and cons of a change, when the discussion starts following a major change being pushed forward without sufficient discussion and consensus.

(See for example the enwiki discussions regarding the watchlist bolding, in which the same community reacted in two polar opposite ways to the same proposal, when first given the opportunity to discuss the proposal in advance (enthusiastic response) and when reacting to its unexpected implementation (about as angry as that community gets, strong "kill it with fire" attitude).)

Since the development seems still ongoing, and it looks like it might get a deployment date set independently by the developers, the discussion would probably be regarding whether, once the deployment date arrives, to keep the feature or disable it (either by Phabricator request or direct disabling).

However, I ask that you please consider simply not having a set "deployment" date at all, and have Hovercards as an available feature to be enabled upon request, once development has progressed far enough (marked "stable"). While discussion will probably successfully propagate to a number of wikis in either case, many will still be caught off-guard if an non-consensus-backed deployment is implemented. Communities in that situation tend to be more likely to respond with a "shut it down first, then we can discuss it" attitude, and it's generally much harder to get consensus for re-enabling a disabled feature than it is to get consensus for turning it on in the first place. Discussion in advance allows for useful feedback and suggestions, and allows for a much less contention between the communities and developers.

I am willing to help out in whatever way would be useful. Yair rand (talk) 15:28, 22 February 2016 (UTC)

The development is sort of on hold, since there are no real developers allocated to it right now. There is also no plan for deployment at this time, but if communities request it, it can maybe be raised on the list of priorities.

Any help is appreciated. Pinging @Prtksxna as one of the primary developers of this feature.

Also: List of known issues. —TheDJ (Not WMF) (talk • contribs) 19:12, 22 February 2016 (UTC)

Oh.

I was confused by some of the Phabricator tickets, which gave me the impression that deployment was soon. My mistake. Yair rand (talk) 19:57, 22 February 2016 (UTC)

Not as far as I'm aware, but stuff changes so often that I might be mistaken of course. —TheDJ (Not WMF) (talk • contribs) 00:07, 24 February 2016 (UTC)

I've had this extensions enabled for what seems ages by now. Occasionally the hovercard fails to disappear properly, but this happens rarely enough that I wouldn't really consider it a reason not to deploy it. It's a bit sad that so many people have to miss out on this feature.

@Jkatz (WMF): Do you know what the status of this feature is? —Ruud 11:29, 25 February 2016 (UTC)

Seconded. I personally really like hovercards (despite the annoying getting stuck bug, which still appears more often than I'd like it to) and I think they make UX nicer. It should be tested, of course, whether users really use them (by e.g. measuring the time between appearance and disappearance of the card - are people even pausing to read?) and whether there is any notable A/B difference in people's behaviour with/without the hovercards. SSneg (talk) 14:35, 26 February 2016 (UTC)

Good comments. I was not aware that the bugs are still appearing. where you aware of this?

"We" (I was not a part of the project then) tested out on 2 smaller wikis for a month and collected results in mid-2015-- while the qualitative feedback was overwhelmingly positive (still need to post those results), I did the timing analysis and it was not ideal--something like ~1.5 as the median time spent.

On Android, we know people like it because they end up clicking on more links, and the timing is more like 5 secs. However, there is more info in the android previews and you have to click to close it, so I would estimate that 3 seconds for a hover would be ideal.

As a result, we increased the amount of time you have to hover before the card appears, but have not re-run the test.

We have not run an a/b test, yet because we can't track sessions yet (due to our privacy concerns it will be much harder to implement). Additionally, it would be hard to evaluate the results: With hovercards, you expect fewer pageviews per session and even faster/shorter sessions--but you expect the same if someone is having a bad time. Return rate would be a good indicator, but we are unable to track that for same reason as above. Any thoughts on how to measure success? Jkatz (WMF) (talk) 04:18, 29 February 2016 (UTC)

Perhaps a less fine-grained metric will do: currently 45,035 users have opted-in to Hovercards, do you know the number of users that opted-in at some point and then opted-out again? —Ruud 08:19, 29 February 2016 (UTC)

@SSneg here is a list of tasks that continue to 'block' the feature being released: https://phabricator.wikimedia.org/T70860 1-3 of them have easy fixes, and a bunch of them are just hard for us to reproduce--meaning they might not be valid. There is nothing here that is a widespread, significant problem, as far as I can see. Jkatz (WMF) (talk) 04:50, 29 February 2016 (UTC)

Thanks @Yair rand for starting this thread and @Ruud Koot for pinging me!

This is a very timely discussion! As @TheDJ pointed out, hovercards have suffered from not having empowered ownership within the foundation for sometime. But it is a great product that keeps on getting better. During Quarterly planning for the next quarter, it was highlighted as a great win for Wikipedia and a top contender for our team to focus on next quarter, provided we have community approval and are able to iron out any remaining, reasonable and significant concerns.

I would very much like to start a discussion as soon as possible about potentially moving forward on rolling hovercards out on 1-n wikis starting sometime in the April-June quarter. I actually fired up this page to see the existing state of discussion in order to figure out how to do this, when I saw your post yesterday! I am unfortunately in meetings quite a bit and did not have a chance to respond until now.

Our goal on reading team is to experiment with bringing the community in at the very beginning of the ideaion process (what are the problems we should solve for readers? what are the high-level solution types), but with products that are already in the pipeline like hovercards we are already too late for that.

Howevere are not too late to have an open discussion about the feature and what the potential blockers for roll-out are (whether they be permanent or temporary).

My question for everyone on this thread is, what do you think the best approaches to such a discussion should be? A proposal, an open comment period? Prior to any discussion, I would like to post the results of our test-rollouts on Greek and Catalan Wikipedias for a month in 2015 and summarize the existing concerns. If anyone would like to run point on this (and provide a more neutral view), I would be more than happy to provide the materials. Thanks again--I really appreciate the proactive communication. Jkatz (WMF) (talk) 17:48, 25 February 2016 (UTC)

I think the best way to go about this would be if a community member (e.g. @Yair rand) would make an honest case on the Village Pump on why this feature should be promoted from an opt-in beta feature to an opt-out one. Ask for people's general opinion on this issue, whether they think a formal RfC is necessary at a later date or not, whether they see any show-stopping issues at the moment. Some of the developers could help answer some of the questions that would undoubtedly be raised.

The developers of course must have the time to actually finish and deploy this if people are positive about it, but if that would take a few more weeks afterwards then that wouldn't necessarily be a huge problem either. —Ruud 18:29, 25 February 2016 (UTC)

I could write it up as a proposal on VPR. I'm not quite sure of what stage of development the feature is at, though. Are there any bugs serious enough that it would be reasonable to state in advance of discussion that they would be blockers to deployment? Some in the community might make their own suggestions for bugs to be considered blockers, but it would probably be helpful to get the most serious ones out of the way beforehand (assuming there are any remaining serious bugs). Some editors will probably have their own suggestions for some changes. In any case, it would probably be best to make it clear that it's not a proposal for immediate deployment, and that community input can result in tweaks/fixes as necessary. Also, just to be clear, if this does get implemented/enabled by default, can we expect it to be maintained long-term? Being implemented as an extension (as opposed to a gadget or similar) means that the community can't easily do "direct" fixes as necessary, which might make some a little uneasy.

@Jkatz (WMF): Are you planning to post the test-rollouts-results and summary to this page (Hovercards)?

(As a side note, are there any good recent English-language screenshots of Hovercards? I haven't been able to find any.) Yair rand (talk) 01:36, 26 February 2016 (UTC)

@Yair rand: I've made a screenshot. —Ruud 13:41, 26 February 2016 (UTC)

Here's one I've just made for you, though there are other examples available in Category: Wikimedia Hovercards

Nick Moyes (talk) 01:42, 28 February 2016 (UTC)

@Yair rand Hey, thanks for taking the lead on this! As far as the survey goes, I posted the results here: Beta Features/Hovercards#Qualtrics Survey Results. I can't post the file because individual answers haven't been vetted for personally-indentifiable information. Let me know if this helps!

As I mentioned in an above response to someone else, all blocking bugs are listed here: https://phabricator.wikimedia.org/T70860 Though there are a number of bugs, most look to be very uncommon. One issue: our engineers do not tend to use Windows (we have devices in office, but most of the web team is remote) so if there are any community member coders out there who want to tackle the windows bugs, that would be really helpful. Jkatz (WMF) (talk) 05:44, 29 February 2016 (UTC)

@Yair rand Hey, just wondering if you had a time frame in mind for bringing this up more broadly. As I may have mentioned, the team is considering making this their goal for Q4 (April-June), but only if the various communities want it.

On my end, I am working on the blocking bug list, as a few more need to be added. I know it is tricky to ask for feedback before the bugs are all fixed, but it will definitely help us prioritize fixing them! Jkatz (WMF) (talk) 05:23, 4 March 2016 (UTC)

@SSneg @Ruud Koot @Parkywiki @TheDJ

Hi! Before the WMF Reading Team commits to finishing and shipping hovercards in the next 3 months to at least a few wikis, I really do want to make sure there is community desire for this.

@Yair rand had offered to reach out and figure this out, but seems to be busy on other things (no judgement!). So I just wanted to reach out and see if anyone else wanted to partner with me to gather input on hovercards. @Alsee spearheaded an RFC for gathering feedback for related pages and this should launch soon. I am not sure that is the method to use here, but this level of cooperation between WMF and community intuitively feels like the right thing to be trying.

Anyone want to propose something or setup a call/IRC chat to talk through ideas? Jkatz (WMF) (talk) 21:07, 11 March 2016 (UTC)

Hey @Risker I know you are in high demand and incredibly busy, but I was wondering if you could weigh in on the above (the comment just above this is a rough summary of the issue). Below I was writing to someone else about how the most important expertise I am seeking is expertise in community decision-making, and your name flew into my brain immediately. No worries if you don't have time and hope you're doing well! Jkatz (WMF) (talk) 04:00, 14 March 2016 (UTC)

@Jkatz (WMF) If you have a questionnaire or any other material that can be translated into Russian, I can share that on the RuWiki and see what people say. SSneg (talk) 08:29, 12 March 2016 (UTC)

Thanks! That will definitely come in handy. I will let you know when we figure out the format. Jkatz (WMF) (talk) 03:50, 14 March 2016 (UTC)

@Jkatz (WMF) I'm probably not technically experienced enough to help gather feedback across a broad spectrum of users. I'm happy to ask for views from a couple of the Wiki Projects I'm involve with, if this helps, or to select a few at random and pose questions. Happy to ask @Victuallers for his advice/input. (Far more experienced than me) Just let me know how an ordinary editor like me can help.

One interesting thought: Are Hovercards notable enough now by their coverage in third party news site to merit a Wikipedia page of their own? And could this help? Nick Moyes (talk) 16:44, 13 March 2016 (UTC)

@Parkywiki

1. I don't think technical experience here is as important as community decision-making experience, but I both get your reluctance to initiate with the universe and appreciate your willingness to reach out to folks. I think we should keep that in our back pocket for now and maybe circle back--I expect reaching out on the Wiki Projects will be helpful once we have a place for people to chime in publicly.
2. Re: notability. I am not sure if it is notable enough (I'm still a relative noob). A quick search showed that there are about 5 articles on respected tech websites that mention hovercards, but generally in the context of 'beta features'. Maybe 'Wikipedia beta features' would deserve the page then. Either way, my guess is that notability is not going to be a factor in community decision-making. Jkatz (WMF) (talk) 03:57, 14 March 2016 (UTC)

OK - Provided someone can create the most appropriate place for discussion, I'm certainly happy to promote it if I can. To that end I've just made a rather gaudy Userbox which users can put on their talk page to show support for rollout from beta.

Not sure it will help much, but it seemed a fun way to promote it on EN:WP! I'm also not sure of the correct way to link to it in this wiki, so it's either this:{{User:Parkywiki/Userboxes/hovercards}}

or this as the full url: https://en.wikipedia.org/wiki/User:Parkywiki/Userboxes/hovercards Nick Moyes (talk) 12:23, 14 March 2016 (UTC)

@Jkatz (WMF) and Ruud Koot: Sorry for the delay. I've started a proposal at w:WP:VPR#Proposal:_Enable_Hovercards_by_default. I've also listed the thread on Centralized discussion. Yair rand (talk) 10:31, 16 March 2016 (UTC)

Excellent @Yair rand! Thanks a ton. I encourage everyone to go and chime in with your thoughts and concerns.

@SSneg Can we take you up on your offer to take the current proposal (above) and translate/post on Russian? Jkatz (WMF) (talk) 19:11, 16 March 2016 (UTC)

Ok! SSneg (talk) 20:33, 16 March 2016 (UTC)

@Jkatz (WMF), I posted this for discussion a while ago, these are the votes and comments so far:

• FOR (me)
• AGAINST (I prefer WP:Tools/Navigation popups, which are more informative)
• FOR
• FOR (The Navigation popups is useful for editors not readers and looks horrible as well)
• AGAINST due to extra slow-down of website performance but if the proposal goes through, no worries, I will just disable it
• AGAINST as long as template lang-xx is broken, otherwise FOR
• FOR
• FOR, one of the most useful beta features, haters can disable
• FOR, but please fix template lang-xx issue first
• AGAINST, prefer the Navigation popups SSneg (talk) 20:32, 29 March 2016 (UTC)

@SSneg This is great. Looks like its mostly positive. 2 concerns are that

1. nav popups will be disabled (they wont)
2. template lang-xx issue

Does anybody know what the template lang-xx issue is? Jkatz (WMF) (talk) 20:47, 29 March 2016 (UTC)

nevermind...found it here: https://phabricator.wikimedia.org/T115817 Jkatz (WMF) (talk) 20:49, 29 March 2016 (UTC)

Problems

In the German wikipedia, there is a problem with the depiction of the article IU (singer) [1]. --~ Christian140 (talk) 07:30, 23 February 2016 (UTC)

@Christian140 Hi, please could you tell us if the problem is still occurring, and if so, please describe the problem. Thanks! (Here's a screenshot: http://i.imgur.com/WKw7xiG.png which seems to be OK?) Quiddity (WMF) (talk) 23:07, 7 March 2016 (UTC)

Yes, it worked till I changed the picture recently. Now, the same problem occured again. Same in the article Seolhyun [[[:de:Seolhyun|https://de.wikipedia.org/wiki/Seolhyun]]]. See pic: http://imgur.com/ghY5xOz Christian140 (talk) 01:16, 11 March 2016 (UTC)

By the way: I am not sure if the error in the IU article now occured again because I changed the photo or just because I saved. I mean, it might could also have occured if I just would have changed the text in the article... I don´t now the reason for this failure. Christian140 (talk) 01:18, 11 March 2016 (UTC)

A problem could be the Korean template or just the Korean letter, cause in this article, everything works fine: https://de.wikipedia.org/wiki/Jun_Ji-hyun. Christian140 (talk) 01:24, 11 March 2016 (UTC)

If we open any link in new tab and come back to original page, the hover card is still being shown and does not hide until we open another hover card. Happening only sometimes. Karalgikarrahul (talk) 11:19, 24 February 2016 (UTC)

This issue is tracked at phab:T68261. Thanks for reporting. Quiddity (WMF) (talk) 23:04, 7 March 2016 (UTC)

Problem similar to that of above (with Korean article snippet being abruptly ended because of original language template) is visible in RU wiki with LANG-LV template, see screenshot: http://imgur.com/xfpiXDx SSneg (talk) 21:29, 3 March 2016 (UTC)

Hi, please could you link to the example, so that I can visit it myself? Thanks, and thank you for including a screenshot! :-) Quiddity (WMF) (talk) 23:45, 7 March 2016 (UTC)

@Quiddity (WMF)

You can visit this page and lookup phrase "Гатис Калниньш". When you hover on the link, it brings up a card that cuts half way through. Same happens when hovering over a few other links in that table, e.g. Вит Римкус, Гирт Карлсон (they all point to articles that include the lang-latvian template in the beginning). SSneg (talk) 19:26, 8 March 2016 (UTC)

Much thanks. I've added a note to the existing Phab:T115817. (It seems to occur for all instances of the family of lang-xx templates) Quiddity (WMF) (talk) 00:41, 9 March 2016 (UTC)

Another problem: the hovercards show images from an article's templates when an article has no other image. However the images of templates are most often too unrelated to the article's topic to be used as its image. Example: Wikipedia:Agnes Boulton shows an image of Wikipedia:Eugene O'Neill. Please disable exclude template images as potential images or otherwise properly restrict the possible hovercard-image. Note: the app has the problem as first reported here. Fixuture (talk) 22:20, 3 March 2016 (UTC)

another example reported today at :en:Wikipedia:Teahouse/Questions#mobile_wikipedia_gives_wrong_picture|https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions#mobile_wikipedia_gives_wrong_picture Nthep (talk) 13:49, 16 April 2016 (UTC)

And another problem: when hovering over Wikipedia:Sci-Hub (example) it shows the photo within the text while it would be better if it showed the logo of the Infobox website.

Not sure why that isn't done anyway -> shouldn't hovercards always show the first image in the article (with some exceptions)? Fixuture (talk) 19:24, 7 March 2016 (UTC)

@Fixuture I think they should but for now they seem to ignore any images in the e.g. Person template (and maybe all and any templates?). SSneg (talk) 20:06, 7 March 2016 (UTC)

@SSneg Well then I guess they should be disabled for all templates with the exception of all the infobox templates. Fixuture (talk) 20:42, 7 March 2016 (UTC)

I've requested more detailed information about exactly how Extension:PageImages works (which is what selects the images in the Hovercards extension amongst other uses), at Phab:T129183. Quiddity (WMF) (talk) 23:38, 7 March 2016 (UTC)

When hovering over links to articles which begin with a template, the content of this template is shown. I think the first few "real" sentences are more useful.

One example is the current version of https://de.wikipedia.org/wiki/Ecuador-Erdbeben_2016, linked from the main website of the German Wikipedia. El Fahno (talk) 19:28, 18 April 2016 (UTC)

The pop-up should disappear when I move the pointer away from the link Marco2024 (talk) 15:02, 22 April 2016 (UTC)

It doesn't work in my computer, or it seems. What's wrong? Elporche1 (talk) 07:11, 11 May 2016 (UTC)

Suggestions

Please click "Reply" to whatever suggestion you're referring to.

First of all I guess the usual procedure for feature requests, suggestions and alike is making a talk page entry so that it can be discussed and creating a phabricator task with the information gathered there if it's still considered a worthy suggestion afterwards - is that right?

Then here's my suggestion: would it be possible to display diffs on the watchlist as hovercards when hovering over them? This way smaller edits can easily and speedily be checked by editors. This would make the whole watchlist-checking process a hell of a lot more time-efficient. (And saving editing-time of editors is increasing the edit-amount they can bear per edit-session resulting in a increase in quality and content of Wikipedia.)

When there are multiple unsighted changes the shown diff should be combined and show the count of diffs in the merged diff. By a simple click the diff could be opened in a new tab if it requires some action by the user. So if these diffs are too long for this to be useful the user can simply open them in a new tab. Also there could be a setting with a maximum diff length to show in hovercards - but that's really just a user-issue; this feature would be of most use for checking small and copyedit edits and as said could speed up the watchlist process by a lot for many. Fixuture (talk) 19:53, 7 March 2016 (UTC)

To answer your first question:

"First of all I guess the usual procedure for feature requests, suggestions and alike is making a talk page entry so that it can be discussed and creating a phabricator task with the information gathered there if it's still considered a worthy suggestion afterwards - is that right?"

Yes! At least that is how I have been approaching it. Jkatz (WMF) (talk) 21:21, 11 March 2016 (UTC)

(why can't I indent my reply? it should be on the +1 level to the original post)

I think the huge problem with the watchlist UX shouldn't be solved by hovercards. The whole page needs to be rebuilt to allow for better preview of changes, patrolling of changes without opening the article, etc.

SSneg (talk) 20:10, 7 March 2016 (UTC)

I'm new to using Flow as well. This is why I edited my above post asking people to use the "Reply" button -> this automatically sets the proper indentation for the post (and that would be useful here as there are multiple suggestions in this thread). You can also manually set indentation by clicking the bottom right "Switch to the wikitext editor" button.

I do not think that it's a solution - just part of it; I rather see it as a major improvement than a solution to some specific problem.

>The whole page needs to be rebuilt to allow for better preview of changes, patrolling of changes without opening the article, etc.

But that sounds much like what I'm proposing. Also not sure how these goals can be reached better, I'm hoping for them to get actually addressed. And the hovercards might be easier and faster to implement than any major overhauls which probably aren't getting done anyway in the next few years.

Fixuture (talk) 20:38, 7 March 2016 (UTC)

Yeah, well, I expressly and intentionally pressed "Reply" and it did not indent my reply, because this is a bug of Flow (or a UX feature I cannot understand) :) When replying to the lowest comment in thread (or to the only one), the reply doesn't get indented. When replying to a comment that isn't the last one, the reply does get indented. See this 15-sec video demo: https://www.youtube.com/watch?v=qLy8ahKSCDU

Yes, this is exactly what you proposed only I'm afraid that WMF will invest into making hovercards something they're not (they were never meant for diff previewing, and WMF have no idea how to visualize a diff anyway) and as a result will think "Whoo, we've improved Watchlist", when WMF actually should actually improve Watchlist, from ground up.

So I'd suggest NOT making hovercards more complex than they should be and spend the relevant resourcesdirectly on improving

the Watchlist. SSneg (talk) 21:33, 7 March 2016 (UTC)

Re: Hovercards & diffs - Hovercards is originally inspired by the ancient and very popular gadget Navigation Popups (Navpopups). It does handle diffs, and this is exactly how I triage my watchlists - by slowly scrolling my mouse up the list of (diff) links! I even made a very short video about it, at File:Navigation_popups_quick_tour.ogv. Navpopups has a ton of features (as in, a seriously huge number of features - see the "Configuration" section), but the gadget is old, hard to maintain and improve, with only a couple of volunteer developers who know the code well enough to fix major breakages. The long-term hope/goal, is to create an "Advanced Hovercards" setting which will implement all the navpopups features (or 95+% of them). So people who like the simple version will be happy, and people who enjoy the advanced features of navpopups will be happy, and all the code will be more easily maintained and internationalized and further improved/extended.

Re: Flow indents. The current setup is intentional - it's designed to only indent when absolutely necessary, and thereby to try to have the best of both indenting-systems and flat-systems, see partial explanation at phab:T92400 - but it confuses almost everyone. There are plans to change it, probably to the expected "reply=indent" and with some sort of automated {{Outdent }} after reaching 10 levels deep. The main tracking task is phab:T108998, but I advise not getting into it; it's a known issue.

HTH! Quiddity (WMF) (talk) 01:06, 9 March 2016 (UTC)

Another suggestion: what about hovercards for categories? In my experience categories are pretty unknown and underused by the topic so this feature would also serve to improve that. It could display some metadata and examples (or just the upper asterisk* / space sorted main articles; or all entries of a category depending on the count of entries in it and eventual user-settings for logged-in users). An example for Wikipedia:Category:Psychoactive drugs (note: that's just a very rough sketch-up):

----

Main article

A psychoactive drug is a drug that directly and chemically affects a person's mental state when used or administered.

64 articles

• List of psychiatric medications
• Pharmacological Calvinism
• Psychiatric medication

39 subcategories

• Psychedelics, dissociatives and deliriants‎ (9 C, 37 P)

Categories: Neuropsychology Neurochemistry Drugs acting on the nervous system

---- Fixuture (talk) 20:27, 7 March 2016 (UTC)

re: Categories - Navpopups does this, too! e.g. http://i.imgur.com/c8ZrMVO.png It could certainly be improved with the details in your suggestion, though. See above, cf. long-term hopes/goals. Quiddity (WMF) (talk) 01:12, 9 March 2016 (UTC)

A function to edit them would be nice. Brakloginu (talk) 15:43, 11 March 2016 (UTC)

These are really great suggestions. It sounds like beyond the article-link usage, there are many ways that a 'summary/more-information' window could be useful. As @Quiddity (WMF) pointed out, the Navpopups gadget does many of these already and the ultimate goal is to migrate these to hovercards and to figure out which of these features should be part of the basic (reader) view and which should be part of the advanced (power user) view.

For tracking purposes, here is the phab ticket for adding the functionality: https://phabricator.wikimedia.org/T109796 Jkatz (WMF) (talk) 21:16, 11 March 2016 (UTC)

The hovercard should have the title of the page it's taking the text/images from. Sometimes the link is the page title, and in that case perhaps it's alright to skip it, but in other cases the link is not, and you have to click the link to find the title (or, I guess, look at the link on the bottom of your browser, but most people don't even know that's there, and what if it redirects?) M00n-sl473r (talk) 19:21, 14 March 2016 (UTC)

I think the cards should include the whole first paragraph or if that's too much it sure that it doesn't stop in the middle of the sentence. Fischbol (talk) 22:17, 12 April 2016 (UTC)

Non-free images in hovercards

I know that the first images in an article are not always used in the hovercards due to the image proportions, size or quality. However, these factors always seem to be changing. For example, in the articles: Nirvana In Fire, Legend of Nine Tails Fox, and The Journey of Flower, all of the images used in the infobox were adequate enough to be put as the image in their respective hovercards. However, in the last few days, the images have not been shown in the hovercards, and since the images are still used in the article, I feel that it's because the Hovercards do not accept pictures with those proportions or quality anymore.

But why? The images were perfectly fine before, but now they are unusable in the hovercard feature. Is there any way to let those pictures be used again in the hovercards? Plus it will be very nice to know what proportions and qualities that are allowed. Thanks

By the way, still love how helpful the hovercards are, but the image can be a very helpful visual aid. Tigress223 (talk) 00:19, 13 March 2016 (UTC)

Good question. I'm afraid I can't offer an answer, but would like to add that I think Wikipedia's Manual of Style/Lead Section and Featured Article guidelines will all need updating soon in order to catch up with the requirements of Hovercards.

It might also be worthwhile you enabling 'Mobile sidebar preview' in Wikipedia's 'Preferences>Gadgets>Testing and development' section to see whether or not the correct image also displays in Mobile view. Nick Moyes (talk) 16:36, 13 March 2016 (UTC)

Thanks for answering and I'll be sure to check that out. It's just that its frustrating that images that could be used before can't be used anymore, and you've lost a perfectly good visual aid with the image requirements forever changing. I hope somebody updates or changes it like it was before.

Again, Thank you Tigress223 (talk) 22:04, 13 March 2016 (UTC)

This is because we have been asked to prevent 'fair use' images from appearing outside of articles. This change rolled out here: https://phabricator.wikimedia.org/T124225

I believe this is well summarized by @Alsee here: Talk:Reading/Web/Projects/Related pages/2016#h-Image_chosen_is_sometimes_inappropriate-2016-03-12T14:55:00.000Z

It impacts almost all movies, books and albums on English Wikipedia. I don't know whether or not revisiting the fair use policy to include article previews is possible.

In lieu of changing policy, a mitigating solution would be to allow editors or readers to identify the images in an article that summarize it well. Jkatz (WMF) (talk) 18:43, 14 March 2016 (UTC)

I don't know whether or not revisiting the fair use policy to include article previews is possible.

I think I can help here. The policy prohibits their use for things like navigation purposes (like the Related Articles feature), but in this case you're using them in a preview of the article itself, along with a useful portion of the article text. I think that argument will probably be accepted. Would you like me to open a discussion on it to get firm clarification? Alsee (talk) 06:15, 15 March 2016 (UTC)

@Alsee I think this is more an issue of changing policy as opposed to interpretation, but I could be wrong. There was also a discussion here that seemed to indicate that, for at least the folks who participated, there was consensus that the policy was being interpreted correctly. Apparently the featured article on the main page is subject to the same restriction. Jkatz (WMF) (talk) 17:05, 15 March 2016 (UTC)

Could you point me to that discussion? I just reviewed everything on this page and I couldn't find anything. Alsee (talk) 20:15, 15 March 2016 (UTC)

@Alsee a million apologies, I did not include the link. Here it is: Talk:Reading/Web/Projects/Related pages/2015#h-RelatedArticles_and_displaying_non-free_content-2015-12-19T17:50:00.000Z Jkatz (WMF) (talk) 23:17, 15 March 2016 (UTC)

Ah, you meant the Related Articles discussion. What I was suggesting was that Hovercards has some possibly relevant differences. Related Articles are basically extra navigation links on a page, and the images serve an essentially decorative purpose on those navigation links. The policy minimizes non-free image use, and specifically targets that sort of navigational use.

I see a reasonable argument that hovercard usage may be acceptable under policy. The reader is specifically requesting a preview of the target article, and you're popping up a mini-view of that article. The image arguably shown "in" the article, rather than placed on another page. This is a bit of a stretch, but the image is arguably still serving the encyclopedic-purpose of helping to understand the topic and associated text in the mini-view.

We'd still have to see if others in the community buy that rationale. Alsee (talk) 02:18, 16 March 2016 (UTC)

@Alsee Ah! I see now. I would love to see that distinction explored! Right now, the images API simply does not return non-free images, but it might not be a huge amount of work to do it the 'right' way and simply flag the property ('this image is non-free') and let the receiving feature/wiki combination decide if it cared. Jkatz (WMF) (talk) 04:19, 16 March 2016 (UTC)

I opened the discussion. You can follow it at Non-free_content#Hovercards. Alsee (talk) 17:10, 16 March 2016 (UTC)

@Jkatz (WMF) and Alsee: I have closed the above-linked discussion with a consensus to allow non-free images to be presented in Hovercards. Mz7 (talk) 02:30, 15 April 2016 (UTC)

@Mz7 That is excellent news! Thank, you both for pushing the conversation forward. Jkatz (WMF) (talk) 16:23, 15 April 2016 (UTC)

comment conecter Jean eric RKT (talk) 08:57, 17 May 2016 (UTC)

Random, inappropriate image on Sexual assault hovercard

Is there a way for someone to change, or tell me how to change, the image on the hovercard for the article on Sexual assault? As far as I know, it was never part of the article unless it was there momentarily after an act of vandalism, because no one remembers it. Here is a screenshot of what it looks like. It's SFW (safe for work). It looks like a woman grimacing while she's doing aerobics or something. It's really not appropriate given the content of the article. Permstrump (talk) 21:23, 17 March 2016 (UTC)

The image is the first (topmost) image on the article that meets the size and aspect ratio requirements Hovercards imposes. It's present on the article in the Prevention section. To replace it, put an appropriate image earlier in the article.

I do think that we ought to have tags for Extension:PageImages to specify no page image (even when there are images in the article) or to specify a particular image even if it's not used on the page or not in the first spot. {{Nihiltres|talk|edits}} 22:43, 17 March 2016 (UTC)

Hah thanks! I didn't scroll down (obviously), but in my defense, I did mention it on the talkpage and no one else realized it either. Permstrump (talk) 06:26, 18 March 2016 (UTC)

Wow. That image is taken painfully out of context. It looks like she's physically wiped-out from a sexual assault in-progress or just ended... and that pose couldn't have been much worse.

If PageImage is going to blindly pick an image out of an article to "represent" that article in search results or hovercards or anywhere else, it needs to be limited to grabbing images from the lead section (and templates in the lead section), or editor selected image from elsewhere in the article. Images in other sections commonly illustrate things that are only indirectly related. I've seen several complaints about this floating around. Alsee (talk) 10:35, 22 March 2016 (UTC)

I added a different image to remove this specific page's issue Diablanco (talk) 17:36, 28 March 2016 (UTC)

That painting did not belong on the sexual assault article. Removed. Alsee (talk) 23:06, 28 March 2016 (UTC)

Hovercards not being displayed on some pages

For example: https://en.wikipedia.org/wiki/Wikipedia:Database_download

Links in the above pages do not show hovercards.

Wish I can be of more help, but running late.

Happy fixing. Sukumargv (talk) 01:02, 24 March 2016 (UTC)

Non-article-namespace links currently don't show links on purpose. Links on that page work as expected for me. Check again? {{Nihiltres|talk|edits}} 03:05, 24 March 2016 (UTC)

I think it makes sense.

Everything else works fine. Sukumargv (talk) 02:02, 16 June 2016 (UTC)

Increased page load times

Enabling Hovercards seems to increase page load times considerably. Accessing the :en:AN/I edit history (with default set to showing the 500 most recent edits) on an old PC (Win 7) caused several timeouts in Chrome, bringing up the option to kill the page or wait (Chrome Version 49.0.2623.87 m). Message displayed bottom left during those wait times indicated the machine was communicating with mediawiki.org. After disabling Hovercards, page load time for the edit history went back to normal; after switching it back on, the problem was back, too. (Also, I was unable to edit this Flow talk page in Chrome. The content remained permanently greyed. Fine in Firefox.) Jayen466 (talk) 15:23, 29 March 2016 (UTC)

I am unable to reproduce this issue on :enAN/I. I don't see a visible difference in load times with the extension enabled or disabled. I tested on Mac OS on the same version of Chrome as yours. I don't think that this could be a Windows specific problem, but I can't be sure either.

Did I miss any steps to recreate the issue? Were there any errors in the Developer tool's console? Prtksxna (talk) 00:32, 6 April 2016 (UTC)

I have a suggestion

in order to solve the problem with the cards length being too long or too short i think we should give some editors the power to select the and picture text being used for the hovercards

pls consider it Hanz24 (talk) 22:40, 30 March 2016 (UTC)

Hi Hanz24,

I think that is a great idea and something we want to eventually get to. Consider another possibility -

When editors see that the first sentence appears in hovercards for a quick read, would that automatically simplify first sentences and make quality of the first image more representative of the subject matter? Vibhabamba (talk) 19:18, 7 April 2016 (UTC)

yes but its usually too short for me to understand i think if we extend the length of the text to two sentences or even 3 if the editor chooses to it just saying i want editors to have the power to control the length of that first text because one sentence is not enough most of the time

how are editors gonna do it you may ask. when the editor when wants to edit the hovercard the system would select the first letter or so then like clicking and dragging select the desired text, but there's a catch you must use the first parts of the article and nothing else or the system will automatically reject the text (this is so no editors use the last or middle part of the text for hovercards) and the system will have a limit of 3 sentences or something like that Hanz24 (talk) 14:40, 11 April 2016 (UTC)

Should articles be edited with hovercards in mind? There are some people who value a well organized arch to articles, and therefore are against a condensed sentence starting off a page. Should it be standard to start with key facts, or is there a better solution? Bman1230 (talk) 18:05, 5 May 2016 (UTC)

yes they should Hanz24 (talk) 17:27, 10 May 2016 (UTC)

Please remember that we also can't control the length of the first line that Search engines display. If you are not taking such thing into account when writing articles... start. —TheDJ (Not WMF) (talk • contribs) 18:10, 10 May 2016 (UTC)

Issue with Zoom

When zoomed in the hovercard can display in an incorrect position.

(Browser was Chrome, OS was Mac OS X 10.11.3) CheChe (talk) 20:37, 9 April 2016 (UTC)

I don't have this problem (same setup). Only if I change zoom level while the card is open I can notice this... 82.75.221.191 (talk) 15:48, 12 April 2016 (UTC)

Duration of hovercard

As I was trying this feature, I noticed that quite frequently the cards don't go away when the person has stopped hovering over the link. THetardis123 (talk) 12:17, 12 April 2016 (UTC)

This is known issue phab:T92932. —TheDJ (Not WMF) (talk • contribs) 15:45, 12 April 2016 (UTC)

Odd issue with page

On the English Wikipedia page, I recently renamed a page to "ASU Foundation". While the hovercard shows the article name as bold, when it comes to the official title, "The ASU Foundation for a New American University", "ASU Foundation" is still in bold, instead of the official name being in bold, like it is in the article. Is there any way to fix this, or is this supposed to be like this? Kevin Rutherford (talk) 18:26, 13 April 2016 (UTC)

This is intended, unfortunately. Hovercards bolds stuff matching the page title exactly every time that happens in the lead. For funsies, check out the behaviour if you preview the "A" article (there's a convenient link to view the hovercard in the lead of the Alpha article).

It's part of a bigger issue where Hovercards and TextExtracts are configured to ignore part of the HTML in the lead, including stripping parentheticals, italics, bolding, subscript, and superscript. It certainly makes a spectacular mess on chemistry articles, e.g. calcium hydroxide, where "Ca(OH)₂" is transmogrified into "Ca2" in the preview. {{Nihiltres|talk|edits}} 18:43, 13 April 2016 (UTC)

Ah, that makes sense. Thanks for the help with that, and hopefully it will be resolved someday! Kevin Rutherford (talk) 20:03, 13 April 2016 (UTC)

Wikipedia Problem

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

On Wikipedia, hovercards only appear on pages in the Article namespace. Is this intentional? Goose121 (talk) 00:08, 21 April 2016 (UTC)

Yes--for the time being, we are limiting the feature to the Article namespace to keep things as simple as possible. Once the feature is successfully rolled out on several wikis, we can explore adding new functionality. Jkatz (WMF) (talk) 02:56, 26 April 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Allow users to set specific show/hide time?

Is there an option to make it possible to set the lenght of exerpts like the show/hiding time? That would be nice and maybe solve the problem for a while untill the best lenght is found. Karl.e05 (talk) 08:23, 21 May 2016 (UTC)

This is a good idea and can currently be set at the project level, but I am hesitant to allow it at the user level, mostly for bigger picture reasons. While there are power users who will want to adjust and play with this and many other fine-grained elements of the experience, there is a general thought by designers and product managers that the level of control we provide our power users with (some 60+ settings) would be overwhelming to our readers, who are casual readers. On any given feature, a setting is easy to argue for, but they quickly add up. Jkatz (WMF) (talk) 18:46, 22 May 2016 (UTC)

Bug "p3"

The article [2] Burg Zeze in the German wikipedia is just shown as "p3". Christian140 (talk) 20:49, 24 May 2016 (UTC)

Parenthesis in the name of the article

Several mineral names contain parenthesis, and it's not been shown in the hovercards (like this https://ca.wikipedia.org/wiki/Agardita). It can be fixed? Yuanga (talk) 21:12, 24 May 2016 (UTC)

Esta tendo erros constantes

Está tendo erros constantes, devido a compatibilidade com o Puffim Browser. Podem corrigir? RenanotakuXD (talk) 16:12, 26 May 2016 (UTC)

I don't speak portuguese, but I think I understand the question based on my limited Spanish. Here's a response in

English:

I think the puffin browser is only for mobile web and hovercards should be disabled on mobile web. Are you using the desktop version of the site on a mobile device? If so, hovercards should be disabled and we can look into it. Please confirm. Thanks! Jkatz (WMF) (talk) 16:25, 26 May 2016 (UTC)

semi-trans style?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Fmadd (talk) 17:10, 27 May 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

display in side pane?

It's a bigger change the the page layout, but would it be possible to display these to the side - reserve a column on the right when enabled. (Almost like a miller-columns view) Fmadd (talk) 17:17, 27 May 2016 (UTC)

Interesting idea! I think that would add a lot of order to the feature/page and would negate the problem a lot of people have with the hover appearing over text. I am not sure where it would go though as it would take up a lot of blank space when the user was not hovering. Thoughts or treatments welcome for how to reconcile the pull between covering content or losing space consistently. Jkatz (WMF) (talk) 17:52, 29 May 2016 (UTC)

A halfway house might be a hover card shown to the right of the link text instead of below; This would still leave you unobstructed when moving the cursor vertically. (maybe it would have to be to the left if your link is on the right side of the screen). and of course it could still be clickable. Fmadd (talk) 02:09, 5 June 2016 (UTC)

Interesting idea! Maybe we can test it. I imagine the designers did above/below for a reason, but if we have time, we can look into it. Jkatz (WMF) (talk) 04:18, 13 June 2016 (UTC)

'diagonal' (i.e. bottom-right , bottom-left, upper-left, upper-right of the cursor) would be another option... closer to the current behaviour, but would still allow unobstructed vertical scrolling past the current hovercard Fmadd (talk) 21:53, 13 June 2016 (UTC)

Don't make the card focusable/clickable

could you try making the card disappear as soon as the cursor moves off the underlying link - make the card itself unable to take focus, & unclickable; this would make it easier to deselect once it's appeared.

I like the hover card idea overall but I think they're a bit too obtrusive, hence this and my other suggestions (show to the side or, show transparent) Fmadd (talk) 17:24, 27 May 2016 (UTC)

Thanks, @Fmadd. We are looking into testing a smaller version. I think allowing someone to click through is an important feature, but it's also an interesting thing to test. I'll respond to some of your other suggestions now as well--mostly looking for clarification. Jkatz (WMF) (talk) 17:46, 29 May 2016 (UTC)

I recommend to add to hovercards of number systems information about transfers them to other number systems

For example, hovercard about Lunar distance (it's a number system):

-----

Lunar distance is as a unit of measure in astronomy. It is the average distance from the center of Earth to the center of the Moon.

1 Lunar distance = 384,402 km = 238,856 mi = 0.00257 AU = 1.282 ls = 60.32 Earth radii

-----

1 Lunar distance = 384,402 km = 238,856 mi = 0.00257 AU = 1.282 ls = 60.32 Earth radii <----- That's what I mean. 0Vista0 (talk) 20:26, 27 May 2016 (UTC)

Thanks for this. There a lot of special entity types that we could create custom hovercards for. For now, I think we need to focus on a generic card and then we (or volunteer developers) can explore how we can customize previews to different types. Jkatz (WMF) (talk) 17:50, 29 May 2016 (UTC)

Make it less obtrusive?

I like the idea overall but find it too obtrusive; I have 3 sub-suggestions that might help:-

[1] display the hover box to the side. (maybe even a side pane, like miller-column view, great use of wide monitors). Then it wont interfere with predominantly vertical browsing movement.

[2] Don't make it focusable; as soon as the cursor moves off the original link text, make the hover card disappear. (I find them lingering when i want to remove, it gets in the way). Easier to flick the cursor from link to link to find what you want.

[3] make the box semi-transparent so your visual focus stays on the page

overall my inspiration for how it should be is the experience of miller-column views , where you can step through the current level with ease, seeing a preview of the next level, before committing. Fmadd (talk) 12:55, 28 May 2016 (UTC)

Thanks, @Fmadd.

This covers a few issues mentioned in other recent cards, so I hope you'll forgive the copy and paste:

[1] Interesting idea! I think that would add a lot of order to the feature/page and would negate the problem a lot of people have with the hover appearing over text. I am not sure where it would go though as it would take up a lot of blank space when the user was not hovering. Thoughts or treatments welcome for how to reconcile the pull between covering content or losing space consistently.

[2] We are looking into testing a smaller version. I think allowing someone to click through is an important feature, but it's also an interesting thing to test. I will add it to the questions for our research team.

[3] I would have to see what you are talking about to gauge it's merit. I haven't seen this done well, honestly. Too transparent and the two levels blur. If you have a mock up, we would definitely take a look. Jkatz (WMF) (talk) 17:56, 29 May 2016 (UTC)

r.e. transparency, another idea is to display it like some linux/mac terminals (dark window with light text) - which instantly separates it from predominantly white pages of text.

Anyway thats' a secondary suggestion. I think the simple change of a hover card to the right would probably be a big help. The transparency idea is definitely harder to get right and more controversial.

Completely unrelated suggestion: show existing watchlist links in a different shade (to draw your eye to links that are outside of your familiarity) Fmadd (talk) 02:15, 5 June 2016 (UTC)

The one problem that might be found with putting the hovercards to the side is that of balance: too wide, and the page is too small and you're constantly scrolling, but too thin, and the hovercards are unreadable. I personally prefer the current system; it saves me a ton of time, and I find that, at least for me, they don't get in the way. Perhaps this could be a configurable preference? DWfan42 (talk) 00:36, 8 June 2016 (UTC)

Here's my argument from another discussion thread as to why the "obtrusive" nature of the hovercards is a sensible design choice:

"I disagree that the cards should be moved to the side; when a user is using the hovercard feature they are likely focusing on the content provided by the card alone, and in that sense it makes sense for the card to be "intrusive" - it is temporarily taking up all of your attention. While you're reading the hovercard there is no reason for you to require access to the current page, and once you're done with the card you just move your mouse away, restoring accessibility to the page you were on. It makes perfect sense."

Also, as others have alluded to, the side cards could create a lot of problems regarding configuration. Especially considering the near infinite number of screen sizes that are out there. Afw35 (talk) 15:52, 8 June 2016 (UTC)

my argument would be: if you want it obtrusive, you can already click the link :) the purpose of the hover card would be a balance between obtrusive and nothing.

I would be perfectly happy with a configurable preference.

Also yet another suggestion: the card could be displayed below but just offset to the right (i.e **bottom-right** diagonal placement relative to the cursor), this would still give you space to move the cursor down past it. Fmadd (talk) 18:16, 10 June 2016 (UTC)

I think it should be something like a Microsoft Word comment.

I agree that we should put it by the side, but there would be lines to suggest where the link is, so people who know which link is which.

Or, we could do something like right-click to show information, something like that. KangisLOL (talk) 19:56, 10 June 2016 (UTC)

subtle point, actually the reason i'm finding it obtrusive is on a mac with trackpad scrolling gestures. If you activate a hover card, but then 'scroll' away form it, you can find the cursor still in the hover card. This could be fixed if you could disable the hover card on scrolling (... i've no idea what events you can receive in these web UIs..). I suppose others may argue that you'd want to be able to scroll hover card contents. Fmadd (talk) 00:13, 12 June 2016 (UTC)

Hovercard of Main Page

How do I disable by default the hovercard on a link to the Main Page? Some wikis have the main page in project namespace. Among wikis with the main page in main namespace, I noted some wikis do not show the hovercard on this link, i.e. en.wiki, it.wiki, while others show the hovercard, i.e. ca.wiki, ro.wiki. Vriullop (talk) 08:24, 2 June 2016 (UTC)

Just to be sure I understand, you're asking to disable Hovercards for just the Main Page? CKoerner (WMF) (talk) 20:39, 8 June 2016 (UTC)

Right. The hovercard for the Main Page with the image of the day and no text is confusing. I wonder how it has been disabled on some wikis. Vriullop (talk) 07:47, 9 June 2016 (UTC)

I think this has to do with Hovercards only working in the content namespaces. Looking at the settings for Wikimedia wikis, nothing stands out to me to confirm that. That's just a guess though. :) Let me ask around and see if I can find out if this is true (Hovercards and the Project namespace) and if there's a setting to disable/enable. CKoerner (WMF) (talk) 15:25, 9 June 2016 (UTC)

Sorry. I do not remember how I checked it, but in fact it is not disabled on wikis I thought it was. Some temporary glitch I suppose. I thought there was some workaround, but there is no need to bother with a simple link. Vriullop (talk) 17:10, 9 June 2016 (UTC)

No images

The images are not properly scaled down into the pop up box. I think doing away with the images will be a better idea since the reader needs only a brief synopsis of the topic. Roni766321 (talk) 10:04, 5 June 2016 (UTC)

Support internal anchors e.g. title#subheading

Currently the content of the hover card shows the heading of the article pointed to by the link. However sometimes links point to a sub-heading for information referenced within larger articles, e.g. a definition of a specific term in a domain.

It would be great if the hover card was aware of this.

e.g. "blah blah [Gather(vector addressing)|gather] blah blah"

"gather" points to #gather in the article [[Gather-scatter (vector addressing)]].. you want to see a definition of 'gather', not the broader domain.

it would also be awesome with redirects to definitions in glossary pages Fmadd (talk) 23:30, 11 June 2016 (UTC)

Yes! This is captured by this ticket: https://phabricator.wikimedia.org/T65792. I don't see it as a blocker for rolling the feature out to anons, but think its an obvious win. Jkatz (WMF) (talk) 04:12, 13 June 2016 (UTC)

I have more complex suggestions aswell but they probably rock the boat too much.. imagine if wikipedia supported some sort of 'micro articles' for definitions (which are automatically assembled into bigger pages, almost automatic glossary/list-of. i prefer the idea of pages based on precise definitions but these seem to run into tension with 'notability guidelines' and avoiding repetition, so we end up with definitions embedded in complex ways. Scratching an itch, i've been going through graphics topics to throw as many definitions of terms as possible into a glossary page Fmadd (talk) 21:51, 13 June 2016 (UTC)

There's another more recent topic discussing the issue at https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2017#h-Hovercards_don%27t_show_the_section_of_a_page_that_the_link_specifies-2017-01-22T15%3A46%3A00.000Z, called "Hovercards don't show the section of a page that the link specifies". Edwardj 123 (talk) 13:57, 24 February 2017 (UTC)

Suggestion: [ [ foo ] ] "... is a blah blah blah..."

when displaying a hover card for a link "[ [ foo ] ]" , could it scan the target text and filter out "in bar, foo is blah blah blah" - and just display a compact definition. "... is a blah blah blah..." since the viewer already knows it's "foo" from the link , and the context ("in 'context' , foo is..") is probably not so far away. Fmadd (talk) 03:13, 13 June 2016 (UTC)

Wrong Image/ Minor Image

Some images are wrong as it shows the one within the text instead of the main image.

For example, as of 2:37 AM, June 21st, 2016, the character photos in the link below are wrong as the hover card shows the picture of other characters within the wiki page. So, for Meredith Grey (female character), it shows the picture of T. R. Knight (an actor), etc.

https://en.wikipedia.org/wiki/Grey%27s_Anatomy#Cast

So, how to edit those kind of errors? Penguinlay (talk) 09:39, 21 June 2016 (UTC)

Howdy Penguinlay. The reason the photo of T.R. Knight appears is due to how Hovercards follows the guideline of non-free images on the English Wikipedia. There was a long discussion on how tools like Hovercards could utilize images earlier this year. The API (application programming interface) that Hovercards uses doesn't allow for non-free content to be used.

You can learn more at Wikipedia:Non-free content, particularly this section. "The use of non-free media (whether images, audio or video clips) in galleries, discographies, and navigational and user-interface elements generally fails the test for significance".

So, the first two photos on that page are fair-use images (not freely licensed) and are excluded from the API. The third image (of the incorrect actor) is the first freely licensed image on that page. Hover cards uses that one.

Non-Intuitive, I agree, but not an error. :) CKoerner (WMF) (talk) 14:14, 22 June 2016 (UTC)

Thank you for the reply! Penguinlay (talk) 15:56, 15 July 2016 (UTC)

Images not displaying (Safari)

Love the hovercards, have a few suggestions to share later on, but for now, just wanted to drop by and ask if anyone knows why the images are not displaying? Anyone else with this problem?

Thanks Daftanatta (talk) 17:13, 22 June 2016 (UTC)

I have the same problem! Images are not displaying! Nico86roma (talk) 05:01, 1 July 2016 (UTC)

A fellow Safari user! I'm too seeing this issue. With or without extensions enabled and in "Private" mode as well. I created a task for the engineers to look at. I'll be sure to keep you updated. If you have a moment, can you tell me which version of OS X and Safari you're using? It might help in narrowing down the cause. CKoerner (WMF) (talk) 17:45, 22 June 2016 (UTC)

I am a Safari user too and facing the same issue of images not showing in the hovercards

My Safari version is the 9.1.1 Kingpin (talk) 17:56, 22 June 2016 (UTC)

My OS X is El Capitan 10.11.5 Kingpin (talk) 18:01, 22 June 2016 (UTC)

Wow, thank you for the prompt reply and for your help.

Just as Kingpin, I'm running the latest and greatest available:

Safari 9.1.1

OS X 10.11.5

And yes, I would greatly appreciate hearing any updates on the issue.

Thanks again. Daftanatta (talk) 10:44, 23 June 2016 (UTC)

Hello again @Daftanatta and @Kingpin. I have a quick update to share. A fix has been made and it should appear on the next deployment window - 7 July (Thursday). CKoerner (WMF) (talk) 15:17, 30 June 2016 (UTC)

Okay, let's hope it solves this problem once and for all.

I will keep you posted about the outcome. Kingpin (talk) 19:52, 30 June 2016 (UTC)

Apologies for missing the update last week. It looks like the patch was successful in fixing the issue for Safari users. Yay!

It looks like ops had to rollback the wiki update due to an un-related issue. This bug is still there. I'll update with more info once I know more. CKoerner (WMF) (talk) 19:52, 11 July 2016 (UTC)

Too bad, it worked perfectly. Kingpin (talk) 17:12, 12 July 2016 (UTC)

How do u feel about Wikipedia it was hard for u to solve some of the problem Troy 9876 (talk) 17:56, 21 July 2016 (UTC)

Looking and working great! Hopefully these will come out for everyone to use soon! Daftanatta (talk) 11:46, 15 July 2016 (UTC)

Hovercards & API

Is there an API query to get the "hovercard content" of a chosen Wikipedia page?

Normally querying page content returns "dirty text", while hovercards display smartly parsed and cleaned up text that is cut at a certain logical point. Also, hovercards smartly display a relevant image. I'd like to be able to get that data, too, without re-inventing all the hovercard functionality. Is it available in some form or shape? SSneg (talk) 18:29, 27 June 2016 (UTC)

Hovercards requires and uses Extension:TextExtracts and Extension:PageImages. Both of which extend the MediaWiki API. If you're looking to set something up on your own, you might be able to use those two extensions independently. Hope that helps! CKoerner (WMF) (talk) 19:06, 27 June 2016 (UTC)

Just another opinion on timing and content

Right now there is IMO a fine delay for popping up of a hovercard after starting with hovering of cursor above the link (true that it should be longer than with reference tooltips as hovercards are much bigger). But when one wants to continue reading he might like to see the hovercard dissapear instantly as it would otherwise block the view (frequently people do not read whole articles word by word).

So my view is just to make hovercards dissappear right when user goes off the link.

I also support the idea of limiting the displayed text logically. What about first 2 sentences (indicated by periods)? With algorithm such as: I) 2 sentences if less or equal to 250 chars -(if not)-> II) First sentence until period and second until comma if less or equal to 250 chars -(if not)-> III) Only first sentence until 250 chars. Gumok (talk) 14:33, 15 July 2016 (UTC)

Links in Links

I'd like to see Links within the Hovercards that create new Hovercards :D whos with me? Quitechirp (talk) 08:06, 22 July 2016 (UTC)

nice idea, but i guess it would be too messy. Fractionfred (talk) 12:42, 12 November 2016 (UTC)

I guess me Satanluv (talk) 17:50, 28 October 2016 (UTC)

The Wikipedia team could perhaps add this feature as an easter-egg setting for Page Previews, disabled by default to avoid general mess for all users. Edwardj 123 (talk) 17:22, 5 December 2016 (UTC)

Equation formatting is not shown properly

I observed that the text formatting is not shown properly in the hovercard. Text to be shown is formatted as "<math>X</math>". Instead of applying the effects of this markup or ignoring it, the markup tag is displayed as "X {\displaystyle X}". I uploaded an image demonstrating the problem here.

Thank you all for your efforts. Gufosowa (talk) 16:56, 23 July 2016 (UTC)

Thank you for letting us know! I have documented the issue here: https://phabricator.wikimedia.org/T141766

for our team to prioritize and fix. If it is part of a larger issue it will be a higher priority (but maybe harder to fix)...if it is just a one-off case, it might be prioritized a little lower. Right now, our team is pausing on most hovercard development while we analyze the results of what happens when we make them default for users (a live test on Hungarian Wikipedia). Jkatz (WMF) (talk) 13:42, 1 August 2016 (UTC)

Another, simpler case is when the linked section includes brackets. These appear to be dropped on the hovercard. That is understandable for parenthetical text, but can be completely incorrect when linking to a maths-based article. For example the hovercard for Pronic number shows "... of the form n", rather than "... of the form n(n+1)".

Almonaster (talk) 13:55, 15 August 2016 (UTC)

Thanks @Almonaster I added your comment to the ticket: https://phabricator.wikimedia.org/T141766 Jkatz (WMF) (talk) 16:29, 15 August 2016 (UTC)

Links to article section

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

When linking to a section, like [[foo#bar|bar]], the text displayed in the hovercard is still the text from the top of the article. I think it would make more sense for the text to be from the linked section. Sjrct (talk) 18:33, 5 August 2016 (UTC)

This has been discussed in Talk:Page Previews/2016#h-Support_internal_anchors_e.g._title#subheading-2016-06-11T23:30:00.000Z. FriedhelmW (talk) 18:54, 5 August 2016 (UTC)

You can also follow the discussion at T65792 and T138607. Prtksxna (talk) 08:16, 16 August 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Images in lemmas in wiktionaries

I liked the gadget because it gives me the opportunity to pre-see when article was changed. But I mostly work in wiktionaries and an image existing in "article" is not always what the "article" is about. That creates a confusion to the reader. "Articles" in wiktionaries are about the word and not the image. Some words (think of the word: "because") are widely used in a totally different sense from the one the image shows. Some users, in some wiktionaries, want to include an image, but the image without its description is always useless (always speaking for an wiktionary visitor). It would be nice if we could remove the image part in the wiktionaries. And it would be nice if we could add more dictionary information such as the language parts the article includes or if there are translations. Vanished user Xorisdtbdfgonugyfs (talk) 05:59, 7 August 2016 (UTC)

Problem

Whenever I click on an article from another page and click the back arrow leading back to the page where I clicked the link from, its hovercard stays there. I'm wondering if we could fix that. 2luze (talk) 11:15, 8 August 2016 (UTC)

Well, I don’t have this problem, cause I tried it out.

It could be a software problem, mine is OS X 10.11.

But I did have to click before the hover card closed.

Jerryzhu2004 (talk) 08:29, 9 August 2016 (UTC)

لم أفهم Israa boubnane (talk) 12:14, 9 August 2016 (UTC)

@Jerryzhu2004 That gif is great for seeing what you're seeing. Thank you for taking the time to make it. So when you navigate back the Hovercard you navigated forward from is still on-screen. It should not be visible when navigating back. Do I have that right?

@2luze Are you also using Safari? If I recall correctly Safari caches pages immediately in the history. I wonder if this is specific to that bowser? I'm not seeing the same behavior in Chrome.

I created a task to see if we can get an engineer to investigate. I will keep you posted. :)

(@Israa boubnane Do you understand now?) CKoerner (WMF) (talk) 21:34, 15 August 2016 (UTC)

لا أفهم الاجليزيا Israa boubnane (talk) 11:26, 16 August 2016 (UTC)

Don't work

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hovercards don't work? Yusuf 506 (talk) 07:51, 16 August 2016 (UTC)

Thanks for reporting this issue. On which link and on which page are you not seeing Hovercards? Details would help us find and fix the problem. Prtksxna (talk) 13:47, 16 August 2016 (UTC)

Hovercards now only works on specific pages Yusuf 506 (talk) 14:00, 16 August 2016 (UTC)

@Yusuf 506 Could you please provide just a little more info? What browser you are using? Which pages are you seeing this problem on? I can see hovercards working as intended in Chrome and Safari on English and Turkish Wikipedias. CKoerner (WMF) (talk) 14:26, 16 August 2016 (UTC)

I'm using sometimes Chrome, sometimes Yandex. Yusuf 506 (talk) 14:38, 16 August 2016 (UTC)

@Yusuf 506 on what pages is it not working? It is not intended to work on non article (main-namespace) pages, which may be what you are seeing. Jkatz (WMF) (talk) 21:18, 16 August 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Hovercards don't enable when I say "Automatically enable all beta..."

I first clicked "Automatically enable all beta features" and clicked save. Then I went to a random page (Society of Jesus) and tested it. It did not work. I then went back to my preferences and manually click enabled Hovercards and saved. I went back to the page and it worked.

Operating System: Windows 10 Pro Version 1511

Browser: Google Chrome Version 52.0.2743.116 m

Maybe this is just a localized problem? NTRIV (talk) 23:55, 16 August 2016 (UTC)

That only works for beta features added after you check that option. Jay8g (talk) 01:16, 17 August 2016 (UTC)

لا أفهم اللغة Israa boubnane (talk) 08:48, 17 August 2016 (UTC)

salve Giancarlo moscione (talk) 08:49, 24 August 2016 (UTC)

Adding Links to Hovercards

I think it would be interesting to have links inside the hovercard that point the user to relevant articles on the topic. For example, the hovercard for ISIS would have links to articles about the Syrian Civil War, etc; NTRIV (talk) 03:25, 18 August 2016 (UTC)

Hmm, interesting. Are you thinking of something like Hovercards + Related Pages? CKoerner (WMF) (talk) 13:42, 18 August 2016 (UTC)

I think that would be very helpful to people doing projects that requires a lot of information Epic Fails (talk) 07:38, 21 August 2016 (UTC)

Hovercards don't work at Commons

Although I have Hovercards switched on, they don't display because they are suppressed by simple tooltips when I place a cursor on the link. The previous and better time-proven tool (User:Lupin/popups.js) is also eliminated. Is there any chance to revive them both? ŠJů (talk) 18:34, 23 August 2016 (UTC)

Popups.js doesn't work on Commons for you even when Hovercards is disabled? I was under the impression that if a person had both enabled that Popups would over rule Hovercards. I'm also seeing that Hovercards don't seem to work on Commons - that may be because most Commons content is in a Category or Project namespace. @Jkatz (WMF) can you help clarify what we're seeing? :) CKoerner (WMF) (talk) 14:48, 24 August 2016 (UTC)

@ŠJů @CKoerner (WMF) Thanks for flagging this! I am not sure why hovercards are not working. I think it might be because we have hovercards set to only be triggered for links to main namespace articles (since all other namespaces would require slightly different treatment). Since that is the case, we might just want to remove the option for hovercards from Commons.

If Navpops are enabled, then hovercards are indeed suppressed, but the best way to ensure this is to use the official gadget in your preferences. Unfortunately, given the high number and varying resilience of custom scripts created by users, we cannot guarantee that all changes to the site will be compatible with each custom script. Jkatz (WMF) (talk) 16:18, 24 August 2016 (UTC)

A minor bug

<br> doesn't resolve into a space, but "". So if I have a page with aa<br>bb the hovercard is not "aa bb" but aabb. רן כהן (talk) 04:46, 25 August 2016 (UTC)

Hi, please could you give us a link to an article where this is happening? That way we can more easily understand the context of why a forced linebreak is used within the lead sentences, and also more easily reproduce the results. It would also help if you could explain how often, and/or in what circumstances, this technique is used. Thanks! Quiddity (WMF) (talk) 22:10, 9 September 2016 (UTC)

I don't remember the page I was on. Just look at what page has "<br>" at the start and hover on it. רן כהן (talk) 17:08, 10 September 2016 (UTC)

Problem with images and references

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hovercards doesn't display images if in the article content is the tag "Plik" (pl. "Plik" = en. "File") instead "Image/File" and tag "Cytuj stronę" (pl. "Cytuj stronę" = en. "Cite web") instead "Cite web" etc... NH35 (talk) 15:13, 28 August 2016 (UTC)

Can you give an example please? FriedhelmW (talk) 15:20, 28 August 2016 (UTC)

Thank you for reply.

[[Plik:123.jpg]] - doesn't work</pre>
<pre>[[File:123.jpg]] - it's working

[[Grafika:123.jpg]] - doesn't work</pre>
<pre>[[Images:123.jpg]] - it's working

<ref>{{Cytuj stronę|url=|tytuł=|autor=|data dostępu=|opublikowany=|język=}}</ref>.- doesn't work &lt;/pre&gt;
&lt;pre&gt;<ref>{{cite web |url= |title=  |date= |website= |publisher= |access-date=}}</ref> - it's working

Other Cite templates (book, newspeper etc.... in Polish language) also doesn't work in Hovercards viev. I don't know if it's important but Polish version of Wikipedia doesn't use the latest version of Hovercards. NH35 (talk) 17:05, 28 August 2016 (UTC)

The version of Hovercards that runs is the same on all Wikipedia servers. Are you perhaps talking about Navigation popups ? —TheDJ (Not WMF) (talk • contribs) 10:07, 29 August 2016 (UTC)

Take a look http://wiki.czarnobyl.pl/wiki/Strona_główna NH35 (talk) 11:31, 29 August 2016 (UTC)

When I type "123.jpg" in the search box I get this error:

Fatal error: OOUI\InputWidget cannot use OOUI\FlaggedElement - it is not a trait in /home/czarnob1/domains/czarnobyl.pl/public_html/wiki/vendor/oojs/oojs-ui/php/widgets/InputWidget.php on line 11

Maybe there are incompatible program versions. FriedhelmW (talk) 19:15, 29 August 2016 (UTC)

yes, it looks like versions of mediawiki, its' vendor php dependencies or the extension are not in sync, and that would result in problems like these. —TheDJ (Not WMF) (talk • contribs) 11:32, 30 August 2016 (UTC)

@TheDJ Thanks for looking at this. I don't think I understand. On Wikipedia are we missing these basic translations or is this happening on other versions of mediawiki that are using incompatible extension versions? Jkatz (WMF) (talk) 00:04, 3 September 2016 (UTC)

.- doesn't work

Template:Cytuj stronę

Unitel Ango (talk) 22:53, 25 October 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Ramanujan's hovercard has a typo, but the actual article doesn't

As seen in this article https://en.wikipedia.org/wiki/Ramanujan%E2%80%93Nagell_equation the last word of the hovercard is Ramanuian but in his article the typo has been fixed. SansC (talk) 10:12, 2 September 2016 (UTC)

Thanks for this. I expect it is the result of slightly less liberal cache-busting for hovercards. Normally we serve articles from a preloaded storage (cache). When an article changes we call the cached version invalid. If you have a local cache we check that it is still valid on reload. I don't think we do that for hovercards, because they only show the first X characters. @ABaso (WMF) @ABaso (WMF) did I get that right? Jkatz (WMF) (talk) 22:58, 6 September 2016 (UTC)

Abrupt Hovercard Descriptions

The description is kind of "incomplete". If you try hovercards on any page in wikipedia and read the last lines on a hovercard, you would find it incomplete. E.g: "The ETSC era witnessed substantial growth of both student enrollment and the"

Another problem is, on a hovercard, certain parts of a sentence cant be selected!! it becomes a link when i drag it (because the text cannot be copied using the mouse) E.g:" The ornate antwren is a species of bird in the family Thamnophilidae. It was formerly placed in the genus Myrmotherula but the new genus Epinecrophylla was created in 2006. " I didnt drag the link. DarkSpartan191 (talk) 14:11, 5 September 2016 (UTC)

1. 1 Yes, this is a problem. I think it is considered a blocker for full rollout and is being tracked by this ticket in phabricator [3]
2. 2 I don't think text selection is a primary use case for this feature. As sucuhwe cwe designed to optimize for the much more popular use case of clicking the card to go to the articlUnfortunately, ie. If you really want to select the text you will unfortunately need to go to the are off .bip... Jkatz (WMF) (talk) 23:47, 6 September 2016 (UTC)

I put forward a suggestion for what I called summaries on the MediaWiki mailing lists of using a {{summary ....}} markdown syntax to allow summaries to be explicitly defined. This could default back to the auto generated summary as you have now. So usage would be transparent but allow explicit summary definitions.

I also though you could have a {{summary simple ...}} which could allow simple summaries for some people as a lot of wikipedias entries are too complex for a ot of people. There could be a number of summary types, for example a child friendly one.

A default summary type for a user could be selected in settings, and overridden on hovercards, or the default even changed on a hovercard.

Yet another option could be a user could select which subjects they are expert in and get expert summaries in those fields. AaronNGray (talk) 00:07, 11 October 2016 (UTC)

Sticky hovercards

• Using hovercards with Chrome (current version), Windows 10, (all updates installed), I've noticed an intermittent tendency for hovercards to stay open when I want them to close and get out of the way. This happens even if I hover the mouse over a different link, or click somewhere in white space. A possible solution to this (and concerns others have had about their placement) might be to give them a "handle" that can be grabbed and dragged, along with an "x" (close) button that can be used to close a particular hovercard, if desired.

• By default, hovercards do not show tags that are on articles. While I understand the reasoning for this, it would be useful if the hovercard could indicate if a deletion tag is on the article. Others may have a desire to see other tags that might be on the article. One way to accommodate the various needs of different users would be to have an opt-in to show tags. It wouldn't be necessary to fully expand the tag -- instead just show whatever appears within the curly braces, up to the first pipe -- and perhaps highlight it with some color. This would only apply to tags at the top of the article, within the text that the hovercard normally grabs. Etamni (talk) 10:05, 7 September 2016 (UTC)

• This one is Phab:T92932 - I've added your suggestion. Thanks. Note that an "x" (close) mechanism was declined in Phab:T105782
• I've filed the suggestion as Phab:T145249 - Hovercards is generally intended as a simple preview extension. This feature would make some sense in the future-planned "advanced hovercards", which will hopefully integrate and improve upon all the features currently available in Navigation_popups. However, it is possible to do this with Navigation popups already, if you tweak your js, to include popupPreviewKillTemplates=false; - See an example in this edit of how I added it to my global.js - See screenshot of results in use. - See Navigation_popups#Configuration (optional) for that and other options. Quiddity (WMF) (talk) 22:06, 9 September 2016 (UTC)

You can also use the Escape key (Esc) to hide the currently displayed hovercard. This works both for when you're actively hovering over the link and when it's being sticky. ReGuess (talk) 20:12, 4 October 2016 (UTC)

A problem with books creator feature

Good morning, this feature bother us links to "add to the book," which are another feature, the creator of books, because that popup windows disturb when you will click on the link mentioned above, sometimes you unwittingly click on the page name in the popup and opens the link destination. Luístro (talk) 13:57, 20 September 2016 (UTC)

Hi I am unable to replicate this on my computer. Can you reply and let me know what browser and operating system you are using when you experience this bug? Incidentally, we are trying to talk to people who use the book creator feature to understand what they use it for. Can you describe why you use the book creator?

For instance, do you use it collect articles as a bookmarking tool or to create a file you can share with others or to print.....and why? This would be very helpful as we investigate the future of this tool. Thank you! Jkatz (WMF) (talk) 21:49, 29 September 2016 (UTC)

profile pictures

i think you should add profile pictures crazyfox 18:19, 23 September 2016 (UTC)

Yes I Add The Profile Pictures ..Thanks Sarkis H Matta Art Gallery (talk) 17:56, 9 October 2016 (UTC)

@Foxy Awesome what do you mean? Most hovercards include the first image from the article. Do you think a different one should be included? Admittedly some articles either do not have an image or do not have a suitable image. Jkatz (WMF) (talk) 21:41, 23 September 2016 (UTC)

sorry im just practicing my nephew was a filipino artist could you please help me how can i create an article of her? Zaijhon25 (talk) 05:00, 26 September 2016 (UTC)

Aha. I can't really help with that and this discussion area is reserved for something else, but here is some information on creating your first article: https://en.wikipedia.org/wiki/Wikipedia:Your_first_article I hope you find it helpful! Jkatz (WMF) (talk) 21:02, 27 September 2016 (UTC)

Wiktionary

On the English Wiktionary (and on every Wiktionary I turned Hovercards on for the sake of testing), the hovercard shows only the time elapsed since the last edit and the gear-icon settings button. I have tested this in Google Chrome as well as Microsoft Edge, and in a variety of languages.

On a somewhat related note, a suggestion: a set of buttons on the Preferences/Beta pages for applying settings either across all languages in a given Wikimedia project or across all Wikimedia projects. This would have been very useful while testing the Hovercards. ReGuess (talk) 21:04, 4 October 2016 (UTC)

Thank you for pointing this out. Due to some current bugs, pages which do not have a first paragraph do not display hovercards, which causes issues on some wikipedias and a number of projects as well. We're tracking it here, but have yet to design a good solution (so ideas are welcome :) Our first step might be to default to not displaying hovercards for these pages. OVasileva (WMF) (talk) 18:22, 24 October 2016 (UTC)

With the picture it's to much

I think the hovercards is too big with a picture. Why do you not puting just the basics informations of the page. Hugocabret (talk) 21:28, 5 October 2016 (UTC)

Thanks for the feedback @Hugocabret. We recently completed some usability testing and found that most people seem to like the larger photo. Can you please tell me more about why you don't like the large picture? CKoerner (WMF) (talk) 14:45, 12 October 2016 (UTC)

can we just have a tick box enable/disable for the picture on the "cog wheel" settings options please ? AaronNGray (talk) 10:51, 13 October 2016 (UTC)

This is a good idea. Making hovercards images configurable is one of the features that we're considering for a later iteration of hovercards. Take a look at this task for tracking purposes (we haven't started working on it yet) OVasileva (WMF) (talk) 18:10, 24 October 2016 (UTC)

I like the image like many users probably do and have some ideas for customising the box display:

Although I don't mind its current size much, it is important that users can customise the box size by changing a setting stored with their account/browser session. I think three sizes called default, medium and small would be the best idea - with the image being the main thing resized:

• "default" as the current size and layout (summary image top or right, summary text with ellipsis dots at end, half font size toolbar with last edit date and Page Previews settings opener button)
• "medium" the same as default but with the summary image resized smaller and a bit less blank space padding in the whole Page Previews hover box
• "small" the same as medium but with the summary image resized slightly smaller.

Relevant "cards are too large/tall" topic on this talk: Talk:Page Previews/2016#h-cards_are_too_large/tall-2016-11-07T05:54:00.000Z Edwardj 123 (talk) 17:30, 5 December 2016 (UTC)

Hovercard Template:Summary markdown extension

I put forward a suggestion for what I called summaries on the MediaWiki mailing lists of using a {{summary ...}} markdown syntax to allow summaries to be explicitly defined. This could default back to the auto generated summary as you have now. So usage would be transparent but allow explicit summary definitions. I also though you could have a {{summary simple ...}} which could allow simple summaries for some people as a lot of wikipedias entries are too complex for a lot of people. There could be a number of summary types, for example a child friendly one. A default summary type for a user could be selected in settings, and overridden on hovercards, or the default even changed on a hovercard.

Yet another option could be a user could select which subjects they are expert in and get expert summaries in those fields.

Selection of summary content from Wiktionary could also be an option on hovrecards.

This should all be able to added transparently. AaronNGray (talk) 00:12, 11 October 2016 (UTC)

AaronNGray (talk) 00:34, 11 October 2016 (UTC)

Summaries could be stored/cached on page save/update in a new SQL table for fast access. AaronNGray (talk) 00:36, 11 October 2016 (UTC)

That doesn't seem like it would very much belong in this extension. It would be part of Extension:TextExtracts or something, so the API that Popups/Hovercard uses can be shared. —TheDJ (Not WMF) (talk • contribs) 09:38, 11 October 2016 (UTC)

Cool I will check that out thanks ! Does not look a very useful API ! How are infobox'es implemented as I cannot find the source or extension for them but they use a {{ ... }} markdown syntax which is similar. AaronNGray (talk) 10:48, 13 October 2016 (UTC)

I love it! Gwen Sommers Redwine (talk) 09:38, 17 October 2016 (UTC)

Optional pictures

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Display of pictures should be an option defaulting to enabled. AaronNGray (talk) 00:35, 11 October 2016 (UTC)

Are you suggesting that there should be more than one photo displayed within a Hovercard? CKoerner (WMF) (talk) 14:34, 12 October 2016 (UTC)

that's a possibility too but the ability to disable the picture for most researchers needs was what I was getting at. AaronNGray (talk) 10:49, 13 October 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

"more" and "less" links

Is it possible to consider looking at having a "more" link to complete up to the end of a sentence or paragraph to deal with abruptly terminating text, and corresponding "less" link at the end of the expanded text please. AaronNGray (talk) 13:39, 14 October 2016 (UTC)

There's a few tasks that are being worked on to make the text extracts more consistent and their termination less abrupt. phab:T113094

One of the issues that that the extract doesn't currently end where you might think it should. :) CKoerner (WMF) (talk) 14:00, 17 October 2016 (UTC)

Reflecting on this idea, do you think Hovercards would benefit from a (More) or (Read more) link at the end of the short bit from the linked article?

Your feedback made me think of this. :) CKoerner (WMF) (talk) 19:01, 20 October 2016 (UTC)

a "more" link would be a quick fix solution that could complete text the next sentence or paragraph, and allow the problem to be easily solved in the time being. AaronNGray (talk) 13:13, 21 October 2016 (UTC)

Thank you for pointing this out, we're aware it's a very confusing experience as of now. We considered a few ways to fix the abrupt termination of text while still indicating that the article continues elsewhere, namely adding ellipses at the end of a sentence or a horizontal gradient/blur - we decided to go with the latter since it's in line with other design elements. If you're curious, the work is tracked here https://phabricator.wikimedia.org/T67845 and should be available in beta within the next month or so OVasileva (WMF) (talk) 17:56, 24 October 2016 (UTC)

could we not have the ellipses clickable and extend to end of sentence or paragraph as it I actually a very easy thing to program ! AaronNGray (talk) 23:53, 2 November 2016 (UTC)

Letting lots more text be displayed defeats the whole point of the article page itself but I suppose displaying the end of the sentence could be acceptable as long as it's not too long.

I think it would be better to just have ellipsis dots or this horizontal blur thing (if it works well) though. Edwardj 123 (talk) 17:27, 5 December 2016 (UTC)

Featured article

Consider adding a small icon to indicate whether the article is featured or not. רונאלדיניו המלך (talk) 18:06, 17 October 2016 (UTC)

That's an interesting idea. I've created a task to start a discussion with the engineers. CKoerner (WMF) (talk) 19:00, 20 October 2016 (UTC)

Related discussion "What metadata should be displayed (article quality, last edited, user views, settings icon etc.)?" - https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2016#h-What_metadata_should_be_displayed_%28article_quality%2C_last_edited%2C_user_views%2C_set-2016-11-29T06%3A12%3A00.000Z. Relevant discussions are often better linked together. Edwardj 123 (talk) 16:07, 7 January 2017 (UTC)

confused

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

how do u talk to others Satanluv (talk) 14:47, 26 October 2016 (UTC)

It's not that kind of program. Try Facebook or Twitter. Good luck! Geekdiva (talk) 13:21, 2 November 2016 (UTC)

i have those but they dont work in school so im trying to find a chat that works in school Satanluv (talk) 16:02, 8 November 2016 (UTC)

Well, this site is about the software that runs wikis like Wikipedia, so unless you're here to talk about these things, I'm sorry but you're in the wrong place. Even on Wikipedia, people only talk about how to improve articles, because it's not a social network.

You could try ask.com or bulletin boards/web forums that focus on a topic that interests you. Maybe you could join your school's computer club and get advice there. You could even ask people on Facebook or Twitter if they have any suggestions. These are just my ideas off the top of my head; I'm not representing Mediawiki.org or the Wikimedia Foundation, by the way. I'm simply another random user here.

Again, good luck, but you'll have to try elsewhere. Take care! Geekdiva (talk) 20:59, 9 November 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Hovercards don't disappear when mouse is moved away

When the mouse cursor is moved away from a hovercard, the card doesn't disappear. Issue found on both OSX Mavericks and OSX Yosemite. TheDestroyer111 (talk) 11:15, 29 October 2016 (UTC)

I've seen this on Windows 10 in Chrome. I've also seen tooltips persist, though. If I mouse over to the link/element and hover again, either will go away. Minimizing everything and then clicking the window fixes the tooltip. I haven't tried it with the Hovercard. Geekdiva (talk) 13:20, 2 November 2016 (UTC)

@TheDestroyer111, do you have any ad blockers or other extensions enabled? I'm trying to reproduce the issue and am not having luck! CKoerner (WMF) (talk) 14:43, 8 November 2016 (UTC)

I only have Ghostery in the blocking genre of add-ons. I have some others, but not many and I don't see how they would conflict. Geekdiva (talk) 19:27, 9 November 2016 (UTC)

I can reproduce this bugs. It seems to have appeared only recently. But it's very troublesome as sometime you just hover a link without wanting to have more information and this popin stays here without any way to close it. Therefore I disabled it for now as it leads to more trouble than it helps me.

I'm on the last firefox version on linux, with ublock origin and disconnect extensions.

At least a close button could be a quick workaround. Milouse (talk) 10:56, 9 November 2016 (UTC)

Let's see if I can get some attention. I've created a task and asked the engineers to take a look into things. CKoerner (WMF) (talk) 20:05, 9 November 2016 (UTC)

Ack, my task was a duplicate. This is the one you'll want to follow. :) CKoerner (WMF) (talk) 16:04, 14 November 2016 (UTC)

Thanks! And thanks for the thanks on the other thing. :) Geekdiva (talk) 21:09, 9 November 2016 (UTC)

I've got the same issue. Nikolaih (talk) 06:28, 13 November 2016 (UTC)

I have no ad-blocking extensions. For extensions, my Chrome browser is really clean and all extensions it has are the ones installed by default (IIRC something for google docs or stuff like that). TheDestroyer111 (talk) 09:02, 13 November 2016 (UTC)

This is the most important issue for me. Removed the feature hopefully they'll fix it. Fcarvajalbrown (talk) 13:17, 25 November 2016 (UTC)

I also have the same issue. Using Chrome last version with AdBlock on Windows 10 and Mac OS Ita140188 (talk) 10:09, 27 November 2016 (UTC)

I hadn't noticed this in previous releases of macOS Sierra and Safari, but in the current macOS Sierra Beta (10.12.3 Beta build 16D17a; Safari 10.0.3 build 12602.4.3), the Hovercards are seem to get stuck open and will close randomly.

Add-ons installed are LastPass and Pocket. No adblocking add-ons installed. Bbreferee77 (talk) 17:45, 5 January 2017 (UTC)

Wrong pictures on certain articles

If I mouse over links to certain articles (such as https://en.wikipedia.org/wiki/McDonnell_Douglas_F-4_Phantom_II) with Hovercards beta turned on, the image from the infobox is ignored and instead, in the case of the F-4, it shows me the photo of a mockup, which is located in the Development section of the article, below the infobox.

In case of the https://en.wikipedia.org/wiki/Folding-Fin_Aerial_Rocket, it is even more awkward - the image in its hovercard is two images and half the article lower than the image which should be displayed. TheDestroyer111 (talk) 11:18, 29 October 2016 (UTC)

It's caused when the picture is in a template, I think. I just wrote about this on a Signpost article:

• Not if the reader is using the beta Hovercards: "...to the infamous post capture photo of Khalid Sheikh Mohammed (pictured). (Mohammed...has a much more flattering picture of himself on his Wikipedia article.)" I'm enjoying using Hovercards a lot. It helps me verify that I'm linking to the correct article in an edit preview, for example. However, it does ignore the first image on a page if that image is in a template—say, Template:Infobox. So hovering over the link to Khalid Sheikh Mohammed pulled up the infamous photo (the next one down the page outside of a template) and not the "more flattering picture" at the top. FYI!

I've also been able to recognize hatnote text that was formatted instead of added by template, and then go to the article in the Hovercard and fix that. Thanks! Geekdiva (talk) 13:12, 2 November 2016 (UTC)

It's definitely not just due to picture being in template - lots of pages properly display a picture inside an infobox, just that the F-4 and FFAR rocket are unlucky ones. TheDestroyer111 (talk) 09:04, 13 November 2016 (UTC)

There's actually two culprits here. The first is that we're restricting the pageimages API (which hovercards uses) to only free images. We will be changing this to allow for non-free images from hovercards to appear as well. If you're interested in details, follow this task, which will allow extensions to select whether they want to display any images or free images only. I'd like to note however, that we will only allow for non-free images for the communities which have approved non-free images for a particular extension. The second is that we're pulling images from the entire page, meaning that images which appear later in each article are showing as the images on a hovercard. To account for this, we're restricting the pageimages API to only pull images from the lead section and infobox for an article. For more info on this, check out this task. The results of this for hovercards will be: if the first image in an article is within the infobox or lead section of the article, we will display the image for the hovercard of the article. If an image appears in later sections, no image will be displayed for that article. OVasileva (WMF) (talk) 15:41, 17 November 2016 (UTC)

The way to do it on mobile devices

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

How do you get it to work on mobile phones and tablets? Say something you think it might work. It might work on the 6s and newer. Jackypoo (talk) 20:24, 4 November 2016 (UTC)

programing has issues to do with such, i guess... Gueliet (talk) 10:33, 10 November 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

cards are too large/tall

Hovercards pose a distraction due to their size. I do not need the pictures. Have a small link for an article image. There needs to be a scroll bar for additional text. Quisqualis (talk) 05:54, 7 November 2016 (UTC)

Howdy @ Quisqualis, you're not the only one with this thought. We've created a task to look into having options for the display of images. https://phabricator.wikimedia.org/T148995 CKoerner (WMF) (talk) 14:37, 8 November 2016 (UTC)

Agreed. (even though I'm 21 days late to this). I'd chalk it up to the images being too predominant and not being tiny thumbnails next to the text that's typically far more important. PolymathGirl (talk) 06:00, 29 November 2016 (UTC)

Although I don't mind its current size much, it is important that users can customise the box size by changing a setting stored with their account/browser session. I think three sizes called default, medium and small would be the best idea - with the image being the main thing resized:

• "default" as the current size and layout (summary image top or right, summary text with ellipsis dots at end, half font size toolbar with last edit date and Page Previews settings opener button)
• "medium" the same as default but with the summary image resized smaller and a bit less blank space padding in the whole Page Previews hover box
• "small" the same as medium but with the summary image resized slightly smaller.

I disagree with the use of scroll bars to show more of the article text unless the standard summary length can't fit into the box size. It is only a summary so should have ellipsis dots such as "..." at the end to show there's more (currently a missing feature) and no scroll bar because showing more is the whole point of the article page itself. Edwardj 123 (talk) 17:02, 5 December 2016 (UTC)

As to the scroll bars, I would agree with User:Edwardj 123 that scroll bars, while a neat extra feature, are kind of going beyond the scope of the purpose of the Preview, such that they don't necessarily need to be added to the Preview; that if a user wants to know that badly about the subject matter, they can just do what we've all been doing all along until this Preview feature came into Beta, which is just normally clicking the link. PolymathGirl (talk) 21:51, 5 December 2016 (UTC)

I didn't realize this was an option, to change box size, but that definitely seems like a worthwhile/beneficial option to have, for each user to be able to say "I just want a little bit" versus "I want quite a decent amount" of information from the Previewed page.

Would/should there be a more user-friendly way to inform users that they have the ability to customize size? For instance, assuming this makes its way out of Beta and doesn't have to be explicitly signed up for, in each user's Preferences tab (or the Settings gear within each hover, if that bit remains) to inform the common non-Wikipedian person who's just consulting the encyclopedia for information, for them to be able to see an informational "setting" of "If you would like to customize the size of your Preview box, here are your three options" (or "here is how to edit/modify that in your browser"). PolymathGirl (talk) 21:49, 5 December 2016 (UTC)

@Bush6984 I think the existing settings icon in the hover box is a simple easy to find way to access the settings and users should expect the customisation options to change the size of the Page Previews box to be in this settings page (like most other applications).

Edwardj 123 (talk) 15:35, 6 December 2016 (UTC)

Aside from the main Page Previews box/card being too tall issue, the summary image inside it is also too tall when displayed horizontally (it overflows slightly). For example, a link to https://en.wikipedia.org/wiki/Cube demonstrates this issue. Edwardj 123 (talk) 16:58, 13 December 2016 (UTC)

Convenient

This feature is really convenient for me. I do not need to open extra pages to look for more details or further information. I just can read the short summary about the linked words on the same page and do not waste time. In my opinion this function is awesome! AmicaVictoria (talk) 21:50, 20 November 2016 (UTC)

This is definitely a useful feature which I like lots but unfortunately there is the problem of users who don't visit the page not knowing about any mistakes on that page so not contributing valuable edits to Wikipedia. Edwardj 123 (talk) 17:16, 5 December 2016 (UTC)

NOT ready to leave beta, let alone be deployed by default

I saw via the Tech News posting on the English Wikipedia's Village Pump that Hovercards was leaving Beta and intended to be deployed by default to logged-out users. It is not ready. I turned it on to try it again and quickly noticed the "abruptly ending text" issue, which I see below is called a "very confusing experience" by OVasileva (WMF) just a month ago, and tracked by open bug T67845 at phabricator. This is a critical hurdle to jump before leaving beta.

Secondly, I'm not convinced this feature should ever be default. My intuition is that it will severely lessen the odds a reader will become an editor. Editors are the lifeblood of the project and we are already critically starved for them. Even if this tool would decrease the new editor rate by just 10%, that's an existentially bad side-effect. Jason Quinn (talk) 22:53, 21 November 2016 (UTC)

Hi Jason, As TheDJ notes below, the message you saw was a sort of 'head's up' that the plans are to move Hovercards out of beta in the future.

We are tracking bugs like the one you mention and intend to address the larger known ones before moving to production.

Did you get a chance to look over the results of the recent A/B tests the team preformed? The findings were generally positive in the communities we tested with.

"My intuition is that it will severely lessen the odds a reader will become an editor."

Interesting. Why do you think Hovercards would have a negative impact in this way? Folks would be less likely to hit "Edit" due to the preview? I'm not sure I follow, but I'd appreciate any clarification you could provide. Thank you for the feedback and the attention! CKoerner (WMF) (talk) 18:18, 22 November 2016 (UTC)

Yes. I think people would be less likely to edit pages. To edit, people need to see pages to find something they want to fix. But with hover cards, it discourages people from actually opening full pages.

Let's say that a typical reader (somebody who's never edited before) reads X primary topics in a session. For example, X might equal one and the primary thing the person visited to know about is "Meteorite".

When reading the "Meteorite" article, they see the wikilinks for "bolide" and "Tunguska event", neither of which the reader knows about. Currently, they open those links to find out. Sure, they may just read the first paragraph but they may also likely glance at more and possibly the whole article. With hovercards, you'll get the two sentence'ish blurb about what it is, they'll be satisfied, and move on with reading just the "Meteorite" article. They never glanced at the "bolide" or "Tunguska event" article. So what they never saw was that the "bolide" article contained an obvious grammar mistake and the "Tunguska event" contains obvious vandalism. As fixing vandalism and grammar are both "easy on" ramps to editing, we've missed our chances for this editor to take their first critical steps.

Mathematically let's suppose viewers come to Wikipedia to learn about (on average) X "main" topics and for each main topic they end up via wikilinks fully reading Y "secondary" topics (on average of course). Now let's further suppose while reading any main or secondary topic they read Z tertiary topics (on average). These are topics I'm defining as ones that they only needed the very basics about, like a definition or single sentence description. Without hovercards, the reader would open X + Y + Z articles during their Wikipedia session. With hovercards they would only open X+Y articles (because the hovercards satisfied their curiosity for the tertiary topics). As the tertiary topics will tend to be more obscure and therefore closer to "stub class" articles there will be for them lots of room for non-expert growth because they have lower editorial quality and fewer page watchers for vandalism. So I see readers missing out on Z pages (on average) that were ripe for them to try out their first edit. I suspect that my guess that hovercards could result in a decrease of 10% (or more) in the new editor rate is at the least a plausible hypothesis.

Wish I had more time to elaborate and look up some of the needed statistics. But, unfortunately, I'm very busy with work these days and even finding 30 minutes to edit is difficult at times. I do not have the time to give a researched reply where I find the values for some of these statistics. It's of course possible my intuition is completely off. And maybe there'd be no effect or even the opposite. Jason Quinn (talk) 19:28, 24 November 2016 (UTC)

We have 1000s of these kinds of 'critical' bugs that don't cause enough actual problems to be high priority issues. Annoying yes, confusing possibly, but blocking.. I seriously question the assertion.

"My intuition is that it will severely lessen the odds a reader will become an editor" I see no reason for that, but real life deploy would give us metrics. So my question would be, will there be metrics.... —TheDJ (Not WMF) (talk • contribs) 10:22, 22 November 2016 (UTC)

Hello, yes, we will have metrics. We will follow the same schema used in the A/B tests, as well as an additional metric which will add the idea of reading depth to the schema (more info here). This will allow us to test the running hypothesis that hovercards might encourage readers to read further into an article and thus make them more likely to notice errors or potential additions within the initial article they are reading. OVasileva (WMF) (talk) 15:17, 2 December 2016 (UTC)

BTW. It should be mentioned that this is just the announcement for the start of this process, not an actual deploy. —TheDJ (Not WMF) (talk • contribs) 10:31, 22 November 2016 (UTC)

I do not agree with Jason Quinn - I think the feature should be rolled out ASAP and is ready for that already: it's way too useful to wait for all bugs to be solved before roll-out (besides if they are expected to be fixed near-term). I also don't think that the tool will decrease the new editor rate in any significant way: Wikipedia just becomes way more useful, time-efficient and people will probably just fetch info on more articles instead of not reading/clicking them at all.

There are many other things to do that could increase the rate of new editors. Fixuture (talk) 20:25, 6 December 2016 (UTC)

Wiktionary

Hovercards is cool for Wiktionary because we can detect quickly if there is a picture or not yet in a target page, but text is not display. I imagine it is because of the army of template in this project. If possible, can you target and display only lines starting with a # and it will be definitions and it may be very useful then! Thank you in advance to consider this suggestion. Noé (talk) 20:42, 22 November 2016 (UTC)

Please make sure that the text ends with a dot

Many times the text just end abruptly, like "~~~. ~~~. ~~~" and causes a (minor) confusion. Please make most of the texts to end in a '.' or ';'. רן כהן (talk) 07:03, 25 November 2016 (UTC)

This part of https://phabricator.wikimedia.org/T150814 ("In the case that the text ends mid-sentence, there should be an [ellipsis] to indicate there is more text").

Tracked in Phabricator
Task T150814

Tbayer (WMF) (talk) 02:50, 26 November 2016 (UTC)

Definitely - I look at these Page Previews and notice the annoying abrupt mid-sentence ending, wondering who forgot the common ellipsis dots "..." to confirm to users that it's a summary. Edwardj 123 (talk) 17:13, 5 December 2016 (UTC)

Cool!

I just try this feature and it's straight my way to wikipedia... Great. Wildan Masyiyan Chaniago (talk) 11:14, 28 November 2016 (UTC)

I just tried it, and at first glance I'm definitely a fan. It spares having to open separate tabs when you're just looking for a quick reminder. PolymathGirl (talk) 06:01, 29 November 2016 (UTC)

>It spares having to open separate tabs when you're just looking for a quick reminder.

Exactly way I think this feature will have a negative impact on the new editor rate. Jason Quinn (talk) 13:34, 3 December 2016 (UTC)

{{ping|w:User:Jason Quinn}} Why do you suspect that opening tabs should affect the rate of new editors?

I'm not saying it couldn't, but I can't readily imagine any reason they're in any way related; Previews-upon-hovering versus new editors's reasons to start. These seem unrelated. Could you provide context? PolymathGirl (talk) 21:54, 5 December 2016 (UTC)

Really like this new Page Previews feature (please deploy it) but make sure it doesn't reduce the amount of users who contribute to Wikipedia, doesn't have abruptly ending text (add ellipsis dots) and users can customise its size by changing a setting (some want to make it smaller).

Also, I have spotted a minor issue: when the summary image is displayed horizontally, it overflows the hover container vertically. Edwardj 123 (talk) 22:11, 4 December 2016 (UTC)

What metadata should be displayed (article quality, last edited, user views, settings icon etc.)?

This discussion topic is about what metadata should be displayed in the Page Previews/Hovercards feature along with the summary content.

The most discussed metadata items are:

• Article quality (a brief piece of text/icon tool-tips and optional icons indicating the how reliable and good the article is, perhaps showing its particular status such as featured article)
• Last edited (a brief piece of text stating the date and time that the article was last edited, typically short local format with standard long UTC format as tool-tip text)
• User views (a brief piece of text stating the number of users who viewed the article within a certain amount of time which can be abbreviated to units such as K - kilo or m - million)
• Settings icon (an icon linking to a tool to configure personal user settings for the display of the preview box which can include opt-in features that only editors would want to enable)

Currently (February 2017), only the settings icon is shown in this feature.

Upon hover, the hovercard display of content seems great, but it seems unnecessary clutter that the settings "gear/wheel" and "Last edited X days ago" display. Those could be gotten rid of, on account that very few people hovering for info probably care whatsoever about the recency of editing status. This would further allow room for more worthwhile text summary to be displayed. PolymathGirl (talk) 06:12, 29 November 2016 (UTC)

Agreed. That will get old quick. Minerbraden (talk) 21:26, 8 December 2016 (UTC)

I think the settings icon is a valuable feature in the Page Previews hover card box because most users will want to have easy access to the settings to quickly change the size of the hover cards or disable them.

The last edited status text seems fairly important and is only a small bit of text so should be kept, particularly for editors' benefits.

The text summary could perhaps be extended, by a maximum of 8 words (not too many to make it visually bad and more than a summary) - particularly when the image is displayed horizontally to the right providing a gap between the summary text and the toolbar. Edwardj 123 (talk) 17:11, 5 December 2016 (UTC)

I would think that changing those settings should be in a more generalized location, such as the "Preferences" or "Beta" link in our upper-right-hand corner, rather than cluttering the space in each and every single drop-down info box upon hovering.

My rationale here is that when people are hovering to get a quick summary of a topic in order to be able keep reading their main article, "Settings" and "Last Edited" are some pretty useless/ancillary bits of information. If I care that much to know a page's last edit, I can click the page itself to look at it. Likewise, if I care that much to change my "Page Preview" settings then I can go to my "Preferences/Beta" links just like I did in order to enable them initially. Point being, the "cost" of having those two items clutter screens is not offset and countered by the negligibly small "benefit" of the tiny few number of users who actually want to use those features directly from the Preview drop-down.

Hopefully that makes sense; that my point is not that those are 100% irrelevant, but that they are instead just rather poorly-placed to "cost" and take up space on every single Preview. To my logic, that is not the purpose the Preview tab serves, and therefore it's irrelevant clutter. PolymathGirl (talk) 21:44, 5 December 2016 (UTC)

Getting rid of the settings icon seems too much - it's such a tiny addition to a large box mostly filled with content, improving user experience because it simplifies accessing these important settings and needing less time to do things is a feature many people in society value. Although they are settings that would be infrequently used, the small icon is hardly cluttering up the space. Edwardj 123 (talk) 15:45, 6 December 2016 (UTC)

If you say so. I disagree, but I'm not gonna waste my time in a back-and-forth.

The purpose of the Preview is quickly viewing a short summary of information, not having bells and whistles. There's no sense in retaining lots of side-bar and bottom-part miscellany when the primary function the Preview is supposed to serve is to: preview. PolymathGirl (talk) 22:37, 6 December 2016 (UTC)

Alright. I won't continue this back and forth debate between us and I partly agree with your point that the Page Preview settings could be accessed elsewhere despite the use case of quick access for inexperienced users using a small icon.

It would be valuable to have a few pieces of small metadata information in the preview box such as article quality, user views or last edited though.

Places for Wikipedia to provide access to Page Previews settings/preferences: user "Preferences" link in the header, link in the footer next to "Mobile view" when not logged in, optional settings icon in hover box. Edwardj 123 (talk) 16:13, 7 December 2016 (UTC)

I'm obviously in the minority here. I find "Last Edited" very useful indeed, but could happily lose the Settings icon. Last Edited gives me a really quick sense of how inactive the article is. I'm then much more likely to follow through from the preview on the page I'm currently editing if the previewed link shows that page has not been updated for some time. I can probably make some quick, useful edits there.

I do agree with Edwardj123 that it would be valuable to have Article Quality in the preview. From an editing point of view, both pieces of information are valuable. I recognise that a recent bot edit affects the Last Edited date. But if it shows a page is stale, clearly neither bot nor editor have been active there. So maybe I can usefully contribute something there, and the Hovercard Preview info helps me make that decision. Nick Moyes (talk) 01:30, 13 December 2016 (UTC)

I too think that the "Last edited" info is unnecessary and just takes away space that could be used to show something more useful (for instance info on the article's quality-status, geo-coordinates or maybe even meta-information such as views the last 30 days etc). Fixuture (talk) 20:15, 6 December 2016 (UTC)

"Last edited" is useful. It could show the user how active that specific article is. If the user sees that the article was last edited long ago, he would be able to quickly conclude and go view the article, edit it with the most-recent updates for that specific topic of that article.

EG :

Let us say that there is a user/editor that was reading an article about some medicines. The article recommends another article, which states the side effects of that same medicine. He wants to view that article, however, he sees that that article was last edited 5 years before. He then realizes that it might have included that it has info which was recently proved wrong. He could check it out on some hospital website then edit the article with the correct, up-to-date info. Marc J Francis (talk) 16:59, 17 December 2016 (UTC)

More discussions of these metadata features:

• Keeping last edited - https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2017#h-Hello_Hovercards_-_bye_bye_%27last_edited%27-2017-02-23T23%3A48%3A00.000Z
• Removing/keeping last edited - https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2015#h-Get_rid_of_%22last_edited%22.-2015-12-24T15%3A54%3A00.000Z
• Keeping article quality, specifically featured articles - https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2016#h-Featured_article-2016-10-17T18%3A06%3A00.000Z Edwardj 123 (talk) 13:48, 24 February 2017 (UTC)

As an editor, "last edited" is all too important. The overwhelming number of edits I make on Wikipedia rely on that feature, and to not have it would impede greatly on my edit frequency. TBMNY (talk) 15:58, 24 February 2017 (UTC)

"As an editor" ... I'd like to point out, that you have the option of using the navigation popups gadget, which has tons of editor specific information. —TheDJ (Not WMF) (talk • contribs) 14:27, 2 March 2017 (UTC)

-> simply make it an option what to display Fixuture (talk) 13:49, 26 February 2017 (UTC)

"simply make it an option what to display" adding options introduces lots of complexity though. Take the navigation popups gadget. It has about 50 options, greatly complicating it's code base. In reality, only about 5 options are used by more than a dozen people or so. I think it is no problem to be very conservative with adding options to this previews feature and to take the time to do so. It's always easier to add options, than to remove options. —TheDJ (Not WMF) (talk • contribs) 14:31, 2 March 2017 (UTC)

As I had predicted, my Wikipedia edit rate has naturally plummeted without the "last edited" feature. TBMNY (talk) 15:22, 2 March 2017 (UTC)

Just as long as "last edited" is available as an option for editors to turn on, then I shall be delighted. If it's not, I suspect many editors won't bother with it, and that would be a real shame for productivity, as TBMNY has indicated.

Until recently it has been really great to quickly run down a list, mouseover, check the link is correct with some visual assistance, and to see how recently (or not) the target article was last changed. Try it on this list of 940 speciest, for example. How many of these articles haven't been touched for some time?

No, I don't know either now. Nick Moyes (talk) 22:47, 2 March 2017 (UTC)

Subscript is lost

The hovercard not save the original design of the text, superscript and subscript are converted into regular. For example, the article "sodium bicarbonate" NaHCO₃ formula looks like NaHCO3. Sorry for my bad english. 2A01:D0:9085:0:C5CB:F11E:69F1:8D9E (talk) 22:12, 4 December 2016 (UTC)

Page images are article metadata, avoid embedding it into article

I see that the plan seems to be creating a parser function for choosing page images on a page, phab:T91683.

As a passive observer that has used other wikis before, I'd say that this is a pretty massive mistake of simply repeating history by putting metadata into the article. Categories are a great example of a tool which has massive problems because of this:

• Localization is impossible - A category is really just a tag, but because it is embedded in an article it can't be translated without massively duplicating the data
• No stable id- This causes several issues, it can't be removed or renamed without needlessly editing every single article containing it
• No centralized GUI or curation tools to manage it
• Performance issues - Phab:T116001

The same thing will be repeated if this is added as a parser function for setting page images:

• Parser function on each article - on 100000 articles, every single article will need to be edited to remove or change it
• GUI or better tools - this would make it once again hard to choose or change images using mobile devices
• Duplicate work - A bat would use the same image, but this would need to be set on every article on every wikipedia, instead of using and encouraging something like wikidata
• Complicated parser function + wikitext - people will likely add parser functions within it, and use hacks like "{{#tag" on it

About the only benefit is setting these images using templates. That in itself is a problem because templates are complicated beasts. This could be done way better by using simplified GUI based decision trees.

Unlike categories, images can be understood by everyone and many people can help out to choose appropriate image for articles. Anyway, this parser function path seems to be already set, but perhaps one day it will be revisited. 197.218.81.208 (talk) 08:58, 6 December 2016 (UTC)

Hovercards show a summary of the article. Therefore, the image shown in the hovercard should be "the image" of the article, and it should be updated when article updates. Usually the automatic choice of image is fine - at least, as fine as the automatic choice of text - but sometimes it isn't and a template or magic word could fix it.

I agree that the tool could be simpler if the image were stored somewhere else (Wikidata?), just as it could be simpler if text would stored somewhere else, but then the hovercard wouldn't be showing a summary of the article. It would be showing something else.

Could hovercards show a summary of Wikidata instead a summary of the article? Yes, they could. Would that be more useful? I think it wouldn't. Pere prlpz (talk) 16:25, 6 December 2016 (UTC)

The idea is to replicate the PAGEBANNER magic word that the Wikivoyage community has been using. It's probably worth reaching out there to see what issues they've had if any with using this. With regards to Wikidata that's captured here: https://phabricator.wikimedia.org/T95026 but I suspect the user of this is going to be an edge case, not the norm. Usually the choice made by the automatic algorithm is good enough. Jdlrobson (talk) 17:59, 6 December 2016 (UTC)

The most common case where the automatic algorithm fails is when it takes an image from a template (e.g. a background map from an infobox or an image from a navigation template) unrelated to the article subject. For those cases a negative magic word (that is, telling the algorithm not to take a given image) could work as well as a positive magic word (telling the algorithm to take a given image).

In fact, positive and negative magic words could be included in templates. Pere prlpz (talk) 18:07, 6 December 2016 (UTC)

> I suspect the user of this is going to be an edge case, not the norm

To quote yourself:

"Why edit in the page when you can edit outside it? ... how many things could be made into metadata?)"@Jdlrobson, Phab:T87686.

I'd also refer you to this:

http://top-10-list.org/2009/09/02/great-inventions-that-went-bad-for-mankind/

Embedding this in the article wikitext will severely limit the possibilities of this useful tool, as you rightly noted about categories. First of all it will be based on a name and not an ID, prolonging the problem with English parser functions, and image names.

To put it into perspective, imagine just how much more warring and how big of a mess it would be if the title of the page was embedded within the wikitext. This will also need proper wikitext, VisualEditor, parsoid support and probably many other tools, when it could simply be a value in the database set with an API. Then people will likely also create rules and strange ideas about where it should be placed within an article or template, much like how they argue about the location of categories.

Instead doing this "properly" would also encourage micro-edits, and participation that doesn't require learning yet another parser function, and looking through a huge list of parser functions.

It doesn't necessarily have to be in wikidata, it could use a mechanism similar to how the page title works stored in an on-wiki database. 197.218.81.177 (talk) 20:29, 8 December 2016 (UTC)

A simple way they can easily abuse the parser function is by simply running a bot that will put it into ALL articles thereby negating any perceived benefits of the "pageimages" algorithm. This would essentially disable the pageimage algorithm and put the choice of image completely under their control, and waste processing power because the algorithm will probably still choose an image before or after they change it. Or even put it into a template, and trigger the same problems as currently exist when a highly transcluded template is changed.

This could be used as a counter measure to force their choice if their demands that the algorithm be completely disabled are ignored by the WMF.

See? it isn't hard to abuse any useful tool. 197.218.81.177 (talk) 22:29, 8 December 2016 (UTC)

If you are concerned that an affirmative parser function can be abused, we can use a negative parser function, to tell the software which image not to use in hovercards. Pere prlpz (talk) 00:37, 9 December 2016 (UTC)

> If you are concerned that an affirmative parser function can be abused, we can use a negative parser function, to tell the software which image not to use in hovercards.

Seems that would create even more work a bit like whack a mole where they might need to add multiple "disable page images". It could still be abused in the same way though, simply run a bot to detect all images used in an article, and disable all of them.

Anyway, I've made my point, the developers will probably find their own way, or simply follow the path of pagebanners, which to be honest has the exact same anti-pattern (problem). 197.218.90.116 (talk) 18:36, 9 December 2016 (UTC)

I think that Hovercards will help a lot. Do you?

This is a great tool to use and it was smart to add them. Minerbraden (talk) 21:24, 8 December 2016 (UTC)

Yes, it is quite useful. It can avoid opening separate tabs while you just need a quick reminder/summary. Marc J Francis (talk) 17:10, 17 December 2016 (UTC)

This has proven to be very useful to me, it's a great idea. Definitely strengthens the desire for improving intros, too! LovelyLillith (talk) 07:47, 1 January 2017 (UTC)

Horizontal gradient – HTML5, CSS and JavaScript code/formatting issues

This topic is for discussion of the computer code used to display the Page Previews/Hovercards feature, mainly issues with HyperText Markup Language version 5 (HTML), Cascading Style Sheets (CSS) and JavaScript (JS).

After a quick look at the Page Previews/Hovercards HTML5 code, I noticed that the CSS frequently uses pixels which is bad because it's an absolute/fixed unit so doesn't change on different screen sizes, browsers and devices (requiring extra media query code to fix this). Using relative units, a feature of responsive web design, is a simpler and better approach which is already used for most MediaWiki web page formatting and should be used here.

The main responsive relative units which should be used are em/rem (based on font size) and percentage widths (%). Also, this problem isn't just about element lengths; the font size of the hover box uses pixels too, which can look bad on different screens. Using "em"/"rem" for the font size (relative to element and browser font sizes) is best. Edwardj 123 (talk) 10:54, 10 December 2016 (UTC)

Another issue is the summary image inside the Page Previews container being too tall when displayed horizontally (it overflows slightly). For example, a link to https://en.wikipedia.org/wiki/Cube demonstrates this issue, showing the image sticking out downwards by a few pixels. This should just be a quick Cascading Style Sheets fix - making the image have a maximum height of the container's height (e.g. max-height: 100%) and ensuring nothing else can overflow or cause scrollbars. Edwardj 123 (talk) 17:05, 13 December 2016 (UTC)

Tracked in Phabricator
Task T153840

Reported this particular issue (overflowing summary image) as T153840. —TheDJ (Not WMF) (talk • contribs) 09:52, 21 December 2016 (UTC)

HTML/JavaScript/CSS is enabling me to save Academic Information Pages as is.

Enabling us to access this valuable data for all free and self-actualization

Because of Java and HTML l'm accessing and saving data as page documents.

Thanks to Wikipedia.Org and latest technologies for 21st century,(CISCO/MICROSOFT etc)

Marry Christmas and Happy New Year 2016-17/20. Tshons (talk) 21:59, 25 December 2016 (UTC)

I recently spotted a visual problem with the horizontal gradient (which is used to show the article content continues) at the end of the article description text: its large height causes it to cover part of the previous line.

After checking the HTML code, I found the problem. The text line height is set to 20px and the gradient pseudo-element has the height 24px. The pseudo-element should be the height of a line of text (20px here). To prevent the issue happening again if the text font size changes, the height should be set to "1em".

Please fix this minor issue - an image showing my screenshots of the problem is available at https://snag.gy/v3Tf8z.jpg and any article with a tall letter such as "g" on the end of the second last line of the Page Previews/Hovercards text should cause this problem. Edwardj 123 (talk) 16:52, 21 April 2017 (UTC)

Tracked in Phabricator
Task T165974

@Edwardj 123 - thank you for pointing this out, filed a bug and lined up for the next sprint (should be fixed within 2 weeks). OVasileva (WMF) (talk) 11:38, 21 May 2017 (UTC)

Closed duplicate issue Minor bug: horizontal gradient also affects the forelast row (https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2017#h-Minor_bug%3A_horizontal_gradient_also_affects_the_forelast_row-2017-03-12T22%3A48%3A00.000Z). Edwardj 123 (talk) 21:42, 22 May 2017 (UTC)

Fix the sentence cutting at the end

The sentence cutting is a little irritating. I would suggest maybe it can pick the first 2 or 3 sentences from the page. Heydari (talk) 01:17, 15 December 2016 (UTC)

In another topic on this talk (https://www.mediawiki.org/wiki/Talk%3APage%20Previews/2016#h-Please_make_sure_that_the_text_ends_with_a_dot-2016-11-25T07%3A03%3A00.000Z), the problem was added as a bug report to their Phabricator collaboration platform (https://phabricator.wikimedia.org/). Edwardj 123 (talk) 17:06, 16 December 2016 (UTC)

Thanks for the information Heydari (talk) 19:02, 14 March 2017 (UTC)

This should now be fixed - we have decided to choose a solution where a horizontal gradient appears - in order to indicate to readers that the section continues. Let us know if you experience any issues. OVasileva (WMF) (talk) 21:00, 17 March 2017 (UTC)

Good tool

I think it's a good tool. It is useful whenever the article that is shown in the popup box has a good introduction. Ayagaures 0 (talk) 19:42, 17 December 2016 (UTC)

I'd like this feature enabled for the TOC

This feature would be useful with articles that have a large TOC FourLights (talk) 23:46, 20 December 2016 (UTC)