Tags dont display image and link previews

[Zabuzard]

Overview

Right now we use embeds for our tag system, but embeds (by default) dont display previews of image links and links in general.

This results in a major UX drawback, compared to the old Dyno system:

Install

/tag install vs ?tag install:

Ask

/tag ask vs ?tag ask

Ideas

At the top of my head, I see two possible fixes:

• the easy fix - we just go back to plain messages instead of embeds
• the advanced fix - we parse the content, identify all links and attach them as proper image/link to the embed, so that a preview is generated
  • this could be just attached to the very end of the message, like it is right now in the dyno system
  • or, but probably more complex, be added exactly at the point of mentioning in the message. but that likely requires splitting the message in multiple.

[java-coding-prodigy]

I am for the advanced fix

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[Tais993]

Another possible solution is to allow setting an image for the embed, thus by command. This results in a better looking UI most of the times, and the few times multiple links are required we'll have to go with the advanced fix.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[Tais993]

A total of 10 embeds can be send, so excluding the tag 9 more embeds. While I doubt we'll ever go over that, it does still require us to talk about it's behavior.

How can we "escape" links, so they don't get rendered? And what to do if 10 or more links (which result in embeds) are found, we'll error or cut off?

And images, do we want to send them as a file, or add them to the embed? If we want to add them to the embed, we'll have less room for links

[Zabuzard]

A total of 10 embeds can be send, so excluding the tag 9 more embeds. While I doubt we'll ever go over that, it does still require us to talk about it's behavior.

Indeed, good point.

How can we "escape" links, so they don't get rendered?

I would say, using the same syntax as Discord, namely <http://...> instead of just http://....

And what to do if 10 or more links (which result in embeds) are found, we'll error or cut off?

I would just display as much as possible (so 9 previews in most cases) and silently not display the rest (without errors).

And images, do we want to send them as a file, or add them to the embed? If we want to add them to the embed, we'll have less room for links

Whatever looks better and more similar to how Discord behaves. In particular for mobile. I think for images it wouldnt matter much, they are probably properly displayed in both cases.

We have to see how to add Link Previews though, you are right with that.

[niklaswimmer]

And what to do if 10 or more links (which result in embeds) are found, we'll error or cut off?

I suggest we never let that happen in the first place. The tag-manage command should reject tags with to many unescaped links (or images) and ask the user to explicitly choose which images to send embed. If there should ever be the situation where a tag still contains to many links (idk, manual entry in the database?) I would send an error back to encourage people to fix it.

I would say, using the same syntax as Discord, namely <http://...> instead of just http://....

I like that, simple and concise.

[Tais993]

I suggest we never let that happen in the first place. The tag-manage command should reject tags with to many unescaped links (or images) and ask the user to explicitly choose which images to send embed. If there should ever be the situation where a tag still contains to many links (idk, manual entry in the database?) I would send an error back to encourage people to fix it.

I rather accept it and send a warning that the user has 1 link too much, if we end up going for the error approach we should send the tag they gave us back. So they can edit it and don't lose all their process.

[niklaswimmer]

I rather accept it and send a warning that the user has 1 link too much, if we end up going for the error approach we should send the tag they gave us back. So they can edit it and don't lose all their process.

A warning is fine as well, but you are right, we should definitely send the tag's message back. For the warning approach as well, since we want to encourage the user to fix this problem (otherwise it is like saying "there is a problem, but if you want to fix it you need to write everything again"). The returned message should furthermore be in a state where it can be copied directly, therefor all special sequences escaped.

So to sum it up, either send a warning but accept it, or error out, but in any case send the user their message back for editing.

That said it would be somewhat cool if that would be the general default for the tag-manage command, to send back the new message, unescaped and escaped (via buttons or something), though this probably is out of scope for this issue.

[Zabuzard]

@Tais993 Any hints on how to get such a preview image? Lets say I identified a link in the message. Now I want to add an embed that contains a preview image for the link - does JDA have something for that?

I guess for actual png files (and similiar) its trivial, since we can just download the data and "attach as file", or is there something better?

[Tais993]

I'd just add it as attachment yeah, means we don't share the same limit of 9 for both images/videos and links.

We find a link We check or it's escaped, if not.

Check or it's a video/image, if it is add as attachment If we can't identify the link, put it in the message's content.

Hopefully that makes sense?

[Zabuzard]

Yeah but how do you get Discord to display an image preview of a non-picture-link? Like https://www.google.de/?

Or is that not possible?

[Tais993]

Just by adding it in the message's content. If you add the link in a spoiler, it's maybe nicer UX wise, and it still gets rendered.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label, comment or add the valid label or this will be closed in 5 days.

[Taz03]

i prefer the easy fix