On 6 June 2014 16:28, S Page <sp...@wikimedia.org> wrote: > On Thu, Jun 5, 2014 at 4:24 PM, Juergen Fenn < > schneeschme...@googlemail.com> > wrote: > > > You might like to > > know, though, that on German Wikipedia most discussions about Flow > > seem to focus on how to turn it off or how to keep it out of the > > project altogether. Switching to Flow would require a community > > consensus anyway. So could you please consider a global switch for > > communities that would rather like to disable these new features > > completely. > > > > Technically, the Flow extension first has to be installed on a wiki, and > then Flow is enabled on particular talk pages or classes of talk pages on > that wiki (currently 18 pages on production wikis). After a mis-step on > meta-wiki, we seek consensus on both steps. Currently both are PHP changes; > the Flow team is figuring out how the second will work in the future. We > have no plans to install Flow on German Wikipedia let alone on any > particular talk page, so your discussions can focus on other issues. > > The tone of your message made me want to cry, quit my job, and punch the > wall in frustration :( But I appreciate you being open about your dislike > and suspicion of Flow, and can only hope that over time Flow's growing > feature set leads users to *want* it enabled on the talk pages they visit. > > Spage, please don't take the criticism of the product to be a criticism of you or your own work. It's really not about you, or even necessarily about Flow, it's about a much bigger picture.
Flow is a product that wasn't asked for, is intended to do things that people didn't ask it to do, and is a fundamentally different user interface than the two major ones we already have (Mediawiki and VisualEditor). Thus, it is adding complexity to the editing experience that does not currently exist. Mediawiki may be difficult to learn, but it's only one interface. VisualEditor, an interface the community has been seeking for over 10 years, gives a visual result that, from the perspective of the editor, is still a wiki-page; it may work somewhat differently, but it still looks like a wiki. There were four problems with talk/discussion pages that users across multiple communities over multiple years have identified: - Automatic signatures for posts/edits - More efficient method for indenting that is not dependent on arcane wikicode knowledge - More graceful handling of edit conflicts - Ability to watchlist an individual thread or section of a page The first two could undoubtedly be done in Mediawiki; we already have bots that add signatures automatically, for example, and it should be elementary to create an "indent" button that goes in the same line as the other editing icons currently in use. The third point has already had significant work, although more can be done there. I have had several experienced Mediawiki developers say that the fourth point is possible but very difficult. In other words, given sufficient focus, effort, talent and willingness, these issues are all likely to be solvable without creating a new user interface that wasn't requested and is visually divorced from wiki editing. Now, I know it's a lot more interesting and exciting to create something new than it is to make major renovations to something that already exists, and I'm pretty sure after all these years that Mediawiki code is a mess. But I've increasingly been getting the impression that there aren't a lot of WMF staff who actually like wikis, let alone developing Mediawiki core. (Even if that impression is not correct, it's out there and it's based on conversations with WMF engineering staff.) Meanwhile, Flow does automatic signatures, but its current design actually makes indenting much more problematic from a reader perspective than the current indenting structure. It's difficult to tell which post is being responded to, who's responding to whom, the responses don't thread well, and it's not possible to rethread a discussion. Edit conflicts don't exist, but they result in odd threading of responses. It's not obvious how to watch specific threads at this point, or how one would make it possible. In other words, it's not really doing a great job of solving three of the four issues that have long been seen as problems. Meanwhile, it's introduced new issues, many of which users have identified as problematic: endless scrolling, inability to archive, inability to completely remove a thread from a page without actual deletion and/or suppression, categorization issues, complex process to find, create, and edit page headers, etc. There was always an underlying assumption that the benefit of having a large number of engineers working together under the direction and leadership of the WMF would result in a much more consistent process for creating products, better prioritization, and more cross-product consistency. Instead, what we are seeing is that each product team is working in a silo. Common UI issues are being addressed differently across products, increasing the complexity of editing for both new and experienced users. There's no overall integration of the design process, and there really doesn't seem to be a serious master plan that goes into detail about cross-product integration. Yes, there's the roadmap, but it's all individual product teams working on their own product, with very little cross-pollination. In other words, this is a leadership issue that is playing out repeatedly across each product line, and it's pretty much the same issue over and over again, just focused on a different product. It's not the fault of the back-room engineers; it's at the PM level and above. Risker/Anne _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
