When will be the mobile version of Flow available? Is there anything going on that side? Now more and more people are editing from mobiles.
About this discussion
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.
Mediawiki edit policy
I edited the Flow page with the "edit" tab when not logged in. Isn't this an invitation to wipe-out your entire wiki?
No. That's how wikis work.
What a human readable thing. Can't they contain at least talk page's name? --~~~~
Oh and it seems I cant even make a link in the heading. How is it expected to be used? --~~~~
Damn guys why can't I use a signature in that thing? And that monochromatic nickname at the top of the post just kills the feel of being on talk page. --~~~~
See T90593 and T53154, which are vaguely related.
Oh wait, they do not work at Talk:Sandbox but they work here (although they are marked as external links). Completely weird.
Hardly understandable threading model
I have made a few tests on Talk:Sandbox with a mock discussion. Nothing too complicate: there is a proposal, three users answering to the proposal and one user endorsing opinion of another user.
The problem is that new threading model make any non-linear discussion unreadable. Once there is a deviation from linearity, that's the deviation that becomes linear, while the main thread moves on the next level. In the cases I have shown the discussion becomes difficult to read (and even more difficult to summarise). In fact this threading model is simply counter-intuitive and does the opposite to what you would suppose. That's sad as this could have been a real discussion and this could have meant that Gdańsk would become Danzig (nothing personal, just a famous edit war, sorry).
In that example, the problem comes from Encyclopaedist003's position being ambiguous, as the "your reasoning" and "this spelling" may refer to any of the positions stated so far in the discussion, and because it doesn't use the traditional "support" or "oppose" !vote. How is this fault of the threading model?
In that situation the proper thing to do would be to ask this user for further clarification; such ambiguous comment should never be taken into account to decide consensus in a real move discussion.
The comment was a bit intentionally vague. The discussion was rather real, it was inspired from a real discussion on ukwiki village pump with the following structure:
- Comment on answer1
This is a very simple threading structure (max. 2 levels) and is very common for discussions. The problem of Flow threading is that a) comment can become vague because of being misplaced; b) logical order of comments is broken.
That assumes that there "is" a logical ordering of comments where every post is a direct reply to exactly one previous comment in the thread, and that you can always tell which one is the parent post. This is a convention in talk pages that is not at all obvious (making it difficult to newcomers to tell what's going on), and it's not always true.
BTW, the structure of that particular example conversation in your post would be exactly the same in the new hierarchical model, except with one less indentation level in all the answers and comments.
"Preview"/"Vorschau" is the wrong name, or better: it's the wrong link
There's a line called "Wikitext verwendet Markup und du kannst jederzeit eine Vorschau des Ergebnisses anzeigen." (Dunno how it's in english), that is utterly wrong. It's not a preview, it's just a switch to VE, and that's something completely different. Especially as there is a special button for switching to VE.
Either change the text (not preferred) or use a proper preview there, without VE.
Just tried it with english setting, and it's called: "Wikitext uses markup and you can preview the result anytime.", so again a wrong, deceitful wording. It ain't a preview, it's just VE.
And VE is just an editable preview.
Quieter Echo Notifications for Flow, after first glance
The new feature phab:T94634 ("Quieter Echo notifications for Flow posts") was released this week. This will change the red New Notifications badge to grey, as soon as we click on it, whilst retaining the number for any still unseen Flow notifications. The goal is to help make it clearer when we get a brand new notification, if we had previously decided to leave some unread - E.g. If I had unread notifications, but wanted to leave 2 of them for later, the badge will be colored grey, and have the number "2"; then, when I receive a new notification, I can easily see that by the fresh red coloring as well as the number incrementing, without having to recall what the previous number was.
Design tweaks to fix the low-accessibility of the white text on grey background, will follow. (phab:T98526)
Note: There is one existing bug for this - it currently always shows as grey if we have "1" unread/unseen notification. That bug has a patch awaiting code-review and will be cherry-picked as soon as possible. (Technical details at phab:T94634#1264132)
Missing link back
As an off-shot of Topic:Sdoatsbslsafx6lw.
I am glad Editing other people’s comments coming last week of March, and Search are being worked on. They are both a feature of LQT, and are in this little list. Some things were not prioritised though.
- Ability to split and merge messages phab:T97983
- Ability to move individual messages phab:T97984
- Ability to indent and outdent messages (both mine and someone else's) phab:T97985
- Ability to edit the signature (and timestamp) of others' messages phab:T97986
As you see, I filed a task for each of them, and linked to this thread (as well as to the little list) in their description. I am hoping this helps us keep track of these issues and implement them.
Yeah, that's becoming a meta tracking bug now...
There are a few items in its description for which I didn't create a specific task yet.
Gryllida, are you assuming that we're going to be converting wikitext talk pages to Flow? We're not planning on doing that -- we're going to convert LQT pages, but wikitext pages will just be archived.
The "ability to edit the signature and timestamp" ticket looks like it comes from the assumption that you'd need to fix a problem that's created by converting wikitext to Flow. I can't think of a reason why you'd want to edit a message creation date; it's system-generated.