[Request]: cross-account actions

[tfardet]

Describe the request

Since Tuba supports multiple accounts, it would be nice to support cross-account actions.

Rationale : for people with multiple accounts, it occurs quite often that you're browsing a timeline with account A when you see a post that you want to interact with using account B before resuming your browsing on the timeline of account A.

With the current implementation, it is quite tedious because you need to

1. copy the link to the post
2. switch from A to B
3. paste the address and search for the post
4. do the interaction from B
5. move back to A
6. find the timeline you were on and resume browsing

With cross-account actions, that would be (e.g. for a boost):

1. set that you want to use account B
2. boost
3. resume browsing (you never left the timeline)

Operation 1. can be done in several ways, the main ones I know are:

• Fedilab-like, upon long-press (on mobile, would be right-click on desktop) on the reply/boost/fav icons, one gets a menu that asks with which account the action should be performed
• Sengi-like, there is a bar with all account avatars somewhere (could be a side panel that you swipe to reveal) and the action is performed by the selected avatar's account, even if the timeline currently being browsed belongs to a different account

As multi-account support is already present, I believe this does not add a new use case (it just makes multi-account support more seamless), and depending on the implementation it also does need additional elements or options that would clutter the interface but greatly reduces user effort (so very much GNOME HIG compatible ;D)

Implementation Details

• This should be an option in settings.
• This should be only available to some fediverse backends. (Include which ones on the above field).
• This is client-only (and shouldn't sync with the instance).
• This follows the GNOME HIG.

[GeopJr]

Thanks for the suggestion!

This is a tricky one

Fedilab-like

Doesn't follow the hig "Do not assign actions to double-clicking or right-clicking a button. Users are unlikely to discover these actions, and if they do, it will distort their expectations of other buttons."

Sengi-like

Sengi was built with that (multi-account timelines) as the goal while Tuba/Tootle was built for general use - account switching is mostly for advanced users (and even then I doubt most people would want their accounts mixing up)

I really don't see any viable way to add this.

• Sidebar? There's already one, adding another one is too much (plus it would need a tutorial on what's the difference between that and the main account switching one).
• Another button on posts? The post widget is already too cluttered/complex.
• Context menu item? It's either 4 new items (reply as, boost as, fav as, bookmark as) (too many items) or a single item (act as a different user) but that would need yet another indicator on the post widget to showcase which is the current active account for that specific one.

And that's the UX/UI portion, (I haven't looked into how Sengi does it) but you have to make network requests using the changed-to account to all visible posts from the changed-from account's timeline to see if the changed-to account can see and interact with them, for the first case. For the other two cases (per-post account switching), you'd have to either make network requests from each account when a user selects that they want to interact as another account to see which ones they can use OR allow them to pick any and just attempt to interact even if it fails (bad UX).

I don't want to sound dismissive but this would require many UI changes and network-related decisions for little to no gain / usage.

I'll leave this open for a bit for any future comments but the chances are very slim

(This is a bit long and I might have overthought it or misunderstood the original suggestion, if so feel free to specify below!)

[tfardet]

Fedilab-like

Doesn't follow the hig "Do not assign actions to double-clicking or right-clicking a button. Users are unlikely to discover these actions, and if they do, it will distort their expectations of other buttons."

Ha, missed this part of the HIG, sorry.

Sengi-like
I really don't see any viable way to add this.

* Sidebar? There's already one, adding another one is too much (plus it would need a tutorial on what's the difference between that and the main account switching one).

I don't really see a problem with an option that would enable a left cross-account action sidebar with the accounts' avatars, but I'll let you be the judge of that.

* Another button on posts? The post widget is already too cluttered/complex.

There is also room for an additional menu button on the posts (especially if buttons span the whole width and not only the text area). This would reproduce the current standard from the Mastodon web interface, so users would probably not mind? But sure, that's a design decision so I'll let you think about it.

* Context menu item? It's either 4 new items (reply as, boost as, fav as, bookmark as) (too many items) or a single item (act as a different user) but that would need yet another indicator on the post widget to showcase which is the current active account for that specific one.

I'm not sure how you differentiate the previous item from this one, could you elaborate.

And that's the UX/UI portion, (I haven't looked into how Sengi does it) but you have to make network requests using the changed-to account to all visible posts from the changed-from account's timeline to see if the changed-to account can see and interact with them, for the first case. For the other two cases (per-post account switching), you'd have to either make network requests from each account when a user selects that they want to interact as another account to see which ones they can use OR allow them to pick any and just attempt to interact even if it fails (bad UX).

Yes, Sengi simply uses the post visibility to tell whether you should be able to interact or not but it does not actually check so there are instances where interaction may fail (e.g. if the person blocked your other account)

I don't want to sound dismissive but this would require many UI changes and network-related decisions for little to no gain / usage.

I understand.
Another possiblity could be an "open post as" option with the feature that navigating back brings you back to the initial timeline and account (that would already remove a large fraction of the inconvenience).

[nekohayo]

For the record, Tweetdeck does this by providing those special actions as part of the meatballs (…) / hamburger menu in the context of the post:

It then prompts you like this (with an overlay, but it could be a dialog), for example:

Personally, it wouldn't shock me to have those 2-3 extra actions in the meatballs menu in addition to the few existing ones, perhaps with a separator inbetween.

