@Jaredzimmerman-WMF regarding the first comment, I think we need a general framework to deal with actions attached to input fields. I was thinking on distributing actions on the left and configuration on the right where the input method menu could fit.

Regarding the second comment, I think you are right and we could avoid the whole mode switching if VE supported wikitext input.

In T78346#1010433, @Pginer-WMF wrote:

Regarding the second comment, I think you are right and we could avoid the whole mode switching if VE supported wikitext input.

Currently, VE mostly just warns you about this ("Wikitext markup detected")

Even if VE supported certain obvious wikitext examples (actually, it does for certain very limited cases like the * list keyboard shortcut), it's never going to support the full power of wikitext. That would require a *third* full-featured wikitext parser, in addition to the PHP MW parser and Parsoid, with the added complication that the source text is part rich text, part wikitext.

I think mode switching is a better choice. We can make the mode switch control normally subtle, then become obvious if you start typing wikitext (VE already has logic to detect this, as noted above).

Since people are already talking about VE, I expanded the scope of the task somewhat ("WikiEditor" is the wikitext toolbar shown in production). This is in the idea/design stage, so it's okay to cover both technologies in the same task for now.

We're going to work on this as part of turning on VE for Flow.

The current spike card is T88182 : Define and estimate work for Minimum Viable Product of VisualEditor in Flow (spike)

I miss my custom buttons in the edit toolbar.
See also:

• T23692: Personal edit toolbar lost (LiquidThreads)

In T78346#1017880, @He7d3r wrote:

I miss my custom buttons in the edit toolbar.
See also:

• T23692: Personal edit toolbar lost (LiquidThreads)

I installed 3 of your scripts to test: https://meta.wikimedia.org/w/index.php?title=User:Quiddity_%28WMF%29/global.js&diff=11213986&oldid=10917385
And took these screenshots: http://imgur.com/a/na16D#0

Are there any use-cases here that might be widely applicable to an entire wiki, or even to all wikis as a default Flow feature? Or perhaps a global-template (if/when those arrive) ?

Separately, I know there is some amount of local customization of the WikiEditor Toolbar buttons (both individually, and at the wiki-level), but I'm not sure how widespread the individual customizations are, nor how to find out, beyond searching for "addToToolbar" at each wiki in user-space and mediawiki-space. Any suggestions?

On talk pages, I believe these are the custom buttons I use the most:

<code>test</code>
<nowiki>test</nowiki>
<syntaxhighlight lang="javascript" enclose="none">test</syntaxhighlight>
<span style="color: #000; background: #E99;"></span>
<pre>test</pre>

(mainly because I usually help with technical problems in the wikis I use) and for content pages,

<math>test</math>

which was removed in 2009 by the usability initiative
https://usability.wikimedia.org/wiki/Talk:Releases/Acai#Math

In T78346#1026966, @Quiddity wrote:

...
Separately, I know there is some amount of local customization of the WikiEditor Toolbar buttons (both individually, and at the wiki-level), but I'm not sure how widespread the individual customizations are, nor how to find out, beyond searching for "addToToolbar" at each wiki in user-space and mediawiki-space. Any suggestions?

IMHO, you'd be doing yourself an injustice if you try to make decisions or draw up plans based on a tally of the "current" numbers or try to apply a "strict" accounting rationale in order to reliably ascertain something like that.

Speaking entirely from the perspective of an Admin primarily focused on the needs and wants of en.wikisource contributors, a vast majority were not entirely thrilled with the Classic toolbar to begin with.... but the ease of customizing it to specific needs still makes it near & dear to just about anyone with any decent amount contributing time under their belts even today. And its not entirely true when folks were never "sold" on what the WikiEditor initiative(s) promised either.

Most folks by me tried WikiEditor when it came off the beta status and immediately hated what they a.) were being forced to load as the "defaults" closely followed by b.) the convoluted process needed just to add customizations to make a.) somewhat bearable. Take those two points and add-in the fact the ProofreadPage extension made life with WikiEditor more problematic as time went by and the exodus back to using the Classic toolbar is not hard to understand.

