Handle messages editing

[YuriRomanowski]

Clarification and motivation

"Message edited" event was already mentioned in an issue #4. Let's discuss how we handle messages editing in more details here

Original suggestion was, given a message, to memorize what references we already processed from that link and process only new references that appeared upon editing and report these references in a new ephemeral message. What I don't quite like in this approach: our ephemeral messages needs a context of the original message, and so the latter should be somewhere close to the ephemeral one. And if some messages were added after the original one, and then it was edited, then the ephemeral is going to appear "in the open field", and it can be hard to figure out what it is related to. To solve this problem, we could for example add a reference to the original message on top of the ephemeral.

Also, instead, we could attempt to keep the corresponding ephemeral message just right after the original one, and edit it periodically. But the Slack docs say that it's not possible to edit an ephemeral directly, only on some user interaction with its interactive blocks (see link). So, one possible solution is:

• When someone posts a message with time references, we send ephemerals to all the users in the channel
• When an original message is edited, we memorize it's most fresh version in our bot;
• Ephemeral message that we posted has an interactive button, say, "Refresh", and when a user triggers it, if we have more recent version of that ephemeral, we replace old version with it;
• So, every user, if they see that the original messages was edited, can trigger "Refresh" button and get a fresh version of time references

The disadvantage of this approach is that if someone didn't understand that they should toggle the refresh button they could easily get wrong information from the ephemeral. But we can just explicitly write in the ephemeral "Toggle this button if the original message was edited" :smile:

Another possible option that I thought about, is that, after getting a message with time reference, we can, instead of emitting any ephemerals immediately, just edit the original message, adding the interactive block to it, saying "translate to my timezone". After triggering this button, bot sends an ephemeral to this user with all needed information about time references. I think that this version is more convenient because the user controls all the flow himself. The only disadvantage is that we have to edit the original message, and sometimes it's important to know whether this message was edited by the sender or not.

What do you think guys? I didn't try how can these ideas implemented technically, but from docs it seems that we can do this. Let's discuss it here

Acceptance criteria

• Discuss how messages editing should be handled
• Implement the best idea

[Martoon-00]

And if some messages were added after the original one, and then it was edited, then the ephemeral is going to appear "in the open field", and it can be hard to figure out what it is related to

I fully agree here.

The disadvantage of this approach is that if someone didn't understand that they should toggle the refresh button they could easily get wrong information from the ephemeral

We can probably also attach the original time to the ephemeral message. But this is sorta a crunch indeed.

---

To add some thoughts, let me also quote a part of one StackOverflow answer I have stumbled upon:

A message created with chat.postEphemeral that itself has no interactive features can never be explicitly deleted. Once it's delivered, it's like a ghost and will disappear following a restart or refresh.

And disappearing after restart is probably not what we want. So it may seem like ephemeral messages is a bad thing to go, but probably we have no alternative.

Probably we really should think into the direction you mentioned - buttons that the user will have to click in order for ephemeral message to be generated or updated. That's not so cool as automatic update, but here Slack just limits us.

As a last check, I would probably investigate the existing Slack apps. If some popular apps that would apparently benefit from automatic updates do not implement them, then for sure we have to handle this differently too.

[YuriRomanowski]

Well, the "ideal" implementation I imagine as follows: after the original message our bot sends a persisting message, which is different for all users and always keeps up to date with the original message :smile: But it's impossible unfortunately.

So, I think we will need to add a button, either directly in the original message (it has a big disadvantage, but looks more smart), or in the next persisting message that is just for the button. After clicking that button, we can send an ephemeral to the user with up-to-date time references.

We can also think how this ephemeral will be delivered. At first, I thought that it will be sent to the same channel, but maybe a better option is to send ephemerals to in private user/bot chat? Because if the original message is somewhere high in the channel, direct sending will not make user to scroll the channel up and down.

[Martoon-00]

At first, I thought that it will be sent to the same channel, but maybe a better option is to send ephemerals to in private user/bot chat?

Yes, that's an option that is important to mention. I would personally rate it as 4/10, it resolves some problems, but IMO things related to the channel are better left in that channel.

[Martoon-00]

