[HOLD #2934] Enhancements for "Debounce account search typing & fix how validation displays in UI"

[mallenexpensify]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

On hold for #2934 since that one adds a necessary fix to phone number validation, and this one builds on that

These are enhancements are related to https://github.com/Expensify/Expensify.cash/issues/2934. Please review that job for more details Whomever is assigned that issue can work on these concurrently or after 2934 is fixed. If the assigner of 2934 doesn't want to work on this issue then it's held for anyone else until a week after 2934 is closed (to ensure there aren't regressions)

Enhancements:

When entering an email address or phone number in OptionsSelector's TextInputWithFocuStyles (on all screens where this exists), the app should do a few things:

1. Show a spinner when user is typing (debounce input, so stop showing spinner 300ms after user stops typing and do validation checks below)
2. When user has stopped typing for 300ms, do basic front-end validation checks
   • Email validation looks decent for now (Str.isValidEmai and !Str.isDomainEmail)
   • Phone number validation should get more strict, it's super basic at the moment (see Str.isValidPhone)
3. If above validation passes, do API-level validation for phone numbers only
   • Call the new Expensify API command IsValidPhoneNumber, which validates phone numbers in this format: '(\+?\d{10,15}|\d\d\d-\d\d\d-\d\d\d\d)'.

Make sure validation error messages still show correctly

• If phone number is invalid, show error message "Please enter a phone number including the country code e.g +447814266907". Example:
  • 
• If email address is invalid, show "Please enter a valid email address". Examples:
  • 
  • 

View all open jobs on Upwork

[MelvinBot]

Triggered auto assignment to @mateocole (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

[MelvinBot]

Triggered auto assignment to @thienlnam (Exported), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[Beamanator]

Removing @thienlnam b/c I'm happy to review proposals 👍

[Beamanator]

Oops, shouldn't have added Exported yet since this job isn't on Upwork yet :O

[pranshuchittora]

Proposal 📄

When entering an email address or phone number in OptionsSelector's TextInputWithFocuStyles (on all screens where this exists), the app should do a few things:

• Show a spinner when user is typing (debounce input, so stop showing spinner 300ms after user stops typing and do validation checks below)
• When user has stopped typing for 300ms, do basic front-end validation checks Email validation looks decent for now (Str.isValidEmai and !Str.isDomainEmail) Phone number validation should get more strict, it's super basic at the moment (see Str.isValidPhone)
• If above validation passes, do API-level validation for phone numbers only Call the new Expensify API command IsValidPhoneNumber, which validates phone numbers in this format: (\+?\d{10,15}|\d\d\d-\d\d\d-\d\d\d\d). Show errors below input box If phone number is invalid, show error message "Please enter a phone number including the country code e.g +447814266907".
• If email address is invalid, show "Please enter a valid email address". Examples:

Research/Investigation 🕵🏻‍♂️

• We need to implement debouncing
• Need to show the spinner
• Handle Validations

  Approach 👨🏼‍💻

  File of concern : Multiple (UI + Logic/Services)

• For implementing debouncing we can use lodash.
• We need to call the validate method/API on every keypress (debounced)
• The validation API and other required things are already provided by the author 👍🏼
• Sibling issue #2934 talks about the implementation of error methods, therefore some amount of dependency exists on the resolutions of the following issue.

Best Practices 💃🏼

• No hard-coded regexes
• No inline styling
• Accessibility
• Follow React Native best practices

Testing Strategy 🧪

• Unit tests for the underlying modules

Expected Delivery Time 📦

Approx 3-7 days. Considering any possible blockers

Open Questions ❓

• [ ] Any documentation for IsValidPhoneNumber. So far this is not been implemented in the codebase.
• [ ] Any UI design for this?
• [ ] Any specific spinner component (<ActivityIndicator />)?

Previous Experience 🙅🏼‍♂️

• https://github.com/Expensify/Expensify.cash/issues/2811

[Beamanator]

Thanks for the proposal, @pranshuchittora !

Here's some responses to your questions:

• Any documentation for IsValidPhoneNumber. So far this is not been implemented in the codebase.

  • Input: Object in format: { phoneNumber: "720-111-1111"}.
  • Valid if phoneNumber satisfies this regex: '(\+?\d{10,15}|\d\d\d-\d\d\d-\d\d\d\d)'
  • Example:

    API.IsValidPhoneNumber({ // you will have to create this in `/src/libs/API.js`
    phoneNumber: "720-111-1111",
    }).then((response) => { ...

  • Output: Json with these properties:
  • isValid (boolean) - is the passed phone number valid
  • jsonCode (number) - should be 200 if the request made it to the api & back to front-end successfully. Otherwise, maybe an internet connection error occurred
  • requestID (string) - this is for internal expensify log tracking, not needed for this job

• Any UI design for this?

  • For error message designs, please follow what you see in the screenshots in the original post.
  • For spinner design, see below

• Any specific spinner component ()?

  • ActivityIndicator should be perfect, we currently use that component in a few places in our app
  • @shawnborton I bet we can just do size="small" on this spinner, right? Care what color we use? Maybe themeColors.spinner?

[pranshuchittora]

Is that works @Beamanator

https://user-images.githubusercontent.com/32242596/118526334-c0d5a300-b75d-11eb-8f8a-f78ab2c8de60.mp4

Debounce

https://user-images.githubusercontent.com/32242596/118526327-bf0bdf80-b75d-11eb-9434-3d660618fa94.mp4

[Beamanator]

Hey @pranshuchittora !

I like the debouncing, but I believe we should show the spinner while we're waiting for the user to stop typing (for 300ms) and while waiting or the IsValidPhoneNumber response to come back. Also are you planning to make sure the "Concierge" & "pranshu_...@srmuniv..." chats are hidden while the text input is debounced?

[pranshuchittora]

Hi @Beamanator

• Will add the spinner

Also are you planning to make sure the "Concierge" & "pranshu_...@srmuniv..." chats are hidden while the text input is denounced?

Not sure about this but I have decided to keep them because so that user have something to go for. Thinking in terms of the User Experience, it is better to show something instead of nothing. Would love to hear your thoughts on this as well :)

[pranshuchittora]

✔️ Spinner ✔️ Debounce ✔️ Ignore phone number validation on email ✔️ Edge cases

https://user-images.githubusercontent.com/32242596/118657125-d18f2300-b808-11eb-84d1-b4f614161168.mp4

cc @Beamanator

[Beamanator]

I absolutely don't consider myself an expert in design, which is why I'd recommend we consult with the @Expensify/design group :D

Hey designers! How do y'all feel about the above design, specifically:

1. When typing in that text box, should we show only the spinner? Or should we also show matching chats?
2. When the user stops typing and there's some validation error (phone or email) and then keeps typing, the error should go away right?

[michelle-thompson]

When typing in that text box, should we show only the spinner? Or should we also show matching chats?

I think we should show matching chats. I know there have been times where I partially know a phone/name/email and search results fill in the rest, so I think it's helpful.

When the user stops typing and there's some validation error (phone or email) and then keeps typing, the error should go away right?

This makes sense to me, yeah.

[shawnborton]

I think the constant jumping around feels really strange. Could we do something where:

• There is always a small gap under the search box and above the top search result row. When there is the small validation message below the search box, it fills this space without causing the rows below it to jump around
• Could we place the loader in the text input, perhaps floating off to the right or something? Or perhaps place it absolutely positioned on top of the search results, and perhaps slightly fade out the results while typing?

Basically this flow should feel ultra smooth and not bouncey/jumpy like it does in the video, so hopefully the ideas above will help us solve that.

[Beamanator]

Ooh I like these ideas! What do you think @pranshuchittora ?

[pranshuchittora]

Ooh I like these ideas! What do you think @pranshuchittora ?

I agree with all the points. @Beamanator can put a comment consolidating all the new design requirements so that it’s properly documented.

[Beamanator]

Here's the updated design requirements:

• While typing:
  • Always show list of matching chats (as you have in your video)
  • Show spinner (either in the text input floating off to the right, or on top of search results (probably centered vertically & horizontally) with search results slightly grayed out but still readable)
  • Clear error message (if one existed)
• When done typing, error message appears below the search box - there should always be space here, even when error doesn't exist - this should prevent components from jumping around

Main important thing to keep in mind:

Basically this flow should feel ultra smooth and not bouncey/jumpy

[mallenexpensify]

Created the job in Upwork, made it private and invited @pranshuchittora , once you accept we'll assign this issue to you https://www.upwork.com/jobs/~014262863179787232

[mallenexpensify]

Hired @pranshuchittora in Upwork, assigning this issue now, @Beamanator will be reviewing the PR

[pranshuchittora]

Thoughts @Beamanator @shawnborton @michaelhaxhiu @michelle-thompson

https://user-images.githubusercontent.com/32242596/118997482-51062900-b9a6-11eb-81cd-4142fe2d5e99.mp4

As per this 👇🏼

Here's the updated design requirements:

• While typing:

  • Always show list of matching chats (as you have in your video)
  • Show spinner (either in the text input floating off to the right, or on top of search results (probably centered vertically & horizontally) with search results slightly grayed out but still readable)
  • Clear error message (if one existed)
• When done typing, error message appears below the search box - there should always be space here, even when error doesn't exist - this should prevent components from jumping around

Main important thing to keep in mind:

Basically this flow should feel ultra smooth and not bouncey/jumpy

[Beamanator]

Looking great!!

One quick comment: When an invalid email address is shown, can you show the message "Please enter a valid email address" below the text field?

[megankelso]

following Alex's comment, should it perhaps be Please enter a valid email address or phone number in that case?

[shawnborton]

Couple of comments:

• The loading spinner feels "heavy" for these quick interactions. Do we even need it? I would be curious to see this without the loading spinner entirely.
• Could we make the text below the search input use a smaller font size (fontSize: variables.fontSizeSmall,) and make sure you are using the correct font family as well (fontFamily: fontFamily.GTA,)? Hopefully that makes that section a bit smaller so that there isn't such a large gap between the search input and the search results.

[pranshuchittora]

Done @shawnborton @Beamanator

https://user-images.githubusercontent.com/32242596/119545645-ac725580-bdb0-11eb-9cdd-5b2947fbf677.mp4

[shawnborton]

Thanks for putting this together! Candidly, this still does not feel like a great user experience. For example, the error message returns so quickly that you don't even get a chance to fully type out your query:

Perhaps we can make the time longer from when the user last presses a key versus when the error message shows up?

I also think I might walk back on my idea of having a fixed gap between search box and the results, as I feel like this gap feels a bit visually strange:

Curious what others think as well.

[Beamanator]

Personally I'm ok with the error message showing up as quick as it does (if you type really quickly you shouldn't get the message until you pause, which makes sense to me).

I do agree that the blank white space under the text box is not very visually appealing... Could we make the error text display above the text box, below 'Search'? Maybe the error message can be shortened so it's 1 line in that case?

[pranshuchittora]

ake the error text display above the text box, below 'Search'? Maybe the error message can be shortened so it's 1 line in that case?

@Beamanator let me know your final thoughts :)

[shawnborton]

Personally I'm ok with the error message showing up as quick as it does (if you type really quickly you shouldn't get the message until you pause, which makes sense to me).