So its not that [my] people won't or don't utilize WikiEditor because it "sucks" or something but because -- at its core -- its specifically designed for the never-to-appear-again-in-the-numbers-they-once-did newbie or occasional Wikipedia-geared contributor with Wikipedia-like needs (not the deal-breaker however). What everybody agrees on as the major roadblock is the forcing of 'crap' as defaults nobody will ever use in addition to the inability to remove said defaults nor the customization of buttons & such without jumping through a billion hoops most non-techie types just won't deal with.

Make the current WikiEditor defaults an option or User pref with a far more simply way to customize it for individuals and I guarantee you the "opting-in" of the Classic toolbar would drop off drastically.

In T78346#1026966, @Quiddity wrote:

Separately, I know there is some amount of local customization of the WikiEditor Toolbar buttons (both individually, and at the wiki-level), but I'm not sure how widespread the individual customizations are, nor how to find out, beyond searching for "addToToolbar" at each wiki in user-space and mediawiki-space. Any suggestions?

mwgrep can answer this question for WMF production. It allows searching for CSS and JS in the User, MediaWiki, or Module namespaces (one at a time).

In T78346#1033515, @GOIII wrote:

Make the current WikiEditor defaults an option or User pref with a far more simply way to customize it for individuals and I guarantee you the "opting-in" of the Classic toolbar would drop off drastically.

Note: Enhancing WikiEditor for normal pages is completely outside the scope of this bug.

In T78346#1038747, @Mattflaschen wrote:

Note: Enhancing WikiEditor for normal pages is completely outside the scope of this bug.

Then don't select the next course of action based solely on that mwgrep's results.

Folks aren't using WikiEditor in some meaningful number just because of the lack in the ease of customization compared to the Classic toolbar followed by some other meaningful number for the inability to prevent the generation of WikiEditor's current defaults.

So until we either actively poll for as much or implement & advertise those "enhancements" to accurately gauge User: preference, etc., we're just making decisions based in conjecture & assumptions more so than in reality and facts.

In T78346#1038829, @GOIII wrote:

So until we either actively poll for as much or implement & advertise those "enhancements" to accurately gauge User: preference, etc., we're just making decisions based in conjecture & assumptions more so than in reality and facts.

The Design Research team did some investigation into editing tools. I believe they're still compiling the results, but here are the links for watchlisting: https://www.mediawiki.org/wiki/Design/Research#Editing

In T78346#1060761, @Quiddity wrote:

In T78346#1038829, @GOIII wrote:

So until we either actively poll for as much or implement & advertise those "enhancements" to accurately gauge User: preference, etc., we're just making decisions based in conjecture & assumptions more so than in reality and facts.

The Design Research team did some investigation into editing tools. I believe they're still compiling the results, but here are the links for watchlisting: https://www.mediawiki.org/wiki/Design/Research#Editing

My point exactly - "they" limited their concerns, polling and decision to a single project (Wikipedia) -- which has a certain scope and a specific mission -- both of which translate to almost the complete opposites as far as Wikisource is concerned (a different project with a different scope and a different mission).

Wikipedia is an ongoing collaborative endeavor that expects both mainspace presentations and non-mainspace discussions to always be in a state of perpetual flux to some degree thanks to it's inherent nature where new developments = addition of new sources to support new content = new points of contentions to work through.

Wikisource, on the other hand, shares little with Wikipedia beyond also being an ongoing collaborative endeavor. Our mainspace end products are suppose to be static by design and as a result our non-mainspace discussions are mostly style guide/formatting/bug/enhancement related in nature.

What does this mean? In a nutshell (a few examples-wise), this means...

1. Nobody here gives a crap about citation tools et. al anywhere near the degree to which Wikipedians do - we primarily deal with static footnotes found in the original fixed content of a specific edition of a copyright free publication. So -- while the two feel similar at first glance -- they are not in practice nor purpose.
2. Thanks to the nature of the works being reproduced and hosted on WS, our needs for image manipulation and presentation make things like Media Viewer completely useless.
3. Flow is pretty and (I guess) helpful for ongoing or complex discussions; we just don't have as many instances of this as Wikipedia seems to have. Sure, making it standard provides easier maintenance across all wikis but it won't add much "value" to our project if any at all.
4. We don't attract the temp newbie contributor types in any comparable numbers nor are they likely to need toolbar dialog crutches to facilitate contributions. What prevents folks by us to break out of their specific favorites into "new" works is an easier way to customize tools to specific works & not so much the repetitive WP-like tasks.
5. ... and I could go on ad nausea

