- Why Hovercards?
This is a feature intended to improve the experience for any reader who normally would have clicked on a blue-link in wikipedia because they needed an overview (definition) of that entity.
- How do we measure Hovercards performance?
The theory of impact for hovercards is that they lower the cost of exploring a link. This should mean that users are less inhibited about exploring links. We should see that the overall links clicked + (non-accidental) hovers exceed the number of links clicked without hovercards. This is what success looks like. There are also some indications of failure that we will look for:
- hovers can be accidental-we need to measure normal dwell time in a controlled condition to ensure that the likely rate of accidental hovers is not too high. To give an example, if a user must dwell on a link for 250 msecs before a hover shows, then we would want to make sure that there are not a large number of users who tend to dwell on a link for more than 250 msecs without clicking it.
- hovercards could lead to fewer pageviews, because the user gets the information that they need from the preview- this is not a problem, but we want to make sure that the decrease (if any) does not result in significantly less editing or fundraising.
- the % of hovers that result in a user continuing to the page is high - this would suggest that most people wanted to go to the page anyway. If this is the case, then the hover is likely just adding an unnecessary step. We expect some significant % of click throughs for hovers. It is ~60% on Android for a similar feature, but we expect it to be lower on desktop.
- What if I have Navpops enabled by default?
If you have Navpops enabled, hovercards are automatically disabled. You will have disable Navpops in order to experience hovercards. This is an intentional decision to ensure that Navpop users' do not have their preferences interrupted.
- How many options do I have in Hovercards preferences?
Right now, hovercards will either be turned on or off by a user. The option to turn them off lives in each hover event. So at each hover event, a user can decide that they are no longer interested. In order for a user to turn hovercards back on, they will have to go to their user settings. This currently does not exist for logged-out users, so we are creating it!
At the project level, administraters can determine how long a user should dwell on a link before a hover is triggered. If a project wants to be conservative, the lag can be longer. WMF will have a recommendation as to optimum dwell time that provides the best user experience while minimizing accidental hovers.
- Why can't users just turn on hovercards if they want them?
Unfortunately, there is no good way to tell users about a new feature. Central notice banners have been suggested, but running them for 2 weeks would not solve the needs of future users and we do not want to run them continuously. Notifying a user of a new feature is best done using a...hover-over. So that is why we are planning to show an initial hover on the users first hover event, followed by an explanation of what the user has seen. They can choose to turn them off in that dialogue.
- If I have hovercards feedback or if I have a suggestion for making them better, where should I go?
Please go to the hovercards discussion page, here: Talk:Beta Features/Hovercards