Page MenuHomePhabricator

Sticky header: Add edit icons to sticky header
Open, HighPublic5 Estimated Story Points

Description

Background

In T289716: Create sticky header skeleton we are building the skeleton for the sticky header. This task will cover the beginning of adding distinct functionality to the header, focusing on icons and links. Note: some configuration of these icons will be available. Configuration functionality will be tracked in a different task

Acceptance criteria

Add the following icons and links to the sticky header as per the prototype below:

  • Edit and/or Edit Source: users must see the edit button they currently see at the top of the page. All personal and wiki preferences must be respected
  • When the wikitext editor link is clicked, the wikitext editor should load. This may require changes in how VisualEditor wires up edit buttons.
  • When the VisualEditor link is clicked, the VisualEditor should load. This may require changes in how VisualEditor wires up edit buttons.
  • When there is only ONE editing option to be shown (based on defaults and preferences), the pencil icon for both wikitext + VE is shown.
  • TBD what icons/menu is shown if BOTH editing options are enabled.
  • When the editor loads via JavaScript the sticky header must hide.
  • When the user abandons the edit, the sticky header must reveal itself again.
  • TBD what icons are shown if a page's status is protected for the user (ACs in follow up ticket).

Developer note about edit button

We can inspect the RAW HTML to see what the user's user preferences are relating to this feature. Change it via:

Screen Shot 2021-09-08 at 10.11.46 AM.png (204×1 px, 28 KB)

Prototype

https://di-community-round-2.web.app/Audre_Lorde

QA steps

  • Login to beta cluster https://en.wikipedia.beta.wmflabs.org/wiki/Albert_Einstein
  • Test edit icons in sticky header (they correlate to the edit links, Edit + Edit source, in the views menu tabs i.e. toolbar of tabs in upper right corner above page title):
    • Test both edit icons in sticky header by making sure Preferences are set to "Show me both editor tabs" under the Editing tab in the Editing mode section
      • When both edit icons are available and either are clicked, sticky header should not appear in either mode.
      • Both pencil icon + wikitext icon (looks like double brackets i.e. [[ ]] ) should link to VE mode and source editing mode respectively.
    • Test single edit icon in sticky header by choosing only Visual Editor, then Source Editor in Preferences under Editing tab under Editing mode.
      • Both should have same pencil icon but different link urls going to their respective editing modes.
    • Test Visual Editor (whether single icon or shown alongside Source Editor)
      • Launch VE, make a change, save edit.
        • If editing at the top of the page, sticky header should reappear after scrolling past page title.
        • If editing at the bottom of a long page, sticky header should reappear when notification alert dialog appears or right after notification disappears
      • Launch VE, don't make a change or save, click the "Read" tab in the views menu tabs (above page title to the upper right)
        • Sticky header should reappear when VE launches, no change is made, user switches back to view mode, and scrolls down past page title.
    • Test Source Editor (whether single icon or show alongside Visual Editor)
      • Sticky header should not appear
  • Test protected pages (not sure how to protect a page on beta cluster - TBD)
    • Once a page has protected status, the edit icon in sticky header should look like a pencil with a lock and navigate to viewing the source

QA Results - Beta

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson renamed this task from Sticky header: Build icon functionality for sticky header to Sticky header: Add edit, talk and history icons to sticky header.Sep 8 2021, 5:14 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson renamed this task from Sticky header: Add edit, talk and history icons to sticky header to Sticky header: Add edit icons to sticky header.Sep 8 2021, 5:19 PM
Jdlrobson updated the task description. (Show Details)
ovasileva renamed this task from Sticky header: Add edit icons to sticky header to Sticky header: Add edit and history icons to sticky header.Sep 8 2021, 8:12 PM
ovasileva renamed this task from Sticky header: Add edit and history icons to sticky header to Sticky header: Add edit icons to sticky header.
Jdlrobson updated the task description. (Show Details)

Alex could you take a look at the acceptance criteria and see if anything relating to behavior is missing? Could you also clarify which icons to use per our conversation earlier.

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

image.png (612×898 px, 81 KB)

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

image.png (762×3 px, 618 KB)

in Minerva we do the following:

image.png (388×1 px, 84 KB)

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

image.png (762×3 px, 619 KB)

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

image.png (924×3 px, 831 KB)


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.

image.png (608×2 px, 210 KB)

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.

LGoto set the point value for this task to 5.

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)

[...]
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):

image.png (924×3 px, 831 KB)

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

image.png (388×1 px, 85 KB)


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.

