Change Details

During the 12 November "Needs Discussion" meeting, the Editing Team aligned on assuming the simplest and most effective way to address the "section editing dead-end" issue would be to do the following... Augment the existing mobile section editing experience by offering people a button that, on-scroll, would be revealed and offer people the ability to edit the entire article. === Requirements //Primary UX// - Just the section selected will be loaded, and a {nav Edit full-page} (exact copy TBD) button will appear to allow users to load the rest of the article's sections in an editable state. - Depending on the section selected, there will be the following cases: -- **1st section**: when someone scrolls to the point of reaching the bottom of the lead section, the {nav Edit full-page} button will be revealed -- **Middle section**: when someone scrolls to the point of reaching the bottom //or// top of the section, the {nav Edit full-page} button will be revealed. --- //Note: the button's location will depend on what direction someone is scrolling in.// -- **Last section**: when someone scrolls to the point of reaching the top of the last section, the {nav Edit full-page} button will be revealed //Edge cases// - Short section in a long article: The button will be displayed by default. //Read: the button appearing will NOT depend on someone scrolling.// - Extra short article: In very short articles (when HTML is less than 20K), the entire article will be loaded and the "Load entire article" button will NOT be displayed. |Mockups |{F70215268} [Figma](https://www.figma.com/design/oj31GiaHi7EZIQ04Zfesbi/T387175---Full-page-editing-on-mobile?node-id=183-16649&t=jrzsseetgGisJd5N-11) //Visual diffs// - Ensure no dirty diffs are introduced as a result of people potentially switching between section- and full-page editing mid-edit on mobile. === Proof of concept https://80a3b29990.catalyst.wmcloud.org/wiki/Douglas_Adams#/editor/0 === Open questions - [ ] 1. How will we make the button visible when the keyboard is up? - [ ] 2. What will the button copy say? - [ ] 3. How will the button visually appear? -- [Offline](https://wikimedia.slack.com/archives/GRR5LM0MS/p1763119478481069?thread_ts=1761739157.490499&cid=GRR5LM0MS), @bmartinezcalvo prposed... --- Use a `large button` instead (44 px) --- Use a white gradient between the button and the page's content so the button is visible while scrolling. --- Once you complete scroll, the button can be at the end of the scroll without gradient. --- i. Where "refining" here could refer to things like: 1) showing 1-2 lines of text from the previous (or proceeding) section behind the button that would enable people to edit it, 2) polishing the animation that appears when the content people are attempting to edit is not yet loaded (T409131)

During the 12 November "Needs Discussion" meeting, the Editing Team aligned on assuming the simplest and most effective way to address the "section editing dead-end" issue would be to do the following... Augment the existing mobile section editing experience by offering people a button that, on-scroll, would be revealed and offer people the ability to edit the entire article. === Requirements //Primary UX// - Just the section selected will be loaded, and a {nav Edit full-page} (exact copy TBD) button will appear to allow users to load the rest of the article's sections in an editable state. - Depending on the section selected, there will be the following cases: -- **1st section**: when someone scrolls to the point of reaching the bottom of the lead section, the {nav Edit full-page} button will be revealed -- **Middle section**: when someone scrolls to the point of reaching the bottom //or// top of the section, the {nav Edit full-page} button will be revealed. -- **Last section**: when someone scrolls to the point of reaching the top of the last section, the {nav Edit full-page} button will be revealed | {F70292215} | {F70292226} | {F70292229} | | First section | Middle section | Last section | //Visual styles// - Normal Neutral Button - box-shadow-medium - White gradient: linear-gradient(180deg, rgba(255, 255, 255, 0.32) 0%, #FEFEFE 108.8%) - Fake skeleton - 3-4 lines of fake skeleton - 20px height each skeleton line - 4px padding between skeleton lines - @background-color-interactive | {F70292279} | {F70292281} | | Bottom button | Top button | //Edge cases// - Short section in a long article: - First section: The button will be displayed by default beneath - Middle section: The button will be displayed by default beneath, and the button will appear above if the user scrolls up. - Last section: the button will appear above if the user scrolls up. - Extra short article: In very short articles (when HTML is less than 20K), the entire article will be loaded and the "Load entire article" button will NOT be displayed. //Visual diffs// - Ensure no dirty diffs are introduced as a result of people potentially switching between section- and full-page editing mid-edit on mobile. //Copy// - We will run a usability testing to decide one of these copies: - Edit full page - Load full page - Switch to full page === Proof of concept https://80a3b29990.catalyst.wmcloud.org/wiki/Douglas_Adams#/editor/0 === Open questions - [x] 1. How will we make the button visible when the keyboard is up? - At present, buttons are presented within the document, so there will be no issues with the keyboard - [x] 2. What will the button copy say? - [x] 3. How will the button visually appear? --- i. Where "refining" here could refer to things like: 1) showing 1-2 lines of text from the previous (or proceeding) section behind the button that would enable people to edit it, 2) polishing the animation that appears when the content people are attempting to edit is not yet loaded (T409131)

