Talk:Beta Features/Hovercards

Jump to: navigation, search

About this board

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 "Settings" and "Last Edited" seem unnecessary

7
Bush6984 (talkcontribs)

Upon hover, the hovercard display of content seems great, but it seems unnecessary clutter that the settings "gear/wheel" and "Last edited X days ago" display. Those could be gotten rid of, on account that very few people hovering for info probably care whatsoever about the recency of editing status. This would further allow room for more worthwhile text summary to be displayed.

Edwardj 123 (talkcontribs)

I think the settings icon is a valuable feature in the Page Previews hover card box because most users will want to have easy access to the settings to quickly change the size of the hover cards or disable them.

The last edited status text seems fairly important and is only a small bit of text so should be kept, particularly for editors' benefits.

The text summary could perhaps be extended, by a maximum of 8 words (not too many to make it visually bad and more than a summary) - particularly when the image is displayed horizontally to the right providing a gap between the summary text and the toolbar.

Bush6984 (talkcontribs)

I would think that changing those settings should be in a more generalized location, such as the "Preferences" or "Beta" link in our upper-right-hand corner, rather than cluttering the space in each and every single drop-down info box upon hovering.

My rationale here is that when people are hovering to get a quick summary of a topic in order to be able keep reading their main article, "Settings" and "Last Edited" are some pretty useless/ancillary bits of information. If I care that much to know a page's last edit, I can click the page itself to look at it. Likewise, if I care that much to change my "Page Preview" settings then I can go to my "Preferences/Beta" links just like I did in order to enable them initially. Point being, the "cost" of having those two items clutter screens is not offset and countered by the negligibly small "benefit" of the tiny few number of users who actually want to use those features directly from the Preview drop-down.

Hopefully that makes sense; that my point is not that those are 100% irrelevant, but that they are instead just rather poorly-placed to "cost" and take up space on every single Preview. To my logic, that is not the purpose the Preview tab serves, and therefore it's irrelevant clutter.

Edwardj 123 (talkcontribs)

Getting rid of the settings icon seems too much - it's such a tiny addition to a large box mostly filled with content, improving user experience because it simplifies accessing these important settings and needing less time to do things is a feature many people in society value. Although they are settings that would be infrequently used, the small icon is hardly cluttering up the space.

Bush6984 (talkcontribs)

If you say so. I disagree, but I'm not gonna waste my time in a back-and-forth.

The purpose of the Preview is quickly viewing a short summary of information, not having bells and whistles. There's no sense in retaining lots of side-bar and bottom-part miscellany when the primary function the Preview is supposed to serve is to: preview.

Edwardj 123 (talkcontribs)

Alright. I won't continue this back and forth debate between us and I partly agree with your point that the Page Preview settings could be accessed elsewhere despite the use case of quick access for inexperienced users using a small icon.

It would be valuable to have a few pieces of small metadata information in the preview box such as article quality, user views or last edited though.

Places for Wikipedia to provide access to Page Previews settings/preferences: user "Preferences" link in the header, link in the footer next to "Mobile view" when not logged in, optional settings icon in hover box.

Fixuture (talkcontribs)

