Talk:Flow/Interactive prototype

This page used the LiquidThreads extension to give structured discussions. It has since been converted to wikitext, so the content and history here are only an approximation of what was actually displayed at the time these comments were made.

This page is an archive. Please leave any new feedback about Flow at Talk:Structured Discussions instead. More comments on the original interactive prototype can be found at w:Wikipedia talk:Flow/Interactive prototype.

Two initial constructive comments.

I don't care for the tattered paper edge to show more comments. Maybe something smoother would look better.

We're losing a lot of vertical efficiency with the space buffers around the different fields. Can we tighten the design up so that comments are more thin/tight and more comments will appear on a single screen?

Thanks for the great work. Ocaasi (talk) 17:18, 9 May 2013 (UTC)Reply

Agreed with both comments. The vertical space could be compacted if the "X edits since Y" were hidden by default (just like the board/contributions links). Also, the reply button could be made square with an icon (say, something like this) and placed on the right of the message, thus saving the vertical space in the bottom (the mark abusive could be moved to the header). For accessibility reasons, the icon reply button could get expanded on hover to include the text. Something along these lines would save a lot of vertical space. Waldir (talk) 00:09, 10 May 2013 (UTC)Reply

Will it be possible to edit messages (both our own and others')? I couldn't find any indication of such in the interface. Waldir (talk) 23:59, 9 May 2013 (UTC)Reply

From what was said during the office hours today, yes, certain groups (presumably local admins) would have the ability to edit other people's comments, but most users would not have that ability. Users will always have the ability to edit their own comments. Finally, whether it is the commenter or a sysop that edits the comment, the change will me logged/marked.

Staffer should feel free to correct me if I'm wrong.

(Testing to edit someone elses text... Mange01 (talk) 20:31, 15 July 2013 (UTC))Reply

Ok, sounds good enough, although it'd be nice to see the intended user interface for that :) I'd just add that probably requiring a sysop to edit someone else's comment would be a little overkill. I think something more akin to rollbacker, or editor would be more adequate. Waldir (talk) 12:08, 16 May 2013 (UTC)Reply

Nice. I believe in this. But I want to be able to edit my own text, but prevent non-administrators from changing it, perhaps causing some kind of indication that the message is revised. That feature is a recent trend in social media. Mange01 (talk) 20:29, 15 July 2013 (UTC)Reply

See the newest version of Flow Portal/Interactive Prototype, which adds a text indicator once you've edited someone's comment (enter "admin mode" (in the sidebar) to test it out).

See Talk:Flow/Interactive prototype#c-Quiddity-2013-07-15T04:37:00.000Z-Jasper_Deng-2013-07-15T02:50:00.000Z for my comment&pointer about user-level-restrictions. Quiddity (talk) 02:16, 16 July 2013 (UTC)Reply

I agree, that really shouldn't be called an "admin" action - it is a part of everyday wiki cleanup to move around or archive comments left by others in the wrong place, or left inappropriately. Making that right something that all editors or rollbackers have should suffice. Sj (talk) 08:05, 16 July 2013 (UTC)Reply

Couldn't agree more. Waldir (talk) 12:20, 16 July 2013 (UTC)Reply

I've added "(or other user-group)" to the documentation, per discussions. If one user-group is selectable, any user-group is selectable. Quiddity (talk) 18:26, 16 July 2013 (UTC)Reply

I would like to stress this a bit. I find it very strange that there is no "edit" action for all posts in the mock-up. There are lots and lots of reasons why an experienced user wants and should be able to edit posts written by other users:

• Simply fixing a broken link.
• Clean other markup and make the post more readable. For example add or remove newlines. Some users tend to put an empty line after every sentence. This makes talk pages ugly and confusing no matter what software is used and should be allowed to fix.
• Move a post or parts of a post to an other talk page and leaving a "moved to" hint.
• Top reason: What if I want to copy and paste parts of the wikitext an other user wrote to use it in the article? Or even simpler to look at it and learn the syntax.

Therefor, in my opinion it must be possible to edit all posts. At least for autoconfirmed users. All other users should have the possibility to show the wikitext of all posts like they have with every protected page. TMg 17:35, 31 July 2013 (UTC)Reply

It is to be local Wikipedia option as to who is to be able to edit others' posts. Although WMF's initial concept was to be admins only, en.Wikipedia has come out strongly for all users. Arthur Rubin ^en.Wiki (talk^en.Wiki) 17:51, 1 August 2013 (UTC)Reply

What does "en.Wikipedia has come out strongly" mean? Do you have a link? TMg 19:43, 13 August 2013 (UTC)Reply

en:Wikipedia talk:Flow#Request for Comment on editing other user's comments with Flow Diego Moya (talk) 19:54, 13 August 2013 (UTC)Reply

Thanks. (And there you have an example for editing foreign comments, I made your copied http link a short wiki link.) I hope we don't have to do the same poll in every local Wikipedia. For me this is very obvious. I can tell you the German users will vote identically for the reasons provided above. Maybe we have to do a poll if unregistered users should be able to edit posts made by registered users. But since it's a wiki and everything can be reverted there is simply no need to restrict editing.

Erm, by the way, how will the version history look like with Flow? I really hope you can do better than Wikidata (with it's millions of tiny edits nobody can track). TMg 20:44, 13 August 2013 (UTC)Reply

As far as we know, there will be no version history - at least not for the whole thread. Only the history of each individual comment can be queried. This is not what we understand by a wiki. Diego Moya (talk) 12:51, 14 August 2013 (UTC)Reply

Perhaps you should explore the prototype some more; whole Topic history has been there for quite some time. Jorm (WMF) (talk) 23:45, 17 August 2013 (UTC)Reply

You're right, I missed the History option as it's located at a different place than in current talk pages, hidden under the Actions menu. WhatamIdoing informed us that there wouldn't be a per-board common history, just a per-comment history, thus my comment above.

Will this history be equivalent to the current page history? By this I mean whether it will provide:

- several records for the same comment, in case the comment is edited more than once.

- a diff of the exact content that changed during the edit.

- direct "diff" comparison between two arbitrary versions of the Board, encompassing changes to several comments. Diego Moya (talk) 22:48, 18 August 2013 (UTC)Reply

Go ahead and play around with it. Edit someone's comments; you'll see new entries are added when that happens.

I can't speak to how well the diffs will work (as that's a Parsoid thing) but I think actually the ability to page through historical changes may be more useful. We're doing a lot of looking at how to handle this - it's a non-trivial problem, one that WikiData has as well. I don't have a better answer for you than that, other than that I've seen a couple stabs at handling "visual diffs" float around. Jorm (WMF) (talk) 23:36, 18 August 2013 (UTC)Reply

"the ability to page through historical changes may be more useful"

It's certainly useful, I use it myself often. That doesn't preclude creating diffs of several comments at once. I use those often, too, for different purposes. I usually do the latter when I want to find out all that changed between two revisions, and the former when I want to know exactly what a user edited.

Visual diffs would be the final presentation step; the way to retrieve what can be sent to Parsoid to find diffs depends on how Flow stores comments, so it's directly related to how you can find all edits in a Board. Am I right? Diego Moya (talk) 23:46, 18 August 2013 (UTC)Reply

Excuse me, there's some misunderstanding here. I've tested the prototype again after a good sleep, and I still can't find a global history that will show changes made to all comments with the same owner Board, only the one that shows the history of a single thread.

You seem to be talking about Topic history, which is what I found yesterday. Per-topic history is not global per-board history. So, is it true what WhatamIdoing told us after all? A per-board history feature is not planned? Diego Moya (talk) 05:52, 19 August 2013 (UTC)Reply

I think that there are some good ideas about functionality here, but, to be frank, I disagree with a lot of the visual choices.

1) The tag, star, and gear icons are too close together, which makes it look muddled. I would personally like to shrink them down just a tad and up the padding between each one a little bit.

2) The indent between each reply (how much indented to the right each box after the first begins) is a bit too much. I personally like the indent size used in this interface here better. For longer conversations, and with pages like ANI there are going to be really long conversations, the number of replies before everything gets squished is really important.

4) There is so much surrounding each comment that I can fit, at most, three or three and a half comments in without having to scroll. In the current system I can see upwards of 10 or 15. This is going to make dealing with conversations of any reasonable size difficult.

4) On a related note, let me turn your attention to this screenshot, taken from the live demo. Aside from that the heavily padded boxes around each separate comment make that conversation absurdly long, the indenting is extremely confusing. It jigs back and forth liberally. Now as someone that's been around his fair share of forums, I know that the jigging and jagging means that we're dealing with different subthreads, but many people aren't going to know what's going on. Additionally, the combination of crazy indenting and crazy length makes it very difficult to follow an individual subthread without getting lost. I strongly suggest that you implement a subthread collapsing system like the one at imgur (picked that one because it had lots of subthreads several posts deep for people to play will collapsing and uncollapsing) so that people can follow long conversations easier.

5) I realize that this is a prototype, but the amount of whitespace off to the right in my widescreen is just bad. I know that there is literature on maximum width, and it makes sense to do what you can to prevent eye strain, but it just looks awful.

But other than all that, I like where it's going thus far. Sven Manguard (talk) 02:25, 10 May 2013 (UTC)Reply

Can this feature be disabled? DaSch (talk) 18:23, 14 May 2013 (UTC)Reply

I'm not sure what feature you're referring to. If you mean Flow - that is, the entire thing - the answer is "probably not". Once it's active, it is active. Jorm (WMF) (talk) 19:09, 14 May 2013 (UTC)Reply

so there is not an option like with Liquid Threads so use old style user discussion page or lqt disussion page instead of this ugly flow overkill? DaSch (talk) 19:46, 14 May 2013 (UTC)Reply

Correct.

Good talk, as always. Jorm (WMF) (talk) 19:55, 14 May 2013 (UTC)Reply

Talk pages are necessary to talk about the content we put into articles. Will we be able to use the same features and syntax in Flow as we can use in Wikitext? Some examples that just come to my mind:

• Basic syntax for text formatting, font size, font face, lists.
• Wikilinks (including interwikilinks to all WMF projects).
• Including images and tables using the same code as in Wikitext, appearing the same as in Wikitext
• Including templates and using custom tags like <code>, <source>

Right now were able to include everything we could put into an article on talk pages. This is absolutely necessary to efficiently produce content for Wikimedia projects. We can't discuss content without visualizing it on talk pages and highlighting the necessary Wikitext. Patrick87 (talk) 21:37, 15 May 2013 (UTC)Reply

Flow will utilize the VisualEditor, so you'll be able to do all the things that the VisualEditor supports.

It's important to note that we are currently focusing only on User Talk pages, and not article talk pages. Jorm (WMF) (talk) 21:39, 15 May 2013 (UTC)Reply

So you are saying that you're forcing everyone into using the Visual Editor, even experienced editors which are much more comfortable with classic Wikitext? Is there a reason to force users using VisualEditor? Shouldn't it be optional so everybody can choose?

"Currently focusing only on User Talk pages" already implies that it will probably be extended to other talk pages as well. Besides that it doesn't really make a difference if it's used only on user talk pages or also article talk pages. User talk pages have exact same needs as article talk pages in my opinion. Patrick87 (talk) 21:50, 15 May 2013 (UTC)Reply