During the 12 November "Needs Discussion" meeting, the Editing Team aligned on assuming the simplest and most effective way to address the "section editing dead-end" issue would be to do the following... Augment the existing mobile section editing experience by offering people a button that, on-scroll, would be revealed and offer people the ability to edit the entire article. === Requirements //Primary UX// - Just the section selected will be loaded, and a {nav Edit full-page} (exact copy TBD) button will appear to allow users to load the rest of the article's sections in an editable state. - Depending on the section selected, there will be the following cases: -- **1st section**: when someone scrolls to the point of reaching the bottom of the lead section, the {nav Edit full-page} button will be revealed -- **Middle section**: when someone scrolls to the point of reaching the bottom //or// top of the section, the {nav Edit full-page} button will be revealed. --- //Note: the button's location will depend on what direction someone is scrolling in.// -- **Last section**: when someone scrolls to the point of reaching the top of the last section, the {nav Edit full-page} button will be revealed | {F70292215} | {F70292226} | {F70292229} | | First section | Middle section | Last section | //Visual styles// - Normal Neutral Button - box-shadow-medium - White gradient: linear-gradient(180deg, rgba(255, 255, 255, 0.32) 0%, #FEFEFE 108.8%) - Fake skeleton - 3-4 lines of fake skeleton - 20px height each skeleton line - 4px padding between skeleton lines - @background-color-interactive | {F70292279} | {F70292281} | | Bottom button | Top button | //Edge cases// - Short section in a long article: - First section: The button will be displayed by default. //Read: the button appearing will NOT depend on someone scrolling.// beneath - Extra short article: In very short articles (when HTML is less than 20K) - Middle section: The button will be displayed by default beneath, the entire articleand the button will be loaded and the "Load entire article" button will NOT be displayedappear above if the user scrolls up. |Mockups - Last section: the button will appear above if the user scrolls up. |{F70215268} [Figma](https://www.figma.com/design/oj31GiaHi7EZIQ04Zfesbi/T387175---Full-page-editing-on-mobile?node-id=183-16649&t=jrzsseetgGisJd5N-11)- Extra short article: In very short articles (when HTML is less than 20K), the entire article will be loaded and the "Load entire article" button will NOT be displayed. //Visual diffs// - Ensure no dirty diffs are introduced as a result of people potentially switching between section- and full-page editing mid-edit on mobile. //Copy// - We will run a usability testing to decide one of these copies: - Edit full page - Load full page - Switch to full page === Proof of concept https://80a3b29990.catalyst.wmcloud.org/wiki/Douglas_Adams#/editor/0 === Open questions - [ ] 1- [x] 1. How will we make the button visible when the keyboard is up? - [ ] 2. What will the button copy say? - [ ] 3. How will the button visually appear? -- [Offline](https://wikimedia.slack.com/archives/GRR5LM0MS/p1763119478481069?thread_ts=1761739157.490499&cid=GRR5LM0MS), @bmartinezcalvo prposed... --- Use a `large button` instead (44 px) - At present, buttons are presented within the document, so there will be no issues with the keyboard --- Use a white gradient between- [x] 2. What will the button and the page's content so the button is visible while scrolling.n copy say? --- Once you complete scroll,- [x] 3. the button can be atHow will the end of the scroll without gradient.button visually appear? --- i. Where "refining" here could refer to things like: 1) showing 1-2 lines of text from the previous (or proceeding) section behind the button that would enable people to edit it, 2) polishing the animation that appears when the content people are attempting to edit is not yet loaded (T409131)