Integrate release announcement

[daniellekirkwood]

As mentioned in an internal room, we've discussed having a 'release announcement'...

Option	Pro's	Con's
Full screen takeover, right hand side:	Space for more content Must be dismissed/hard to miss	New build that's not aligned with current company strategy
Top-left toasts:	Already exists Copy kept to a minimum (less to translate) and can link to a blog post	Easier to miss
Specific tool tips:	Specific content will make the new UI easier to learn	specific for each release (hard to repeat) New build that's not aligned with current company strategy

Open questions

• Where does the data come from?

[HarHarLinks]

(there is a "top-left toast" for update notifications on develop already)

[nadonomy]

@germain-gg in any solution, if we wanted to only show it once to existing users, do we have an easy way to detect that?

[daniellekirkwood]

As discussed yesterday we're going to choose a simple option to unblock the first release planned. @germain-gg could you provide an estimate for the chalkboard experience (without thinking too much about the long-term issues we've raised). If we have one for the header and one for the right panel - is that a few hours/days/weeks?

[grati-cule]

Have we considered creating a room called something like Element Update Announcements that appears in the left hand panel and contains each announcement we send out?

Element users are conditioned to consume messages this way so it seems intuitive to use it as the mechanism for announcements.

[HarHarLinks]

like https://matrix.to/#/#homeowners:matrix.org does for synapse? has the downside that it's impossible to show a diff from the currently installed version to the update.
or do you mean like a pseudo-room? maybe, but might as well be confusing e.g. if users expect to find that room in their other clients

[t3chguy]

@HarHarLinks it has an even larger downside of enumerating a lot of system admins into one list

[daniellekirkwood]

@germain-gg ping reminder :)

[americanrefugee]

@germain-gg @daniellekirkwood Here is the component for Release Announcement, which includes a proposal for the specific wording of each thing. WDYT?

[daniellekirkwood]

Great. Couple o' questions @americanrefugee ...

• Do we have confidence that folks call it the "title bar"? I've only ever heard it be the "Room header"
• Will we be showing all of them at the same time, or one after another (if so, do they need numbers and what order are they in?)
• I don't think we're changing the composer or the timeline for this first launch so we can keep those up our sleeve for a later date, right @germain-gg ?

[Johennes]

I don't think we're changing the composer or the timeline for this first launch so we can keep those up our sleeve for a later date, right @germain-gg ?

For #25883, we'd only need the second and the third, yes. I think we should talk about how these tooltips carry over across versions though. Should they only show in the version the change was released in? Or should they still be displayed if somebody updates from an older version, skipping over the version where the change was released?

[daniellekirkwood]

Should they only show in the version the change was released in? Or should they still be displayed if somebody updates from an older version, skipping over the version where the change was released?

I'm right in saying that we don't have a way to know if someone is new to the product or not?

I think it makes sense to show the tooltip in the release and maybe the one after? But, as you've mentioned, if someone jumps a few releases they will miss the tooltips.

Maybe that's the risk we have to take without an in-product release notes mechanism (which is a solution I would prefer). For example, Slack have a present icon so you can see what's new, and it's not intrusive. Beeper use a Matrix room to do so. @nadonomy have we explored these ideas and access points?

To unblock us for now, what about a time based approach? We're only going to be talking about the title bar and the right panel and that content is vanilla enough that if a new-to-element person sees it, it's not off putting. So maybe we show them for 4 weeks (see data here). It looks like after 2/3 weeks most people will have updated their version.

We'd only want to show it to one person once though... that's doable, right?

[Johennes]

I'm right in saying that we don't have a way to know if someone is new to the product or not?

We may not have that ability today but given that we can carry stored stated (e.g. your login) forward between updates, I think it should technically be possible for us to figure out if the user is on an initial installation or an update.

Beeper use a Matrix room to do so

Some concerns about this option have been raised here and in the comment after.

To unblock us for now, what about a time based approach? We're only going to be talking about the title bar and the right panel and that content is vanilla enough that if a new-to-element person sees it, it's not off putting. So maybe we show them for 4 weeks (see data here). It looks like after 2/3 weeks most people will have updated their version.

I like that. A time-based approach would also decouple the announcement logic from what our release cadence is entirely.

I'm actually wondering if we could even take it a step further and add no expiration at all? We'd put the announcements into a file in the repository and they'd show on every update unless you have already seen them before. When we feel that the announcement isn't relevant anymore, we remove it from the file and it will stop showing for updaters with the next release.

We'd only want to show it to one person once though... that's doable, right?

It should be, yes. We just need to store locally what announcements you have already seen.

[t3chguy]

Beeper use a Matrix room to do so

This is false. They use something that looks like a Matrix room in the UI but is actually backed by an RSS feed.

[Johennes]

@daniellekirkwood given our capacity bottlenecks, I'm going to descope this from the current room header / details initiative because I'm fairly certain that we won't get to it in light of other work.

[daniellekirkwood]

@Johennes I think we need something - this is a big change otherwise. Are any of the options above a really quick, fast way of announcing changes?

[Johennes]

Option one and two from the issue description seem cheaper to implement than option three. However, option three seems like the most effective one. I agree that having this would be nice but that feels like a project of its own as we'd use such an infrastructure for other features, too. So I'm really not sure if this should block the epic when we're already struggling to find the time to finish it. 😕

[daniellekirkwood]

Ok, so then do we re-open this issue, remove it from the epic and attach it to a future compound epic when we do have the time? This should stay on our backlog somewhere as we plan to do it in the future?

[Johennes]

Yes, that sounds like a good idea 👍