The point -- as it relates to the issue of editing/toolbars in general and development overall -- is "we" basically continue to have no say in these matters; if an editing feature or a contribution aspect is not Wikipedia- or Commons- centric, the editing needs of other projects will, at best, be an add-in, a work around or some other afterthought -- if "we" are lucky, that is. The Editing Tasks Survey mentioned is but another example of this....

... Based on the above criterion, we queried our internal data-bases for English Wikipedia users and found 9316 users to contact.

Doesn't seem like anything "good-for-Wikisource" can from decision making based on polling like that does it?

Flow is pretty and (I guess) helpful for ongoing or complex discussions; we just don't have as many instances of this as Wikipedia seems to have. Sure, making it standard provides easier maintenance across all wikis but it won't add much "value" to our project if any at all.

@GOIII, so for the specific case of discussions in Wikisource, is there any specific kind of content that would be useful to get help from a rich text editor to deal with in converstions?

I tried to look for some complex scenarios based on current use but in the example I found formatting needs seemed basic (user mentions, lists, and links). Do you know of some examples of current (or potential) uses of more advanced formatting?

In T78346#1061982, @Pginer-WMF wrote:

@GOIII, so for the specific case of discussions in Wikisource, is there any specific kind of content that would be useful to get help from a rich text editor to deal with in converstions?

I tried to look for some complex scenarios based on current use but in the example I found formatting needs seemed basic (user mentions, lists, and links). Do you know of some examples of current (or potential) uses of more advanced formatting?

@Pginer-WMF - Boy, finding something in NS-1 (the talkspace for the main namespace) that would benefit from Flow is not likely to exist. Again, Wikisource's mainspace output follows the premise of ''reproducing an original publication as faithfully as possible" so there is little left to question where long or ongoing talk page discussions are likely needed to take place.

Still, we do have continuous "action" in the Village Pump equivalent, Scriptorium, that might benefit from using Flow. Debate traffic also exists for certain Help: and Template: namespace pages every so often, but nowhere near approaching the typical Wikipedia article's talkpage traffic or timeframe.

I'll keep looking for other possible examples in mind but I wouldn't bet on anything more substantial coming to light beyond those already mentioned.

I talked to James about toolbar use in VE -- they don't currently have tracking on which buttons get used the most. But he gave me his gut instinct on it, which I think is good enough for a first pass.

He said that for discussions, the most used tools are: Links, Mentions, and Bold/Italics.

(For article content, he'd also include Citations, Templates & Media, but these aren't as important for discussions.)

I think we can go with Pau's mockups for a first version of a VE/Flow toolbar. We can even take out the ellipsis/more menu, and just have these controls:

• Bold/Italics
• Link
• Mention
• switch to wikitext

This will be better than not having one, and we can find out what else people need from there.

Pau, we'll need mockups that show what happens when you click on those buttons. I'm assuming Bold/Italics has a dropdown menu. Would Link and Mention have little modal boxes?

Link should be exactly the same as VE once you click it, both for a consistent user experience and so we don't have to implement a new link widget (with autocomplete, etc.)

Based on these example threads, and our goal to rollout further at mediawikiwiki, and He7d3r's comment above, and my own experience, I still strongly advocate for having <code> and <nowiki> tags available and planned from the start (in a dropdown menu).

• https://ca.wikipedia.org/wiki/Topic:Sbk26yv6cpcxxm87
• https://ca.wikipedia.org/wiki/Topic:Sbi6jrldf94ea8nt
• https://ca.wikipedia.org/wiki/Topic:Sa23rwtl0w12e4sk
• https://ca.wikipedia.org/wiki/Topic:S8h1yv4n7yfm4fmi
• https://ca.wikipedia.org/wiki/Topic:S8adbxrruu971vyd
• https://fr.wikipedia.org/wiki/Sujet:Sb3nxhhm4wdodaez
• https://fr.wikipedia.org/wiki/Sujet:Sabk082dkr6rat37
• https://fr.wikipedia.org/wiki/Sujet:Sb3m5set5zkob0rj
• https://fr.wikipedia.org/wiki/Sujet:Sbceer9529lnk66g

