React-instantsearch: RefinementList is getting checked after the results are refined. Bad UX for slow internet connections

Created on 23 Jun 2017  ·  11Comments  ·  Source: algolia/react-instantsearch

Hello,

using react-instantsearch - latest

I tried to throttle my network and selected refinements, it seems like the checkbox gets selected after algolia is able to make the network call and fetch the results, this could lead to a bad UX as the user might think its not yet selected and click again which would make another API call.

Wanted to know how we can go around this.

Thanks!

❔ Question ♻️ Needs IS sync

Most helpful comment

Would it be possible that multiple refines can be clubbed together and made a single query?

The issue is that each refine sends a different set of results and allowed filtering options set. Which mean you can't bundle them since they might no more be relevant.

Example:

  • refinementList shows sci-fi and romance genres
  • click on sci-fi genre
  • UI updates, romance is no more selectable
  • => if we allowed for bundle, we would show a state that is not relevant/true

All 11 comments

What I suggest as an improvement is to put the state of the checkbox as checked as soon as a user clicks, but also put it as disabled={true}. Once the request comes back, the disabled={false}. This sort of pattern should come back in all of the Widgets probably

That makes sense! However I am not sure if you are going to include it in the library itself? This is doable if I use connectors.

It depends. This is not a top priority right now, as you say, it's perfectly doable with connectors, maybe as a guide. If you have the code for dealing with this problem, feel free to put it here, or PR a guide

This is a tricky subject (slow connections). Ultimately every click on a refinement list can lead to different results (where some other might no more be available).

For example we could check the box asap but then it provides a fake view to the user, he can select other categories that might disappear when response comes back.

Thus a more generic solution would be to lock widgets when the response is awaiting, but this can also provide a bad UI.

Even google struggles with that, I have seen "This item is updating" boxes in google calendar, feels very bad.

So I was thinking about this, In React-Instantsearch, every single change is triggered by a refine, Would it be possible that multiple refines can be clubbed together and made a single query?

So basically we will let the users quickly click around and apply the filters and we debounce all the refines and combine and make a single query.

Does that make sense?

Yes, but it's not as simple as just debouncing, since that would be hurting the users that actually do have a good connection. In any case, that's probably something that should happen in the Helper, rather than individually in each InstantSearch version

Why not? I dont think debouncing hurts people with good connection, making an api call will have some latency on the user's location, its the same as debouncing on search box.

@harshmaur I did see some UI interfaces that were very confusing because of the search as you type experience along with the debouncing.

In any case, this discussion reminds me this refineHook asked feature => https://github.com/algolia/instantsearch.js/issues/1994

It's still on the backlog, but not top priority for now.

@mthuret Yes! And it can always be connected. :)

Would it be possible that multiple refines can be clubbed together and made a single query?

The issue is that each refine sends a different set of results and allowed filtering options set. Which mean you can't bundle them since they might no more be relevant.

Example:

  • refinementList shows sci-fi and romance genres
  • click on sci-fi genre
  • UI updates, romance is no more selectable
  • => if we allowed for bundle, we would show a state that is not relevant/true

Oh Yeah, I didnt think of that fact!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

afgoulart picture afgoulart  ·  4Comments

flouc001 picture flouc001  ·  5Comments

mxmzb picture mxmzb  ·  4Comments

rtman picture rtman  ·  5Comments

danhodkinson picture danhodkinson  ·  3Comments