The primary reasons why we are using the VisualEditor in Flow are to a) create a consistent user experience for people and b) to ensure that all posts will be able to be edited by the VisualEditor. Starting with the VE is the best way to ensure that. Jorm (WMF) (talk) 22:06, 15 May 2013 (UTC)Reply

Well, consistent would be to have the same editing functionality everywhere on Wikipedia (basically what we have now) instead of mixing normal articles with LiquidThreads and Flow.

Where is consistency when I'm forced to use Visual Editor on talk pages although I don't like it?

I think you put the cart before the horse: If Visual Editor isn't able to correctly parse all Wikitext it should be fixed. Using a crippled Visual Editor as a "consistent base" neglecting functionality that was there since the early days is just wrong.

If you can't achieve Flow to be as flexible as current talk pages are it will never be a satisfactory replacement. Patrick87 (talk) 22:16, 15 May 2013 (UTC)Reply

You might find watching some of the user test videos enlightening with regards to why Wikitext is a bad idea. Jorm (WMF) (talk) 22:21, 15 May 2013 (UTC)Reply

(Content removed). Posted twice because the flow editor failed to refresh the page and show where my first comment were. Oh, the irony... Diego Moya (talk) 10:42, 15 July 2013 (UTC)Reply

Forcing all users to use Wikitext is a bad idea, I don't think nobody is denying that. But forcing all users away from Wikitext is an equally bad idea, and this is said by someone who love visual editing and user-friendly workflows. The fact that you don't seem to realize the reasons of why such is the case is utterly worrisome, given that you seem to be in charge of the design. That you actively want to get rid of wikitext is decidedly alarming.

There are features in plain text editing and formatting that simply have no match in the state-of-the-art approach to visual editing. Copy-paste workflows, re-arranging, quick access to parameters from memory by expert users, touch-typing... those are severely hurt or right away impossible in full-featured visual editors, let alone new developments with entry-level features.

A decision to remove wikimarkup completely would break the workflows of millions of expert editors, which are the majority of your current users, and certainly the more vocal ones. The huge resistance to change that the VE and Flow are facing are because so far any of you have failed to even recognize that this might be a problem. Please say that you have some concern for we the veterans, and that experienced editors are not going to be thrown to the wolves with the vague hope that new editors will come in masses to fix the project thanks to the usability improvements alone. Diego Moya (talk) 10:47, 15 July 2013 (UTC)Reply

It's not the Flow editor, it's the LiquidThreads editor. Flow doesn't exist, yet. Arthur Rubin ^en.Wiki (talk^en.Wiki) 16:42, 15 July 2013 (UTC)Reply

There's also another thing to consider:

It is entirely possible that the data for each post will not be saved as wikitext because there are considerable performance issues that arise when doing so. If this is the case, things like templates will simply be unable to be supported. Jorm (WMF) (talk) 22:34, 15 May 2013 (UTC)Reply

<redacted> Anomie (talk) 22:45, 15 May 2013 (UTC)Reply

I would dearly love to kill off Wikitext. But perhaps you should talk to Gabriel Wicke about that. Jorm (WMF) (talk) 22:47, 15 May 2013 (UTC)Reply

And remove the one thing from Wikipedia that makes it unique?

When I realized in my early days how the simplicity of the WikiEditor provided even beginners with all the necessary tools to write articles but at the same time a huge amount of HTML, CSS and JavaScript was at hands of the experienced users I was astonished.

Now I'm astonished how these functionalities are to be stripped out one by one... Patrick87 (talk) 22:54, 15 May 2013 (UTC)Reply

I think that, in the List of things that makes Wikipedia unique, Wikitext is not there. There are far more important things that make us unique than an esoteric scripting language.

Like, "free knowledge for all," or "it's in your language," or "anyone can edit". Note the last one: Wikitext is a barrier to achieving that goal. Jorm (WMF) (talk) 23:13, 15 May 2013 (UTC)Reply

"Free knowledge for all" and "it's in your language" are directly dependent on "anyone can edit". And I think you're wrong that Wikitext could be a barrier here: the most stupid idiots (sorry for that, but it's true) are able to use simple editors like the Wiki-Editor (that's what most forums have, and it works). Patrick87 (talk) 23:31, 15 May 2013 (UTC)Reply

Okay. I'm going to have to take issue with you referring to our users as "stupid idiots". It's this kind of talk that pushes people away from the projects, never to return. Jorm (WMF) (talk) 23:33, 15 May 2013 (UTC)Reply

Did I say Wikipedia users were stupid idiots? I said stupid idiots could use the Wiki-Editor.

That means Wikipedia users should be able to handle Wikitext with ease in most situations... Patrick87 (talk) 23:36, 15 May 2013 (UTC)Reply

Well, given that we have a lot of users who come in and get baffled by markup after one or two contributions, you didn't - you said some of our users are worse than idiots ;p. But this is a distraction from the main point.

When you say 'wiki-editor' that most forums have, what are you referring to, exactly? Okeyes (WMF) (talk) 23:38, 15 May 2013 (UTC)Reply

Im refering to a simple editor that uses some simple markup to format text and offers some buttons to insert this markup (like &ltb> [b] and the like). Some of them directly show the markup as Wiki-Editor does, others offer some basic WYSIWYG like Visual Editor.

To add a little personal experience: In the case of simple markup editors I never heard someone complaining it was too complex. I often hear people complaining about simple WYSIWYG, though, since they are also YNAGWYW ("you not always get what you want"). Patrick87 (talk) 23:47, 15 May 2013 (UTC)Reply

Totally; a lot of forums have that sort of markup (phpBB comes to mind). But there are several crucial differences.

1. First: while it is a common feature of a lot of forums, it's not a mandatory feature. It's perfectly fine to get along with posting without it (and a lot of people do!) Markup on Wikimedia sites, including on talkpages, is pretty much mandatory; there is very little you can do without some element of wikimarkup, be it section headings or signings.
2. Second: one of the reasons that the markup is, as you say, simple, is because there's a lot of things that forums handle that talkpages don't. If I want to post something on a forum, I post it; that's it. If I want to post it on a talkpage? Well, if I want a new section, I need headers and signatures. Not a particularly big deal. If I want to reply to an existing section, I need to know the various forms of indentation, properly scope how far I need to indent, signatures. If I want to do anything complex - anything 'meta'pedian, involving participation in the core workflows, I need indentation, scoping of indentation, signatures, links - and it only gets more complex from there. Closing requires template syntax, outdenting when something has indented too far requires template syntax, there are various different forms of indentation depending on how I want things to display, and so on and so forth. The fact that a lot of people can handle phpBB indicates nothing about wikimarkup; wikimarkup and what we expect users to handle is far more complex. We're comparing apples to oranges. Okeyes (WMF) (talk) 00:11, 16 May 2013 (UTC)Reply

They are both fruits in the end. Only look and taste a little different ;)

So youre saying "while it is a common feature of a lot of forums, it's not a mandatory feature". However you want to make VisualEditor a mandatory feature. How is one better than the other? If you want to protect the casual editor from Wiki markup try to improve the VisualEditor. It can easily handle things like indention and signatures (which are not that hard after all). Section headings are only one simple element in addition to the easy syntax of most forums and can be handled by VisualEditor, too.

All the things you're describing are much less of a hassle than trying to create a table with a WYSIWYG editor...

When you're talking about indentation: This thread is already so deep nested that it's impossible to get to the newest post easily. How should this be handled by Flow? How should the software now when to outdent? I think that's pretty much impossible. Patrick87 (talk) 00:30, 16 May 2013 (UTC)Reply

Ah. We are improving the visual editor. The way in which a WYSIWYG editor is better than having to write in a markup language, in terms of how user-friendly it is and what barrier to participation it creates, is...fairly self-explantory.

On indentation: I don't know; I'm the liaison/business analyst, unfortunately, not the interaction designer or developer. But it's a problem we're certainly going to have to tackle.

Why would you say it's impossible? Ironholds (talk) 01:43, 16 May 2013 (UTC)Reply

I see the point that a WYSIWYG editor is more user-friendly for beginners and I totally agree. No need for discussion here.

However, experienced users are much more productive with simple markup. That's why I'm saying always both possibilities should be given. Changing the system in favor of beginners while scaring off experienced users with the change isn't an option.

Why I'd say it's impossible? Because a computer program can only outdent after a given depth is achieved. This will inevitably lead to cluttering of threads. Human editors are able to tell when an new argument evolves and it is time to outdent. They can judge if a comment is so closely related to the previous that it should stay indented. Humans understand the structure of a discussion while machines never will. Patrick87 (talk) 09:56, 16 May 2013 (UTC)Reply

Sure, which can be handled pretty easily by replying versus splitting off a new sub-thread. Even LiquidThreads has that feature. Okeyes (WMF) (talk) 17:59, 31 May 2013 (UTC)Reply

Sure, but the initial argument was that it was too complex for new editors to care for indentation, which should therefore be handled by the software. Patrick87 (talk) 19:40, 31 May 2013 (UTC)Reply

Yes, but that doesn't mean it's exclusively going to be handled by the software, it means that people will have, say, buttons for using that feature rather than having to type out indentation. Okeyes (WMF) (talk) 18:46, 6 June 2013 (UTC)Reply

Oh yes, and this will be a lot more straightforward for sure: Fiddling around with buttons to somehow get the intended indentation level right instead of just counting colons and quickly adding or removing some of them... (sorry for the sarcasm)

