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 section editing experience by offering people a button that, on scroll, would be revealed offering people the ability to edit the entire article. This task involves the work of building a proof of concept of the experience described below so that we can evaluate the extent to which the assumption that prompted this task holds up in reality or not. === Decision(s) to be made - [ ] Does approach – described in the `Requirements` section below – feel good enough to move forward with refining [i] and ultimately, evaluating through a controlled experiment (T409112)? === Requirements Just the section selected will be loaded, and a "Load entire article" button will appear to allow users to load the rest of the article's section to edit them. Depending on the section selected, there will be the following cases: - **1st section**: when start scrolling, the button will appear fixed at the bottom - **Middle**: when start scrolling, the button will appear at the bottom or on top depending on the scroll direction. - **Last section**: button will appear on top by default, allowing the user to load the previous sections 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) --- 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 //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 on-scroll, would be revealed and offering people the ability to edit the entire article. This task involves the work of building a proof of concept of the experience described below so that we can evaluate the extent to which the assumption that prompted this task holds up in reality or not. === Decision(s) to be made - [ ] Does approach – described in the `Requirements` section below – feel good enough to move forward with refining [i] and ultimately, evaluating through a controlled experiment (T409112)? === Requirements Just the section selected will be loaded, and a "Load entire article" button will appear to allow users to load the rest of the article's section to edit them.//Primary UX// Depending on- Just the section selecteded will be loaded, there will be the following cases: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. - **1st section**: when start scrolling- Depending on the section selected, the buttonthere will appear fixed at the bottombe the following cases: - **Middle-- **1st section**: when startomeone scrollings to the point of reaching the bottom of the lead section, the button will appear at the bottom or on top depending on the scroll direction.{nav Edit full-page} button will be revealed - **Last section**: button will appear on top by default- **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, allowing the user to load the previous sectionsthe {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)