Translations:Page Previews/40/ja

ページプリビューはリンクを開くためのコストを下げるという発想に基づいて影響度を把握します. これは言い換えるなら、ユーザーは負担を感じずにリンクを開けるかどうかということです. つまりマウスを（無意識ではなく）当てて内容を閲覧したリンクの数が、実際にリンクをクリックした件数より多くなれば、ページプリビューが成功したと言えるはずです. 反対に、失敗を示す指標として以下に注目していきます. Navpops が有効だとページプリビューは自動で無効になり、Navpops を無効にすると使用できます. 個人設定の既定を変更しなかったのは、Navpops 利用者の使用感を変更しないためです. 注記: ブラウザによっては変更を反映するため、キャッシュの破棄が必要な場合があります. 現状、ページプリビューが使える場面（イベント）ごとに、ユーザーがその場で有効と無効を切り替える設定です. イベントが変わり、無効にしようと判断したときに変更できます. ログイン利用者の場合、各自の個人設定からページプリビューを常に有効にできます. 匿名利用者（ログインせずに利用）は、ページ下部の「プリビューを有効にする」ボタンで有効にできます.
 * ページプリビューの便利さはどう数値化できる？
 * マウスを当てるホバーが偶然ではないかどうか - 一定条件でホバーの滞留時間を計測し、マウスをリンクに当てたのが偶然だったという割合が高くないと確認する必要があります. 一例としてリンクにマウスを当ててからページプリビューが表示されるまでの滞留時間の設定を250ミリ秒にするなら、特定のリンクにマウスを当てたユーザーで、250ミリ秒以上滞留してからクリックする率は低いと確認しなければならないのです.
 * ページプリビューを利用するとページ閲覧数が減る可能性があります. プリビューすれば知りたい情報がわかるからで、それ自体は問題になりません. ただし（もし）閲覧数が減少したなら、編集件数や寄付件数に目立った影響が出ないように注視する必要があります.
 * リンクをホバーしたユーザーが実際にリンク先を開くのは高確率（%）- このことからその人たちは本来、リンク先を訪問する意思があったと推定されます. もしそうであれば、ページプリビューは不用な手間になりかねません. マウスを当ててからクリックスルーに至る確率（%）に基準を設けます. Androidでは同様の機能は60%以下ですが、デスクトップ版ではもっと低いと予測しています.
 * ページプリビューを無効にしたユーザーは低比率（機能を無効にする方法を知っているという前提）- ユーザーがこの機能を歓迎していると解釈.
 * 既定で Navpops が有効の場合はどうなりますか?
 * ページプリビューの個人設定には何種類ありますか?