Change Details

**Design:** @iamjessklein **Design Review:** @alexhollender **Engineer Review:** @Esanders **Product Review:** @ppelberg **Open questions** - [ ] Should we present the context item, or some version of it, after the contributor leaves the link inspector view? - [ ] How does the context item get affected after a contributor taps "unlink"? - [ ] What do we show when the cursor is initially placed in a link, as we don't want to hide the keyboard immediately? And more broadly, what are the range of actions the expose the context item? Source: [T204733](https://phabricator.wikimedia.org/T204733#5078762) - [ ]I n the case of a contributor attempting to add a new link is it reasonable to pursue a flow like the one [described here](https://phabricator.wikimedia.org/T220385#5185867)? --- **Success criteria:** - Mockup sufficiently provides a solution to the problem of managing a users ability to maintain focus within an edit - Engineering can use the mockups to implement the solution --- **Why are we doing this?** So we can look for edge cases and ensure that we've accounted for when the keyboard is up and down **User Story:** As a Reactive Corrector on the mobile web, I would like to add a link to a webpage into an existing Wikipedia article. **Mockups:** https://wikimedia.invisionapp.com/freehand/document/s1duRw6io

**Design:** @iamjessklein **Design Review:** @nirzar **Engineer Review:** @Esanders **Product Review:** @ppelberg **Open questions** - [ ] Should we present the context item, or some version of it, after the contributor leaves the link inspector view? - [ ] How does the context item get affected after a contributor taps "unlink"? - [ ] What do we show when the cursor is initially placed in a link, as we don't want to hide the keyboard immediately? And more broadly, what are the range of actions the expose the context item? Source: [T204733](https://phabricator.wikimedia.org/T204733#5078762) - [ ]I n the case of a contributor attempting to add a new link is it reasonable to pursue a flow like the one [described here](https://phabricator.wikimedia.org/T220385#5185867)? --- **Success criteria:** - Mockup sufficiently provides a solution to the problem of managing a users ability to maintain focus within an edit - Engineering can use the mockups to implement the solution --- **Why are we doing this?** So we can look for edge cases and ensure that we've accounted for when the keyboard is up and down **User Story:** As a Reactive Corrector on the mobile web, I would like to add a link to a webpage into an existing Wikipedia article. **Mockups:** https://wikimedia.invisionapp.com/freehand/document/s1duRw6io

**Design:** @iamjessklein **Design Review:** @alexhollender nirzar **Engineer Review:** @Esanders **Product Review:** @ppelberg **Open questions** - [ ] Should we present the context item, or some version of it, after the contributor leaves the link inspector view? - [ ] How does the context item get affected after a contributor taps "unlink"? - [ ] What do we show when the cursor is initially placed in a link, as we don't want to hide the keyboard immediately? And more broadly, what are the range of actions the expose the context item? Source: [T204733](https://phabricator.wikimedia.org/T204733#5078762) - [ ]I n the case of a contributor attempting to add a new link is it reasonable to pursue a flow like the one [described here](https://phabricator.wikimedia.org/T220385#5185867)? --- **Success criteria:** - Mockup sufficiently provides a solution to the problem of managing a users ability to maintain focus within an edit - Engineering can use the mockups to implement the solution --- **Why are we doing this?** So we can look for edge cases and ensure that we've accounted for when the keyboard is up and down **User Story:** As a Reactive Corrector on the mobile web, I would like to add a link to a webpage into an existing Wikipedia article. **Mockups:** https://wikimedia.invisionapp.com/freehand/document/s1duRw6io