I might be the source of most of the misinformation here :-) On Sat, Mar 8, 2014 at 3:48 PM, bawolff <[email protected]> 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.
_______________________________________________ Multimedia mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/multimedia
