| Revision as of 13:00, 5 February 2014 editFram (talk | contribs)Autopatrolled, Extended confirmed users, Page movers, IP block exemptions, New page reviewers, Pending changes reviewers, Rollbackers, Template editors247,563 edits →Flow + Echo = Error?: Further...← Previous edit | Latest revision as of 08:56, 30 December 2023 edit undoSänger (talk | contribs)Extended confirmed users673 edits Undid revision 1192604098 by Nathan ejersa (talk) vandalism revertedTag: Undo | ||
| Line 1: | Line 1: | ||
| {{info|Please use ] instead, for centralized feedback.}} | |||
| {{info|This is the page for suggestions, comments, and other collaboration, on '''how Flow works''' (features/functionality).<br /> To discuss the '''design aspects''', please use ] instead. Thanks! }} | |||
| {{info|Note that the prototype is being updated very frequently at the moment (whenever code changes are ready for testing). Much of the functionality is not fully built, and the design is rapidly changing. It is '''not''' the finished product! }} | |||
| {{User:MiszaBot/config | {{User:MiszaBot/config | ||
| |archiveheader = {{aan}} | |archiveheader = {{aan}} | ||
| |maxarchivesize = 150K | |maxarchivesize = 150K | ||
| |counter = |
|counter = 15 | ||
| |minthreadsleft = |
|minthreadsleft = 5 | ||
| |algo = old( |
|algo = old(15d) | ||
| |archive = Misplaced Pages talk:Flow/Archive %(counter)d}} | |archive = Misplaced Pages talk:Flow/Archive %(counter)d}} | ||
| {{archive box |auto=yes |search=yes |bot= |
{{archive box |auto=yes |search=yes |bot=Lowercase sigmabot III |age= 15 |units= days |index=/Archive index}} | ||
| {{User:HBC Archive Indexerbot/OptIn | {{User:HBC Archive Indexerbot/OptIn | ||
| |target=/Archive index |mask=/Archive <#> |leading_zeros=0 |indexhere=yes}} | |target=/Archive index |mask=/Archive <#> |leading_zeros=0 |indexhere=yes}} | ||
| == Flow was just renamed to "Structured Discussions" == | |||
| == Report on Infinite scrolling == | |||
| As if discussions on talk pages are not structured, the WMF in it’s infinite wisdom just decided to rename Flow to '']'', the official ratio is this: | |||
| Yesterday's ] column from the ] publishes . Some highlights: | |||
| :Structured Discussion was formerly known as “'''Flow'''”. Flow was a bigger project that has been re-scoped to focus on user-to-user discussions. The software has been renamed to reflect this change. | |||
| They fail to see the difference between a structure and bondage gear. And they obviously hate flexibility. Grüße vom ] <sup> (])</sup> 19:57, 14 September 2017 (UTC) | |||
| :Wikitext talkpage are "structured" in a way that editors who are accustomed to the system can understand, but not always intuitively, e.g. interleaved comments, or inconsistent indenting, or bulletpoints mixed with colons. | |||
| :Wikitext talkpages are not "structured" in a way that software can understand. E.g. the indented quote you pasted above, is not programatically identifiable as being written by you, except by analysing every single revision ever made to this page and significant changes to the "diff" system (which is easily confused by refactored (moved around) blocks of text). | |||
| :Just like templates and databases bring consistency (and the possibility of powerful new features) to structured data, a structured discussion system brings consistency (and the possibility of powerful new features) to human discussion. | |||
| :I know you dislike it, and I don't want to argue, but please ask any programmer that you respect for confirmation that wikitext talkpages are ''not'' "structured" in a software-sense. ] (]) 20:30, 14 September 2017 (UTC) | |||
| ::Talk pages have the same structure as every other page at Misplaced Pages. Anyone who cannot deal with a talk page is unable to contribute in a useful manner. Of course people need help for their first few posts (and first few article edits, and first few attempts to add references), but help is part of a collaborative community. A simple script to add a comment is all that is needed: guess what indent to apply and whether to add four tildes. The script would cover most usage cases for a new user. Flow is fine for baby talk or for discussions where hard facts are being discussed, such as when someone is asking an expert how to perform some operation. Flow is useless for typical discussions concerning disputed topics with multiple views from multiple people. ] (]) 23:06, 14 September 2017 (UTC) | |||
| :::I agree entirely with ]. I hope that the statement on the project page that there is no intention to return Flow to tne English Misplaced Pages is still correct. ] ] 09:12, 24 September 2017 (UTC) | |||
| * Continuous scrolling is advantageous for content that streams constantly and has a relatively flat structure, where each unit of content belongs at the same level of hierarchy and has similar chances of being interesting to users. | |||
| ::], I'm a programmer and I fully understand what you mean about structure. However 99% of the people on the planet aren't programmers. The name "structured discussions" may be obvious and natural ''inside'' the WMF, but it isn't going to be so natural and obvious for people who don't know about software internals and don't care. Under the plain-English meaning of the word, any normal person would say 'yes, the Misplaced Pages article for United States is structured'. This new name is clumsy, confusing, and trying to rename the project is pointlessly disruptive. We have countless megabytes of discussions and information about Flow. Are you going to spend the next few years trying to argue/correct people who keep calling it Flow? People who say Flow either because that is the only name they know, or because it's 18 characters shorter, or because they are using the most common name to ensure other people understand what they are discussing. You're really fighting human nature on the '18 characters longer' point. You'd have an easier time getting people to switch to 'Glix' or 'Zopy'. ] (]) 09:03, 15 September 2017 (UTC) | |||
| * Infinite scrolling has advantages, but should be applied with caution. Endless scrolling is not recommended for goal-oriented finding tasks, such as those requiring people to locate specific content. Finding by feature might be difficult to accomplish quickly if all of the are presented linearly on a never-ending page, without sorting or other filtering or navigation techniques to help isolate the intended item. | |||
| ::Talk pages are for humans, the software is just a tool. If software can't read it, so what? It's the humans that should be able to read it in a proper way, and I don't think any human will have a problem with the structure of this topic right now. They will even grasp intuitively that this is an answer to you, and not to Alsee. If machines are not able to grasp it, they are not fit for talk pages, that's all. Machines are nothing we should put up first, they are just tools, not subjects. Grüße vom ] <sup> (])</sup> 09:13, 15 September 2017 (UTC) | |||
| :I think that the discussion from top to bottom and infinite scrolling are really the principal nuisances of Flow, whereas the current talk page format I have difficulty in telling posts apart and to figure out which indentation to use, and having to sign posts and needing a bot for this is also irritating. Granted I am more used to the discussion style of ] which is very similar to Flow. I am interested to know whether users who are not long accustomed to Misplaced Pages would find such a modified Flow easier or harder to comment on than the current talk page format. ] (], ]) 15:35, 18 September 2017 (UTC) | |||
| == Rework of page content == | |||
| * Locating a previously found item on an extremely long page is inefficient, especially if that item is placed many scrolling segments down. It’s much easier for people to remember that the item is on page 3 than it is to gauge where the item is positioned on an extremely long page. | |||
| I did some HEAVY cleanup. I figured that this page was rather unreadable if you don't really care about flow development and just wanted to find out what it was about. Most of the information was 2-4 years old and did not help any user who is currently reading the page. Most information was duplicate with the mediawiki.org pages to begin with. I considered it best to keep to a short description of the product and its intent, a description of the current state, and the links to the relevant team and product pages. | |||
| * Endless scrolling can hurt the user experience as well. For task-driven activities, infinite scrolling can feel like drowning in an information abyss with no end in sight. | |||
| Is there anything that should be re-added that I had not considered ? —] (] • ]) 14:11, 15 September 2017 (UTC) | |||
| : Should this page now be moved to WP:Structured Content, to match the mw: one? Though most of us here probably think of it as "Flow" now, it has a new name which will become the main name its known by as it continues to be maintained and developed.--<small>]</small><sup>]</sup><sub style="margin-left:-2.0ex;">]</sub> 17:40, 15 September 2017 (UTC) | |||
| ::Maybe we wait until it really is the new name everywhere? I just looked at the "Beta" preferences on Wikidata, and there it is still called "Flow". —''']''' (]·]) 20:37, 15 September 2017 (UTC) | |||
| :::It is the new name everywhere, see . It just takes a few days before it's updated to MediaWiki wikis. ] (]) 07:51, 18 September 2017 (UTC) | |||
| ::::No rush though, another week won't be a problem :) —] (] • ]) 09:00, 18 September 2017 (UTC) | |||
| So if we do move... do we move all subpages with it ? See: ] and ] —] (] • ]) 07:46, 22 September 2017 (UTC) | |||
| :{{ping|TheDJ}} I would just move this page and talk. The others are just historical, but would have to be rewritten otherwise. ] ] 14:39, 23 September 2017 (UTC) | |||
| ==Concerns about flow== | |||
| * With pagination, there is a beginning and an end. There is a happy sense of completion when a page is reviewed. Pagination gives people control to decide whether or not to continue to the next page. | |||
| I have concerns that Flow will result in no technical support for the current talk page system. It is claimed that wikitext cannot allow "per-topic notifications". I am not convinced this is true. One could improve the current wikitext so that it does allow this. ] (] · ] · ]) 18:44, 23 September 2017 (UTC) | |||
| * Infinite scrolling breaks the scroll bar by causing it to display the page length inaccurately. | |||
| :The current talk page system does not seem to need additional support, or so it seems to me. ] (], ]) 19:26, 23 September 2017 (UTC) | |||
| ::I would love the ability to watchlist sections of talk pages. This is something many have requested. I do not see that it would be that hard technically. Would also be nice to have a version of VE that works on talk pages so new and old editors do not need to learn two or three systems of editing. ] (] · ] · ]) 19:39, 23 September 2017 (UTC) | |||
| :::According to ] there is a moderately complex solution for a particular case. Watching sections of pages in general would require a significant change of how wiki pages in general work. Making Flow compatible with standard markup is potentially a different solution to the "systems of editing" issue, not sure how hard that would be. ] (], ]) 09:30, 24 September 2017 (UTC) | |||
| ::::It seems fairly clear, standing back from details to see the big picture, that making Flow compatible with standard markup is an unrealistic goal. Trying to make a fundamentally different platform "pretend" to be like another, such as in this case, swallows up unbounded amounts of expert labor to chase after an unending supply of flaws in the pretense. It's easy to make things look just the same if at their foundation they really ''are'' the same, and ultimately hopeless to try to make them look just the same if at foundation they aren't. <p> There is, tbh, a structural flaw in the way the Foundation is positioned relative to the sisterhood. The Foundation has a powerful impulse to apply expert programmers to developing stuff for the sisterhood. What would actually be good for the sisterhood? A stable, simple, easy-to-use markup platform that vastly empowers volunteers, giving scope for their imaginations. This, though, clashes severely with the Foundation's impulse — in the long run, the Foundation's impulse leads to perpetual platform instability in the name of having expert programmers add things ''instead of'' empowering the volunteers to do them. Could the Foundation resist this impulse? Perhaps — supposing a concerted effort at the Foundation to build that resistance into its corporate culture. It's all made even more difficult because figuring out how to empower volunteers with simplicity is a much harder design task than adding specialized features that increase volunteers' dependence on tech support — and the harder design task flies in the face of what commercial social-media platforms seek to do (hence a fatal flaw in the Foundation ''comparing'' itself to any commercial platform). --] (]) | |||
| :::::Just a note.. If I read some of the tickets that are currently under consideration correctly, then it seems that Structured Discussion posts will be stored in wikitext again. Which doesn't mean they will be wiki pages, as there is a difference between a page and it's storage format (and in this case even the storage format of a part of the page), but does make sure that they'll be closer to wiki code parsing. —] (] • ]) 08:19, 25 September 2017 (UTC) | |||
| ::::::For what I know, that means only that every individual post will be stored in wiki markup; the structure of the page itself will not be represented by markup, but by a relational database schema. This is not closer to a wiki system than before, since it doesn't allow editors to define the structure of the page; as Pi zero said, Flow is a ''fundamentally different platform'' at its core. I find Pi zero's comment most insightful - the best the Foundation could do is empower the community to build and improve our own tools, but the WMF's gravitas pushes it towards building simple tools that will make editors more dependent on developers. ] (]) 08:51, 25 September 2017 (UTC) | |||
| :::::::"the structure of the page itself will not be represented by markup, but by a relational database schema." That is correct. —] (] • ]) 09:36, 25 September 2017 (UTC) | |||
| :I don't think we are likely to ever have section watch listing.. Let's put it this way. If equals signs for headers are deprecated, and instead people need to use buttons like: Add new section, Remove section, Rename section, maybe then, we can think about watch listing sections. Before that, it seems highly unlikely to me. —] (] • ]) 08:19, 25 September 2017 (UTC) | |||
| ::What does the internal representation have to do with the user interface? Equal signs for headers are good enough for the parser to detect the location of each subsection for the Table of Contents, editing sections and creating edit summaries; I don't see a reason why they couldn't also be use to generate targetted notices. ] (]) 08:53, 25 September 2017 (UTC) | |||
| :::Header identifiers are not unique, not stable, don't reliably indicate start and/or end of a section, aren't stored atomically (we store pages, not sections) and can be moved or even deleted, untraceably from pages. Retroactively adding or inferring such details from wiki code is fragile and complex (building a parser on top of a non-stable parser) and most importantly I think, terribly resource intensive as well. We are already having trouble with people with 100000 or more pages on their watchlist, if we additionally would have section watch listing implemented with such weak underpinnings, watch lists would become a significant performance problem for which there would not be an immediate solution. I went with explaining this problem in UI concepts :) —] (] • ]) 09:32, 25 September 2017 (UTC) | |||
| ::::There is an alternative approach detailed in the ticket, where we basically ignore most of those problems (Nemo's approach). I personally call this the 'lossy' variant. But I think that a big reason people have reservations about that approach, is that it's just moving the goal post of complaints. So when that works (still, or possibly with even MORE performance problems btw), people will start complaining about sections suddenly disappearing from their watchlist, archiving not working etc. and will be stuck further down on the dead end road —] (] • ]) 09:51, 25 September 2017 (UTC) | |||
| :::::I think that 'lossy' variant has great potential, and would be a welcome improvement, covering a large number of cases. As long as its users develop an accurate mental model ("you're following a section named '' 'xyzzy' ''"), they would understand why and how the section is no longer being followed (e.g. "section '' 'xyzzy' '' has been renamed to '' 'foobar' ''"). The software could avoid complaints by providing support for fallback situations, such as issuing a last notification when the section is renamed or archived, and/or going back to tracking the whole page in those cases (with a notice explaining the cause). ] (]) 10:21, 25 September 2017 (UTC) | |||
| ::::::{{replyto|Diego Moya}} How would you expect multiple watched sections on the same page to be handled in such a situation ? —] (] • ]) 15:02, 25 September 2017 (UTC) | |||
| :::::::{{replyto|TheDJ}} By creating several search filters for the same page, one for each followed thread, and each with its own text pattern, no? I don't see any particular problem in that. More problematic would be what happens if several sections share the same name, like "Arbitrary break". But even then if users are aware of how the filter works, i.e. that you subscribe to "sections with string YYY in their title". And the community could work around the problem, by avoiding exact duplicate titles. I think that's a small price to pay for the flexibility of avoiding a strict discussion model with unique IDs for each thread, and is consistent with the mental model of "everything in a wiki is a raw text string with markup". ] (]) 17:55, 25 September 2017 (UTC) | |||
| :"no technical support for the current talk page system" There is no current talk page system. There is no functional difference between a wikipage and a talkpage, other than that wikipages have even namespace numbers and talk pages have uneven namespace number. Both therefor have the exact same amount of technical support. —] (] • ]) 09:43, 25 September 2017 (UTC) | |||
| '''Alternatively''', there is a feature I've had on my wish-list for years. For lack of a better name (suggestions?), call it "subwatch". The idea is that, in addition to marking certain individual pages as watched, one can mark certain pages subwatched; subwatching doesn't ''directly'' affect which edits show up on your watchlist, but it does ''help'' you to watch subpages of that page. Thus: | |||
| Other analysis I've found for the usability of infinite-scrolling pages are and providing a framework to study their usability. While results are still inconclusive, it seems to me that the infinite scroll metaphor is suitable for content consumption, but it's a bad choice for directed tasks such as collaboration and retrieval of archived content (two central goals of Misplaced Pages talk pages). As the focus of design in FLow is to ] for inspiration, I'd want to ask which research was evaluated when the choice to use an infinite scrolling interface was made, and whether you will ponder some alternative designs on the light of these findings. ] (]) 13:00, 3 February 2014 (UTC) | |||
| * At the moment you first mark a page P for subwatch, P and all its subpages go on your watchlist. | |||
| :That's fantastic research, Diego; thank you for undertaking it and for providing us with the results :). ], read! ;p. ] (]) 19:27, 3 February 2014 (UTC) | |||
| * Whenever a new subpage of subwatched P is created, that newly created page immediately goes on your watchlist. | |||
| ::], yes, thank you again for gathering this info you're points are well taken for flow its interesting because some users will be mostly consuming and others consuming and contributing (task based interface) while we'd love for everyone to be part of the conversation (a major product and design goal for flow) we do want the information to be easily understandable very quickly for someone who isn't already part of the community or a specific discussion. We're working on search, we have multiple view formats for a board and the ability to deep link into a specific conversation or share a marker to a specific comment or tangent. We're investigating ways to display the right content at the right time, e.g. initially hide or show tangent replies? what level of default expansion do we show to new users, etc. | |||
| * Those are the only two things that are actually done by subwatching P. At any time you can choose to unwatch any subpage of P, or you can even unwatch P itself, with no affect on the subwatch on P: even though you might not be watching P itself, any newly created subpage of P will be automatically watched. | |||
| You could, for example, set yourself up to automatically watch all nomination pages for a certain type of nominations, and then you could unwatch the ones that you decide aren't going to be of ongoing interest to you. On Wikibooks, of course, this could be ''hugely'' convenient, if you're interested in a particular book and want to know about anything done to it (including addition of new modules to the book). On Wikinews — and perhaps elsewhere, who knows, perhaps even on Misplaced Pages — one might set up some sort of hierarchy discussion arrangement that would put each comment on a separate page and use the subwatch facility to help tie them all together. --] (]) 17:32, 25 September 2017 (UTC) | |||
| :{{ping|Pi zero}} That would be ] I believe. ] (], ]) 18:57, 25 September 2017 (UTC) | |||
| :: {{ping|Jo-Jo Eumerus}} Hm. Interesting. There seem to be some similarities. I think what I'm describing would be much simpler to implement, easier to use, and perhaps effectively more powerful because of its simplicity. --] (]) 19:10, 25 September 2017 (UTC) | |||
| :::Using subpages is what LQT basically did. If I remember correctly, that was causing significant performance problems though (exploding the pages table of the database). Not sure if those performance problems would still be an issue. —] (] • ]) 20:30, 25 September 2017 (UTC) | |||
| :::: Well, sort of yes. Using subpages is certainly ''part'' of what LQT does. It also does some other things that are quite unpleasant (although we still use LQT on en.wn, to this day, even though we agree it's nasty for most purposes, because for the specific thing we use it for we've found it more effective than a wiki page — and yes, we did discuss Flow some time back and concluded that, for the one purpose where LQT was more effective than an ordinary wiki page, it was also superior to Flow... but I digress). --] (]) 20:51, 25 September 2017 (UTC) | |||
| ::::: I might point out, though, that the device I'm describing would, I believe, be immensely useful for the other things I was mentioning, regardless of whether one chose to use it in that particular highly-inefficient way. Granted, the relevance to the current discussion ''is'' for talk threads. --] (]) 21:08, 25 September 2017 (UTC) | |||
| ::::::: (Or I could just be misunderstanding the other proposal... sigh. Well, the current notification system does a lot to improve things.) --] (]) 14:25, 26 September 2017 (UTC) | |||
| I wrote up this essay about improving wikitalk a couple years ago, back when some people were still serious about implementing flow. Everything I wrote remains valid. ]. ] (]) 17:04, 3 March 2018 (UTC) | |||
| == WMF is refusing to uninstall Flow on Commons == | |||
| ::to you specific question about how are things findable in infinite scrolling interfaces? we have to work within the framework of the browser, e.g. you can browser find on page, something that isn't technically on the page at that point. How do you handle the state change when someone leaves a page and comes back via browser history buttons, to me these are mostly technical hurdles and I'm confident we can solve them. Check out http://developers.soundcloud.com/docs to see an interesting way they've delt with location in a long document, both via the TOC and a url hash. I think something like this plus some basic browser history manipulation could make the experience great for users with infinite scrolling. | |||
| {{archive top|This is not an enwiki issue and the poster has been cross posting this across projects. Feel free to follow up either at the commons thread or the meta thread (]) if you care. — ] <sup>]</sup> 12:02, 3 March 2018 (UTC)}} | |||
| Commons established ], as was done on EnWiki and on WetaWiki. The WMF has just posted a ]. ] (]) 04:25, 3 March 2018 (UTC) | |||
| ::I think only with some real world testing after the launch to the initial participating wikiprojects will we be able to answer some of the questions this poses. ] (]) 21:24, 3 February 2014 (UTC) | |||
| :::We do? Exactly who do we think will be simply reading the talkpage without any intent of contributing to it? ] (]) 22:07, 3 February 2014 (UTC) | |||
| ::::@]: Any answer on ]'s question above? I can't imagine anyone coming on a board (discussion page) only to read everything that's already there, indefinitely until he reaches the end of the board, without being somehow involved in a task. That task could be the intention to contribute to some of those discussion topics, the intention to start a new discussion topic if there isn't already one about the matter he has in mind, the hope to find some conclusions on a previous discussion that could guide his current work on an article or help him understand the background of some decision, the need to assess a user's behaviour (in contexts such as anti-vandal fight and ArbCom)... whatever except just reading because he has nothing else to do ! In my opinion, discussions are not the type of content that people would just consume without being involved in any kind of task. ] (]) 11:41, 5 February 2014 (UTC) | |||
| :I personally think Flow is wholly unfit for its stated purpose (and that's putting it mildly), but in this case I see WMF's response as reasonable. ] (]) 05:12, 3 March 2018 (UTC) | |||
| :Thanks. When you can search (more like filter) a Flow board to only show matching topics, I hope we'll get the best of both worlds. If you're collaborating on a particular topic, I think you would start with its permalink. With existing talk pages, following a link like ] when the section has been renamed or archived is very frustrating; permalinks are better in that you'll always get to see the topic, and we're working on making the UUID of the post a little shorter (but still opaque). -- ] (]) 22:00, 3 February 2014 (UTC) | |||
| ::] when you say the response is 'reasonable', do you mean that you would personally find it an acceptable result? Or do you mean you think it reasonable and worthwhile for the WMF to battle and further damage WMF-community relations over this? Especially when a volunteer dev has already done the work writing the patch to carry out the task? ] (]) 06:20, 3 March 2018 (UTC) | |||
| ::Yes, true permalinks would be an improvement for archiving. But I'd rather have permalinks and search results work as an entry point to the infinite stream, not only to see the linked topic isolated. I.e. following the link should show that topic at the top of the screen, but it should still be possible to navigate down and load the other earlier topics as "more content" (and probably there should be a link at the top to load "newer content" too). That truly would achieve the best of both worlds. ] (]) 23:15, 3 February 2014 (UTC) | |||
| '''Note''': The WMF has opened a to '''build a superprotect level for Flow'''. ] (]) 06:14, 3 March 2018 (UTC) | |||
| :Um, to me it reads like they are planning to remove all flow content sans some log entries, and that "superprotect" thing sounds more like permanent archival to me as well. ] (], ]) 09:39, 3 March 2018 (UTC) | |||
| {{archive bottom}} | |||
| == |
== Talk pages consultation 2019 == | ||
| ::'''Testing can be done at ]. Thanks!''' | |||
| ::''Newer code (arriving here soon) can always be seen at ], or even newer code at http://ee-flow.wmflabs.org/Sandbox.'' | |||
| Hi folks. I'm pleased to announce that, with the permission of the users involved, we've deployed Flow to ] and ]. Obviously, the intent is for editors to use the Flow boards as they would a normal talk page, so please don't use it for testing (unless you're a wikiproject member, of course!) - just use the test space at ]. If you've got feedback, please feel free, as always, to leave it either here or on the ]. We'll be asking them directly in 2/4 weeks whether they're happy to continue testing, but will greatly appreciate all the feedback you all can give in the meantime. Once the first set of WikiProject members have had a chance to try out the software, we will be seeking other WikiProjects to volunteer for participation in this working-environment testing. ] (]) 22:15, 3 February 2014 (UTC) | |||
| : Basically as predicted: I tried to watch ], which made my watchlist unusable: About half of the top screen are taken by the activity of the Wikiproject talk. Unwatching now until smth gets modified.--] (]) 22:37, 3 February 2014 (UTC) | |||
| ::My experience from the Flow talk page on mediawiki.org is much the same. The truth is, it will require a slight shift in behavior. Unless you ''really'' want see all discussion activity, I would just unwatch a Flow board and instead wait for notifications that are built in when someone replies to a thread you're participating in or mentions you. <font style="font-family:Georgia, serif;">] • ]</font> 22:55, 3 February 2014 (UTC) | |||
| :::Well, no, because then you never get to actually see what's going on unless you've already participated. ], this is a bug, not a feature; we'll be fixing and limiting it in the next 2 weeks. ] (]) 22:58, 3 February 2014 (UTC) | |||
| ::::@]: really? It would be nice but doesn't seem to correspond to what ] replied to ] on just 7 days ago. Could we get new feedback there, also on the proposals made by ] and myself ()? ] (]) 11:58, 5 February 2014 (UTC) | |||
| :::::Klipe, the permalinks generated by Flow are not working in Wikitext. This had been noted at MediaWiki, but not corrected yet, and not disabled either. The point of keeping the permalinks active while they can't be used correctly escapes me, but it doesn't really surprise me. ] (]) 12:01, 5 February 2014 (UTC) | |||
| So if you're hiding this, will normal users get to see a topic has been replied to, as normally shows up on a watchlist or will you have to go to a talk page to discover what discussions have been going on? Also, why is the font so big? Finally, the Flow project has (I assume temporarily) wiped the history from WikiProject Hampshire and only replaced it with the Flow discussion history. ]]....] ''disorganising disorganisation for just 7 years'' 00:02, 4 February 2014 (UTC) | |||
| :{{reply to|Simply south}} Re: watchlist contents - there's definitely some tweaking needed, both immediately, and over the long-term as new features (such as per-topic watchlisting) get added. In the short-term, I believe they'll be aiming to get it to display as we expect (ie. only showing the last/most-recent change to the Board). But ideas for how it could be even better than the-standard-watchlists-we-have-now, are warmly appreciated. (Some ideas have already been put forward, but not compiled yet. Plus I'm hoping that we'll get some new/unique ideas if editors aren't presented with a list of options, but rather are given a blank slate to dream upon..) | |||
| :Re: Font size in Flow Boards - there's an ] that briefly touches upon this issue (linking to a single ref). I'll ask the design team for additional info. | |||
| :Re: History - I did a page-move archive so that ] was easily accessible. :) ] (]) 00:26, 4 February 2014 (UTC) | |||
| The foundation is running a consultation on what to do about Talk_pages (implicitly including discussion of what, if anything, to do about Flow). Everyone is invited to participate in the RFC at ]. ] (]) 13:56, 24 February 2019 (UTC) | |||
| == First impression == | |||
| == request info == | |||
| I'm not involved in the participating WikiProjects, so I didn't do any testing, just had a look. Here's my very first impression: | |||
| * The fonts are huge. My first reflex was to zoom out with the browser, but then the rest of the interface gets tiny. Are there plans to allow for custom settings or even skins? Maybe via custom css? It's hard to get an overview of what's going on if you can see only very few posts at a time. | |||
| * Clicking on the undelined '6 comments' (the only item that actually looks like a link) in collapsed view does nothing. In full view it scrolls down to the end of the comments. I don't see why, would have expected the link to toggle the collapsing of that thread. | |||
| * The little pencil and flag icons have no tooltips and don't seem very intuitive by themselves. | |||
| I know it's not done, I'm not meaning to complain, just some feedback from fresh eyes. Hope it helps. — ] 22:43, 3 February 2014 (UTC) | |||
| ::* Re: font sizes - I'll ask the design team to weigh in. | |||
| ::* Re: the underlined '6 comments' link not functioning as expected - I ''think'' this is covered by ] (patch-to-review) but I'll check with the devs. | |||
| ::* Re: The pencil and flag icons - they're being moved entirely. You can see/test the upcoming design at ]. ('edit' links will be permanently visible next to the permanent 'reply' links, if one has permission to edit the post. the flag-moderation icon is being moved into the "action menu" (3-dots icon).) | |||
| ::Much thanks for the feedback, 'tis appreciated. :) ] (]) 01:10, 4 February 2014 (UTC) | |||
| :::Thanks for the reply, I'll see what happens. As a general note, I have to say I don't like the look & feel yet, but I find all the new features that might eventually become possible exciting. So I'm glad you're working on this and I think this mini-deployment was a good idea. — ] 07:37, 4 February 2014 (UTC) | |||
| this idea sounds good. please keep me posted!! --] (]) 14:51, 30 January 2020 (UTC) | |||
| Now that it's here, and I also have a few minutes to really look, there are some key points I'd not paid attention to on Mediawikiwik (where I was trying to figure out hiding and stuff): | |||
| :]: You may want to watchlist ]. --] (]) 15:38, 30 January 2020 (UTC) | |||
| *Agree with Hhhippo, the fonts are way too big. Please revert to the normal font. | |||
| *More importantly, the smaller size of font in the replies psychologically suggests that responses are less important than initial statements. | |||
| *Unless one is actively mousing over the initial post, it's not obvious that there's a "reply" space; the word "reply" isn't visible. It should always be visible, unless you want everyone to just add comments. While I'm not discounting that possibility, it's hardly conducive to discussion. | |||
| *Find a way to make this compatible with existing archive processes; nobody wants to lose access to their past archives, nor to have to hunt around for them. | |||
| *The page history has to be accurate, and to include all posts made to the page. This by itself should be considered a critical issue that must be addressed, and I'm not convinced even the test should have proceeded without this. | |||
| *Way too many entries on my watchlist; just like current pages, it should default to include only the most recent change. I'm fine with an option to expand to all changes, but the default should be most recent change. | |||
| More will follow. ] (]) 00:51, 4 February 2014 (UTC) | |||
| ::* Re: Font sizes - I'll ask the design team to weigh in. | |||
| ::* The "reply" links will become static (always visible) very soon (I believe on Thursday). (See the upcoming design at ]) | |||
| ::* I know you know, but for anyone else: The Board-history and Topic-history are currently separated. iirc, there are plans to merge their display, but I'll have to check how far along that is. If it will be long, I'll see if we can get a note added to the page-history header. | |||
| ::* Re: Watchlist entry abundance - that will be a priority over the next sprint. | |||
| :: ] (]) 01:02, 4 February 2014 (UTC) | |||
| :::About the watchlist integration: I agree it's basically not working yet, but the particular issue of cluttering is not too bad when using the enhanced watchlist ("Group changes by page in recent changes and watchlist", why don't such preferences have an easy to find name?). — ] 07:37, 4 February 2014 (UTC) | |||
| ::::{{U|Hhhippo}}, is that ]? ] 22:02, 4 February 2014 (UTC) | |||
| :::::{{U|Helder.wiki}}, no. I didn't have any problem finding the preference itself, I just wasn't sure by which name to refer to it, so I quoted the description instead. It would be nice to have easy-to-quote and easy-to-find names for preferences, like . — ] 22:42, 4 February 2014 (UTC) | |||
| ::::::{{U|Hhhippo}}, you can to get the key of the message from MediaWiki namespace which is used for each part of the interface (in the example, "tog-usenewrc"). Then, you can use <code><nowiki>{{int: <key> }}</nowiki></code> to get its text in the user language ("<code><nowiki>{{int: tog-usenewrc }}</nowiki></code>" = "{{int: tog-usenewrc }}"). ] 11:17, 5 February 2014 (UTC) | |||
| *I just noticed now that when I was typing on a Flow page, the entire screen output starting from the "reply" window on down was quivering. It was particularly noticeable for the cancel/preview/reply buttons (in fact the vibrating green button was what made it obvious) but it applied to everything below the "blue link" to my name, including the editing box. For the record, it's a nice stable monitor, and I've never seen anything quiver on the screen before, but the quivering was directly instigated by each keystroke. ] (]) 03:33, 4 February 2014 (UTC) | |||
| *:{{reply to|Risker}} That's ], which is fixed in the code-base, and that version should be live on Enwiki soon (either this Thursday, or next, if I understand correctly). ] (]) 20:57, 4 February 2014 (UTC) | |||
| :::Glad to hear it, Quiddity. I don't usually look at the screen when I'm writing, and the quivering was pointed out to me by a family member walking past me about two meters away from the screen, so it's quite noticeable. ] (]) 21:00, 4 February 2014 (UTC) | |||
| :::Oh hold on. I just read the bug, and that's not what I'm talking about at all. Think about the bottom of the screen being a little chihuahua out in the cold. *That's* the kind of quivering I mean. That bug seems to report jumping of the screen when the entire post isn't visible. ] (]) 21:03, 4 February 2014 (UTC) | |||
| ::::It's not just you. I often get the same shivering chihuahua effect on the screen while typing in Flow. ] <small><font color=" #FFBF00">]</font>]</small> 23:01, 4 February 2014 (UTC) | |||
| ::::Risker, what browser/operating system are you using? I'm pretty sure I know what is happening but I want to confirm it. (This would be a conflict between two css rules). --] (]) 00:19, 5 February 2014 (UTC) | |||
| :::::Win7 and FF26.0, {{u|Jorm}}. ] (]) 02:44, 5 February 2014 (UTC) | |||
| ==Large image when logged in== | |||
| Not sure if this is intentional but when logged in I see ] as an embedded 3 megabyte image at the end, but not when not logged in. Tested with Opera (logged in and not, but I need to upgrade Opera) and Firefox (logged in only) and with Cologne Blue skin (also seen in Monobook but I use a lot of CSS and JS in that skin). I do have a lot of gadgets enabled but none that should expand images. -] (]) 23:08, 3 February 2014 (UTC) | |||
| :Yeah, this is a bug in the software exploited by a user who chose to use an actual, used talk page for testing. The underlying bug will be fixed; the thread is deliberately now hidden. ] (]) 23:11, 3 February 2014 (UTC) | |||
| Ah, I see. I thought it was part of the testing. How would an editor such as myself fix such problems, for example by changing the image to a '''<nowiki>]</nowiki>''' link as I would do normally? -] (]) 23:22, 3 February 2014 (UTC) | |||
| :Currently the "hide" button is in the flag-icon, which is hidden under the image. >.< | |||
| :Once the next release is deployed, (coming this Thursday), we would just click "hide" in the action menu, which will be in the grey topic-titlebar area (See the 3-dots action menu icon, in topics/posts at ]). | |||
| :Re: Changing the wikitext: Flow is currently configured to only allow the original author (if signed-in) to edit a post, plus admins can edit the posts of other editors. This is explained (as an experimental config) at ] in the "Comment editing" row. HTH. ] (]) 00:03, 4 February 2014 (UTC) | |||
| == About archiving and staggered loading == | |||
| How will Flow handle archiving? Flow has an infinite scrolling process, but there is sometime that you need to let those things go. If Flow isn't going to have a table of contents then that scares away users to have 500+ discussions and no way to navigate them. There will be a search box but nobody wants to have to manually look for a needle in a haystack. | |||
| Another problem with not archiving is that infinite or "lazy" scrolling only loads part of the page when you go to it. How will that be supported by, say, text only browsers, or people with slow internet connections? I can tell you that from someone who edits on a phone, lazy loading is unusable for the mobile interface. | |||
| With no table of contents, how are we supposed to go to the bottom? With each part taking time to load, getting to the bottom of 500+ discussions will take forever. This is rather unintuitive, not to mention a huge problem. How will we ever respond to new threads when you can't get to them? <span style="text-shadow:0em 0em 1em #003399;">]</span><span style="text-shadow:0em 0em 1em #FF8C00;">]</span> 04:10, 4 February 2014 (UTC) | |||
| :I believe new topics go at the top, so there is no scrolling down to see the most recent. I just had a quick look, and cannot see any docs on that. What I'm wondering is how do I ''search'' a talk page—using the browser's "find" function, and using a tool to search archives. ] (]) 11:50, 4 February 2014 (UTC) | |||
| ::Which is of no help if you want to scroll down to something that is not the most recent topic. Many times, "search it" is the wrong answer, and you still need a way to access some specific section through navigation. ] (]) 12:25, 4 February 2014 (UTC) | |||
| :::And remember: new topics go at the top, but topics with new comments stay where they were. So if you reply to the 20th topic on a Flow board, it doesn't rise to the top but stays way down. ] (]) 12:07, 5 February 2014 (UTC) | |||
| == Custom signature == | |||
| Will there be any option for custom signatures in flow? For example, my tree-colour signature? (I don't read MediaWiki discussions) <span style="background:orange;border:orange ridge">]</span><span style="color:blue;background:white;otit;border-bottom-style:ridge;">☸</span><span style="background:#57C738;border:green ridge">]</span> 09:45, 4 February 2014 (UTC) | |||
| :No, see ]. Some of us think that is Flow's best feature. ] (]) 10:45, 4 February 2014 (UTC) | |||
| :* This is "forced point". A point is being created just to support another point. No one said anything against custom signature till now. ] mentions some limitation but allows custom signature. And suddenly these signatures are becoming "disruptive". <span style="background:orange;border:orange ridge">]</span><span style="color:blue;background:white;otit;border-bottom-style:ridge;">☸</span><span style="background:#57C738;border:green ridge">]</span> 11:30, 4 February 2014 (UTC) | |||
| If you would like to highlight your signature in Flow I think the technique of adding an entry to ] will still work, e.g. | |||
| :<code><nowiki>#bodyContent a { background-color: #57C738; border:green ridge; font-weight: bold; color: #000; }</nowiki></code> | |||
| This code (should be all on one line, btw) will highlight your user name when it appears as the title of a link, e.g. ]. You'll be the only person who see the highlight, so you can be as dramatic as you want. - ] (]) 11:17, 4 February 2014 (UTC) | |||
| * Thank you, But my signature resembles Indian flag {{Flag icon|India}} <span style="background:orange;border:orange ridge">]</span><span style="color:blue;background:white;otit;border-bottom-style:ridge;">☸</span><span style="background:#57C738;border:green ridge">]</span> 11:30, 4 February 2014 (UTC) | |||
| You can't reliably use CSS to add characters like ☸ to your username, but you can use it to create multicolor backgrounds in modern browsers, like this: | |||
| <span style="background: -webkit-repeating-linear-gradient(top,rgb(255, 153, 51) 0%,rgb(255, 153, 51) 33%,rgba(0, 0, 0, 0) 34%,rgba(0, 0, 0, 0) 66%,rgb(18, 136, 7) 67%,rgb(18, 136, 7) 100%); background: repeating-linear-gradient(to bottom,rgb(255, 153, 51) 0%,rgb(255, 153, 51) 33%,rgba(0, 0, 0, 0) 34%,rgba(0, 0, 0, 0) 66%,rgb(18, 136, 7) 67%,rgb(18, 136, 7) 100%); padding: 2px; font-weight: 400; color: #000;">Titodutta</span>. The customization in your common.css would look something like this (all on one line): | |||
| :<code><nowiki>#bodyContent a { background: -webkit-repeating-linear-gradient(top,rgb(255, 153, 51) 0%,rgb(255, 153, 51) 33%,rgba(0, 0, 0, 0) 34%,rgba(0, 0, 0, 0) 66%,rgb(18, 136, 7) 67%,rgb(18, 136, 7) 100%); background: repeating-linear-gradient(to bottom,rgb(255, 153, 51) 0%,rgb(255, 153, 51) 33%,rgba(0, 0, 0, 0) 34%,rgba(0, 0, 0, 0) 66%,rgb(18, 136, 7) 67%,rgb(18, 136, 7) 100%); padding: 2px; font-weight: 400; color: #000; }</nowiki></code> | |||
| Apparently Flow will provide some mechanism for displaying a nickname, so perhaps you could display <span style="background: -webkit-repeating-linear-gradient(top,rgb(255, 153, 51) 0%,rgb(255, 153, 51) 33%,rgba(0, 0, 0, 0) 34%,rgba(0, 0, 0, 0) 66%,rgb(18, 136, 7) 67%,rgb(18, 136, 7) 100%); background: repeating-linear-gradient(to bottom,rgb(255, 153, 51) 0%,rgb(255, 153, 51) 33%,rgba(0, 0, 0, 0) 34%,rgba(0, 0, 0, 0) 66%,rgb(18, 136, 7) 67%,rgb(18, 136, 7) 100%); padding: 2px; font-weight: 400; color: #000;">Tito☸Dutta</span>. However, if you want your name to be read as Tito☸Dutta by others, why not permanently change it to ] or at least register your nickname as a ] account? Otherwise anyone who registers your nickname as their username will be able to stop you from using your nickname, because of the policy about impersonating another account. - ] (]) 13:24, 4 February 2014 (UTC) | |||
| *'''Bad feature''' Custom signatures should be encouraged. ]] 19:35, 4 February 2014 (UTC) | |||
| :Actually, {{ping|Bluerasberry|p=,}} I wasn't trying to take sides in that debate. But I know some people have been concerned about not being able to see their own contributions when scrolling down a Flow subscription, and I'm just pointing out that you can already use common.css to customize how your username appears to you when you are logged in. No-one else will see it, so you can be as outrageous as you wish, and it has the rather useful side-effect of highlighting your name on history pages and wherever other people link to your username. - ] (]) 21:47, 4 February 2014 (UTC) | |||
| ::Ahh, please excuse me {{u|Pointillist}}, as I was not trying to call you or anyone else out. I was just throwing an unattached opinion into the forum. If I were to respond to your points, I would say that I want to see everyone else's custom signatures more than I want to see my own. ]] 21:54, 4 February 2014 (UTC) | |||
| :::Ironically, I was thinking just the opposite. :-) There are so many custom signatures where the "official" username and the one that shows up in the signature are unrelated that sometimes it's hard to tell who is who. And some of the add-ons become absurd; a fair number of the ones with lots of code in them make them hard to read. I suppose it's a good example of something that some users consider a feature and others consider a bug! ] (]) 22:02, 4 February 2014 (UTC) | |||
| ::::Well, if you prefer not to see other people's custom signatures, there are a couple of techniques at ]. - ] (]) 22:14, 4 February 2014 (UTC) | |||
| :Not speaking for the team, just my long held personal opinion: ]. ] (]) 03:38, 5 February 2014 (UTC) | |||
| == Please disable Flow from enwiki == | |||
| Why has Flow been enabled on enwiki, when the discussions and tests on Mediawiki have shown enough major, major problems to keep you busy for quite a while? | |||
| We have: | |||
| *No decent history | |||
| *No decent watchlist entries | |||
| *No archiving | |||
| *No good search options | |||
| *No indication of how we can enable and disable Flow (locally, not by asking) | |||
| *No categories (the old talk page was on what, four categories?) | |||
| And so on. Some of these were part of the minimal requirements and promised to be implemented before going live with it. | |||
| If you desperately needed to test Flow here, why not use ''this'' page instead of a live environment? ] (]) 14:00, 4 February 2014 (UTC) | |||
| Honestly, as had been said at the tests at MediaWiki, this is ''not'' ready for enwiki. But why have we even bothered giving feedback as it obviously isn't taken into account... When you go to someone's history, you see | |||
| 13:55, 4 February 2014 (topic) . . (+1,340) . . Jayen466 (talk | contribs | block) added a comment. | |||
| 05:10, 4 February 2014 (topic) . . (+468) . . Jayen466 (talk | contribs | block) added a comment. | |||
| 05:06, 4 February 2014 (topic) . . (+359) . . Jayen466 (talk | contribs | block) added a comment. | |||
| 05:03, 4 February 2014 (topic) . . (+295) . . Jayen466 (talk | contribs | block) added a comment. | |||
| 05:02, 4 February 2014 (topic | post) . . (+13) . . Jayen466 (talk | contribs | block) edited a comment. | |||
| 05:01, 4 February 2014 (topic) . . (+361) . . Jayen466 (talk | contribs | block) added a comment. | |||
| 04:59, 4 February 2014 (topic) . . (+276) . . Jayen466 (talk | contribs | block) added a comment. | |||
| 04:57, 4 February 2014 (topic) . . (+858) . . Jayen466 (talk | contribs | block) added a comment. | |||
| No obvious display of where it happened, no edit summaries, no undo(!!!) or rollback(!!!). (Note: Jayen486's edits don't need undo or rollback, it's an example). ] (]) 14:38, 4 February 2014 (UTC) | |||
| * I agree with ]. <span style="background:orange;border:orange ridge">]</span><span style="color:blue;background:white;otit;border-bottom-style:ridge;">☸</span><span style="background:#57C738;border:green ridge">]</span> 14:40, 4 February 2014 (UTC) | |||
| Another ''funny'' problem; you can't see from your watchlist whether you have checked an edit yet or not; the "Pages that have been changed since you last visited them are shown with a green bullet." doesn't work, once you have been to a Flow page, all later comments will be stuck with a "blue" bullet as well. Apparently, when you've seen one, you've seen them all... So, like I said, history, watchlist, ... are all totally useless with Flow, and no alternatives are ready. ] (]) 14:49, 4 February 2014 (UTC) | |||
| :All the issues you mention affect only people who use these two WikiProject talk pages. It was the decision of those two communities to give Flow a try, even though it's not done, and it's up to them if and when they want to go back to a standard talk page. I agree that Flow is not ready for a broad deployment, but I don't see any reason here to ''diable FLow from enwiki'' as long as the people actually affected by it are happy to test it. | |||
| :The issues mentioned below, CU and RevDel not working, are a bit more worrying. However, what's the damage if we have no CU on two low-traffic pages for a while? How often is it usually used there? And is it really not working at all? I would guess all the needed data are somewhere in the database, it's just that the usual interface to retrieve them doesn't work here yet. But that doesn't mean CU is impossible, it might be one just has to wait until the interface works, and then retrieve the data, or it might be possible for the devs to retrieve the data manually if necessary. | |||
| :For RevDel I guess we have to rely on the devs for the time being. I'm sure they have a close eye on these pages and they have the ability to RevDel by backend-magic if needed, so they can take on that role of administrators/oversighters until the feature is implemented. Maybe one of them can confirm this here to smooth the waters? — ] 20:06, 4 February 2014 (UTC) | |||
| :* I don't mind this tool's implementation in the mentioned two pages. But <u>in current condition</u> I'll not like to see an announcement like "The initial Flow test was successful. But we realised not all editors (specially the new editors) don't follow these announcement discussions and have not got opportunity yo test this feature it. So we are extending flow to more/all talk pages." Flow is a powerful tool, it needs improvement <span style="background:orange;border:orange ridge">]</span><span style="color:blue;background:white;otit;border-bottom-style:ridge;">☸</span><span style="background:#57C738;border:green ridge">]</span> 21:08, 4 February 2014 (UTC) | |||
| No, the issus affect all admins, bureaucrats and so on. You have implemented new software, albeit on a very limited basis, that is totally unsuitable for any admin actions. Apart from the things listed by Risker below, and the things listed by me above (like the lack of undo, rollback, ...), there is also e.g. ''no'' option to protect or semi-protect Flow pages. And of course, when you have them on your watchlist, they literally flood your watchlist with totally unusable entries, instead of following the standard watchlist options. Absolutely useless, as said (but ignored) at MediaWiki. What's the point of having a test environment if you don't bother to fix the most basic errors before going live? ] (]) 07:53, 5 February 2014 (UTC) | |||
| :So....protection works on MediaWiki.org, but apparently it hasn't be deployed to enwiki yet. ] (]) 08:05, 5 February 2014 (UTC) | |||
| ::Nono, we must be mistaken the MediaWiki admins in their wisdom have declared that protection and so on is available and works on Flow pages at enwiki; (corrected link, there seslf-generated permalinks don't work in wikitext, as I had posted there a while ago...). I have seen many problematic replies from MediaWiki, but this one must be the icing on the cake, telling us without checking and without being able to check that we are wrong, and that protection is available to enwiki admins for flow pages. I thought ivory towers were a pre-1968 concept, but apparently this hasn't reached every institution yet. Still, they have now eliminated the one major problem (me) with a speed one normally never sees at MediaWiki when actual problems are reported. The wonders of IRC probably. Like Joe Jackson said, ''"If my eyes don't deceive me, there's something going wrong around here"''. ] (]) 09:47, 5 February 2014 (UTC) | |||
| == Additional issues == | |||
| *There are problems with both Checkuser and suppression which have been reported directly to the team and through Bugzilla. (As an aside, the enwiki functionaries were of the impression after running into serious issues with AFT5 that the WMF wouldn't release new extensions that permitted editing, even as tests, until it was certain that both CU and OS were properly integrated and functional. We were apparently incorrect in our understanding.) | |||
| *Somehow the software is incorrectly determining which comment a user is responding to, and is sending notifications to the wrong person. I have received emails telling me that a user has responded to me, only to find that they were responding to someone else's comment entirely. I am assuming that the editor to whom the response was directed did not receive an email notice, either. This is repeated in the Echo notifications here onwiki. | |||
| *I was unable to post a reply comment today when coming from the emailed link. I could type it, but it would not save. (I'm working on a different computer, WinXP on IE7.) | |||
| These are fairly significant issues, I think. ] (]) 14:18, 4 February 2014 (UTC) | |||
| :I got a notification that I was "mentioned". I think you got a notification that someone had replied to you because you had posted the parent post. Assuming I am right, this means that if you have the temerity to start a discussion (equivalent to starting a talk page section) that will draw many commenters, your notifications will be inundated for days. You'll get a message that "someone replied to you" every time someone posts to the topic or subtopic you started. ] <small><font color=" #FFBF00">]</font>]</small> 16:27, 4 February 2014 (UTC) | |||
| ::Perhaps partially correct, although I've not started any topics, so not entirely bang on. In my early posts, I assumed that the space at the bottom of my screen was where I typed replies, and that resulted in outdented messages, but they weren't new topics. As far as I can tell, though, some of the emails I'm getting trace back to comments that don't start with me at all. ] (]) 16:30, 4 February 2014 (UTC) | |||
| :The team should also be aware of. I do hope you'll let the user know when the test is over so they will feel comfortable in returning. ] (]) 17:01, 4 February 2014 (UTC) | |||
| == Unreadable title under Modern == | |||
| {{tracked|60857}} | |||
| ] | |||
| I use the ''Modern'' skin, and on all flow-enabled pages the title is black-coloured which makes it unreadable on the blue title background. To be clear, I'm generally fond of flow, modulo this and some of the other, more show-stopper bugs mentioned by {{user|Risker}} in the above section. ''']<font color="darkgreen">]</font>''' 16:02, 4 February 2014 (UTC) | |||
| :{{ping|LFaraone}} thanks, I've filed ] to track this and have submitted a patch to fix it. ] (]) 03:00, 5 February 2014 (UTC) | |||
| == Diffs and deletions == | |||
| In future implementation, will it be possible to see the diffs in the comments instead of trying to work them out from the full comments? As you know, seeing diffs is one of the most fundamental things on Misplaced Pages in vandal fighting, error correction etc. | |||
| Secondly, how do you delete comments? I've tried deleting the title and the comments and some bugs come up where it will not let you implement the changes once you've blanked them. ]]....] ''disorganising disorganisation for just 7 years'' 17:29, 4 February 2014 (UTC) | |||
| :Re: Diffs: The latest diff to a post or title is currently accessible from the pencil icon at the end of the post content, eg . The Board-history and Topic-history are in the process of being overhauled, to more closely match what we are all used to (ie. standard elements and ordering); see the product-management , and for details. I'm not sure what the ETA is for that, or whether they'll be working on it piece-by-piece or all-at-once. (I believe piece-by-piece, to get the most needed functionality in place, a.s.a.p.). ] (]) 21:37, 4 February 2014 (UTC) | |||
| :Re: Deletion: For non-admins, the equivalent of "reverting" an edit is to use the "Hide" function. This current configuration is explained in the "Post moderation" section of ]. The idea is to make things less confusing for someone reading a discussion - Ie. in the current talkpage system, if posts are entirely deleted without trace, it's very hard to understand what happened without going through the page-history. | |||
| :(Side-note - I've seen forums decimated of useful content, by a contributor "retiring" and deleting all of their submitted posts before doing so. :/ ) | |||
| :An idea that has been suggested, is to allow editors to delete their own posts within x seconds of submitting them, but this has complications to do with Notifications (see ). | |||
| :So that's the current situation. HTH. ] (]) 21:37, 4 February 2014 (UTC) | |||
| == Nesting == | |||
| See . The discussion rapidly becomes confusing and unreadable after just one reply. Why isn't the more then one level of nesting? I am especially concerned about large noticeboards here. | |||
| Also, how will parent and child sections work? ie. <nowiki> ==parent thread== </nowiki> and <nowiki>===child thread===</nowiki>. <span style="text-shadow:0em 0em 1em #003399;">]</span><span style="text-shadow:0em 0em 1em #FF8C00;">]</span> 20:08, 4 February 2014 (UTC) | |||
| : I am an opponent of FLOW, but nesting levels have been discussed (basically with the promise that they will be enabled in the bright future).--] (]) 20:16, 4 February 2014 (UTC) | |||
| :: How many nesting levels should be allowed on which board is a complicated ] issue, and I don't want to comment on that now. However, there is an additional ''technical'' issue here: on boards with limited nesting, like the ones we have now, I think there should be no ''reply'' links below each comment on the last level. Any reply to a last-level comment will not be displayed as such, but just as an additional comment on that same last level, that is, an additional reply to a second-last level comment. For consistency, this should be make clear already when posting such a comment. For example, one could remove the ''Reply'' links below the individual comments on the last level, and instead have a single ''Add reply'' link some distance below the last comment, just where the next one would appear, and still to the right of the dotted line. <small>I hope this makes sense to somebody...</small> — ] 20:50, 4 February 2014 (UTC) | |||
| == Feedback on timestamp bug == | |||
| Hi {{ping|Pocket calculator operator|EBernhardson (WMF)|Dougweller}} Re: the comments about ] at - I believe those issues are fixed in the latest code - could you check whether the timestamp displays correctly (both with and without mouseover, in the browser(s) that you are seeing problems in) at http://ee-flow.wmflabs.org/Sandbox ? Let us know if that has fixed it. Thanks. | |||
| Generally, if we could discuss bugs here, and do any needed testing at ], instead of in the WikiProject pages, that'd be much appreciated! :) ] (]) 21:07, 4 February 2014 (UTC) | |||
| :The problem is still present for me; in fact, it looks exactly like the screenshot I emailed to Maryana earlier today (which includes my browser detail). ] (]) 21:13, 4 February 2014 (UTC) | |||
| ((ec)):I don't see any timestamps at all on that page, only n days or n months ago. Risker, what am I missing that you can see timestamps and I can't? Or are we talking about a different page? ] (]) 21:20, 4 February 2014 (UTC) | |||
| ::Hi {{ping|Dougweller}}. The ] illustrates the problem - look at the lower right corner of the posts in the screenshot. When I go to http://ee-flow.wmflabs.org/Sandbox which is supposed to be the "fix", I see the same problem. ] (]) 21:43, 4 February 2014 (UTC) | |||
| :It does look very much the same, Quiddity. The reply button worked without incident this time. That detail may have been lost when I was figuring out how to post using Flow, and edited my comment several times. In any event, that is the extent of the input I can give. Good luck. :) ] (]) 21:31, 4 February 2014 (UTC) | |||
| :{{reply to|Dougweller}} The timestamps should switch between "elapsed" (x ago) and "exact" (x o'clock) on mouseover. | |||
| :Thanks all, for the added feedback. I'll file a bug for this now (]). (I thought it might be fixed, because another user seeing the same bug, with a different browser, had reported that the code at ee-flow fixed it). ] (]) 21:51, 4 February 2014 (UTC) | |||
| ::Thought I'd replied last night, sandbox looks fine to me now I know to hover! ] (]) 06:31, 5 February 2014 (UTC) | |||
| == Note on username display == | |||
| {{Ping|R'n'B}} Hi, Re: your comment ("''Having my user name appear at the end of each section is confusing, when I haven't yet commented on the page. Also, the "Article collaboration" topic appears to be embedded in the middle of the "Welcome to Flow" topic, and the latter topic resumes after the end of the former one.''") - the username at the end of each topic has been removed in the latest code (visible at ]) and should be live on Enwiki on Thursday. Regarding the "embedded topic" issue, I think you might be referring to , which has a screenshot as the main content! If you're seeing something else, further up, let us know. Hope that helps. ] (]) 23:43, 4 February 2014 (UTC) | |||
| : Doh! I didn't realize it was a screenshot. --] (] Russ) 00:46, 5 February 2014 (UTC) | |||
| == Through The Looking Glass == | |||
| "There's an old story about the person who wished his computer were as easy to use as his telephone. That wish has come true, since I no longer know how to use my telephone." --Bjarne Stroustrup | |||
| '''Background:''' (You can skip this section if you want.) | |||
| A while back I looked at something (exactly what is not important) that ] said would definitely be a feature of Flow. Alas, it was not theoretically possible. Not just hard. Impossible. Perpetual motion impossible. Turning lead into gold impossible. Despite the fact that nobody at the WMF (or anywhere else for that manner) could describe the steps that they hoped would get us to the impossible result (because no such sequence of steps exists or can exist) when asked about this someone from the WMF claimed that they do know how to do this impossible thing. (Who said what is not important. I am trying to fix the problem, not fix the blame). Later the claim was quietly deleted from the page. Not the ideal situation, but such things happen when it takes specialized technical knowledge to realize that something isn't just hard but is actually theoretically impossible. | |||
| The problem is not that error, but the reaction when I identified it. Rather than simply changing the page, I was first told that the impossible is possible, then told that Flow is completely undefined in all aspects and that no design decisions have been made, followed by further unpleasantness that isn't relevant here. Of course we all know that Flow is ''not'' undefined, and design decisions ''have'' been made. For example, it has been decided that Flow will sign your comments instead of asking you to add four tildes ("<nowiki>~~~~</nowiki>") at the end. That is not going to change, nor does anyone want it to. | |||
| There is a page at http://blogs.atlassian.com/2013/07/agile-requirements-documentation-a-guide/ and another at http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm that describe Agile Requirements Documentation. | |||
| '''The Agreement''' | |||
| Because of the above, we worked out a solution that everyone agreed to. We agreed that the WMF would pick a page on the English Misplaced Pages (] would be a good choice) that documents, in broad strokes, WMF's current understanding about what Flow is. | |||
| This document was to contain selected "we haven't decided yet" items and selected "we don't know yet" items, but it was also to document everything that we know we are going to do (autosigning posts, for example). This document was to be kept short with broad strokes, not TL:DR detailed documentation. It would also document those things that we have agreed ''not'' to do, along with selected items that are desirable but might not or probably won't get done. | |||
| We agreed that, when we decide something here on this talk page and everyone agrees that it will be (not might be) done, someone at the WMF would update the page to reflect that decision. That edit would then be considered to be a promise and a commitment. | |||
| Of course even the best-laid plans sometimes need to be modified, so if the plans change, someone at the WMF would update the page and post a message on the talk page. Something like "Remember that autosigning thing we all agreed on? I had to move it into the 'we don't know yet' section because of...". | |||
| We also agreed that, every so often, key members of the Flow team would look the page over and make sure we don't have something in there that they will object to later. | |||
| That is what we agreed to do, and I set a reminder on my computer to fire in three months so I can whether it was done. | |||
| It has been three months. Nobody has notified me that it is done. ] mentions few things in the lead and in the "expectations" table, but it falls short of what I expected and what I thought we agreed to do. | |||
| I was especially disappointed when I checked https://wikimedia.mingle.thoughtworks.com/projects/flow/cards/288 and saw that it had been marked "done" without the slightest indication that anyone has actually done anything to implement my suggestion. --] (]) 04:07, 5 February 2014 (UTC) | |||
| :Have you checked the various pages on MediaWiki.org, linked to from the sidebar of ]? — <span style="border:dashed #666;border-width:1px 0 0 1px">]</span> and <span style="border:dashed #666;border-width:0 1px 1px 0">]</span> 05:33, 5 February 2014 (UTC) | |||
| == Flow + Echo = Error? == | |||
| I experimented with transcluding another page to the Flow test page, . | |||
| One thing I didn't expect was that such a move would trigger Echo notifications for people listed on that page. But I'm glad it did, since it looks like the notification they got doesn't work... an editor describes how this notification gave a ''Could not find the requested workflow'' error. ] (]) 12:57, 5 February 2014 (UTC) | |||
| The editor has added more problems with this, , with Echo refusing to un-echo the edit I made. No idea whether the problem is Echo, Flow, or interaction, but it certainly is a problem! ] (]) 13:00, 5 February 2014 (UTC) | |||
Latest revision as of 08:56, 30 December 2023
 | Please use mw:Talk:Structured Discussions instead, for centralized feedback. |
 Archives |
|
This page has archives. Sections older than 15 days may be automatically archived by Lowercase sigmabot III when more than 5 sections are present. |
Flow was just renamed to "Structured Discussions"
As if discussions on talk pages are not structured, the WMF in it’s infinite wisdom just decided to rename Flow to mw:Structured Discussions, the official ratio is this:
- Structured Discussion was formerly known as “Flow”. Flow was a bigger project that has been re-scoped to focus on user-to-user discussions. The software has been renamed to reflect this change.
They fail to see the difference between a structure and bondage gear. And they obviously hate flexibility. Grüße vom Sänger ♫ 19:57, 14 September 2017 (UTC)
- Wikitext talkpage are "structured" in a way that editors who are accustomed to the system can understand, but not always intuitively, e.g. interleaved comments, or inconsistent indenting, or bulletpoints mixed with colons.
- Wikitext talkpages are not "structured" in a way that software can understand. E.g. the indented quote you pasted above, is not programatically identifiable as being written by you, except by analysing every single revision ever made to this page and significant changes to the "diff" system (which is easily confused by refactored (moved around) blocks of text).
- Just like templates and databases bring consistency (and the possibility of powerful new features) to structured data, a structured discussion system brings consistency (and the possibility of powerful new features) to human discussion.
- I know you dislike it, and I don't want to argue, but please ask any programmer that you respect for confirmation that wikitext talkpages are not "structured" in a software-sense. Quiddity (WMF) (talk) 20:30, 14 September 2017 (UTC)
- Talk pages have the same structure as every other page at Misplaced Pages. Anyone who cannot deal with a talk page is unable to contribute in a useful manner. Of course people need help for their first few posts (and first few article edits, and first few attempts to add references), but help is part of a collaborative community. A simple script to add a comment is all that is needed: guess what indent to apply and whether to add four tildes. The script would cover most usage cases for a new user. Flow is fine for baby talk or for discussions where hard facts are being discussed, such as when someone is asking an expert how to perform some operation. Flow is useless for typical discussions concerning disputed topics with multiple views from multiple people. Johnuniq (talk) 23:06, 14 September 2017 (UTC)
- I agree entirely with User:Johnuniq. I hope that the statement on the project page that there is no intention to return Flow to tne English Misplaced Pages is still correct. Doug Weller talk 09:12, 24 September 2017 (UTC)
- Quiddity (WMF), I'm a programmer and I fully understand what you mean about structure. However 99% of the people on the planet aren't programmers. The name "structured discussions" may be obvious and natural inside the WMF, but it isn't going to be so natural and obvious for people who don't know about software internals and don't care. Under the plain-English meaning of the word, any normal person would say 'yes, the Misplaced Pages article for United States is structured'. This new name is clumsy, confusing, and trying to rename the project is pointlessly disruptive. We have countless megabytes of discussions and information about Flow. Are you going to spend the next few years trying to argue/correct people who keep calling it Flow? People who say Flow either because that is the only name they know, or because it's 18 characters shorter, or because they are using the most common name to ensure other people understand what they are discussing. You're really fighting human nature on the '18 characters longer' point. You'd have an easier time getting people to switch to 'Glix' or 'Zopy'. Alsee (talk) 09:03, 15 September 2017 (UTC)
- Talk pages are for humans, the software is just a tool. If software can't read it, so what? It's the humans that should be able to read it in a proper way, and I don't think any human will have a problem with the structure of this topic right now. They will even grasp intuitively that this is an answer to you, and not to Alsee. If machines are not able to grasp it, they are not fit for talk pages, that's all. Machines are nothing we should put up first, they are just tools, not subjects. Grüße vom Sänger ♫ 09:13, 15 September 2017 (UTC)
- I think that the discussion from top to bottom and infinite scrolling are really the principal nuisances of Flow, whereas the current talk page format I have difficulty in telling posts apart and to figure out which indentation to use, and having to sign posts and needing a bot for this is also irritating. Granted I am more used to the discussion style of TV Tropes which is very similar to Flow. I am interested to know whether users who are not long accustomed to Misplaced Pages would find such a modified Flow easier or harder to comment on than the current talk page format. Jo-Jo Eumerus (talk, contributions) 15:35, 18 September 2017 (UTC)
Rework of page content
I did some HEAVY cleanup. I figured that this page was rather unreadable if you don't really care about flow development and just wanted to find out what it was about. Most of the information was 2-4 years old and did not help any user who is currently reading the page. Most information was duplicate with the mediawiki.org pages to begin with. I considered it best to keep to a short description of the product and its intent, a description of the current state, and the links to the relevant team and product pages. Is there anything that should be re-added that I had not considered ? —TheDJ (talk • contribs) 14:11, 15 September 2017 (UTC)
- Should this page now be moved to WP:Structured Content, to match the mw: one? Though most of us here probably think of it as "Flow" now, it has a new name which will become the main name its known by as it continues to be maintained and developed.--JohnBlackburnedeeds 17:40, 15 September 2017 (UTC)
- Maybe we wait until it really is the new name everywhere? I just looked at the "Beta" preferences on Wikidata, and there it is still called "Flow". —Kusma (t·c) 20:37, 15 September 2017 (UTC)
- It is the new name everywhere, see translatewiki.net. It just takes a few days before it's updated to MediaWiki wikis. Stryn (talk) 07:51, 18 September 2017 (UTC)
- No rush though, another week won't be a problem :) —TheDJ (talk • contribs) 09:00, 18 September 2017 (UTC)
- It is the new name everywhere, see translatewiki.net. It just takes a few days before it's updated to MediaWiki wikis. Stryn (talk) 07:51, 18 September 2017 (UTC)
- Maybe we wait until it really is the new name everywhere? I just looked at the "Beta" preferences on Wikidata, and there it is still called "Flow". —Kusma (t·c) 20:37, 15 September 2017 (UTC)
So if we do move... do we move all subpages with it ? See: Special:PrefixIndex/Wikipedia:Flow and Special:PrefixIndex/Wikipedia_talk:Flow —TheDJ (talk • contribs) 07:46, 22 September 2017 (UTC)
- @TheDJ: I would just move this page and talk. The others are just historical, but would have to be rewritten otherwise. --Jules (Mrjulesd) 14:39, 23 September 2017 (UTC)
Concerns about flow
I have concerns that Flow will result in no technical support for the current talk page system. It is claimed that wikitext cannot allow "per-topic notifications". I am not convinced this is true. One could improve the current wikitext so that it does allow this. Doc James (talk · contribs · email) 18:44, 23 September 2017 (UTC)
- The current talk page system does not seem to need additional support, or so it seems to me. Jo-Jo Eumerus (talk, contributions) 19:26, 23 September 2017 (UTC)
- I would love the ability to watchlist sections of talk pages. This is something many have requested. I do not see that it would be that hard technically. Would also be nice to have a version of VE that works on talk pages so new and old editors do not need to learn two or three systems of editing. Doc James (talk · contribs · email) 19:39, 23 September 2017 (UTC)
- According to phab:T2738 there is a moderately complex solution for a particular case. Watching sections of pages in general would require a significant change of how wiki pages in general work. Making Flow compatible with standard markup is potentially a different solution to the "systems of editing" issue, not sure how hard that would be. Jo-Jo Eumerus (talk, contributions) 09:30, 24 September 2017 (UTC)
- It seems fairly clear, standing back from details to see the big picture, that making Flow compatible with standard markup is an unrealistic goal. Trying to make a fundamentally different platform "pretend" to be like another, such as in this case, swallows up unbounded amounts of expert labor to chase after an unending supply of flaws in the pretense. It's easy to make things look just the same if at their foundation they really are the same, and ultimately hopeless to try to make them look just the same if at foundation they aren't.
There is, tbh, a structural flaw in the way the Foundation is positioned relative to the sisterhood. The Foundation has a powerful impulse to apply expert programmers to developing stuff for the sisterhood. What would actually be good for the sisterhood? A stable, simple, easy-to-use markup platform that vastly empowers volunteers, giving scope for their imaginations. This, though, clashes severely with the Foundation's impulse — in the long run, the Foundation's impulse leads to perpetual platform instability in the name of having expert programmers add things instead of empowering the volunteers to do them. Could the Foundation resist this impulse? Perhaps — supposing a concerted effort at the Foundation to build that resistance into its corporate culture. It's all made even more difficult because figuring out how to empower volunteers with simplicity is a much harder design task than adding specialized features that increase volunteers' dependence on tech support — and the harder design task flies in the face of what commercial social-media platforms seek to do (hence a fatal flaw in the Foundation comparing itself to any commercial platform). --Pi zero (talk)
- Just a note.. If I read some of the tickets that are currently under consideration correctly, then it seems that Structured Discussion posts will be stored in wikitext again. Which doesn't mean they will be wiki pages, as there is a difference between a page and it's storage format (and in this case even the storage format of a part of the page), but does make sure that they'll be closer to wiki code parsing. —TheDJ (talk • contribs) 08:19, 25 September 2017 (UTC)
- For what I know, that means only that every individual post will be stored in wiki markup; the structure of the page itself will not be represented by markup, but by a relational database schema. This is not closer to a wiki system than before, since it doesn't allow editors to define the structure of the page; as Pi zero said, Flow is a fundamentally different platform at its core. I find Pi zero's comment most insightful - the best the Foundation could do is empower the community to build and improve our own tools, but the WMF's gravitas pushes it towards building simple tools that will make editors more dependent on developers. Diego (talk) 08:51, 25 September 2017 (UTC)
- "the structure of the page itself will not be represented by markup, but by a relational database schema." That is correct. —TheDJ (talk • contribs) 09:36, 25 September 2017 (UTC)
- For what I know, that means only that every individual post will be stored in wiki markup; the structure of the page itself will not be represented by markup, but by a relational database schema. This is not closer to a wiki system than before, since it doesn't allow editors to define the structure of the page; as Pi zero said, Flow is a fundamentally different platform at its core. I find Pi zero's comment most insightful - the best the Foundation could do is empower the community to build and improve our own tools, but the WMF's gravitas pushes it towards building simple tools that will make editors more dependent on developers. Diego (talk) 08:51, 25 September 2017 (UTC)
- Just a note.. If I read some of the tickets that are currently under consideration correctly, then it seems that Structured Discussion posts will be stored in wikitext again. Which doesn't mean they will be wiki pages, as there is a difference between a page and it's storage format (and in this case even the storage format of a part of the page), but does make sure that they'll be closer to wiki code parsing. —TheDJ (talk • contribs) 08:19, 25 September 2017 (UTC)
- It seems fairly clear, standing back from details to see the big picture, that making Flow compatible with standard markup is an unrealistic goal. Trying to make a fundamentally different platform "pretend" to be like another, such as in this case, swallows up unbounded amounts of expert labor to chase after an unending supply of flaws in the pretense. It's easy to make things look just the same if at their foundation they really are the same, and ultimately hopeless to try to make them look just the same if at foundation they aren't.
- According to phab:T2738 there is a moderately complex solution for a particular case. Watching sections of pages in general would require a significant change of how wiki pages in general work. Making Flow compatible with standard markup is potentially a different solution to the "systems of editing" issue, not sure how hard that would be. Jo-Jo Eumerus (talk, contributions) 09:30, 24 September 2017 (UTC)
- I would love the ability to watchlist sections of talk pages. This is something many have requested. I do not see that it would be that hard technically. Would also be nice to have a version of VE that works on talk pages so new and old editors do not need to learn two or three systems of editing. Doc James (talk · contribs · email) 19:39, 23 September 2017 (UTC)
- I don't think we are likely to ever have section watch listing.. Let's put it this way. If equals signs for headers are deprecated, and instead people need to use buttons like: Add new section, Remove section, Rename section, maybe then, we can think about watch listing sections. Before that, it seems highly unlikely to me. —TheDJ (talk • contribs) 08:19, 25 September 2017 (UTC)
- What does the internal representation have to do with the user interface? Equal signs for headers are good enough for the parser to detect the location of each subsection for the Table of Contents, editing sections and creating edit summaries; I don't see a reason why they couldn't also be use to generate targetted notices. Diego (talk) 08:53, 25 September 2017 (UTC)
- Header identifiers are not unique, not stable, don't reliably indicate start and/or end of a section, aren't stored atomically (we store pages, not sections) and can be moved or even deleted, untraceably from pages. Retroactively adding or inferring such details from wiki code is fragile and complex (building a parser on top of a non-stable parser) and most importantly I think, terribly resource intensive as well. We are already having trouble with people with 100000 or more pages on their watchlist, if we additionally would have section watch listing implemented with such weak underpinnings, watch lists would become a significant performance problem for which there would not be an immediate solution. I went with explaining this problem in UI concepts :) —TheDJ (talk • contribs) 09:32, 25 September 2017 (UTC)
- There is an alternative approach detailed in the ticket, where we basically ignore most of those problems (Nemo's approach). I personally call this the 'lossy' variant. But I think that a big reason people have reservations about that approach, is that it's just moving the goal post of complaints. So when that works (still, or possibly with even MORE performance problems btw), people will start complaining about sections suddenly disappearing from their watchlist, archiving not working etc. and will be stuck further down on the dead end road —TheDJ (talk • contribs) 09:51, 25 September 2017 (UTC)
- I think that 'lossy' variant has great potential, and would be a welcome improvement, covering a large number of cases. As long as its users develop an accurate mental model ("you're following a section named 'xyzzy' "), they would understand why and how the section is no longer being followed (e.g. "section 'xyzzy' has been renamed to 'foobar' "). The software could avoid complaints by providing support for fallback situations, such as issuing a last notification when the section is renamed or archived, and/or going back to tracking the whole page in those cases (with a notice explaining the cause). Diego (talk) 10:21, 25 September 2017 (UTC)
- @Diego Moya: How would you expect multiple watched sections on the same page to be handled in such a situation ? —TheDJ (talk • contribs) 15:02, 25 September 2017 (UTC)
- @TheDJ: By creating several search filters for the same page, one for each followed thread, and each with its own text pattern, no? I don't see any particular problem in that. More problematic would be what happens if several sections share the same name, like "Arbitrary break". But even then if users are aware of how the filter works, i.e. that you subscribe to "sections with string YYY in their title". And the community could work around the problem, by avoiding exact duplicate titles. I think that's a small price to pay for the flexibility of avoiding a strict discussion model with unique IDs for each thread, and is consistent with the mental model of "everything in a wiki is a raw text string with markup". Diego (talk) 17:55, 25 September 2017 (UTC)
- @Diego Moya: How would you expect multiple watched sections on the same page to be handled in such a situation ? —TheDJ (talk • contribs) 15:02, 25 September 2017 (UTC)
- I think that 'lossy' variant has great potential, and would be a welcome improvement, covering a large number of cases. As long as its users develop an accurate mental model ("you're following a section named 'xyzzy' "), they would understand why and how the section is no longer being followed (e.g. "section 'xyzzy' has been renamed to 'foobar' "). The software could avoid complaints by providing support for fallback situations, such as issuing a last notification when the section is renamed or archived, and/or going back to tracking the whole page in those cases (with a notice explaining the cause). Diego (talk) 10:21, 25 September 2017 (UTC)
- There is an alternative approach detailed in the ticket, where we basically ignore most of those problems (Nemo's approach). I personally call this the 'lossy' variant. But I think that a big reason people have reservations about that approach, is that it's just moving the goal post of complaints. So when that works (still, or possibly with even MORE performance problems btw), people will start complaining about sections suddenly disappearing from their watchlist, archiving not working etc. and will be stuck further down on the dead end road —TheDJ (talk • contribs) 09:51, 25 September 2017 (UTC)
- Header identifiers are not unique, not stable, don't reliably indicate start and/or end of a section, aren't stored atomically (we store pages, not sections) and can be moved or even deleted, untraceably from pages. Retroactively adding or inferring such details from wiki code is fragile and complex (building a parser on top of a non-stable parser) and most importantly I think, terribly resource intensive as well. We are already having trouble with people with 100000 or more pages on their watchlist, if we additionally would have section watch listing implemented with such weak underpinnings, watch lists would become a significant performance problem for which there would not be an immediate solution. I went with explaining this problem in UI concepts :) —TheDJ (talk • contribs) 09:32, 25 September 2017 (UTC)
- What does the internal representation have to do with the user interface? Equal signs for headers are good enough for the parser to detect the location of each subsection for the Table of Contents, editing sections and creating edit summaries; I don't see a reason why they couldn't also be use to generate targetted notices. Diego (talk) 08:53, 25 September 2017 (UTC)
- "no technical support for the current talk page system" There is no current talk page system. There is no functional difference between a wikipage and a talkpage, other than that wikipages have even namespace numbers and talk pages have uneven namespace number. Both therefor have the exact same amount of technical support. —TheDJ (talk • contribs) 09:43, 25 September 2017 (UTC)
Alternatively, there is a feature I've had on my wish-list for years. For lack of a better name (suggestions?), call it "subwatch". The idea is that, in addition to marking certain individual pages as watched, one can mark certain pages subwatched; subwatching doesn't directly affect which edits show up on your watchlist, but it does help you to watch subpages of that page. Thus:
- At the moment you first mark a page P for subwatch, P and all its subpages go on your watchlist.
- Whenever a new subpage of subwatched P is created, that newly created page immediately goes on your watchlist.
- Those are the only two things that are actually done by subwatching P. At any time you can choose to unwatch any subpage of P, or you can even unwatch P itself, with no affect on the subwatch on P: even though you might not be watching P itself, any newly created subpage of P will be automatically watched.
You could, for example, set yourself up to automatically watch all nomination pages for a certain type of nominations, and then you could unwatch the ones that you decide aren't going to be of ongoing interest to you. On Wikibooks, of course, this could be hugely convenient, if you're interested in a particular book and want to know about anything done to it (including addition of new modules to the book). On Wikinews — and perhaps elsewhere, who knows, perhaps even on Misplaced Pages — one might set up some sort of hierarchy discussion arrangement that would put each comment on a separate page and use the subwatch facility to help tie them all together. --Pi zero (talk) 17:32, 25 September 2017 (UTC)
- @Pi zero: That would be phab:T4308 I believe. Jo-Jo Eumerus (talk, contributions) 18:57, 25 September 2017 (UTC)
- @Jo-Jo Eumerus: Hm. Interesting. There seem to be some similarities. I think what I'm describing would be much simpler to implement, easier to use, and perhaps effectively more powerful because of its simplicity. --Pi zero (talk) 19:10, 25 September 2017 (UTC)
- Using subpages is what LQT basically did. If I remember correctly, that was causing significant performance problems though (exploding the pages table of the database). Not sure if those performance problems would still be an issue. —TheDJ (talk • contribs) 20:30, 25 September 2017 (UTC)
- Well, sort of yes. Using subpages is certainly part of what LQT does. It also does some other things that are quite unpleasant (although we still use LQT on en.wn, to this day, even though we agree it's nasty for most purposes, because for the specific thing we use it for we've found it more effective than a wiki page — and yes, we did discuss Flow some time back and concluded that, for the one purpose where LQT was more effective than an ordinary wiki page, it was also superior to Flow... but I digress). --Pi zero (talk) 20:51, 25 September 2017 (UTC)
- I might point out, though, that the device I'm describing would, I believe, be immensely useful for the other things I was mentioning, regardless of whether one chose to use it in that particular highly-inefficient way. Granted, the relevance to the current discussion is for talk threads. --Pi zero (talk) 21:08, 25 September 2017 (UTC)
- (Or I could just be misunderstanding the other proposal... sigh. Well, the current notification system does a lot to improve things.) --Pi zero (talk) 14:25, 26 September 2017 (UTC)
- I might point out, though, that the device I'm describing would, I believe, be immensely useful for the other things I was mentioning, regardless of whether one chose to use it in that particular highly-inefficient way. Granted, the relevance to the current discussion is for talk threads. --Pi zero (talk) 21:08, 25 September 2017 (UTC)
- Well, sort of yes. Using subpages is certainly part of what LQT does. It also does some other things that are quite unpleasant (although we still use LQT on en.wn, to this day, even though we agree it's nasty for most purposes, because for the specific thing we use it for we've found it more effective than a wiki page — and yes, we did discuss Flow some time back and concluded that, for the one purpose where LQT was more effective than an ordinary wiki page, it was also superior to Flow... but I digress). --Pi zero (talk) 20:51, 25 September 2017 (UTC)
- Using subpages is what LQT basically did. If I remember correctly, that was causing significant performance problems though (exploding the pages table of the database). Not sure if those performance problems would still be an issue. —TheDJ (talk • contribs) 20:30, 25 September 2017 (UTC)
- @Jo-Jo Eumerus: Hm. Interesting. There seem to be some similarities. I think what I'm describing would be much simpler to implement, easier to use, and perhaps effectively more powerful because of its simplicity. --Pi zero (talk) 19:10, 25 September 2017 (UTC)
I wrote up this essay about improving wikitalk a couple years ago, back when some people were still serious about implementing flow. Everything I wrote remains valid. User:Oiyarbepsy/Wikitalk: The Next Generation. Oiyarbepsy (talk) 17:04, 3 March 2018 (UTC)
WMF is refusing to uninstall Flow on Commons
This is not an enwiki issue and the poster has been cross posting this across projects. Feel free to follow up either at the commons thread or the meta thread (meta:Wikimedia_Forum#WMF_is_refusing_to_uninstall_Flow_on_Commons) if you care. — xaosflux 12:02, 3 March 2018 (UTC)The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Commons established Consensus to uninstall Flow, as was done on EnWiki and on WetaWiki. The WMF has just posted a response refusing to uninstall Flow. Alsee (talk) 04:25, 3 March 2018 (UTC)
- I personally think Flow is wholly unfit for its stated purpose (and that's putting it mildly), but in this case I see WMF's response as reasonable. Shock Brigade Harvester Boris (talk) 05:12, 3 March 2018 (UTC)
- Shock Brigade Harvester Boris when you say the response is 'reasonable', do you mean that you would personally find it an acceptable result? Or do you mean you think it reasonable and worthwhile for the WMF to battle and further damage WMF-community relations over this? Especially when a volunteer dev has already done the work writing the patch to carry out the task? Alsee (talk) 06:20, 3 March 2018 (UTC)
Note: The WMF has opened a Phab task to build a superprotect level for Flow. Alsee (talk) 06:14, 3 March 2018 (UTC)
- Um, to me it reads like they are planning to remove all flow content sans some log entries, and that "superprotect" thing sounds more like permanent archival to me as well. Jo-Jo Eumerus (talk, contributions) 09:39, 3 March 2018 (UTC)
Talk pages consultation 2019
The foundation is running a consultation on what to do about Talk_pages (implicitly including discussion of what, if anything, to do about Flow). Everyone is invited to participate in the RFC at WP:Talk pages consultation 2019. Alsee (talk) 13:56, 24 February 2019 (UTC)
request info
this idea sounds good. please keep me posted!! --Sm8900 (talk) 14:51, 30 January 2020 (UTC)
- Sm8900: You may want to watchlist mw:Talk pages project/Updates. --HHill (talk) 15:38, 30 January 2020 (UTC)