Topic on Talk:Page Previews/Flow

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: 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: 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: *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.

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!

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.?