@iamjessklein @ppelberg @Esanders regarding Edit and Edit source icons, currently the desktop editor uses the following:

if we translated this directly to the sticky header we'd end up with this, which doesn't seem clear enough to me:

in Minerva we do the following:

which would result this, which feels a bit heavy to me but also seems more clear:

my initial instinct was to do what's shown below, which ultimately conflicts with how the icons are being used in the editor, and perhaps gives added weight to Visual editing (given that the pencil is, I'd guess, more easily recognizable as an Edit icon...though that might not matter given the sticky header is currently only for logged-in users and they will only see both icons if they have their preferences setup to show both):

My questions for you all are:

1. do you have time to form an opinion about this (which ideally would include thinking through all use cases — desktop, mobile, apps, etc. — and coming up with a coherent icon plan)? it's fine if you don't, we can also run this through our general design team process and get it sorted out in a more generic way
2. have you considered using a toggle instead of a dropdown in the editor, therefore removing the need for a "parent" icon? I bring this up because a) if we didn't have a parent icon it might simplify things (two icons instead of three), and b) according to UX collective it is bad UX practice to have a dropdown with only two items in it (link to article). E.g.

Thanks!

cc @ovasileva @RHo @Volker_E

The current interface is a result of T116417 in 2016-17. It's a long discussion thread, about dropdown/toggle/button layouts and the various icons; I haven't read it in entirety now, but I scanned and there seem to be a lot of the same suggestions you're making and answers to them. It looks like the current interface was ultimately proposed by Pau in this comment: T116417#2955333.

do you have time to form an opinion about this (which ideally would include thinking through all use cases — desktop, mobile, apps, etc. — and coming up with a coherent icon plan)? it's fine if you don't, we can also run this through our general design team process and get it sorted out in a more generic way

I defer to @ppelberg regarding timing and when we can integrate this work into our schedule.

have you considered using a toggle instead of a dropdown in the editor, therefore removing the need for a "parent" icon? I bring this up because a) if we didn't have a parent icon it might simplify things (two icons instead of three), and b) according to UX collective it is bad UX practice to have a dropdown with only two items in it (link to article). E.g.

As @matmarex noted, the team hasn't worked on this (at least not at all while I've been in this role). I agree that the UI is confusing. This has particularly become more challenging as the Visual Editing experience has become more robust over the years. I think that exploring a toggle here does make sense. From a high level, I think that there should be one "editing" button that defaults to visual mode and then can be toggled to source. From what I recall, however, whenever we've tried to implement some kind of default system, that has been reverted (for whatever reason) by the individual language wikis. So for example, VE is not default on English Wikipedia. (I'm sure @matmarex can speak more directly to this)

In T289723#7348837, @alexhollender wrote:

[...]
my initial instinct was to do what's shown below, which ultimately conflicts with how the icons are being used in the editor, and perhaps gives added weight to Visual editing (given that the pencil is, I'd guess, more easily recognizable as an Edit icon...though that might not matter given the sticky header is currently only for logged-in users and they will only see both icons if they have their preferences setup to show both):

Not sure if this has been discussed on a separate task, but showing both Edit and Edit source is actually dependent on the language wikis as well. So for example on cswiki both tabs are shown by default (even for logged out users).

---

My questions for you all are:

1. do you have time to form an opinion about this (which ideally would include thinking through all use cases — desktop, mobile, apps, etc. — and coming up with a coherent icon plan)? it's fine if you don't, we can also run this through our general design team process and get it sorted out in a more generic way
2. have you considered using a toggle instead of a dropdown in the editor, therefore removing the need for a "parent" icon? I bring this up because a) if we didn't have a parent icon it might simplify things (two icons instead of three), and b) according to UX collective it is bad UX practice to have a dropdown with only two items in it (link to article). E.g.

Thanks!

cc @ovasileva @RHo @Volker_E

Is there a possibility to remove the toggle/switch entirely from the wikitext/VE editors when there are two Edit/Edit source tabs?