From what I can tell from the recording, you need to type very quickly though. Is there a happy balance we can strike here?

Could we make the error text display above the text box, below 'Search'?

Personally not a fan of this idea as it goes against the pattern we've established elsewhere, where form validation happens as a small message below the input.

Maybe the error message can be shortened so it's 1 line in that case?

That would be awesome, though not sure if we have enough room. In the very least, @pranshuchittora can you make the error text display at a fontSize of 11 and see if that helps?

[pranshuchittora]

@shawnborton in the above-attached video the font size has been changed to 11 as per the feedback received prior to that :)

[michaelhaxhiu]

From what I can tell from the recording, you need to type very quickly though. Is there a happy balance we can strike here?

Yeah I agree with @shawnborton on the quick timing we are displaying the error. It shows up really quickly. Maybe we can add a 1.5 second delay after a user presses the last key?

Also, is there a confirmation button a user clicks after entering a valid email or phone number? Like "Submit" or something? Or is it just enter on the keyboard?

As an idea... I'm wondering if we ought to use something that resembles this grey/green arrow? It could serve a replacement for the loading spinner and a way for a user to confirm their input by tap / click when putting in an email or phone number.

• grey arrow = invalid email or phone number, cannot submit input
• green arrow = valid email or phone number, can submit input

[shawnborton]

