Hoi, I am afraid you do not get the point. The point is that the desktop as we know it is our history. It is like the Dodo; something that is best experienced in the museum to be replaced by something contemporary in the real world. The development of a single UI is what you should consider and expect and it should support any platform. What the Mediaviewer does is move us away from a cluttered unintelligible page of data junk for those who are not initiated. It is a step towards something intelligible that may be supported on any platform. Yes, what you hear is people whining about their desktop experience. They want to keep things as it is and, any argument, any approach is fine as far as they are concerned. Our desktop experience has improved somewhat over the years but it is all the ballast of the past that is keeping us back. It is all the byzantine embellishments that are so "important" to have. But really, when people like myself refuse to edit Wikipedia because the experience is so bad you have lost with me more than is justified by insisting on the status quo. Ask yourself, who do we do it for and who should be able to edit. FYI I was involved in Wikipedia before there was a Wikimania. Thanks, GerardM On 15 August 2014 10:02, Pine W <wiki.pine(a)gmail.com> wrote:

On 15 August 2014 06:08, Todd Allen <toddmallen(a)gmail.com> wrote: This is a false dilemma. The WMF does not have any plans to stop developing desktop features. On the contrary, the VisualEditor team recently changed scope to be the Editing team in part so that the scope of their team also included maintaining the wikitext editor on desktop. Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

On Aug 17, 2014 6:49 AM, "Richard Farmbrough" <richard(a)farmbrough.co.uk> wrote: product MediaWiki itself has 4893 open bugs. Guess we need to start over so we can write bug-free software. Except that's not how it works, absolute bug counts are a pretty useless metric. -Chad

And that is a common community complaint, games communities, social communities, and content communities. They all say "fix the bugs before working on new stuff." Developers prefer working on new stuff, managers prefer working on new stuff. Where's the kudos from making things bug-free? But that is what is needed. On 17 August 2014 13:48, Comet styles <cometstyles(a)gmail.com> wrote: -- Landline (UK) 01780 757 250 Mobile (UK) 0798 1995 792

Well, hold on here. On 17 August 2014 19:55, Pete Forsyth <peteforsyth(a)gmail.com> wrote: Given the current use of bugzilla, which doesn't limit itself to bugs but also feature requests and enhancements over the base functionality, calling everything reported using bugzilla a "bug" is incorrect and inappropriate. The Commons/File pages don't do that, why would you expect this software to do it? Agree this is important. Do you have any evidence that it is any less accurate than the Commons/File pages? The mere fact of the image being used on an article anywhere on a Wikimedia project suggests that this problem is in the actual usage, not in the software being used to display more information and detail in the image. If you believe that this is a serious issue, then it should be addressed where 100% of readers can see it, not in a subpage viewed only by the limited number of readers who click on the image. It's not a Media Viewer problem, it's an image usage problem. What problems are you seeing here? Spell it out, rather than making vague suggestions that there is an issue. Why is this a Media Viewer issue? This is a problem for all types of software on all types of platforms, and is a challenge even for IT departments hundreds of times the size of the WMF. I cannot think of any software I have used in the last 20 years that has not had "bugs" or unsatisfactory UI elements or seems to miss a functionality I'd like to have. It is unreasonable to hold a comparatively very small organization to a standard that can't even be met by IT giants. Risker/Anne