I too think that the "Last edited" info is unnecessary and just takes away space that could be used to show something more useful (for instance info on the article's quality-status, geo-coordinates or maybe even meta-information such as views the last 30 days etc).

Reply to "The "Settings" and "Last Edited" seem unnecessary"

Display lead sentence of #Section, rather than of article proper

2
Unitof (talkcontribs)

When an article links to a specific section of an article, rather than the general article, should we display the lead sentence (and possibly even photo) of that specific section:

Example: the Hovercard for the link Year#Besselian year in the Universal Time article displays:

A year is the orbital period of the Earth moving in its orbit around the Sun. For an observer on the Earth, this corresponds to the period it takes the Sun to complete one course throughout the zodiac along the ecliptic."

but I believe it would be more helpful if it instead displayed

The Besselian year is a tropical year that starts when the (fictitious) mean Sun reaches an ecliptic longitude of 280°.
Fixuture (talkcontribs)

See this: https://phabricator.wikimedia.org/T65792

Reply to "Display lead sentence of #Section, rather than of article proper"
Cole128 (talkcontribs)

I think that hovercards would be better, if instead of telling me when the article was last edited, I could click a "read more" button that would give me the entire first paragraph inside the hovercard. Seeing cut-off sentences is annoying and not very helpful.

Parkywiki (talkcontribs)

An interesting idea. Not one I had thought of, but being able to see the expanded text of the introductory paragraph (including birth and death dates, pronunciations, alternative spellings etc) would be very welcome.

As an editor, I find seeing when the article was last edited quite helpful. Article class could be useful too.

Cole128 (talkcontribs)

How is seeing when it was last edited helpful? Maybe it shows how active the page is?

Parkywiki (talkcontribs)

Absolutely, Cole128. By the Hovercard showing when a page was last edited, I can quickly decide whether it's worth checking out. A long-unchanged page quite often benefits from a quick check and some updating, whereas a recently edited page is likely to be in the process of being edited by many others, and probably doesn't need my input. I accept this is a minority interest - but I like it, as I work in the non-popular culture areas of wikipedia where I can make more of a difference in my field of knowledge. Hope this makes sense.

Fixuture (talkcontribs)

I don't think that there are many other users who'd find it useful for the same reason. Furthermore I don't think that it's useful information for the end you described here: for instance it could have been recently updated by a bot and left unchanged for years - the last-edited-info is no useful indication for whether or not info is missing from an article whatsoever.

Cole128 (talkcontribs)

Thanks! I does make sense, and I still think the "read more" button would be a good idea. Having both the "last edited" and the "read more" would make a happy medium.

Reply to "Get rid of "last edited"."

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"

Add the page in the Watchlist just with the Hovercard view

6
GrandCelinien (talkcontribs)

Hey !

It would be nice if we had the possibility, by a little button, to add the article in our watchlist, like the title said.

I don't know if it had been already said before, sorry for the spam in this case... :)

Fixuture (talkcontribs)

I think this is useful just at first glance: I don't think anybody wants (or should be motivated) to add articles to the watchlist without having at least viewed (note: that doesn't equal read) the full article at least once. What instead would be useful is a to-read list (or alike) that one could add articles to like described. Here's the relevant extension: Extension:Gather

Would be interested what you and especially the developers would think about adding support for it to hovercards.

This comment was hidden by Fixuture (history)
Jkatz (WMF) (talkcontribs)

I think this is a good concept, but agree with @Fixuture that watchlist probably should only come after viewing the article. One thing we have implemented on the android app is a similar feature that makes a little more sense to me. There is a link preview similar to hovercards on the app, and on that you can choose to 'save the article' for later reading. This is something we have on iOS too on the new feed--you see a preview and can save for later.

I think there is an important distinction between wanting to bookmark and article and wanting to track the diffs. We don't have a great bookmarking feature (the recently pulled gather collections experiment was a failed effort in that direction), but I hope we can keep moving in that direction.

GrandCelinien (talkcontribs)

OK well it's true. I was thinking like a patroller, but most of the contributor doesn't need it. The idea of a "read latter" button is good. Thanks for the answer ! And sorry for my bad english :(

Jkatz (WMF) (talkcontribs)

@GrandCelinien Your english is great! ;)

Reply to "Add the page in the Watchlist just with the Hovercard view"

Page images are article metadata, avoid embedding it into article

4
197.218.81.208 (talkcontribs)

I see that the plan seems to be creating a parser function for choosing page images on a page, phab:T91683.

As a passive observer that has used other wikis before, I'd say that this is a pretty massive mistake of simply repeating history by putting metadata into the article. Categories are a great example of a tool which has massive problems because of this:

  • Localization is impossible - A category is really just a tag, but because it is embedded in an article it can't be translated without massively duplicating the data
  • No stable id- This causes several issues, it can't be removed or renamed without needlessly editing every single article containing it
  • No centralized GUI or curation tools to manage it
  • Performance issues - Phab:T116001

The same thing will be repeated if this is added as a parser function for setting page images:

  • Parser function on each article - on 100000 articles, every single article will need to be edited to remove or change it
  • GUI or better tools - this would make it once again hard to choose or change images using mobile devices
  • Duplicate work - A bat would use the same image, but this would need to be set on every article on every wikipedia, instead of using and encouraging something like wikidata
  • Complicated parser function + wikitext - people will likely add parser functions within it, and use hacks like "{{#tag" on it

About the only benefit is setting these images using templates. That in itself is a problem because templates are complicated beasts. This could be done way better by using simplified GUI based decision trees.

