For some reason, when I clicked in one of my Echo notification, which was pointing to https://www.mediawiki.org/w/index.php?title=Talk:Flow&topiclist_sortby=newest&fromnotif=1#flow-post-s2gcx0zvqjwnp6ct, I got blue bars on the left side of many messages, mostly messages I didn't see before. However, some of these did read before, and should not be highlighted again.
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.
Never do an edit without leaving a summary
This is a golden wiki rule dating back to the very early days and I am very much into it. I teach this as the very first thing to new people interested in wikis. While this may not appear very important for edits in the first place for your own posts it is indeed very much so if editing foreign posts. That's actually one thing that irritated me on bugzilla and currently irritates my on phabricator or on TUX.
Edit: One could argue that providing a summery by adding an Edit: to the post like I am doing it now is enough but in the long run Flow supporting such a feature will be nice I believe.
Thank you for pointing to the task on phabricator. As expected it was already there.
Same goes for Flow, I don't know where I could put my edit summary to, but hey, this is something new, they don't care about the Wikiverse and good experiences from the communities. In SF they want to invent all new from scratch without being bothered by the unwashed masses (who de facto do the real work here: content, not bling), that's more sexy then just evolving the very good stuff already there.
Your post moves this thread into a slightly negative mode which does not help I you would like others to (re)implement features. I see my post more like a strong reminder for important things that should be and most probably are already in the pipeline but have not been implemented yet because other features needed a better polish first. New things cannot have all features from the start. Also I would not like to blame the Flow programmers for things that have been done suboptimal by other programmers of different features in the past, like e.g. VE or so.
You're right, it's "slightly to the negative", sorry for using your thread for this, but WMF (and it's programmers) have lost next to all AGF they ever had with the fiascos VE (first implementation), MV (with it's extreme aggressive implementation against the communities) and now this unwanted, useless Flow-forum-impersonation with complete loss of connection to the normal wikiverse. Flow is a move away from the wikiverse, towards unwanted facebookisation. It might be fine for programmers to build new things from scratch, it's completey wrong in a well functioning surrounding like WP, especially as requests from the communities are regarded with contempt. The WMF should improve the wikiverse, not build something new in parallel, and Flow is something new in parallel.
Your post offends me since I politely asked you not to use this thread for bashing of any type. All you are saying has been said on numerous other places and I deliberately did not participate there. Now I see myself ending up in such a discussion.
Topic not showing up after editing it
Topic:Sedrllzckauwfm50 does not show up here though it should. Probably due to the fact that I messed up by embedding a parser function without wrapping it into the "nowiki" tags as I should have. Stupid me. :(
How do I indent an reply to a particular post?
Is see that people have maganged to actually indent their reply to a particular post within a flow thread. However when I click on reply I end up at the initial level.
For posts already saved, there is no way to change the indentation. See phab:T78253.
Thanks for noting this. From my past experience with LQT is was quite rarely necessary to relocate a post. So in my opinion not a front burner thing to have if at all.
This answer to the original post, that should be in the same indentation level as all other answers to the original post, is in another level, while my answer to a post down the thread, that should be one more level indented, as it's an answer to an answer, looks like it's on the same level as the original post.
You've got to plan this indentation for real discussions, not for simple two-post threads. If it's not capable of working something like a real discussion with several dozens of posts, diverse sub-threads, it's useless. It's definitely not a proper replacement of a real talk page. It's just one more step in the facebookisation, read dumbing down, of the WP.
Edith says: This looks like an answer to He7d3r, while it's an answer to Kghbln, because the indentation is fucked up.
So why doesn't this post end up indented?
Either I am too stupid which may very well be the case or I am missing something. Dunno if I should be sad or grumpy right now.
Try to indent 1. level
Edith says: Didn't work as expected, was possible before. Something seems to have changed.
- Next level indentation.
- Trying the usual colon to indent, lets see what happens.
Edith says: Lines do indent, the post doesn't. The second line (scnr) was somehow more indented as I did this edit, dunno why.
Seems to be bug then. Let's wait for the fix. I production this would be a near fatal bug if one cannot move particular post to a new location like in LQT but even then. Have not figured out how to relocate posts yet. Probably a matter of user rights.
See the clearest explanation at I CAN HAZ IDNETATION? - which I'll try to condense down into an FAQ sized answer, next week.
Ah, now I get it. I guess there is something to it. Since this is breaking with classic as well as LQT talk (10+ years of habit) it will imho indeed be very important to note this change quite prominently. If people do not know this they will definitively bang their heads against a wall like I did this morning. To cut it short: The issue is not how it will be done here, but telling people that it is done differently.
There is a difference between answering to the last post in a thread, like I do now, and answering the original post in this thread, and now this big difference is blurred methinks. Just have to test it with another answer to the original post.
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).
Special:ListGroupRights shows flow-edit-post for autoconfirmed today.
Edit by Sänger: And I had to try this asap, seems to work for typing, now the final click on save...
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!
Is there an equivalent to "Special:NewMessages" for Flow? I use this to keep important threads sticky in privacy. I probably could use personal categories for this once it is implemented (for MonoBook?) but these categories would not be private. I cannot really use my watchlist for this since I follow much more threads which only pop up when action takes place. So basically something inbetween inintial notification of a new post and watching all interesting threads will be cool.
Admittedly I did not read the talk following the initial post till now. So I am not the only one missing this and I believe that phabricator:T93109 addresses this.