Page MenuHomePhabricator

Conduct Edit Cards v3 usertesting.com test
Closed, ResolvedPublic

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"

Event Timeline

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 reassigned this task from iamjessklein to ppelberg.
iamjessklein added a subscriber: iamjessklein.

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?

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.

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.

JTannerWMF added a subscriber: JTannerWMF.

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)?

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.

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

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