User should see indication that they have tapped

[holmesworcester]

Right now there are no tapped states on iOS or Android for channels and menu items (we used to have them on Android for channels) so users can't tell when they've tapped the screen.

I think we should be using TouchableOpacity on channels and menu items in action sheets (like settings, delete, etc.) And TouchableHighlight on buttons. See: https://reactnative.dev/docs/handling-touches

[EmiM]

https://github.com/TryQuiet/quiet/pull/1584

[kingalg]

1.4.0 Mobile

Implemented correctly.

[holmesworcester]

@kingalg @EmiM this isn't done quite right. Two issues:

1. Opacity shouldn't change on drag/scroll since this is non-standard.
2. Opacity change should only last as long as the tap.

GPT4 has some suggestions: https://chat.openai.com/share/92d3c71d-be76-4821-8b98-9c73e6312ebf

Airbnb is an app that has this behavior (in the results list). It's fairly hard to find an app with this behavior, as most apps simply load the desired screen fast enough so that no user feedback is required (changing screens is the only feedback needed.)

I think we should fix the first issue by adding the delayPressIn parameter, since that seems easy, and then deprecate the need for any of this by making loading the new screen consistently fast regardless of the size of the channel:

<TouchableOpacity delayPressIn={150}>
  <Text>Touch Here</Text>
</TouchableOpacity>

[kingalg]

@holmesworcester I agree that it's going to look better without change on scroll but I also don't think that it's wrongly implemented by @EmiM . Yesterday when I was checking this issue I was actually missing details of how it should work and I asked Emi how she understood those requirements. It's never a good sign if developer and QA need to guess so we should definitely from the beginning ask for detailed requirements. Opacity not changing on drag/scroll is more common solution but not the only one. To not look far, opacity change on drag/scroll is implemented on reactnative webside that was linked as an example of handling touches. So it was justified that without specific description Emi has chosen this one. What I would take from this is:

1. Let's change how we handle opacity to what Holmes described in the comment - I suggest tracking this in separate issue as this is out of scope of description of this task and it will be easier to check on this later in separate issue.
2. More detail in the task description is better then less even if we think that something is obvious.
3. If we feel that not all details are clear its important to ask for them.

[holmesworcester]

We can add some animations to the Figma prototypes to use as a reference, but from googling quickly I think the word 'tap' has enough specificity (as distinct from dragging or swiping) to make this issue clear.

Another way to approach this is to include a short screencast of every UX related feature for feedback, or at least for every animated one (with screenshots as an option for static UX related features) with the expectation that we might need one round of feedback for many user-facing features. I think this is already our general policy and it helps a lot. This will let us catch things before release.

[holmesworcester]

Creating another issue, as per our discussion.

[holmesworcester]

When this issue is complete, let's remove the tap/opacity effect entirely: https://github.com/TryQuiet/quiet/issues/1063