I think a submit button would make the experience poor as well, especially given that the chat search is used to quickly jump between chats.

[michaelhaxhiu]

Got it. I looked at other fields in e.cash that resemble this one, and see that you can click the row or hit enter on the keyboard. Let's keep consistent with that theme and ignore my idea.

[shawnborton]

Okay so my latest idea, and not far from where we current are, is that maybe we should just launch the Search pane with no fixed space underneath the search box. I would hope in most cases when people quickly navigate to a different chat, their search query would return results and won't need an error message. When there is indeed an error, let's just show the error message under the box. Bonus points if we could do some kind of animated slideToggle for the height of the error message box so that it feels a little less jarring.

@pranshuchittora @Beamanator @michaelhaxhiu thoughts on trying something like this?

[Beamanator]

I have a similar idea that may help us solve some problems:

What if we only show the error message when there aren't any matching results showing? I think it looks a little weird showing results & an error message at the same time because the user sees "something's wrong with what I'm typing, but there's also some results showing". Example:

So with this idea of "not showing an error message if the current text matches at least one already-created chat / report", we would basically be doing:

1. Only show matching results if there's matching results from old chats
2. New Chat if no chats match & if the typed text is valid
3. Error message if no chats match & if the typed text is invalid

How about this @shawnborton @pranshuchittora @michaelhaxhiu ? :D