Another option that we can consider (but it's fat not my favourite, just mentioning it): post a normal, non-ephemeral message that would include times in all timezones matching the present users :smile:

They can be added using Slack attachments like on the picture, this way it would be hard to pick time addressed to someone else, and the large output added by the app won't be too distracting. But still, that sounds quite annoying for large channels.

[Martoon-00]

And continuing this brainstorm, yet another option which branchouts from @YuriRomanowski's suggestion with buttons: just create a modal dialog when the button is clicked and show the time in that modal, instead of working with ephemeral messages.

It will be less convenient, but a significantly more robust option. Something to think about here :thinking: :thinking: :thinking:

[YuriRomanowski]

@Martoon-00 in the https://github.com/serokell/tzbot/pull/27 PR what you say here was implemented, it's always possible to translate whatever message you like, even in the direct message chats. But I think ephemerals are not so bad, because usually messages are not edited many times, and sending ephemerals immediately will save the user from unnecessary clicking buttons. I think that on the original message we should send ephemerals always immediately. And for message_edited event I think we can send an ephemeral without any time references, because if we put time references there we also should put the original message, and such ephemerals will be too bloated. Just say "message time references were edited. Click to view it". What do you think?

[Martoon-00]

Yeah, after looking at how it looks like in #27, I agree that ephemerals work and nice to have.

And for message_edited event

Making them even not very much bloated would really be bad - for a message that seemingly randomly appears in the chat.

If we just post a link to a message with "Click to view it", how will the user see the translated time? He will jump to the edited message along with the ephemeral message next to it that contains outdated info, and I'm afraid it would be too tempting for a user to just read the time in that ephemeral.

[YuriRomanowski]

it would be too tempting for a user to just read the time in that ephemeral.

OK, so we can post the full ephemeral again, but with the message link on top of it?

[Martoon-00]

Hmm, won't there be a way to edit the ephemeral if it contained buttons? Maybe in the first ephemeral (that's right after the translated message) we could leave an update button, and on edit submit such ephemeral: "Timestamp in \\ has been updated, click Update to recalculate the time"?

[YuriRomanowski]

Hmm, won't there be a way to edit the ephemeral if it contained buttons? Maybe in the first ephemeral (that's right after the translated message) we could leave an update button, and on edit submit such ephemeral: "Timestamp in \ has been updated, click Update to recalculate the time"?

Yes, it's possible. We can implement it. Let's do it this way?

upd: Hm, if you mean to edit the first ephemeral on the original message editing, it seems it's not possible (we can edit them only when the user interacts directly with the ephemeral). At first I though that you just propose to leave an update button inside the first ephemeral and user can update the ephemeral whenever he wants.

[Martoon-00]

At first I though that you just propose to leave an update button inside the first ephemeral and user can update the ephemeral whenever he wants.

Yes, that's what I mean. And on message editing submit another ephemeral asking to press that update button.

This looks like the least painful solution to me. If you agree, let's probably go with it.

Let me also ask @dcastro, he is back from vacation now and may give some thoughts here too.

[YuriRomanowski]

Now, I think that we should not add extra buttons to the original ephemeral for same reasons why we deleted "report" button before: it's not used most of the time, but it takes space, which can be annoying. How about another solution: on message edit send an ephemeral containing the link to the original message, the button "click here for details" which will show our "view" modal with message text and translations and optionally a reminder that entrypoint from the message context menu also can be used. You @Martoon-00 said that old original ephemeral will confuse the user, but it seems that we can't avoid this, and also I think that the user is likely to notice time references mismatch and won't trust the old ephemeral, rather check using the entrypoing.

[Martoon-00]

it's not used most of the time, but it takes space, which can be annoying.

Oh, that's fair. Even if it wasn't, having two buttons is not more annoying that having one, this would make my reasoning for avoiding "Report issue" button invalid.

but it seems that we can't avoid this

And that's also true.

However, the presence of "Update" button would at least make it clear that the time may be outdated, without it the user may rely on the bot and make a mistake.

Maybe in the new message, we could optionally remind the user that the old ephemeral is outdated?

I think that the user is likely to notice time references mismatch

I would not think so. People are bad at textual comparisons. Moreover, for me as a user it would be tempting not to look at the original message at all since looking at two different time entries will increase the chances of mis-remembering the right time.

---

Meh, looking at this, I think for confuse-everything users the best UX would be, on edit, to jump to the original message and manually remove the ethemeral next to it :smile: Slack functionality is really limited.

[YuriRomanowski]

Maybe in the new message, we could optionally remind the user that the old ephemeral is outdated?

Good thought! I really also decided that it would be good to add this note to the on-edit ephemeral.

Meh, looking at this, I think for confuse-everything users the best UX would be, on edit, to jump to the original message and manually remove the ethemeral next to it

