Based on the content I have seen in discussions (on both Flow and Talk pages) I don't think the switch to wikitext should be much more prominent than other tools such as the link tool or mention tools for example.
Having said that, I think we can increase the prominence when we identify that is needed. For example, if we can detect the user is typing wikitext while in VE mode (which Visual Editor is capable of when editing an article), we can react by making the switch-to-wikitext button more prominent (e.g., change in color, label/tooltip appearing, etc.).

One thing that Filceolaire said struck me as a good point -- VE currently uses a different icon for switching to source mode, and our toggle might be more visible if it was consistent with that. I'll attach a shot of that below.

We had an initial discussion about that. The main points to figure out (which is the right metaphor to use and verifying whether it works) were captured in T97451: Make source/wikitext icon consistent. If we find out that the current icon is an issue for discoverability, I'm totally for changing it, but I think that instrumenting it to measure how much it is clicked would provide us a wider perspective and allow to compare the effects of possible icon changes.

We're still getting a steady drumbeat of complaints from users who say that the toggle icon is confusing.

I'm not sure how instrumenting the switch would be helpful in figuring this out. If there are 750 clicks on the toggle per week, that doesn't tell us anything about whether the toggle is discoverable or not. With time running out on this phase of Flow development, I'd like to see if we can come up with a switch that's more easily discoverable.

Is text out of the question? We already have a line of text in the wikitext editor with a link that switches to VE anyway. A small [ Wikitext ] in the bottom right on the VE entry field might be okay.

My main concern is with the alignment of prominence with the frequency of use. I'm assuming that most of the time replies in the discussions Flow supports are based on plain text, often some styling or richer elements such as links are needed, and in fewer cases getting into a "code" mode is needed to see the internals of the content and tweak it to add advanced stuff. This is the reason why the text area is presented upfront, then icons for format are shown later in a compact way, and source mode is shown in the right. Raising the prominence of the wikitext switch over the formatting actions breaks that balance in the overall picture.

I'm open to ways that add more clarity to the action but I don't think that just raising the prominence of the button is beneficial overall. For example, currently standard tooltips take a while to appear which makes them less useful in this context, having fast appearing tipsy tooltips as proposed originally (T90764) may also help. Another option could be to replace the direct action with a settings menu where we can add a label to the action without affecting other usecases (Illustrated below).

Another related issue is about the clarity of the icon. We considered using a generic source icon instead of a more specific wikitext icon. The rationale was to avoid non-experienced users to be exposed to unfamiliar concepts. The icon use is common in HTML and Markup editors so a user that wants to just ask a question in a talk page can identify that as the code-advanced mode. I'm ok in changing the icon to a specific wikitext one if this is causing issues to advanced users but it would have been great to have some observations on how each group of users understands the icon.

Some side story about prominence and the role of metrics

(Apologies in advance if it goes a bit off-topic or beyond the specific scope of the current ticket)

With the Media Viewer project we got complaints about image metadata information not being discoverable because it required to scroll to access it "below the fold", as a response to those complaints and despite design recommendations a button was added above the fold to access Commons. Then we got complaints about the button not being discoverable enough, and it was turned blue. Fortunately, we got no additional complaints. After instrumenting these actions, the increase of prominence was not resulting on a significative increase in users clicking at the button. Even more, the whole assumption of scrolling being non discoverable was probably wrong: we can check that on a daily basis users scroll to get image details ("file description page (above fold)" event) one million times while the button is used about 70K per day ("metadata open (scroll)"). As captured in the retrospective that the Multimedia team did, capturing these metrics was really positive and one of the biggest regrets was not doing that earlier and often ("Get key metrics on the status quo before doing any changes.").

I'm not sure how instrumenting the switch would be helpful in figuring this out.

It probably won't tell the whole story but it may be better than operating completely blind. For example:

