Thank you for testing the Hovercards Beta Feature!
You can use this thread to write down anything you would change about Hovercards. If you'd prefer to start your own thread, please feel free to do so.
Topic on Talk:Page Previews/Flow
It might be good to have link syntax which prohibits hovercards on certain namespaces or targets, or even on a link by link basis.
Jaredzimmerman (WMF): I agree, I think Talk pages should be disabled for now as they don't work particularly well with Hovercards, and there's no easy way of making them work as a Wikipedia article would.
Nicereddy, yes, you're right there are lots of page types on the roadmap, but we might want to invest some time in explicitly blacklisting types that don't work yet, since its not an idea experience in the mean time.
Jaredzimmerman (WMF): For link by link, I would suggest reusing what navpopups use. We don't need two classnames where one will do. For non-link by link approaches, I would say that it should simply not present popups for what it cannot understand.
TheDJ, good call I'll make sure this gets passed on to Prateek.
When hovering over an interwiki link, moving the mouse outside of the card by just a few pixels causes the card to disappear instantaneously. This is horribly frustrating to me, as I'll be trying to read a card when it disappears. This feels like a punishment for a simple, common mistake. I would really like for the card to disappear after a 1-second delay, as this feels more fair to myself and likely will to most users. In that case, it feels more like it was my own fault, rather than the fault of the interface.
A good example of this, off the top of my head, is when the user's cursor is covering an image they're viewing from within a Hovercard. Instinctively, you'd move the cursor away from the image in order to see it, but oftentimes this closes the card. To me, it's a rather frustrating behavior.
Nicereddy, this is an important thing to get right, balancing, it feeling quick, responsive and "out of the way" with not feeling too finicky and and disappearing when you don't want it to.
Jaredzimmerman (WMF): the traditional navpopups has many 'hidden' capabilities on this front. You can configure the timing (both in an out), but you can also set it to only work with a meta key pressed. It will never hide as long as your mouse is inside the hover (but gives you time to move your mouse there before it disappears). Even less known, shift drag to reposition anywhere you want it :D
TheDJ: Ah! too many settings, if the biggest target is readers (logged out) we probably want to stay away from too many settings. But figuring out the best defaults and using those seems like a reasonable middle ground
Jaredzimmerman (WMF): I don't think many people know about these settings, but if you know what JS blob to use, you can override it to however you desire.
Nicereddy: I understand your frustration, it has happened to be a couple of times too. Its currently set to 100ms and becomes difficult if your pointer speed is slower than average (OS setting). We are however collecting data to see how many times it got accidentally closed (open for a very short time) and will fine tune that number accordingly.
Nicereddy: We have talked about using a clean right rail to display popups for important links. This would address the problem you raise but also relies on major page layout changes which you can help us with =]
If the link is near the bottom of the screen, the card is partially hidden. Either we need to scroll the page up so that the card is visible or flip the card so that it shows above the link.
Santhosh.thottingal: We have some initial logic to keep the card from going off the right edge (or less likely left edge) of the screen, but not yet moved to bottom of the screen, its on the roadmap however.
Santhosh.thottingal: Thank you for reporting this. This is really a bug and we should fix it. We want to prevent page scroll because it can be jarring for the reader.
When the image that the hovercard selects for display is smaller than the size that the hovercard has allotted to display that image, the hovercard's solution is to stretch the image out. As the screenshot below shows, this doesn't look particularly good.
I propose that if an image's native resolution is smaller than that allotted area in the hoverbox, the image should be displayed in its original resolution. In this scenario, the image would be horizontally centered in the area the hoverbox allots for images, and the extra vertical height would be trimmed out. I've mocked this up in the right-hand box in the collage below.
Sven Manguard, I think this is a bug but I'll let Prateek confirm
Sven Manguard: Thanks for your suggestion! I've added the bug using your screenshot and have assigned it to myself.
It would be nice if when I hovered over a word, the word appeared bold or different than the rest of the text shown in the hovercard, to indicate this is the preview of this word/page. Thanks! Good job guys!
Jooojay: That's a good idea, if the text is present already then it wouldn't actually need to be duplicated again but would still draw your eye to it.
Jaredzimmerman (WMF), Vibhabamba: Liking the bolder titles! Thanks
I would like a bit more heavy border. Any thoughts on that?
Wiki-uk: We're missing the hard drop shadow from the original design, that should make it more visible against the background text. Let us know if it helps once it gets integrated.