Talk:Beta Features/Hovercards

Jump to: navigation, search

About this board

Not editable

The Hovercards beta feature solves the core problem of users opening multiple tabs to gain an understanding of a word in the context of the subject they are reading. Whenever a reader hovers over a link to another article, a short summary of the subject, including its graphical image, is provided to them so they can decide whether they need to visit that subject more fully before continuing the current subject.

Please give us feedback on your experience using this beta feature so we can change and improve it. Each language is welcome in this discussion!

You can read more about the feature here.

Known Issues

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

The rollout plan, and clarification on how the community interprets consensus

Alsee (talkcontribs)

There is a rollout plan in progress(?!) but the only community consensus on it was quite opposed to default-on deployment.

Perhaps this was unclear because the close was written as "No Consensus" (to enable) rather than "Consensus against". This is not unusual when the effect is expected to be essentially the same. Often language like "no consensus (for a proposal)" is used to more openly invite a new discussion, if anyone feels it may lead to a different result. (Either because changes have been made, or because circumstances have changed, or because someone wants to bring new information or arguments to the table, or becomes someone simply thinks that views on the subject may have shifted over time.)

The WMF may be able to (cautiously) go forwards with a project in a genuine non-consensus situation, where the results were close and other factors might support it. However in this case the closer cited a fuzzy&incomplete vote ratio of about 3-to-1 against, and the closer noted that factors other than raw vote count don't lean in the support direction. My generous/optimistic interpretation would put the result at about 2-to-1 opposed. This is important, the RFC topic was "Proposal: Enable Hovercards by default" and there was "no consensus" to take that action. However imagine we rewrote the RFC question as "Proposal: Disable Hovercards". Imagine everyone responded the same way they did the first time. That same 2-to-1 result would pretty well constitute a consensus to disable. Therefore the "No consensus to enable" is effectively a "Consensus against enabling". It was just phrased to be more friendly if you want to try raising the topic again. (Or maybe the closer always uses "no consensus" language to summarize any failed proposal.)

I didn't participate in that RFC, but I'd like to offer my experience with Hovercards. It sounds like a great idea, and I actively tried to help the project along. I hate how often the WMF&community get into conflict and I really wanted to help a project succeed. I enabled Hovercards and played with it, and it seemed great and useful. "Neat, I can get a preview whenever I want". Then I stopped playing with it and when back to normal. Over the next few days it became clear that I was never actually using Hovercards. In fact it became increasingly annoying to have unwanted popups randomly blocking my ability to read the current page. The longer I left Hovercards enabled, the more frustrating it became to have my view repeatedly and randomly blocked by popups. Hovercards are a great idea in theory - you get preview when you want it. In practice, for me at least, ~100% of the popups turned out to be unwanted and frustrating.

Hovercards are a love-it or hate-it feature. I know your survey got pretty positive numbers, but I have to wonder if some of that positive feedback was like mine... that Hovercards only seem great on first impression when you're actively playing with it. Even if a majority of people do like Hovercards, even if you try to make them easy to disable, I think too many people will get pissed off. This is especially critical for logged out users. They'll get really pissed off repeatedly trying to shut off Hovercards every week or every month or whatever. If there is another RFC then I'll have to regretfully oppose any enabled-by-default.

CKoerner (WMF) (talkcontribs)

Hey Alsee, when you say community are you referring specifically to the English Wikipedia? I'm assuming so in my response.

Beta Features/Hovercards#Rollout Plan shows there's no check mark for the English Wikipedia. We have not approached that community since the RfC to address the concerns raised. However, a quick look at that RfC I can see that most of the more egregious issues are addressed with our plans.

  1. Editors are opt-in. They won't get the feature enabled by default.
  2. Non-logged in folks can opt-out. There's a preference they can set without logging in to disable the feature.
  3. The big bugs have been addressed (and many smaller ones). Especially Page Previews getting stuck - the most frustrating of all if you take a look at the talk page here :)
  4. There were concerns around user experience. The research and feedback received during A/B tests address if folks understand the feature and how to disable/enable.

This also doesn't mention the qualitative and quantitative research the team's done since the English Wikipedia RfC to investigate if Page Previews negatively impact things like page views, performance, and fundraising. Spoiler alert! Nothing strongly negative was discovered. :)

As you described in great detail, the RfC did not obtain consensus. Like we've done for the 4 communities we have already approached, we state our intent for the feature, reference our rational and research, provide the community time to respond with questions and concerns, and then hopefully move forward if there no outstanding issues. The same will apply with the English Wikipedia.

Really, now that I'm looking over the RfC a little more I think the latter part of Jon Katz's descriptions of the next steps in the RfC are pretty much what I've described above!

I hope that alleviates some of your concerns. Thank you for taking the time to investigate and greet us here with the information and feedback you've provided. I appreciate it.

CKoerner (WMF) (talkcontribs)

Oh, and another thing we haven't mentioned yet. The new refactored version of Page Previews will arrive (as the current opt-in Beta Feature) next Thursday (23 February) if things go to plan. We should have a message out to the wikitech-l maling list tomorrow. Having the updated code in the Beta feature allows communities use the feature and provide feedback as we approach them.

I hope you (and others reading) will give the feature another try when the updated code arrives and provide feedback on performance, bugs, and what not.

Alsee (talkcontribs)

@CKoerner (WMF) thanx. And yep, I was referring to the (linked) English discussion on it.

Like we've done for the 4 communities we have already approached, we state our intent for the feature, reference our rational and research, provide the community time to respond with questions and concerns, and then hopefully move forward if there no outstanding issues.

Three :) and I see you're going back for #4.

However I'd like to point out a common pattern. Stuff gets pushed out to small wikis because they don't/can't effectively participate. English Wiki shares a common language with the WMF. English is the oldest, largest, most established, and most engaged Wiki. Some of the the other large wikis have a well developed central community and sometimes engage, but it often takes a pretty big issue for them to climb over the language barrier to effectively participate. This is amplified when WMF postings tend to come across as "announcements". On EnWiki there was a "Proposal to enable Hovercards". It was posted as an RFC for a meaningful examination of consensus. I used machine translation to look at the other four wiki postings. You posted the A/B results, you stated that you want to enable Hovercards, you invited feedback, and you announced that you intend to deploy it unless you see serious problems. That got almost no participation. It was not treated as a significant discussion, much less a consensus process. For example on Russian Wiki it looks like two people posted clearly supportive comments, one person explicitly tried to cast an oppose , and I think another badly-translated response is a second oppose !vote. There was negligible participation (2 vs 2), and no attempt to form any kind of consensus because it was just an announcement. People aren't likely to turn on a beta feature and seriously investigate the issue just to post a throw-away comment after an announcement.

Let's put it this way. Let's say other major wikis do seriously examine Hovercards, with consensus in favor. That would suggest that maybe EnWiki got it wrong for some reason, and consistency across wikis is a reasonable factor to weigh. That would make a strong case for reconsideration of the EnWiki position. Now let's flip it the other way. English is almost half of our global community, and let's say a few other other major wikis agree with the EnWiki consensus. I think that would make a seriously strong case that the WMF shouldn't push a product out to the smaller wikis that can't/don't effectively participate. If wikis representing a majority of the global community consider it a problem then it's safe to conclude that it would be a problem for small wikis too. And again, consistency itself is a factor to weigh. Tiny wikis shouldn't have weird random configuration differences without a really good reason. A lot of people visit more than one wiki. It's undesirable for things to randomly appear or disappear.

It's a bad idea to do these bottom-up deployments, especially when there's a known problem. Micro wikis never reject anything, but that means they never accept anything either. The last thing you want is to deploy something to 200+ micro wikis that never speak up, then reach to the top few wikis and discover that the whole global community sees a problem with it.

I strongly urge RFCs on the other top wikis before the "deploy everywhere" step.

Alsee (talkcontribs)

@CKoerner (WMF), I'm correcting myself. I mentioned a Russian discussion above, but I now see there were two discussions. The earlier discussion, which I missed, was posted as a question and it did get a meaningful discussion. (It was small by EnWiki standards, but reasonable in proportion to community size.) It looks like it was mostly positive.

I was particularly concerned when it looked like nowhere had really asked for Hovercards. I have no complaints about deployment to Russia. That reduces, but does not eliminate, my concern for the interests of other wikis. It looks like we basically have a small positive result at RuWiki, and a large negative result at EnWiki. Is there anything additional to indicate that silent wikis want it? (I'm trying to objectively evaluate the good-faith expectation, if they actively voiced their interests.)

CKoerner (WMF) (talkcontribs)

One small correction.

  1. Catalan
  2. Greek
  3. Russian
  4. Italian

4, but who's counting. :)

I want to make sure I understand your suggestion. Are you suggesting to start deployments of features with the largest, most active, most vocal communities? Is that correct?

The near default method of deployment for software by the Foundation has been to start with smaller - and smaller interested communities - then build up to the bigger projects. It has many advantages - eager communities are more likely to adopt new things, working with smaller communities and discovering bugs - that don't mess with bigger projects! That sort of thing. With bigger projects - more people, more eyes - the alarm is often louder when things do break! :)

I see what you mean that these larger communities are more active - in articles, edits, page views, etc. I'd be curious to see numbers of percentages between say page views, active contributors and edits to the Project: namespace. That might be one way to amplify your claim, if I understand it correctly, that larger wikis would catch problems quicker/better than smaller projects.

Rereading your comment, this sounds a little like you're advocating for the smaller wiki's because "English Wikipedia knows better". That seems a little dangerous. I don't want to speak for communities I'm not familiar with, but I'm not sure they'd be comfortable - formally or not - with English Wikipedia leading decision making on what features their communities should consider. But then again, maybe they'd like a leg up? Something to consider.

>Tiny wikis shouldn't have weird random configuration differences without a really good reason

Of course. If you have an issue with the methodologies used and don't believe the work of the team was done with good reason, please explain them so we can improve.

It's not called out in our roadmap, but we are sending a notice to the Village Pump of communities in Phase 1. I have a draft of a short version and we're considering reusing the same announcement for the communities we have reached out to as well.

>It's undesirable for things to randomly appear or disappear.

Agreed, which is why we are approaching each community early, to the best of our ability, notifying them in an appropriate (most appropriate?) venue and giving them time to discuss.

>I strongly urge RFCs on the other top wikis before the "deploy everywhere" step.

You are more familiar with the RfC process than I. :)

CKoerner (WMF) (talkcontribs)

Re-reading my reply I hope I'm not coming across as disparaging. I think the conundrum is that an RFC at the end of the development of a product is not a suitable replacement for early engagement with communities on changes. However, and in all honesty, this makes it sticky to talk about now as we're so far down the path for this feature. That's not to say I'm not enjoying talking about it or that it's not worth it, quite the opposite! I'm also/obviously talking to others in the team as well.

It's late where I'm at. Happy to continue the discussion with you later.

Alsee (talkcontribs)

I am delighted with your reply. The subject of WMF-community engagement is sometimes awkward.

Early input on a project is definitely critical, especially prior to build phase. It has been challenging to build that early engagement process. Trying to engage a diffuse global community is hard. I fear that arguments for inclusivity have, at times, led to an all-or-nothing trap. The valid goal of inclusivity should not undermine easiest or "reasonable effort" engagement. I hate to single out EnWiki, but it shares the WMF's language and its size and experience make it the easiest and most effective point of engagement. EnWiki alone represents forty-odd percent of the global community. EnWiki plus two other big wikis covers a majority of the community. A top-down approach can get you far, for whatever outreach is manageable.

I'm not sure (small wikis would) be comfortable - formally or not - with English Wikipedia leading decision making on what features their communities should consider.

To clarify, all communities can consider and request anything. A main concern was how silent wikis are handled.

When smaller wikis can't or don't speak up, the rest of the community is their best representative. This is basically how we already manage wikis. There are a vast number of casual editors with no knowledge or interest in community management, and lots of major editors with no interest in doing that work. The most dedicated, most experienced, and most interested community members do the work of community-wide management. Everyone is welcome to show up, and the work is done by those who show up. I think our public-service mission and our culture of consensus makes the core community pretty good at trying to serve those who didn't show up.

I very much want a better voice for other communities. I'm sure smaller wikis feel powerless and voiceless. An announcement that invites an RFC is likely to be far more effective. People volunteer to do work when they know it's meaningful. A concrete question is key. In the pre-build phase it would be great to see something like "Is this something you think you would want". Along with that you can ask for feedback on features etc. That feedback will generally be very fuzzy unless there is a focused discussion on it.

Are you suggesting to start deployments of features with the largest, most active, most vocal communities? Is that correct?

Deployment is complicated and has competing factors. It absolutely does makes sense to start small, to get bugs fixed, to get initial feedback, and make sure things don't explode :) What I am saying is that top wikis evaluate it before global-hundreds-of-wikis deployment. Bottom-up deployments are risky. It's the "path of least resistance", but that path also leads directly to the worst case scenario. The WMF wouldn't built a product unless you believe it is beneficial, so the WMF is sometimes eager to deploy that benefit to silent wikis. Everything seems to be going great, then you get to the last few wikis and suddenly a majority of the global community objects. At that point the options get bad. Trying to "finalize" the project by pushing out the last few deployments can result in a crisis. Rolling back hundreds of deployments is ugly, especially if a rollback itself is somehow disruptive. Partial deployment may or may not be viable, depending on the product. But if the wikis who do speak up are objecting to deployment, the good-faith assumption should be that the silent wikis would also object. That can make the silent deployments look bad.

