The Collaboration team has enabled Flow on this talk page.
- Please conduct testing at Talk:Sandbox, retaining this page for discussions and suggestions.
- If you find bugs not yet tracked, report in Phabricator if you can, and here if you can't.
Testing mobile link rendering
13 new topics on Talk:Flow
I haven't checked in on this page in a while. Echo says, "13 new topics on Talk:Flow". That's nice. Which ones are they? Do you expect me to manually count down the un-numbered list in the (hidden) table of contents, make a note of its subject line, and remember that when I get to the 13th, that I'm probably done reading them? This really isn't functional. I need a way to see only the posts and threads that are new, and I need a way to mark the ones that I've read (so that if I get interrupted while reading all 13 threads, I'll be able to figure out where I was when I get back to it).
Heh ...and the "way to mark the ones that I've read" must not be automatically marking them as read as soon as I open them, because sometimes I can get an idea that the message is complicated to deal with even before finishing reading it... and I would want to mark it as unread, for resolving the issue later.
Those are good use cases, and they're definitely things that we can work on. Are those things that you can currently do on wikitext talk pages?
Yep! Depending on the edit summary (which appears in the watchlist) I can choose to open it or leave it for later (and it will stay bold in the list until I open the page).
The current system has a way to indicate "new content", via the blue-sidebar at the left (in LTR languages) of each post, e.g.
&fromnotif=1 string in the URL, is what triggers those highlights, based on the #ID of the post it is linked to.
For editors that use the Echo Notifications links, the Notifications about bundled-new-topics on a Board, and about replies-to-an-existing-topic, get this treatment. For editors that use the "grouped & expanded" preferences, that link is available in the "n changes" link (screenshot). There are possibly/probably other links, that should get this treatment... Suggestions appreciated!
(Sidenote: that does run into some problems, when the oldest "new" content is outside of the first 10 topics that are loaded. Anything loaded in the infinite scroll, will not be properly marked. e.g. here)
Re: wanting to not mark new content as read just by loading it, I've filed phab:T94061 ("Create a way to mark Flow Topics as unread") with a few extra details. (though possibly the use-case will be solved in a different way, per discussions at phab:T93109 and elsewhere.)
There was a dif link in my Special:Watchlist pointing to https://www.mediawiki.org/w/index.php?title=Topic:Se14547daaj65kpa&curid=0&diff=0&oldid=0 which didn't cause any comment to be highlighted (I had to re-read the comments and remember which ones are old, to see what is new on this topic).
Auto-archive by month
Good search can solve a lot of things, but I believe that structured auto-archiving is needed as well. Some scenarios:
- A user may want to see how many posts did he have on his user talk page each month.
- A user may want to check what things were discussed around the time of certain news events, holidays, MediaWiki software changes, etc.
- A user may want to find a conversation that is hard to find by words, because the relevant words are too common and yield too many results, but he does remember the time when the conversation happened.
- It may sound like circular logic, but own internal engine's search indexing is far from perfect even for English, and for most other languages its morphological support is even worse. An archive by dates would be a reasonable fallback for such languages.
It makes sense to me to see automated archives of Flow conversations by month. I imagine something like a box that shows years and months, and clicking a month would show a page with all the conversations from that month.
I don't have statistics about the number of conversations by month, but I imagine that even in the busiest talk pages a whole month could fit reasonably on one page. Maybe some especially busy ones could be split by weeks. I'd love to see statistics, if anybody has them.
Perhaps it would be more sensible to expand the options under "View Newest topics" to include an item that allows you to "View by date range". Then you don't have separate pages, but you can still see whatever you want.
I guess that the designers and the user researchers can chime in here, but a window with twelve links per year sounds to me simpler and more relevant than a range selector.
So... the first thought is that edit summaries shouldn't be needed at all with talk pages in general and with Flow in particular.
But on a second thought, they may be useful. A Hebrew Wikipedia user said: "If from the edit summary I see that it's a welcome or a warning template, then I don't bother checking, but if it's a reply to a post that interest me, then I do. And sometimes talk pages are vandalized."
So I'm passing this on - although maybe the right thing is not to add edit summaries, but to somehow understand the different workflows and indicate them in recent changes and watchlists accordingly.
Templates are used for so much (like welcoming and warning, as you mention) and I think we should really use that to our advantage.
Also, these Flow edit windows really need to be resizable. Why is "resize: none;" there?
Because it's supposed to resize automatically as you type.
Unusable when topics being loaded during scrolling
Looking good but when I scroll and topics being loaded, then I stop scrolling to read some topic, then after a few moments the topic above finished loading and is inserted, everything moves and I loose track of where I have been reading before.
This is a problem especially when using the "Browse topics" because there is mostly some stuff loading above the chosen topic.
Starting conversion of LiquidThreads to Flow at mediawiki.org
LiquidThreads (LQT) has not been well-supported in a long time. Flow is in active development, and more real-world use-cases will help focus attention on the higher-priority features that are needed. To that end, LQT pages at mediawiki.org will start being converted to Flow in the next couple of weeks.
There are about 1,600 existing LQT pages on Mediawiki, and the three most active pages are VisualEditor/Feedback, Project:Support desk, and Help talk:CirrusSearch. The Collaboration team has been running test conversions of those three pages, and fixing issues that have come up. Those fixes are almost complete, and the team will be ready to start converting LQT threads to Flow topics soon. (If you’re interested in the progress, check out phab:T90788 and linked tasks.) The latest set is visible at a labs test server: http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback. See an example topic comparison here: Flow vs LQT)
The VisualEditor/Feedback page will be converted first (per James' request), around the middle of next week. We’ll pause to assess any high-priority changes required. After that, we will start converting more pages. This process may take a couple of weeks to fully run.
The last page to be converted will be Project:Support desk, as that is the largest and most active LQT Board.
LQT Threads that are currently on your watchlist, will still be watchlisted as Flow Topics. New Topics created at Flow Boards on your watchlist will appear in your Echo notifications, and you can choose whether or not to watchlist them.
The LQT namespaces will continue to exist. Links to posts/topics will redirect appropriately, and the LQT history will remain available at the original location, as well as being mirrored in the Flow history.
There’s a queue of new features in Flow that will be shipped over the next month or so:
- Table of Contents is done
- Category support for Flow Header and Topics is done
- VE with editing toolbar coming last week of March (phab:T90763)
- Editing other people’s comments coming last week of March (phab:T91086)
- Ability to change the width & side rail in progress, probably out in April (phab:T88114)
- Search is in progress (no ETA yet) (phab:T76823)
- The ability to choose which Flow notifications end up in Echo, watchlist, or both, will be coming up next (no ETA yet)
That being said -- there are some LiquidThreads features that don’t exist in Flow yet. We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion. At the same time, we’d like further suggestions on how we could improve upon that (or other) features from LQT. Please let us know what you think!
What happens to my LQT list of "New messages (123)", which I can check periodically at Special:NewMessages, once this conversion is done? Will I lose the list? Will it be moved to my "Messages (1234)" in Echo's menu, so that I can continue to check the list periodically to see what I missed in the last few days/weeks in pages I watch?
We're going to be doing more work on notifications and watchlists over the next month. Right now, you can subscribe to a board and get Echo notifications for new topics, and new posts on topics that you're following show up in Echo and your watchlist.
There are several things that this notification system doesn't do -- one of them is giving the LQT-style overview of what's happened on the page since you were there last. That's one of the things that we need to spec out and build.
Who will be the main point of contact? How long is the entire conversion process expected to take?
Is there a compiled list of all pages which are planned to be converted, and has any thought been put into determining which pages will be after the first and before the last page to be converted? Is LiquidThreads Test Page going to be converted (it might be a waste of resources to undertake this in production, however it would be a useful test case for being undertaken in a test/qa/beta environment), or is there a list of pages which wont be converted?
Is there an opt-out procedure, where a person/group can opt to restore a page to wikitext?
Is there a process in place to rollback the conversion if bugs are found in the conversion script or Flow software (single page and/or entire conversion)?
Also, I request that user_talk: pages of unsuspecting (i.e. not opt'ed-in) users are not done *early* in the migration. While they might be smaller and easier to migrate, selecting them early in the process will cause a lot of grief as these are a cohort of people who are unlikely to be prepared to be beta testers on their own user_talk page.
An edit toolbar is definitively handy in Support Desk, and I assume it would be also handy in other boards. Specially to escape markup (<nowiki></nowiki>) and the charinsert extension with other things like <code></code> and <syntaxhighlight></syntaxhighlight>
I understand it so, that you still can switch between the actual source editor and the editing toolbar. But i agree: We need a way to edit the plain wikitext (or the editing toolbar needs to support _all_ possible wikitext constructs (VE doesn't actually)).
We're about to release v1 of a VisualEditor toolbar; it should be on Mediawiki in the next couple of weeks. This first version is only going to have four items -- Bold/Italics, Links, Mentions and a switch for wikitext editing. We're definitely going to do more work on toolbars, but we want to see how this first one works before making any solid plans.
Sure, but there should be always a switch to view the wikitext version of an answer :)
If you're going to add Bold and Italics, could you please also add Code? That gets used a lot on this wiki, and it should be just as easy to add as Bold and Italics.
Editing other people’s comments is also needed, since new people often paste PHP configurations or logs, without wrapping them inside <pre></pre> tags, so someone needs to fix them to make the posts readable
I'm not sure, but i can edit comments from other people, so i think there is an user right, which is currently set to sysop only?
flow-edit-post is only granted to administrators.
That is changing very soon, per phab:T90670 ("Enable Flow post editing for autoconfirmed users on MediaWiki.org, English, Russian") as a first step. (Currently in code-review, so nearly here).
I think you all missed some old good rants. So here is one :) why the hell is the URL Topic:Sdoatsbslsafx6lw and not something easy to read and remember?
Yeah, I agree that's annoying. We need a unique ID for topics, so that we can do things like moving a topic from one board to another, or generating a feed of the discussions you're involved in. But that gives us ugly links that are impossible to make sense of. There are a couple ideas for how to make them easier to read -- either adding extra text at the end that has the topic title, or generating links that automatically display with the correct title. It's not at the top of the list right now, but it's something we'll need to build.
Yes, please! Will an opt-in kind of feature ensue, or should I create some LQT discussion pages only to get them converted to Flow soon? 0 :-)
Assuming the LQT conversion goes smoothly, we'll start talking about turning Flow on for pages that don't exist yet, and then the wikitext pages. But feel free to use your own workarounds. :)
Yeh this works on mobile! Liquid threads 0 flow 1!
- Something I liked about the wiki system is I could correct others. I'm not talking about ortography mistakes but about broken links and something obviously wrong or missleading. Maybe an option could be added to propose a correction to the author, but I would like if this correction could be seen/accessible somehow before the author accepts or rejects the correction.
- I miss the "wiki" editing box, where I can add symbols (like « ») and formating like listing (*) or bold letters (that). Now I wonder if this is going to be like the old code editor or like the visual editor.
We're actually going to try out allowing users to edit other people's posts in a couple of weeks. There'll be a link to edit in the dropdown menu. If you edit somebody else's post, then the timestamp will say "Edited by Ssola 1 minute ago".
This has always been possible for admins. Is the plan to expand to autoconfirmed editors? I really don't believe that we are improving communication by making it easy for IPs to vandalize other people's comments.
Exactly. Autoconfirmed+ will be the next step that is tried, and just at the wikis that have requested it: phab:T90670.
(edited by BanjoDog (Danny) because editing is now available to autoconfirmed users -- sssh don't tell anyone)
Also, the link with text "March 26, 2015 5:33 PM" (whose text I was not able to copy because it keeps hiding when I try to select it!) points to https://www.mediawiki.org/w/index.php?title=Topic:Sdjk2ce202ud1fl0&action=history where I didn't find an easy way to see what was changed. Then I tried the "prev" link to https://www.mediawiki.org/w/index.php?title=Topic:Sdjk2ce202ud1fl0&action=compare-post-revisions&topic_newRevision=sea6olf6raeposmg
(same problem for the "cur" link)
fix for this BadMethodCallException on compare-*-revision pages going out in ~4 hours
The previous comment was edited by two people (BanjoDog and me), but it only mentions my username (I edited it last).
Thanks for pointing that out -- we recently fixed the prev/next function for diffs, and it would make more sense for the "Edited by X" link to take you straight to the most recent diff.
The purpose of that text is to flag that someone edited the post who isn't the original author. I don't think that putting more than one name in that field makes it any more informative; you still wouldn't know who edited what. But linking to the diff would help you to browse through all of the revisions. I'll make a ticket.
TOC "Browse topics" behavior is rather wacky, I would say.
On the top of the page, (when clicked) it would display in the order of edit (newest at the bottom), while the threads itself is in reverse order (newest at the top). If it stop at that I would not complain. But then (while the TOC is open) when I scroll to the bottom, suddenly the TOC changed its behaviour and reordered everything in reverse (newest, current section at the top), which suddenly disorient me and while I understand the intention of the devs, I wouldn't be able to get accustomed to that.
Plus, the TOC is blocking the view, while about 40% space in the right hand side of the screen is left empty (I'm using monobook btw, if that's matter). Wouldn't it be better to put the TOC on the right?
Steps: 1. Go to the top of the page 2. Click "Browse topics" (TOC) 3. Scroll to the bottom of the TOC 4. While the TOC is opened, scroll down the page a little bit (probably until the next section or two), until the TOC flipped, the TOC is suddenly scrolled to the top of the TOC 5. Scroll up again, and it's magically flipped again Repeat 4 and 5 to get yourself dizzy. Which way is up? Which way is down?
There are two possible orders for the board, "Newest topics" (the topics that were *started* most recently) and "Recently active topics" (the topics that had *activity* most recently, anything from being started, to a reply, etc.). You can change this in the top right (next to Browse topics).
Note, neither neither of these are meant to have newest at the bottom. Either the newest topic is at the top, or the most recently active topic is at the top.
However, the TOC and board should always use the same order. Note that when you scroll the page, the TOC also scrolls at the same time, showing you where you are in the board. However, you can still scroll wherever you want in the TOC manually as well.
If the order really is inconsistent, that's a bug. To help us track that down, can you tell us:
1. What board does it happen on? 2. Which order are you using? 3. What are the first 3 topics of the page, and first 3 of the TOC? 4. When did you do this test?
Also note that if someone changes the board in the meantime, that may lead to some minor discrepancies as new topics are loaded (pagination, essentially). This will not lead to a full-scale flip, though.
As I checked again today, I didn't notice the wackiness anymore. Thanks.
Just one small request
Please return the hotkey Alt+Shift+"S" for Saving, pretty please, with cherry on the top.
(while you do that, you could do Alt+Shift+"P" also for Preview, but that's not as important as the first; currently Alt+Shift+"P" tries to show the printable view of the page instead)
Thanks for this project
I coincidentally found this project and and I want to say "Thanks" for the work you already have done. I am looking forward to the day the Flow extension will be enabled at German Wikibooks where I mostly work. Good job!
Thanks for the feedback. We are currently rolling out gradually to smaller wikis, so if you're interested, keep in touch.
In addition to this page, we have an IRC channel (public mailing list.) and a