Talk:Flow Portal/Interactive Prototype

Jump to: navigation, search

About this board

Edit description

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

What about all the nice things Wikitext offers us? Will they be available in Flow?

Patrick87 (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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.

Patrick87 (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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.

Patrick87 (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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

Diego Moya (talkcontribs)

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

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.

Arthur Rubin (talkcontribs)

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

Jorm (WMF) (talkcontribs)

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.

Anomie (talkcontribs)


Jorm (WMF) (talkcontribs)

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

Patrick87 (talkcontribs)

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

Jorm (WMF) (talkcontribs)

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.

Patrick87 (talkcontribs)

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

Jorm (WMF) (talkcontribs)

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.

Patrick87 (talkcontribs)

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

Okeyes (WMF) (talkcontribs)

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?

Patrick87 (talkcontribs)

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

Okeyes (WMF) (talkcontribs)

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.
Patrick87 (talkcontribs)

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.

Okeyes (WMF) (talkcontribs)

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.

Patrick87 (talkcontribs)

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.

Okeyes (WMF) (talkcontribs)

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

Patrick87 (talkcontribs)

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.

Okeyes (WMF) (talkcontribs)

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.

Patrick87 (talkcontribs)

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

Jorm (WMF) (talkcontribs)

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.

Patrick87 (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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.

Patrick87 (talkcontribs)

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.

Stefan2 (talkcontribs)

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.

Arthur Rubin (talkcontribs)

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.

Quiddity (talkcontribs)

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

Marcgal (talkcontribs)

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.

Diego Moya (talkcontribs)

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.

Arthur Rubin (talkcontribs)

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

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

Jorm (WMF) (talkcontribs)

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.

Arthur Rubin (talkcontribs)

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

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

Maunus (talkcontribs)

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.

Kww (talkcontribs)

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

Stefan2 (talkcontribs)

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?

Quiddity (talkcontribs)

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

TMg (talkcontribs)

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.

Myrtonos (talkcontribs)

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.

SPage (WMF) (talkcontribs)

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

Stefan2 (talkcontribs)

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

SPage (WMF) (talkcontribs)

Good question. I don't know.

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

Reply to "What about all the nice things Wikitext offers us? Will they be available in Flow?" (talkcontribs)
Reply to "Native <input> tags"
NaBUru38 (talkcontribs)

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.

Quiddity (WMF) (talkcontribs)

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.

Reply to "Comment format"
Waldir (talkcontribs)

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

Sven Manguard (talkcontribs)

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

Waldir (talkcontribs)

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.

Mange01 (talkcontribs)

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.

Quiddity (talkcontribs)

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.

Sj (talkcontribs)

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.

Waldir (talkcontribs)

Couldn't agree more.

Quiddity (talkcontribs)

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

TMg (talkcontribs)

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.

Arthur Rubin (talkcontribs)

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.

TMg (talkcontribs)

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

Diego Moya (talkcontribs)

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

TMg (talkcontribs)

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

Diego Moya (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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

Diego Moya (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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.

Diego Moya (talkcontribs)

"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 (talkcontribs)

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?

Reply to "Editing?"
Stefan2 (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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.

Reply to "Redirects"
Fox (talkcontribs)

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

TMg (talkcontribs)

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.
Reply to "Header prominence" (talkcontribs)

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

Jorm (WMF) (talkcontribs)

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

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

Jorm (WMF) (talkcontribs)

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.

Diego Moya (talkcontribs)

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.

Anthere (talkcontribs)

Curiously, I found it pretty quick on mine.

Reply to "It's awful!"
Diego Moya (talkcontribs)

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?

Jorm (WMF) (talkcontribs)

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.

Reply to "Weird comment reordering"
Diego Moya (talkcontribs)

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.

Reply to "Inverted page structure"
Patrick87 (talkcontribs)

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

Jorm (WMF) (talkcontribs)

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.

Patrick87 (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

You'll have to talk to the VisualEditor team about their functionality, I'm afraid.

Patrick87 (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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.

Patrick87 (talkcontribs)

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

Jorm (WMF) (talkcontribs)

I'm not at liberty to promise either of those things, and I wouldn't promise them even if I could.

Moroboshi (talkcontribs)

I hope there is someone that is coordinating or at least keep the concatct between the two project so that they can work together.

Kww (talkcontribs)

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.

Maunus (talkcontribs)

I agree. I want to disable it entirely and I certainly dont want to be forced to used it on talkpages.Maunus (talk)

Zellfaze (talkcontribs)

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.

Stefan2 (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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.

Adam Cuerden (talkcontribs)

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

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.

Jorm (WMF) (talkcontribs)

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

Cyclopia (talkcontribs)

What's horrific about the hatnotes?

Jorm (WMF) (talkcontribs)

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.

Stuartyeates (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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.

John Broughton (talkcontribs)

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.

Jorm (WMF) (talkcontribs)

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.

Zellfaze (talkcontribs)

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.

Diego Moya (talkcontribs)

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?

Jorm (WMF) (talkcontribs)

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.

Diego Moya (talkcontribs)

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

Reply to "Markup-mode *needed* in editor"