Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emoji reactions support, take 4 #2462

Open
wants to merge 30 commits into
base: main
Choose a base branch
from

Conversation

TheEssem
Copy link

@TheEssem TheEssem commented Nov 10, 2023

Replaces #1980, #2127, and #2221.

All previous commits have been merged and rebased. I've also fixed a couple of formatting issues and inconsistencies.

Let me know if there's anything missing. I hope to have this PR serve as a base for continued development of this patch.

@TheEssem
Copy link
Author

I've been thinking about how showing who reacted to a post could work on the web UI; would it be better to show users like in the favorites/boosts lists in chronological order but with the emoji next to them somewhere (maybe next to the follow button?), or would it be better to have a list with separate tabs for different emojis?

Here are a couple of mockups for a potential button to view them; one option I thought of was to put a clickable smiley icon next to the boost/favorite counts (taken with upstream's Material Icons set, but probably doable with FA4):
image
Maybe an "info" button can go at the end of the reactions instead (though likely slightly larger than depicted here:
image

@Plastikmensch
Copy link

I've been thinking about how showing who reacted to a post could work on the web UI; would it be better to show users like in the favorites/boosts lists in chronological order but with the emoji next to them somewhere (maybe next to the follow button?), or would it be better to have a list with separate tabs for different emojis?

Here are a couple of mockups for a potential button to view them; one option I thought of was to put a clickable smiley icon next to the boost/favorite counts (taken with upstream's Material Icons set, but probably doable with FA4): image Maybe an "info" button can go at the end of the reactions instead (though likely slightly larger than depicted here: image

See: #2221 (comment)

Also Font Awesome will likely be removed.

@MagicLike
Copy link

I've been thinking about how showing who reacted to a post could work on the web UI; would it be better to show users like in the favorites/boosts lists in chronological order but with the emoji next to them somewhere (maybe next to the follow button?), or would it be better to have a list with separate tabs for different emojis?

Here are a couple of mockups for a potential button to view them; one option I thought of was to put a clickable smiley icon next to the boost/favorite counts (taken with upstream's Material Icons set, but probably doable with FA4): image Maybe an "info" button can go at the end of the reactions instead (though likely slightly larger than depicted here: image

See: #2221 (comment)

Also Font Awesome will likely be removed.

Wouldn't it be better for UX and general usability to do it "Misskey-Style" and show the usernames on hover? The list could be added anyway for a better mass-overview.

@imdatceleste
Copy link

If you do it MissKey-style (hover on mouse-over), how would you do that on mobile devices, where there is no mouse?

@mkody
Copy link

mkody commented Nov 10, 2023

Misskey and derivatives use both a mouse-over for a quick peek (shows only 11 people and then a "+[n]") and have either a link in the post's menu or a tab to list again all reactions and who used it, similarly to how Discord does it.

Screenshots

Mouse-over:
Mouse-over a reaction, showing the popover with 11 accounts who reacted with the first emote

Misskey's variant:
Misskey's "Reactions" element in the post's menu   Misskey's reactions popup

And on Firefish:
Firefish's reactions tab

Edit: Adding an icon + a total count next to the favorites and boosts, like the first pic from Essem, is a good idea and keeps it consistent with the other interactions.

@Plastikmensch
Copy link

Plastikmensch commented Nov 10, 2023

I'm still for removing modifications of the vanilla flavour.
It was frankly a naive mistake to suggest and doubles the workload of maintaining this beast.

Also this modifies locales managed by Crowdin again

@TheEssem
Copy link
Author

Also this modifies locales managed by Crowdin again

Ah, apologies; I didn't realize that's why they were removed. Fixed.

@@ -6,8 +6,8 @@ class NotificationMailer < ApplicationMailer
:routing

before_action :process_params
before_action :set_status, only: [:mention, :favourite, :reblog]
before_action :set_account, only: [:follow, :favourite, :reblog, :follow_request]
before_action :set_status, only: [:mention, :favourite, :reaction, :reblog]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From a server owner cost management and email reputation perspective, sending an email per reaction could get incredibly expensive really fast.

It would be great to have an option for

  1. roll reactions these up into 30-60min aggregate mails
  2. a server setting to outright disable email notifications for reactions

Personally, I would use (2) on my server, simply because the cost aspect of potentially sending 100s of mails to a user is not something I'm interested in bankrolling on behalf of my users, and it can have significant email deliverability impact as well if users get spammed and never opens/interacts with them.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reaction email notifications are disabled by default in user settings and notification emails of any type are only sent to inactive users anyways (unless a specific setting is manually enabled).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's great its disabled by default, but I do think it would be great to have a server setting to turn it off, with no way to turn it on - I really don't want to see someone (myself included) being burned by potentially expensive transactional mails due to malice of some trolls, or some random toot going viral and burning through mail credits.

It can be quite expensive for on-demand transactional emails, and can prohibit verification mails from going out if the server admin is using a pre-paid delivery plan with X mails per month.

Copy link

@Plastikmensch Plastikmensch Nov 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While the concern is understandable, this is not something this PR can or even should address.
As already stated, Mastodon rarely even sends e-mail notifications by default and most people don't enable those.
This just adds the option to receive e-mails for reactions, in line with other notifications.
Concerns about potentially burning e-mail credit should be brought up upstream, but this is pretty much a non-issue in practice.

@TheEssem
Copy link
Author

Once the Material Symbols set is ported, I'm thinking that the current "plus" icon could be replaced with the set's own "Add Reaction" icon to better indicate what it's for and bring it more in line with other UI implementations.
image

Copy link

This pull request has merge conflicts that must be resolved before it can be merged.

Copy link

This pull request has resolved merge conflicts and is ready for review.

@ShadowJonathan
Copy link

@TheEssem what're the blockers for un-drafting this, atm, btw?

Copy link

This pull request has merge conflicts that must be resolved before it can be merged.

@TheEssem
Copy link
Author

@TheEssem what're the blockers for un-drafting this, atm, btw?

I'm mainly just waiting for further review.

@ShadowJonathan
Copy link

ShadowJonathan commented Nov 15, 2023

If you mean maintainer review then I'd suggest making it non-draft, since else (fme) maintainers won't look at it

@ClearlyClaire
Copy link

I'm sorry I really don't have much mental bandwidth right now, and my priority is bringing glitch-soc to a more maintainable state. There's a lot I've postponed, and it's becoming a lot.

Copy link

This pull request has resolved merge conflicts and is ready for review.

@lunaisnotaboy
Copy link

Is this suitable for being merged into a fork?

Copy link

@lunaisnotaboy lunaisnotaboy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@TheEssem TheEssem marked this pull request as ready for review November 22, 2023 01:26
@lunaisnotaboy
Copy link

Running in production at michiru.me, and it works great!

TheEssem and others added 26 commits October 6, 2024 23:38
This was in a previous PR. Not quite sure how it didn't carry over.
Probably worth tackling later, but for now it's not worth worrying about; some other implementations (e.g. Misskey's) look to have the same behavior anyways.
This was done to announcement reactions in 1b0cb3b. Might as well do it here too.
This prevents things from breaking with embeds.
Copy link

github-actions bot commented Oct 7, 2024

This pull request has resolved merge conflicts and is ready for review.

Lastorder-DC added a commit to MaratangLife/maratang that referenced this pull request Oct 12, 2024
Squashed from glitch-soc#2462

Co-authored-by: Essem <[email protected]>
Co-authored-by: fef <[email protected]>
Co-authored-by: Jeremy Kescher <[email protected]>
Co-authored-by: neatchee <[email protected]>
Co-authored-by: Ivan Rodriguez <[email protected]>
Co-authored-by: Plastikmensch <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.