Per discussion with @alexhollender and @ovasileva, when there is only one editing option enabled, the pencil editing icon should be shown for both VE + wikitext.

What is shown if both editing options are enabled is still TBD (2 icons or dropdown?).

What icons are shown for protected pages is still TBD and will be outlined in a follow up ticket.

Updated ACs accordingly.

In T289723#7368791, @RHo wrote:

In T289723#7348837, @alexhollender wrote:

[...]

Not sure if this has been discussed on a separate task, but showing both Edit and Edit source is actually dependent on the language wikis as well. So for example on cswiki both tabs are shown by default (even for logged out users).
Is there a possibility to remove the toggle/switch entirely from the wikitext/VE editors when there are two Edit/Edit source tabs?

Sorry to clarify, I mean currently it's weird when this happens:

	or in new vector

@iamjessklein @ppelberg a few additional nuances and questions we've discovered recently...

There are three states (so to speak) of the edit buttons in the article toolbar:

1. one Edit button that leads to VE
2. one Edit button that leads to wikitext editor
3. two buttons: Edit and Edit source

Mapping those three states to the sticky header we get the following:

	article toolbar	sticky header
1. one Edit button that leads to VE
2. one Edit button that leads to wikitext editor
3. two buttons: Edit and Edit source

The three things to note about the mockups above are:

• for states 1 and 2 the same icon is used (this is based on/mirroring the fact that in the article toolbar the button says Edit in both cases)
• for state 3 we still need to define which two icons to use
• for state 3 we have the option of using a dropdown instead of two icons (mockup below). While this is what we do in the editor I question if it would be as appropriate here because a) the article toolbar has two buttons in this case, not a dropdown (and we want to mirror that as much as we can), and b) the rationale for using a dropdown in the editor seems to be that adding some additional friction is useful so people don't switch from one to the other without knowing what they're doing, however in this context we are not yet in the editor we are still in the reading experience, so I'm not sure if that friction is necessary. However if we were unable to come up with two icons that were satisfactory to us, and not confusing to people using the site, it could make sense to consider the dropdown. Alternatively, in that case, we could also consider text labels instead (though I dislike this because the text in the sticky header competes with the content more-so than icons do).
  • with dropdown for editor choices
    
  • with text labels for editor choices
    

Change 723614 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[mediawiki/skins/Vector@master] Add edit icons to sticky header

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

@ppelberg @iamjessklein @ovasileva and myself met today to discuss this.

We discussed the three options for the situation where there are two edit buttons:

1. Use icon buttons
2. Use an icon-button with a dropdown menu
3. Use text buttons

Text buttons have the most consistency with the article toolbar at the top of the page. We agreed to flesh out the text button option a bit further. Here is how text buttons would look in a few different languages:

We noted an open question: what percentage of people see two edit buttons, and have they opted-into that situation?

Further explorations:

Continuing to evaluate the possibility of using icons. What if we tried to establish clearer icons for Edit and Edit source (not necessarily the ones below), used those icons+labels in the article toolbar and in the editor, and then used those icons in the sticky header? That might look something like this:

icons
article toolbar
editor
sticky header

I wonder if this would leave us in a more flexible situation going forward (i.e. being able to present a toggle with just icons), at least when thinking about mobile? In the case where there is only one edit button we could still use the generic pencil icon, and then whenever we need to represent the two options we use the more nuanced icons which would be somehow similar to the "parent" icon.

In T289723#7389944, @alexhollender wrote:

@ppelberg @iamjessklein @ovasileva and myself met today to discuss this.

We discussed the three options for the situation where there are two edit buttons:

1. Use icon buttons
2. Use an icon-button with a dropdown menu
3. Use text buttons

Text buttons have the most consistency with the article toolbar at the top of the page. We agreed to flesh out the text button option a bit further. Here is how text buttons would look in a few different languages:

We noted an open question: what percentage of people see two edit buttons, and have they opted-into that situation?

Hi @alexhollender - i mentioned this earlier but may have been lost in the threads, but I believe this depends on the wikipedia language, for example CS Wikipedia shows both edit buttons by default, even for logged out people.

