Page Previews/zh

页面预览功能解决了用户需要打开多个窗口来理解他们正在阅读的概念或词语. 页面预览功能可以在用户浮上链接到其他文章的词语时，显示简短的主题和图片（如果有的话）. 之后，用户可以决定是否要在完成当前文章的阅读前去通篇阅读链接的那篇文章. 提供了页面预览功能的完整说明. 这篇博客文章提供了从2018年5月开始所有相关技术文档的概述.

“引用预览”功能是一个相关的项目. 每当读者悬停在脚注标记上时，它都会显示脚注的预览. 有关此功能的说明，请访问其项目页面.

简介
页面预览旨在降低探索链接的成本，并通过允许读者获得他们正在阅读的文章的上下文，或在不偏离原始主题的情况下定义不熟悉的术语、对象、事件或想法来促进学习. 对于普通读者来说，页面预览将使用户在决定是否浏览文章之前更容易获得文章的概述. 有兴趣阅读整篇文章的用户不会因为阅读不熟悉的概念而分心或气馁——他们可以简单地预览概念，而无需导航到新页面. 因此，将提高这些用户的用户体验的平滑度.

多年来，有很多人要求提供类似的功能；有一些浏览器扩展（请参阅list）和一个大量使用的小工具（更侧重于编辑器的Navigation popups）也可以解决这个问题. 页面预览于2014年首次作为测试版功能（称为Hovercards）构建，在采用率、用户反馈和对使用的影响方面，它一直是我们最受欢迎的测试版功能之一. 在Hovercards的主要谈话页面上，在两年的时间里，所有项目中的许多问题都得到了识别和解决. 在安卓应用程序上实现的移动版页面预览2015年9月，导致每页点击的链接增加了20%.

页面预览设置面板允许已注销的用户根据自己的偏好启用和禁用该功能. 登录的用户可以从“特殊:首选项”的“外观”部分启用或禁用“页面预览”. 如果同时启用导航弹出窗口和页面预览（通常，对于通过测试版功能选择加入的登录用户），则导航弹出窗口优先. 若要启用页面预览，必须禁用导航弹出窗口.



设计
对于页面预览的当前迭代，每个预览都包含以下内容：
 * 文章第一段的一部分
 * 文章中的图片（如果可用）. 图像显示为水平或垂直，具体取决于文章中链接的位置.
 * 允许用户打开和关闭页面预览的设置齿轮



与导航弹出菜单的主要区别

 * 导航弹出窗口适用于超级用户，具有许多与大多数网站用户无关的功能，例如指向元数据页面的快速链接，如历史记录、差异和用户贡献.
 * 导航弹出窗口适用于指向所有命名空间和所有Wikimedia项目的链接. 页面预览被配置为仅使用主空间链接，并且目前仅在Wikipedias上使用.
 * 页面预览的样式是为了便于阅读. 目前，Nav弹出窗口的类型大小很小，边缘很紧.
 * 页面预览对所有用户都可用，而不仅仅是已登录的用户.
 * 页面预览使用与文章类型处理一致的视觉样式
 * 页面预览强调引导图像，因此用户可以同时使用文本和图像来了解术语.
 * 小工具中的操作集感觉断章取义，因此我们需要验证其中哪些操作对读者和编辑有用.



HTML预览
自2018年3月1日起，页面预览现在以HTML形式显示预览. 这解决了许多突出的错误，提供了数学、化学和其他公式的正确表示，并确保预览显示与文章内容相同的格式.

-{zh-hans:设置; zh-hant:設定;}-
 === -{zh-hans:启用/禁用;zh-hant:开/关}-



注销的用户
注销的用户可以通过每个预览底部显示的齿轮图标关闭页面预览. 如果用户希望重新启用页面预览，可以通过任何wiki页面底部的“”链接启用. 他们还可以在浏览器中禁用JavaScript以永久关闭它.



登录的用户
已登录的用户可以从两个位置控制其设置. 他们可以从“特殊：首选项”的“外观”部分启用或禁用“页面预览”. 登录的用户还可以通过每个预览底部显示的齿轮图标关闭页面预览.
 * 如果登录的用户点击设置齿轮，系统会将他们重定向到用户偏好页面.
 * 如果用户以前启用了悬停测试版功能，则他们的首选项将保留并显示在用户首选项的“外观”部分.



成功度量和功能评估
进行了大量定性和定量测试，以评估页面预览功能的性能. 这些测试的重点是以下问题：
 * 用户喜欢页面预览并觉得它们有用吗？
 * 页面预览如何改变阅读行为，并帮助用户在选择想要阅读的文章时更加准确？
 * 启动页面预览功能会对筹款产生影响吗？



2015希腊语和加泰罗尼亚语维基百科测试
在希腊语和加泰罗尼亚语维基百科上进行了为期4个月的功能测试. 报告了一些问题和错误，并通过调查记录了用户满意度. 用户普遍获得了良好的反馈，大多数用户认为页面预览（悬停）有用、易于使用且使用愉快.

阅读这些测试的全部结果.



2016定性测试
为了确定用户对页面预览功能的态度，并跟踪读者行为的进一步变化，使用UserZoom (failed to load link)软件. 大多数参与者表示对页面预览功能持积极态度. 此外，大多数参与者在打开和关闭该功能方面没有问题. 用户对该功能的描述总体上是积极的，并表示它不会分散他们的阅读体验.

阅读这次测试的全部结果和分析.