Let's just hope that people will not edit their time references very often :rofl: Indeed I believe it's something like not "comme ils faut", if one edits his time references too often his colleagues are very likely to be confused.

[dcastro]

How about another solution: on message edit send an ephemeral containing the link to the original message, the button "click here for details" which will show our "view" modal with message text and translations and optionally a reminder that entrypoint from the message context menu also can be used.

I fully agree with sending an ephemeral with a link to the original message, when a message is edited. This way the user can tie the new ephemeral message to the original text message, which solves the problem described in this issue.

Not sure I agree with the button + modal. Is the purpose of this to avoid cluttering the window?

If so, I'm personally not too concerned about clutter, as I don't think it's likely to happen often, and therefore not a workflow that needs to be optimized or justifies special handling.

My reasoning is the following:

• Most messages, in general, are never edited.
• Of the messages that are edited, only a small percentage of them have time references.
• Of the messages that are edited and have time references, only a small percentage will have different time references between edits.

So I personally think that something like this is just fine:

[This message](link to msg) has been edited:

"10am" in Europe/London         00:30, etc

IMO, we should optimize for clarity (which the example above does), but not for removal of clutter.

[YuriRomanowski]

So I personally think that something like this is just fine

What I'm also concerned about is that time translations always were somewhere near the original text. In your example it can be hard to reason about this time reference, what it is about? We can't say without the original message. Or do you believe that messages are mostly often edited just right after they were posted? I can't say this for sure, but if yes, this approach is sensible.

[YuriRomanowski]

Not sure I agree with the button + modal. Is the purpose of this to avoid cluttering the window?

So, maybe I should have paid more attention to my motivation, but in my solution the main element was the link to the original message, and button + modal was just an additional option (I wouldn't mind against just removing it). The main idea was to easy return the user to the context of the original message with the provided link, and after that to suggest him to use entrypoints to get the new translation.

[dcastro]

In your example it can be hard to reason about this time reference, what it is about?

The link to the original text message solves that, right? You can click it and scroll back to the original text message to see the context. It's not perfect, because the 2nd ephemeral and the original text message are still physically apart, but it's good enough IMO.

Or do you believe that messages are mostly often edited just right after they were posted?

I wasn't thinking of that, but yes, that seems like a reasonable assumption.

Personally, if I posted a message like "hey, let's have a meeting at 10am" and 10 mins later changed my mind, I wouldn't edit the original message. I would simply write a new message (in a thread or in the channel) like "sorry, I meant 11am folks!"

[dcastro]

The main idea was to easy return the user to the context of the original message with the provided link, and after that to suggest him to use entrypoints to get the new translation.

Oh, I get it now! So something like this:

[This message](link to msg) has been edited. Please use the context menu to convert any new time references.

?

That seems reasonable too.

I support this option (let's call it option 1) and the one I suggested above (let's call it option 2).

I have no real preference between the two. Both solve the issues we discussed, both are relatively easy to implement.

[YuriRomanowski]

Oh, I get it now! So something like this

Yep, that's something that looks cool to me. Maybe we also should add the note (formatted with italics) that the original ephemeral can be invalid and can't be trusted, only the entrypoint can be trusted :smile:

[Martoon-00]

I agree with the conclusions made here :+1:

---

I also wanted to note that IMO the need to edit the original message, maybe quite late, is not a so rare use case.

If I declare some global event and post a large message with @channel mentions, in case of time updates I will want to drop a short additional message about time change and update the original post - because people will likely look at that original message for all the information.

Or, maybe this case is rare, but such a large event may affect many people, so this use case is quite considerable.

[YuriRomanowski]

Well, after I got a draft implementation, it seems I changed my opinion a bit. I wanted the new ephemeral to have a message permalink in order for user to easily get the message text by clicking that link. But when a user even hovers over that link, the updated text is already shown in a very convenient way - and, what is important for us, above the ephemeral text. And if we put translation of all time references to that ephemeral, we'll win the jackpot: user is able to see at the text and translations near each other, and if required he can return to the message itself (if it's very big for example). So I'd like to just put all the time references translations to the after-edit ephemeral. Does it make sense?

[Martoon-00]

Interesting, really :thinking:

As far as I can see if I check, only about 20 words will be quoted. That's not enough to see all the original time references, but should be enough to recover the context.

However again, if the user makes 2 or 3 edits in a row, wouldn't that be too much text intercepting the normal messages flow? Although if, as @dcastro noticed, we expect edits to be rare, then that's barely a big deal.

From other points of view, this appears to be very convenient.