Talk:Flow/Interactive prototype

Previous page history was archived for backup purposes at Talk:Flow/Interactive prototype/LQT Archive 1 on 2015-07-10.

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.

I share the view above, I love the idea but the interface itself is too bulky..

I completely agree.

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.

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?

yutube

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.

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.

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.

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.

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.

You might find watching some of the user test videos enlightening with regards to why Wikitext is a bad idea.

(Content removed). Posted twice because the flow editor failed to refresh the page and show where my first comment were. Oh, the irony...

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.

It's not the Flow editor, it's the LiquidThreads editor. Flow doesn't exist, yet.

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.

<redacted>

I would dearly love to kill off Wikitext. But perhaps you should talk to Gabriel Wicke about that.

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...

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.

"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).

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.

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...

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?

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").

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.

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.

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?

This post was posted by Okeyes (WMF), but signed as Ironholds.

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.

Sure, which can be handled pretty easily by replying versus splitting off a new sub-thread. Even LiquidThreads has that feature.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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. ;)

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.

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.

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.

I see this minimal requirement for Flow, that it can actually discuss whatever the article space contains (that is, Wikimarkup) has been ignored.

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.

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.

(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.

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.

Many editors disable the Visual Editor. Are they going to be unable to talk? Or are you going to override their preference setting?

See also Thread:Talk:Flow Portal/Interactive Prototype/Markup-mode *needed* in editor/reply (20) below. Will talk be disabled for people using certain web browsers? If so, then how will we interact with those users?

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.)

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.

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.

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.

This post was posted by SPage (WMF), but signed as S Page (WMF).

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).

Good question. I don't know.

This post was posted by SPage (WMF), but signed as S Page (WMF).

Note: This thread was moved to w:Wikipedia_talk:Flow/Design_FAQ#Native_<input>_tags

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.

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.

Will it be possible to edit messages (both our own and others')? I couldn't find any indication of such in the interface.

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))

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.

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.

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 Thread:Talk:Flow Portal/Interactive Prototype/Vandalism, privacy issues, spam, libel issues, etc./reply (2) for my comment&pointer about user-level-restrictions.

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.

Couldn't agree more.

I've added "(or other user-group)" to the documentation, per discussions. If one user-group is selectable, any user-group is selectable.

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.

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.

What does "en.Wikipedia has come out strongly" mean? Do you have a link?

en:Wikipedia talk:Flow#Request for Comment on editing other user's comments with Flow

Thanks. (And [Template:Fullurl:: 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).

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.

Perhaps you should explore the prototype some more; whole Topic history has been there for quite some time.

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.

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.

"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?

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?

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.

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.

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 :)

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.

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

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.

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)

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.

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.

Curiously, I found it pretty quick on mine.

¿Que es este sitio?

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?

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.

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.