Talk:Page Previews/2014/05

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

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

Archived discussion for this page are available at /Archive 1

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

hovercard obscures links, buttons

the hover blocks the blue links and buttons. and does not go away when scrolled off. i.e. can't see save page or preview button when the hover of the CC license drops down. 98.163.68.34 (talk) 00:48, 1 May 2014 (UTC)

98.163.68.34: Can you share which Operating system, browser and version of that browser you are using ? That will likely be helpful in solving.

Also, the "CC license", can you detail which exact page you that ? —TheDJ (Not WMF) (talk • contribs) 10:12, 1 May 2014 (UTC)

Namespaces

Now Hovercards works for all links. Most users don't want 'summary' of templates, userpages etc. I thinks we should keep it only for mainspace and maybe for files. — putnik 14:33, 2 May 2014 (UTC)

It might be better if we can turn on/off namespaces in a user preference, just as Echo does for notification types.

I think the Project (Wikipedia, Wiktionary, etc) namespace is justified because those pages usually (or are expected to) start with a short summary. However, a talk page is not meant to have a cohesive content to be summarized and does not fit with Hovercards, IMO. Templates and user pages are arguable - as an editor I personally would like to see a summary there, but as a reader, I might not. whym (talk) 03:51, 5 May 2014 (UTC)

Whym: I filed enhancement bug 65692 - Hovercards should show useful info for talk page. It's related to a discussion about whether the Talk page link could show activity level on the talk page, as the MobileFrontend does in alpha mode. SPage (WMF) (talk) 19:33, 23 May 2014 (UTC)

Totally agree to both posters. It probably should be configurable.

As an example, personally, I'd only like to see hovercards

1. When navigating in article namespace for other articles
2. When navigating elsewhere for project pages
3. Redirects

I don't like and don't need hovercards anywhere else, since they distract me and are an needless clutter often shadowing the content I actually want to read. Patrick87 (talk) 09:30, 6 May 2014 (UTC)

Disconnected indicator arrow-head