Unlike categories, images can be understood by everyone and many people can help out to choose appropriate image for articles. Anyway, this parser function path seems to be already set, but perhaps one day it will be revisited.

Pere prlpz (talkcontribs)

Hovercards show a summary of the article. Therefore, the image shown in the hovercard should be "the image" of the article, and it should be updated when article updates. Usually the automatic choice of image is fine - at least, as fine as the automatic choice of text - but sometimes it isn't and a template or magic word could fix it.

I agree that the tool could be simpler if the image were stored somewhere else (Wikidata?), just as it could be simpler if text would stored somewhere else, but then the hovercard wouldn't be showing a summary of the article. It would be showing something else.

Could hovercards show a summary of Wikidata instead a summary of the article? Yes, they could. Would that be more useful? I think it wouldn't.

Jdlrobson (talkcontribs)

The idea is to replicate the PAGEBANNER magic word that the Wikivoyage community has been using. It's probably worth reaching out there to see what issues they've had if any with using this. With regards to Wikidata that's captured here: https://phabricator.wikimedia.org/T95026 but I suspect the user of this is going to be an edge case, not the norm. Usually the choice made by the automatic algorithm is good enough.

Pere prlpz (talkcontribs)

The most common case where the automatic algorithm fails is when it takes an image from a template (e.g. a background map from an infobox or an image from a navigation template) unrelated to the article subject. For those cases a negative magic word (that is, telling the algorithm not to take a given image) could work as well as a positive magic word (telling the algorithm to take a given image).

In fact, positive and negative magic words could be included in templates.

Reply to "Page images are article metadata, avoid embedding it into article"
Quisqualis (talkcontribs)

Hovercards pose a distraction due to their size. I do not need the pictures. Have a small link for an article image. There needs to be a scroll bar for additional text.

CKoerner (WMF) (talkcontribs)

Howdy @ Quisqualis, you're not the only one with this thought. We've created a task to look into having options for the display of images. https://phabricator.wikimedia.org/T148995

Bush6984 (talkcontribs)

Agreed. (even though I'm 21 days late to this). I'd chalk it up to the images being too predominant and not being tiny thumbnails next to the text that's typically far more important.

Edwardj 123 (talkcontribs)

Although I don't mind its current size much, it is important that users can customise the box size by changing a setting stored with their account/browser session. I think three sizes called default, medium and small would be the best idea - with the image being the main thing resized:

  • "default" as the current size and layout (summary image top or right, summary text with ellipsis dots at end, half font size toolbar with last edit date and Page Previews settings opener button)
  • "medium" the same as default but with the summary image resized smaller and a bit less blank space padding in the whole Page Previews hover box
  • "small" the same as medium but with the summary image resized slightly smaller.

I disagree with the use of scroll bars to show more of the article text unless the standard summary length can't fit into the box size. It is only a summary so should have ellipsis dots such as "..." at the end to show there's more (currently a missing feature) and no scroll bar because showing more is the whole point of the article page itself.

Bush6984 (talkcontribs)

As to the scroll bars, I would agree with User:Edwardj 123 that scroll bars, while a neat extra feature, are kind of going beyond the scope of the purpose of the Preview, such that they don't necessarily need to be added to the Preview; that if a user wants to know that badly about the subject matter, they can just do what we've all been doing all along until this Preview feature came into Beta, which is just normally clicking the link.

Bush6984 (talkcontribs)

I didn't realize this was an option, to change box size, but that definitely seems like a worthwhile/beneficial option to have, for each user to be able to say "I just want a little bit" versus "I want quite a decent amount" of information from the Previewed page.

Would/should there be a more user-friendly way to inform users that they have the ability to customize size? For instance, assuming this makes its way out of Beta and doesn't have to be explicitly signed up for, in each user's Preferences tab (or the Settings gear within each hover, if that bit remains) to inform the common non-Wikipedian person who's just consulting the encyclopedia for information, for them to be able to see an informational "setting" of "If you would like to customize the size of your Preview box, here are your three options" (or "here is how to edit/modify that in your browser").

Edwardj 123 (talkcontribs)
@Bush6984 I think the existing settings icon in the hover box is a simple easy to find way to access the settings and users should expect the customisation options to change the size of the Page Previews box to be in this settings page (like most other applications).
Reply to "cards are too large/tall"
Wildan Masyiyan Chaniago (talkcontribs)

I just try this feature and it's straight my way to wikipedia... Great.

Bush6984 (talkcontribs)

I just tried it, and at first glance I'm definitely a fan. It spares having to open separate tabs when you're just looking for a quick reminder.

Jason Quinn (talkcontribs)

>It spares having to open separate tabs when you're just looking for a quick reminder.

Exactly way I think this feature will have a negative impact on the new editor rate.

Bush6984 (talkcontribs)

{{ping|w:User:Jason Quinn}} Why do you suspect that opening tabs should affect the rate of new editors?

I'm not saying it couldn't, but I can't readily imagine any reason they're in any way related; Previews-upon-hovering versus new editors's reasons to start. These seem unrelated. Could you provide context?

MaryamE bre (talkcontribs)

why

MaryamE bre (talkcontribs)

i just try

Edwardj 123 (talkcontribs)

Really like this new Page Previews feature (please deploy it) but make sure it doesn't reduce the amount of users who contribute to Wikipedia, doesn't have abruptly ending text (add ellipsis dots) and users can customise its size by changing a setting (some want to make it smaller).

Also, I have spotted a minor issue: when the summary image is displayed horizontally, it overflows the hover container vertically.

Reply to "Cool!"
Hugocabret (talkcontribs)

I think the hovercards is too big with a picture. Why do you not puting just the basics informations of the page.

CKoerner (WMF) (talkcontribs)

Thanks for the feedback @Hugocabret. We recently completed some usability testing and found that most people seem to like the larger photo. Can you please tell me more about why you don't like the large picture?

AaronNGray (talkcontribs)

can we just have a tick box enable/disable for the picture on the "cog wheel" settings options please ?

OVasileva (WMF) (talkcontribs)

This is a good idea. Making hovercards images configurable is one of the features that we're considering for a later iteration of hovercards. Take a look at this task for tracking purposes (we haven't started working on it yet)