2016匈牙利语、意大利语和俄语维基百科A/B测试
为了确定阅读行为的变化并评估页面预览（Hovercards）测试版功能的成功，在匈牙利、意大利和俄罗斯的维基百科上启动了三个A/B测试. 匈牙利语的A/B测试于2016年6月7日启动，意大利语和俄语的A/B测试则于2016年9月23日启动.

这些测试的结果表明，页面预览通过提高用户选择他们阅读的页面的精度，降低浏览其他页面的成本，并允许用户通过在页面中提供上下文来选择性地关注单个主题，从而促进阅读行为的积极变化. 在收集和分析数据的过程中，我们在仪器中遇到了许多错误和问题，这些错误和问题使我们得以改进和改进，以确保后续测试没有问题.

阅读这些测试的全部结果和分析.



2017-2018英语和德语维基百科A/B测试
从2017年10月到11月，从2017年12月到2018年2月，在这些项目发布之前，我们运行了两个A/B测试来评估功能的性能. 结果、详细描述在报告中，显示页面浏览量减少，但读者互动的不同页面数量总体增加，这表明当该功能打开时，他们更有可能探索更多种类的主题. 我们还注意到后退按钮的使用减少，禁用该功能的比率非常低. 此外，我们在enwiki上进行了一些筹款测试.



自2016年4月英语维基百科讨论以来的改进
在2016年4月的讨论期间，我们发现了一些错误、改进和其他请求，我们通过以下方式解决了这些问题：

预览“卡在”打开位置


 * 我们已经重构了代码，这不再是一个问题

粗体文本和数学公式未显示在预览中


 * 目前，预览显示在HTML中，内容与文章内容一致

一种从卡本身禁用该功能的方法


 * 登录和注销的用户现在可以通过选择卡中的设置档位来禁用该功能.

一种确保页面预览不会干扰导航弹出窗口的方法

提供更深入的研究和A/B测试结果，在英语维基百科上进行大规模的A/B测试
 * 登录的用户可能有导航弹出窗口或页面预览. 如果你是导航弹出窗口用户，除非你先关闭导航弹出窗口，否则你将无法启用页面预览，反之亦然
 * 自讨论以来，我们已经进行了两个A/B系列测试，第一个是在匈牙利、俄罗斯和意大利的维基百科上. 以及英语和德语维基百科上的第二.

限制性能影响


 * 我们已经与我们的性能团队合作，尽量减少任何问题的页面预览. A主面板，其中包含有关功能性能的详细信息.

提供一种仅为匿名用户启用该功能的方法


 * This is ready as well. As of March 2018, the feature is enabled by default for anonymous users on all Wikipedias except English and German

Providing data on how often users disable the feature


 * For both of our 2017/18 A/B tests, the disable rate was around 0.01%. Because the rate had been similarly low in earlier A/B tests, we also did a qualitative test to confirm that users did not have problems enabling or disabling the feature.  Our conclusion is that people know how to turn the feature off without difficulty but do so at extremely low rates.

Providing information on whether the feature was considered a nuisance


 * Based on our qualitative testing, we concluded that tested users did not find the feature distracting, or a nuisance.

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

Future Iterations and Potential Improvements
Following the general 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. Request declined: 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). The project page for the Reference Previews feature has more details.

FAQ

 * Why Page Previews?
 * 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.


 * How do we measure Page Previews performance?
 * 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:


 * 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 page views, 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?
 * 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.


 * What if I have Navpops enabled by default?
 * 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.


 * How many options do I have in Page Previews preferences?
 * 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.

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.


 * Why can't users just turn on Page Previews if they want them?
 * 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.


 * What impact to Page Previews have on page views?
 * 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 Previews on and off groups.


 * What about accessibility?
 * Page Previews only activate when the focus/hover state occurs over a link. They are usable for people who use keyboard navigation. For screen readers, Page Previews have proper WAI-ARIA semantics declaring them as tooltips. In short, screen reader software ignore Page Previews.


 * If I have Page Previews feedback or if I have a suggestion for making them better, where should I go?
 * Please go to the Page Previews discussion page.


 * The Page Previews continues to show an old version of a page. What can I do?
 * The Page Preview shows the cached version of a page. If the page has been edited and you want Page Previews to show the new version right away, you can purge the page.


 * How can I exclude certain page images?
 * See Extension:PageImages for details.

Code

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


 * To measure content usage via Page Previews, in an aggregated way that is compatible with the existing Pageviews data, a separate instrumentation was set up that went live in April 2018. There are plans to make some of this data public for the benefit of e.g. Wikipedia editors and academic researchers.

Rollout Update July 2018
Page previews are now available on all Wikipedias. The feature is on by default for anonymous users and newly created accounts and off by default for accounts created before July 10, 2018.

Rollout Update April 2018
The next step of the rollout for English and German Wikipedias is planned for the first half of April 2018. This deployment will include turning the feature on by default for logged-out users. This will mean no changes for logged-in users. The feature will be off by default for logged-in editors, unless currently enabled. If you would like to enable it, it is available in your Preferences under “Appearance”. If you have the feature enabled already, it will stay on.

In terms of future changes for logged-in users, we have a few options we will be requesting feedback on:


 * Keep the feature off by default for logged-in users.
 * Turn the feature on by default for new accounts only. Currently, when users move from being readers to contributors and create an account, the feature will seem to vanish, and that would be confusing.  As a further step in the feature rollout, we plan to change this configuration and enable the feature for all new accounts.
 * Turn the feature on by default for existing logged-in users (Even if it were enabled for everyone, it would still be automatically suppressed for anyone who uses NAVPOPS.)

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.