FWIW, my preference out of your explorations are there ones that use an icon. Mainly I wonder if it will appear a little strange when scrolling that the username button/link to another page gets replaced with a Edit text-only buttons that are an action on the article content below.

---

Further explorations:

Continuing to evaluate the possibility of using icons. What if we tried to establish clearer icons for Edit and Edit source (not necessarily the ones below), used those icons+labels in the article toolbar and in the editor, and then used those icons in the sticky header? That might look something like this:

icons
article toolbar
editor
sticky header

I wonder if this would leave us in a more flexible situation going forward (i.e. being able to present a toggle with just icons), at least when thinking about mobile? In the case where there is only one edit button we could still use the generic pencil icon, and then whenever we need to represent the two options we use the more nuanced icons which would be somehow similar to the "parent" icon.

We noted an open question: what percentage of people see two edit buttons, and have they opted-into that situation?

There are two levels of customization:

• Each wiki may be configured as single-edit-tab or not (see list here)
• On the single-edit-tab wikis, each user can choose to see both tabs (in Preferences → Editing → Editing mode → Show me both editor tabs)

Historical context: When VE was originally written, it always replaced the "Edit" tab with a pair of tabs, which were once labelled "Edit" and "VisualEditor", and now are "Edit source" and "Edit". Around 2016, there was a project to go back to a single "Edit" tab and move the editor switching into the editor interface, and the change was rolled out to some wikis, but it wasn't very warmly received, and many wikis remained with two edit tabs.

Personally, I'm a fan of your pencil-with-eye and pencil-with-brackets icons.

The edit buttons have a very large potential to quickly change editing behaviour on wikis, so I think this is a very important decision. In the past the editing team has been very hesitant to change them due to the feedback we get from the community when we do, but this project gives us a unique opportunity.

Ideally we would test different approaches and their impacts on (1) editing sessions initialised and (2) editing sessions completed successfully (being mindful reverted edits). Instinctively I would agree that labelled buttons would be the clearest and drive the most engagement.

@Pginer-WMF @RHo @iamjessklein @KieranMcCann and myself met today to discuss the edit affordances in the sticky header. Here is a summary of our conversation:

