Page MenuHomePhabricator

Add an image: minimal caption validation
Closed, ResolvedPublic

Description

In Iteration 1, we will not have sophisticated validation of captions. That is described in T292888: Add an image: caption validation (PLACEHOLDER). This is a simple minimum version.

  • When the user first arrives on the caption step, the publish button is not active, and no warning message is present.
  • Then the user starts entering a caption. Once they get to five characters, the publish button becomes active. If they delete characters and go below five characters, then it goes inactive again.
  • If they do anything that brings their focus outside the caption box, like opening image details, opening the caption onboarding, or tapping the inactive publish button, this triggers the red warning text. Exception: T295911: Add an image: always show the placeholder text when there's no input
  • Once the red warning text has been triggered, it then displays whenever there are fewer than five characters in the box, until the user leaves this step.
  • The text starts with a "stop sign" icon, and reads, "Captions must be 5 characters or longer."

Mockup as of 2021-10-29:

image.png (681×624 px, 368 KB)

Figma: https://www.figma.com/file/ULhJr1isDstRbGE5vjYDsr/Add-images-structured-task?node-id=3050%3A9628

Event Timeline

MMiller_WMF renamed this task from Add an image: minimal caption validation to Add an image: minimal caption validation (PLACEHOLDER).Oct 13 2021, 1:40 AM
MMiller_WMF created this task.

@RHo -- what is your preferred experience with the red warning text that will appear under the caption box? Is it like this:

  1. User arrives on page with empty caption box. No red text.
  2. User types first character. Red text appears. Publish button stays gray.
  3. User types sixth character. Red text disappears. Publish button turns blue.

It might be annoying for the warning text to flash every time the user is at the beginning of typing their caption. How should this work? Should there be a delay before it appears? Or should it not appear until they try to press publish?

@RHo -- what is your preferred experience with the red warning text that will appear under the caption box? Is it like this:

  1. User arrives on page with empty caption box. No red text.
  2. User types first character. Red text appears. Publish button stays gray.
  3. User types sixth character. Red text disappears. Publish button turns blue.

It might be annoying for the warning text to flash every time the user is at the beginning of typing their caption. How should this work? Should there be a delay before it appears? Or should it not appear until they try to press publish?

Thanks @MMiller_WMF, good catch . It would be very annoying to to users to get a validation before they've had the opportunity to add anything to the caption, esp. as we are planning to focus on it after the page loads. With that in mind, I propose that validation only happens:

  1. After there is some input into the field (detecting an onChange event), and
  2. Until the user goes to submit or otherwise taps outside of the text field so it loses focus (I think this is called an onBlur event?).

If number 2 is not possible, then the option would be to add a delay of 1s after there is input before validation kicks in.

Showing warnings on blur is very common for web forms, but in this case, there isn't really any place for focus to move to - there are no other form fields, and the submit button is disabled.

Showing warnings on blur is very common for web forms, but in this case, there isn't really any place for focus to move to - there are no other form fields, and the submit button is disabled.

I was thinking this would be useful to show for when someone taps out of the form to view image details or read the article, as well as if they try to continue by tapping on the disabled submit button. My inclination is to not show this particular minimum text validation too sensitively, as this would be annoying for someone who is just taking their time to craft the caption. But perhaps this is fine if we set the check to be delayed 1s on change?

More specifically, I think the most common behavior is:

  • initially, let the user type and only validate on blur / submit;
  • once the form field has been in an error state, validate immediately on change.

We could do that here and apply the same logic to the submit button; then, it would start out as active, and once the user clicks on it, it would go inactive and the caption UI would switch to error state. Not sure how natural that would feel.

{{citation needed}} but I don't think you can change focus by tapping on a disabled button.

More specifically, I think the most common behavior is:

  • initially, let the user type and only validate on blur / submit;
  • once the form field has been in an error state, validate immediately on change.

We could do that here and apply the same logic to the submit button; then, it would start out as active, and once the user clicks on it, it would go inactive and the caption UI would switch to error state. Not sure how natural that would feel.

Besides as you say the switching of enabled to disabled state being a bit unnatural, it's more important in my view to have the button start off as disabled as a signal that this is not an optional step.

{{citation needed}} but I don't think you can change focus by tapping on a disabled button.

Is it possible to add a click outside detector to detect for this? Something I read about from https://css-tricks.com/click-outside-detector/

If this is *not* possible, my proposal would be a slight tweak from @Tgr's specification:

  • initially, let the user type and validate after 2s delay (thinking that this would be more ample time to allow someone to type 5 characters);
  • once the form field has been in an error state, validate immediately on change.

@RHo @Tgr -- let me re-digest this to see if it sounds right:

  • Initially, let the user type and validate after 2s delay. The 2s starts over after each keystroke. In other words, if they take 1.5 seconds to type each character, and therefore take 7.5 seconds to type "Photo", they would not see the warning message at any point.
  • Once the form field has been in an error state, validate immediately on change.
  • The publish button should not be enabled until there are five characters in the box. If the user has typed in five characters, but starts deleting them, the button goes back to disabled.

Is this right?

