Topic on Talk:Flow/Interactive prototype

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