feat(RelationshipButton): add feedback to transitional loading state

[camelCaseNick]

The intermediate state that a RelationshipButton implicitly has is not displayed to the user. As the button can be in this state for up to the timeout of the corresponding network request, it can lead to a perceived unresponsiveness of the app.

I also tried a Gtk.Spinner, but to me, it looks like a label fits better the button that also has a label otherwise.

[GeopJr]

Sounds good to me! I don't think there's any guidelines for such behavior but my goto so far for similar actions is to show the end result and revert on error.
For example: on post actions, like favoriting one, it plays the animation & increases the counter when the user clicks it before the request finishes. If it fails for any reason, it reverts it.

That gives the "instant" feeling to users (even if not accurate to what's going on). Megalodon on the other hand does something similar to setting the action to insensitive until it's done.

So I'm mostly leaning towards changing the button label to the resulting one and reverting it if it fails:

"Follow" => "Unfollow" => modify relationship ==if it fails=> "Follow"

What do you think?

[camelCaseNick]

In principle, this is close the Gtk.Switch:{active,state} where active is the desired value (left is off, right is on) and state is the currently actual value (grey is off, blue is on). You can see this e.g. in Settings where turning on and off Bluetooth takes time.

I think this difference is important to distinguish between in the UI, especially when it is important to you that the state is to be insured. In other words: I want that if Tuba says I'm following someone that I am following them.

Except Gtk.Switch, I cannot recall having seen anything similar that could help here with finding a good design, and I think you have a point that the UI should at least indicate the desired state.

[GeopJr]

Comparing to some other frontends, Mastodon web UI and Elk seem to do what I suggested (show end result, do request afterwards (fwiw you can verify this using the inspector)) while Akkoma (and Pleroma I guess) do what you suggested (kind-of, Follow => Requesting... => Request sent (should be following)).

Another thing to consider is the amount of time it takes to complete the request. Relationship requests are usually instant or at least very fast and return a tiny amount of data (compared to other operations). Showing a label or a spinner for 100ms is more likely to be distracting, from the HIG:

It is better not to show spinners for very short periods of time, since briefly displayed animated elements distract from the overall user experience. If an operation can vary in how long it takes, consider only showing the spinner after a period of time has elapsed.

We can ask the design team for a de-facto answer but considering the amount of time the request takes and the current guidelines, I believe the answer will be the same one as Elk/Masto web ui

Either way, I don't think this will make it in the upcoming release (especially if it introduces a new string (no time for translations)). Maybe we can split it into a lighter version (just setting it to insensitive until it's done) so it makes it in partially?

[camelCaseNick]

Another thing to consider is the amount of time it takes to complete the request. Relationship requests are usually instant or at least very fast and return a tiny amount of data (compared to other operations). Showing a label or a spinner for 100ms is more likely to be distracting, from the HIG:

I know this quote from the GNOME HIG. I just opened this, because I encountered slow (as in, up to a few seconds) responses.

Either way, I don't think this will make it in the upcoming release (especially if it introduces a new string (no time for translations)). Maybe we can split it into a lighter version (just setting it to insensitive until it's done) so it makes it in partially?

Also: After thinking about it, this could be a good case for a toast for when it failed. Regardless, I pushed a new version with just the sensitive line, as the toast idea would also be a solution with new strings.

[GeopJr]

I know this quote from the GNOME HIG. I just opened this, because I encountered slow (as in, up to a few seconds) responses.

We'll revisit it again after the release. I'm not sure what would be the best way to handle slow servers or connections instead as this is an issue that can affect other parts of tuba too (like resolving accounts).

[GeopJr]

LGTM, thanks!