And @RHo, I just want to make sure you don't want to do this simpler version instead:

  • Publish button is always enabled.
  • If the user taps it when they have fewer than five characters, they do not progress. Instead, the warning shows up until they have more than five characters.

@RHo @Tgr -- let me re-digest this to see if it sounds right:

  • Initially, let the user type and validate after 2s delay. The 2s starts over after each keystroke. In other words, if they take 1.5 seconds to type each character, and therefore take 7.5 seconds to type "Photo", they would not see the warning message at any point.
  • Once the form field has been in an error state, validate immediately on change.
  • The publish button should not be enabled until there are five characters in the box. If the user has typed in five characters, but starts deleting them, the button goes back to disabled.

Is this right?

Yes, but only if it is definitely not possible or easy to detect a tap outside of the text field (which would include someone trying to tap on a disabled button). This would be the preferred initial trigger for validation:

{{citation needed}} but I don't think you can change focus by tapping on a disabled button.

Is it possible to add a click outside detector to detect for this? Something I read about from https://css-tricks.com/click-outside-detector/

And @RHo, I just want to make sure you don't want to do this simpler version instead:

  • Publish button is always enabled.
  • If the user taps it when they have fewer than five characters, they do not progress. Instead, the warning shows up until they have more than five characters.

I agree this would be better than having the button changing from enabled to disabled and back again, but still don't love the button being enabled. So I suppose the order of preference is firstly if we can validate on lost focus, secondly the 2s delay, and third would be this proposal for always enabled button and validate on submit.

Is it possible to add a click outside detector to detect for this? Something I read about from https://css-tricks.com/click-outside-detector/

Yeah, we can detect click events on the button, or anywhere not in the form. It's just more likely to result in surprises on some device, compared to relying on native browser focus mechanics.
I suppose we can just use the click handler to validate when the user clicks on the button, without involving focus in any way in that case.

MMiller_WMF renamed this task from Add an image: minimal caption validation (PLACEHOLDER) to Add an image: minimal caption validation.Oct 29 2021, 11:21 PM
MMiller_WMF updated the task description. (Show Details)

@RHo @Tgr -- I went back through the comments because I think we settled on a set of rules. Could you please review the task description to make sure it's right?

Hi @RHo — I have a few clarifications:

  • I just realized that the Figma spec currently doesn't have the state of the caption box when the input is valid so I wanted to confirm the box color. At which point does the box color change to white (when the warning is shown or right when the user enters something)?

No input

Screen Shot 2021-11-08 at 1.08.02 PM.png (158×600 px, 33 KB)

Invalid input

Screen Shot 2021-11-08 at 1.08.08 PM.png (244×606 px, 29 KB)

Valid input
?

  • The current copy for the warning spells out "five". Would it be ok if this were "5" instead? This will make it possible to configure the minimum character length (we don't have a way to specify that the numeric parameter should be spelled out).

Change 737754 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] Add an image: caption length validation

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

RHo updated the task description. (Show Details)

Hi @RHo — I have a few clarifications:

  • I just realized that the Figma spec currently doesn't have the state of the caption box when the input is valid so I wanted to confirm the box color. At which point does the box color change to white (when the warning is shown or right when the user enters something)?

No input

Screen Shot 2021-11-08 at 1.08.02 PM.png (158×600 px, 33 KB)

Invalid input
Screen Shot 2021-11-08 at 1.08.08 PM.png (244×606 px, 29 KB)

Valid input

Apologies I wanted to use the standard OOUI textbox style for the valid input – just added to the figma here and also screenshotted below:

image.png (784×720 px, 397 KB)

  • The current copy for the warning spells out "five". Would it be ok if this were "5" instead? This will make it possible to configure the minimum character length (we don't have a way to specify that the numeric parameter should be spelled out).

Ahh I missed this in the spreadsheet, but have updated it on task and everywhere now to Captions must be 5 characters or longer.

Change 737754 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add an image: caption length validation

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

@mewoph - ack sorry I realised I didn't change the text input colour on valid text to be Base10 instead, sorry it should be this:

image.png (784×720 px, 397 KB)

Change 738480 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] Add an image: Update text color for caption field

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

Thanks @RHo, the text color has been updated in the latest patch.

Change 738480 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add an image: Update text color for caption field

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

For @RHo quick review.

  • all works as expected
  • the valid input is of Base10

Note: it's kind of a grammar norm in English to write out the numbers from 1 to 10. Should 5 be spelled out as five or it'd be forcing translators to use the word "five" which might not be the norm in other languages?

Screen Shot 2021-11-15 at 3.28.11 PM.png (1×760 px, 493 KB)

For @RHo quick review.

  • all works as expected
  • the valid input is of Base10

Note: it's kind of a grammar norm in English to write out the numbers from 1 to 10. Should 5 be spelled out as five or it'd be forcing translators to use the word "five" which might not be the norm in other languages?

Screen Shot 2021-11-15 at 3.28.11 PM.png (1×760 px, 493 KB)

Oh that sounds like another good reason to keep as the numeric 5 instead of five! But actually @mewoph asked for the change on T293161#7490916 to enable easier configuration (in case we want to change it to 10 or some other number in future)

Else this LGTM, thanks!