This page used the Structured Discussions extension to give structured discussions. It has since been converted to wikitext, so the content and history here are only an approximation of what was actually displayed at the time these comments were made.
The design is very nice and minimal! I'm sure you'll get heat for that from some users, but I think this is far more useful to the silent majority - that being users - than the previous iteration. It's quite obvious a lot of thought has gone into it, and for that I appreciate it significantly. Kudos to everyone involved! Nicereddy (talk) 02:31, 21 March 2014 (UTC)Reply
Nicereddy, we've thought about this, and may investigate a slightly alternate appearance for logged in vs logged out users or allowing a preference for more advanced actions to be opted-into if a user desires. Jaredzimmerman (WMF) (talk) 17:20, 21 March 2014 (UTC)Reply
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) (talk) 17:18, 21 March 2014 (UTC)Reply
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 (Not WMF) (talk • contribs) 10:31, 21 March 2014 (UTC)Reply
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 (talk) 02:40, 21 March 2014 (UTC)Reply
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 (Not WMF) (talk • contribs) 19:42, 21 March 2014 (UTC)Reply
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) (talk) 23:06, 21 March 2014 (UTC)Reply
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. Prtksxna (talk) 01:19, 22 March 2014 (UTC)Reply
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 =] Vibhabamba (talk) 08:16, 22 March 2014 (UTC)Reply
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 (talk) 06:57, 21 March 2014 (UTC)Reply
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.
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! Joojay (talk) 01:12, 27 March 2014 (UTC)Reply
This is another feature that when enabled by default would have significant accessiblity consequences due to floating/modal windows. This needs to be taken into account in any sort of deploy strategy. —TheDJ (Not WMF) (talk • contribs) 10:19, 21 March 2014 (UTC)Reply
Jaredzimmerman (WMF): I think TheDJ's point here is that, for example, the accessibility provided by screen readers may not interact very well with Hovercards popping up. Best case, the screen reader doesn't read the text on the card. Worst case, the card totally breaks the screen reader. We need to be considerate of this in future deployments, but we're fine for now due to the opt-in nature of the feature.
DGarry (WMF): Exactly. what happens if the user has a mouse that happens to hover a link (he would have no clue about this). The card is read if he is at the end of the page, and the links inside it would be interaction points for him. Best is usually to actually try this scenario (chromevox or voiceover) and listen to what is being read to you (but remember that screen readers are anything but consistent).
It's a bit of a complicated scenario as well. Normally if the popup is closed, you'd want the user to be able to open it using keyboard commands, but since the target is already a link, that will be difficult.
Some useful things here may be.
role=dialog could be used (but you are out of dom order, so slightly confusing to the user)
you need to handle transfer of keyboard focus if the user enters and leaves the dialog
Explain the dialog with an aria-label [your mouse is hovering a link giving you a preview of the target's content. You can use keyboard key 'p' on any focused link to activate a preview).
On the content, you could put aria-live (would start to read it after short period of inactivity).
Don't use dialog, but aria-haspopup and aria-expanded (but how do you explain how to open the popup, without clicking the link?)
An alternative is to simply disable the popups altogether for disabled users, by putting aria-hidden on the entire block. It's not nice to hide functionality from users who don't use a mouse, but it might be an acceptable stopgap method.
TheDJ: I believe if we can work out the popup into the tab-index order for screenreaders, (Obviously, I need to investigate it more thoroughly) this would be great for accessibility. Going off to a whole other page just to get context isn't the best thing for a user with a visual impairment. Vibhabamba (talk) 08:08, 22 March 2014 (UTC)Reply
TheDJ: To my surprise, there was a whole section on dialog/tooltips in the Aria Practices document. I feel this is more of a tooltip than a dialog box. There are no controls within the Hovercard except a link to open the relevant page. This is the same as the link that the user has given focus to, thus we don't need bring focus to the Hovercard–at least for now (see open questions).
Jdlrobson: There is no patch as of now. I am trying to decide where the problem lies, whether its Extension:TextExtracts not returning anything or something wrong with Extension:Popups. If its in TextExtracts should we not show the Hovercard at all if its empty? What should we do if it returns an image but no text? Prtksxna (talk) 02:50, 24 March 2014 (UTC)Reply
IP User Hovercards - If you look around this Talk page, probably near the top, there are a few comments by anonymous users, represented by their IPs. My issue is that every user has a hover card, except for IP users. Obviously, it'd be unrealistic for them to have a proper hover card as they lack a user page. Despite this, I would at least like a card for consistency's sake. Perhaps just a card saying "This user isn't logged in or doesn't have a Wikipedia account." or something similar.
Nicereddy: IP addresses link to [Special:Contributions/IP] (in both Flow and in normal signatures and in History/RC/etc pages), hence this is expected behaviour.
However, as you suggest, a custom card for that type of link might be interesting. (?) Long-term feature enhancement though. –Quiddity (talk) 23:39, 27 March 2014 (UTC)Reply
Copying some feedback from the now-archived Talk page
Latest comment: 11 years ago2 comments2 people in discussion
I suppose I should note that these were all written before the actual implementation of the Beta Feature, so they may not reflect my current opinions. I'm just too lazy to update them right now :P
I've looked through the slides on this feature and they really excite me! I use the Navigation Popup tool on the English Wikipedia and this seems to be an improvement over it in just about every way!
Here are my concerns/feedback based on the current design:
General Hovercard Feedback (Not specific to any certain type of card):
No article title in the Hovercard - Unlike the aforementioned Navigation Popup tool, the title of the article isn't available in hovercards. While this makes the card cleaner, I think it's a feature a lot of Wikipedians would like to see. The card is brought up by scrolling over an interwiki link to the article, but the links aren't always representative of the article they're connected with. I use Navigation Popups to understand more ambiguous interwiki links fairly frequently, so this'd be a nice addition.
Card disappearance - As explained in File:NavigationPopups V1.pdf, when moving the mouse away from the pop-up it will disappear. The slide implies that this would be immediate, which would lead to a bad user experience. "Move your mouse just a little bit too far? Boom, gone." The Navigation Popup tool allows the popup to stay for an extra few seconds (2 seconds, I think?), which doesn't punish the user for minor error whilst also not frustrating users who didn't mean to hover over the interwiki link. Perhaps the slide is just unclear, but if you were intending to make the disappearance instantaneous, I'd ask that you reconsider.
Article Hovercards:
Color of "Watchlist" icon and "Last Edited" text may be confused with that of the "Thank" iconography - Based on the "Last Edited" text at the bottom of the card shown in File:NavPopups Portrait.png, the green used for the Watchlist and text next to it are the same (or very similar) as the color used for the "Thank" dialogs. It also contrasts with the "Watchlist" button in the toolbar of every article, which is a shade of blue (in Vector, at least). I think making it a lighter green may be a good idea? The heart that is oftentimes associated with Thanks or Likes in UI design is similar to the star icon, so adding the same color could cause further confusion.
User Hovercards:
Emphasizing length of membership and number of edits for users - As shown in File:NavigationPopups Usernames-10.png, the User-specific Hovercards show how many days the user has been contributing to Wikipedia as well as how many edits they've contributed. I would think the most important parts of that are the number of days and number of edits, so emphasis should be given to them, e.g. "Nicereddy has been contributing for 666 days and has contributed 1337 edits". Whether it should be bolded or italicized can be decided by the development team, but I think those parts of the card should be very easy to find without just listing the days/edits as statistics (as some users will likely suggest).
Should "Edit" be capitalized? - Again with regards to File:NavigationPopups Usernames-10.png, "Edits" is capitalized in the user statistics, but not in the Most Recent Thanks section. I don't personally believe it should be capitalized, but if it's going to be I figured I'd at least point out the inconsistency.
In User cards, the different sections aren't separated by anything but white space. While I can understand the use of white space, I feel like having a horizontal divisor line would make the separation between sections more obvious and therefore make the card more readable by the user. If not a horizontal divisor, perhaps differences in color, font weight, etc. The italics for the first section help, but the latter two sections are the same weight, color, and size.
Anyway, that's all I have for now. Hopefully it's helpful, I'm really looking forward to using this in place of Navigation Popups! Nicereddy (talk) 01:51, 21 March 2014 (UTC)Reply
No article title in the Hovercard — I think if the link = article title, then a title would be an unnecessary duplication, but a good thing to think about
Color of… — We are working hard to have consistency of colors with mediawiki.ui having subtly different colors or variations of green with no clear reason why per context is something we'd like to avoid, that said we can think about rational for why green at all for this particular use, other than consistency with the mobile last edited bar (experimental)
User card — noted, alternate card types are still in development…
Latest comment: 11 years ago4 comments3 people in discussion
As having worked on navpops, a few tips:
When having this as beta, it might be handy if the users of navpopups don't clash with this. Ideally detect when users have navpopups running, and then ask the user to switch between the two (store pref in localStorage). Hovercards can disable navpopups simply by calling the global function disablePopups() (yes, navpopups precedes function scoping modules).
Recognize the class "nopopups", which denotes areas of the page where popups should not be presented. There are a number of links that might be troublesome and this is the way navpopups blocks them, might as well stay compatible with that. (popups does this by putting a "inNopopupSpan" property on any links in these .nopopups blocks, which is checked by the popups code before just presenting the popup.
Popups can be annoying... Sometimes i just don't want them on a page filled with links that i'm trying to read. popups has the menu entry: "disable popups" which removes all popups from that page for the duration of the page
The delay to dismiss the popup, after moving away from the popup, is one of the best parts of popups.
Remember that we have lots of 'unclean' links. red, oldid and a lot of other forms. Links in history, links in edit summaries, links to categories, css, js, lua, file upload urls etc. —TheDJ (Not WMF) (talk • contribs) 10:17, 21 March 2014 (UTC)Reply
nice work, I don't have all these extensions installed to test this, but as far as I can see they can only be improvements.
The way navpopups does it is as following: After loading the page, it looks for $('.nopups a') then it sets the property inNopopupSpan on each of this a's. Inside the 'open popup' it checks for presence of this property (i'd use data this time) and depending on it does not actually show the popup. An example that uses this is for instance en:Template:Pp-meta
It doesn't have to be very obvious, but something like it should be there. if you are scrolling a page, or need to do a few copy pastes, the popups can quickly becoming an annoyance —TheDJ (Not WMF) (talk • contribs) 13:03, 23 March 2014 (UTC)Reply
TheDJ: 1 & 2 are excellent points. Thank you for positive feedback in bullet 4 - Mad Props to prateek for this =] Hearing objective positive feedback from the community truly validates our work.
Regarding bullet 3 - Excellent that you bring this up. I too am concerned about this side effect and would like to understand this better. In the process of scrolling your mouse accidentally lands on linked words which trigger popups - yes?
Regarding bullet 5 - Thank you for bringing this up. Do you have any recommendations as to how the popup should behave for a red link? Vibhabamba (talk) 07:41, 22 March 2014 (UTC)Reply
What image should be used on user profile hovercards?
Latest comment: 11 years ago9 comments6 people in discussion
Hey there Vibhabamba, Prtksxna, and DGarry (WMF). I was reading this, and it looks exciting. I do have one concern though. In the "Target object is a user name" section, it says that the plan is to use the last image uploaded by the user for the image in the hovercard. I'm not sure that's a good idea. There are three reasons for this:
Users that work with files upload new images regularly, meaning that if people form a connection between a particular image and a particular user, this will be disrupted each time that the user uploads a new image. Additionally, if people upload on multiple sites, they will have different images in their hovercard on each site.
There is no accounting (either in this section or in the Hovercards plan as a whole) for the license of the image. Almost all of my uploads to English Wikipedia are edits to non-free files, as my freely licensed works go on Commons. Having non-free images appear in hovercards (for articles or for users, but especially the latter) strikes me as being against the spirit of our policies on minimizing the use of non-free images.
Users may upload images out of an encyclopedic duty (visual coverage for topics), but still personally disagree with the message that is displayed in the image. Everything from images with nationalistic or religious significance, corporate and institutional logos, and images of historic tragedies and wrongs get uploaded by users looking to improve projects' coverage of an issue, and I doubt that many users would want some of those images splashed above their names in hovercards.
I have a few recommendations for ways to get around this:
We could set the hovercards so that they only look at the most recent Commons upload. While this will not solve points 1 or 3, it will solve point 2.
We could use the user's signature instead of an image. This is an existing form of visual identity, and one that is both controlled directly by the user and generally stable over the long term.
We could hold off on using images in hovercards for users at all, and then put them in later, once the avatar/profile system is deployed. This will allow users to have a single image of their own choosing that appears across all projects.
Sven Manguard: I'm now imagining someone uploading an image related to, say, Nazi Germany, then being horrified when they hover over their own username with Hovercards enabled. Ouch. ;-)
Unfortunately, setting Hovercards to use Commons uploads is blocked on the SUL finalisation being performed. Similarly, using the user's signature will become blocked when Flow is deployed more widely, as Flow may or may not support signatures in the form that they are supported currently.
What do you think about taking the first image from the person's user page? WP:NFCC, WP:USER, and related policies preclude the possibility of non-free images on user pages, so that seems to be the easiest way to get a free image associated with the user. This would probably work on User:DGarry (WMF). However, on the English Wikipedia, on User:Deskana (my volunteer account) it would likely return an image of the adminship mop. Suboptimal, perhaps, but maybe there's only a limited amount that Hovercards can do!
Stream of consciousness unrelated to your point: Perhaps Hovercards indicating the user rights a user has would be cool, as users often complain they cannot sufficiently differentiate between admins and non-admins. On the other hand, perhaps it wouldn't, because it may lead to arguments that we're encouraging hat collection. Worth considering.
DGarry (WMF): No need to thank me, it was my pleasure.
Using the first image on your user page seems like it would work. Although this would open up a new avenue for personal attack/defamation vandalism, that is something that can easily be countered. It might be possible, for example, to set up an edit filter to detect when a user alters or adds a file to another user's user page. If not, it's certainly a type of edit that we can train Huggle and the other anti-vandalism tools to recognize and alert vandalism fighters to. Other than that, I don't see any potential downsides to your suggestion.
As to your second point, I was actually thinking of proposing that myself; I just hadn't worked out all the details yet. I think that there is definitely a value to displaying certain user rights, but little value to displaying others. Essentially, if an editor without a certain user right would have cause to search for someone with that user right and ask them for assistance, there is a value to displaying that user right in the hovercard.
Applying this standard to English Wikipedia:
Administrators, file movers, account creators, template editors, and all four Education Program user rights would make sense to include. The first four because they have the technical ability to perform tasks that other users might need to find someone to do for them, and the Education Program ones because students should be able to easily find people that have knowledge of the program. If we can display global rights on local project hovercards, steward and global sysop also make sense.
Bureaucrats, checkusers, oversighters, and edit filter managers would also fit the standard of having the technical ability to perform tasks that other users might need done. The tasks that they can do, however, are all very behind the scenes, and an editor experienced enough to need those tasks done would know how to find out who has those rights. The last one, edit filter managers, is one that I would definitely not display, because the projects are better off if only experienced users know that we use edit filters as part of our vandalism fighting arsenal.
There are also some non-user rights that would make sense to display, if we can find a technical method of pulling it off. OTRS volunteer comes to mind (it's a user group on Commons but not enWiki), as does Teahouse host and Wikimedia Foundation staff member. Bot approval group member is, like 'crats, CUs, OSes, and EFMs, something that only experienced users would need to find, but it's also an option.
Finally, I definitely think that it would be a huge plus for the hovercards of bots to say something along the lines of "This account is an automated program. Please contact [bot operator] for questions, concerns, or to file a bug report".
Sorry for how long this response is, but I wanted to give you as complete a picture of my thoughts as possible. I'm really excited about hovercards, and am glad to have the opportunity to help.
We are currently using the Extension:PageImages to get the first relevant image from the page in question. We aren't getting the last uploaded image as of now. Also, I am working on the code so that we can load different things based on the kind of page (this isn't ready yet). I'll be sure to look into all the possible data points you've mentioned. Thanks again. Prtksxna (talk) 01:34, 22 March 2014 (UTC)Reply
Sven Manguard: Completely agree with you. Ideally user images should be representative of the users themselves and should not keep changing.
The last uploaded images to commons is a workaround because for better or worse the community has been very averse to adding their own visual identity - a photo or something that more permanently represents them. What do you think about this?
Your recommendations in bullets 2 and 3 are both good ones. As agree within the team, our most immediate focus is to get more readers to discover and use this feature. Once we have substantial volume and feedback we will expand this to other objects with proper detail such as - User names, wiktionary items etc. Vibhabamba (talk) 08:05, 22 March 2014 (UTC)Reply
Vibhabamba: If there's an aversion to visual identity, that ought to be diagnosed as its own problem. I suspect that much of the problem is mostly that there is currently no "official", preference-supported setting allowing visual identity to be specified. There's no indication anywhere in the site design that visual identity is desirable in any way, so where's the surprise that people don't tend to seek it out?
Using the last uploaded picture risks the perception of the software forcing a visual identity upon people, while not allowing those who have such an identity the control to select it. I use a section of The Garden of Earthly Delights as a consistent, pseudonymous visual identity, and I would be quite upset if that identity were replaced by my latest upload.
Here's another problem: what if the user's latest upload is a fair-use image? Fair-use images shouldn't be used except as relevant article content. Most, if not all, of my uploads on English Wikipedia are fair-use, and ideally the same would be the case for most enwiki users, since freely-licensed images ought to be uploaded to Commons. Other concerns in the same vein (what if the user's last upload is "offensive", and they'd not want it representing them?) follow similar patterns, and most could be circumvented by offering choice to users.
Users should have complete control over their identities. I cannot stress this enough. I completely support efforts that encourage visual identity, but I can't approve of a design that would force it upon people. {{Nihiltres|talk|edits}}21:02, 24 March 2014 (UTC)Reply
One additional concern that I had since then:
What if the last file a user uploaded is not an image but an audio clip, video clip, or PDF? It looks like you might be supporting audio (I'm basing that off of the Wiktionary mock up), but I haven't seen video or text documents addressed.
Just a thought. Keep up the good work, and I look forward to hearing your thoughts.
Jaredzimmerman (WMF): My personal opinion, and one that the internet seems to share, is that autoplay is almost never a good idea. For people with bad connections or data plan limits, videos are a luxury best avoided. For everyone else, unexpected audio (and if the video is large enough, unexpected bandwidth constriction) is an annoyance. If hovercards does allow for video, I would definitely make it click to play.
As for how to handle video controls, I think that the system we use when videos are imbedded into articles would work. The video starts when the user clicks an obvious play button superimposed over the video, and the video has a minimal control bar that disappears if you move the mouse away. Consistency in control schemes across the website is a good thing, and reusing an existing system saves time for the hovercards development team. Sven Manguard (talk) 02:47, 22 March 2014 (UTC)Reply
Latest comment: 11 years ago7 comments5 people in discussion
Suppose that I am in the article on Leonardo da Vinci and I hover over the link to Mona Lisa. A hovercard pops up and has a picture of the Mona Lisa on the top half of the card and a short blurb from the article on the bottom half (or left side and right side).
When I click on the picture of the painting, what happens? There seems to be five valid possibilities:
Clicking on the picture takes me to the article
Clicking on the picture takes me to the file namespace page for the picture
Clicking on the picture brings up the media viewer pop-out window that I'd get if I clicked the image inside of an article.
Clicking on the image closes the hovercard. (I feel that this would make sense only if clicking anywhere except for "Read more" closed the hovercard).
Clicking on the image does nothing.
I'm not sure what I feel the "right" answer is. While I'm against superimposing a magnifying glass or other icon over an image when it's inside of an article (because you never know what you're covering up), it seems like it might be a good idea inside of the hovercard. Clicking an expand icon would open up the media viewer pop-out window for the image, while clicking on the image itself might do something else.
There are pros and cons to each option. I'd be happy to speak with you about my thoughts on those (as someone that's spent a long time working in and with files and the file namespace). Let me know if you're interested.
Sven Manguard, glad you're asking these questions! We're trying to decide now whether there should be actions inside the hover cards at all… one idea is to keep it simple and say there are no action inside the card, e.g. the card is not a choice and the target is the same as the link you're hovering over.
The other (possibly equally valid) idea is that there should be multiple targets inside the card similar to the current navigation popups, I think these are two very different use cases that target different user groups, many things to think about… Jaredzimmerman (WMF) (talk) 23:03, 21 March 2014 (UTC)Reply
Sven Manguard: Thank you so much for reading the project page, trying the feature and for spending time in writing these responses.
'Read more' was in the initial mocks but was deliberately eliminated for the following reasons
1. This feature is reader focussed and will not carry any actions in the near future. The entire popup could serve as a giant target instead of just the 'Read more' text since no other actions had to be accommodated.
2. Larger targets are generally better for usability especially in modal contexts (Larger targets are better and faster for all audiences) (ref - https://en.wikipedia.org/wiki/Fitts's_law)
3. We want interactions with this modal to be quick, so a user doesn't have to stop and think about how to interact with it.
Vibhabamba: I think it should be kept as a singular actionable item, as you suggest and as it's currently implemented. To me personally, linking to the article as it does now seems like the obvious action caused by doing so. The image is representative of the article, and would be expected to link to the article it's representing.
1. This gadget is optimized for readers - single target, no actions.
2. The current popups are heavy with editor actions and feel like they are designed for editors. We didn't have much usage data on the actions themselves so there wasn't a data informed way of simplifying them. Vibhabamba (talk) 05:55, 23 March 2014 (UTC)Reply
As one of navpopups former maintainers, I can tell you, better start over... Although I've been considering using part of hover cards and migrating it back into navpopups. Especially where it comes to the parser and renderer of navpopups. —TheDJ (Not WMF) (talk • contribs) 16:23, 22 March 2014 (UTC)Reply
Base, TheDJ is right, it didn't make sense to start there, we reached out to Yair, the original author(s?) of Navigation popups and he contributed code to the beta feature as well. Depending on how the Beta Feature goes Dan the PM and I will make a call as to whether Hovercards will be an option that sits next to Navigation Popups or replaces it. Jaredzimmerman (WMF) (talk) 02:47, 23 March 2014 (UTC)Reply
Jaredzimmerman (WMF): Actually, the original pop ups was written by User:Lupin. Some parts of it (like InstaView the parser and renderer) are by User:Pilaf and are from 2003 and earlier. It's actually a miracle that it still works as well as it does, considering the thousands of changes that have been applied across the board. —TheDJ (Not WMF) (talk • contribs) 12:52, 23 March 2014 (UTC)Reply
Latest comment: 11 years ago4 comments2 people in discussion
After reading the project page and getting through the slideshow I have got ... ehm, just few ... questions :D . Hopefully you will find some of them useful.
How fast are they appearing / disappearing?
Can you get more hovercards opened at once?
Are the delays going to be changed in Preferences by users or hardcoded?
Can it recognize (and show something different) you have already got that linked article in your Watchlist?
Are hovercards showed only in main namespaces pages?
Are hovercards showed only on links to main namespaces pages?
Can it deal with links to chained redirects (page redirecting to other redirect)?
Can it deal with links to redirects linking to other namespaces?
How is "lead image" picked? Is it the first one in article?
What about links to articles without images but with a (direct via template or indirect via their Wikidata item) connection to Commons category with some images?
How do hovercards deal with large images (say, 1:10 panorama view)? Do they take the setting from the linked article?
Is that "Add to Watchlist" star showed to not logged users too? I assume hovercards are showed to both logged and not logged users.
How is the used length of snippet found?
Are some parts (like other names, pseudonyms) from the top of the linked article ommited? I assume infoboxes and other templates like language ones or "add reference here" are not counted with .
So the name of article is not showed in bold in hovercards? Are there going to be any other styles showed, like italics for, say, some music/literal pieces or just plain text?
Are non breakable space taken from article or changed to normal ones?
Are upper-case letters M and E with T in "Read More" and "Last Edited Today" really needed? Maybe even any such letters in those two messages.
Is "Today" counted with UTC or user's system time (against UTC timestamp of edit)?
Can it deal with "time ago" = 1?
Can it deal with "time ago" = 0?
How detailed is that "time ago"? For example, is "1h 13m" showed just as "1 hour ago" or "32s" showed as "1 minute ago"?
Can it deal with "time ago" < 0?
Will it even reflect edits to linked pages after this page was loaded? I assume yes as I see loading snippets for each linked page during loading of the current page would be reaaally slow.
What about small "IPA" link in the corner for Wiktionary hovercards? With a link to some table with what-those-weird-sign-do-mean info (say, article IPA).
Are there really links to Wiktionary in Wikipedia articles? Or how are those hovercards going to be picked? Are you going for "ok, this word is not a link to article, let's try looking it up on Wikitionary", so every word in text can possibly have its hovercard? That sounds like too much pop-ups.
"Add audio prompt"? Will clicking on it actually take user to uploading area?
"thanked for an edit"? What about linking the edit diff itself and not the article? Or is that too scary for common hovercard user?
What about adding "Articles added to Watchlist via hovercards" to Analytics & Instrumentation section?
Utar: I'm not a developer, but I can answer a few of these.
First, I would recommend going to the Beta tab (in the top right corner) of MediaWiki and enabling Hovercards to test it yourself right now, as that'll answer a number of your questions right off the bat.
1) It's currently at 100ms, or 1/10th of a second before disappearing.
2) Only one hovercard can be opened at once, as far as I can tell.
3) Based on comments from the developers, delay probably won't be customizable. Correct me if I'm wrong, of course.
4) The Watchlist functionality isn't available in the current Hovercards implementation, and as far as I can tell it won't be added to the feature at all.
5) Nope, you can view hovercards inside any article on MediaWiki currently, and I imagine that will remain true on Wikipedia, assuming the page being linked to is itself supported by Hovercards.
10) It currently doesn't support images if the image isn't within the article itself.
11) Currently, it forces the image to fit to the card if it's too small, not sure about too big. This is a bug and will be fixed soon.
12) See above, Watchlist star isn't included in the actual product, only mockups.
15) Article titles are not currently included in Hovercards.
17) "Read more" is no longer included, "edited" is now lowercase.
I can't really answer any others, if I am mistaken about any of these please correct me. Hope this helps and takes a bit of work off the developer's shoulders so they can work on the feature itself :D Nicereddy (talk) 00:34, 26 March 2014 (UTC)Reply
Nicereddy: By article titles in 15 I have meant those few starting words in Introductory text, similar to the title of that article, which are usually in bold.
According to Tech news, we should see Hovercards at cswiki around today, they are not yet enabled there. Thanks for fast reply. Utar (talk) 18:28, 26 March 2014 (UTC)Reply
Utar: Right now I believe all bolding, italics, etc. is stripped from the text so that no part of the text takes away the attention of the user from everything else. It's probably a User Experience decision, and I don't see it as a huge problem, though perhaps I'm in the minority with that viewpoint. Nicereddy (talk) 20:42, 27 March 2014 (UTC)Reply
Latest comment: 11 years ago2 comments2 people in discussion
On the English Wikipedia en:Template:Redwd was created. This is a template to put in a red link to link to the relevant item in Wikidata. Nice idea, but I don't think that scales. Wouldn't it be nice if you hover over a red link that Wikidata gets searched and you get suggested items? Multichill (talk) 19:42, 26 March 2014 (UTC)Reply
Latest comment: 11 years ago1 comment1 person in discussion
Hello everyone!
Today we've launched Hovercards as a Beta Feature on all WMF wikis. We hope you like using it!
There are two options for giving us feedback:
Contribute to another thread that's ongoing. There are three threads I started soliciting specific feedback here, such as what you like about Hovercards, and what bugs you've found.
Start your own topic that contains just your feedback.
Latest comment: 11 years ago4 comments3 people in discussion
I'm quite enjoying Hovercards on Wikipedia thus far, but have run into additional image-related concerns. I believe that there needs to be a way to have certain articles not show images in hovercards. A hidden category or a magic word would probably be enough.
This would be used in articles such as List of people with bipolar disorder, where there is a valid encyclopedic purpose to including images of notable individuals (many of whom are still alive), but at the same time it would be questionable for any single image to represent the article in a hovercard. Sven Manguard (talk) 23:20, 26 March 2014 (UTC)Reply
Sven Manguard: It seems to me that this may be more of an editorial issue. We increasingly pull lead images from the article for representative purposes. The same image is used to represent the article in mobile search results for example, and perhaps we'll add something similar to desktop search eventually. Perhaps guidelines like Wikipedia:Manual_of_Style/Images#Images_for_the_lead should be updated to reflect that? IMO it should be possible to identify a representative lead image for lists like the one you point out, even if it's one that's more representative of the topic as a whole. Eloquence (talk) 02:06, 27 March 2014 (UTC)Reply
Eloquence: The problem in this case is that the hovercard isn't drawing from the lead, but a vertical gallery (Template:Stack). The photograph of Russel Brand is the first one because the images in that gallery are arranged in alphabetic order. I'm sure that we could find a replacement image for every article where this is a problem, but they will not always be forthcoming, and the ability to suppress having an image drawn to represent an article still seems like a useful tool. Sven Manguard (talk) 18:28, 27 March 2014 (UTC)Reply
Latest comment: 11 years ago9 comments4 people in discussion
When hovering the "→" symbol on history pages (the one that is created in edit summaries when editing a section) hovercards are shown erroneously.
Question: I actually wanted to report this as a bug in bugzilla but was not sure which component would have been appropriate. Would "BetaFeatures" have been OK or is this only for bugs regarding the feature "BetaFeatures" itself in contrast to the features offered as BetaFeatures? Patrick87 (talk) 00:09, 27 March 2014 (UTC)Reply
Patrick87: Re: "→" are you suggesting that Hovercards shouldn't show anything on that arrow, or that it should preview the actual subsection's content as Navpopups does (or tries to do)?
Quiddity: Yes, I think there shouldn't be any Hovercard on the arrow.
All necessary information (author, date of edit, etc.) is on the history page anyway
When actually hovering the arrow I'd say in 99.9% of all cases one wants to click it anyway, so there's no need to show the sections content in a hovercard. Patrick87 (talk) 10:15, 28 March 2014 (UTC)Reply
The same applies for user names and the links to their respective talk pages on history pages. They do not carry any really useful data. Instead often a hovercard pops up when one actually did not want it and hides useful information (like the following entry in the history). Patrick87 (talk) 10:25, 28 March 2014 (UTC)Reply
Other locations where hovercards are shown in error (at least in my opinion) are:
Links to user / user talk pages
Probably every Wikilink which does not link to article namespace (I don't think hovercards to e.g. help/projectpages are particularly useful)
Instead those should continue to have the title attribute shown as tooltip as before (otherwise it becomes impossible currently to tell where some links will lead except for looking at the URL) Patrick87 (talk) 00:31, 27 March 2014 (UTC)Reply
I think Hovercards should be exclusively shown on pages in article namespace (e.g. when reading Wikipedia). They are rather obstructive everywhere else (when contributing to Wikipedia).
The current mockup for user pages makes me think about post counters in discussion forums (which are an endless source of controversy and add nothing constructive). If I want to know more of a user I visit his user page. And even then I only want to get this info once whereas the hovercards will be present on each and every post of a user in a discussion which is utterly pointless. Patrick87 (talk) 02:50, 27 March 2014 (UTC)Reply
Patrick87: I disagree with Hovercards being useful only for articles, as the casual viewer would rarely - if ever - see a User link unless they were on a Talk page for some reason. It's an editor feature, and only editors will realistically ever encounter it. I also don't think it'd be particularly difficult to avoid hovering over user names.
At the same time, your concern with the User cards brings up a good point, and I think I'd agree with your point about the triviality of the edit count. Someone with 100 edits may have written 10 whole articles with just those edits, whereas someone with 1000 may have just done a lot of minor copyediting. There's no reason to compare the edit counts as though they matter, and they really only help sustain the "I have more edits, therefore my opinion is worth more" culture of Wikipedia.
Jay8g: While we would like to support more skins, we are a small development & design staff building and maintaining beta features. Beta and Regular features are optimized for the default vector skin as stated in the Wikimedia Foundation Design Guidelines. It would be great if a volunteer member could submit a monobook patch, but I'm not familiar with the technical details in this matter. Vibhabamba (talk) 09:14, 27 March 2014 (UTC)Reply
I have monobook and popups, the text in popups is bigger and more readable. hovercard text is tiny, diacritic marks are only one or two pixels high, text is almost unreable. JAn Dudík (talk) 08:54, 27 March 2014 (UTC)Reply
Latest comment: 11 years ago4 comments4 people in discussion
I'm curious to understand how this relates to navigation popups. It seems to me we have had (more or less) this feature available for many years -- does this benefit from the design work that went into that? Will this offer an option to turn on the intermediate and advanced (editor-focused) features, so that it can fully replace popups, or will it be a separate feature? It's important for the main page about this feature to explain what the thinking is about navigation popups -- otherwise it's hard to assess its merit. As of this writing, it is only listed under "open questions." I'm sure this wasn't developed in ignorance of the existing gadget, but it would be very helpful to know how the design team regards the existing feature, and whether it is considered valuable to integrate new design projects with existing features that have strong overlap. -~ Pete Forsyth (talk) 02:25, 27 March 2014 (UTC)Reply
Peteforsyth take a look at this thread a bit further down, also I think Vibha Bamba can explain the design rationale better, but, yes the team was fully aware of Navigation Popups.
We were absolutely aware that navigation popups exists. We worked with Yair and looked at Lupin's code.
Agree that we have had this feature for many years. It has been editor facing. I don't think it was consciously 'designed' for two reasons.
1. It is heavy with actions all of which are tiny targets
2. The type and imagery both of which convey information are very small for quick scanning.
The purpose of this version is to serve readers better.
The original gadgets numbers look like this -
Total # of registered users with at least 1 edit in December on enwiki:122,383
Subset of these users with navigation popups enabled: 3251 (2.7%)
While we want a cohesive strategy, we have no data as how to how useful the actions in the gadget are. Any ideas on how we can audit the set of actions? Thanks. Vibhabamba (talk) 08:47, 27 March 2014 (UTC)Reply
This is what I wrote a month ago:
As a longtime user of w:WP:NAVPOP, this is what I'd like to see, 6 months from now...
A single thing, called "Popups", that incorporates 3 aspects:
For readers: A simple version, which the current Hovercard prototypes are getting close to, and which merges Reference tooltips.
For editors: An advanced version, using wp:navpop as the target to surpass. But with improved UX (not yellow. Slightly larger font. Slightly larger image). It should include all the things we power-users love, such as:
Easy access to most, if not all of the Actions that navpop currently includes.
For both: An "off" toggle, because some people hate them!
Now however, I'm starting to think that having them permanently separate (in at least some ways) might be a good thing, as it helps us brainstorm the feature for the reader demographic by itself, without worrying about how it will impact the Navpopups that many of us know and love.
The only aspect I'm still unclear on, is how much code can, or should, be shared between Hovercards, and (the inevitable future) Navpopups2.0:GlobalEdition. I don't have enough programmatic experience to know if it might result in a simpler code-base for the reader-oriented version, whilst still allowing for shared architectural tricks. Hopefully the devs can continue to discuss these possibilities over the coming months. –Quiddity (talk) 05:27, 28 March 2014 (UTC)Reply
Latest comment: 11 years ago5 comments5 people in discussion
Going through a page history, every time my mouse moved onto an edit summary where the user had edited one section, I was faced with the hovercard for that page. Since every link was to the same article, it is rather pointless. Ypnypn (talk) 03:04, 27 March 2014 (UTC)Reply
A little irritating in the history section. Just to support the point raised above i think in the history section is kinda like not necessary cos its to the same article. I think the focus should be for main pages or searched pages. Flixtey (talk) 08:21, 27 March 2014 (UTC)Reply
Latest comment: 11 years ago2 comments2 people in discussion
In enwp, the hovercards seem to ignore the For-template in top of an article, which give you more relevant content in the popup. In svwp this does not seem to be the case, when using Template:För. How can that template be improved to get the same behaviour? 80.216.16.247 (talk) 06:55, 27 March 2014 (UTC)Reply
Latest comment: 11 years ago8 comments6 people in discussion
I'm glad a feature of this sort is now up and running. One thing though. The hovercard isn't 'responsive'. And I mean, when I hover over a link which is close to the bottom of the screen, instead of displaying the hovercard in the upwards direction, it shows rather below the screen.
Depending on the position of the link, it should display up or down to give the viewer a clear complete view instead of hiding behind the unseen portion of the screen. Nkansahrexford (talk) 07:37, 27 March 2014 (UTC)Reply
41.222.234.146: I think that lag or delay might be coming from your end as per your internet connection. Plus, it should NOT be *very* quick to display. Otherwise, when moving your mouse over an article with links, popups will be showing bam bam bam.
It needs at least 1 or 2 seconds on the link for it to recognize you *really* want to see the preview and then it starts to request from the server which is another round-robin different story if your connection is slow! Nkansahrexford (talk) 08:23, 27 March 2014 (UTC)Reply
Nkansahrexford: Indeed. I actually feel that it's a bit too fast. Once I've already hovered over a link once (and thus loaded it once), it appears almost instantly when I move the mouse over the link again. Sven Manguard (talk) 18:37, 27 March 2014 (UTC)Reply
TheDJ: yes, I think so too. As it works now, I think its perfect. The lazy loading is a good approach too. Perhaps giving the user a loading gif to feast his/her eyes on whiles the loading of the content occurs in background will be nice too. Nkansahrexford (talk) 18:12, 10 May 2014 (UTC)Reply
Shizhao: Then I'm afraid you've given me insufficient information to be able to understand or replicate your problem. As a quick test, I switched my interface to German and everything is properly localised. Can you give me a more detailed description of your problem (such as a screenshot), and how to replicate it? Dan Garry, Wikimedia Foundation (talk) 18:20, 28 March 2014 (UTC)Reply
Salix: Pronolagus rupestris is the title, "Lièvre roux de Smith, Lapin roux de Smith" is the subtitle (because this taxa has got two correct French names), made with "sous-titre/Taxon" template.
Latest comment: 11 years ago6 comments4 people in discussion
One thing that I would like to see, and if I recall correctly SJ also was also interested in, is easier access to the metadata (and attribution info) for images in Commons when they're displayed in Wikipedia articles. It is common practice, and good manners, to show the author, year, copyright status and source of artworks, images, videos etc. but it is not feasible to do this in a consistent way in Wikipedia's captions.
I would like to know if it was possible to extend the hovercard system to allow readers to quickly see the core metadata for any Commons item in an article without the editors of the WP article being required to manually code in all that data. A side benefit of this would be to expose the errors and omissions of metadata in commons more quickly - ensuring that this is more readily maintained. Wittylama (talk) 01:56, 28 March 2014 (UTC)Reply
Wittylama: It is not feasible in captions in large part because the information is not systematically stored/accessible - you've got to do template parsing to get at it, instead of a simple/sane API call. The same problem applies here. When that problem is addressed by the multimedia team (which is on the roadmap, a few quarters out?) then it probably will make sense to look at it again in this particular context. —Luis (WMF) (talk) 17:50, 31 March 2014 (UTC)Reply
LuisV (WMF): I don't understand what you mean. A helpful design would create the visual standard for where that attribution-metadata shows up in a WP article, and would call some function to retrieve that data. If the data's not available (for whatever reason: lacking API, template-parsing doesn't find a trivial match) then nothing shows up. But in some cases, the data is available, in which case it should appear.
Creating the visual style to make that data appear is a great way to get people to update metadata on all images to match whatever systematic structured-data you / the parsing scripts prefer. And the visual style will ahve to be debugged over months just as the code will: so we should start iterating on it sooner rather than later. Sj (talk) 01:59, 2 May 2014 (UTC)Reply
This will be handled by the mediaviewer beta feature. When you click on any image, it opens up a modal with a high res version of the image and details as you mentioned. Please do take a look at that feature. Vibhabamba (talk) 08:11, 28 March 2014 (UTC)Reply
Vibhabamba: As I understand it, Liam's request is to make attribution visible from the default article view, wherever an image is embedded. This is separate from, and will be viewed 100s of times more often than, metadata that is viewable after a click. This is the equivalent to a long tradition of attributing media in print publications. Sj (talk) 02:00, 2 May 2014 (UTC)Reply
One more thing: doing this properly makes pages more beautiful, and more interesting both to read and to contribute to. This sort of knowledge-enrichment in a single view is one of our trademarks (concise, thorough infoboxes; detailed tables of contents; dense hyperlinnks, including in captions and edit summaries; universal timestamps). Making progress on this - and similarly improving attribution for article pages overall - is important, and will amplify our strengths. Sj (talk) 05:53, 20 May 2014 (UTC)Reply
Latest comment: 11 years ago3 comments2 people in discussion
English Wikisource uses formatted templates to head files to present specific (meta)data and then transcludes pages of content from the Page: ns, the hovercards simply are unable to render valued information from the main namespace links. For main ns works, sometimes all I get is a title with last edited, other times, I big ugly zoom of the graphic from a copyright tag. For main ns at enWS the last edited is truly not relevant compared with the level of validation of the work, etc.
Author: ns pages, similarly unhelpful display, where I get told when last edited..
The ability of the gadget Navigation popups still outweighs the information and usefulness and will be my preferred tool (by an order of magnitude) — billinghurstsDrewth03:08, 28 March 2014 (UTC)Reply
Billinghurst: As you've noted, Hovercards presently doesn't supply any useful information to projects that make heavy use of templates at the start of articles, as it has a tendency to return blank cards. We're unsure how to address this at present, as it's not an easy problem to fix due to the way that Hovercards extracts text snippets.
The issue about the copyright tag has already been reported as bug 63185, but I've modified the title of the bug to make it clearer that it shouldn't just be specific to sister-project images but also to copyright tags.
It's to be expected that you'd prefer to use NavPopups; the intended user group for that feature is experienced editors, whereas the intended user group for Hovercards is casual readers. Hovercards is not intended to replace NavPopups in that regard.
DGarry (WMF): Depends on what is the purpose of the hovercards, which seems to be managing expectations of what will be at the link. So I see that there are two basic expectations 1) a choice of page title, and lead text, or 2) pulling established and expected metadata from a known expected template.
I would think that the WSs would be easy, it is templated metadata, and it is known what template will be at the head of each page (well, it is for English WS) and the specific content starting in the body of the works is less relevant for the hovercard. Then, if a page link does not have the expected metadata, then bad luck for that link.
To me a hovercard for a WS would say
something about the namespace (generic statement, eg. main ns: "reproduced work"; author ns: "Author's works and biographical detail")
something about the article (eg. main "Title, author, year published"; author ns: "name, years of life, maybe notes")
So I would see that communities would have a setting per namespace that would indicate whether the namespace is to extract lead content or metadata, and if metadata, a known and defined set of metadata that would be assigned to the namespace and possible extractable. The ability to embed metadata for mediawiki pages is surely part of the big plan, and this works well to that. — billinghurstsDrewth04:17, 29 March 2014 (UTC)Reply
Latest comment: 11 years ago6 comments6 people in discussion
I find the IPA codes mildly distracting. They take up space in a very small text snippet, and tend to disrupt smooth reading. For the quick glance that Hovercards mean to facilitate, they are out of place in a tiny excerpt of the article. BTW I find the same less distracting on the full article page. But Hovercards are meant to be shown possibly in quick succession. Erik Zachte (talk) 12:45, 28 March 2014 (UTC)Reply
I agree with you but we should probably check with a few more people.
Whether these are displayed in the hovercards is up to the community, if I understand correctly. Part of the IPA block is in a tag that is marked with the class "noexcerpt", presumably removing it from showing up in excerpts such that used in hovercards, while the rest of the IPA is specifically not marked with the class. I assume this is because others disagree as to whether displaying the IPA is helpful in these cases. Yair rand (talk) 23:32, 30 March 2014 (UTC)Reply
I think Yair is correct here. It may not be easy to change this, and the decision may ultimately rest with the community. If we think that the content is bad for hovercards, we should work with the community to remove it. For now, it doesn't seem that high priority compared to other issues with hovercards. Steven Walling (WMF) • talk21:49, 31 March 2014 (UTC)Reply
Latest comment: 11 years ago1 comment1 person in discussion
I think there's some need to discuss where we actually want hovercards to be shown. Basically we have to answer two questions:
On which pages (e.g. in which namespaces) do we want to show hovercards?
For which pages (e.g. links to which namespaces) should a hovercard be displayed.
Personally I'd favor to (1.) only show hovercards in article namespace and (2.) only show hovercards for links to article namespace (since cross namespace links are deprecated on most projects 2. isn't really needed in this scenario, but I consider it even more important than 1.)
May rationale behind this is, that I don't think any really useful information can be contained in hovercards leading to e.g. user pages, talk pages in general and many more. The main use case for hovercards (at least in my opinion) is to evaluate if a Wikilink to another article is relevant while reading an article. Nothing more but also nothing less.
What do others think? Should this be even configurable by the user (in which case we'd need a reasonable default for unregistered users)? Patrick87 (talk) 12:03, 29 March 2014 (UTC)Reply
Latest comment: 11 years ago8 comments5 people in discussion
While testing the beta feature in my daily work on enwiki and dewiki while both, reading and editing Wikipedia, I noticed hovercards can be really disturbing:
When I already know I want to click a link, a hovercard is popping up uselessly anyway
When reading a page with many links it often happens that I hover over a link by chance and an unwanted hovercard pops up (often covering the text I was just reading).
One idea how one could solve this problem would be to only show a small (probably iconic) pop up that allows to easily expand the hovercard on request. This smaller pop up could be made hoverable so no additional click is needed. The content could be either loaded in advance so the expansion would be instant or only on request to save bandwidth. Patrick87 (talk) 12:15, 29 March 2014 (UTC)Reply
Patrick87: the problem is real, but i do not like your solution.
what i suggest is a bit different: on each hovercard, add two miniscule buttons: one to turn off hovercards for current page (probably just by setting global JS variable), and the other to turn hovercards off globally (presumably through cookie). if the feature is turned off globally, it would be nice to add a way to turn it back on (e.g., a linkette in the toolbox).
(note that gadget navpopups has something similar, at least for curent page).
of course, all this only if user did not opt out through preferences.
Same problem. I have to enable/disable the beta feature quite often to be able to edit text without being disturbed. Another solution could be a link into the "tool" left column, to have it on/off easily. Salix (talk) 23:43, 29 March 2014 (UTC)Reply
Salix: When you say "edit text without being disturbed" what do you mean? are you seeing hovercards while editing (VE, Wikitext) I understand what you mean about the hovercard popping up when you're in a list, but I wanted to learn more about the issue while editing. Jaredzimmerman (WMF) (talk) 07:38, 31 March 2014 (UTC)Reply
Regarding "clicking": Thats why I suggested some "double hovering" or the like as an alternative. Anyway even clicking to expand a hovercard is a huge difference from opening the article:
No need to open a new tab, switch to it, close the new tab, go back to the original article etc. It's still everything happening on one page without further navigation being necessary.
The overview of the linked article via hovercard would still be "quick" (I don't think that it takes overly long to make a click), but on purpose (whereas now the hovercard often pops up accidentally – and there's nothing worse on a page than unwanted pop-ups)
It still saves bandwidth and therefore also time by only loading a small portion of a page whereas opening the full page requires the full page to load by definition. Patrick87 (talk) 13:24, 27 April 2014 (UTC)Reply
Latest comment: 11 years ago4 comments3 people in discussion
Hi, when used on fr:Butiinae article, clic on "Cocotier du Chili" : we get a portrait instead of Taxobox's Chilean Wine Palm. It's the last of many illustrations of [2]) ! Salix (talk) 23:27, 29 March 2014 (UTC)Reply
I'm having a similar problem with Counter-Strike: Global Offensive. The picture shown is the screenshot in the Gameplay section rather than the image in the infobox at the top.
Latest comment: 11 years ago2 comments2 people in discussion
Hi, on a list, it's easier to go from botom to top to avoid overlay problems while reading fast, or you need each time to get out of the popup to be able to hover over the next word down. Hovercards should be displayed on right or left of the bleu link, or live free a larger space in between the word and the square, to provide an easy acces to the next line. Salix (talk) 10:04, 30 March 2014 (UTC)Reply
Latest comment: 11 years ago2 comments2 people in discussion
Presumably I know a fair bit about the articles in my watchlist, and (if others are anything like me) I tend to do a fair bit of mousing around on that page (since there is soooo much nitty-gritty detail in it/so many links). So I found the popups a little distracting in that context. Might make sense to disable them there. Otherwise love them - thanks! 2620:62:C000:149:457:BFA7:41DD:C7F3 (talk) 17:34, 31 March 2014 (UTC)Reply
Patrick87 (talk) 11:48, 29 March 2014 (UTC)