(Copied from Village_pump_(idea_lab)#simple pop-up when hovering the mouse over hyperlinks)

Are we talking about the little boxed popup that happens when we hover on a cite index? It seems somebody thought it would be nice to put a little arrow at the bottom of that, located over the cite index being har\\overed. Problem: The little arrow gets disconnected on an incoherent basis depending on the order selection of the cite indices. Check this picture:

You can see the little arrow far to the left on the page margin. I'm using Iron 27 in W7HPx64SP1. Gordon | Talk, 07:04, 4 May 2014 (UTC)

This is a different gadget called Reference Tooltips. Perhaps at some point it will be merged with this Hovercards feature... ? —TheDJ (Not WMF) (talk • contribs) 12:59, 19 May 2014 (UTC)

A cross-wiki Hovercards

On Wikimedia Commons, Hovercards displays an extract of a Commons page. And doesn't work on [[:en:toto]], [[:fr:toto]]...

It would be interesting to display an extract of a wikipedia page. Pyb (talk) 11:37, 6 May 2014 (UTC)

i think this is a brilliant idea, and to the best of my knowledge, it's easy to implement. we could even have hovercards on the interwiki links!. the only delicate point here is the need to pay attention to RTL/LTR: the card should use the directionality of the target wiki, rather than the present one.

same for links to other projects (wikitext, wiktionary etc.), as long as the target wiki has the mobile extension installed.

peace. קיפודנחש (talk) 23:27, 9 May 2014 (UTC)

Show to IP or logged out users only?

This is a small feature, designed for readers. What if we were to start with an experiment where we only show this to anonymous editors? Vibhabamba (talk) 13:10, 10 May 2014 (UTC)

Select Text from Hovercards

Hovercards are currently a link as a whole. There's no possibility to select the text displayed on the hovercard. As you can see from the extract below, the <a href> is applied to the beginning of the text. I think the <a href> should be applied to a button beneath the extract text thus allowing the possibility of copying text from hovercards.

So it should rather be this:

<svg xmlns="http://www.w3.org/2000/svg" width="203" height="250">
<image xlink:href="https://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Cobalamin.png/239px-Cobalamin.png" x="-18" y="-25" width="239" height="300"></image>
</svg>
<div class="mwe-popups-extract">Vitamin B12, vitamin B12 or vitamin B-12, also called cobalamin, is a water-soluble vitamin with a key role in the normal functioning of the brain and nervous system, and for the formation of blood. It is one of the eight B vitamins. </div><div class="mwe-popups-timestamp-recent">
<span>Last edited 3 hours ago</span>
</div>
<!-- using Foundation Zurb css framework for illustration -->
<a href="/wiki/Vitamin_B12" class="button small success"> Read article </a>

Nkansahrexford (talk) 07:06, 12 May 2014 (UTC)

Thanks for bringing this up. We briefly considered this idea, but then there were no clear use cases as to why a user would like to select text from a floating panel. There are also considerable accessibility challenges with selecting text from floating panels.

The other factor that came into play here was that, we want to make sure there is a large target area for the user to get to the article, hence the entire card is a target url.

What are your thoughts on this? Vibhabamba (talk) 20:19, 18 May 2014 (UTC)

Vibhabamba: I think your point is true and makes sense. For the general user, I also think there won't be as much use cases for selecting the panel text. Making the target area bigger too is fine, and I agree.

Good work guys. I think the hover cards is now almost perfect, if not perfect already.

cheers. Nkansahrexford (talk) 08:55, 20 May 2014 (UTC)

Hovercards leaving text all over the browser

Hovercards come up but then don't always disappear cleanly, leaving text (but also sometimes very small images) on top of your browser window, which makes editing quite a challenge when it happens while editing. I am using Chrome and the source editor.

This is an example. I am viewing (not editing) Yowah, Queensland and I have hovered over the "Eulo" link in the adjacent localities section of the infobox. This is the result.

Kerry Raymond (talk) 00:11, 17 May 2014 (UTC)

Thanks for reporting this. Hovercards will not be visible when a user is in editing mode.

I just tested this in read mode and its not happening for me. https://en.wikipedia.org/wiki/Yowah Vibhabamba (talk) 20:15, 18 May 2014 (UTC)

What I see there looks like Navigation Popups, not Hovercards. "I spot "disable popups" in there for instance, which is a Navigation Popups link. What might be possible, is that the user has BOTH enabled, and some sort of 'race condition' is occurring. —TheDJ (Not WMF) (talk • contribs) 12:57, 19 May 2014 (UTC)

TheDJ: Hmm, I cant think how Hovercards could leave rubbish. The CSS should be intact. Any insights from the gadget? Could it be that its styles are removed? Prtksxna (talk) 16:01, 19 May 2014 (UTC)

Prtksxna: something else that could be the problem here, is last weeks bits.wm.org outage... That should clear out by itself though. —TheDJ (Not WMF) (talk • contribs) 16:07, 19 May 2014 (UTC)

Remove images from Hovercards

Yeah... I was going over w:Eggman a few minutes ago... there are certain images in the internal links, rotund for example, which leave... rather scarring images in your mind. So please take a look at the images used when creating hovercards Darkness Wizard (talk) 20:25, 18 May 2014 (UTC)

I see your point, but we can't really screen images. The image in the hovercard will be an image contained in the page. And really that effect could be seen on actual pages as well. Vibhabamba (talk) 23:04, 18 May 2014 (UTC)

isn't there a designator on images, such as G or PG or R or X or don't let the five hear old on the computer because wikipedia is showing porn on it's hover cards?

I love the images, but if there was a designator even categorically it would be better than nothing, else we can start a project of "rating" images based on appropriate content i.e. age appropriate er, uh... gosh that 'whats appropriate' is subjective as well as just down right intimidating isn't it? Eossipov (talk) 14:18, 20 May 2014 (UTC)

Eossipov: There have been 100s of discussions on this topic already, it's a huge wasp nest, much more 'subjective' than you expect. Dealing with that is WAY out of the scope of this project. —TheDJ (Not WMF) (talk • contribs) 09:52, 21 May 2014 (UTC)

Feedback

I've just tried the Hovercards extension and I would to say that it is a fantastic tool. I don't previously know the navigation popups and this appliance is fine to me. Fugi-bis (talk) 07:46, 19 May 2014 (UTC)

I too think that Hovercards is an amazing feature. It definitely enhances the user experience of browsing Wikipedia. It gives the real essence of reference work that was supposed to be the original purpose of having wikilinks on an article, the additional feature here is that no longer need to each and every link, you can just hover over it to learn about it in a nutshell. -Diptanshu Diptanshu Das (talk) 17:57, 24 May 2014 (UTC)

Hopping on Firefox

Hovercards hop up and down on Firefox 29.0 on Ubuntu 14.04, apparently when I put the mouse pointer over a link somewhere in the lower half of the screen and the card is going to show up above the pointer. I see this phenomenon when hovering over the "skin" link in the last line of the lead section of Help:Navigation on a 1366x768 screen.

Links in the upper half of the screen (and the cards shown below the pointer) nor Chromium do not seem to have this problem. whym (talk) 12:30, 19 May 2014 (UTC)

Whym: i'm pretty sure i made it happen with google chrome on windoze, too. i do not think it's ff specific.

(after some more testing: in chrome, i made it "blink" once or twice at most. with ff you can make it blink indefinitely, so it's really not the same).

guess: the hovercard contains a piece which inserts itself above the element, effectively causing a &quot;mouseout&quot; event. remedy: when popping the card upward take 8 more pixels distance from the event (i.e., reduce 6 pixels). a better remedy would be to set the location of the card using &quot;bottom&quot; instead of calculating the height and using &quot;top&quot;. i discussed the issue in Bugzilla:62971#c12 .

peace. קיפודנחש (talk) 21:37, 22 May 2014 (UTC)

Whym, Salix, the flickering-bug patch is now live and tested. The core problem is fixed on all wikis. Thanks again for your patience and bug-reports. :) Quiddity (WMF) (talk) 22:53, 5 June 2014 (UTC)

Hi, I get the same effect with Firefox 29.0.1 over the links "skin" and " Recent changes". Salix (talk) 14:55, 20 May 2014 (UTC)

This bug is tracked at bugzilla:65433. HTH. Quiddity (WMF) (talk) 17:13, 21 May 2014 (UTC)

Quiddity (WMF): Thanks, but it's getting worst ! It happens quite all the time now. Seems to be mostly when the card is displayed above the link. Salix (talk) 19:24, 22 May 2014 (UTC)

Salix: I believe it only occurs when the card is above the link - I've never seen it occur for a card below the link (I tried multiple examples, just now). But yeah, the developer is working on it; I'll ask him for any news, when we next overlap timezones. Quiddity (WMF) (talk) 21:06, 22 May 2014 (UTC)

Quiddity (WMF): I will have to disalble this feature - pity - because when I clic on a links there is not effect as Hoverdard is covering it. I have asked for a larger space in between the text line of the link, and the top/bottom of the card. It could solve this trouble too. Salix (talk) 22:53, 22 May 2014 (UTC)

Great

This is one amazing feature. Fantastic! I love it!!!! Ajohnson2199 (talk) 20:49, 19 May 2014 (UTC)

Thank you! We launched Hovercards in April and we hope to make it available on certain language projects first. Most Beta features have a life of 6 months so we have until August to get as many editors as possible to participate in the discussion and tell us what they think. If most of the feedback tends positive, the beta feature graduates and becomes part of the default experience. Vibhabamba (talk) 00:32, 20 May 2014 (UTC)

Images too large?

Hi, I noticed today on hovercards, the images being displayed are not consistent and mostly bigger than the hovercard itself. Perhaps a nice 100x100 image would be great because then we can see text under it. If there was a way to programmatically change this for all that would be great, if not, I could see where it would be a major pain in the arse.

:)

