Topic on Talk:Page Previews/Flow

Does the plan for deployment of this feature include getting community consensus in advance?

I ask because I was considering starting a discussion on this at the English Wikipedia, but I don't want to mess up anything if someone with more involved here was planning to do it. If it's not planned, I'd also like to avoid a situation of this being started too early, causing discussion to circulate around remaining major bugs, instead of the real merits and issues of the feature as a whole.

In my experience, these kinds of discussions are far easier to have in advance of deployment, as the community atmosphere tends to be not at all conducive to calm discussion regarding the pros and cons of a change, when the discussion starts following a major change being pushed forward without sufficient discussion and consensus.

(See for example the enwiki discussions regarding the watchlist bolding, in which the same community reacted in two polar opposite ways to the same proposal, when first given the opportunity to discuss the proposal in advance (enthusiastic response) and when reacting to its unexpected implementation (about as angry as that community gets, strong "kill it with fire" attitude).)

Since the development seems still ongoing, and it looks like it might get a deployment date set independently by the developers, the discussion would probably be regarding whether, once the deployment date arrives, to keep the feature or disable it (either by Phabricator request or direct disabling).

However, I ask that you please consider simply not having a set "deployment" date at all, and have Hovercards as an available feature to be enabled upon request, once development has progressed far enough (marked "stable"). While discussion will probably successfully propagate to a number of wikis in either case, many will still be caught off-guard if an non-consensus-backed deployment is implemented. Communities in that situation tend to be more likely to respond with a "shut it down first, then we can discuss it" attitude, and it's generally much harder to get consensus for re-enabling a disabled feature than it is to get consensus for turning it on in the first place. Discussion in advance allows for useful feedback and suggestions, and allows for a much less contention between the communities and developers.

I am willing to help out in whatever way would be useful.

The development is sort of on hold, since there are no real developers allocated to it right now. There is also no plan for deployment at this time, but if communities request it, it can maybe be raised on the list of priorities.

Any help is appreciated. Pinging @Prtksxna as one of the primary developers of this feature.

Also: List of known issues.

Oh.

I was confused by some of the Phabricator tickets, which gave me the impression that deployment was soon. My mistake.

Not as far as I'm aware, but stuff changes so often that I might be mistaken of course.

I've had this extensions enabled for what seems ages by now. Occasionally the hovercard fails to disappear properly, but this happens rarely enough that I wouldn't really consider it a reason not to deploy it. It's a bit sad that so many people have to miss out on this feature.

@Jkatz (WMF): Do you know what the status of this feature is?

