I updated Invision with the latest wireframes (not final UI) - provide anecdotal/nitpicky feedback there and high-level feedback here.

cc/ @Esanders @ppelberg

Looking good, @iamjessklein.

High level

• Do you think it's necessary to show the context item after contributors finish with their linking task?
  • IMO, it's not necessary to show the context item after the link inspector in any case [1] considering it'd take one tap for contributors to reveal it. I also wonder whether presenting the context item a second time makes the linking actions feel heavier than they need to.
• What do you think consolidating the the internal and external link searching within the link inspector would look like?
  • @Esanders raised this already (see T222082) and you've already started thinking about what this might look like. I'm mentioning here to link these different threads.
• Automated text in edit summary: how is this being populated?
  • Would I be correct to assume this would be something we'd have to build considering T54859 is open? cc @Esanders

Minor details

Added to Invision wireframes freehand

1. Any case: Adding a new link, modifying an existing link's target, modifying an existing link's label

6-May outcomes

@Esanders, @iamjessklein and I talked about the wireframes.

Decided/next steps

• Link inspector
  • Leave the "Internal" and "External" tabs as a separate for now (them being so is intended to discourage external linking)
  • We'll still refresh UI of the view
  • If we're going to have the "Internal" link tab heading read "Wikipedia" or something else context-specific, we will need to define a "sensible default" for use on other projects and third party wikis where the site name might not be set
• Context item
  • We're going to get rid of "Cancel" and "Done" actions in favor of something meaning "Close"

Open

• Should we present the context item, or some version of it, after the contributor leaves the link inspector view? added to task description
• How does the context item get affected after a contributor taps "unlink"? added to task description

Edit: Added questions raised in T204733 to this ticket's description so all open questions related to wireframes are in one place.

13-May

Discussed

• This progression is potentially confusing: "✓" > "Publish..." > ("Save your changes") > "Publish"
  • In the time between now and when we've revised the toolbar (see T211255), let's experiment with one of the following:
    1. "✓" > "Continue" > ("Save your changes") > "Publish" or
    2. "✓" > "Next" > ("Save your changes") > "Publish" <--- the mobile wikitext editor follows this pattern
       
• Icons we'd need to represent should we pursue a unified toolbar. See: T211255#5185846

Open

• In the case of a contributor attempting to add a new link, can we assume, based on the text they've highlighted, that they're a) wanting to make an intrawiki link and b) what article they are attempting to link to the text they've highlighted? If we feel comfortable making this assumption, this would enable us to pursue a flow like the below (added to task description)
  1. Contributor highlights text
  2. Contributor taps "🔗" in toolbar
  3. Context item is shown, link target is automatically made to the first search result (the highlighted text becomes the search terms)

This post is mainly for documentation. Currently, we have the experience prototyped in a clickable prototype and have a script written for it that @Esanders tested at the May 2019 Prague hackathon.

Moving to "blocked" until we document feedback and steps for our next iteration (planned for later this week)

Notes from today's CR <> Product meeting

Meta

• Is there an opportunity to make it more clear that you're linking to a Wikipedia article
• Needs to be a clear workflow to create a red link (signal to others that a new page should be created)

Add a link

• Assumed link had been made to "Pencil" upon tapping 🔗; not clear needed to go into link inspector to complete action
• Why am I being dropped back into - what looks like – the same Edit card view despite just having done something (linking "pencil" to w/Pencil)? (Talk about w/ Jess)
• "X" is confusing; feels like it should be more of a "done"
• "W/Pencil" leads people to think it's a sub-page; action: "/" suggest hierarchy

Edit the link's label

• After changing link label, assumes link target has changed
  • Expecting to see the Edit card to confirm label text is changed, but target remain has unchanged.
  • If we pull out the edit link label into its own view, lost context about the link's target
• How do we visually communicate that the link label has been changed within the doc? (clean up language)

External link

• Not clear you're required to tap the link embed to "finish"

Update | 21-May

There are a few questions blocking us from moving forward. This task's description has been updated to include the following questions:

• What do we show when someone taps an existing link?
• If we show the Edit card whenever a contributor taps an existing link (read: we don’t put the cursor inside the link), how will a contributor edit the link's label? Current thinking: tap "Edit" within the edit card. Idea: double tap to bypass the Edit card and show the keyboard.
  • What if any additional information do we show about the link’s properties? (this assumes the shelf is gone)

Next steps

• @iamjessklein is going to think through a potential implementations for: If we show the Edit card whenever a contributor taps an existing link (read: we don’t put the cursor inside the link), how will a contributor edit the link's label?

^ See presentation: existing links

Update | 22-May

In T220385#5202086, @ppelberg wrote:

Update | 21-May

There are a few questions blocking us from moving forward. This task's description has been updated to include the following questions:

• What do we show when someone taps an existing link?

Next steps

• To address the above, @iamjessklein is going to create and test an Invision prototype of version B (showing the edit card whenever a contributor taps a link) on usertesting.com in order to figure out how – if at all – disruptive the edit card interaction [1] is to contributors seeking to edit a link's label.

The primary goals of this prototype are to gain insights on the following aspects of features within the Editing interface:
editing and links deleting links. We want to answer the following questions:

• Are users able to successfully turn text into a link?
• Are users able to successfully access the link-editor frustration-free?
• Are users able to successfully edit an existing link?
• Are users able to successfully remove a link?

At the moment, I'm planning on creating a lower fidelity prototype than the initial one done in Invision as the fidelity did not match the level of confidence in the prototype. I also hope that this will help testers to feel comfortable providing feedback.

Here is the sketch for "Version B" that @ppelberg referenced:

Note that in addition to all of the actions described here we would like to test a short cut into label editing through a double tap.

Update | 29-May

• The work involved with the usability test mentioned above is now represented here: T224520
• Further design and development work depends on the results of this test. Reason: the test will resolve our key open questions. These "key open questions" are listed below. They are also represented in the "Blocked by" section of the task description:
  • What do we show when the cursor is initially placed in/on an existing link? And more broadly, what are the range of actions the expose the context item? Source: T204733; more details in T220385#5202086
  • If we don’t put the cursor inside an existing link, how would a contributor edit the link’s label?

Feedback

@deryckchan was able to tap around the prototype and had a few comments to share (below).

Edit card feedback

• Deryck did not see anything within the prototypes that caused him concern. Although, he did mention that it's hard to say for certain whether his perspective would change after using a fully functional version.

• Deryck did not bring up anything unprompted about the "editing a link label" flow, but when asked...he expressed a preference for editing the link label inside a form (what we are proposing here T220385#5207030).
  • Reason: he can see this approach being helpful for contributors editing in Cantonese, Classical Chinese or Japanese where link labels can be single characters. Single character link labels mean there is less room/a smaller "opportunity" to place the cursor correctly. Less room to place the cursor means contributors need to be more precise. More precise = more difficult.

Considering the back and forth I propose that we close this and work directly on the prototype T221309.
To push this forward, I am going to remove the editing-design tag

cc/ @JTannerWMF @ppelberg

In T220385#5249649, @iamjessklein wrote:

Considering the back and forth I propose that we close this and work directly on the prototype T221309.

Good suggestion, @iamjessklein. Closing this ticket and adding the following to resolve our "Blocking questions".

I'm also transferring the remaining "Open questions" to the task description of T221309.

Blocking questions

• What do we show when the cursor is initially placed in/on an existing link? And more broadly, what are the range of actions the expose the context item? Source: T204733; more details in T220385#5202086

For this first iteration, we decided the Edit card/context item will show whenever a contributor taps an existing link. We will see what contributors think of this implementation and revise if necessary.

• If we don’t put the cursor inside an existing link, how would a contributor edit the link’s label?

Moot. See above. For context, to edit a link label in this first iteration, contributors will tap "Change label" in the edit card.