Talk:Beta Features/Hovercards/preferences

About this board

An aesthetics and accessibility menu

3
Quiddity (talkcontribs)

https://phabricator.wikimedia.org/M17 contains the idea that I still believe solves this problem, and a whole lot more. Also with notes below on relevant external examples. I urge investigation into that.

Npangarkar (WMF) (talkcontribs)
Quiddity (talkcontribs)

Yup! and more since I started suggesting File:Wireframe of Appearance menu.png. (replicated at M17).

The reason I'm pushing the M17 implementation, is that it would live outside the preferences menu, and thus, hopefully, be available to logged-out/IP users.

Reply to "An aesthetics and accessibility menu"

Storage of selection?

4
Xaosflux (talkcontribs)

Regardless of the choice, where is the storage of the selection to reside? In a client cookie? I object to storing any of this server side based on client ip address.

Wugapodes (talkcontribs)

I would assume a cookie. I agree that server-side by IP would be inappropriate. ~~~~

Jdlrobson (talkcontribs)

It uses localStorage so it is tied to and private to your device. In future we could tie storage to account details for logged in users but we don't have any plans to just yet.

Quiddity (talkcontribs)

It is already possible for IPs to re-enable hovercards once they're disabled via the cog icon. We used the same system that Reference Tooltips does, as explained/illustrated at Beta_Features/Hovercards#Settings. However, this isn't perfect, especially because of localstorage issues with Firefox (see phab:T66721#2014128 and others). I'm not uptodate (nor a developer) on the technical details and issues though.

Reply to "Storage of selection?"
Oiyarbepsy (talkcontribs)

I thought that you created an option to allow IPs to opt out of media viewer, but here you are saying that hovercards would be the only reader preference option. Am I wrong about media viewer?

Npangarkar (WMF) (talkcontribs)

No, you are not wrong. The difference is, media viewer can be re-enabled from commons image detail page. we don't have a common place to enable hovercard's and hence we came up with these options.

Reply to "Media viewer?"
BethNaught (talkcontribs)

Design 1 is incompatible with current Wikipedia processes since it gets in the way of top icons such as featured article stars and protection padlocks.

Npangarkar (WMF) (talkcontribs)

It will co-exist with semi-protect and the featured article star. it can be on the right of the indicator icons.

Reply to "Topicons"
BethNaught (talkcontribs)

I have nominated for deletion on Commons the screenshots Npangarkar (WMF) uploaded. They are copyright violations because they do not attribute the authors either of MediaWiki, Wikipedia or the included images, nor do they attribute the licenses of such.

Reply to "Image copyrights"
Ruud Koot (talkcontribs)

I've also made a mash-up of a non-modal version:

Possible advantages may be:

  • If a user changes the font size or contrast settings, they can immediately see the effect on the article. (This is partially obscured in the modal version.)
  • It may be possible to automatically open the non-modal preferences window when a new feature becomes available or a user without any preferences sets comes along. With a modal window, this would become too obtrusive. (And, being opened on page load, also means nothing has to unexpectedly "pop up" later.)
  • It fits better with Echo's notification windows.

Also, is the "Save" button really necessary? (This may be one reason to prefer the modal window.) Having to "save" or "apply" your settings is becoming a bit old-fashioned. You can't really damage anything by changing these settings, so there should be no need to confirm you really want to change them.

Npangarkar (WMF) (talkcontribs)

This is a really good idea! I will make sure it reflects in the design if we (with community's input) decide to go with the new preference.

Reply to "Non-modal window"
There are no older topics