Hovercards are a wonderful feature. Great Job folks! Eossipov (talk) 14:13, 20 May 2014 (UTC)

Cards open off screen

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.

---

If a user hovers over a link at the bottom of the browser view area, hovercards open downwards, obscuring itself, therefore requiring the user to scroll down. If the hovercard could open upwards if link is at bottom half of page, that would be one fix. I hope this will be an easy fix. Iczero (talk) 02:57, 21 May 2014 (UTC)

This seems to be fixed now, can you take a look and tell us what you think? Vibhabamba (talk) 07:44, 27 May 2014 (UTC)

It works for me too. Iczero (talk) 23:19, 31 May 2014 (UTC)

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

Hovercards in article pages only

After several days testing, today I have decided to deactivate Hovercards. I think they are very good for readers of articles, but they get in the way in several of my routines as volunteer editor. I believe the problem is that those routines imply pages with lists frequently, starting with the watchlist, and continuing with other lists of articles. In these cases links are close to each other and too often you open them to new tab with right-click, creating several accidental cards that get on the way.

I was wondering whether it would be technically possible and whether it would make sense to activate the cards only in articles (Main namespace) and not in the rest of namespaces, used less by casual readers and more by editors. Sorry if this has been discussed before, I'm not following this feature closely. Qgil-WMF (talk) 21:57, 22 May 2014 (UTC)

It is too large in my opinion. I do not like it. The older one is more better. MrFawwaz (talk) 00:05, 23 May 2014 (UTC)

Well, it looks like I'm the only one bothered about this. Good news?  :) Qgil-WMF (talk) 17:39, 30 May 2014 (UTC)

Hover twitch

I was on pt.wikipedia in the proposals Village pump (Wikipédia:Esplanada/propostas) and trying to click on the general village pump link in the right sidebar and the hover card kept popping on and off intermittently and I was not able to click on the link and go to the desired page. GoEThe (talk) 09:35, 23 May 2014 (UTC)

GoEThe and Jr8825, the flickering-bug patch is now live and tested. The core problem is fixed on all wikis. Thanks again for your patience and bug-reports. :) Quiddity (WMF) (talk) 22:52, 5 June 2014 (UTC)

Same problem here, I've had to disable the beta for now because it's too disruptive to navigation. Jr8825 (talk) 13:05, 27 May 2014 (UTC)

Hovercard hover placement issue.