Seconded. I personally really like hovercards (despite the annoying getting stuck bug, which still appears more often than I'd like it to) and I think they make UX nicer. It should be tested, of course, whether users really use them (by e.g. measuring the time between appearance and disappearance of the card - are people even pausing to read?) and whether there is any notable A/B difference in people's behaviour with/without the hovercards.

Good comments. I was not aware that the bugs are still appearing. where you aware of this?

"We" (I was not a part of the project then) tested out on 2 smaller wikis for a month and collected results in mid-2015-- while the qualitative feedback was overwhelmingly positive (still need to post those results), I did the timing analysis and it was not ideal--something like ~1.5 as the median time spent.

On Android, we know people like it because they end up clicking on more links, and the timing is more like 5 secs. However, there is more info in the android previews and you have to click to close it, so I would estimate that 3 seconds for a hover would be ideal.

As a result, we increased the amount of time you have to hover before the card appears, but have not re-run the test.

We have not run an a/b test, yet because we can't track sessions yet (due to our privacy concerns it will be much harder to implement). Additionally, it would be hard to evaluate the results: With hovercards, you expect fewer pageviews per session and even faster/shorter sessions--but you expect the same if someone is having a bad time. Return rate would be a good indicator, but we are unable to track that for same reason as above. Any thoughts on how to measure success?

Perhaps a less fine-grained metric will do: currently 45,035 users have opted-in to Hovercards, do you know the number of users that opted-in at some point and then opted-out again?

@SSneg here is a list of tasks that continue to 'block' the feature being released: https://phabricator.wikimedia.org/T70860 1-3 of them have easy fixes, and a bunch of them are just hard for us to reproduce--meaning they might not be valid. There is nothing here that is a widespread, significant problem, as far as I can see.

Thanks @Yair rand for starting this thread and @Ruud Koot for pinging me!

This is a very timely discussion! As @TheDJ pointed out, hovercards have suffered from not having empowered ownership within the foundation for sometime. But it is a great product that keeps on getting better. During Quarterly planning for the next quarter, it was highlighted as a great win for Wikipedia and a top contender for our team to focus on next quarter, provided we have community approval and are able to iron out any remaining, reasonable and significant concerns.

I would very much like to start a discussion as soon as possible about potentially moving forward on rolling hovercards out on 1-n wikis starting sometime in the April-June quarter. I actually fired up this page to see the existing state of discussion in order to figure out how to do this, when I saw your post yesterday! I am unfortunately in meetings quite a bit and did not have a chance to respond until now.

Our goal on reading team is to experiment with bringing the community in at the very beginning of the ideaion process (what are the problems we should solve for readers? what are the high-level solution types), but with products that are already in the pipeline like hovercards we are already too late for that.

Howevere are not too late to have an open discussion about the feature and what the potential blockers for roll-out are (whether they be permanent or temporary).

My question for everyone on this thread is, what do you think the best approaches to such a discussion should be? A proposal, an open comment period? Prior to any discussion, I would like to post the results of our test-rollouts on Greek and Catalan Wikipedias for a month in 2015 and summarize the existing concerns. If anyone would like to run point on this (and provide a more neutral view), I would be more than happy to provide the materials. Thanks again--I really appreciate the proactive communication.

I think the best way to go about this would be if a community member (e.g. @Yair rand) would make an honest case on the Village Pump on why this feature should be promoted from an opt-in beta feature to an opt-out one. Ask for people's general opinion on this issue, whether they think a formal RfC is necessary at a later date or not, whether they see any show-stopping issues at the moment. Some of the developers could help answer some of the questions that would undoubtedly be raised.

The developers of course must have the time to actually finish and deploy this if people are positive about it, but if that would take a few more weeks afterwards then that wouldn't necessarily be a huge problem either.

I could write it up as a proposal on VPR. I'm not quite sure of what stage of development the feature is at, though. Are there any bugs serious enough that it would be reasonable to state in advance of discussion that they would be blockers to deployment? Some in the community might make their own suggestions for bugs to be considered blockers, but it would probably be helpful to get the most serious ones out of the way beforehand (assuming there are any remaining serious bugs). Some editors will probably have their own suggestions for some changes. In any case, it would probably be best to make it clear that it's not a proposal for immediate deployment, and that community input can result in tweaks/fixes as necessary. Also, just to be clear, if this does get implemented/enabled by default, can we expect it to be maintained long-term? Being implemented as an extension (as opposed to a gadget or similar) means that the community can't easily do "direct" fixes as necessary, which might make some a little uneasy.

@Jkatz (WMF): Are you planning to post the test-rollouts-results and summary to this page (Hovercards)?

(As a side note, are there any good recent English-language screenshots of Hovercards? I haven't been able to find any.)

@Yair rand: I've made a screenshot.

Here's one I've just made for you, though there are other examples available in Category: Wikimedia Hovercards

@Yair rand Hey, thanks for taking the lead on this! As far as the survey goes, I posted the results here: Beta Features/Hovercards#Qualtrics Survey Results. I can't post the file because individual answers haven't been vetted for personally-indentifiable information. Let me know if this helps!

As I mentioned in an above response to someone else, all blocking bugs are listed here: https://phabricator.wikimedia.org/T70860 Though there are a number of bugs, most look to be very uncommon. One issue: our engineers do not tend to use Windows (we have devices in office, but most of the web team is remote) so if there are any community member coders out there who want to tackle the windows bugs, that would be really helpful.

@Yair rand Hey, just wondering if you had a time frame in mind for bringing this up more broadly. As I may have mentioned, the team is considering making this their goal for Q4 (April-June), but only if the various communities want it.

On my end, I am working on the blocking bug list, as a few more need to be added. I know it is tricky to ask for feedback before the bugs are all fixed, but it will definitely help us prioritize fixing them!

@SSneg @Ruud Koot @Parkywiki @TheDJ

Hi! Before the WMF Reading Team commits to finishing and shipping hovercards in the next 3 months to at least a few wikis, I really do want to make sure there is community desire for this.

@Yair rand had offered to reach out and figure this out, but seems to be busy on other things (no judgement!). So I just wanted to reach out and see if anyone else wanted to partner with me to gather input on hovercards. @Alsee spearheaded an RFC for gathering feedback for related pages and this should launch soon. I am not sure that is the method to use here, but this level of cooperation between WMF and community intuitively feels like the right thing to be trying.

Anyone want to propose something or setup a call/IRC chat to talk through ideas?

Hey @Risker I know you are in high demand and incredibly busy, but I was wondering if you could weigh in on the above (the comment just above this is a rough summary of the issue). Below I was writing to someone else about how the most important expertise I am seeking is expertise in community decision-making, and your name flew into my brain immediately. No worries if you don't have time and hope you're doing well!

@Jkatz (WMF) If you have a questionnaire or any other material that can be translated into Russian, I can share that on the RuWiki and see what people say.

Thanks! That will definitely come in handy. I will let you know when we figure out the format.

@Jkatz (WMF) I'm probably not technically experienced enough to help gather feedback across a broad spectrum of users. I'm happy to ask for views from a couple of the Wiki Projects I'm involve with, if this helps, or to select a few at random and pose questions. Happy to ask @Victuallers for his advice/input. (Far more experienced than me) Just let me know how an ordinary editor like me can help.

One interesting thought: Are Hovercards notable enough now by their coverage in third party news site to merit a Wikipedia page of their own? And could this help?

@Parkywiki

1. I don't think technical experience here is as important as community decision-making experience, but I both get your reluctance to initiate with the universe and appreciate your willingness to reach out to folks. I think we should keep that in our back pocket for now and maybe circle back--I expect reaching out on the Wiki Projects will be helpful once we have a place for people to chime in publicly.
2. Re: notability. I am not sure if it is notable enough (I'm still a relative noob). A quick search showed that there are about 5 articles on respected tech websites that mention hovercards, but generally in the context of 'beta features'. Maybe 'Wikipedia beta features' would deserve the page then. Either way, my guess is that notability is not going to be a factor in community decision-making.

OK - Provided someone can create the most appropriate place for discussion, I'm certainly happy to promote it if I can. To that end I've just made a rather gaudy Userbox which users can put on their talk page to show support for rollout from beta.

Not sure it will help much, but it seemed a fun way to promote it on EN:WP! I'm also not sure of the correct way to link to it in this wiki, so it's either this:{{User:Parkywiki/Userboxes/hovercards}}

or this as the full url: https://en.wikipedia.org/wiki/User:Parkywiki/Userboxes/hovercards

@Jkatz (WMF), Ruud Koot: Sorry for the delay. I've started a proposal at w:WP:VPR#Proposal:_Enable_Hovercards_by_default. I've also listed the thread on Centralized discussion.

Excellent @Yair rand! Thanks a ton. I encourage everyone to go and chime in with your thoughts and concerns.

@SSneg Can we take you up on your offer to take the current proposal (above) and translate/post on Russian?

Ok!

@Jkatz (WMF), I posted this for discussion a while ago, these are the votes and comments so far:

• FOR (me)
• AGAINST (I prefer WP:Tools/Navigation popups, which are more informative)
• FOR
• FOR (The Navigation popups is useful for editors not readers and looks horrible as well)
• AGAINST due to extra slow-down of website performance but if the proposal goes through, no worries, I will just disable it
• AGAINST as long as template lang-xx is broken, otherwise FOR
• FOR
• FOR, one of the most useful beta features, haters can disable
• FOR, but please fix template lang-xx issue first
• AGAINST, prefer the Navigation popups

@SSneg This is great. Looks like its mostly positive. 2 concerns are that

1. nav popups will be disabled (they wont)
2. template lang-xx issue

Does anybody know what the template lang-xx issue is?

nevermind...found it here: https://phabricator.wikimedia.org/T115817