On 17 August 2014 20:25, Pete Forsyth &lt;peteforsyth(a)gmail.com&gt; wrote: Perhaps you should get to know a bit more about bugzilla and its current usage; of the 104 current reports on Multimedia Viewer, 16 are enhancements and several others that are currently listed as "bugs" of varying importance/urgency are "features" that don't appear to exist in the "standard" format for viewing images or are so badly designed in the File pages that they're almost impossible to call acceptable in that format, either. Someone who is better able to describe the developer functions could better describe the planned changes from the use of Bugzilla to Phabricator, which is a more flexible platform that (I understand) is intended to consolidate several different design/development/improvement/bug reporting platforms currently in use. But right now, bugzilla is at least in some cases used as a platform for the design process of just about everything to do with MediaWiki, its extensions, and all the other platforms that are in use/developed by WMF. Every single type of software used on Wikimedia project sites, as well as software for other features provided by the WMF, has bugzilla reports. There are thousands for MediaWiki, the core software of the project. We haven't thrown in the towel on it just because it's got lots of bugzilla reports. I'm sorry. How, exactly, do you envision a new editor or reader improving file pages? There's not very much that can be edited there that isn't going to cause more problems than it solves. Should they modify the author? Change the license? Add (potentially non-existent) categories? When the chances of reversion are nearly 100%, it's not necessarily a net positive to make a big deal about the existence of an "edit" button. Media pages are not really comparable to (written) content pages. I'd rank file pages as possibly the worst place to suggest that new editors just jump in, with the possible exception of templates. <snip> Wikimedia This point has a lot of nuance in it, and I'm happy to discuss it, but not I am at a loss as to why a template on Commons has anything to do with the privacy of subjects of photos. And yes, I read that entire page over twice. Templates are simply a manner in which to facilitate the level of adherence to certain policies (and in some cases legal requirements); they're not the place to discuss over-arching philosophy. Well, if you don't have a problem with it, why are you including it in your list of problems? This is exactly how what might very well be a problem for a very small number of users gets inflated to be considered a big issue for a large number of users. For the record: I don't care one way or the other; I can use file pages, I can use MMV, and since I don't do a lot of file work either is fine for me. I didn't opt in before hand, but I haven't opted out since it went live. It would be helpful for others to give serious thought to why they've decided to opt in (before) or opt out (after default deployment) and then report this so that realistic data can be collected. I'm going to be honest, I've seen a lot of "I don't like it", but I've also seen some good reasons, for personal decisions either way. I've not seen a lot of good arguments for disabling it for readers, though, especially as it exists today. Your comparison in your initial post was to a policy discussion on the Terms of Use, which you felt went well. And yet, this was a discussion on a single site, Meta, where very few Wikimedians participate; there was no particular outreach to projects except to meet the legal obligation of making reasonable efforts to notify users of a change in the TOU. For MMV, we have, at minimum: - Beta features option in the user preferences for all users on all projects. Unfortunately, an administrator unilaterally removed this preference tab on dewiki, thus withdrawing the opportunity for any users on that project to opt in and test and comment on this and other software throughout the stages of development. I understand this has now been restored, and look forward to seeing comments on many software changes from our colleagues on that project. Or not - it's their choice. - Posts on Village Pumps and other appropriate locations on hundreds of project sites - Information provided to site-specific information dissemination functions (e.g., Signpost on 14 May 2014 and earlier) - Active attempts to seek out user opinions through questionnaires. (Yes, I know there was some perception of bias in the wording of some questions. Nonetheless, this is an additional opportunity for gathering information that was not used for the TOU.) In other words, you thought a discussion on a single site went well, but one that took place across hundreds of sites didn't do enough to inform people and seek feedback. Do you see why I am perceiving a bias on your part? Commons has a very different use case for information about files and media than any other project site in the Wikimedia family, and it seems to me that the WMF listened when that community pointed out their differing needs; again, despite lots of advance notice it seems that not a lot of Commons users communicated these concerns before deployment. Both Enwiki and Dewiki have had a troubled relationship with the WMF (and particularly the Engineering & Product departments) in recent history. In the case of enwiki, though, an RFC on this specific topic still could only draw 64 editors supporting opt-in for MMV (as opposed to opt-out or default status). Dewiki had stronger support for moving away from default status, although this was the project that had little opportunity to test in advance because of the removal of the opt-in option in advance of its deployment there. That was a shame, because our dewiki colleagues have often provided very useful comments and recommendations for improvement of other software in development. In other words....everyone has something to learn here, but perhaps the most important and valuable point is that changes are going to keep happening across these sites - in fact, they're made every week, although not always as major as this - and there is a huge need from all sides for users to participate and identify concerns while software is being developed so that problems that aren't necessarily obvious to developers will be flushed out before largescale deployments. At the same time, product managers and developers need to work with users to identify the difference between minor concerns and concerns that should be considered "blockers" as software is being developed/improved/modified/etc. Risker/Anne

On 18 August 2014 03:53, Pete Forsyth &lt;peteforsyth(a)gmail.com&gt; wrote: As I stated in my response, although the WMF failed to predict that this would be a hot issue, I predicted it clearly in February, and so did another longtime community member. (If anybody wants to see that other piece, let me know -- I now have permission to share it, actually an IRC log, not an email.) https://meta.wikimedia.org/w/index.php?title=User_talk: LilaTretikov&diff=9512960&oldid=9512915 (and the reference link: https://www.mediawiki.org/w/index.php?diff=907392 ) Wow, Pete. You predict something will be rejected by the community, and identify a list of concerns. Several months later, you apply the code that applies a community "rejection". This brings the term "self-fulfilling prophecy" to a whole new level. Just wow. Risker/Anne

I'm approaching this thread with some trepidation, but would someone mind telling me more about this - or pointing to where this issue is already documented? (I have no idea how to navigate Bugzilla ;) ) Regards, Chris

Hi, On Mon, 18 Aug 2014, at 10:12, Risker wrote: It does. There is an Edit button at the top, and an Upload button at the left. Showing description is important for privacy of subject of photo in some cases. I.e. if I kill a cat for a movie and someone takes a picture, I should be able to tell readers that I'm doing this for a movie. The long description usually does so, if needed. Otherwise the readers might perceive that doing this is my usual activity. This is probably not the original issue in mind of the first folk who mentioned privacy two paragraphs up there, but that's the first thing I can think of. Another thing is slideshows. "The Big Pictures" website lets people browse pictures with long descriptions. We have galleries, and MV's left/right arrows. Why not make something in the middle, with both a long description/caption, and these left/right arrows? MV is inconsistent, because other pages (history, talk) still force a page reload, for instance, and returning from them back to an article isn't as easy as one 'X' button. No comment on this one. svetlana