Edwardj 123 (talkcontribs)

I like the image like many users probably do and have some ideas for customising the box display:

Although I don't mind its current size much, it is important that users can customise the box size by changing a setting stored with their account/browser session. I think three sizes called default, medium and small would be the best idea - with the image being the main thing resized:

  • "default" as the current size and layout (summary image top or right, summary text with ellipsis dots at end, half font size toolbar with last edit date and Page Previews settings opener button)
  • "medium" the same as default but with the summary image resized smaller and a bit less blank space padding in the whole Page Previews hover box
  • "small" the same as medium but with the summary image resized slightly smaller.

Relevant "cards are too large/tall" topic on this talk: Topic:Tevksgaota2q40h2

Reply to "With the picture it's to much"
AaronNGray (talkcontribs)

Is it possible to consider looking at having a "more" link to complete up to the end of a sentence or paragraph to deal with abruptly terminating text, and corresponding "less" link at the end of the expanded text please.

CKoerner (WMF) (talkcontribs)

There's a few tasks that are being worked on to make the text extracts more consistent and their termination less abrupt. phab:T113094

One of the issues that that the extract doesn't currently end where you might think it should. :)

CKoerner (WMF) (talkcontribs)

Reflecting on this idea, do you think Hovercards would benefit from a (More) or (Read more) link at the end of the short bit from the linked article?

Your feedback made me think of this. :)

AaronNGray (talkcontribs)

a "more" link would be a quick fix solution that could complete text the next sentence or paragraph, and allow the problem to be easily solved in the time being.

OVasileva (WMF) (talkcontribs)

Thank you for pointing this out, we're aware it's a very confusing experience as of now. We considered a few ways to fix the abrupt termination of text while still indicating that the article continues elsewhere, namely adding ellipses at the end of a sentence or a horizontal gradient/blur - we decided to go with the latter since it's in line with other design elements. If you're curious, the work is tracked here https://phabricator.wikimedia.org/T67845 and should be available in beta within the next month or so

AaronNGray (talkcontribs)

could we not have the ellipses clickable and extend to end of sentence or paragraph as it I actually a very easy thing to program !

Edwardj 123 (talkcontribs)

Letting lots more text be displayed defeats the whole point of the article page itself but I suppose displaying the end of the sentence could be acceptable as long as it's not too long.

I think it would be better to just have ellipsis dots or this horizontal blur thing (if it works well) though.

Reply to ""more" and "less" links"