Recently, Media Viewer[1] (MMV) has been switched at Wikimedia Commons to be default.
As some people do not care a lot for beta features or new features, do not read the mailing lists and overlook main discussion forums or are just unable to understand English, they were surprised and confused and wondered how they could disable the feature.
Please help me to evaluate if there are alternatives to how software deployment is currently done. Here are some suggestions from community member Jameslwoodward (commons adminstrator):
A Post a banner so that there is a good chance of actually reaching everyone. B Ensure that the internally referenced help page actually has correct information. C Major changes can be the default for new users, but should be opt-in for existing users.
I think (A) could be partially done by tech-ambassadors (what a difficult word); however when deploying something like MMV to all wikis, isn't this worth a CentralNotice?
(B) is as obvious as important. Outdated information is confusing. Make sure to update your help pages before going to release your software to the wild. Or delay the release until this is done.
Suggestion (C) is interesting, although perhaps technically difficult to implement. If a feature that one experienced as anonymous user is good [login cookies expire, ...], or one explicitly tested the feature or was told by a fellow about a good feature, it is very likely that one will enable that feature for the account, too. People will do this freely. Without complaining. And people, who intentionally enabled a feature, usually have a positive attitude, are willing to help and improve the feature. They will provide you with constructive feedback. The overall atmosphere would be a lot more positive than that we currently experience with new tools, *the power users do not need*. So why not actively promoting a feature until there is a critical mass using it? It may take a lot of time but I think it's worth a test.
A personal appeal: Please care about the power users [2]. They are the core and foundation of the WMF projects. They create the content; manage most issues - think about the OTRS team - in their spare time, ... so WMF can finally run the fundraiser banners and you can get your payment.
-- Rillke
[1] https://www.mediawiki.org/wiki/Help:Multimedia/Media_Viewer [2] http://www.aswedeingermany.de/50SoftwareDevelopment/20MostImportantRuleOfUID...
I thought we already had this discussion recently: http://www.gossamer-threads.com/lists/wiki/wikitech/412782?do=post_view_thre...
On Sat, May 17, 2014 at 2:55 PM, Rainer Rillke rainerrillke@hotmail.comwrote:
Recently, Media Viewer[1] (MMV) has been switched at Wikimedia Commons to be default.
As some people do not care a lot for beta features or new features, do not read the mailing lists and overlook main discussion forums or are just unable to understand English, they were surprised and confused and wondered how they could disable the feature.
Please help me to evaluate if there are alternatives to how software deployment is currently done. Here are some suggestions from community member Jameslwoodward (commons adminstrator):
A Post a banner so that there is a good chance of actually reaching everyone. B Ensure that the internally referenced help page actually has correct information. C Major changes can be the default for new users, but should be opt-in for existing users.
I think (A) could be partially done by tech-ambassadors (what a difficult word); however when deploying something like MMV to all wikis, isn't this worth a CentralNotice?
(B) is as obvious as important. Outdated information is confusing. Make sure to update your help pages before going to release your software to the wild. Or delay the release until this is done.
Suggestion (C) is interesting, although perhaps technically difficult to implement. If a feature that one experienced as anonymous user is good [login cookies expire, ...], or one explicitly tested the feature or was told by a fellow about a good feature, it is very likely that one will enable that feature for the account, too. People will do this freely. Without complaining. And people, who intentionally enabled a feature, usually have a positive attitude, are willing to help and improve the feature. They will provide you with constructive feedback. The overall atmosphere would be a lot more positive than that we currently experience with new tools, *the power users do not need*. So why not actively promoting a feature until there is a critical mass using it? It may take a lot of time but I think it's worth a test.
A personal appeal: Please care about the power users [2]. They are the core and foundation of the WMF projects. They create the content; manage most issues - think about the OTRS team - in their spare time, ... so WMF can finally run the fundraiser banners and you can get your payment.
-- Rillke
[1] https://www.mediawiki.org/wiki/Help:Multimedia/Media_Viewer [2]
http://www.aswedeingermany.de/50SoftwareDevelopment/20MostImportantRuleOfUID...
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Rainer makes a few good points. This is not just another weekly software update, this is a high profile interface change. The discussion Max linked to did not have the same scope. And the site notice is just point A in a set of three sensible suggestions. I've followed the development of the Media Viewer and am very happy with how it turned out. On the other hand I can understand that it may pose a disruption in the established workflows of power users. I don't think we should paddle back now though. What we could offer on commons is a banner with a two buttons. One to dismiss the banner, and one to dismiss the banner and deactivate the media viewer (we have the technology for one-click gadget (de)activation already). I'd hate for a negative opinion to build on media viewer because of that. I'm convinced it is a necessary and modern UI that is adequate for most of our end users. Daniel
On Sat, May 17, 2014 at 4:18 PM, Max Semenik maxsem.wiki@gmail.com wrote:
I thought we already had this discussion recently: http://www.gossamer-threads.com/lists/wiki/wikitech/412782?do=post_view_thre...
On Sat, May 17, 2014 at 2:55 PM, Rainer Rillke rainerrillke@hotmail.comwrote:
Recently, Media Viewer[1] (MMV) has been switched at Wikimedia Commons to be default.
As some people do not care a lot for beta features or new features, do not read the mailing lists and overlook main discussion forums or are just unable to understand English, they were surprised and confused and wondered how they could disable the feature.
Please help me to evaluate if there are alternatives to how software deployment is currently done. Here are some suggestions from community member Jameslwoodward (commons adminstrator):
A Post a banner so that there is a good chance of actually reaching everyone. B Ensure that the internally referenced help page actually has correct information. C Major changes can be the default for new users, but should be opt-in for existing users.
I think (A) could be partially done by tech-ambassadors (what a difficult word); however when deploying something like MMV to all wikis, isn't this worth a CentralNotice?
(B) is as obvious as important. Outdated information is confusing. Make sure to update your help pages before going to release your software to the wild. Or delay the release until this is done.
Suggestion (C) is interesting, although perhaps technically difficult to implement. If a feature that one experienced as anonymous user is good [login cookies expire, ...], or one explicitly tested the feature or was told by a fellow about a good feature, it is very likely that one will enable that feature for the account, too. People will do this freely. Without complaining. And people, who intentionally enabled a feature, usually have a positive attitude, are willing to help and improve the feature. They will provide you with constructive feedback. The overall atmosphere would be a lot more positive than that we currently experience with new tools, *the power users do not need*. So why not actively promoting a feature until there is a critical mass using it? It may take a lot of time but I think it's worth a test.
A personal appeal: Please care about the power users [2]. They are the core and foundation of the WMF projects. They create the content; manage most issues - think about the OTRS team - in their spare time, ... so WMF can finally run the fundraiser banners and you can get your payment.
-- Rillke
[1] https://www.mediawiki.org/wiki/Help:Multimedia/Media_Viewer [2]
http://www.aswedeingermany.de/50SoftwareDevelopment/20MostImportantRuleOfUID...
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Best regards, Max Semenik ([[User:MaxSem]]) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Here is an interesting deployment idea, roll out but leave as opt-in for a period of time, after a month or so, set as default for anons and new accounts, During the whole process keep track of who has enabled it and then disabled it, vs never enabled it. After a period of time move everyone who hasnt specifically disabled the viewer to have the setting as default.
This would achieve several different things all at the same time, enabling wider spread testing/debugging, and a phased deployment process that should minimize negative user impact as much as possible. As I have seen way too many "features" pushed out to the general pubic long before they should have been. WMF wikis take mediawiki and wikitext along with templates and the parser and make them do some really odd things. It doesnt matter how much testing you do, quirks will pop up. In a phased deploy process that utilizes both watchlist and central notices this should keep the fallout to minimum.
I actually think that anons should be the last to gget new features if at all possible: they are the group least informed about projects' internal workings and thus it's hard for them to report problems.
On Sat, May 17, 2014 at 3:37 PM, John phoenixoverride@gmail.com wrote:
Here is an interesting deployment idea, roll out but leave as opt-in for a period of time, after a month or so, set as default for anons and new accounts, During the whole process keep track of who has enabled it and then disabled it, vs never enabled it. After a period of time move everyone who hasnt specifically disabled the viewer to have the setting as default.
This would achieve several different things all at the same time, enabling wider spread testing/debugging, and a phased deployment process that should minimize negative user impact as much as possible. As I have seen way too many "features" pushed out to the general pubic long before they should have been. WMF wikis take mediawiki and wikitext along with templates and the parser and make them do some really odd things. It doesnt matter how much testing you do, quirks will pop up. In a phased deploy process that utilizes both watchlist and central notices this should keep the fallout to minimum. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 5/17/14, Max Semenik maxsem.wiki@gmail.com wrote:
I actually think that anons should be the last to gget new features if at all possible: they are the group least informed about projects' internal workings and thus it's hard for them to report problems.
+1
I'm reminded of a type of issue that popped up on flagged revision wikis, where anons get stable versions, and users get newest version - Since the anons were viewing different text, it took a long time for the people with the power to fix things to actually find out things were broken because anyone who could report the issue saw the ok version.
As for A and B - B seems to be a no brainer. A is a bit of a balance. Its hard to know what is too much notification, and when its not enough.
I do think there are probably better ways to handle notification of new features. Perhaps a pop up the first time new feature is activated explaining the feature and how to disable it. I'm not really sure.
--bawolff
Sun May 18 00:20:10 UTC 2014 Brian Wolff bawolff at gmail.com wrote:
I do think there are probably better ways to handle notification of new features. Perhaps a pop up the first time new feature is activated explaining the feature and how to disable it. I'm not really sure.
Yeah, that would be cool: I am tool "x", I do "y" and you can disable me pressing button "z". Let button "z" be a prominent element of the UI for the time of testing at large scale. This way, we can get rid of some of the banners, thus reducing the risk for ~-blindness and some of the trouble. VE has something similar now, if I recall correctly (though the disable-me-button is missing).
-- Rillke
--- I also like MMV as a visitor; but it doesn't fit into any administrator's workflow at Commons most of the time. Perhaps you also want to make it easier for anyone to report issues? Other sites have heavy libraries allowing users to pick the trouble-maker, or take a screenshot and cutting it, ...
I said this during the retrospective about beta features. I think all beta features should be enabled for all logged in users the month before they get deployed. Let's not resort to banners please.
Let's instead train people to go to the beta features page and help us build great products that meet both user and administrator needs upon first release. On 18 May 2014 19:24, "Rainer Rillke" rainerrillke@hotmail.com wrote:
Sun May 18 00:20:10 UTC 2014 Brian Wolff bawolff at gmail.com wrote:
I do think there are probably better ways to handle notification of new features. Perhaps a pop up the first time new feature is activated explaining the feature and how to disable it. I'm not really sure.
Yeah, that would be cool: I am tool "x", I do "y" and you can disable me pressing button "z". Let button "z" be a prominent element of the UI for the time of testing at large scale. This way, we can get rid of some of the banners, thus reducing the risk for ~-blindness and some of the trouble. VE has something similar now, if I recall correctly (though the disable-me-button is missing).
-- Rillke
I also like MMV as a visitor; but it doesn't fit into any administrator's workflow at Commons most of the time. Perhaps you also want to make it easier for anyone to report issues? Other sites have heavy libraries allowing users to pick the trouble-maker, or take a screenshot and cutting it, ...
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 19 May 2014 03:49, Jon Robson jdlrobson@gmail.com wrote:
I said this during the retrospective about beta features. I think all beta features should be enabled for all logged in users the month before they get deployed. Let's not resort to banners please.
This is a much better idea than putting up banners which people learn to tune out. For me, not only do I not read them anymore, but it's gotten to the point now that I don't even notice whether there's even a banner up.
If we were to do this, we should make sure that people are aware upon opting out of the beta feature that their preference will only be respected until it's graduated.
Dan
On Sun, May 18, 2014 at 08:22:13PM +0200, Rainer Rillke wrote:
Yeah, that would be cool: I am tool "x", I do "y" and you can disable me pressing button "z". Let button "z" be a prominent element of the UI for the time of testing at large scale.
For the record, we did the first part of this - there was a link to the preferences page that would let you disable the feature at the bottom of the metadata panel from the day we pushed to the 3rd pilot sites, I think.
As for "prominent", I don't think that's a good idea because it would disrupt the realism of the feature. The purpose of such a feature would be temporary, and when it got removed from the UI, it would cause a (small) jolt to users. We already have a bunch of weird one-time things that are cluttering the toolbar, we didn't need another one disrupting the flow of our product.
If you're a power user, you know where Special:Preferences is, and we made sure to help you out as much as possible if you don't. I don't think we needed to do anything to make the preference more discoverable, it would have been a waste of our time to do so given the other things we have on our plates.
I can't speak to the community side of things - I was under the impression that very few people had actually had that much trouble with the docs, but perhaps the issues with them should be brought up *on their talk page* rather than launching some weird campaign over a feature that, frankly, could not *possibly* have been launched in a more cautious way.
Cheers,
On Sat, May 17, 2014 at 2:55 PM, Rainer Rillke rainerrillke@hotmail.comwrote:
As some people do not care a lot for beta features or new features, do not read the mailing lists and overlook main discussion forums or are just unable to understand English, they were surprised and confused and wondered how they could disable the feature.
Surprised and confused is a good description of how I feel when I visit the main page of Commons and my mouse cursor strays onto the picture of the day. A purple hazard light flares along the edges of the image, presumably intending to alert me to the gross misuse of JavaScript that is about to occur. Then the image pops out like some demented, angry Jack-in-the-box, only nominally larger then the original image (which is still visible below it), but transposed so that it obscures interface elements and page text.
Commons has 17 gadgets enabled by default, more than any other wiki I am aware of. The Foundation could always do a better job. But as the saying goes: good manners begin at home.
Hi Ori,
As some people do not care a lot for beta features or new features, do
not read the mailing lists and overlook main discussion forums or are just unable to understand English, they were surprised and confused and wondered how they could disable the feature.
Surprised and confused is a good description of how I feel when I visit the main page of Commons and my mouse cursor strays onto the picture of the day. A purple hazard light flares along the edges of the image, presumably intending to alert me to the gross misuse of JavaScript that is about to occur. Then the image pops out like some demented, angry Jack-in-the-box, only nominally larger then the original image (which is still visible below it), but transposed so that it obscures interface elements and page text.
Unless I am mistaken, this is galleryZoomHover.js [1]
It has never been made into a gadget.
You and I are two of the mere 11 users (is Special:Search is to be trusted) to have activated this piece of JavaScript in their common.js :-)
[1] <https://commons.wikimedia.org/wiki/User_talk:Rillke/galleryZoomHover.js
wikitech-l@lists.wikimedia.org