Select avatar on Avatar Picker

[etoledom]

Description

This PR implements selecting a different avatar on the Avatar Picker.

Bigest changes:

• AvatarModelList to manage the models array. This is helpful to simplify updating elements in the array.
• AvatarPickerProfileView loads the avatar image directly from a URL.
  • In this way we can pass a recently selected avatar url without depending on backend cache times. It also should load the image from already cached images, since the URL is the same than images from the grid.

Testing Steps

• Select different avatars from the Avatar Picker.
• Select a recently uploaded avatar.
• Check that the selected avatar gets selected on web (going to the profile url).

[andrewdmontgomery]

If tapping an avatar makes the change live, then the card at the top isn't a preview, it is a live view. So I think it needs to reflect the live state.

I think the card at the top should only fully update to the new avatar once the backend confirms the change has been saved. I think there is a way to have a transient state though. I'll get to that below.

I think it is difficult for a UX like this to convey the consequences of tapping an avatar – your taps go live immediately. This will be something that users will need to discover through experimentation. And we need to help them discover it. I think having the spinner appear over the action helps convey the idea that "what you did caused something to be processed".

That's why I think the tapped avatar should have the spinner. Every tap does more than select a new avatar – it makes that change live. I think making the spinner a direct consequence of your action helps convey this unusual UX.

There's one change to this that I would suggest:

Transient State for Live Card

As I said, I think the state of the profile card should reflect the state of the change. So in the time between the selection being changed and the backend confirming the change, I think we should have a transient state.

I don't think it should be a spinner. I think that is most effective over the selection (see above). Instead, I suggest this:

1. Tap a new avatar
2. Process the change:
   • Move blue selection box to tapped avatar
   • Place loading spinner over tapped avatar
   • Update Live profile card with new avatar... but dimmed (conveys "the avatar is changing, but not yet live")
3. Once the backend confirms:
   • Remove spinner from selection
   • Un-dim the avatar in the live card
4. If the backend fails for some reason, revert the avatar, display toast error, etc.

Multiple Taps

In the case where someone makes a rapid series of taps on different avatars:

• The spinner appears only on the most recent selection (it's removed from the previous selection)
• The greyed-out avatar in the live card should continue to be updated with the most recent selection while we wait for the backend to confirm (and then un-grey the avatar in the card).

Tangent: Tapping shouldn't make live changes

This is only a problem because these changes are happening live.

I dislike that, which I've already voiced elsewhere. In this use case, I feel this is an anti-pattern. We're doing it because it feels like it requires fewer steps, and imposes less friction. But it requires more friction, not less. It's the same number of taps. But now, all changes are live. That requires more network connections, potentially on a slow network connection. It also means they can't preview their change, forcing them to wait while the change is processed before seeing their choice.

In my opinion, a better flow would be to have a "Done" button (top right). In that scenario, the card at the top is a Preview. So it should update immediately, allowing you to visualize the change before committing to it. And then the only network request happens when tapping "Done". It's the same number of taps for the user. But the experience is better:

• The card at the top is becomes a preview, and is updated instantly as you explore avatars
  • With live changes, we need to wait for the backend to update before displaying the new avatar
• Only 0 or 1 network requests need to be made, regardless of how many avatars are tapped
  • With live changes, we need to make network requests for each tap, even though the user only wants to save the last one.
• Changes are committed intentionally (tapping "Done")
  • With live changes, users will need to discover through experimentation that they are making live changes, which could be surprising, or even misunderstood.
• Changes can be reverted simply by tapping "Back" instead of "Done".
• It's the same number of taps for a user to change an avatar.

[etoledom]

@andrewdmontgomery -

I think the card at the top should only fully update to the new avatar once the backend confirms the change has been saved.

I have implemented this change, as it's also how it is working on Android

Multiple Taps In the case where someone makes a rapid series of taps on different avatars:

I have also made necessary changes for this case. We cancel the previews and do not react to the cancellation error to avoid selecting back the originally selected avatar.

Tangent: Tapping shouldn't make live changes

I understand this and I agree. This PR implements the current design. We can advocate for this change in the future.

[etoledom]

@pinarol - maybe you want to take a look at this cancellation logic which handles multiple rapid taps on avatars before merging 👀