Wordpress-ios: [Choose a Domain] Update search results to behave more like Android

[chipsnyder]

Expected behavior

When you search for a domain on Android during the site creation flow, it returns results that include "This domain is unavailable" and more results than the iOS flow.

I'd like to see if we can consolidate the behavior between the two sources.

Actual behavior

iOS seems to return about 5 results, which seem to be heavily influenced by different back-end behaviors. For example, if I make the request: https://public-api.wordpress.com/rest/v1.1/domains/suggestions?locale=en&query=test&segment_id=1
I get:

{
    "error": "empty_results",
    "message": "No available domains for that search."
}

However, if I add quantity like https://public-api.wordpress.com/rest/v1.1/domains/suggestions?locale=en&query=test&segment_id=1&quantity=20

I'll get about 19 results.

Steps to reproduce the behavior

📓 These steps are for the enhanced site creation flow

1. Navigate to the Create WordPress.com site
   
   
   
   • My Sites > ➕ > Create WordPress.com site
   
   
2. Choose a design or select skip
3. Search for a domain in the resulting screen

[chipsnyder]

@mkevins Want to move this comment over from https://github.com/wordpress-mobile/WordPress-iOS/pull/15360#issuecomment-732938289 so we could track our discoveries on this issue.

if you hook up a proxy does the app reflect the results from the last search that was performed?
Can you clarify this part? Do you mean, to running the app via a sandboxed API (or any other steps)? To be clear, the above results were on the production API, and I observed that even by merely clicking the links in your comment above.

Hey @mkevins, I was thinking more along the lines of a network monitoring tool against the prod environment. For example, I was using Charles Proxy but any monitoring tool would probably work.

I'm really hoping to confirm if all of the inconsistencies are network-related or not. While I tested I saw that a particular request would return the result set "A", then on a second call it might return a new result set of "B", then on a subsequent call, I might get "A" again.

So while running the app I might see a sequence like:

1. query=te returns result "A"
2. query=newString returns result "C"
3. query=te returns result "B"
4. query=newString returns result "C"
5. query=te returns result "A"

But what I noticed in the app is the display would work as expected and return the results of the last request. So in my example above I would see the results "A". I was wondering if you're seeing the same or not.

[chipsnyder]

@iamthomasbishop @kyleaparker

I wanted to get your thoughts on this. On Android we have a bar that will let you know an address that matches your search term isn't available. From what I can tell it gets this information based on not finding an exact match in the results. Should we try and mimic this on the iOS side as well? I was thinking we might be able to add a row above "Suggestions" as a separate section but let me know what you think.

Android Version:

[kyleaparker]

Should we try and mimic this on the iOS side as well? I was thinking we might be able to add a row above "Suggestions" as a separate section but let me know what you think.

Yes I think this would be really useful!

On iOS is the way we prioritize the suggestions seems random. For example, if I search "mylittleinternetsite" I would expect mylittleinternetsite.wordpress.com to be the first suggestion, but it's third on third on the list right now:

[chipsnyder]

Good callout @kyleaparker! Judging by Android it looks like they're sorting the results by placing the exact matches first and sorting the subdomains alphabetically. Then sorting close matches alphabetically.

We might need to create an Android component to this ticket as well if we go with this suggestion but I'm wondering if we would want to prioritize wordpress.com as the top suggestion if available so:

mylittleinternetsite.wordpress.com <- Exact Match
mylittleinternetsite.art.blog <- Exact Match
mylittleinternetsite.design.blog <- Exact Match
mylittleinternetweb.wordpress.com 
mylittleplaceinternetsite.home.blog

Android's sort

[iamthomasbishop]

@chipsnyder I might be missing a detail, but my opinion would be that I definitely agree that we should bump exact matches up to the top, but we probably shouldn't place special weight on the wpcom URLs.

[chipsnyder]

@iamthomasbishop That works for me too. The only reason I thought to prioritize wpcom URLs was because we reference wpcom if an exact match isn't available. Not prioritizing wpcom would make the logic easier so I'm good with that.

[iamthomasbishop]

The only reason I thought to prioritize wpcom URLs was because we reference wpcom if an exact match isn't available. Not prioritizing wpcom would make the logic easier so I'm good with that.

Ah ok, fair enough. Sounds good!