Conduct Edit Cards v3 usertesting.com test
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• ppelberg
	Aug 5 2019, 3:33 PM

Description

This task involves the work involved with running and summarizing the findings of a usertesting.com test of the Edit Cards v3 prototype.

We will also being paying attention to any feedback relevant to the refreshed toolbar, considering v1 is live on the prototype server as well. More information about v1 of mobile VE's refreshed editing toolbar can be found here: T225634.

Test goals

We are seeking to understand how people experience the form-based approach to editing an existing link's label:

At what points was it not clear to contributors what they should do next to complete the task at hand?
Do contributors find the steps for adding and editing links sense to be intuitive? Does everything act in ways contributors expect?
What are contributors’ overall impressions of editing the label of an existing link? What do they think could be improved?

"Done"

Test script is written
Test is run: https://www.usertesting.com/st/hpFS3ENj_yT88Yz_wyvF
Test results are analyzed and findings are summarized posted to this ticket

Related Objects
Search...

Status	Assigned	Task
Open	None	T221247 [Epic] Mobile context items
Resolved	None	T229830 Edit Cards: deploy v3 to all wikis
Resolved	Esanders	T229831 Implement Edit Cards v3
Resolved	• ppelberg	T229832 Conduct Edit Cards v3 usertesting.com test

Event Timeline

• ppelberg created this task.Aug 5 2019, 3:33 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 5 2019, 3:33 PM

• ppelberg added a parent task: T229831: Implement Edit Cards v3.Aug 5 2019, 3:34 PM

• ppelberg updated the task description. (Show Details)Aug 5 2019, 3:42 PM

JTannerWMF added a project: Editing Design.Aug 5 2019, 4:15 PM

• iamjessklein updated the task description. (Show Details)Aug 8 2019, 3:24 PM

I ran the tests on usertesting.com (which is reflected in the ticket description).
Here is a summary of the results:

What flows worked:

adding a link
editing a link
removing a link

What flows can be improved:

editing a link label
adding an external link

Suggested tweaks

provide instructions for adding the link label
provide contextual instructions for users when searching for internal and external links
autofill links with proper http:// or https://
add ⓧ buttons in the form input fields to make text deletion easier

Miscellaneous

distinguishing between read and edit modes remains a struggle
many participants struggled to select the text that they intended to select. Even if they were able to select a word, several found it to be challenging to highlight multiple words at the same time

• iamjessklein closed this task as Resolved.Aug 8 2019, 3:35 PM

• iamjessklein moved this task from 📚 Backlog to 👀 Needs PM Input on the Editing Design board.

• iamjessklein reopened this task as Open.Aug 8 2019, 3:39 PM

• iamjessklein reassigned this task from • iamjessklein to • ppelberg.

• iamjessklein subscribed.

add ⓧ buttons in the form input fields to make text deletion easier

We could switch these to an OOJS-UI SearchInputWidget, probably. Easier for external than internal, because internal uses mw.widgets.TitleSearchWidget and we might need to make sure there wouldn't be any side-effects there.

autofill links with proper http:// or https://

Challenge there is that we don't know which it should be. Defaulting to https if nothing is given would probably work for most cases... but for others we'd be wrong and making a broken link. And technically the http and https versions of a given URL could be entirely separate sites... though that's rare.

many participants struggled to select the text that they intended to select. Even if they were able to select a word, several found it to be challenging to highlight multiple words at the same time

I'm curious whether there was a platform-distinction here?

In T229832#5403007, @DLynch wrote:

autofill links with proper http:// or https://

Challenge there is that we don't know which it should be. Defaulting to https if nothing is given would probably work for most cases... but for others we'd be wrong and making a broken link. And technically the http and https versions of a given URL could be entirely separate sites... though that's rare.

Good spot, David. Here is the ticket where this work is happening: T229839

autofill links with proper http:// or https://

While this has been tracked and something basic implemented, I think this is a result of a slightly unrealistic test, where the user is asked to type out a URL. In the real world the user would likely paste the link.

JTannerWMF moved this task from Incoming to Product owner review on the VisualEditor (Current work) board.Aug 9 2019, 5:26 PM

• Whatamidoing-WMF awarded a token.Aug 12 2019, 4:57 PM

Following up on my earlier suggestion to document things...

We could switch these to an OOJS-UI SearchInputWidget, probably. Easier for external than internal, because internal uses mw.widgets.TitleSearchWidget and we might need to make sure there wouldn't be any side-effects there.

I got a patch merged to OOUI that makes SearchWidget use a SearchInputWidget rather than a TextInputWidget. Mediawiki core's TitleSearchWidget extends SearchWidget, so that means that when the chain of dependency updates finishes going through, our internal-link search is going to have the ⓧ in its input.

Hey @ppelberg this is ready to be closed. @DLynch and @Esanders it looks like you're still commenting on this thread, should the conversation be migrated to an investigation ticket (spike)?

In T229832#5451118, @JTannerWMF wrote:

Hey @ppelberg this is ready to be closed. @DLynch and @Esanders it looks like you're still commenting on this thread, should the conversation be migrated to an investigation ticket (spike)?

Thanks for calling this out @JTannerWMF...linking to tickets where the threads brought up in T229832#5403331 and T229832#5414240 can be talked about further.

In T229832#5403331, @Esanders wrote:

autofill links with proper http:// or https://

While this has been tracked and something basic implemented, I think this is a result of a slightly unrealistic test, where the user is asked to type out a URL. In the real world the user would likely paste the link.

This work mentioned in T229832#5403331 is being tracked in this task: T229839

In T229832#5414240, @DLynch wrote:

Following up on my earlier suggestion to document things...

We could switch these to an OOJS-UI SearchInputWidget, probably. Easier for external than internal, because internal uses mw.widgets.TitleSearchWidget and we might need to make sure there wouldn't be any side-effects there.

I got a patch merged to OOUI that makes SearchWidget use a SearchInputWidget rather than a TextInputWidget. Mediawiki core's TitleSearchWidget extends SearchWidget, so that means that when the chain of dependency updates finishes going through, our internal-link search is going to have the ⓧ in its input.

It sounds like the work discussed in T229832#5414240 is finished and is just waiting on some upstream changes before it can go into effect. Created another task for easier tracking: T231847

The outcomes of our v3 usertesting.com tests have been posted on the Edit Cards project page: https://www.mediawiki.org/w/index.php?title=VisualEditor_on_mobile%2FEdit_cards&type=revision&diff=3392872&oldid=3370950

Conduct Edit Cards v3 usertesting.com testClosed, ResolvedPublicActions