I'm not sure if I'm the only one experiencing this but whenever I mouseover a wikilink the hovercard pops up directly where my cursor is so I cannot click the link itself which is crazily annoying because then I sit there trying to move my mouse lightning-fast clicking as fast as I can so I can "click" the wikilink before the hovercard pops up and blocks it. If it were 5-10px above/below the hovered-over wikilink then it would be fine. Dainomite (talk) 14:13, 23 May 2014 (UTC)

Dainomite: please note that the hovercard itself links to the same article as the element that triggered it, so there is no need to "move your mouse lightning-fast clicking as fast as you can".

simply click on the card itself when it obscures the element.

that said, the hovercard should not pop directly under the mouse pointer: when it opens downward it should be some ~20 pixels below the pointer, and when popping upward (happens if triggering element is in bottom half of browser's window), it should be some ~20 pixels above pointer.

peace. קיפודנחש (talk) 15:27, 23 May 2014 (UTC)

קיפודנחש: Sadly it doesn't always work that way as the gif uploaded by Odie5533 below illustrates. Dainomite (talk) 04:50, 24 May 2014 (UTC)

Dainomite: this is a known issue, reported in another topic here (i don't know how to link to a topic in "flow") and reported in Bugzilla:65433 .

i was only referring to the "can't click" part.

the flickering thing seems to be firefox specific, at least i did not hear of the problem with any other browser. i can make it happen in chrome, but only once, not repeatedly as in the gif.

peace קיפודנחש (talk) 13:58, 24 May 2014 (UTC)

Dainomite: I am having the same problem on Chrome. For me, the hovercard is always too low. Jessaveryja (talk) 17:29, 24 May 2014 (UTC)

I'm experiencing the same problem as Dainomite, and I also find it extremely annoying: very often when I put my cursor over a link, I have to Ctrl+Click several times to have the link opening in an other tab in Chrome. Simply clicking where the mouse is doesn't work every time.

Often, if I Ctrl+Click when the hovercard is poping up, the Ctrl+Click is lost, and the hovercard disappears and starts poping up again. Painful to use, I'm currently considering deactivating this feature.

I'm an old user of Navigation Popups, which I find a lot less annoying, first of all because it doesn't popup instantly after the cursor is over a link. There's a small delays, like tooltips, which makes it a lot friendlier. NicoV (talk) 16:45, 23 May 2014 (UTC)

I started getting the same problem. It only happens for the up-pointing Hoveracards, and not the ones that point down. I uploaded an image that shows the flashing behavior: http://imgur.com/sISA887 Odie5533 (talk) 03:51, 24 May 2014 (UTC)

Odie5533: Thanks for linking a gif of the problem. Dainomite (talk) 04:51, 24 May 2014 (UTC)

I've also seen an other situation, less frequent: sometimes, when the hovercard is completely displayed, Ctrl+Click doesn't work at all unless you move the cursor a bit.

If you repeatedly do Ctrl+Click without moving the cursor, the only thing that happens is that text is selected in the hovercard: first word, then all text, then nothing, ... NicoV (talk) 09:04, 24 May 2014 (UTC)

I've found that if I move my cursor over a link and pause, the hovercard stays in place and I can then move my cursor away from the card and click on the link. I'm generally moving my cursor to the left; would it be possible to set a horizontal offset for the card to the right of the cursor (or left, if you're at the right margin of an article)? It would also be helpful to increase the vertical offset a bit more for both upwards- and downwards-displaying cards, it's just too close to the link. (I think the problem might be that the pointer on the card is eating up nearly half of the ~20px offset; you might want to set the offset from the top of the pointer.) That said, I've noticed that the current offset is inconsistent, even on the same link. (I've uploaded an image.)

Given time, I could probably get used to clicking the card instead of the link, but old habits die hard. All that aside, I really do like the feature—and I'm sure the bugs will get worked out. Thanks! D'Ranged 1 (talk) 03:56, 26 May 2014 (UTC)

This bug is far too annoying to keep this feature enabled in my preferences any longer. If this is ever fixed I'd gladly re-enable Hovercard but in it's current state I just can't do it. Dainomite (talk) 21:19, 28 May 2014 (UTC)

Links to flow boards

Links to flow boards have hovercards that are useless, showing just "This talk page has been taken over by a flow board". However, links to normal talk pages do not have hovercards. Flow board hovercards should either be removed or show info from the header. Jay8g (talk) 01:43, 24 May 2014 (UTC)

Feature update request

I feel that Hovercards is a great addon that enhances the user experience on Wikipedia and related wikis. As of now, on hovering on a link, it displays a portion from the relevant article lead and the associated image along with the details of last update of the page. I feel that one or two more parameters would enhance its value.

• As enabling of Hovercards is an optional feature, the image display in Hovercards could be made optional too (with the default set at displaying images).
• Similar to en:User:SuggestBot/Documentation/Suggestion columns wherein views per day and quality of the article are mentioned, one or both the features could enhance the value of Hovercards.

Discussion and user inputs are requested in this regard.-Diptanshu (talk) Diptanshu Das (talk) 18:14, 24 May 2014 (UTC)

Feedback

I like the concept of hovercards, but I don't like:

• that sometimes it flickers and I cannot click the link
• that it is too big, or that I cannot configure the size
• that I cannot change the text being displayed.

Regarding this last point, in an article it makes sense to display pronunciation, origin of the word, etc, but that obstructs the purpose of conveying the meaning of the concept. Maybe it would be better to be able to configure it to take Wikidata descriptions instead? They are not as detailed as articles, but they can be edited, they are short and they can be in multiple languages (for instance I could choose to display the hovercard in another language, even if the chosen article has no translation). Anyhow, I like that this is being experimented with and I hope to see more iterations of this feature. Vanished user e175adb86e72bb96a1706f7ab31b9df8 (talk) 09:41, 25 May 2014 (UTC)

Thanks for your feedback. I'll go through these one at a time.

1. This is being examined on this bug - https://bugzilla.wikimedia.org/show_bug.cgi?id=65433

2. It would be rather unwieldy if we allowed every user to configure display sizes.

3. This is actually something we have looked into. Like you mention, descriptions are high level and so may not solve the problem of helping the user understand the term in question. Also,

roughly 55% of articles have wikidata description fields and a subset of those have actual descriptions. If we did have wikidata descriptions for everything this would be help to provide primary context, perhaps in addition to the first line of the article. Vibhabamba (talk) 07:42, 27 May 2014 (UTC)

Bugs

This hovercard feature worked well until it recently started flickering when hovering over links and consequently being unable to click the link easily. Also, the font size was unnecessarily increased meaning less of a pages opening paragraph is shown than it was previously. Dogcutter (talk) 11:56, 25 May 2014 (UTC)

Dogcutter: having the same issue. I had to turn hovercards off because it was really annoying that I cannot click on the link below. Xia (talk) 08:52, 26 May 2014 (UTC)

Teemeah and Dogcutter and NBMATT and Czar and Odie5533, the patch is now live and tested. The core problem is fixed on all wikis. Thanks again for your patience and bug-reports. :) Quiddity (WMF) (talk) 22:48, 5 June 2014 (UTC)

I've been having the same (or similar) problem lately. It doesn't register the click whenever I try to follow the link before the card has a chance to display itself; instead I've had to keep the cursor hovered over the link for a second or two before it registers the click and opens the link. NBMATT (talk) 13:11, 25 May 2014 (UTC)

Had to come here to report the same—within the last few days the size of the text has increased in the hovercard (which makes it less space efficient) and I believe the hover bubble is positioned further down or in any case such that my clicks on the links don't register. So I'm turning off (!!) the feature because it is more of a hindrance than a help (but it was quite helpful up until the changes a few days ago). czar 14:06, 25 May 2014 (UTC)

This bug is discussed below in the thread "Hovercard hover placement issue." Here is a gif of the problem: http://imgur.com/sISA887 Odie5533 (talk) 21:23, 25 May 2014 (UTC)

Thank you for reporting the flickering issue. Its being investigated here - https://bugzilla.wikimedia.org/show_bug.cgi?id=65433

Regarding the type size, can you provide screenshots as to what is bothering you? We increased the type size marginally so that its easier and faster to read the first sentence of the hovercard. Vibhabamba (talk) 07:35, 27 May 2014 (UTC)

There's less of the opening paragraph shown now compared to how it was previously, despite unnecessary information such as the pronunciation and alternate names now being excluded. Shouldn't freeing up space in this way allow for more of the opening paragraph to be shown?

I'm not sure that having the type size larger than that of the actual article text is ideal; the previous text size may have been too small, but a better balance between the readability of the hovercard and the substantiveness of the information presented on it would be worth considering. Dogcutter (talk) 15:45, 3 June 2014 (UTC)

Various Ctrl+Click issues

I've already posted some of my comments in a previous thread "Hovercard hover placement issue", but got no answer, so I'm posting them again and also adding more problem reports. The idea behind this is good, the display is nice but it needs some modification to stop getting in the way of normal use of the encyclopedia.

First, hovercards shouldn't be displayed so quickly, to ensure that they are displayed because the reader wants them to, not juste because the mouse went over a link. I still have Navigation popups active (because it allows me to do more things, like fixing links to disambiguation pages) and I think that having a similar delay would be a lot better.

Other problems I have encountered are with clicking (I almost only use Ctrl+Click, so I don't know if the problems I saw happen also with simple Click) :

1) (already reported) Very often when I put my cursor over a link, I have to Ctrl+Click several times to have the link opening in an other tab in Chrome. Simply clicking where the mouse is doesn't work every time. Often, if I Ctrl+Click when the hovercard is poping up, the Ctrl+Click is lost, and the hovercard disappears and starts poping up again. Painful to use, I'm currently considering deactivating this feature.

2) (already reported) I've also seen an other situation, less frequent: sometimes, when the hovercard is completely displayed, Ctrl+Click doesn't work at all unless you move the cursor a bit. If you repeatedly do Ctrl+Click without moving the cursor, the only thing that happens is that text is selected in the hovercard: first word, then all text, then nothing, ...