image.png (608×2 px, 210 KB)

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.

[...]

image.png (924×3 px, 831 KB)

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:

image.png (1×1 px, 259 KB)
or in new vector
image.png (646×2 px, 393 KB)

@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 toolbarsticky header
1. one Edit button that leads to VE
image.png (592×2 px, 354 KB)
image.png (488×2 px, 466 KB)
2. one Edit button that leads to wikitext editor
image.png (592×2 px, 359 KB)
image.png (488×2 px, 433 KB)
3. two buttons: Edit and Edit source
image.png (610×2 px, 387 KB)
image.png (488×2 px, 466 KB)

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
      image.png (628×2 px, 550 KB)
    • with text labels for editor choices
      Screen Shot 2021-09-23 at 2.20.34 PM.png (192×1 px, 122 KB)

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:

image.png (1×2 px, 805 KB)
image.png (1×2 px, 867 KB)
image.png (1×2 px, 804 KB)
image.png (1×2 px, 818 KB)

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
image.png (278×664 px, 26 KB)
article toolbar
image.png (722×2 px, 287 KB)
editor
image.png (448×754 px, 31 KB)
sticky header
image.png (762×3 px, 596 KB)

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.

cjming added a subscriber: cjming.

@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:

image.png (1×2 px, 805 KB)
image.png (1×2 px, 867 KB)
image.png (1×2 px, 804 KB)
image.png (1×2 px, 818 KB)

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
image.png (278×664 px, 26 KB)
article toolbar
image.png (722×2 px, 287 KB)
editor
image.png (448×754 px, 31 KB)
sticky header
image.png (762×3 px, 596 KB)

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:

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 toolbarsticky header
image.png (722×2 px, 320 KB)
image.png (722×2 px, 803 KB)
Two edit button configuration
article toolbarsticky header
image.png (722×2 px, 322 KB)
image.png (722×2 px, 804 KB)

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

cjming updated the task description. (Show Details)

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

@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/

Edtadros added a subscriber: Edtadros.

Test Result - Beta

Status:
Environment: beta
OS: macOS Big Sur
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

✅ AC1: Test both edit icons in sticky header by making sure Preferences are set to "Show me both editor tabs" under the Editing tab in the Editing mode section

  • When both edit icons are available and either are clicked, sticky header should not appear in either mode.
  • Both pencil icon + wikitext icon (looks like double brackets i.e. [[ ]] ) should link to VE mode and source editing mode respectively.
Screen Recording 2021-10-14 at 7.02.11 AM.mov.gif (926×1 px, 2 MB)
Screen Recording 2021-10-14 at 7.02.39 AM.mov.gif (926×1 px, 3 MB)

✅ AC2: Test single edit icon in sticky header by choosing only Visual Editor, then Source Editor in Preferences under Editing tab under Editing mode.

  • Both should have same pencil icon but different link urls going to their respective editing modes.
Visual EditorSource Editor
Screen Recording 2021-10-16 at 9.33.35 AM.mov.gif (808×856 px, 1 MB)
Screen Recording 2021-10-16 at 9.34.24 AM.mov.gif (808×856 px, 1 MB)

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

  • Launch VE, make a change, save edit.
    • If editing at the top of the page, sticky header should reappear after scrolling past page title.

Screen Recording 2021-10-16 at 9.40.03 AM.mov.gif (808×856 px, 2 MB)

  • If editing at the bottom of a long page, sticky header should reappear when notification alert dialog appears or right after notification disappears

Screen Recording 2021-10-16 at 9.42.08 AM.mov.gif (808×856 px, 710 KB)

  • Launch VE, don't make a change or save, click the "Read" tab in the views menu tabs (above page title to the upper right)
    • Sticky header should reappear when VE launches, no change is made, user switches back to view mode, and scrolls down past page title.

NOTE: @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?

Screen Recording 2021-10-16 at 9.49.28 AM.mov.gif (808×856 px, 2 MB)

Screen Recording 2021-10-16 at 9.52.20 AM.mov.gif (808×856 px, 1 MB)

✅ AC4: Test Source Editor (whether single icon or show alongside Visual Editor)

  • Sticky header should not appear

Screen Recording 2021-10-16 at 9.53.12 AM.mov.gif (808×856 px, 1 MB)

✅ AC5: Test protected pages

  • Once a page has protected status, the edit icon in sticky header should look like a pencil with a lock and navigate to viewing the source

Screen Recording 2021-10-16 at 9.55.13 AM.mov.gif (808×856 px, 1 MB)

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

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.

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