• If we estimate that switching to Wikitext may be needed for 25% of the messages, but we measure that it is being used only in 1% of them, then we have an indication that there may be a problem.
• If we decide to try another approach which makes the button more prominent (e.g., a flashing blue button) you would expect its use to be increased (because of those people not able to find it with the former version). However, if that does not happen, we may consider that the button was discoverable enough and it was a matter of users just not needing to switch to Wikitext (or we may consider the button not being prominent enough and try another even more prominent version).

So my question would be: how are we going to check if the button is more discoverable after the change? By the lack of new complaints? By asking the people that complained initially (who now already know about the button) to imagine they are seeing the new version for the first time?

With all the above, I'm not saying to just ignore self-reported feedback (feedback of different kinds can be very informative). I just wanted to illustrate the challenges of capturing a broader picture and being able to make sure that an improvement is made with each change.

Change 234435 had a related patch set uploaded (by Catrope):
Use wikitext icon from VE for the VE->WT switch tool

https://gerrit.wikimedia.org/r/234435

In T101316#1582137, @gerritbot wrote:

Change 234435 had a related patch set uploaded (by Catrope):
Use wikitext icon from VE for the VE->WT switch tool

https://gerrit.wikimedia.org/r/234435

Random idea: VE already has an icon for the concept of switching to wikitext, so we could use that icon. Or, if we decide that a different icon would communicate that better, we should probably be using the same icon in both places.

The issue is that there are experienced editors who are specifically looking for the switch to wikitext, and can't find it. I've heard this a number of times, including the conversation linked at the top.

The </> icon doesn't mean code to me -- you could easily see it as two arrows pointing in opposite directions, so people assume it's a navigation icon and leave it alone.

As Roan said, the existing VE icon uses two brackets, which I think is a more recognizable icon for switching to wikitext. I'd like to switch to that, if we can think of a decent icon for the other direction. A stylized VE in that spot could work.

The </> icon doesn't mean code to me -- you could easily see it as two arrows pointing in opposite directions, so people assume it's a navigation icon and leave it alone.

When researching for common ways to represent code icons along those lines were quite widespread in places to represent code (as a general idea) as well as an alternative view of a piece of content. I just added a couple of examples from the code-related site Github:

Icons, especially when analysed out of the surrounding context, are subject to multiple interpretations, but in this case I think we tried to follow existing conventions. In an icon repository we can find many alternative representations for "code" but despite the lack of context, the fact that many of them are based on the very same concepts makes me think that it is common to associate them with the idea of "code".

It would be very informative to hear more details about the confusion with navigation when a user who don't know hat the icon does is looking for wikitext (where is trying to look at for such functionality? or are they not even trying? where is the user expecting this navigation to lead them to?).

So I think that the current icon is one of the safest bets to represent "code". As I detail below, whether to represent "code" or "wikitext" (or something that represents each concept good enough for the users which are familiar with each) is a different discussion.

As Roan said, the existing VE icon uses two brackets, which I think is a more recognizable icon for switching to wikitext.

I'm ok in using the wikitext icon. I think it could work reasonably well for the overall of our users.

It definitely represents wikitext better. My preference for using a more generic concept (to try to represent code as oppose to the specific wikitext code) is because of those users reaching Flow without any editing mindset at all (e.g., users following the "provide feedback link" of a given feature and reaching a discussion page where they can create a message) and not knowing what wikitext is at all. If we assume that there are users not knowing what wikitext is, we can also assume that references to wikitext may be confusing for them.

Having said that, the icon itself can work well enough as a generic "code" representation too. Probably not the best one (not as common around the web), but if it adds extra clarity for advanced editors is definitely worth trying.

I'd like to switch to that, if we can think of a decent icon for the other direction. A stylized VE in that spot could work.

I'm not sure we need a different icon to go back. Currently we are just presenting a mode that you can enable, clearly highlighting it as active, and disable. Making the icon switch created the action/state confusion where it is no longer clear whether the icon represents the state you are in, or the state you'll go after clicking on it. This is a well known source of confusion I'd try to avoid unless we have resources to test it is not happening in this case.