3) (new report) I'm currently working on fixing ISBN errors, I'm using a page that lists all ISBN errors on frwiki [1]. I often take one line, and Ctrl+Click on all the links in that line to open the articles each in a new tab. Sometimes, when I move to a new link, the hovercard from the previous link is still displayed, and sometimes, even if I have the impression of clicking on the new link, it's the previous link that gets opened one more time instead of the new link.

[1] https://fr.wikipedia.org/wiki/Projet:Correction_syntaxique/ISBN_invalides NicoV (talk) 08:36, 27 May 2014 (UTC)

And also:

4) (new report) after Ctrl+Click, I move the cursor (the hovercard disappears), I go to the new tab, make my modification, and then close it. Then, Chrome displays again the previous page on which I did the Ctrl+Click : the hovercard reappears even if the cursor is nowhere near the link. NicoV (talk) 08:46, 27 May 2014 (UTC)

NicoV: the flickering-bug patch is now live and tested. The core problem is fixed on all wikis. Thanks again for your patience.

Regarding the other issues (incl. timing, wrong-link opening, hovercard-reappearing when not near link), I'll [file or poke] bugs and developers. Thanks for all the details, tis appreciated. Quiddity (WMF) (talk) 22:46, 5 June 2014 (UTC)

Quiddity (WMF): thanks for the heads up. It's a lot better now, including wrong link opening.

The hovercard reappearing is still there. I also noticed that if you go to an other tab and come back to the original tab, the hovercard also reappears, and you can do it continuously (go to an other tab, come back => hovercard appears, move the mouse to it to make it disappear, start again from the beginning) NicoV (talk) 07:16, 6 June 2014 (UTC)

NicoV: In case you wish to follow the bugs, see bugzilla:66221 (flicker on click), bugzilla:66240 (flicker edge-case), bugzilla:64234 (timing. Increasing the default will probably solve your issue with trying to rapidly ctrl-click many items in a vertical list. Also, there might eventually be a "disable Hovercards" option built-in, as Reference Tooltips has.), bugzilla:66261 (ctrl-click then reappear), bugzilla:66262 (triangle and border area not clickable). I think that covers them all. Let me know if I missed anything. Quiddity (WMF) (talk) 16:07, 6 June 2014 (UTC)

Hovercards interfering with clicks

In the last few days, the hovercards have started to interfere with my trying to click on links. What I believe is happening is that the hovercard appears too close to the mouse cursor location, and catches the clicks instead of the links themselves. This is on Firefox 30 beta on Linux. The Anome (talk) 10:10, 27 May 2014 (UTC)

I have the same problem, I need to click a link several times because of the hovercard. Kohelet (talk) 11:51, 27 May 2014 (UTC)

I have this problem too in Google Chrome. Hovercards begin in the middle of the words, not above them. Hynas (talk) 13:56, 27 May 2014 (UTC)

We are aware of the firefox issue. If this is seen on chrome, can you please provide a screenshot? That would tremendously help us fix it. Vibhabamba (talk) 16:44, 27 May 2014 (UTC)

Yeah, flickering and unable to click on links. Disabling for now. Robvanvee (talk) 17:16, 27 May 2014 (UTC)

Robvanvee: can you help us with which browser this is happening on? Vibhabamba (talk) 17:58, 27 May 2014 (UTC)

Vibhabamba: I think i understand what is causing the unable to click issue. I see the same with Safari.

I can clearly reproduce it by entering the area of the link from 'below' the link.

I suspect it is caused because the offset of the card is calculated in the done of the request. The request is fired 50ms after entering the link. The render however occurs after settling on the link (waits for !scroll) and then it waits another 150ms. Thus the card is rendered at an 'old' position. —TheDJ (Not WMF) (talk • contribs) 21:28, 27 May 2014 (UTC)

Vibhabamba: I think I got the same problem. It's oscillating/flickering and almost unclickable. Almost means: clicking about some ten times is most of the time enough to have a reasonable chance to hit "accidently" the right moment of oscillating's phase, when link is yet sensitive to click. Annoying. Until a few days ago it was working. Therefore I disabled Hovercards for now.

