Page Previews

The Page Previews  feature solves the core problem of users needing to open multiple tabs to gain an understanding of a word or concept within the context of the subject they are reading. With Page Previews, whenever a reader hovers over a link to another article, a short summary of the subject and an image (if available) is displayed. The user can then decide whether they wish to visit that subject more thoroughly before continuing with the current article. A complete description of Page Previews functionality can be found here.

Introduction
Page Previews are designed to reduce the cost of exploration of a link, as well as to promote learning by allowing readers to gain context on the article they are reading or to define an unfamiliar term, object, event, or idea without navigating away from their original topic. For casual readers, Page Previews will make it easier for users to get an overview of an article before deciding whether or not to browse to it. Users interested in reading an entire article in its totality will not be distracted or discouraged by viewing unfamiliar concepts - they can simply preview the concept without navigating to a new page. Consequently, the smoothness of the user experience for these users will be increased.

There have been many requests over the years for a similar feature; there are browser extensions (see list) and one heavily used gadget (the more editor-focused Navigation popups) that also exist to solve this problem. Page Previews were first built as a beta feature in 2014 (called Hovercards) and have been among our most popular beta features in terms of adoption, user feedback and impact on usage. On the primary talk page for Hovercards, over the course of 2 years, numerous issues across all projects were identified and resolved. The mobile equivalent of Page Previews, implemented on the Android app in September, 2015, led to a 20% increase in links clicked per page.

The Page Previews settings panel enables logged-out users to enable and disable the feature based on their preferences. Logged-in users can currently enable and disable the feature from their beta settings. If Navigation popups and Hovercards are enabled at the same time (typically, for logged in users who have opted in via the beta feature), Navigation popups takes precedence. To enable Page Previews, Navigation pop-ups must be disabled.



Design
For the current iteration of Page Previews, each preview will contain the following:
 * A portion of the first paragraph from the article
 * An image (if available) from the article. Images will appear horizontal or vertical depending on the location of the link within the article.
 * A settings cog which will allow users to turn Page Previews on and off

Key differences to Navigation Popups

 * Navigation popups are for power users and has many features that are not relevant to most site users.
 * Hovercards is styled to enable easy reading. Currently, Navpop-ups' type-size is small and the margins are tight.
 * Page Previews will be available to all users, not just logged-in users
 * Create a consistent visual style with the article type treatment.
 * Emphasize the lead images, so a user gets an idea of a term using both text and image.
 * The action set in the gadget feels out of context, hence we need to validate which of those actions are useful for readers and editors.
 * Include the last edited timestamp that we have tested on Wikipedia mobile web.

HTML Previews
As of March 1st, 2018, page previews now display previews in HTML. This resolves many outstanding bugs, provides correct representation of mathematical, chemical and other formulas, and ensures previews display the same formatting as the article content.

Line Height issues
The line height of page previews is 140px. For wikis with larger default max height preview text might display inconsistently. So far, this has only been observed on arwiki, but it is possible it is an issue elsewhere. To fix, the max height of previews must be adjusted as follows:

.mwe-popups.mwe-popups-is-not-tall .mwe-popups-extract {max-height:130px;}

Examples and more information can be found in the corresponding phabricator task

Logged Out Users
Logged out users may turn Page Previews off via the cog-icon displayed at the bottom of each preview. If a user wishes to re-enable Page Previews, they can be enabled via the "" link available at the bottom of any wikipage.

Logged-In Users
Logged-in users can control their settings from two places. Logged in users may enable or disable Page Previews from the Appearance section of Special:Preferences. Logged-in users may also turn Page Previews off via the cog-icon displayed at the bottom of each preview. Logged in users should opt-in via their user preferences if they would like to use Page Previews.
 * If a user chooses to select the settings cog, the system will redirect them to the user preferences page.
 * If a user previously had the Hovercards beta feature enabled, their preference will be kept and appear in the Appearance section of user preferences.

Open/Close delay timing
Logged-in users can change the timing of how fast Page Previews appear and disappear (open/close delay). See Extension:Popups#Show/hide timing for instructions.

Success Metrics and Feature Evaluation
A number of qualitative and quantitative tests were performed to evaluate the performance of the Page Previews feature. These tests were focused on the following questions:
 * Do users enjoy Page Previews and find them useful?
 * How do Page Previews change reading behavior and do they help users be more accurate when selecting the articles they wish to read?
 * Would launching the Page Previews feature have effects on fundraising?

2015 Greek and Catalan Wikipedia test
A feature test on was implemented for a period of 4 months on Greek and Catalan Wikipedias. A number of issues and bugs were reported and user satisfaction was recorded using a survey. Users had generally favorable feedback, with the majority of users finding Hovercards useful, easy to use, and enjoyable to use.

Read the full results of these tests.