[tfardet]

@nekohayo Agreed! This would be my preferred choice.

In case it is not deemed acceptable, here is a 3rd proposal:

Since the last version it now seems that there is a menu item next to the post privacy icon (top-right corner) so we could also add the following option

1. click the menu from account A and select "open in another account"
2. select desired account B
3. make the interaction
4. (important) clicking "previous" (the top-left arrow) brings you back to the post on the initial account's timeline (i.e you're back to account A)

Though that's already a lot of interactions, I feel it'd still a significant improvement over the current state.

[selfisekai]

Mastodon has also announced that they are planning to introduce quote boosts, and they are already a feature in at least Akkoma and Calckey, so maybe these 2 problems can be solved together.

on Twitter and Bluesky, the repost button opens a menu like this:

on Tumblr, the reblog button opens a dialog like this, where a comment can be optionally added and identity can be switched. I remember Twitter was A/B testing this kind of workflow a few years back, but has seemingly withdrawn from it.

this however still doesn't solve the problem for favs.

[GeopJr]

Ok so, I gave it a try on #281 (there's screenshots)

The approach I took is changing the account to act as from the menu and execute the post actions using it.

I am not sure if that's the ideal approach, the tweetdeck one is also worth looking into - showing the actions next to every account

The tumblr one involves the composer mostly which might be worth looking into in a different issue ("Posting as different a account without switching to it") and/or when a composer redesign is proposed!

I'm still not really fond of cross-account actions, before doing anything, it already requires making a search request from the changed-to account to get the post id from its instance and then everything is kind-of random (in regards of whether you can interact etc). At least the initial search request deals with whether the changed-to account can see the post.

[tfardet]

Ok so, I gave it a try on #281 (there's screenshots)

So am I right in understanding you implemented that proposal?
In that case, does the "go back" button indeed redirect to the original account and timeline where the post was first seen?

The approach I took is changing the account to act as from the menu and execute the post actions using it.

I am not sure if that's the ideal approach, the tweetdeck one is also worth looking into - showing the actions next to every account

Yes, I would say tweetdeck implementation is the most time-saving option, but this is already a great improvement.

I'm still not really fond of cross-account actions, before doing anything, it already requires making a search request from the changed-to account to get the post id from its instance and then everything is kind-of random (in regards of whether you can interact etc). At least the initial search request deals with whether the changed-to account can see the post.

I guess with the tweetdeck version you could actually check whether the action is possible and only display the accounts that can do the requested interaction?

Anyway, thanks a lot for starting to look at this, it really makes a world of difference when using multiple accounts!

[GeopJr]

So am I right in understanding you implemented #223 (comment)?
In that case, does the "go back" button indeed redirect to the original account and timeline where the post was first seen?

Kind-of, apart from the "opening" part - it's closer to Sengi:

• You select doas (not final name) from the menu of a post (that is public or unlisted)
• Then select one of the saved accounts
• Tuba does a search request from the changed-to account
• If it fails, it won't act as the changed-to account
• If it succeeds, it will slightly change the post background color to purple and act as the changed-to account
• If you then select doas again and pick your active account, the purple background color will be removed and you will act as the active account

I guess with the tweetdeck version you could actually check whether the action is possible and only display the accounts that can do the requested interaction?

You are right, it would require doing a search request from every single account so probably not going to happen

[tfardet]

Kind-of, apart from the "opening" part - it's closer to Sengi

* You select `doas` (not final name) from the menu of a post (that is public or unlisted)

OK, I imagine that you don't do followers-only because you don't want to make the additional search requests

* If it succeeds, it will slightly change the post background color to purple and act as the changed-to account

I'd find it more intuitive if the post went (perhaps in addition to the color change) into "thread mode", like when you normally click on a post, so that it's really obvious that you are no longer in the same context. In my opinion that would also make it easier to implement the reply as in this context.

* If you then select `doas` again and pick your active account, the purple background color will be removed and you will act as the active account

With this implementation, it's an additional two clicks to go back to the other account and you need to know it (it is not intuitive). What happens if you don't click "doas" again and resume scrolling?
To me it seems more intuitive to go to thread mode, where you have to click back (you don't need to know what you're supposed to do, there is not other option).

You are right, it would require doing a search request from every single account so probably not going to happen

OK

[tfardet]

@GeopJr did you have time to think about the potential implementations? As you mentioned that you wanted to discuss this with some GNOME designers, I was wondering if you got the opportunity to do so.

[GeopJr]

Nope. I'm not satisfied with the current implementation nor the other suggestions so it's stuck in the backlog. I don't like that pretty much everything is left up to "it might or might not work" and it's not as easy as just "opening a thread as a different account" because there are many moving parts from custom emojis to how many poll options an instance supports or whether it can display quotes and emoji reactions.

[tfardet]

Nope. I'm not satisfied with the current implementation nor the other suggestions so it's stuck in the backlog.

I understand.

it's not as easy as just "opening a thread as a different account" because there are many moving parts from custom emojis to how many poll options an instance supports or whether it can display quotes and emoji reactions.

I did not follow that last part, could you explain why this is an issue here, compared to the situation where I would find a post on account A, copy its link, go to account B and search for the post there?