• We prefer using icons over text buttons in the sticky header
• We feel comfortable using the edit pencil icon to both represent editing generically (leading to whatever your preferred editor is), and to represent visual editing in cases where both editor experiences are offered together. We recognize that this communicates that source editing is the secondary mode of editing.
• We feel comfortable using the wikitext icon [[]] to represent the source editor
• We are curious about the decision of some projects to show both editor "tabs" by default. Could we learn more about that, and potentially ask those projects to turn that configuration off? If so it would limit the group of people who see both tabs to people who have explicitly chosen that experience.
• We discussed the opportunity to introduce icons in the article toolbar (to reinforce their meaning), and also discussed how a modified/simplified toolbar might make the editing experience cleaner (i.e. helping to resolve the situation Rita commented about in T289723#7375087)

Our proposal is as follows:

One edit button configuration

article toolbar	sticky header

Two edit button configuration

article toolbar	sticky header

Test wiki created on Patch Demo by CMing (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/2a4d405aff/w/

Change 726678 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[mediawiki/core@master] DNM: config for patchdemo

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

Test wiki created on Patch Demo by CMing (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/3aec0762f2/w/

Test wiki on Patch Demo by CMing (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/2a4d405aff/w/

Change 726694 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/VisualEditor@master] Vector sticky header edit icons should not trigger page load

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

Change 723614 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Add edit icons to sticky header

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

Change 726926 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[mediawiki/skins/Vector@master] Switch order of edit icons in sticky header.

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

Change 726926 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Switch order of edit icons in sticky header.

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

@alexhollender I re-read the T289723#7398039 comment from @Esanders and was just thinking about testing. Is there a plan yet for how this will be tested and evaluated? My primary concern of course is that we don't want this to be disruptive to the editing experience.

cc @ppelberg @Whatamidoing-WMF

In T289723#7428181, @iamjessklein wrote:

@alexhollender I re-read the T289723#7398039 comment from @Esanders and was just thinking about testing. Is there a plan yet for how this will be tested and evaluated? My primary concern of course is that we don't want this to be disruptive to the editing experience.

cc @ppelberg @Whatamidoing-WMF

Yes, all of the features we're releasing are tests so to speak. It would be helpful for us if you all could clarify what data you would like collected, and what would qualify as success/concern there. That will enable us to figure out the right analytics and release strategy.

Test wiki created on Patch Demo by PPelberg (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/48797e0499/w/

In T289723#7436172, @Edtadros wrote:

@cjming , this doesn't work if clicking the edit icon in the sticky header, it only works if clicking the links alongside a section header. Is this what is expected?

hi @Edtadros - can we hop on a quick screenshare to run through? I just tested this on beta cluster and it seems to be working.

To reiterate my comment from before, I think using an un-labelled icon is going to be a big missed opportunity for exposing edit functionality. I would definitely rather label the edit action than the language dropdown.

In T289723#7438694, @Esanders wrote:

To reiterate my comment from before, I think using an un-labelled icon is going to be a big missed opportunity for exposing edit functionality. I would definitely rather label the edit action than the language dropdown.

There's some details on the decision from the design team in T289723#7402822. I believe we will also follow-up with some changes to the tabs themselves later on in the project that improve the recognition between the icons and the text.

In T289723#7402822, @alexhollender wrote:

• We are curious about the decision of some projects to show both editor "tabs" by default. Could we learn more about that, and potentially ask those projects to turn that configuration off? If so it would limit the group of people who see both tabs to people who have explicitly chosen that experience.

One tab is exactly the opposite of what the communities want on the desktop site. Since https://www.mediawiki.org/wiki/VisualEditor/Single_edit_tab started five years ago, every time we have talked to experienced editors about what they want as a default, they have always asked for two tabs. Several communities that were in the Single Edit Tab mode have spontaneously held their own conversations, and every conversation has ended with a request that we set two tabs as the default (examples: T132760, T169741, T181045). Also, "some projects" is "nearly all of them – just not the English Wikipedia".

Two "compromise" positions have been offered. They are: You can have one edit tab if it leads to wikitext source mode only (=the English Wikipedia's choice for logged-out editors), or you can have one edit tab for newbies, but all the Real™ editors need two tabs.

The requests for two tabs were so common in the early days that Editing stopped deploying SET except to wikis with no prior access to the visual editor. These requests were one of the reasons that Editing stopped work on the SET project entirely. Something about having only one editing tab just doesn't work for (experienced) editors.

thanks so much for that context @Whatamidoing-WMF

Test Result - Beta
Status: ✅ PASS
Environment: beta
OS: macOS Big Sur
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

✅ AC3: Test Visual Editor (whether single icon or shown alongside Source Editor)

After discussing with @cjming, the behavior in T289723#7436172 AC3 is the correct behavior.

Test wiki on Patch demo by PPelberg (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/48797e0499/w/

Test wiki on Patch demo by CMing (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/3aec0762f2/w/

Based on feedback in German WP, I think that the current icon for wikitext editing is not clear enough. With the editing pencil loading the VE, the impression is that Vector 2022 automatically enforces VE. I still prefer the combined icons of Minerva desktop …

In T289723#8540326, @XanonymusX wrote:

Based on feedback in German WP, I think that the current icon for wikitext editing is not clear enough. With the editing pencil loading the VE, the impression is that Vector 2022 automatically enforces VE. I still prefer the combined icons of Minerva desktop …

This is helpful to know, @XanonymusX –can you please share a link or links to the feedback at de.wiki you're referring to in the above?

So far it was only one user in this discussion. He tried editing with Vector 2022 and ended up using VE involuntarily. As he is an experienced editor, I wonder how new users would experience it (but Vector 2022 is not yet default on dewiki, so it’s hard to say).