Firefox 29.0.1 Pemu (talk) 10:07, 28 May 2014 (UTC)

Vibhabamba: Firefox 29.0.1 Robvanvee (talk) 11:24, 28 May 2014 (UTC)

I think (almost) everyone has this problem. And that's the reason I disabled the feature, though I liked it. And I have to hover the link from the top and not from the bottom like I'm used. Eurofan2005 (talk) 01:54, 28 May 2014 (UTC)

it is a good idea, but has some bugs when it passes over a link and it was difficult to select this link thereafter. But I think if this mod is improved it would probably be very much appreciated; and I'll probably one of the first to install it.

(Sorry for the translation but I have a little difficulty with English) Italianfan-67 (talk) 07:00, 28 May 2014 (UTC)

I'm going to disable hovercards for now -- hovercards are great, but nearly unclickable links make Wikipedia unusable for me. Hopefully, this bug will be fixed soon, and I can go back to using them.

By the way, this is how to do a beta: I really appreciate the devs choosing to work out the bugs in beta, rather than rushing to deployment. The Anome (talk) 20:28, 28 May 2014 (UTC)

Today I have find that the hovercards flickers all time and I cannot click the link. This is on Firefox 3.0 on Linux. I'm going to disable hovercards for now too. Fugi-bis (talk) 19:13, 29 May 2014 (UTC)

We have a patch that is getting merged today that should fix this issue. Vibhabamba (talk) 22:37, 29 May 2014 (UTC)

Would be great! Looking forward that the problem will be solved. Great idea, these cards... Minihaa (talk) 13:28, 30 May 2014 (UTC)

Could you please include it in the tech news when this is fixed? That would be the trigger for me to enable it again. Multichill (talk) 12:26, 31 May 2014 (UTC)

<nowiki>Regarding this specific problem, I sincerely appreciate the time & energy so many of you have spent in reporting this bug. We are testing the patch for a swat deployment this tuesday. We will be sure to post this on tech news. Also once this bug is fixed we plan to post on Wikitech L and Village pump so there is greater awareness of the feature. Vibhabamba (talk) 20:09, 31 May 2014 (UTC)

The same problem in Opera.

MAybe hovercards should be disabled on special:recentchanges by default... JAn Dudík (talk) 16:26, 25 June 2014 (UTC)

Flickering bug - fixed soon

Just a quick note, to let everyone know that a patch for the flickering Hovercards bug has been written and tested, and is just awaiting review. It will be pushed live as soon as possible. I'll ping everyone who has commented on it below, once the patch is in place. Thanks, and sorry for the wait. Quiddity (WMF) (talk) 23:37, 29 May 2014 (UTC)

Add some delay to fade out of hovercards

This may address some issues regarding clicking of links as noted by other users. If the user is unable to click on the linked article, the hovercard is an alternative way for users to click to go to the linked article.

However, hovercards appear depending on where the mouse cursor hovers over the links. If the user wants to hover the mouse cursor over the hovercard, the hovercard may disappear if the cursor is no longer hovering on the context objects - in this case the hovered link and the hovercard.

Visualization of this problem: http://i.imgur.com/Njv2FPr.gif

This may be addressed using the solution as follows:

http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown Dashed (talk) 12:53, 31 May 2014 (UTC)

Rendering of parenthetical text in hovercards

Hovercards don't appear to render text in brackets from the target page. For instance, hovercards concerning the Wikipedia page for w:RAF Hospital Wegberg state that it is "commonly abbreviated to RAFWegberg", while the page itself states that it is "commonly abbreviated RAF(H) Wegberg"; both the '(H)' and the space after it appear to be missed by the hovercard. Sasuke Sarutobi (talk) 12:56, 31 May 2014 (UTC)

This is a good point. Typically parenthesis carry complicated IPA's or scripts from other languages that hinder a quick read of the hovercard. Hence we have elected to remove parenthetical content. Making a note of this case for investigation. Thank you for pointing this out. Vibhabamba (talk) 06:26, 1 June 2014 (UTC)

Vibhabamba: Thank you for your answer. My first thought is that are IPAs and scripts typically not in templates? I've not worked on articles featuring these for a while, so I don't know what the general trend is these days. Secondly, being a language learner and able to (approximately) read IPA and a few other scripts, I find such content useful to have. I've not read especially many foreign-language subjects through hovercards since enabling the feature, but would it be possible for it to be optionally enabled (i.e. disabled by default).

With regards to the missing space as well; I'm guessing that in addition to the script removing parenthetical content, it removes the first found instance of a space in order that remaining text is rendered correctly (since there would be a space either side of the parentheses). I know that this is an unusual example in that the parentheses are only accompanied by one space instead of two, but might it be worth changing it so that it removes the space immediately before the parentheses? Sasuke Sarutobi (talk) 10:48, 1 June 2014 (UTC)

Sasuke Sarutobi: I agree that it is a somewhat crude method to remove these right now. It's prone to failure (and also hides birth/death dates, that are usually enclosed in parenthesis).

The templates are not really relevant here, since hovercards deals with rendered output, not wikitext. I think we should reevaluate how to achieve this goal. —TheDJ (Not WMF) (talk • contribs) 09:09, 2 June 2014 (UTC)

As a footnote, I've also noticed square-bracketed IPA script is displayed in hovercards; e.g. w:Audemars. I thought that might be of interest. Sasuke Sarutobi (talk) 12:18, 1 June 2014 (UTC)

Now filed as phab:T91344. Please edit or add details, there. Thanks. Quiddity (WMF) (talk) 01:23, 3 March 2015 (UTC)

Use of pictures

The feature displays the first picture on a page, even when this picture is some way down the article, and illustrating something else; for instance, the hovercard for charity activist w:Stephen Sutton displays (rather confusingly) a picture of w:Jason Manford, one of Sutton's most active celebrity supporters. This is because Manford's picture is the first (and currently only) on the page. Ideally, the solution to this would be the inclusion of a picture of Sutton further up the article, but in the current absence of such, a confusing image is displayed. As cases such as this may take time in acquiring suitable pictures of the primary topic, especially in cases where fair use or free use images may be harder to source, it may be worth amending the feature to take such into account.

Might the feature therefore perhaps be restricted to pictures in the lede (or also first section) of an article? Sasuke Sarutobi (talk) 18:22, 31 May 2014 (UTC)

This is a really good point, and in some cases it hurts continuity when a user clicks on the hovercards and lands on the article to see a completely different lead image. This may need to be filed as a feature request with the Page Images extension that Hovercards uses. Thank you for commenting on this. Vibhabamba (talk) 20:12, 31 May 2014 (UTC)

An ideal solution might be to allow manually specifying those page images (optionally). I'm not sure if it's in scope of the PageImages extension or Hovercards, I would suggest creating a special markup to indicate the absence of images representative of the topic (such as __NO_PAGEIMAGES__), and a markup to specify an image to be the primary one among multiple images on the page. whym (talk) 01:18, 1 June 2014 (UTC)

Whym: WikiData is sort of doing that already (registering a primary image reflecting a topic). Might be interesting to use that at some point (but will probably take a while). —TheDJ (Not WMF) (talk • contribs) 08:59, 2 June 2014 (UTC)

The latter suggestion is interesting, would you consider filing a bug/extension with pages images suggesting this idea? Thanks! Vibhabamba (talk) 06:22, 1 June 2014 (UTC)

Vibhabamba, TheDJ: I have filed bug 66077. whym (talk) 14:45, 3 June 2014 (UTC)

Thank you, I'll follow up with Max Semnik, who has the most context about page images. Vibhabamba (talk) 17:54, 3 June 2014 (UTC)

Sasuke Sarutobi has a good point: only use pictures in the first section of the article.

However, there is another problem with the use of pictures:

For some pages with infoboxes in the first section, e.g. The Linux Foundation, the Hovercards feature seems to ignore the image in the infobox, which is the logo of The Linux Foundation i.e. the best image for representing the article. Instead, the hovercard shows an infographic representation of the CUPS printing system which represents Unix in general instead of Linux specifically, and only hardly so. The same problem applies to ARM architecture which again displays an infographic; and Canonical Ltd. which displays a screenshot of the Ubuntu operating system(the company's main product) instead of the company's logo located in the infobox at the top of the article.

However the same problem doesn't seem to apply to Hydrochloric acid, Sulfuric acid and Lettuce.

Weirdly enough though, for Smartphone, the image displayed is a BlackBerry, which is the third image in the page, and not the first. Busukxuan (talk) 20:48, 9 June 2014 (UTC)

Busukxuan: Looking into these:

• The Linux Foundation: Unseen image is a png in "Template:Infobox" infobox, displayed image is a thumb svg file;
• ARM architecture: Unseen image is an svg in "Template:Infobox", displayed image is a thumbnail svg image;
• Canonical Ltd.: Unseen image is an svg in "Template:Infobox", displayed image is a thumb png file;
• Hydrochloric acid: Displayed image in "Template:Chembox";
• Sulfuric acid: Displayed image in "Template:Chembox";
• Lettuce: Displayed image in "Template:Taxobox";
• Smartphone: Unseen images are png files, displayed image is a jpeg.

So it seems that there is something in the infobox template that is preventing pictures being found, that isn't in the other boxes (e.g. Chembox and Taxobox). Likewise, it looks like jpegs are picked up over pngs. Sasuke Sarutobi (talk) 23:52, 24 June 2014 (UTC)