Talk:Page Previews/2014/04

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

Location of hovercard

The location of the card is determined by the element to which it's attached. In many cases this is sub-optimal. Specifically, when it's attached to an internal link which is word-wrapped, the location of the hovercard is determined by the beginning of the link (or, rather, "upper left corner"), which can be very surprising when you hover over the wrong half (if i'm not mistaken, which half is "wrong" depends on whether this is LTR or RTL page).

it would be better to use the mouse location rather than the element for this, like most browsers' tooltip behave (mouse location can be extracted from the "event" object which is passed to the handler).

While you are at it, please also look at "auto" gravity (one of the options of tipsy). in a nutshell, when card location turns out to be too low, jump it above the point instead of below. If location is too much to left or right, correct accordingly.

peace. קיפודנחש (talk) 17:48, 1 April 2014 (UTC)

קיפודנחש: Some of the issues that were presenting in Hovercards as a result of poor handling of RTL languages were fixed recently in bug 62970. In particular, the issue of the popup appearing in the wrong place when you hover over a multi-line link is already filed as bug 63159. We've also got bug 62971 for issues relating to popups not appearing correctly at the edges of the browser windows. I'm unsure what you're referring to when you say "Tipsy"; perhaps you could comment on the bug with an explanation?

Thanks very much for the report! Dan Garry, Wikimedia Foundation (talk) 20:55, 1 April 2014 (UTC)

DGarry (WMF):

i only mentioned rtl in the context of split-link, where hover location may be sensible either when hovering over the head or tail, depending on directionality.

as to tipsy: it's a jquery plugin used by mediawiki that provides "better tooltips". the whole hovercard feature could have easily used tipsy to save part of the code, instead of handling the display directly. it would not save you much - maybe a couple hundred lines.

this plugin has an option for "intelligent" location of the card such that if you are too close to the bottom, it pops above (presuming you want it below otherwise).

(btw - tipsy does not know yet how to display the hint based on mouse location - i'm trying to create a patch to solve this).

i added a comment to bugzilla:62971.

peace. קיפודנחש (talk) 14:23, 2 April 2014 (UTC)

Interference from existing preference

There is a similar feature available as a preference (at least on Wikipedia and Wiktionary). This hovercards feature should disable it when it is enabled, otherwise you get two different overlapping hoverboxes at once. Wikitiki89 (talk) 18:49, 1 April 2014 (UTC)

Wikitiki89: That's tracked at bugzilla:62952. Thanks :) –Quiddity (talk) 19:30, 1 April 2014 (UTC)

Additionally, the hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. Help:Navigation#Sidebar) and previewing the reference of a <ref> tag. Wikitiki89 (talk) 23:59, 5 April 2014 (UTC)

Typo : Double coma and no italics

Hi, when you have footnotes markers in a text, separated with [[http://fr.wikipedia.org/wiki/Modèle:,]], and then a normal coma, Hovercads displays two successive normal comas. (eg. Try Atherurus macrourus on fr:Athérure page). In the same article, you can also see that hovercards doesn't display italics of the scientific name. Salix (talk) 21:36, 1 April 2014 (UTC)

Can you please include a screenshot of what you are seeing? Vibhabamba (talk) 04:11, 4 April 2014 (UTC)

Vibhabamba: No problemo : https://fr.wikipedia.org/wiki/Fichier:2014-04-04_121447.jpg Salix (talk) 10:22, 4 April 2014 (UTC)

Image sometimes missing

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.

---

Go to https://en.wikipedia.org/wiki/Disco, search for "Disco Demolition Night". When you hover it, there's no image (just blank area). Juliusz Gonera (talk) 23:58, 1 April 2014 (UTC)

Juliusz Gonera: We've got a patch in for review on this issue: bug 63207. Thanks! Dan Garry, Wikimedia Foundation (talk) 21:15, 2 April 2014 (UTC)

It's a very common problem. We have the same on most of the blue links for example in this article : https://fr.wikipedia.org/wiki/Hyphessobrycon. Salix (talk) 08:33, 2 April 2014 (UTC)

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

Hovercards showing up when scrolling

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

---

I think popups should not show up when I scroll and my cursor accidentally ends up hovering a link. Since I didn't hover the link on purpose, I probably wanted to continue reading the article instead of seeing a hovercard.

An easy solution to this would be to temporarily disable hovercards on window scroll JS event and reenable them on mousemove event. Opinions? Juliusz Gonera (talk) 00:04, 2 April 2014 (UTC)

Juliusz Gonera: Seems reasonable, want to submit a patch? Jaredzimmerman (WMF) (talk) 08:01, 3 April 2014 (UTC)

Jaredzimmerman (WMF): Done (https://gerrit.wikimedia.org/r/123790) Juliusz Gonera (talk) 21:56, 3 April 2014 (UTC)

Juliusz Gonera Awesome cc:Prtksxna Jaredzimmerman (WMF) (talk) 23:08, 3 April 2014 (UTC)

Juliusz Gonera: Thanks for the patch! I'll merge it as soon a possible. Prtksxna (talk) 10:13, 4 April 2014 (UTC)

My thoughts exactly, thank you. Eman235 (talk) 00:13, 4 April 2014 (UTC)

Thank you very much for preparing this patch. Vibhabamba (talk) 04:10, 4 April 2014 (UTC)

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

Difficult to select and copy the text of a link

The popups makes the selection of the text of a link more difficult. Helder 15:49, 2 April 2014 (UTC)

The popups don't actually cover the links at all. Is there any way that you can show us a screenshot of the popups obscuring the link you're trying to select so we can better understand the issue? Jaredzimmerman (WMF) (talk) 08:00, 3 April 2014 (UTC)

It is distracting. The pop ups are not helpful during the selection process, so they should not be displayed in this case. Helder 18:54, 3 April 2014 (UTC)

Can you explain your use case? Why are you selecting the text of a link and how frequently do you do it? Vibhabamba (talk) 04:09, 4 April 2014 (UTC)

I remember these common cases for now:

• To copy the user name of someone, to insert in a {{U|...}} template;
• To copy the title of a page to explain something about it
• To quote something another user said in a link
• To copy a comment I just wrote in a discussion from the preview to the summary Helder 14:59, 4 April 2014 (UTC)

Error: Cannot read property

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.

---

"Cannot read property '0' of undefined"

This error has occurred in the link to the post history of IP users. Frozen-mikan (talk) 03:15, 3 April 2014 (UTC)

And correct. Is not only IP user, this error has occurred for links to Contributions page of all users. Frozen-mikan (talk) 06:22, 4 April 2014 (UTC)

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

Окон нет

И что? Где эти окна?? Их нет! Angeil Rogozina (talk) 05:16, 3 April 2014 (UTC)

Angeil Rogozina are you having an issue with the hovercards not appearing? or just seeing blank hovercards? If you're not seeing the hovercards at all, go back to Beta in your preferences and make sure the feature is enable, and don't forget to save your preferences before going back to an article.

From google translate—

вы возникли проблемы с наведения карты не появляется? или просто видя пустые наведении карты? Если вы не видите наведении карты вообще, вернуться в бета-версии в настройках и убедитесь, что функция позволит, и не забудьте сохранить настройки, прежде чем вернуться к статье. Jaredzimmerman (WMF) (talk) 07:57, 3 April 2014 (UTC)

Nice feature but has many problems

Can you please explain the issues you are experiencing? Vibhabamba (talk) 04:09, 4 April 2014 (UTC)

overlaps with the gadget 'Navigation popups'

with both activated, they basically overlap each other, so i guess they are competing gadgets? is there no elegant way to preview both in the preferences, so i can select one or the other?

after having used navpops for years, i'm more accustomed to that layout: familiar wiki heading, underlined blue links, small main pic (if present). hovercards have a neater, postcard feel to it; but the layout seems to vary from link to link -- some have a large blank filling up to 60-70% of the box, which i assume is an image that failed to load (or a nasty bug), and this image-space seems to float towards random edges for different links (no discernible pattern to me). i don't think such a large preview image is necessary, and i personally prefer preserving the underlined blue links in the text -- breaks the monotony of a chunky paragraph while highlighting keywords.

another minor aesthetic complaint: the hovercards seem to have some mouseover-underline of the entire paragraph displayed -- any reason for that? i suspect a CSS overlap with my Vector skin underlining. Alveolate (talk) 19:37, 4 April 2014 (UTC)

Alveolate: I also prefer the old navigation popups. These new hovercards only seem to display the first sentence of each article (the popups display the first whole paragraph, which I appreciate). OmgItsTheSmartGuy (talk) 17:30, 5 April 2014 (UTC)

I much prefer the navigation popups.

1. You can hover over links within a nav pop to trigger a further nav pop, which is something I do often. (Many times the initial popup is not specific enough to explain the original link to me.)

2. The nav pops have a delay so they don't appear as your cursor glides across the page (absentmindedly or otherwise), but only when you actually want to "expand" a link.

The aesthetic of the new hovercards is a step in the right direction (clean, white, with a pointer, etc) compared to the yellow, early-2000s-looking nav pops, but the utility of the latter far outweighs this. 108.44.44.121 (talk) 13:50, 5 April 2014 (UTC)

Above comment by 108.44.44.121 was me, I didn't realize I wasn't logged in. Ellsass (talk) 13:51, 5 April 2014 (UTC)

Font size on hovercards are very small when using the Monobook skin

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.

---

This problem does not appear when using the Vector skin. Lennieii (talk) 04:39, 5 April 2014 (UTC)

Also happening in Modern skin.

Cologne Blue shows legible fonts, but notably smaller than Vector.

Maybe this issue is affecting many other skins. Junghyeon Park (talk) 04:01, 6 April 2014 (UTC)

As per the design guidelines and limited resources, we are unable to provide optimization for skins other than the default skin - Vector. I highly recommend switching over to the default skin. 'Designs as intended' in terms of sizes, styling and overall experience are heavily tested for correct rendering in Vector and we address all bugs related to that. Vibhabamba (talk) 23:48, 8 April 2014 (UTC)

Vibhabamba: Monobook skin is widely used betveen sysops and "old" editors because in vector are many useful tabs (delete, lock, move) hidden uder arrow.

There is problem with unrecognisable diacritic marks žščřáéíóů JAn Dudík (talk) 10:50, 22 April 2014 (UTC)

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

Needs more features

A edit link would be nice as well as some meta information, like the amount of wikilinks an images are on the page as well as a way to watch the page right from the hovercard Kangaroopowah 05:18, 5 April 2014 (UTC)

Kangaroopower: true Daughterofathena101 (talk) 06:27, 5 April 2014 (UTC)

Lacks useful features of old hoverboxes

The hovercards are missing many of the features that the old hoverboxes have. For example: previewing the correct section of the page for section links (e.g. Help:Navigation#Sidebar) and previewing the reference of a <ref> tag. As of now, these hovercards are nearly useless on Wiktionary because most pages have nothing in the lead section (thus the hovercards are blank) and most links link to specific language sections (e.g. a#French). Wikitiki89 (talk) 00:09, 6 April 2014 (UTC)

Agreed. Also with the navigation tooltips (the predecessor that Wikitiki89 refers to as the 'old hoverboxes') you could hover over the links in that tooltip and another pop up would appear and so on. It would be nice to have that in this as well. Imagine Wizard (talk) 22:24, 16 April 2014 (UTC)

IPA Tooltip

This isn't terribly important, but I've noticed something that's pretty annoying while having hovercards enabled and hovering over the IPA for English anchors to read the tooltips that show the phonetic descriptions. Because each syllable is a separate link to enable them each to have their own tooltips, every time you move your cursor to the next one the hovercard closes and opens again, which I'm sure you can imagine is even more annoying for words with many syllables.

Here's a screenshot of what I'm referring to: http://i.imgur.com/qRpqD2D.png

I suppose my suggestion would be to either disable the hovercard for those IPA links, try to configure it to keep the first card open as you move your cursor amongst the group of links (so the card only opens once), or--and this would be best in my opinion--replace the standard tooltip with a hovercard style tooltip. Actually now that I think about it, a hovercard that compiles all of the syllable descriptions of the word into one card would be awesome. In that case the user wouldn't even have to move their cursor to the next syllable as the card could list them all in one box.

An example of what I mean using the word in my screenshot would be a hovercard containing a list like this:

/'nɑːwɑːtəl/

- "n" as in "nigh" - /ɑː/ like the "a" in "father" - "w" as in "wind" - /ɑː/ like the "a" in "father" - "t" as in "tie" - /əl/ like the "le" in "bottle"

Obviously it doesn't have to be a bulleted list and can be made to look more useful and appealing, but I think you'll get the gist of what I mean. (Edit: I wrote the above list with every point being on its own line, but this Flow feature apparently forces every point to display on one line. Sorry for the confusion.) NBMATT (talk) 00:45, 6 April 2014 (UTC)

Parametr $1 translation message not found

https://translatewiki.net/w/i.php?title=MediaWiki:Popups-last-edited/kk-cyrl&action=edit Here parametr $1 translation message not found. Where here?

Arystanbek (talk) 05:44, 7 April 2014 (UTC)

Im a little confused by this screenshot. Are you seeing both the english and native script next to each other? This is where we track translations - https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc Vibhabamba (talk) 23:42, 8 April 2014 (UTC)

This string can’t be translated on Translatewiki.net: the Hovercards extension includes the Moment.js library, which doesn’t have anything for Kazakh yet. You can contribute a Kazakh localization on GitHub, but I don’t know how this library handles script codes like “cyrl”. You may also have to nag the Hovercard developers to update their copy of Moment.js. Minh Nguyễn ^💬 07:29, 13 April 2014 (UTC)

nice but have some problems with it - pics, none relevant text appearance, empty area

• the pics r too big and thus text availability is compromised - depends on location in page, but in my experience most of the time scrolling is needed, so abit annoying - text is more relevant in most cases...
• in cases of multiple uses of a term, the window doesn't show relevant text, but the first note naming the page focus and directing to the other usages.
• sometimes it opens with an empty area - i assume, an absent image. Dalilonim (talk) 03:39, 8 April 2014 (UTC)

Thank you for reporting this, we have a bug out for item 1. In the second bullet - are you suggesting that we remove the re-directs? That has already been fixed. You should expect to see a change within the next 2 weeks. Vibhabamba (talk) 22:02, 8 April 2014 (UTC)

yes the re-directs. tnx. i hope u will also correct no. 3 also i'd like to add:

4. as an editor i would like to have the option to put off the function, i often only want to check the link behind. i think u should consider giving that kinda of control to readers, so they have full interactivity. now days changing design and tools has become a routine, there r always people who suffers from it, find it hard to adapt again and again, or just want to read like with a book, when they can turn the pages they don't like. maybe we should give them that kinda tools. Dalilonim (talk) 06:17, 9 April 2014 (UTC)

Add a option show one preference interwiki

When translating, we need to check whether there is one corresponding entry at zhwiki of a link at enwiki. If HCs has a option show one preference interwiki, it will be convenience that we don't have to click to enter each entry to check the interwiki. By the way, the display text of interwiki copied available will be the best.

We have achieved this feature at Popup in special script by zh:User:喵.

window.popupHomeLanguage = "en";

importScript('User:喵/fork/MediaWiki:Gadget-popups.zh.js');

importScript('User:喵/fork/MediaWiki:Gadget-popups.js');

importStylesheet('User:喵/fork/MediaWiki:Gadget-popups.css'); 乌拉跨氪 (talk) 11:59, 8 April 2014 (UTC)

Nice feature

I've been using hovercards for just a few days and it's a great little feature that enhances the browsing experience. The visual design is modern and clean. Like the name as well. As always with new gadgets there are things to improve and here are some suggestions.

1. Keep it as simple for the readers as possible. Pretty much as it is right now. An editor version with extra functionality and info might be worth considering (depending on feedback) but that should not be the default version.

2. The only functionality I would consider adding is the cascading popup functionality of navpops which means that hovercards need to show hyperlinks in the text (nice to have not must have).

3. If you hover over a link at the bottom of the page the hovercards should open upwards instead of downwards

4. I often rightclick on links to open an article in a new tab (or window). During this action the hovercard appears with is somewhat distracting and annoying. Can the hovercard recognize the rightmouse click and stay closed?

5. Disable hovercards in the watchlist.

6. Disable hovercards on the view history page.

7. Disable hovercards on WikiProject pages Wolbo (talk) 12:33, 8 April 2014 (UTC)

Wolbo: Regarding your first point, maybe the current implementation of NavPopups should be merged into Hovercards as its optional 'editor' mode, but with an interface updated to match that of Hovercards? RandomDSdevel (talk) 19:12, 5 May 2014 (UTC)

RandomDSdevel: I was thinking exactly that as well. In theory, Hovercards could replace NavPopups entirely, if Hovercards offered an "editor mode" that switched on an equivalent featureset (or at least a sufficiently-complete subset of features that NavPopups users value). The main advantage would be avoiding the "collision" possibility of multiple link-hovering tools, as they can't usefully be used together. I remeber at one point some link-hovering code had been switched on at enwiki (I think it was for note/reference links), and for those of us who had NavPopups enabled the two hovers overlapped unhelpfully. Consolidating the features would avoid forcing users to choose between NavPopups and HoverCard.

However, from what I've seen of HoverCard and based on some of what I've read here, I no longer believe that's a good idea. The design of HoverCard clearly follows the recent trend towards minimalist, "clean", low-noise interfaces, absent both clutter and power. That's not merely its current form, but the philosophy of its design and its designers. This is evidenced by the response (somewhere above) that a feature to turn off images in HoverCard isn't workable, because it's somehow bad practice to have "preferences at an element level".

NavPopups may be a bit busy and ugly, but there's a lot there. A HoverCard "editor mode" would inevitably discard most of those features, making it a crippled replacement for NavPopups. I'm personally tired of seeing useful tools replaced with less-useful "improvements". 2001:470:1F07:D25:D5D0:5F09:52BB:2A77 (talk) 16:07, 15 May 2014 (UTC)

2001:470:1F07:D25:D5D0:5F09:52BB:2A77: *sigh* I guess I somehow got logged out in the process of editing that post, which I hadn't realized until it posted. Since there doesn't appear to be a way in Flow to "claim" the post as mine, I just wanted to identify myself as the author of the above. FeRDNYC (talk) 16:13, 15 May 2014 (UTC)

FeRD NYC: I'll keep using NavPopups for the time being, then. Even though this gadget's feature set can't be even partially migrated over to that of Hovercards in a permanent manner, could a Hovercard 'editor mode' copy over at least some of the functionality that currently exists as part of NavPopups? Why would it be bad to have preferences at an 'element' level? Whose idea was that? I think that sub-feature preferences are great! RandomDSdevel (talk) 22:29, 21 May 2014 (UTC)

Thank you for all the feedback.

There is a bug out for item 3 & one for items 5, 6, 7.

Item 2 is a good idea, but has dependencies with general mouse behavior. We are gathering a pool of feedback whether hovercards are getting in the way of scrolling etc. And if they should persist when you move your mouse into them.? Vibhabamba (talk) 21:53, 8 April 2014 (UTC)

It's really nice, but...

There is just one thing that works wrong in the hovercards. When you put the mouse over a link to a page that has disamibguation, it shows it and not the article. When you hover america, for example, this text is shown:

ערך זה עוסק ביבשת אירופה. אם התכוונתם לפירושים נוספים למושג "אירופה", ראו אירופה (פירושונים).

(Translation to english)

This article is about the continent. For other uses, see Europe (disambiguation).

The bug, as much as I know, only appears at the Hebrew Wikipedia.

Can you make the hovercards skip the "פירוש נוסף" (another explnanation) tamplate? בנימין (talk) 05:29, 11 April 2014 (UTC)

Thanks for the comment, Binyamin.

A clarification for the developers who are reading this: This is not about a disambiguation page, but about what in English Wikipedia is called a disambiguation hatnote, such as en:Template:About. It indeed doesn't seem useful to show them, and it would be nice to have a robust way to hide them. This may be useful for some other templates as well. Amir E. Aharoni {{🌎🌍🌏}} 13:28, 18 April 2014 (UTC)

Thanks

This is an extremely useful feature. And nicely designed too. Hope you would add a feature to disable it similar to or exactly the same way as in Reference Tooltips (were it can also be easily reenabled by clicking the link at the bottom) Vis M (talk) 22:28, 13 April 2014 (UTC)

Maybe the two features could be merged in such a way that users could enable them independently of full Hovercards? RandomDSdevel (talk) 17:53, 4 May 2014 (UTC)

Save space in redirect cards?

Instead of having "redirects to" taking up extra space in the card, why not just add the redirect arrow next to the article title? Space is pretty valuable for a card that's supposed to be fairly small, so I think it'd be valuable to implement this. Nicereddy (talk) 22:25, 17 April 2014 (UTC)

Great idea! We are eliminating the 'redirect' labels. Vibhabamba (talk) 22:18, 21 April 2014 (UTC)

Translation to Hungarian

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

---

I turned this function on at huwiki for myself and noticed that the text is in English. Would like to help but I have no idea how to find what is needed to be translated. https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-popups&suppressempty=1&language=#sortable:3=desc does not have Hungarian listed. Please help :) Xia (talk) 17:28, 18 April 2014 (UTC)

Thank you for pointing this out, I'm checking and will get back to you. Vibhabamba (talk) 22:17, 21 April 2014 (UTC)

I just found that, Hungarian is actually included. If you uncheck the checkbox which says 'Do not display languages which do not have any translations', you will see it. Its a simple 1 string translation for the 'Last Modified' timestamp. Perhaps you can translate it? Vibhabamba (talk) 22:45, 21 April 2014 (UTC)

Vibhabamba: Thank you! Found it and translated all texts. Xia (talk) 13:53, 24 April 2014 (UTC)

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

Actions from the original navigation popups gadget

We are trying to better understand the usage of the original gadget. Specifically -

1. Investigate which actions from the original gadget are useful

2. How do editors use the navigation popup - Do they read the extract and the statistics?

If you used the original gadget, please add your comments with explanation here. Vibhabamba (talk) 23:01, 18 April 2014 (UTC)

The actions I use most are

• Diffs (from watchlist, history, contribs, etc; including from other popups)
• History
• User contribs (including from history popups)
• Multi-level popups (article popups from other article popups

I sometimes look at the statistics on user popups. I do not feel the last-edited statistics on hovercards are useful. Jay8g (talk) 18:02, 19 April 2014 (UTC)

Vibhabamba: first and foremost, diffs.

for diffs, i'd rather see the whole diff, with scrollbar if needed, rather than truncated beginning of diff (navpop shows the whole diff, but it does not create a scrollbar, and instead, the navpop box can grow arbitrarily tall).

second, the fact that navpop understands anchors: if the link is "Page#Section" rather than "Page", navpop will show the opening paragraphs of the section, while hovercards shows the opening of the article.

this works for real links in the article, and also the link of "→ <section>" in history, watchlist and recent changes pages etc.

peace. קיפודנחש (talk) 22:52, 19 April 2014 (UTC)

Vibhabamba: The navigation popups are far more useful than the hovercards. I assume you already know this. That said, I very much use the popups to examine users for their edit count and which hats they collected. (I like knowing to whom I'm speaking.) I also like getting a quick look at their edit history and talk pages. This is especially useful on vandal IPs. On articles I like getting the lede as well as the age and size of the article. I also use the link to see the page's history tab and talk page. Navigation popups are probably the best gadget second only to Twinkle. Chris Troutman (talk) 11:01, 22 April 2014 (UTC)

Chris troutman:Totally agree that the gadget is super useful. Are many editors un-aware of this gadget? We looked up some numbers. As of December 1 2013, only 2.7% of all registered users with at least one edit had the navigation popups gadget enabled. And the total registered users was about 120K. Vibhabamba (talk) 18:30, 23 April 2014 (UTC)

Vibhabamba: I mainly use it for viewing diffs and histories on my watchlist. While the popups diff display is arguably atrocious, it mostly gives a decent first impression (but takes 'trained' eye). After that, I use it to peek to other articles. And I occasionally use it to revert to a specific revision. -- [[User:Edokter]] {{talk}} 11:03, 22 April 2014 (UTC)

Edokter: thats interesting. Currently hovercards is only addressing links within main article area - blue links for other articles, references and wiktionary items. We haven't included diff's and histories. Both really good points for us to think about in the future. Thank you for responding. Vibhabamba (talk) 20:40, 23 April 2014 (UTC)

For all pages:

• Read Preview (recursive)
• Watch/Unwatch
• View History (recursive)
• Open Talkpage in new tab
• Viewing diffs - Particularly from my Watchlist page, or a History/UserContributions page, I'll mouseover dozens of these difflinks every day

For Users:

• View Contributions (recursive) - to check specific contribs, and to check recent activity levels
• Open Talkpage in new tab
• "Space" - Search Subpages (Special:Prefixindex)
• User stats (groups, editcount, first join date)
  • I wish it included a "last edited" time.
• I wish it included a link to Special:CentralAuth or SUL Info

Custom-additions:

• popupFixDabs=true; (this lets us fix links-to-disambiguation-pages with 1-click)
• popupDelay=0.3; popupHideDelay=0.3; (this is slightly faster than the default. I left notes on timing at the archived page which I think warrants research.)

Note: There are already a few layout options for Navpopups, en:Wikipedia:Popups/Structure examples, though I'm not sure how widely these are used.

I'd suggest asking the Research dept to put together stats on how much each of those, and the other en:Wikipedia:NAVPOP#Options are used, if possible. That options list is well worth reading, to get a sense of its power/complexity. –Quiddity (talk) 20:59, 22 April 2014 (UTC)

1. Quick navigation (mostly edit/history/talk/pagelog, user contribs, leave a comment, user log). I know where i'm going, don't need the inbetweenspot of the page.
2. Getting stats: 31.7kB, 114 wikiLinks, 0 images, 2 categories, 20 hours old (big or small article?), sysop, 35176 edits since: 2005-04-21 (new or seasoned editor)
3. Fixing links (redirects, disambiguations).
4. Viewing diffs —TheDJ (Not WMF) (talk • contribs) 18:56, 19 April 2014 (UTC)

How can I invite more community members to participate in this audit? Vibhabamba (talk) 21:04, 21 April 2014 (UTC)

Vibhabamba: By asking people on wikis with actual user traffic. Your best bet is the Technical Village Pump on the English Wikipedia. Jorm (WMF) (talk) 21:45, 21 April 2014 (UTC)

Thats a great Idea! Ill work with Dan and Nick to work on a quick post. Thanks for pointing to this. Vibhabamba (talk) 22:20, 21 April 2014 (UTC)

Personally, for articles I've only ever used:

• View history
• Most recent edit
• Talk

and for Users:

• Contributions
• Talk

I don't really see much of a reason to include the Move/Edit functionality in Hovercards, as I've never seen a real reason to edit an article based on the preview given in a Hovercard. Perhaps other users have reasons to include the feature, though. Nicereddy (talk) 23:52, 21 April 2014 (UTC)

Hovercards: I tried but disabled. I found the emphasis on images more distracting than useful.

Popups: I've enabled for a while now and certainly like the idea in principle. As a reader, I primarily use them to preview articles (although as often as not, I read Wikipedia on a tablet). But as an editor, I find myself clicking through most of the time to the underlying content, though I find them useful for examining reference numbers. Popups would be especially useful to me if the feature could shortcut "Watchlist checking": viewing changes made on a given article since my last visit. At present, that's a cumbersome, multi-click process. Barte1 (talk) 15:17, 24 April 2014 (UTC)

Text summaries are clipped awkwardly sometimes.

Most times the hover cards do a good job of ending after an appropriate amount of content, but on longer excerpts text gets truncated, often abruptly. (Example: The link to the flow extension at the top of this talk page.) This is opposed to just ending at a sentence boundary.

This wouldn't be so bad if ellipses were at least appended to the text, but in either situation it badly triggers the zeigarnik effect. This leads to clicking on the page to finish reading the excerpt... and then you've left the page and lost your original reading context.

As a designer/copywriter/programmer, this just stuck out at me -- I don't know if it bothers anyone else. Overall though, I think hover cards are a great idea. The project page states that the goal of the feature is to provide readers with an excerpt so that they "can make the decision about whether they want to read the full article" or not, but it strikes me as being just as useful for getting a quick idea of what a term means. (It's kind of the idea pondered here.)

I have a couple other suggestions, but I want to turn those over in my head for a bit first. For most of the project though: looks good! Connor Krammer (talk) 17:42, 19 April 2014 (UTC)

Connor, I completely agree with you, we should truncate sentences. Say we have to truncate after 250 characters. This would be very different for different languages. What counts as a character in Hindi is much less than an actual alphabet. So we are struggling a bit with this technical limitation.

Its a great insight that once the user lands on the target page, the transition is lost. I have some ideas, but would also like to hear of how we might be able to solve this. Vibhabamba (talk) 22:00, 21 April 2014 (UTC)

I believe we have some language engineering folks who can help figure this out. Pau Giner? Vibhabamba (talk) 18:42, 23 April 2014 (UTC)

Showing some partial content in a way that works well across multiple languages is a hard thing to do. Depending on how you want to deal with it, you may need to take into account how each language separate words, use a different line according to their script, or the very notion of "character" and how those are counted.

It would be useful to have a generic component in MediaWiki that let's you just show a given number of lines, or whichever content fits in a given space. This is something that the Language Team may consider to support in the future.

An alternative to cropping with an ellipsis, could be to make the last part of the text to fade out by applying a transparent-to-white gradient on top of it (covering the last line).

Regarding the continuity problem mentioned by Connor, that can be solved if when reaching the article though a hovercard, the first sentence of the article gets highlighted for a second (e.g., background could fade to grey and back to white again). In that way, the user could guess that the text is the same and continue reading where he/she left. Pginer-WMF (talk) 21:06, 23 April 2014 (UTC)

Breaking the sentence after a certain number of characters is not i18n safe. It can cause lot of issues with complex scripts. Complex scripts require grapheme boundary detection or word boundary detection for finding out sensible line break positions. That is defined in TR29 of unicode standard and very difficult for the context. Pau's suggestion about fading the last line looks good to me. Santhosh.thottingal (talk) 04:19, 27 April 2014 (UTC)

Santhosh.thottingal: I think you are making it a bit too complicated here. You are looking for solutions to fix an imperfection, but your workaround is also not perfect. Don't trade the one imperfection for another imperfection too easily. —TheDJ (Not WMF) (talk • contribs) 10:32, 28 April 2014 (UTC)

TheDJ: I was just pointing out the i18n aspect. I did not propose any solution or workaround. Thanks. Santhosh.thottingal (talk) 11:53, 28 April 2014 (UTC)

As an example of somewhat awkward cropping, mousing over a link to https://en.wikipedia.org/wiki/Bernard_Zakheim gives "Bernard Zakheim, Apr.", presumably because it treats the period as a sentence termination rather than an abbreviation. Not the end of the world but something else to consider while improving this. LuisVilla (talk) 22:37, 21 May 2014 (UTC)

Longer delay in categories

When I am not only reader but editor too and want to open more links from category/list, hovercard make opening of more links difficult, because hovercard is usually over next link. Pop-ups have longer delay before opening. JAn Dudík (talk) 10:47, 22 April 2014 (UTC)

I would agree with the above request to implement a longer delay before the hovercard is displayed - just moving my mouse around on the screen will cause hovercards to open, and they don't disappear readily so it can block the article text I am reading. Instead, use a longer delay so that the hovercard is only displayed when it is clear that the user wants to see it. Ryan • (talk) • 18:36, 2 May 2014 (UTC)

Include an opt-out for images?

I like the idea of Hovercards, but I find the inclusion of an image unhelpful. For one, the image doesn't render in my browser (Safari 7.0.3).

Also, the image forces the text about halfway down the page, far below the link. From an ease of use perspective, I think we want the text directly below the link, not 3-4 inches down the page. If the link is toward the bottom of my window, I have to scroll down to read the text in the Hovercard, which gets annoying.

Anyway, I would suggest either removing the image part of Hovercards altogether or including an opt-out for those who want the text but not the image. As it stands right now, it works best for articles that have neither an image nor an info box, as then the text appears directly below the link.

I second Connor Krammer's comment that Hovercards are probably as useful (if not more so) for defining terms as they are for helping readers decide whether or not to read an article.

Update: Hovercards works just fine in Firefox 25.0; the images render and the text appears right below the link. I think the problem is that it doesn't work very well with Safari. I actually kind of like having the image appear with the text in Firefox. :) AmericanLemming (talk) 16:18, 22 April 2014 (UTC)

AmericanLemming: I agree that the feature would be much better without an image. The image takes up too much space, and covers up too much of the present article that the reader is at.

To me, it doesn't matter whether the image renders well or not. It just takes up too much space.

So, I suggest an opt-in for images. Anythingyouwant (talk) 01:09, 24 April 2014 (UTC)

Drop the image. It takes up precious space. The text is more important in getting clarification. Often the image is clipped or too small to see anyway. Drop the image. *Opt-in* for image.

As is, the text is cut short; would be nice to enable *more* text inclusion in the pop-up (user controlled?). Malcolmj1 (talk) 21:03, 27 April 2014 (UTC)

I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its a also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. Vibhabamba (talk) 02:19, 28 April 2014 (UTC)

Images doesn't render in my browser too.

Windows 8 and IE11. 89.142.77.230 (talk) 03:55, 9 May 2014 (UTC)

Feedback

I've just tried out the Hovercards extension, and I just would like to say that it provides no surplus as compared to the traditional popup feature I've been using on all platforms so far. I'll switch it off again.

If you would like to receive more feedback from me, please ping me on German or English Wikipedia because I don't visit mw regularly and I have notifications switched off here. Thx. Aschmidt (talk) 00:09, 23 April 2014 (UTC)

Hovercards is not intended to be a replacement for Navigation Popups. NavPopups is intended for editors who appreciate the actions that it provides and use those actions to streamline their work. Hovercards, on the other hand, is intended for readers, and therefore does not include actions as by definition a reader is more interested in reading than editing.

I hope that helps you understand our decision to not include actions. Thanks for your feedback! Dan Garry, Wikimedia Foundation (talk) 17:48, 28 April 2014 (UTC)

Opt-In

The text in the hovercard might be useful, but the image is not, because it takes up a lot of space and covers up too much of the article. So, even if the image displays correctly, I think it should be an opt-in.

My preference would be for the whole hovercard to be an opt-in, because I think it would encourage bad writing. Lazy Wikipedia editors would no longer explain what terms mean, and instead just rely on the hovercard. That would be unfair to people who opt out of the hovercards and also unfair to people who want to hover some of the time but not all of the time. Anythingyouwant (talk) 16:58, 24 April 2014 (UTC)

I'm afraid your point doesn't hold. How it would encourage bad writing? The hovercard extracts the first few characters from the 'existing introduction' of the article. Vibhabamba (talk) 03:18, 27 April 2014 (UTC)

I certainly understand that if we removed the image we may be able to accommodate more text. But its unclear that readers actually need and want more text. Also, Images and text both carry information in them. Many times the lead image helps clarify a concept better than text. Its also a sub optimal practice to design features where you have preferences at an element level. It creates severe maintenance overhead and makes it difficult to develop components further. Vibhabamba (talk) 02:20, 28 April 2014 (UTC)

Perhaps the positioning of the image needs to be different. I appreciate the experimentation with putting the image top first (not sure how it decides between top and side positioning). But personally, I like the positioning on the side a lot better. Inside the text, i'm reading so when I hover a textual link, i'm not looking for pictures, i'm looking for explanation about the topic. With the image on top layout, i then need to move my eyes, look for where the text starts and startup reading again. It's a lot more work for my eyes. —TheDJ (Not WMF) (talk • contribs) 10:16, 28 April 2014 (UTC)

TheDJ: The difference between top/side is image-dimensions: landscape vs portrait.

I'd second the recommendation for putting the text on top, with landscape images. That should solve most of the frustration, in this thread and Include an opt-out for images? below. –Quiddity (talk) 21:01, 28 April 2014 (UTC)

TheDJ: The feedback about the image getting in the way of the text is fair. Not sure that moving the image below the text will work, let me think about this a little bit. Vibhabamba (talk) 07:08, 29 April 2014 (UTC)