[shawnborton]

I like it! @pranshuchittora thanks for your patience with us as we figure this one out :)

[pranshuchittora]

Sure

[Beamanator]

I believe we're all agreeing we should push forward with this plan right?

[michaelhaxhiu]

Yep!

[pranshuchittora]

I have a similar idea that may help us solve some problems:

What if we only show the error message when there aren't any matching results showing? I think it looks a little weird showing results & an error message at the same time because the user sees "something's wrong with what I'm typing, but there's also some results showing". Example:

So with this idea of "not showing an error message if the current text matches at least one already-created chat / report", we would basically be doing:

1. Only show matching results if there's matching results from old chats
2. New Chat if no chats match & if the typed text is valid
3. Error message if no chats match & if the typed text is invalid

How about this @shawnborton @pranshuchittora @michaelhaxhiu ? :D

Done 🚀

https://user-images.githubusercontent.com/32242596/120934227-1bd63680-c71b-11eb-93a2-5f0b0748ea54.mp4

Thoughts ?? P.S> PR has been updated

[Beamanator]

Ooh that looks great! Let's see what the @Expensify/design team things too :D

[michelle-thompson]

Looks good! My only comment is that the search results feel too close to the input. It should look like this, which has 12px padding between input and results:

[pranshuchittora]

Done @michelle-thompson I have updated the PR

[michelle-thompson]

The spacing looks great!

One more comment -- it looks like the focus border is on top of the original input border, you can see a light grey border on all four corners. Can we ensure that the corner radii for the focus matches so we don't see two borders?

[pranshuchittora]

The spacing looks great!

One more comment -- it looks like the focus border is on top of the original input border, you can see a light grey border on all four corners. Can we ensure that the corner radii for the focus matches so we don't see two borders?

The focus border is browser behaviour. It depends on the browser and platform (OS). Overriding it might not be feasible. cc @Beamanator

[Beamanator]

@pranshuchittora I think you're right about that - also, there's another issue (https://github.com/Expensify/Expensify.cash/issues/3108) to handle form styling, so as long as this PR doesn't introduce any new form styling issue (which I don't think it does), you can definitely leave this as is :D

[mallenexpensify]

@Beamanator @pranshuchittora , can I get an update on this? Want to post in the parent issue where we're at. Thanks

[Beamanator]

Waiting on @pranshuchittora to respond to my comments or work on requested changes

[Beamanator]

Unassigning for lack of updates - I'm going to clean up requirements & put this on hold for https://github.com/Expensify/App/issues/2934

[Beamanator]

Issue we're holding for hasn't been completely fixed yet

[Beamanator]

Back to weekly since I'm focusing on some other tasks for now

[Beamanator]

Closing this issue since it would be nice to have a fresh start when we're ready