I've been meaning to change the WT->VE button too (not just the icon, more aspects of it). Would you say that changing that to be identical to the proposed new VE->WT button (wikitext icon) except with active/pressed styling would work?

In T101316#1585664, @Catrope wrote:

I've been meaning to change the WT->VE button too (not just the icon, more aspects of it). Would you say that changing that to be identical to the proposed new VE->WT button (wikitext icon) except with active/pressed styling would work?

I'd need some more detail on those aspects. Which is the "proposed new VE->WT button"? Is there any Phab. ticket describing it? Is the patchset https://gerrit.wikimedia.org/r/234435 including already those aspects beyond the icon change?

What I proposed is to present rich text editing as the default where there is a wikitext mode that can be activated and deactivated. That is supported by a button representing the wikitext mode that remains active while the user is in such mode. I'm not sure if the above comment is diverging from that or not, and which are the reasons to do that.

In T101316#1588495, @Pginer-WMF wrote:

In T101316#1585664, @Catrope wrote:

I've been meaning to change the WT->VE button too (not just the icon, more aspects of it). Would you say that changing that to be identical to the proposed new VE->WT button (wikitext icon) except with active/pressed styling would work?

I'd need some more detail on those aspects. Which is the "proposed new VE->WT button"? Is there any Phab. ticket describing it? Is the patchset https://gerrit.wikimedia.org/r/234435 including already those aspects beyond the icon change?

That patch only changes the VE->WT icon (to the one from VE). That's also what I meant by "proposed new VE->WT button": a button with the wikitext icon. So what I meant was, how about having a button with the wikitext icon that looks normal in VE mode and looks active in WT mode. It sounds like that's the same as what you meant:

What I proposed is to present rich text editing as the default where there is a wikitext mode that can be activated and deactivated. That is supported by a button representing the wikitext mode that remains active while the user is in such mode. I'm not sure if the above comment is diverging from that or not, and which are the reasons to do that.

Yes, that's exactly what I meant. Sorry for not being very clear. I'll whip up a patch soon to demonstrate this.

Change 236726 had a related patch set uploaded (by Catrope):
Replace the WT->VE switch button with an OOUI toolbar tool

https://gerrit.wikimedia.org/r/236726

In T101316#1591376, @Catrope wrote:

Yes, that's exactly what I meant. Sorry for not being very clear. I'll whip up a patch soon to demonstrate this.

Alright, that took longer than expected, but please take a look at https://gerrit.wikimedia.org/r/236726 . It replaces the </> WT->VE switcher button with an OOUI toolbar tool using the same icon as the VE->WT icon from my earlier patch (https://gerrit.wikimedia.org/r/234435), except that it's always in the active/pressed state, so it looks like a toggle

To make the toggle effect more convincing, I also made the VE and WT editors exactly the same height (hence the giant stack of commits below it). This makes it so the tool doesn't appear to move when you click it, even though it's a completely different DOM element since we've just removed the entire editor and built a new one. The only remaining difference I could see when switching between empty VE and WT editors is that the placeholder moves slightly upwards and leftwards. I haven't figured out why that is yet and I don't have time to look into it further right now; maybe later.

Change 234435 merged by jenkins-bot:
Use wikitext icon from OOUI for the VE->WT switch tool

https://gerrit.wikimedia.org/r/234435

Change 236726 merged by jenkins-bot:
Replace the WT->VE switch button with an OOUI toolbar tool

https://gerrit.wikimedia.org/r/236726

Filed two issues:
T111984 and T111987(it's a regression bug)

@Pginer-WMF Before I forget, here's a note, just in case this gets re-opened.
Here's a clearer additional rationale for using a text label, in addition to an icon.

The wikitext icon might not be considered clear enough. because it is:

• close to the ULS keyboard icon (when in wikitext-mode),
• in the same location as the draggy-arrow for resizing textboxes (which a standard page's wikitext editor has, and the usual visualeditor doesn't need).

both of which regular editors are accustomed to ignoring.

Current status

Regular wikitext editor: