Page MenuHomePhabricator

v3: Implement form-based approach to editing a link's label
Closed, ResolvedPublic

Description

Path forward

Approach #1: Experiment with consolidating the link label and link target into one dialog. See: T229431#5394488

Approach #2: If Approach #1 proves to degrade the experience, we'll keep separate dialogs for editing a link's target and label with the potential of adding additional text to the dialog(s) to give contributors more context. See: T229877

Considerations: link target and label in one dialog

  • On smaller devices (i.e. iPhone 5), when the soft keyboard is up, it's possible there isn't enough room for the label text input field, the link target input field and article search results to all be visible simultaneously.

Event Timeline

ppelberg created this task.Jul 31 2019, 2:53 PM
Restricted Application added a project: VisualEditor. · View Herald TranscriptJul 31 2019, 2:53 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Update
On Monday, 29 July, Ed posted an initial version of the form-based approach to editing a link's label to the prototype server.

See: Edit Cards v3 prototype

Next step(s)

Thanks @Esanders

As you can see in this screenshot, the user has absolutely no instructions or context about what they are supposed to be doing. So, there's a few options:

  1. Add instructional and contextual copy
  1. Add instructional and contextual copy and an in-situ preview
  1. Combine the actions so the link and label can be edited in the same modal.

Which of these options technically feasible?

This is basically the same level of guidance as we provide on the link target page: A title describing the purpose of the form, a single input prefilled with the expected value, and a 'Done' button.

We can combine the inputs onto one form, and this is what David L's original patch did, although it was for desktop. On mobile it is less clear that it's a good idea given than we have limited height when the keyboard is up, and we'd like at least a few autocomplete results to be visible when editing the link target. There will also be confusion about where to put the internal/external tabs.

A few thoughts:

  1. Putting everything in context is a good idea and we can test how confusing it actually is (and combining could potentially reduce unnecessary clicks)
  2. The label will always be maintained so the wiki/external site disambiguation is only relevant to link
  3. Another option is if we don't choose to combine is to think about providing didactic copy in both models for clarity
JTannerWMF moved this task from 📚 Backlog to 📐 Doing on the Editing Design board.

Here's how it looks on the iPhone 5:

ppelberg updated the task description. (Show Details)Aug 5 2019, 11:08 PM

Update: 7-Aug
Outcomes of a conversation with @Esanders and @iamjessklein:

  • In T230045#5400416, Ed discovered it is not possible to have the link label or link target fields in focus, on iOS, when a contributor lands on the link dialog. This would potentially mean that on small devices the link label field, link target field and some amount of article results would all be visible to a contributor upon landing on the link dialog [b/c they wouldn't be blocked by the keyboard].
  • On small devices and even large devices, we're concerned that consolidating label and link target into one view, does not provide contributors enough space to effectively complete their tasks.
  • The resulting question then becomes... "What's better: having link label editing and link target editing in separate workflows? Consolidating the two into one and accepting space limitations?
  • Ed prototyped the the consolidated link dialog so we can better compare that approach to the existing one (link label and link target editing happening in separate dialogs). That prototype can be tested here: http://visualeditor-prototype.wmflabs.org/wiki/Pride_and_Prejudice

Next steps

  • Decide on an approach: consolidate link label and target editing in one dialog or have them exist in separate ones
JTannerWMF added a subscriber: JTannerWMF.

@Esanders please move this to the appropriate column on the current work board

Next steps

  • Decide on an approach: consolidate link label and target editing in one dialog or have them exist in separate ones

We are going to test the consolidated approach to link dialog at Wikimania. That work will be tracked in this task: T230213.

Change 526232 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] [PULL THROUGH] Mobile link label editing

https://gerrit.wikimedia.org/r/526232

Change 303956 had a related patch set uploaded (by Esanders; owner: DLynch):
[VisualEditor/VisualEditor@master] LinkAnnotationInspector: add a "label" field on mobile

https://gerrit.wikimedia.org/r/303956

Change 303956 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] LinkAnnotationInspector: add a "label" field on mobile

https://gerrit.wikimedia.org/r/303956

Change 526232 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (07687721b)

https://gerrit.wikimedia.org/r/526232

Ryasmeen edited projects, added Verified; removed Editing QA.Aug 27 2019, 9:48 PM
Ryasmeen moved this task from QA to Product owner review on the VisualEditor (Current work) board.
ppelberg closed this task as Resolved.Aug 28 2019, 3:47 AM