Talk:Beta Features/Hovercards/Archive 1

Comments around actions and read more would help our current line of thinking. General Feedback welcome.

Animation

Something like http://daneden.github.io/animate.css/ fadeInUp for entrance and fadeOut (but much faster) would be nice. Jaredzimmerman (WMF) (talk) 23:55, 22 January 2014 (UTC)

Please see the changes made in Add animation to NavigationPopups. Ping me if you'd like to see a demo to fine tune the delays. --Prtksxna (talk) 05:00, 6 February 2014 (UTC)

I quite like the fadeInUp/Out animation - that, combined with the placement of the hovercard, help establish which link it was that triggered the feature. (Re: placement. There's Hovercards, which always line up with the link that triggered it; and there's Navpops, which align with exactly where the mouse-cursor came to rest on the link. Interesting difference, and I think I prefer the current Hovercards system, though would need to use it for a while in action before finding out the pros and cons.) –Quiddity (talk) 03:51, 26 February 2014 (UTC)

Actions in popups

Pros

• Direct access to some actions, like watch, talk, history (feels like very advanced user actionsJaredzimmerman (WMF) (talk) 23:55, 22 January 2014 (UTC)
• Access to "read it later/next" type action (same or different than watchlist?)Jaredzimmerman (WMF) (talk) 23:55, 22 January 2014 (UTC)

Cons

• Fitt's Law don't suggest a second target like "read more…" that goes to the same place as the link that is directly under your cursorJaredzimmerman (WMF) (talk) 23:55, 22 January 2014 (UTC)
• Having additional targets inside flyout means that it is on screen longer, and not dismissed when cursor moves out of the bounds of the link, this could distract from the reading experience. Jaredzimmerman (WMF) (talk) 23:55, 22 January 2014 (UTC)
• Having a smaller clickable target within another one might be confusing. -Prtksxna (talk) 05:02, 6 February 2014 (UTC)

Priority of popups to roll out

1. Articles
2. …
3. …

Have some code

Just saw this in the recent changes. Please take a look at w:User:Yair rand/NavPopupsRestyled.js. Still probably quite buggy, but it seems to cover all the stuff mentioned here.

I strongly recommend not trying to force this on any community, by the way. If you think it should be enabled by default, propose it at a village pump. --Yair rand (talk) 13:32, 23 January 2014 (UTC)

Thanks Yair. My understanding is that we plan to enable this as a Beta Feature at first, which is opt-in. Steven Walling (WMF) • talk 19:49, 23 January 2014 (UTC)

Thanks for the pointer Yair, I've shared your link this with Prateek Saxena, who is working on building this beta experiment. Vibhabamba (talk) 23:07, 23 January 2014 (UTC)

Yair, I tried importing this on enwiki but it doesn't seem to work for me (importScript('User:Yair rand/NavPopupsRestyled.js');) in Vector.js). Am I missing something?--Jorm (WMF) (talk) 00:06, 24 January 2014 (UTC)

Jorm (WMF) You may need to also have the regular Navigation Popups enabled. Steven Walling (WMF) • talk 06:54, 24 January 2014 (UTC)

I do.--Jorm (WMF) (talk) 07:46, 24 January 2014 (UTC)

@Steven (WMF): Actually, that's not required at all. Code-wise, the new script is completely unrelated to the original NavPopups. --Yair rand (talk) 10:11, 26 January 2014 (UTC)

@Jorm (WMF): Skin js pages are lowercase. w:User:Jorm (WMF)/Vector.js should be at w:User:Jorm (WMF)/vector.js. --Yair rand (talk) 10:11, 26 January 2014 (UTC)

Prateek just ran your scripts and sent me the screenshots, It looks really close. Really appreciate the work. Thank you. Vibhabamba (talk) 00:08, 24 January 2014 (UTC)

A few minor issues of ambiguity in the design:

• The colors of the "last edited" text is different in different pictures. I coded it on the assumption that the color is related to the amount of time since the last edit, with grey being the color for everything edited more than 48 hours ago. I don't really know if that's what was intended, though...

that's exactly it, although our threshold is 24 hours. Older than 24 hours is grey, The green color value according to our style guide is - 00AF89. See - https://www.mediawiki.org/wiki/File:Guide_Color.png Vibhabamba (talk) 01:24, 5 February 2014 (UTC)

• When the hovered link is very near the right side of the page, it's not clear what the best behavior for the popup would be, if part of it would overflow past the right side of the screen. Should it be flipped to the left, with the arrow at the right? Pressed against the side of the page, with the arrow in the middle-ish?

The popup should never bleed outside the viewport. So if its under the fold or bleeding right/left of the screen edge, it should flip. Vibhabamba (talk) 01:24, 5 February 2014 (UTC)

I was implementing and testing this when I noticed that in some situations it gets cut at the bottom. Its too long even if its flipped to the top. Any ideas? --Prtksxna (talk) 05:19, 6 February 2014 (UTC)

• The light-blue background of the link in the images extends several pixels outside the link. Is this supposed to be like that?

The blue highlight was for presentation purposes only. We don't need the highlight in the product if the pokey positioning works out. Vibhabamba (talk) 01:24, 5 February 2014 (UTC)

--Yair rand (talk) 15:42, 30 January 2014 (UTC)

Do we need a way to open article in a new tab/ new window

Currently clicking on a blue link in a Wikipedia article has target url = same window, so you can't continue to read your current article if you want to investigate something you came across. There's mixed opinions on whether this functionality is needed or if we should simply rely on users using their right click menu. Of course my old parents use wikipedia and do not know how to use right click menu's. So if we are concerned about accessibility and tech saviness, we should discuss solutions. Please insert ideas! Vibhabamba (talk) 01:59, 24 January 2014 (UTC)

No, we don't need to add that functionality. It's just going to be clutter. People can right click or ctrl/command click and let it happen. It's not our job to solve for our users' ignorance of how to use their browser.--Jorm (WMF) (talk) 02:10, 24 January 2014 (UTC)

Agreed. Middle-click, or right/ctrl/command-click, are all fairly widely known, for users that use multiple tabs/windows. Additionally, choosing whether to force a new tab vs window, is difficult (I know 2 people IRL who hate tabs, and I would guess they are representative of a quiet minority?). –Quiddity (talk) 18:47, 24 January 2014 (UTC)

I've made the complete popup an anchor tag (within a container) so a user will be able to do normal link actions on it. --Prtksxna (talk) 05:04, 6 February 2014 (UTC)

Some comments on the first Iteration

I've looked through the slides on this feature and they really excite me! I use the Navigation Popup tool enabled in the preferences 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 dissapear. 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) 03:06, 18 February 2014 (UTC)

Integration with Navigation Popups (and reference tooltips)

Re: "How does this integrate (or not) with the existing navigation popups and reference tooltips?"

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:

1. For readers: A simple version, which the current Hovercard prototypes are getting close to, and which merges Reference tooltips.
2. 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:
   • Recursive popups
   • Powerful per-user configuration options
   • Detailed metadata
   • Easy access to most, if not all of the Actions that navpop currently includes.
3. For both: An "off" toggle, because some people hate them!

Hope that helps. –Quiddity (talk) 04:25, 26 February 2014 (UTC)

Ideal timings for show and hide

The gadget navpopups has a default timing of 0.5 seconds, for both In and Out.

It is user-customizable, and I personally change it to 0.3 seconds.

If we search Enwiki for the parameter name, we see up to 740 users appear to have tweaked their settings, with a wide-range of figures, from 0 to 10 seconds. (It might be good to analyze those customizations for patterns?)

Per the section above, I'd like the same abilities with this extension. 0.5 seconds is a reasonable Default, but users like to customize. –Quiddity (talk) 04:28, 26 February 2014 (UTC)

Ideal length of excerpt

WP:NAVPOP's length is controlled by a user-customizable variable (popupMaxPreviewCharacters); the default is 600 characters.

Afaik, the length in Hovercards is currently defined as "Truncate at 250 characters with complete words [ending with ellipse if no final punctuation exists]". Given the larger font and image (which I like :-) that seems a reasonable default. However it would be good to have this as another user-customizable variable.

(Tangentially, I made a list at m:Concise Wikipedia#A summary of existing short-options, using an example, of the various "excerpt lengths" that we have.)

HTH. –Quiddity (talk) 08:18, 26 February 2014 (UTC)

Some comments from a navpopups dev

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.

Good luck TheDJ (talk) 10:06, 17 March 2014 (UTC)

Use of last uploaded image for users

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.

I'd be interested in hearing your thoughts. Sven Manguard (talk) 21:10, 17 March 2014 (UTC)

Ping for copying feedback

Hi Nicereddy, TheDJ, and Sven Manguard. I just wanted to ping you, and suggest that you copy your comment from this archive, into the newly flow-enabled talkpage. I'm going to do so with my own feedback, after other people (such as yourselves) have had a chance to get the first word in. :) Thanks. –Quiddity (talk) 23:58, 20 March 2014 (UTC)

@Quiddity: Apologies for replying, as I realize we're not technically supposed to do that seeing as this is an archive. However, I figured I'd link to the new Flow page for the sake of convenience of others. Talk:Beta Features/Hovercards --Nicereddy (talk) 01:52, 21 March 2014 (UTC)