If a product is expected to be optional per wiki, I'd suggest testing small, then validate whether any engaged wikis actually find it desirable before pushing it to silent wikis.

If a product is expected to be "everywhere", I'd suggest testing small then (maybe) consider jumping to the top. If a universal deployment is going to blow up, EnWiki will give you that answer. Chuckle. It's a tough call. You want the product as bugfixed and improved as possible before getting there, but it's not good for virtually half of the community to be the last ones to say it needs a major change or that there's some fundamental problem. It mostly comes back to effective early engagement to

I see what you mean that these larger communities are more active - in articles, edits, page views, etc. I'd be curious to see numbers of percentages between say page views, active contributors and edits to the Project: namespace. That might be one way to amplify your claim, if I understand it correctly, that larger wikis would catch problems quicker/better than smaller projects.

And it's not merely a question of catching an issue. People need to believe they can do something meaningful to address it. The information needs to bubble up to somewhere useful. For small wikis, the WMF is impossibly far away. They don't feel they can do anything meaningful about the software, they don't have people focusing on it. This will grow, if people see they can contribute valuable work in the area.

Probably the best and simplest thing is to just to look at the community's equivalent of Village Pump. That's where generic wiki-wide issues are handled. That should show the organisational and human resources available for arbitrary engagement. That's where people show up looking to handle generic community work, where you'd find people who would opt-in to a beta feature specifically as community-service work testing it.

CKoerner (WMF) (talkcontribs)

Hey Alsee, I see your message here, but it's late on a Friday where I'm at. Monday is a holiday, and then I'm traveling to San Francisco for some annual plan...planning the rest of the week. I wanted to let you know I hear ya, I'll think on this, and get back to you when I have a moment.

Alsee (talkcontribs)

I'll ping the closer, Dank, in case they would like to agree or disagree with my comments regarding their close. My "optimistic 2-to-1 opposed" was based on the initial 7 responses that you didn't include in your tally, as well as assuming that bugfixes or other improvements converted mixed-votes into supports.

Dank (talkcontribs)

Alsee, I was following a random link to meta today and found out you pinged me 3 days ago here ... Generally, I only get pings left on en.wp. Reading quickly, it looks like the hovercard feature will not be enabled by default for registered en.wp users, which (for them) is in line with those RfC results. For unregistered users ... I'm not sure what I think, let me ask around. As soon as I have something, I'll ping you on en.wp.


Enable Previews link on every wikipage?

Alsee (talkcontribs)

I understand that you want the options to be easily available, but should we really start piling various preference options direction onto every page?

During Hovercards discussions, several people suggested it might be a good idea to upgrade the preferences system. The preference system could potentially be higher profile, and it could be re-worked to be more friendly to readers. Perhaps the initial preference page would focus on items intended for readers.

How about keeping "Enable Previews" within preferences, with the preferences system itself considered for future examination?

Hovercards don't show the section of a page that the link specifies

Summary by Edwardj 123

There are many articles containing hyperlinks that go to a specific section of a page when clicked because the other content isn't relevant, so users typically read this content first to understand the topic referenced. The Page Previews/Hovercards feature currently only previews the first section introducing the whole article, which some users would like changed so they can read a summary of the specific section that an article references.

Gluons12 (talkcontribs)

Often, there are links that point to a specific section of a page, but the hovercards always preview only the lead section. Is that by design, or is there work going on so that it previews individual sections as well?

CKoerner (WMF) (talkcontribs)

This is by design, but section previews would be an interesting feature. Pinging @OVasileva (WMF) to share your thoughts with the product owner. :)

Edwardj 123 (talkcontribs)

The Page Previews/Hovercards feature was designed to do that - it's meant to show previews of articles, with the main introduction content only. Showing a specific section seems worthwhile though if the link specifies it as a link anchor (using a fragment identifier) so clicking the link will jump to that part of the page. In that case, a summary/introduction to that part would be useful. I think this functionality has been mentioned before but I don't know how much work has been done for it.

OVasileva (WMF) (talkcontribs)

Hi - we haven't done any work on this functionality so far, but currently it is in our list of tentative improvements for the feature after initial rollout - you can look over the highlights of the list here. Also - if you have any ideas for other future improvements, we are tracking them in the "Hovercards Pt 2" page in phabricator.

Brackets () in chemical formula breaks it

DePiep (talkcontribs)

So Hovercards removes anything between and including () brackets. OK. However, when a chemical formula is presented with brackets, is gets broken into nonsense. Example in case: en:RDX has opening line:

RDX is the organic compound with the formula (O2NNCH2)3.

In Hovercards it shows:

RDX is the organic compound with the formula3.