2016 Qualitative test
To determine user attitudes towards the Page Previews feature and trace further changes in reader behavior, an unmoderated remote panel study was performed using UserZoom software. The majority of participants reported positive attitudes to the Page Previews feature. In addition, the majority of participants had no issues in turning the feature on and off. Users also described the feature in generally positive terms and reported it was not distracting to their reading experience.

Read the full results and analysis of this test.

2016 A/B tests on Hungarian, Italian, and Russian Wikipedias
To determine changes in reading behavior and evaluate the success of the Page Previews (Hovercards) beta feature, three A/B tests were launched on Hungarian, Italian, and Russian Wikipedias. The A/B test on Hungarian was launched June 7, 2016, the A/B tests on Italian and Russian were launched Sept 23, 2016.

From the results of these tests, we can conclude that Page Previews facilitate positive changes in reading behavior by increasing the precision with which users select the pages they read, reducing the cost of exploration of other pages, and allowing users to selectively focus on a single topic by providing context within a page.

Read the full results and analysis of these tests.

2017 A/B test on English and German Wikipedias
On August 28, 2017, we launched an A/B test to gauge the performance of the feature prior to release on these projects. The tests ran for two weeks concurrent with a number of fundraising tests on enwiki.

Blacklisted pages
For security reasons, Page Previews won't be loaded on certain special pages. We refer to these pages as "blacklisted pages". The initial version of the blacklist can be found here:.

Future Iterations and Potential Improvements
Upon success of an initial launch of Page Previews, we are planning on iterating on the feature to add functionality. These items will include:
 * Configuration of images and other settings:
 * a number of users have requested making images configurable within Page Previews. We're marking this feature for future implementation and tracking it in https://phabricator.wikimedia.org/T148995
 * other logged out preferences (more info here)
 * Article titles - currently, only the summary of the article is available within Page Previews. As an iteration, we would like to display the title of each article along with its summary
 * Reference Tooltips (phab:T67114)

FAQ
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. It's inspired by one of the most popular gadgets, Navigation popups.
 * Why Page Previews?

The theory of impact for Page Previews is that they lower the cost of exploring a link. This should mean that users are less inhibited and more focused when exploring links. We should see that the overall links clicked + (non-accidental) hovers exceed the number of links clicked without Page Previews. This is what success looks like. There are also some indications of failure that we will look for: No. If you had the feature enabled as a Beta feature you will still have the feature enabled. See Preferences>Appearance>Reading preferences to change the setting. If you have Navpops enabled, Page Previews are automatically disabled. You will have to disable Navpops in order to experience Page Previews. This is an intentional decision to ensure that Navpop users' do not have their preferences interrupted. Note: for certain browsers, you might have to clear your browser cache first for the change to take place. Right now, Page Previews 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. For logged-in users, Page Previews may be re-enabled from user settings under the section titled "Appearance". For logged-out users, Page Previews may be re-enabled by selecting the "Enable Previews" link at the bottom of the page.
 * How do we measure Page Previews performance?
 * 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.
 * Page Previews 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.
 * the percentage of users who disable Page Previews is low (given that users are aware on how to disable the feature) - this suggests that users enjoy the feature.
 * Is this enabled by default for logged-in users?
 * What if I have Navpops enabled by default?
 * How many options do I have in Page Previews preferences?

At the project level, administrators 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. Unfortunately, there is no good way to tell users about a new feature without showing it to them first. 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. According to A/B tests we did not see a large decrease in session depth across all Wikipedias. Average session depth (average number of pages viewed per session) remained relatively equal between the Hovercards on and off groups. Page Previews only activate when the focus/hover state occurs over a link. They are usable for people who use keyboard navigation. For screenreades, Page Previews have proper WAI-ARIA semantics declaring them as tooltips. In short, screenreader software ignore Page Previews. Please go to the Page Previews discussion page.
 * Why can't users just turn on Page Previews if they want them?
 * Why can't users just turn on Page Previews if they want them?
 * What impact to Page Previews have on page views?
 * What impact to Page Previews have on page views?
 * What about accessibility?
 * If I have Page Previews feedback or if I have a suggestion for making them better, where should I go?

Code

 * Analytics and instrumentation
 * Page Previews are currently instrumented to measure various aspects of usage. Please see the popups extension page for details and feel free to ask any clarifying questions.

Rollout Plan
We began rolling out to Catalan, Greek, Hungarian, Italian, and Russian Wikipedias in early 2017. Data from the A/B tests represented highly favorable views of the feature. After this, we would like to continue rolling out in stages to other Wikipedias as described in the table below.

Onboarding Experience
The onboarding experience for the feature will depend on the consensus of each community on having Page Previews on by default or providing users with an onboarding experience during which they can reject the feature. The discussion has begun on English Wikipedia with no current consensus. More info here: https://en.Wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_131#Proposal:_Enable_Hovercards_by_default