Topic on Talk:Page Previews/Flow

NOT ready to leave beta, let alone be deployed by default

7
Jason Quinn (talkcontribs)

I saw via the Tech News posting on the English Wikipedia's Village Pump that Hovercards was leaving Beta and intended to be deployed by default to logged-out users. It is not ready. I turned it on to try it again and quickly noticed the "abruptly ending text" issue, which I see below is called a "very confusing experience" by OVasileva (WMF) just a month ago, and tracked by open bug T67845 at phabricator. This is a critical hurdle to jump before leaving beta.

Secondly, I'm not convinced this feature should ever be default. My intuition is that it will severely lessen the odds a reader will become an editor. Editors are the lifeblood of the project and we are already critically starved for them. Even if this tool would decrease the new editor rate by just 10%, that's an existentially bad side-effect.

CKoerner (WMF) (talkcontribs)

Hi Jason, As TheDJ notes below, the message you saw was a sort of 'head's up' that the plans are to move Hovercards out of beta in the future.

We are tracking bugs like the one you mention and intend to address the larger known ones before moving to production.

Did you get a chance to look over the results of the recent A/B tests the team preformed? The findings were generally positive in the communities we tested with.

"My intuition is that it will severely lessen the odds a reader will become an editor."

Interesting. Why do you think Hovercards would have a negative impact in this way? Folks would be less likely to hit "Edit" due to the preview? I'm not sure I follow, but I'd appreciate any clarification you could provide. Thank you for the feedback and the attention!

Jason Quinn (talkcontribs)

Yes. I think people would be less likely to edit pages. To edit, people need to see pages to find something they want to fix. But with hover cards, it discourages people from actually opening full pages.

Let's say that a typical reader (somebody who's never edited before) reads X primary topics in a session. For example, X might equal one and the primary thing the person visited to know about is "Meteorite".

When reading the "Meteorite" article, they see the wikilinks for "bolide" and "Tunguska event", neither of which the reader knows about. Currently, they open those links to find out. Sure, they may just read the first paragraph but they may also likely glance at more and possibly the whole article. With hovercards, you'll get the two sentence'ish blurb about what it is, they'll be satisfied, and move on with reading just the "Meteorite" article. They never glanced at the "bolide" or "Tunguska event" article. So what they never saw was that the "bolide" article contained an obvious grammar mistake and the "Tunguska event" contains obvious vandalism. As fixing vandalism and grammar are both "easy on" ramps to editing, we've missed our chances for this editor to take their first critical steps.

Mathematically let's suppose viewers come to Wikipedia to learn about (on average) X "main" topics and for each main topic they end up via wikilinks fully reading Y "secondary" topics (on average of course). Now let's further suppose while reading any main or secondary topic they read Z tertiary topics (on average). These are topics I'm defining as ones that they only needed the very basics about, like a definition or single sentence description. Without hovercards, the reader would open X + Y + Z articles during their Wikipedia session. With hovercards they would only open X+Y articles (because the hovercards satisfied their curiosity for the tertiary topics). As the tertiary topics will tend to be more obscure and therefore closer to "stub class" articles there will be for them lots of room for non-expert growth because they have lower editorial quality and fewer page watchers for vandalism. So I see readers missing out on Z pages (on average) that were ripe for them to try out their first edit. I suspect that my guess that hovercards could result in a decrease of 10% (or more) in the new editor rate is at the least a plausible hypothesis.

Wish I had more time to elaborate and look up some of the needed statistics. But, unfortunately, I'm very busy with work these days and even finding 30 minutes to edit is difficult at times. I do not have the time to give a researched reply where I find the values for some of these statistics. It's of course possible my intuition is completely off. And maybe there'd be no effect or even the opposite.

TheDJ (talkcontribs)

We have 1000s of these kinds of 'critical' bugs that don't cause enough actual problems to be high priority issues. Annoying yes, confusing possibly, but blocking.. I seriously question the assertion.

"My intuition is that it will severely lessen the odds a reader will become an editor" I see no reason for that, but real life deploy would give us metrics. So my question would be, will there be metrics....

OVasileva (WMF) (talkcontribs)

Hello, yes, we will have metrics. We will follow the same schema used in the A/B tests, as well as an additional metric which will add the idea of reading depth to the schema (more info here). This will allow us to test the running hypothesis that hovercards might encourage readers to read further into an article and thus make them more likely to notice errors or potential additions within the initial article they are reading.

TheDJ (talkcontribs)

BTW. It should be mentioned that this is just the announcement for the start of this process, not an actual deploy.

Fixuture (talkcontribs)

I do not agree with Jason Quinn - I think the feature should be rolled out ASAP and is ready for that already: it's way too useful to wait for all bugs to be solved before roll-out (besides if they are expected to be fixed near-term). I also don't think that the tool will decrease the new editor rate in any significant way: Wikipedia just becomes way more useful, time-efficient and people will probably just fetch info on more articles instead of not reading/clicking them at all.

There are many other things to do that could increase the rate of new editors.

Reply to "NOT ready to leave beta, let alone be deployed by default"