The result will be people not caring for indentation at all resulting in deeply nested discussions, or no nesting at all (depending on the softwares default behavior). Maybe even totally messed up indentation because of some people replying to the last post while others reply to specific posts and even others reply always to the first post (I've seen that on other websites before)

It also won't be possible for experienced editors to clean up indentation because they can't simply add or remove some indentation to/from another post as it is possible with Wikitext. Actually the won't be able to edit other posts at all (and even if they could, I doubt they will start clicking buttons on multiple posts to realign all of them in a reasonable manner).

Anyhow were digging into some very specific details here already. We can talk about them if you want, but it won't solve the main problem that where having with Flow and what this thread was about initially: The fact Wikitext will be stripped out from the comment functionality and one will have to use the VisualEditor.

I don't think there are any news on this front, though (I followed the discussion on [:en:WP:VP en:WP:VP]). Patrick87 (talk) 20:29, 6 June 2013 (UTC)Reply

I'm sorry, but this doesn't make any sense to me.

Users will NEVER have to describe how deep they want to indent anything. Jorm (WMF) (talk) 23:49, 9 June 2013 (UTC)Reply

And how will you solve the problem we are just seeing on this page (yes, I know, it's LiquidThreads, but the same problem will apply to FLOW, too)? Every answer increases indentation to the point were more than half of the page is indentation. At some point the thread needs to be outdented again in long discussions. Or you have to omit indentation completely. Patrick87 (talk) 02:03, 10 June 2013 (UTC)Reply

Patrick, it is becoming clearer and clearer to me that you have read very little of the documentation. I'm not sure you've interacted with the prototype, either, based on some of the accusations and claims you're making here and elsewhere.

This is very frustrating to me, having to repeat myself.

The topic of indentation is discussed here; please read it. Jorm (WMF) (talk) 02:06, 10 June 2013 (UTC)Reply

No, I missed that part. I'm sorry.

Thanks for clarification. This seems like a reasonable approach to combine the benefits of threaded discussion without the downsides of unlimited nesting. Patrick87 (talk) 03:09, 10 June 2013 (UTC)Reply

How do I use w:Template:Outdent using the visual editor (or with this software for that matter)? The discussion is way too indented and I'd want to add an {{Outdent }} here so that I see more than a word on each line. Also, the indentation "fixes" things so that I only see one letter on each line in the edit window. Stefan2 (talk) 18:48, 15 July 2013 (UTC)Reply

You must have a smaller screen than I do. I had to run up to 200% to get your message down to about 10 characters wide. Still, this is LiquidThreads, and that will be Flow. which, according to the comments, is only going to indent about 6 before stopping. Arthur Rubin ^en.Wiki (talk^en.Wiki) 01:57, 16 July 2013 (UTC)Reply

LiquidThreads (this 3 year old system we're using here) doesn't have an outdent function, as far as I know.

You can see some of Jorm's thinking on discussion nesting at Flow Portal/User to User Discussions#Thread Depth Models. (And yup, you might want to start a new thread, if commenting/suggesting things based on that topic and documentation. ;) Quiddity (talk) 02:12, 16 July 2013 (UTC)Reply

Ironholds wrote: Ah. We are improving the visual editor. The way in which a WYSIWYG editor is better than having to write in a markup language, in terms of how user-friendly it is and what barrier to participation it creates, is...fairly self-explantory.

More user-friendly does not mean better for all uses!!!

Please note that (X)HTML is still being in use. Many people create WWW sites just by creating and editing plain HTML, CSS. WYSIWYG editors, actually, did not yet manage to kill plain HTML and CSS. Keep this in mind, OK?

Hopefully you are going to have any (at the very least, a brand new) text language behind your new ideas for Wikipedia (as you are, perhaps, going to kill Wikitext at all)? And that this language will be accessible and editable in text for all users?

Please clarify this. Thanks in advance. Marcgalrespons 14:26, 22 July 2013 (UTC)Reply

The text language behind the WMF new tools will be HTML5 + RDFa, which is a general semantic language for knowledge representation. (Being based on HTML, it's not as editor-friendly as wiki markup, which was intended to be lean and human-readable).

While this language is not backwards compatible with wiki markup, the WMF is also developing a translator between both formats called Parsoid, which is expected to have near-full backwards compatibility.

What remains unclear is how much of that compatibility will be used by new tools, built on top of the new storage format. The Flow developers in particular have made it clear that this tool will not support the content existing at current talk pages. Diego Moya (talk) 15:03, 22 July 2013 (UTC)Reply

Do you want to translate all of Wikipedia into your desired markup format? If not, Wikitext should stay in the discussion workflow so that old articles can be discussed and edited.

I concur with the comments about touch-typing, which I have not had success with in any editor which does not have markup format, including word processors. In fact, I have occasionally written Word and WordPerfect documents in a markup format, and written macros (with multiple custom search-and-replace functions) to convert the markup to/from "native" format. I admit to being a power-typist, but I'm sure some new users have learned to type. Arthur Rubin ^en.Wiki (talk^en.Wiki) 16:59, 15 July 2013 (UTC)Reply

I see this minimal requirement for Flow, that it can actually discuss whatever the article space contains (that is, Wikimarkup) has been ignored. Arthur Rubin ^en.Wiki (talk^en.Wiki) 16:21, 19 July 2013 (UTC)Reply

Actually, it hasn't. It sucks that there isn't a full design out for the ideas we have around collaborative posting, but there's stuff about it in documentation somewhere.

The reason it isn't highlighted is because article talk space is last on the list. First on the list is user talk space, and "discussing what is in the article space" is not a requirement for "user talk"; therefore my time has not been spent fleshing out parts of the system that will not see development for at least a year. But it has been thought about. Jorm (WMF) (talk) 19:07, 19 July 2013 (UTC)Reply

User talk space is being used to discuss what should be in articles, although most of that should be in article talk space or project space. Discussion of how to do something in Wikimarkup could be in the talk page of the article the markup is to be used in, but that doesn't work if the article hasn't been written yet, and it doesn't work well if the markup concept is to be used in multiple articles, but not as a template.

And, I say again. Unless article sections can be copied between articles and Flow messages, and can be edited in Flow messages, Flow is not suitable as a replacement for article talk pages. There may be alternatives, but, if Flow doesn't use Wikimarkup, then there must be a way to translate between Wikimarkup and Flowmarkup, such that any Wikimarkup (including templates) can be translated, and the translation can be done with fidelity. There might be exceptions for Wikimarkup and templates which should never be used in articles, but the Flow team must be prepared to quickly implement in Flow any Wikimarkup which is used in articles, or give up on using Flow as a replacement for article talk pages.

By designing this version of Flow, ignoring features which are presently used on user talk pages but do not match your model of what user discussion pages should be, you may be preventing integration of functionality which will be required for article talk pages. Arthur Rubin ^en.Wiki (talk^en.Wiki) 20:08, 19 July 2013 (UTC)Reply

(Partial duplicate message.)

Re: "discussing what is in the article space"

Well, think about it again. If Flow is not going to have full Wikimarkup (including templates), and the ability to edit raw Wikimarkup, it is not suitable for article talk pages. If Flow will not, at present, use Wikimarkup, then you will be creating a third representation of Flow messages (VE, Flowmarkup, and now Wikimarkup), and the translations will probably fail.

It's not your job, but fixing Visual Editor so it doesn't damage Wikimarkup is a difficult task, fixing it so it doesn't damage Flowmarkup is a separate task, unlikely to be completed by the time (someone) has said they would want to rollout Flow for article talk pages.

I'm not convinced VisualEditor will be fully functional by the time you are going to start rolling out Flow. You need to have a backup plan there, as well. Arthur Rubin ^en.Wiki (talk^en.Wiki) 20:18, 19 July 2013 (UTC)Reply

I don't think forcing a single experience onto all editors is conducive to any goals. Just let newbies use the visual editor on the talkpage if they like, but let me use the wikieditor. Maunus (talk) 23:19, 14 July 2013 (UTC)Reply

Many editors disable the Visual Editor. Are they going to be unable to talk? Or are you going to override their preference setting? Kww (talk) 21:35, 14 July 2013 (UTC)Reply

See also Talk:Flow/Interactive prototype#c-Stefan2-2013-07-15T18:09:00.000Z-Jorm_(WMF)-2013-07-13T22:24:00.000Z below. Will talk be disabled for people using certain web browsers? If so, then how will we interact with those users? Stefan2 (talk) 18:52, 15 July 2013 (UTC)Reply

It's been stated a few times that they will "provide a fallback mode" for people without javascript, or with browsers that don't support VisualEditor. Nobody will be forcibly excluded. (Take the rumors/hyperbole some people are spreading, with a grain of salt. There are a lot of unfounded/erroneous/exaggerated statements being made recently. Not all, but a lot.) Quiddity (talk) 02:07, 16 July 2013 (UTC)Reply

Wow, wait a second. What's going on here? I believed in you, guys. You always told us you want to analyze the existing workflows and provide an alternative interface for these workflows without breaking them. Using wikitext on talk pages is an essential feature. Removing this feature is out of the question. This would make the whole Flow project pointless.

Articles are edited in wikitext and always will be edited in wikitext no matter if the wikitext is edited in a WYSIWYG editor or at the source level. Experienced users (the goddam stakeholders in our valuable and beloved Wikimedia landscape) will always use wikitext. Always. They did this for over 10 years and will continue to do this for another 10 years for the same reason LaTeX is still used by experienced users since 30 years. It's not that these LaTeX users are grumpy old people and the only reason they are still editing at the source level is that they are to lazy to learn something new. Young people still learn and love LaTeX today. Same with wikitext. If articles are edited in wikitext it does not make any sense to ban wikitext from talk pages. Not even from user talk pages. We want to talk about the articles we write. We want to show examples of different formating options. We want to talk about different implementations of a template on our user talk pages. We need the same syntax we are using in the articles.

I really don't see a reason why it should not be possible to simply rely on wikitext in discussions like LiquidThreads does right now. Discussions don't use much formatting anyway. Unexperienced users don't need to care about any syntax details. They write a sentence and press "save". They don't need any WYSIWYG. This will only lead them to make their posts super-fancy with colors and all other formatting options they find. This is not helpful. We need talk pages to talk about articles. That's all.

Sure, wikitext is not nice and it's definitely a good idea to make it better (e.g. get rid of the single vs. double brackets confusion, ban deprecated HTML feature like the <font> and everlasting <center> crap). It's not that we need the current implementation of wikitext. It's a language. Languages can be translated. But we need source level editing for both articles and most talk pages. Please don't ruin the wonderful Flow project by banning wikitext. One thing is for sure: If you do this the big communities (especially the German community) will ban Flow. I don't want this to happen. I want a better software for talk pages. But it can't be all WYSIWYG. It must be a well balanced mixture. TMg 18:13, 31 July 2013 (UTC)Reply

I'v never had significant problems with learning wikitext, I know to use double square brackts for internal and interwiki links, and single square brackets for external links other than interwiki, what's so confusing about that, let alone for experienced. One thing is for sure, if liquid threads or flow are enabled on all talk pages, the name signing code (~~~ which signs the post, ~~~~ which signs and dates it and ~~~~~ which produces only the date stamp) is probably unneccesary, and probably should be eliminted from the wikitext on such sites.

On a related topic, see this relevant wikipedia ruling, had we not needed the name signing code, there would have been one less remedy in that arbitration case. Also in the WP signature guideline there is a limit to signature length in markup as well as display. With liquid threads and flow, signature clutter is eliminated. Also see Zelda Wiki's signature policy, liquid threads eliminates the need for method 2 and I'm sure flow will too. Myrtonos@ 13:03, 29 September 2013 (UTC)Reply

A few points

• The current prototype only uses VisualEditor for editing if you enable it in Special:Preferences > Editing. We'll temporarily be disabling VE for Flow soon, the integration needs work (e.g. a separate preference for Flow or maybe an [Edit/Edit source] way to switch editor, an appropriate VE toolbar for Flow, etc.).
• Most wikitext will work, I believe including everything Patrick87 originally mentioned. We're using Parsoid to parse wikitext. There are... challenges with things like magic words relative to the current "Page", and whether to store expanded templates.
• You can always use a subpage for the few wiki markup features that don't work in a Flow post, e.g. reflists. S Page (WMF) (talk) 23:16, 12 November 2013 (UTC)Reply

Does Flow properly support templates which display differently for different editors? Commons has lots of templates which display differently depending on the language setting. See for example Commons:Template:Dont upload Wikipedia thumbnails (depends on Commons:Template:Autotranslate), Commons:Template:Original upload log (uses MediaWiki namespace transclution) and Commons:Template:Self-photographed (depends on Commons:Template:LangSwitch). Stefan2 (talk) 00:23, 13 November 2013 (UTC)Reply

Good question. I don't know. S Page (WMF) (talk) 23:33, 24 November 2013 (UTC)Reply

The clickable areas in the headers of the Flow page need to be rethought. Right now you can click anywhere from the arrow all the way across to tags/star/settings icons (even though the mouse doesn't turn into a clickable cursor while over the arrow). You should restrict this clickable area to be only over the actual header text.

Also, some of the titles have links in them. How will this be handled? If you click the link, does it trigger the thread being opened, or does it actually follow the link? Parent5446 (talk) 00:35, 16 May 2013 (UTC)Reply

If Flow should ever get accepted at all I'd propose fundamental style changes:

• First of all the interface wastes by far too much space. Two lines of content are using up approx. five times the space because of

1. excessive padding
2. the disproportionate header (with user name, edit count etc.) and
3. the incredibly large reply button

Header and reply button should add two additional lines at most. Padding should be reduced to a minimum.

• Secondly the interface does not fit into Wikipedia. We have an Wikipedia interface (or more correctly various skins) with some recognition value. Flow should look exactly like every other page on Wikipedia. That includes especially headings but also all other content:

1. Headings should have the same level as on other pages (e.g. "h1" for the page title, "h2" for top level sections (which could actually be threads) and look exactly the same.
2. Large green "Reply" buttons or are a no-go. Simple textual links would suffice by far.
3. Actually styled buttons should be kicked out completely. We never used them in Wikipedia and it should stay this way. Use native inputs.

Don't start trying to overstyle everything. Stick to the classic skins (and make Flow skinnable as MediaWiki itself) so it blends into the rest of the page. Patrick87 (talk) 10:26, 16 May 2013 (UTC)Reply

I share the view above, I love the idea but the interface itself is too bulky.. Addshore (talk) 11:56, 19 May 2013 (UTC)Reply

I completely agree. Ypnypn (talk) 19:24, 20 May 2013 (UTC)Reply

I agree there is too much space wasted. It feels like there would be far too much scrolling with the padding, very large police, big buttons and so on.

I would nevertheless suggest that buttons might not be a bad idea necessarily. We tend to have lots of link and from time to time, it is pleasant to see immediately the one we should click upon. With people with visual problems, it might make sense to have buttons which would satisfy accessibility requirement possibly better than a simple blue word could do (I have never actually tested the contrast between the blue of links and black of text, but I would not be surprised if it failed accessibility recommendations).

Last, regarding space, it should not be fixed width but a width that automatically adapt itself to the support. If a phone, very small column. If a laptop, it would be more confortable; If a wide screen, it really ought to take the entire width rather than about 1/3 as the prototype is doing. Anthere (talk) 20:37, 23 May 2013 (UTC)Reply

I beg to differ slightly. I agree that consistency is good but actually most modern websites do have a lot more "white space" than Wikipedia does; it makes Wikipedia look cluttered and a bit old fashioned. I would argue things the other way - we want Wikipedia to look more like Flow than the other way around. But I guess that's down to personal preference.

That being the case, the question really becomes - is Flow skinnable? Can we personalise the css? Waggers (talk) 11:00, 6 June 2013 (UTC)Reply

It's awful. It works extremely slowly on my computer. 178.66.190.120 20:05, 18 May 2013 (UTC)Reply

It's a demo. It has not been optimized for speed in any way. Since everything is loaded and parsed via JSON, it's going to be slow no matter what. In the real world, it will be much faster since rendering will happen on the server. Jorm (WMF) (talk) 21:25, 18 May 2013 (UTC)Reply

Both expanding and collapsing all threads take about 1 minute, and page hangs for that time. 178.66.175.191 14:49, 21 May 2013 (UTC)Reply

Expand/Collapse all will most definitely not be in the final product. The function doesn't make sense when a page is an infinite-scrolling buffer (you could activate a "collapse all" but then topics that have not loaded at the time will not be collapsed, etc.).

It is also very important to note that this is an "interactive prototype". It's built out of html, javascript, and hope. It has not been optimized in any way and, by its nature of constructing and destroying elements on the fly, is going to be significantly slower than the real thing. Jorm (WMF) (talk) 22:48, 22 May 2013 (UTC)Reply

If "collapse all" is not available, will you provide a "Table of Contents" or "Titles List" instead? An overview function, allowing you to see the titles for all threads (and sub-threads) in a page is an essential function for quickly scanning the contents of a talk page. "Collapse all" was a poor substitute, but it at least provides that function in a limited form. Diego Moya (talk) 06:02, 30 July 2013 (UTC)Reply

Curiously, I found it pretty quick on mine. Anthere (talk) 20:29, 23 May 2013 (UTC)Reply

¿Que es este sitio? Leitoxx (talk) 22:04, 29 July 2013 (UTC)Reply

• Listing a user's edit count and user rights is probably a bad idea. The idea of an edit count having any real meaning is heavily rejected in certain areas. Showing the sysop flag prominently below the user's username would probably be quite damaging to a number of Wikimedia cultures, who place importance on user rights being not a big deal, and not something to be shown all over the place when it doesn't have immediate relevance.
• The "mark abusive" thing is also probably not a good idea. I assume it would be used to deal with vandalism, but I don't think that we get so much vandalism on talk pages that we need to have a button to mark it on every single comment.
• The "Last updated" marker for the topic seems frequently redundant to the time/date markers for comments.
• The little icons at the top right might be more than a little confusing. Using a gear as the "other actions" icon is generally not the expected meaning.
• The blinking in and out of the "(Board · Contributions)" bit is rather distracting.
• As others have said, that is really a lot of padding. Maybe a bit too much... Yair rand (talk) 20:00, 20 May 2013 (UTC)Reply

Aside from the issue of wasted space as already mentioned by others

1. I have been wondering how long the flow would go. Is it planned to go on forever as we scroll (the way twitter is doing) or can it be limited by preference ? (if stopped, it could be either by setting up a time limit such as "last week" or "last month" or "last day" which I think would reflect quite well on many current uses. Or it could be a fixed length).

2. Related issue... how is stuff archived ? I see there is a link for a future archived talk. What goes in archived ? and when ? and how ? I think most users are happy to somehow archived information for a time period (such as per months or per year). It should probably be a decision by the user, not something imposed. I am just curious how you are planning it given that the flow seems to be rather planned unlimited.

3. Full expansion versus complete collapse of a topic is I think unsufficient. Often, we would like to keep track of a specific comment that it drowned in thousand of lines. What about being able to collapse individual comments rather than the full topic ?

4. I am disturbed by the "report abuse". What if I click on this button ? What happens ? Is it "calling" someone to rescue me ? Who will come ? What will be the practical consequence of this ? I can imagine it will somehow feed a sort of list of "abuse reported", which can be looked upon by admin and eventually deleted. Right... If the "abuse" is in my own board or my feed, I want to deal with it myself first by being able to collapse it to *my* view. Hence a first need for an individual collapse thingy. But I would be happy to also deal with abuse for the benefit of others rather than selfishly for my benefit only. So I want to be able to collapse it from others views as well (the light version of what we do right now which is "removing" someone else comment) If we want to be logical, everyone should have the ability to report abuse. Then what happens with buggers who will find it funny to report abuse even when there is not ? An option to deal with that would be to have the abusive content flow ranking reports according to number of reports (10 reports high on the list. Only one report low on the list). But one single report can be a very serious one, which may be overlooked if at the bottom of the list. Well, overall, I fear that feature because I feel it very binding and inclusive that every one is able to deal with an abuse right now. Whilst the liquid thread system and the flow possibly make it able to deal with only by admins. And this is NOT going in the right direction. If I may suggest a rather radical solution... it would be that all comments could be edited and removed by everyone (edition and removal being actions able to be reverted of course). Of course, I realise the consequences of what I am asking for. I fear the consequence of removing that option will actually have a bad impact on community health.

In any cases... I hope you realise that we actually "trust" the admins (including our self) because we know that everything they do... can be reverted. Despite this, the number of editors becoming admins over time on big languages is dropping. This is a serious issue. If the admins are given the option to delete/edit comments made by others without the reverting option... the rate of people becoming admins will come to zero... and the activity of admins will drop because they will be aware an action is permanent. In short, flow needs to be wiki.

5. Is the flow going to work for all linguistic versions ? (for example, through a dropdown list of all projects for example ?)

6. Status of editors proeminently displayed in their post (admins, number of edits, staff etc.) -> very bad idea (already commented above by other editors. I agree with them. Please do not do that.

7. I would suggest it would be a good idea to better differenciate (or be able to select, unselect) the different spaces for the feed (main space, users, talk pages etc.)

And yes, otherwise, I like that very much ! Anthere (talk) 21:19, 23 May 2013 (UTC)Reply

Lots to talk about here; I'm going to go point by point. Please forgive any snipping.

1. I have been wondering how long the flow would go. Is it planned to go on forever as we scroll (the way twitter is doing) or can it be limited by preference ? (if stopped, it could be either by setting up a time limit such as "last week" or "last month" or "last day" which I think would reflect quite well on many current uses. Or it could be a fixed length).

As currently designed, it will be an "infinite scroll", yes. Filtering to a date range seems emminently reasonable, though. Non-javascript users will likely get a paginated version.

2. Related issue... how is stuff archived ? I see there is a link for a future archived talk. What goes in archived ? and when ? and how ? I think most users are happy to somehow archived information for a time period (such as per months or per year). It should probably be a decision by the user, not something imposed. I am just curious how you are planning it given that the flow seems to be rather planned unlimited.

That link is an example to show that the old "User_talk" - the wikitext page - is still available for reading. Ideally, we'd lock that down for editing (so as not to perpetuate a "shadow" conversation space). We don't want to delete old conversations, obviously.

The archiving system is totally different. You won't have to archive your discussions; that will happen naturally as time goes on. The system for archiving (and locking) is more fully explained here.

3. Full expansion versus complete collapse of a topic is I think unsufficient. Often, we would like to keep track of a specific comment that it drowned in thousand of lines. What about being able to collapse individual comments rather than the full topic ?

The system (currently) tries to be smart about collapsing of posts within a topic and only auto-collapses posts you've already read. To add a per-post collapse control is pretty cluttery - you can see how it works in LiquidThreads, and it's a bit clunky. I am currently working on a design for "zooming" into deeper threads that may solve for some of our other weird issues with this.

4. I am disturbed by the "report abuse". What if I click on this button ? What happens ? Is it "calling" someone to rescue me ? Who will come ? What will be the practical consequence of this ? I can imagine it will somehow feed a sort of list of "abuse reported", which can be looked upon by admin and eventually deleted. Right... If the "abuse" is in my own board or my feed, I want to deal with it myself first by being able to collapse it to *my* view. Hence a first need for an individual collapse thingy. But I would be happy to also deal with abuse for the benefit of others rather than selfishly for my benefit only. So I want to be able to collapse it from others views as well (the light version of what we do right now which is "removing" someone else comment) If we want to be logical, everyone should have the ability to report abuse. Then what happens with buggers who will find it funny to report abuse even when there is not ? An option to deal with that would be to have the abusive content flow ranking reports according to number of reports (10 reports high on the list. Only one report low on the list). But one single report can be a very serious one, which may be overlooked if at the bottom of the list. Well, overall, I fear that feature because I feel it very binding and inclusive that every one is able to deal with an abuse right now. Whilst the liquid thread system and the flow possibly make it able to deal with only by admins. And this is NOT going in the right direction. If I may suggest a rather radical solution... it would be that all comments could be edited and removed by everyone (edition and removal being actions able to be reverted of course). Of course, I realise the consequences of what I am asking for. I fear the consequence of removing that option will actually have a bad impact on community health.
In any cases... I hope you realise that we actually "trust" the admins (including our self) because we know that everything they do... can be reverted. Despite this, the number of editors becoming admins over time on big languages is dropping. This is a serious issue. If the admins are given the option to delete/edit comments made by others without the reverting option... the rate of people becoming admins will come to zero... and the activity of admins will drop because they will be aware an action is permanent. In short, flow needs to be wiki.

I really wish I hadn't put the "report abuse" link in there; it was meant to be illustrative of the beginnings of "how can we handle vandal comments" and the like but I didn't get a chance got flesh it out. Unfortunately, it's become a topic of conversation and I'm not super happy about that.

Ideally, clicking on that link (and the terminology there is obviously open for discussion) will start a workflow that helps a user define if a comment is abusive, vandalism, off topic, whatever.

I have intentionally not spent a great deal of time on anti-vandalism workflows because I wanted to get more information about how people would like to see that work; this is my fault for showing something half-baked.

5. Is the flow going to work for all linguistic versions ? (for example, through a dropdown list of all projects for example ?)

I'm unsure what you're asking here. Flow will be localized and will use the local wiki's language settings (or local user preference, which ever is applicable).

6. Status of editors proeminently displayed in their post (admins, number of edits, staff etc.) -> very bad idea (already commented above by other editors. I agree with them. Please do not do that.

I know. :) That line was just meant to be illustrative of the kinds of things we can surface that we can't easily do with current talk pages. The idea comes from navigation popups.

7. I would suggest it would be a good idea to better differenciate (or be able to select, unselect) the different spaces for the feed (main space, users, talk pages etc.)

Right now, we're only focusing on user talk. When we move to additional talkspaces, there will be visual cues to let you know where a discussion is taking place. Jorm (WMF) (talk) 19:03, 29 May 2013 (UTC)Reply

Before starting development, at least start a widely publicized discussion about this and whether or not the community wants to implement it before forcing it onto everybody. This just isn't Wikimedia/Wikipedia. Also "mark abusive"? What? Are comments just going to be randomly censored because someone doesn't like them? Is there going to be a never ending backlog of these that needs to be reviewed? What about editing other's comments for technical corrections or copyrighted content? Please, please don't implement this. I don't even like the interface I'm editing right now here. Please also see the "Too much stuff" section below me and the "Interface wastes too much space, doesn't fit into Wikipedia" section. Ramaksoud2000 (talk) 23:25, 28 May 2013 (UTC)Reply

There is a widely-publicized discussion that is happening right now - and you're part of it, especially by coming here.

Flow portals have been created on three distinct wikis (mediawiki.org, enwiki, and meta). Announcements have been made in various forums and Village Pumps, as well as a blog post, and then emails sent to Wikimedia-l and Wikitech-l, as well as to the Wikitech Ambassadors.

It really isn't possible for us to try to publicize it more without resorting to central notice (which we may end up doing, just not yet). Jorm (WMF) (talk) 19:17, 29 May 2013 (UTC)Reply

Jorm is right, there are various announcements spread across many Wikimedia projects.

However, I'm feeling there is still not enough input by far. I assume this talk page es well as the one located directly at Talk:Flow Portal are supposed to be the places were most of the discussion should be happening right now?

However there's only input by few people so far and even that seems to be not properly accounted for. There's mainly criticism right now, but it appears to me the developers of Flow (or mainly you, Jorm, since there don't seem to be many developers actively contributing to the discussions right now) are mainly trying to explain themselves instead of responding to the constructive feedback and trying to implement some of the proposed changes. Patrick87 (talk) 19:53, 29 May 2013 (UTC)Reply

Well. There are no developers (yet); we're in the design phase. I am the one on point for the project at this time; there will be more people getting involved as things ramp up further. That said, "implement proposed changes" doesn't make a lot of sense in this context; there's nothing to implement. I could update the interactive prototype (and am), but it's just that: a prototype, with no backing. Focusing on visual design criticism doesn't have a lot of value at this point in the game and that's really the only thing I could "implement". Jorm (WMF) (talk) 20:27, 29 May 2013 (UTC)Reply

OK, I wasn't aware of that. I thought there was a small team at WMF working on Flow, I didn't know it was that small.

But you have to respond to feedback (and if you provide an interactive prototype, visuals are the thing people notice first, espiacially if most other things are not working yet). Defending the decisions you made so far is not helping the project at all. It only gives the impression you're not really caring for the needs of the community but trying to overrun it with an all-new discussion system that the WMF thinks is best for the community. Patrick87 (talk) 20:48, 29 May 2013 (UTC)Reply

I'm confused. Brandon has spent a large number of hours sat on this talkpage, largely without staff support, having a conversation with you about what the plans are. Do you think he'd be doing that if he felt that he didn't owe editors a conversation about this in which they could participate? The very fact that we're having this discussion somewhat undermines the argument here.

I agree there needs to be more input, and we'll be throwing it out a lot more widely and in a lot more detail once we're in the next phase. But at the moment we're just throwing ideas around; the fact that your suggestions haven't been implemented in the prototype doesn't mean we're not listening, it means we're having a discussion. Yes, we're going to have energy spent on explaining our thinking behind features, and defending those features, because that's what "discussion" means; both sides setting out their case. Us implementing whatever people wanted instantly without thought would not be a discussion, it'd be software design by committee - and I'd note that when we're criticising LiquidThreads, one of the big things that brought it down was design by committee. Okeyes (WMF) (talk) 17:58, 31 May 2013 (UTC)Reply

Well, I'm a little confused, too, that's what I wanted to make clear in my posts.

You're requesting feedback, but instead of discussing how this feedback could be implemented best in the final Flow, most of the replies by Jorm are reasons why the requested features won't get implemented. He spends time to defend his decisions instead of reconsidering his decisions based on the given feedback. This is just pointless in my opinion.

I didn't follow the discussion around LiquidThreads and I'm not completely sure what you mean by "design by committee" but in my opinion the new Flow should include the features the community wishes for, redacted and planned by the WMF but based on the ideas of the community. Instead I have the feeling WMF (or Jorm) are planning on their own and present the community with a fait accompli. Patrick87 (talk) 19:36, 31 May 2013 (UTC)Reply

I'm sorry that you think I'm ignoring the comments and defending the decisions made. You are correct in your (unspoken, but I believe it to be true) assumption that there have been decisions made. However, I am not trying to "defend" them; I am trying to explain them.

All design - especially product design, which is what we're talking about here - operates under a series of constraints. Walls that we must account for. Many of those constraints revolve around performance and scalability as well as future proofing.

For example, one of the reasons why LiquidThreads (this discussion system) is so slow is that every comment is stored and managed as its own Wikitext Page. In order to display a LiquidThreads discussion, the following happens:

1. All threads to be displayed are located.
   1. For each thread, find the current revision and retrieve it
   2. For each thread, find the posts that belong there
      1. For each post, retrieve the current revision
         1. Run each post through the wikitext parser to produce HTML
      2. Assemble each post in correct order for each thread
2. Display

It's ridiculously slow and is absolutely not scalable in any way, shape, or form.

The slowest part is the actual processing of each post through the parser - turning the wikitext into HTML. We can achieve a speed increase along several orders of magnitude - *thousands of percent faster - by skipping this step. That means storing each post as pre-parsed HTML (e.g., we parse it on the way in and not the way out, which is how the Parsoid project works (kind of - it's complicated)).

Parsoid does not do well with templates. Ergo, we are designing with the assumption that we can't use templates.

Future proofing requires that we use the VisualEditor now so that people don't splatter in a stuff that the VisualEditor can't process. We have to ensure that we're "VE-proof" from the beginning.

And so forth. Jorm (WMF) (talk) 19:49, 31 May 2013 (UTC)Reply

Thank you for this post since it really gave me some insight on your motivations.

However it made it clearer than ever that decisions were made on your side and you won't reconsider them anymore, knowing they may not resemble the communities wishes. That's sad, and it will inevitably lead to differences between WMF and community and to rejection of the whole Flow system.

I don't know your reasons to hazard these consequences, but I hope those are good reasons... Patrick87 (talk) 20:24, 31 May 2013 (UTC)Reply

Personally, I have a very simple and driving reason: the continued survival and viability of the movement's projects in service of the greater mission. Relying on a dwindling technical priesthood is clearly not the solution; we must move out of the year 1999 and into the year 2015. Jorm (WMF) (talk) 20:29, 31 May 2013 (UTC)Reply

Let's hope you'll not want to get back to the future when it's due... Patrick87 (talk) 20:39, 31 May 2013 (UTC)Reply

If something contains copyrighted content it seems like precisely the kind of thing that should be marked as abusive - and as for copyediting, why is that a requisite feature? Let's be clear, here, that we're in an early design stage. Statements like "there will be a mark-as-abusive feature" are just that; statements, not explanations of the underlying workflow. If you've got an idea of how the workflow for removing problematic posts would work in an ideal world, say it and we'll see what we can do about it :). See Brandon's comment below: Ideally, clicking on that link (and the terminology there is obviously open for discussion) will start a workflow that helps a user define if a comment is abusive, vandalism, off topic, whatever. I have intentionally not spent a great deal of time on anti-vandalism workflows because I wanted to get more information about how people would like to see that work; this is my fault for showing something half-baked." Okeyes (WMF) (talk) 18:01, 31 May 2013 (UTC)Reply

The current notice on the English Wikipedia Community Portal says:

If the current system of talk pages seems confusing, a replacement is on the way! Flow, a much more intuitive way of communication resembling those on other websites, will be enabled soon, hopefully in June.

Yet according to a post here just last week, "there are no developers (yet); we're in the design phase.... there's nothing to implement".

I think it's a tad over-optimistic for something like this to go from design phase to implementation this month; please can we have some clarity on what the plan actually is? (And perhaps update that Community Portal notice accordingly).

If Flow isn't coming soon we need to try to get people using things like {{replyto}} instead so that we can make full use of Notifications. Waggers (talk) 11:25, 6 June 2013 (UTC)Reply

It's safe to say it's not coming in June. Killiondude (talk) 23:01, 6 June 2013 (UTC)Reply

Jorm responds to many comments, although I had no clue Jorm was to this page. Maybe some sort of "To:" function could be included. Also, second level responses by others seem gangish rather than informative. Which brings up the subject of who patrols the vandalism patrolls. I personally am tired of vandals using warnings to vandalize user talk pages. I've found one way to avoid them is to finish the article off Wikipedia. Then, contribute it and forget it. The way Nupedia was probably written by those asked to write them. 67.101.80.187 05:04, 5 July 2013 (UTC)Reply

Have you encountered the new en:WP:Notifications features? One of those, is the new "Mentions" feature, whereby if you link to a username, and sign the post with 4-tildes in the same save, it will send a Notification to the user saying "You have been mentioned by x at y."

You do have to be logged in to receive Notifications though.

AFAIK, Notifications is only in a few wikis at the moment (such as here and en.wiki), but will be rolled out to meta in the next few months, and other languages in the latter half of the year.

Cross-wiki Notifications, are also on the roadmap.

This, and other "To:" type functionality, is already being strongly thought about for Flow and Notifications. Good times are ahead! Quiddity (talk) 05:15, 5 July 2013 (UTC)Reply

I appreciate the time and effort that is being put into this project, and several of the changes from the traditional talk page format may be helpful. However, there are several major elements of Flow (as it stands now) that make me very opposed to its future use, in particular on the English Wikipedia. (I'm going to refer to the current interface used for talkpages as "Talk Prime" to same time/space.)

First and foremost, the interface is clunky. Discussions take up a lot more space than they would if rendered as wikitext in Talk Prime. From a design standpoint, the Flow interface appears drastically different from Wikipedia's default skin. When compared to the rest of Wikipedia, Flow honestly looks like it comes from a different website altogether. It even looks like it comes from a different kind of website—more like a chat forum or social network.

This brings me to my next point, which is about Flow's timestamp format. In Talk Prime, timestamps render as the UTC time and date at the moment of posting. Flow renders timestamps as "about [x] [unit of time] ago", and the exact date and time is accessible upon hovering over the text. While this may be useful for people unfamiliar with UTC, it is a huge departure from Wikipedia's current practices. It also makes it harder for those of us reading on mobile phones to get the exact date/time of posting. I imagine it would also pose an accessibility issue for visually impaired people reading Wikipedia with a text-to-voice screen reader.

I also dislike that the edit count of a user is displayed. I will expand on this and other points later, but for now I have to go as my lunch break is up. Cheers, Cymru.lass (talk) 19:35, 5 July 2013 (UTC)Reply

Keep in mind that it is just a concept-mockup, and not a design proposal.

E.g. The timestamps for a post are stored in a database, and could be styled/displayed according to user preferences, just like our current Special:Preferences system allows.

So, think more about the abstract ideas and big-picture - don't pay too much attention to the prototypes's visual-design and layout. See also Talk:Structured Discussions/2013a#c-Quiddity-2013-06-23T22:05:00.000Z-This,_that_and_the_other-2013-05-21T08:14:00.000Z Quiddity (talk) 21:16, 5 July 2013 (UTC)Reply

I noticed that on the boards, it could get long at times, especially at Fully Chaos. Could we make it smaller? I like it, and know it's just a demo, but the space thing needs more work. Also, I loved the fact that I was an admin, and the link to List of animals with fictional diplomas! Buffbills7701 (talk) 22:19, 5 July 2013 (UTC)Reply

The load times are an artifact of this being a prototype. It has to render everything from JSON source files. It should be significantly faster in the real world. Jorm (WMF) (talk) 21:58, 13 July 2013 (UTC)Reply

Hi Jorm,

you just updated the interactive prototype and I noticed that there are many changes regarding visuals (padding, user infos like post count and the like).

Does this mean that we're approaching a state were we can comment on visuals? Or should we still focus on functionality rather than UI? Patrick87 (talk) 21:53, 13 July 2013 (UTC)Reply

Feel free to comment all you like. You should know that these visuals (the buttons, etc.) are very close to the final Agora designs that we will be rolling out. So you'll be commenting on Agora more than Flow, but as far as you're concerned, they're the same. Jorm (WMF) (talk) 21:58, 13 July 2013 (UTC)Reply

If you're taking feedback on the visuals, I have my share of comments. (Warning, wall of text below).

- The borders around each comment are too big and heavy. They provide too low density of text - requiring a lot of scrolling. Also while colorful, they're distracting - I want my eye to flow towards the text, not the interaction chrome. Make them low-contrast and to the left of text, like every other discussion system does for good reason.

- I find the overall navigation metaphor confusing. If I click on a notification, it shows a conversation without context, and no clear indication of where I'm located. I've barely noticed after the fact that there's a breadcrumb at the top with the label "Back to board" - it should be more clear to what place it returns (i.e. "Back to <username> board").

- I'm not sure in what order one is expected to consume the conten. The old talk pages (as well as every blog in existence since the 90's) have a table of contents that show conversations on the order of creation. With the automatic reordering, all spatial is lost. If you skip one single thread, it's impossible to tell whether you've already read it or not. The "mark as read" is a workaround - it forces the user to manage a manual upkeep of the read status, which should be automatic.

There should be a static index where all threads are located by creation so thread titles can be scanned and located quickly. Again, copy the well-proven interface of blogs and you won't err.

If you want a flowing interface to keep track of updates, that's fine, but that shouldn't be the primary navigation metaphor; conversations are different than items in the review backlog, which need to be reviewed just once. When you want to get back once and again to the same content, there must be a static structure to relate all of it; I find the blog metaphor the best one for Wikipedia, where discussions can be kept alive for months and referred to for years after they've finished. Please don't reinvent the wheel, forum threading is an already solved problem - just copy the state of the art and provide refinements on it, not whole new paradigms.

- As for the "Mark as read" button, it's unclear what will be marked when pressed: the whole thread? the whole *board*? Only the current comment? All comments above? Here you can copy the design at GMail's thread - the "mark unread from here" button available at each comment, exits the thread, and only previous comments are marked as read - everything below the button is kept unread. That's a exquisite solution, even if non-standard, and works reasonably well.

I hope these comments will help refine the interface. I have a severe case of lost-in-hyperspace case with that flow metaphor. Diego Moya (talk) 13:12, 15 July 2013 (UTC)Reply

Since VisualEditor is active on English Wikipedia now I had experimented with it here and there. And what should I say – I hate it! Whatever I do quickly with a few characters in Wikitext (e.g. Wikilinks, text formatting, embedding graphics, templates, etc.) needs at least the same amount of clicks through various windows in VE and takes ages therefore. In my opinion this is just unacceptable for experienced users – and I'm not the only one as the [:en:Wikipedia:Village pump (technical)#"Opt out" of VE needed under preferences overwhelming consensus] regarding the necessity for an opt-out of VE shows.

I don't want to get into the discussion whether VE is a good or a bad thing here. Personally I even think it's great for newbies or people with a reluctance towards markup in general. But there needs to be a choice!
I therefore strongly suggest that – however the final FLOW will look like – a tiny checkbox is installed somewhere in preferences where one can select whether to edit comments in a simple markup editor or VisualEditor (and maybe even a small button in both editors to switch to the counterpart directly from the UI).

Don't get me wrong, I don't want to be able to use all functionality of Wikitext (Jorm already pointed out that this won't be possible due to how comments will be saved in the backend). But all formatting that will be available to the FLOW-VE editor (which will only be a subset of the normal functionality, too) should be available in a FLOW-Wikitext editor. Patrick87 (talk) 22:14, 13 July 2013 (UTC)Reply

You should strive to achieve Zen acceptance that the only editor for Flow will be the VisualEditor. If, by the time Flow is released, the VisualEditor supports a native code editor, it will likely be there. But nothing is promised - nor can it be. Jorm (WMF) (talk) 22:24, 13 July 2013 (UTC)Reply

Well, maybe you should strive to get the native code editor ready by then.

Otherwise you'll have a really hard time to achieve Zen acceptance that Flow will be rejected.

I'm sure you followed the discussions around the VE start on English Wikipedia – they were more than heated and I'm glad nobody came to death (merely joking). All this was only because the VE editor was deployed in parallel to the WikiEditor. Now, can you imagine what would have happened if the WikiEditor was removed in favor of VE? I honestly can't (and I don't want). But exactly this is what you are proposing!

I don't mind if the markup editor is part of VE or not. But I'm sure if there is no markup editor available the day Flow should be deployed will be the day it is either abandoned or the day on which many editors will be searching other projects to spend their time on. Patrick87 (talk) 22:54, 13 July 2013 (UTC)Reply

You'll have to talk to the VisualEditor team about their functionality, I'm afraid. Jorm (WMF) (talk) 05:11, 14 July 2013 (UTC)Reply

Oh, come on Brandon. We're all sitting in the same boat (while we can leave it when it sinks, you can't).

Now you ask me (who I am not involved with the WMF or development at all) to talk to your colleagues how they should design VisualEditor to work with your discussion system?

I'm not bugging you with this for the sake of bugging. I do it because I know it will cause serious clashes (to the point of people boycotting Flow or even leaving, both of which can't be your goal), when it is not fixed. I propose you achieve Zen acceptance that a markup editor is needed and start to negotiate with the VE team how fast they can implement a markup editor.

I do not understand why you're giving yourself so stubborn regarding this issue. It helps neither you nor Flow nor the community to deny the obvious. Patrick87 (talk) 13:50, 14 July 2013 (UTC)Reply

I'm saying that I can't promise anything about what the VisualEditor will and will not support. I am not working on that project and cannot speak for their roadmap, nor do I have any level of influence over it. Jorm (WMF) (talk) 22:08, 14 July 2013 (UTC)Reply

I understand that you can't give definitive statements on VE development.

But you could promise that you will make sure to negotiate with the VE team so a markup editor will be ready when Flow is deployed (you guys are talking to each other at WMF after all I suppose?). Or you could promise Flow won't be deployed before the markup component of VE is ready.

Those are two distinct projects, but that does not mean that Flow has to blindly use VE in whichever state it might be (at least I hope so). Patrick87 (talk) 22:52, 14 July 2013 (UTC)Reply

I'm not at liberty to promise either of those things, and I wouldn't promise them even if I could. Jorm (WMF) (talk) 22:54, 14 July 2013 (UTC)Reply

I hope there is someone that is coordinating or at least keep the concatct between the two project so that they can work together. Moroboshi (talk) 08:12, 15 July 2013 (UTC)Reply

Why should anyone achieve "Zen acceptance" of the Visual Editor? Why should anyone be required to use it in order to use this as a replacement for talk pages? When I disable the Visual Editor, that's exactly what I expect to happen. I don't expect it to suddenly pop up again under a different name. Kww (talk) 21:25, 14 July 2013 (UTC)Reply

I agree. I want to disable it entirely and I certainly dont want to be forced to used it on talkpages.Maunus (talk) Maunus (talk) 23:16, 14 July 2013 (UTC)Reply

While I'm not entirely sure I'd want to disable it entirely myself (we'll see how I like it when it is done), I do want the option to be there. No one should have to be forced to use it. I agree with the sentiment that if you disable VE it shouldn't pop up again on another type of page. Zellfaze (talk) 12:51, 15 July 2013 (UTC)Reply

When I'm reading and editing Wikipedia on my phone, I am usually using Opera Mini as that browser uses up a lot less power and bandwidth. The browser is marked with a big red at VisualEditor/Target browser matrix. How will I be able to respond to a comment posted on my talk page, if there is no way to use the visual editor using Opera Mini? Also, 8% of the users use MSIE 8.0, which isn't supported either. How will they be able to respond to comments posted on their talk pages? I'm seeing no choice but to post a big notice on my talk page and in the corresponding edit notice saying that posts to my talk page won't be read or answered and that you have to post a message in wikitext at Special:MyPage/talk instead. Stefan2 (talk) 18:09, 15 July 2013 (UTC)Reply

As has been stated many times, there will be a "fall back" editor mode for those users who cannot use the VisualEditor. This fallback editor will not be as fully functional as the Flow's version of the VisualEditor.

For example, the Flow version of the editor will allow you to "ping" or "mention" users by typing an "@" sign and then you'll be given an auto-complete of the username to fill out. We can't do that with a fallback editor. It's functionality that will not exist (same with other auto-completion tasks). There are other differences as well: in order to ensure "future compatibility" the fallback editor will likely support only a subset of the full wikitext language.

I'm sorry you feel that you will have to create a complicated, unfriendly work-around. I would urge you to at least think positively and try the tool out first before assuming that the universe is ending. Jorm (WMF) (talk) 00:27, 17 July 2013 (UTC)Reply

NO! I really HATE the VE. Wolf Lambert (talk) 09:16, 22 July 2013 (UTC)Reply

So, the WMF is going to screw over the visually impaired? Going to break every bot that edits talk pages? Remove the ability to copy material from the article to the talk page? [Or are you going to force VisualEditor on article pages too?

Is everyone in the WMF on drugs? Adam Cuerden (talk) 23:27, 14 July 2013 (UTC)Reply

For that matter, how will templates work on talk pages if Wikitext isn't even supported? Are you expecting your users to recode nearly a decade's worth of supplemental material in order to let you have your Flow? Because, if you do, expect the flow to stop pretty quickly. Adam Cuerden (talk) 23:32, 14 July 2013 (UTC)Reply

Templates will likely be supported in two ways:

• As being subst'ed in (like from a bot post, for instance)
• As to the degree that the VisualEditor currently supports them.

What we are trying to avoid is the situation where broken/horrific wikitext is inserted into posts that make them unusable and unreadable in the future (like the current way hatnotes are implemented, with a collapse top and a collapse bottom template). Jorm (WMF) (talk) 00:01, 15 July 2013 (UTC)Reply

What's horrific about the hatnotes? Cyclopia (talk) 20:17, 15 July 2013 (UTC)Reply

Hatnote templates are actually broken, incorrect wikitext. They create code sections that are extremely difficult to parse because neither the top nor the bottom template is "syntactically complete" - each is but one half of a wikitext idiom (or program, if you like).

Flow has built-in functionality that replaces hatnotes. Jorm (WMF) (talk) 00:29, 17 July 2013 (UTC)Reply

That's the same as saying that '[[' is "actually broken, incorrect wikitext". It's only extremely difficult to parse because of the assumptions you made when you started to build your parser; hatnotes are absolutely not responsible for VE's ongoing and continuing brokenness. Stuartyeates (talk) 02:35, 17 July 2013 (UTC)Reply

No one has said anything about screwing over the visually impaired - and, in fact, there's an earlier thread about just that (visual impairment and dictation software and disabled javascript). Obviously there will be a fallback version. It will not be as feature complete - by necessity - and it will likely be clunky, slower, and less usable (as is the way of things like this).

I'm not sure where you get the "cannot copy content" from. I don't believe anyone has said anything like that.

I would like to request that we have less hyperbole. It makes the conversation needlessly hostile. Jorm (WMF) (talk) 23:58, 14 July 2013 (UTC)Reply

Jorm - VE does not support copying of formatted information from one page to another. Copying a footnote (let's say, footnote 3) simply pastes a "[3]" to the new page.

It's quite common, in talk page discussions, to copy/paste wikitext that is, or includes footnotes, from articles - for example, to show what was removed by an edit. It's common - perhaps even more common - to post potential footnote to a talk page, and - if acceptable - to have them copied to the article by another editor. That's what we ask those with conflict of interest issues to do, for example. John Broughton (talk) 01:50, 15 July 2013 (UTC)Reply

Yeah, and I think that's one of the things they're working on fixing. Seriously, though: I'm not on the VisualEditor team, and I can't speak for their roadmap. Jorm (WMF) (talk) 01:52, 15 July 2013 (UTC)Reply

I'm not entirely sure anyone can speak for their roadmap at this point. The Engineering Roadmap and the Mediawiki Roadmap's sections on Visual Editor are maybe not so verbose.

EDIT: Though I may be being a little bit hard on the engineering road map. It does have some information, but it really isn't as detailed as I would like. Zellfaze (talk) 12:50, 15 July 2013 (UTC)Reply

Though if Flow is going to rely exclusively on the VisualEditor, your feature set is their feature set, isn't it? How can you create a design for your interface if you don't know and can't control the one module that is core to the possibilities of your tool's workflow? Diego Moya (talk) 13:27, 15 July 2013 (UTC)Reply

How we design in this case is to assume "worst case" and apply that as a design constraint. We have some assumptions about which constraints will be lifted or non-existent in the future, but crystal balls are hazy, murky things, and it is better to speak to what we know rather than what we assume. Jorm (WMF) (talk) 00:30, 17 July 2013 (UTC)Reply

So, regarding Adam's question: does that mean that you're designing Flow around the possibility that content can not be copied from articles into discussions? (the worst case, and the current situation).

So, how is the proposed design going to overcome this constraint in order to allow current tasks that depend on that function? (such as drafting, and discussing specific article paragraphs, sentences or images). Diego Moya (talk) 10:59, 17 July 2013 (UTC)Reply

Some of the previous comments have mentioned that the majority of the comments have been critical of Flow. I, however, like it a lot. Perhaps it's because I tried to follow along with the development of Flow and with Jorm's thoughts on this and other subjects, but there are also other reasons:

• I much prefer that you won't have to click "edit" to start editing but simply place the cursor in the right place and start typing
• after clicking "save", Flow seems to work the way most normal systems do, with not reloading the page and you having to scroll down to the right place, but rather stay on the right comment
• I think the thing about not having to sign your comments is long overdue and will significantly improve life on the wikis I am active on. On Swedish Wikipedia our Report an error page, and newcomers' talk pages are full with comments about their forgetting to sign
• it seems to be very much easier to teach to new editors; something that I do a lot
• automatic indentation is one of the good things about Liquid Threads, and it is good to see it included here. So many people get it wrong in the present wikitext system
• the "unsubscribe from topic" and other topic choices make Flow look like something that I want to work with. There are so many topics that start out promising but then go on forever, and these type of choices make that easier to deal with, rather than having to unwatch the whole talk page/Wikipedia page
• the left hand arrow that allows you to minimize or maximize a topic is better than what we have now, where you can scroll through the same things over and over (I trust that the choice for the topic will be remembered?)
• the "working" image (the W logo being drawn) is beautiful
• I like being able to mark pages as read. Not enough systems have that option
• the box with the profile page, archived talk, etc is very good to have on top, instead of to the left. It make those tools easier to find

To couter some of the criticism about Flow taking too much space for each comment, I don't really think that is going to be an issue. I've seen Jorm working and I am confident that this is something he will work on, and get others to help. Perhaps a system with the user name to the left and the comment to the right.

I would ask for a way to "favorite" a topic, to keep it near the top of the page.

All in all, an improvement that I look forward to seeing deployed. Thanks for your work. Hannibal (talk) 22:56, 13 July 2013 (UTC)Reply

That's great feedback (clearly explained, well-separated, and positive!), and an interesting suggestion. Thanks! More suggestions would be welcome. Quiddity (talk) 20:18, 14 July 2013 (UTC)Reply

Thank you so much for this feedback. As Quiddity says, it is very good and well-explained.

Regarding your suggestion about each topic remembering its closed or open state, I would love to do that, but there may be technical limitations that prevent it. It's a lot of data to process and store. I know how we would do it (it would be another field in your "subscription" to the topic) but there may be issues with remembering state on topics you aren't subscribed to (which would create a weird and inconsistent user experience). However, I'll look into it and talk to our software guys about it. Jorm (WMF) (talk) 00:49, 15 July 2013 (UTC)Reply

This is largely just a "me too" on Hannibal's comments. All of this is going to come with some points of friction--to pick an example, I've poked folks on every side of this discussion about the impedence-mismatch that's going to come from AfC drafts currently living on talk pages--but I think the cost of the change will be amply repaid by how much nicer an environment this will be for discussion. Joe Decker (talk) 17:41, 16 July 2013 (UTC)Reply

AfC just needs to be moved to another namespace to keep it away from Flow; it's not, and not intended to be, suitable for the concept of Flow.

That being said, the prototype would be suitable for an additional place for Wikipedia discussions. In my opinion, and that of all en.Wikipedia editors who have expressed an opinion at w:WT:Flow, as that it, as presently conceived, is not suitable for a complete replacement of user talk pages, and cannot be made into a replacement for article talk pages without undoing much of what is presently proposed. Arthur Rubin ^en.Wiki (talk^en.Wiki) 20:29, 19 July 2013 (UTC)Reply

It's nice to counter some of the negative feedback, but we should also try really hard to think of suggestions for improvement. I agree that the prototype has many significant improvements and I'm glad that you highlighted the space issue as an area to improve. Hopefully Jorm does take that seriously as you suggest. It feels somehow very crowded partly due to the margins and large font. A minimalist version for those who have sharp eyesight and want to take in a lot of information quickly would be nice. I also agree with many of the other comments on this page (e.g., source editing for convenient wikilinking and stuff).

The floating "start new discussion" box is distracting and takes up a ton of space, making it a negative. There's tons of empty space to the right where you could float some sort of menu with various options, including even a table of contents which could be helpful. If I want to start a new discussion I'll have figured that out when I land on the page. Notably, the prototype squeezes the text into a fixed-width div of 798 pixels (at least on my laptop) whereas the status quo is a fluid div which generally ends up being significantly wider in general for me. I believe some research suggests that short widths are easier to read, but it comes at the expense of more scrolling. The empty space on the right could also be used, although I really like the idea of being able to minimize things if you're in the minimalist mood, which I often am.

I have a little trouble understanding how this is all going to fit together based on this prototype. Is there going to be any actual test server, where we can play and it will save? It seems that there's generally been a reluctance to let editors test in a test environment, which I don't understand.

On the higher-level, the tagging will be nice although details are scarce (Talk:Flow_Portal#Thread_tags_27816 and Flow_Portal/Architecture#Tags) - it's not clear that the tags discussed in Flow_Portal/Use_cases#Talk_namespace are the same. There should also be more readily-available ways to list pages which are having a lot of discussion and I imagine the feed will allow you to select which tags to follow, which could reduce siloing and could help editors meet other people in the more informal space of talkpages. Often a user talkpage discussion will actually be related to a discussion on an article talkpage or an ANI talk, and tagging or linking these could help show the totality of the discussion. ImperfectlyInformed (talk) 22:58, 21 July 2013 (UTC)Reply

I just checked the interactive prototype and saw that most "threads" only contained few posts. I then thought about how some threads at [:en:WP:VP en:WP:VP] would look in Flow – and I shuddered. The already page-long discussions would virtually get endless. Even when Flow leaves out some messages I think this could be a serious problem.

Also from a usability point-of-view I think there is plenty room for improvement: Currently a comment with two lines of text (those two lines are the real content of a comment, everything else is more or less background information, and should be treated like that) take up roughly 8 lines of space. This is four times the space necessary.

Sure, the prototype looks, nice, but I'm afraid it wouldn't be fit for real world usage. As an example I took two screenshots: The current style of the interactive prototype, and a version I quickly reduced in size:

It's only half the height while showing exactly the same information! And it could even be optimized further (e.g. the header currently takes two lines, too). Patrick87 (talk) 23:22, 13 July 2013 (UTC)Reply

Right. Jorm (WMF) (talk) 05:10, 14 July 2013 (UTC)Reply

I would also favor an action Reply over an edit box after each comment, like Patrick87 says it makes the UI more compact, but also less cluttered with standard texts. Erik Zachte (talk) 14:03, 14 July 2013 (UTC)Reply

In Vector, actions in "Toolbox" (What links here, Upload file) and in the dropdown menu near the search box (mostly Move), are unknown to quite a lot of editors. I don't have precise data, but new users ask me where to find these actions quite frequently, so I'm assuming that they hard to find at least to some people.

I am writing this, because the same would be true for the actions in the little "Actions" menu in the corner. It would make more sense if the actions would appear as simple links written in a human language rather than hidden in the menu. Maybe some actions that are expected to be rare can be put there, but not all. Amir E. Aharoni (talk) 09:03, 14 July 2013 (UTC)Reply

Today, every editor has the ability to remove vandalism, violations of privacy, libel, purely attack postings, wikichat, and so on from talk pages. Flow doesn't allow that!?!

What I'm seeing is statements like "Administrators must be able to delete individual comments or entire topics"; "certain groups (presumably local admins) would have the ability to edit other people's comments, but most users would not have that ability". Do you have any idea how many thousands of posts are deleted (directly or via revert) every day from talk pages? Are you really seriously thinking that whenever an editor sees something wrong, he/she should summon an admin?

The larger issue is that wikitext, and diffs, establish accountability. Yes, any editor can delete another editor's comments, but do that more than once - after a warning, probably posted via template, on the editor's user talk page - and that editor is likely to get blocked. Yes, any editor can edit anyone else's comments - but it better be constructive and defensible, or

And that's the problem with Flow as it seems to be conceived - exactly the problem that has resulted in moderation on discussion boards, and for comments to blog posts, and to a lot of blog posts not even allowing comments - it takes a lot of work to prevent abuse. Wikis solve that problem by enabling any editor to be a moderator (remove abuse). And the ability to see exactly what an editor did (diffs) establish accountability - yes, editors have all this power, but they also can be held to task.

So, if we're talking grand design here, the software absolutely needs to meet three major requirements:

• (1) A majority of the experienced editors (for example, those with rollback privileges) must be enabled to fix problematical posts; the system will fail catastrophically (spam, vandalism, abuse attacks, etc, on user talk pages) if only admins can act on problematical posts.

• (2) It must be possible for editors to edit the posts of others, not just hide or delete them. For example, in an article talk page, some issues are potentially libelous; it's critical to remove the libelous part without just deleting the posting if a good discussion is to continue (and, obviously, to prevent editors from feeling that their posts are being censored).

• (3) There has to be accountability when someone edits someone else's posting (or deletes it, of course). That is, there has to be an "audit trail" - which is what diffs are - so editors can be accountable. There also has be to be some way to scan the editing that other editors have done (that's one use of diffs, in history pages); otherwise "accountability" is a pointless word.

If Flow can't do (2) and (3), that's a deal-breaker, as far as I'm concerned. The English Wikipedia isn't a pristine world where 99.9 percent of posts are non-abusive. Rather, it's a very messy place, with lots of vandals and spammers and trolls and newly-registered editors who don't understand community norms and IP editors who often have zero understanding of - and zero commitment to - Wikipedia's rules. In such semi-chaos, (almost) every experienced editor needs to be a moderator of sorts, and moderation has to be more than just deleting problematical postings. John Broughton (talk) 02:48, 15 July 2013 (UTC)Reply

I have to concur and note that this was one of the pet peeves I've seen with LiquidThreads. Although most people can edit most posts, only admins can outright delete them. Jasper Deng (talk) 02:50, 15 July 2013 (UTC)Reply

See w:Wikipedia_talk:Flow#Arbitrary_Section_Break_1, particularly Jorm's and Whatamidoing's comments. Editing other people's comments is just a user-right, which will (presumably) be up to us to decide how it is given out (and/or changed later on). If it can be restricted to "group-admin", it can be restricted (or unrestricted) in any way. Quiddity (talk) 04:37, 15 July 2013 (UTC)Reply

There's a lot here; I'll see if I can capture all of it.

Currently, the prototype defines the following:

• Editing your own comments is something you have the right to do.
• Editing the comments of others is something that requires privilege (in the prototype, that's the "admin" toggle)
• Deleting a comment is something anyone can do.
• Restoring a comment is something anyone can do.
• Deleting a topic (and all comments in it) is something anyone can do.
• Restoring a topic (and all comments in it) is something anyone can do.
• Closing a topic (hatnoting it) is something anyone can do.
• Re-opening a topic is something anyone can do.
• Suppressing a topic is something only those with privilege can do.
• Editing a topic title is something anyone can do.

All of those use cases above are doable in the prototype. There is another use case - suppressing a comment - that has not been implemented in the prototype but will be in the next revision.

When comments are edited - by anyone - a marker is placed in the comment indicating that it was altered and by whom.

When a comment or topic is deleted - by anyone - a marker is placed indicating that an item was deleted and by whom. Leaving the marker is important for thread continuity and to note that replies to the comment have been left to something no longer there.

The only functional difference between the current model and the Flow model is that the ability to edit someone else's comments is restricted. That's it. Jorm (WMF) (talk) 00:23, 17 July 2013 (UTC)Reply

It looks very VERY old.

My suggestion: 1. Getting rid off that awful grey background as soon as possible, and picking another color (maybe light blue), with a glittering fade out effect - similar to the one Microsoft Windows 8 tiles use. 2. Changing the confusing arrows design to the standard + and - convention, in order to collapse and expand replies and threads. 3. Space a bit (just a bit) between the different replies, so that they appear in an entire different boxes. This looks nicer and easier to read. 4. Change the titles' view of each thread - current design looks almost exactly like current Wikipedia's one, which, once again, looks anachronistic.

That's all for now, as for a 5 minutes impression.
Oz. 84.111.9.220 16:14, 15 July 2013 (UTC)Reply

Sorry, but what's wrong with Wikipedia's current style? It's functional maybe that is what you mistake for "anachronistic"?

I think Flow should look much more as if it actually was Wikipedia. Currently Flow looks like something completely different, forcefully plugged into MediaWiki, without the intention of making it blend in.

I'm fine with a skin that has all this "glitter" you're proposing (and that can be chosen if the user likes glitter more than functionality). But it should be used site-wide, as every skin should. Everything else will always look like unfinished work or patch-work. Patrick87 (talk) 16:38, 15 July 2013 (UTC)Reply

Seriously. It's clunky beyond belief in its appearance; it looks like it came from the 1980s, and not in a cool "retro" way either. It looks like a particularly low-rent forum. It takes up more room than a talk page, and is literally no improvement over a talk page that has actually been used correctly. Lukeno94 (talk) 07:48, 18 July 2013 (UTC)Reply

I'm testing the new prototype and I'm unable to make sense of how comments are reordered when several thread levels are involved. I don't know if this is a bug or the expected behavior, given that the post is animated and mover to different place after I press "Reply" instead of standing there where I wrote it.

Say we have this existing conversation:

• Post by user A
  • Post by user B
    • Post by user C

Now if I post a reply to the first post by user A, this is the result:

• Post by user A
  • • Post by user B
  • My reply to user A
    • • Post by user C

This makes it seem like user C was replying directly to me! Also all connection between user B and C is lost. The only hint that something weird happened (apart from the conversation not making any sense) is because "My reply to user A" has a more recent timestamp than "Post by user C".

What I expected to happen is this:

• Post by user A
  • Post by user B
    • Post by user C
  • My reply to user A

This is how conversations with different depth levels are handled nowadays. It's a common idiom at places like Slashdot and Reddit. I hope this behavior is a bug? If not, can someone please explain it to me? Diego Moya (talk) 13:54, 22 July 2013 (UTC)Reply

I think the behavior you're seeing is a bug and an artifact of the fact that the content is loaded from a JSON file and has no real structure. Jorm (WMF) (talk) 21:04, 23 July 2013 (UTC)Reply

The current page structure at the board looks upside-down to me. The floating toolbar with the option to start a new thread obscures the page navigation, and input actions are usually found at the bottom of dialogs.

I have this suggestions to improve the page layout:

• put the input form "Click here to start a discussion with UserX" at the bottom of the page. At the top of the page put a "back to top" link or a breadcrumb (see below).

• Include the form "Click here to start a discussion with UserX" when watching a filtered thread (the default status when following a notification).

• When watching a filtered thread, change the "Back to board" button to a breadcrumb that also shows the thread title, like this:

 " Back to Ryan_Vasey's board > Can page curation stop a copyvio spammer?"

This should increase the reader's awareness of where a conversation is taking place, and make it more explicit when starting a new thread where it will be located. Diego Moya (talk) 14:33, 22 July 2013 (UTC)Reply

If a user has multiple accounts (for example an extra account for insecure connections, or a bot account), the user talk page for the extra account is often redirected so that the posts end up at the talk page of the main account. Also, if a user account is renamed, the user and user talk pages for the previous user name tend to be redirected to the new user name. How will these features be implemented using Flow? I hope it won't be like Wikia's horrible message wall where I can't figure out how to add that kind of redirects. Stefan2 (talk) 12:39, 1 August 2013 (UTC)Reply

I think that user renames should end up working transparently, for the most part.

What you're talking about is the concept of "Merging Boards". I have a chat with Erik about its implementation; I can't imagine it being that difficult. Jorm (WMF) (talk) 23:40, 17 August 2013 (UTC)Reply

While I understand design is backseat to functionality at the moment, and that this is likely far from finished, I'd like to politely point out that, as it stands, the username block (with the "6 months ago" etc) is ridiculously prominent and dwarfs the (much more important) thread headers. I think having massive font sizes and bold colours for the usernames is pretty backwards, and I think the username should probably be at the bottom of the comment as opposed to the top. Just my opinion but hopefully you can see the concern :) Foxj (talk) 04:34, 10 August 2013 (UTC)Reply

I agree:

• The font size of the thread headlines is to small.
• The font size and colored boxes with the user names are a little bit to big.
• There are still to much border lines and boxes. Even if most of them are dimmed.
• The total width of the page in the current prototype is way to narrow. It's limited to only 700px width some "max-width" and even "width" CSS styles. This wastes huge amounts of space even on medium size monitors. This will make discussions with very deep nesting nearly impossible to read. I think I wrote this before but I can't find it any more. Don't tell me this fixed width is required because of small screens. It's not a problem to make the CSS "responsive". It scales down on small screens and scales up on large screens. TMg 20:31, 13 August 2013 (UTC)Reply

Hi! I want to show my views on comment format. First of all, the Thank button shouldn't appear and disappear when the cursor moves over each comment, it's annoying. The permalink icon is small so it's ok, but the Thank button is too big for that feature.

The date should be on the top right (as in Gmail), not at the bottom.

The extra details on the user and timestamp work fine, except that I would remove the seconds and the timezone, and shorten the timestamp to "Fri, 15 Nov 2013 14:04", so it's easier to read.

last but not least, where's the Reply button? I can't see it anywhere. NaBUru38 (talk) 23:05, 16 November 2013 (UTC)Reply

Hi NaBUru38, thanks for your feedback on the current layout and interface.

Re: the Reply button, it is positioned directly to the left of the Thanks button (see annotated screenshot), so there must be a bug preventing it from rendering correctly in your browser. Please could you tell me what browser and OS you are using, and if you have javascript turned off? That way I can file a bug, and try to reproduce it myself, too. Thanks. Quiddity (WMF) (talk) 03:07, 17 November 2013 (UTC)Reply

67.252.103.23 03:30, 22 November 2013 (UTC)Reply

Note: This thread was moved to w:Wikipedia_talk:Flow/Design_FAQ#Native_<input>_tags Quiddity (WMF) (talk) 22:56, 23 November 2013 (UTC)Reply