Hi guys,
We would appreciate your advice on the Opt-out Feature for Media Viewer.
Our goal is to enable Media Viewer by default on all wikis when it the tool is ready.
But as recommended by many in our onwiki and IRC discussions, we would also like to provide a way for users to disable Media Viewer on a given site, so they can opt-out from this feature if I don't want it.
To that end, we are considering these different options:
A. 'Enabled' user preference Provide a preference checkbox with Media Viewer enabled by default (e.g.: 'Show images in Media Viewer'). To disable MV, users can uncheck this preference. • Pros: preferable from a UX point of view, indicates this is our recommended option, more user-friendy than JS gadget option below • Cons: this approach has caused problems before, users may not want this option to be selected for them, adds to preference bloat issue
B. 'Disable' user preference Provide a preference checkbox where Media Viewer can be disabled (e.g.: 'Disable Media Viewer'). To re-enable MV, users can uncheck that preference. • Pros: addresses user concerns about pre-selection, more user-friendy than JS gadget option below • Cons: unclear what Media Viewer is, confusing because you have to uncheck the preference to re-enable Media Viewer, adds to preference bloat issue
C. Javascript gadget or script Provide a site-wide gadget (or personal JS script) that would let users disable Media Viewer. • Pros: no preference bloat, no cache fragmentation, can simply ride on #263 and provide example JS code. • Cons: not user-friendly (the gadget has to be installed manually), the bootstrap script would still get loaded.
Notes • If we implement a user preference, the recommended location would be in the 'Appearances' section, under 'Files'. • We should also let power users know that they can easily use Ctrl-click or Shift-click to bypass Media Viewer and access images the same way they used to before this feature was introduced. So even with Media Viewer enabled, there are shortcuts you can use to go directly to Commons if you like.
We would appreciate your advice on which of the options above would be most helpful for the majority of our users (not just power users).
Please respond via email on this list — or add your comments on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Feedback_o...
Next week, we will ask your advice about other high-priority features for Media Viewer.
Thank you — and have a wonderful weekend!
Fabrice
_______________________________
Fabrice Florin Product Manager, Multimedia Wikimedia Foundation
A. 'Enabled' user preference Provide a preference checkbox with Media Viewer enabled by default (e.g.:
'Show images in Media Viewer'). To disable MV, users can uncheck this preference.
- Pros: preferable from a UX point of view, indicates this is our
recommended option, more user-friendy than JS gadget option below
- Cons: this approach has caused problems before[..]
Really? What problems?
B. 'Disable' user preference Provide a preference checkbox where Media Viewer can be disabled (e.g.:
'Disable Media Viewer'). To re-enable MV, users can uncheck that preference.
- Pros: addresses user concerns about pre-selection, more user-friendy
than JS gadget option below
- Cons: unclear what Media Viewer is, confusing because you have to
uncheck the preference to re-enable Media Viewer, adds to preference bloat issue
My understanding is that negations are harder to understand at a glance. Check pref to not do X is more confusing than check pref to do X no matter what the default state is.
I find it hard to believe users would object to having something checked by default but not object to having its meaning reversed and unchecked by default. If people are going to object its going to be to enabling the feature. Phrasing it as a double negative wouldn't change that. Otoh humans are silly sometimes.
C. Javascript gadget or script Provide a site-wide gadget (or personal JS script) that would let users
disable Media Viewer.
- Pros: no preference bloat, no cache fragmentation, can simply ride on
#263 and provide example JS code.
- Cons: not user-friendly (the gadget has to be installed manually), the
bootstrap script would still get loaded.
(Parser) Cache fragmentation should not be an issue either way. This sort of pref should not need to vary the parser cache. (If it was implemented in that way, i would predict strong objections in gerrit. We have only a few cache varying prefs, and my understanding is we dont want to add any more without a very very good reason).
-bawolff
I might be the source of most of the misinformation here :-)
On Sat, Mar 8, 2014 at 3:48 PM, bawolff bawolff+wn@gmail.com wrote:
A. 'Enabled' user preference Provide a preference checkbox with Media Viewer enabled by default
(e.g.: 'Show images in Media Viewer'). To disable MV, users can uncheck this preference.
- Pros: preferable from a UX point of view, indicates this is our
recommended option, more user-friendy than JS gadget option below
- Cons: this approach has caused problems before[..]
Really? What problems?
I vaguely remembered some problem the VE(?) team had with changing a preference from unchecked-by-default to checked-by-default. (It had to do with having to run a database query to flip that preference for all users, I think.) Probably not applicable here.
B. 'Disable' user preference
Provide a preference checkbox where Media Viewer can be disabled (e.g.:
'Disable Media Viewer'). To re-enable MV, users can uncheck that preference.
- Pros: addresses user concerns about pre-selection, more user-friendy
than JS gadget option below
- Cons: unclear what Media Viewer is, confusing because you have to
uncheck the preference to re-enable Media Viewer, adds to preference bloat issue
My understanding is that negations are harder to understand at a glance. Check pref to not do X is more confusing than check pref to do X no matter what the default state is.
Agreed; the text you are quoting says pretty much the same. (OTOH such a checkbox would probably communicate more clearly that enabling MediaViewer is the "normal" state; people usually expect checkboxes to default to unchecked.)
C. Javascript gadget or script
Provide a site-wide gadget (or personal JS script) that would let users
disable Media Viewer.
- Pros: no preference bloat, no cache fragmentation, can simply ride on
#263 and provide example JS code.
- Cons: not user-friendly (the gadget has to be installed manually), the
bootstrap script would still get loaded.
(Parser) Cache fragmentation should not be an issue either way. This sort of pref should not need to vary the parser cache. (If it was implemented in that way, i would predict strong objections in gerrit. We have only a few cache varying prefs, and my understanding is we dont want to add any more without a very very good reason).
I thought this would not fragment the HTTP cache because the same set of JS modules would be loaded initially for everyone; but there is no HTML caching for logged-in users, so this is a non-issue.
At any rate, I think this could be complementary to one of the other two options; it is less user-friendly but much more flexible, so it would be possible to say (in a gadget, or site-wide JS) that MediaViewer should not load on a certain page, in a certain namespace etc.
On Mar 9, 2014 12:21 AM, "Gergo Tisza" gtisza@wikimedia.org wrote:
I might be the source of most of the misinformation here :-)
On Sat, Mar 8, 2014 at 3:48 PM, bawolff bawolff+wn@gmail.com wrote:
A. 'Enabled' user preference Provide a preference checkbox with Media Viewer enabled by default
(e.g.: 'Show images in Media Viewer'). To disable MV, users can uncheck this preference.
- Pros: preferable from a UX point of view, indicates this is our
recommended option, more user-friendy than JS gadget option below
- Cons: this approach has caused problems before[..]
Really? What problems?
I vaguely remembered some problem the VE(?) team had with changing a
preference from unchecked-by-default to checked-by-default. (It had to do with having to run a database query to flip that preference for all users, I think.) Probably not applicable here.
MW stores prefs as a default value, and then all users who have something other than default separately. Changing the default is easy (only have to change in one place). I think echo ran into some problems here because they wanted existing users to have different "default" than new users. Just having the default be checked or unchecked for everyone is easy.
B. 'Disable' user preference Provide a preference checkbox where Media Viewer can be disabled
(e.g.: 'Disable Media Viewer'). To re-enable MV, users can uncheck that preference.
- Pros: addresses user concerns about pre-selection, more user-friendy
than JS gadget option below
- Cons: unclear what Media Viewer is, confusing because you have to
uncheck the preference to re-enable Media Viewer, adds to preference bloat issue
My understanding is that negations are harder to understand at a glance.
Check pref to not do X is more confusing than check pref to do X no matter what the default state is.
Agreed; the text you are quoting says pretty much the same. (OTOH such a
checkbox would probably communicate more clearly that enabling MediaViewer is the "normal" state; people usually expect checkboxes to default to unchecked.)
C. Javascript gadget or script
Provide a site-wide gadget (or personal JS script) that would let
users disable Media Viewer.
- Pros: no preference bloat, no cache fragmentation, can simply ride
on #263 and provide example JS code.
- Cons: not user-friendly (the gadget has to be installed manually),
the bootstrap script would still get loaded.
(Parser) Cache fragmentation should not be an issue either way. This
sort of pref should not need to vary the parser cache. (If it was implemented in that way, i would predict strong objections in gerrit. We have only a few cache varying prefs, and my understanding is we dont want to add any more without a very very good reason).
I thought this would not fragment the HTTP cache because the same set of
JS modules would be loaded initially for everyone; but there is no HTML caching for logged-in users, so this is a non-issue.
At any rate, I think this could be complementary to one of the other two
options; it is less user-friendly but much more flexible, so it would be possible to say (in a gadget, or site-wide JS) that MediaViewer should not load on a certain page, in a certain namespace etc.
I think the main reason to go this route would be to avoid pref bloat - which is something some devs care a lot about but most users dont seem to.
-bawolff
On Sat, Mar 8, 2014 at 8:37 PM, bawolff bawolff+wn@gmail.com wrote:
I think the main reason to go this route would be to avoid pref bloat - which is something some devs care a lot about but most users dont seem to.
If enough people want to disable, then there would have to be a gadget for it. Not sure if that is any less preference bloat than a proper option.
On Sun, 9 Mar 2014, at 19:27, Gergo Tisza wrote:
On Sat, Mar 8, 2014 at 8:37 PM, bawolff bawolff+wn@gmail.com wrote:
I think the main reason to go this route would be to avoid pref bloat - which is something some devs care a lot about but most users dont seem to.
If enough people want to disable, then there would have to be a gadget for it. Not sure if that is any less preference bloat than a proper option.
A gadget doesn't prevent relevant JS from loading, I think. Disabling server-side could save bandwidth and improve performance.
multimedia@lists.wikimedia.org