Being able to discuss wikimarkup, is crucial to so many of the places we want to deploy to.

+1 to the idea of starting with a subset of the current VE toolbar for articles.

+1 to the idea of enabling in the Flow VE buttons the same UX as the full ED version.

if anyone is going to write 'yet another toolbar', can someone please make sure to really think stuff through ? I'm counting:

1: Old toolbar (that community doesn't want to get rid off, yet we do)
2: WikiEditor toolbar (that we prefer over old, but is also a bit over designed and old style JS)
3: VE toolbar (OOjs UI, but not yet finished)
4: Mobile Editing versions of VE toolbar.
5: and now Flow

Will the Math extension soon require 4 modules to provide a math insertion button to all editors types ?
We have things like textSelection, confirmCloseWindow, live preview and stash. All that stuff comes into play, and any new wikitext editor work we do should recognize that and along the way should try to improve and consolidate.

Similarly:

Enhancing WikiEditor for normal pages is completely outside the scope of this bug.

But please do account for the many ways in which it is FAILING users.

The idea is for the different controls to behave like they do on the VE toolbar (preferably using the same components, just adjusting how prominent they are shown according to our context). For the case of the text format action, a drop-down like the one used by VE will be shown:

Regarding which controls to use, some thoughts:

• Regarding the "code" and "nowiki", I wonder if we can have a unified "quote" action to cover most of the usecases (refer to portions of wikicode, source code, or specific parts of a comment someone previously said).
• We may consider lists and inserting media to be under the "more" section. For example, in the current conversation in Phabricator they are used frequently and, although it cannot be generalised, I wonder if they may be used more in the wiki context if they were easily accessible.
• I think it is ok to start with fewer controls and iterate on adding new ones.

With the controls mentioned above, the expanded "more" menu can either expand in-place the advanced controls or be a regular dropdown menu (the later may be easier to support initially, but if menu items grow, or we want to better support repetitive use the former is preferred):

We talked about this in the design meeting this morning, and decided on a plan for v1.

We need to get a simple v1 of the VE toolbar out soon, in order to roll out on a couple of languages that are excited about trying out Flow.

So v1 will have:

• Bold/Italics (with a menu offering the two choices)
• Link (with the same VE modal)
• Mention (with a new modal)
• Toggle to wikitext / VE

There are several pieces that we definitely want to include, but not in the v1: Lists, something that helps with Code/Pre/Nowiki/Blockquote (tbd), and Insert media. (Insert media would be especially helpful if it includes an upload picture function, so that people could upload screenshots when they're asking for help.)

Pau, I think the only mockup that we still need is the mentions modal... Am I forgetting anything?

For the mention dialog (check mockups below), I would recommend the following:

• Show the dialog in-line with the text. When the user clicks on the mention icon, the dialog is shown where the text cursor is. This makes the user feel that she is manipulating the content directly since the information is in a single place.
• Initially, provide as the auto-suggestion values the users that participate in the current conversation or sub-conversation, or the frequently mentioned by the user (or any other criteria that can anticipate the user action and it is easy to implement).
• As the user types, auto-suggestions will show users with the given username (if possible, it would be great to be flexible in the search to typos and preferred names if those are available). The first selection will be highlighted (following the standard style for list selection).
• If the user is not found, some text will indicate so.
• An option to close the dialog is provided.
• The dialog can be controlled with the keyboard. The user can type @ and the dialog will open for the user to just type the user name and hit enter to insert the first selection from the list. We may want to not interfere with the use of "@" as a valid character. For that we may want to (a) make sure that the "@" happens in a valid context (after a space, text beginning, or non-word character) to avoid it appearing when users type an email for example; and (b) close the panel if the user types a space after having pressed "@", which would just result in adding the "@" character. the "esc"key will close the dialog.
• Most of the time the mention action will be triggered without a selected text,but if there is a text selection, we may want to use that text for the user search when the panel is opened. In this scenario, if the operation is cancelled, the user text should not be destroyed.

I also put together some of the mockups we mentioned for the first version in this prototype. Only basic transition between modes are supported, don't expect to actually turn text into bold.

VE basically has two types of dialogs:

• Inspector (the one you see when you click the link icon)
• Dialog (e.g. Insert->Template)

For now, I think we should stick to one of these two, for both maintainability and visual consistency. The closer one (but not that close) is inspector.

In T78346#1099845, @Pginer-WMF wrote:

For the mention dialog (check mockups below), I would recommend the following:

• Show the dialog in-line with the text. When the user clicks on the mention icon, the dialog is shown where the text cursor is. This makes the user feel that she is manipulating the content directly since the information is in a single place.

We decided it will use an inspector, at least initially.

• Initially, provide as the auto-suggestion values the users that participate in the current conversation or sub-conversation, or the frequently mentioned by the user (or any other criteria that can anticipate the user action and it is easy to implement).

Auto-complete will use all authors in the current topic.

• Inspector (the one you see when you click the link icon)

We can start using this. I can create a mockup to illustrate the dialog in that format.

I added new screenshots from the prototype to T90764.

I have a question about the Mentions modal: If there are a lot of users who have posted on the thread, does it get a scroll bar?

In T78346#1115277, @DannyH wrote:

I added new screenshots from the prototype to T90764.

I have a question about the Mentions modal: If there are a lot of users who have posted on the thread, does it get a scroll bar?

Yes. Try typing Assoc into the link inspector to get an idea. Ours probably won't be a truncated list, though.

I've created T92588: Implement mentions inspector to track this specifically.

In ru.wiki we definitely ourselves will add some buttons for wikitext. (https://ru.wikipedia.org/wiki/Википедия:Викификатор , https://ru.wikipedia.org/wiki/Википедия:Гаджеты/Упрощение_ссылок ) Something for these buttons "it was necessary already yesterday".

Shouldn't this be resolved?

See also https://www.mediawiki.org/wiki/Topic:Smsn1ofyp04kqxle.

On this feedback, a user asks to have personalized buttons on the toolbar (#3), and a way to add templates (#8).

A user complains about she can't post pictures of kittens on a conversation. We definitely need to do something. For kittens.

Create a minima a way to personalize VE and wikitext toolbars with a gadget would be a good idea. I know, there is always risks of abuses (thousand of buttons) but this did not happen with wikitext editing toolbar afak.

Create a minima a way to personalize VE and wikitext toolbars with a gadget would be a good idea.

Adding media is a reasonable usecase for conversations. We consider providing support for it from the beginning but the decision was postponed until VE would be able to support an uploading process (and not just reusing existing images from commons).

As the image upload workflow gets supported inside VE, Flow would adopt those powers too (at least for the rich text view where VE is used). If I recall correctly, exposing the "insert media" icon is just a simple configuration change.

In T78346#1747890, @Pginer-WMF wrote:

Create a minima a way to personalize VE and wikitext toolbars with a gadget would be a good idea.

Adding media is a reasonable usecase for conversations. We consider providing support for it from the beginning but the decision was postponed until VE would be able to support an uploading process (and not just reusing existing images from commons).

That will be done very soon, next week iirc. (T40030: Way in VisualEditor to initiate Commons file uploading, and insert image on completion)

As the image upload workflow gets supported inside VE, Flow would adopt those powers too (at least for the rich text view where VE is used). If I recall correctly, exposing the "insert media" icon is just a simple configuration change.

There is two different requests from communities :

• add images on a conversation
• add smileys/kittens/whatever on a conversation (usual tools on a chat)

And there is still the following needs:

• add a toolbar to wikitext
• personalize the toolbars (I would love to have my personal pre-written messages when I answer on the fr help desk)

New feedback concerning the lack of toolbars. I hope we will be able to address that problem soon.

Some thoughts raised during Collaboration team's offsite concerning VE toolbar for Flow have been added to T93243: Flow's VE toolbar v2.

I'm retitling this task, due to the recent work on the VE toolbar in T93243: Flow's VE toolbar v2