(A space has gone too btw). Any solution, here or in the article? Adding:

en:4-Phenyl-4-(1-piperidinyl)cyclohexanol has brackets in the titleword, resulting in Hovercards:
Nihiltres (talkcontribs)

Probably worth mentioning at T91344 or elsewhere on the TextExtracts workboard.

It's probably also worth looking into if the <chem> markup could work with Hovercards (don't know offhand)—even if it's currently borked, making an exception to render chemical formulas that use the tag would probably be easier than tweaking broad code related to removing parenthetical content.

Personally, I think the responsible thing's to disable the removal of parenthetical content, and certain bits of HTML (in your example the remaining "3" gets unwrapped from its <sub> element), until that can be done reliably—there are too many edge cases like this where meaning is broken by aggressively simplifying the code.

OVasileva (WMF) (talkcontribs)

Hi - thanks @DePiep for pointing this out. Currently the issue is with most HTML. We're tracking it here, but let us know if there's any edge cases that we might be missing.

DePiep (talkcontribs)

The tracking OVasileva (WMF) mentions covers this well. It already says 'mathematical'. Maybe Unicode has other () brackets with math semantics (i.e., "use U+9xxy, U+9xxz pair to denote math () brackets"). No need to disable the function for this minor issue. imo, close-able.

Os cartões flutuantes poderiam mostrar outra coisa além da introdução

Novato10 (talkcontribs)

Não há nada que dê para mostrar na introdução, sendo que a maioria dos artigos não tem

CKoerner (WMF) (talkcontribs)

Você poderia dar um exemplo?

Novato10 (talkcontribs)

Sim, em Wikicionário aparece ...

Disable hover card focus-ability

2 (talkcontribs)

The hover card does not need to take focus from the mouse cursor: if you want to enter the target, the cursor is *already on the wiki-link*; the only reason to move is if you *dont* want it.

If the cards didn't focus , they wouldn't be obstructive .. you could flick the cursor through the text rapidly, *and* benefit from the previews.

Could you enable this behaviour as an option so we can at least try it out?

FriedhelmW (talkcontribs)

The card does not take the focus. Pressing a cursor key scrolls the window.

to dobra funkcja (Polish to English translation: "it's a good feature")

Multimat12 (talkcontribs)

kto się zgadza?

Hovercard won't disappear

Icebob99 (talkcontribs)

Hi, I love the hovercards feature! Sometimes, though, when I mouse over a hovercard, it pops up, I read it, I move my mouse away, and the card doesn't go away. I can sometimes get rid of it by remousing over that wikilink or another link, but more often than not, the card will momentarily disappear and then reappear. Sometimes I can scroll up or down to get rid of it. My OS is the ChromeOS on a Toshiba Chromebook. Here's the system info: Version 56.0.2924.58 beta (64-bit)

Platform 9000.58.0 (Official Build) beta-channel swanky

Firmware Google_Swanky.5216.238.5)

Let me know if you need anything else to try and recreate the issue. Thanks, Icebob99

CKoerner (WMF) (talkcontribs)

Thanks @Icebob99 for the note. We have a task to fix this bug and will hopefully have the update available shortly.

GuyDoodles (talkcontribs)

I have the exact same problem. The only way I've been able to fix it is by reloading completely, though.

When will Hovercards leave beta phase?

Summary by Daylen

Hovercards are currently being rolled out across Wikipedia. A full list of when hovercards will be arriving on a Wikipedia project in a specific language can be found here.

Benediktneumayr (talkcontribs)

Hi! As the title says, when will the Hovercards-feature end its beta phase? I really like it and would be very happy when it gets stable soon!

OVasileva (WMF) (talkcontribs)

Hi! Glad to hear you're excited by the feature. We're scheduling the initial rollouts right now, as well as fixing all important bugs. The rough dates for roll-outs live here.

Bavb (talkcontribs)

I just have to say that Hovercards are wonderful, i love love love them.

Benediktneumayr (talkcontribs)

Thank you for your answers!

Summary by Daylen

When a page does not have an intro section, the hovercard will notify the user that a preview is unavailable.

Daylen (talkcontribs)

Hi @OVasileva (WMF)! The hovercard appears blank if an article does not have an intro. It would be great if the hovercard automatically showed text from the first section if this is the case.

OVasileva (WMF) (talkcontribs)

Hi @Daylen - thanks for bringing this up. We are addressing this issue, but a bit differently. Since the content of the first section of a page might not present an accurate summary or representation of the page itself, we have put in a special preview type which lets users know that a preview is unavailable - a more-detailed outline of these can be found on the functionality page.