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

Prepend emoji to body text of messages containing files #963

Closed

Conversation

e-caste
Copy link
Contributor

@e-caste e-caste commented Oct 29, 2022

this should apply to:

  • message previews in the chat list view ✅
  • messages inside a chat ✅
  • notifications (I can't check since I can't receive notifications with my developer certificate)

This should help identify the nature of a message in lieu of a media preview.

Simulator Screen Shot - iPhone 14 Pro - 2022-10-29 at 12 27 19

Simulator Screen Shot - iPhone 14 Pro - 2022-10-29 at 13 03 47

this should apply to:
- notifications
- message previews in the chat list view
- messages inside a chat

this should help identify the nature of a message in lieu of a
media preview

Signed-off-by: Enrico Castelli <git@caste.dev>
@e-caste
Copy link
Contributor Author

e-caste commented Nov 11, 2022

Hey @SystemKeeper @Ivansss what do you think about this? I know it seems silly, but in my experience it should be a good enough UX improvement to be able to quickly recognise the type of attachment directly from the message text. Let me know if you need any change to be able to merge this, by the way I was thinking about adding one method per MIME type in NCUtils like the two I have added in #955.
Also as I mentioned above I can't test if this is the same text that is received in the notifications but I hope so, otherwise please tell me what I need to add.
Should I also handle the maximum character limit in any way? Cause if I add "🅱️ " it takes 2 characters away from the limit, one for the emoji and one for the space (even 3 in cases of emojis with ligatures such as person/hand+specific color e.g. 👌🏼).

@SystemKeeper
Copy link
Collaborator

Hey @e-caste
Sorry for not replying earlier :-). In general I like the idea. It's nice to see a poll or contact in the conversation list for example (also in push notifications). I do think however that it is kind of redundant in the chat itself, because if there's a shared contact (or map, or file, etc)., we already have a big icon, so I don't think we need another one. (Also I'm not sure about file sharing, because a folder does not look right for a .docx file, but that might be fine-tuning).
Actually I did create #976 with your PR in mind 😉 It would allow us to separate the message used in the chat and in other places. What do you think about that?
I can talk with Ivan about it next week. We first wanted to merge your preview enhancements, but other things popped up 😄

@e-caste
Copy link
Contributor Author

e-caste commented Nov 11, 2022

@SystemKeeper Yeah makes sense! It would also allow us to expand on this idea in the future, like for example Telegram shows a very small thumbnail of the actual attachment instead of an emoji for its kind (though it showed an emoji in previous versions).

@SystemKeeper
Copy link
Collaborator

Yea, that sounds like a nice idea! I think that makes more sense than emojis, at least for files and images. For "objects" (poll, map, contact, etc). I think emojis are totally fine

@SystemKeeper
Copy link
Collaborator

Hey @e-caste
just wanted to check with you, would you want to adjust this PR with the new situation (#976 merged) or should we take a look at some point? :-)

@e-caste
Copy link
Contributor Author

e-caste commented Dec 5, 2022

Hey @SystemKeeper thanks for asking. I don't think I'll have time in the near future for this, but you can absolutely add more commits to this PR if you need to update it to be able to merge it

@SystemKeeper
Copy link
Collaborator

Continuation in #1805

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.

2 participants