Topic on Talk:Flow/Interactive prototype

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.

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.

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.

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

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.

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.

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

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

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

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.

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

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.

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.

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.

NO! I really HATE the VE.

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?

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.

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

What's horrific about the hatnotes?

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.

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.

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

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

I would like to request that we have less hyperbole. It makes the conversation needlessly hostile.

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

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.

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.

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?

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.

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