Page Previews/preferences

From mediawiki.org

About[edit]

As you may know, there was a discussion going on about enabling hovercards/link previews for Wikipedia on the desktop site. We would like to address all concerns about this feature before we advocate for its release.

One of the bigger design challenges for this feature came up during the initial analysis. Disabling hover cards should be easier for logged in and anonymous users. This brings up the need for a place to set user preferences without a user being logged in.

This community consultation is around “Reading Preferences” and where they should sit, so that even anonymous users can customize their Wikipedia experience.

Please vote on the approach you think works for Wikipedia.

Approach 1[edit]

Create a new, convenient and easy to access modal window for “Reading Preferences” There will always be a settings button on all articles where users can change their preferences for reading.

This also can house the accessibility preferences we are yet to implement. Viz. Font size, contrast and night reading mode. It will have only the hovercard enable/disable feature to begin with, and we can extend to have other reading settings in the future.

Approach 1 appearance[edit]

Support approach 1[edit]

  1. Support While approach 2 would be more consistent with the logged in experience, readers don't really care about that, and logged in editors probably won't care about it either. I also see this as better because it does not require the reader to leave the page to change the settings. I also think this just looks better. That being said, it probably will conflict with topicons which is problematic but I don't think unable to be reconciled. Perhaps if they were just moved to the side of the preferences. Wugapodes (talk) 20:06, 19 May 2016 (UTC)[reply]

Oppose approach 1[edit]

  1. Oppose. Having "navigation popups" and other such things enabled and disabled via "preferences", and another option (similar to "navigation popups"?) enabled and disabled in some other way, will be messy, confusing, and unnecessary. Maproom (talk) 21:17, 19 May 2016 (UTC)[reply]
  2. Oppose per Maproom. Treat the option consistently with other preference options. Ivanvector (talk) 22:47, 19 May 2016 (UTC)[reply]

Approach 2[edit]

In this approach, we simply extend the current preferences page (Special:Preferences) to include the hovercard preferences. This means, the preference link will be available from the right top menu even when you are not logged in. If you are not logged in and you access special:preferences, you will be given only one tab “Appearance” from the regular preferences. Here you can disable or enable hover cards.

Approach 2 appearance[edit]

Support approach 2[edit]

  1. I support this option as it's consistent with the logged-in experience. The specific problem I have with approach 1 is that the space in the mockup for the modal dialog also is commonly consumed by top icons (FA stars in article space and who-knows-what-variety of icons outside that) and geographic information. The UX for "preferences" is also commonly found here (and sometimes in the lower-left sidebar) of sites, though it's usually "settings". Maybe it would be a good idea to rename this for readers, who will understand "settings" better than "preferences"? --Izno (talk) 18:38, 19 May 2016 (UTC)[reply]
  2. Support. It'll be a preference. Whyever wouldn't it go under under "Preferences"? That's the natural place to look for it. Maproom (talk) 21:19, 19 May 2016 (UTC)[reply]
  3. Support per Maproom again. Ivanvector (talk) 22:47, 19 May 2016 (UTC)[reply]
  4. Support as this is the common sense approach and where most will look for, or happen across, it. GenQuest (talk) 13:12, 20 May 2016 (UTC)[reply]
  5. I suppose this is the best of the options - see the discussion page - I have no support unless this will be stored client-side though. Xaosflux (talk) 18:45, 21 May 2016 (UTC)[reply]

Oppose approach 2[edit]

Access from Hovercards[edit]

As mentioned above, because we want to make it easy to disable/enable hovercards, we will retain the “settings” icon on each hovercard you see. Approach 1 and Approach 2 above are where this settings cog on each hovercard takes a user to disable the feature if the user wants to do so.

How it looks


We look forward to feedback from the community!