📑 New in apps changelog display

[blizzz]

Users and admins should have a brief info on what's new in an available app release, and the possibility to have a direct link to a Changelog.

• [ ] in an additional changes.xml the app developer will be able to optionally specify "What's new" info consisting of up to 3 bullet points with up to 100 characters each. (Provided this can be read from the appstore with the new update info).
• [ ] in the changes.xml the app developer will be able to optionally specify a link to a changelog page.
• [ ] when an app update is available, below the "Update to x.y" button a "What's new?" text is shown. On click a popup is shown with that info (if given, a placeholder text otherwise), and a link to the changelog (if provided). If neither are provided, the "What's new?" label is not shown.
• [ ] the information is provided by the app store along the other meta information, in the user's language
• [ ] A "What's new" popover on corresponding app shows the same short info after update, until dismissed (like for the Server what's new).

Appeareance on the apps management:

Mockups by @jancborchardt

[nickvergessen]

It should also be visible in the actual place of the app. I guess no one looks for new features in the personal section.

When a talk update was done, the info should be displayed as soon as the user visits index.php/apps/spreed the first time.

Of course this needs to be done by the app itself, I would say we should just provide a frame work how to do this, for displaying something like the first-run-wizzard is something I could imagine.

[blizzz]

The idea, as discssed with @jancborchardt, was to have as little interruption to the user as possible. That's why we did not go for notifications, for instance. Some apps may have not a page of their own (e.g. impersonate, e2ee, checksum), for others a common approach is not really feasible (richdocuments, various viewers).

[blizzz]

As ^ was discussed further on IRC, the takeaways: personally I am not convinced, anyhow opinions on this matter drift to different directions. Imho, we should go with this approach. Later, still something like a reusable Vue component can be offered to display an indicator on an app about news (not a popup). The risk of misuse for unimportant changes is there, but apps could do this already by their own implementations either way.

[jancborchardt]

A user-facing thing we could do is something in the left #app-navigation. Like a container which can be closed via an x icon in the top right. Similar to what https://github.com shows in the top right when you are logged in (will do a screenshot when they show news again).

[MorrisJobke]

(will do a screenshot when they show news again).

[juliushaertl]

 in the info.xml the app developer will be able to optionally specify a link to a changelog page.

We could also just used the changelog from the app store for that, since the store parses CHANGELOG.md files in the release bundles if they are available.

when an app update is available, below the "Update to x.y" button a "What's new?" text is shown. On click a popup is shown with that info (if given, a placeholder text otherwise), and a link to the changelog (if provided). If neither are provided, the "What's new?" label is not shown.

A "What's new" section on the personal settings shows the same short info (with version and date) after update. Entries only younger than 3(?) months will be shown there, older ones are expunged.

I would probably break this into two parts, admin related changelog (in the apps management) and a user related changelog as @jancborchardt suggested (in the app itself)

[blizzz]

We could also just used the changelog from the app store for that, since the store parses CHANGELOG.md files in the release bundles if they are available.

Interesting aspect. However, sometimes the md file is not present, or worse outdated.

The advantage would be that we can show it inline and do not require the user to open another website. The mock would need to be extended to reflect that @jancborchardt

I would probably break this into two parts, admin related changelog (in the apps management) and a user related changelog as @jancborchardt suggested (in the app itself)

@jancborchardt would be two sorts of "what's new" notification, same discussion for the server part. Especially for later I need a decision sooner than later. Makes sense imho. Your call.

[jancborchardt]

For sure a good idea to break it into two parts. The first part to implement is the admin side of course. But having it on the user side is also needed further down the line.

@blizzz what do you mean by that it needs to be extended to reflect that? Even if a changelog.md is present, I would say we cut it max to the first 3 lines, and encourage people to summarize it in max 3 points (more can be below of course).

[blizzz]

@blizzz what do you mean by that it needs to be extended to reflect that? Even if a changelog.md is present, I would say we cut it max to the first 3 lines, and encourage people to summarize it in max 3 points (more can be below of course).

@jancborchardt it's about the link for the changelog, not for the shown 3-line content. The changelog would not to be suited for this.

[blizzz]

For sure a good idea to break it into two parts. The first part to implement is the admin side of course. But having it on the user side is also needed further down the line.

So: separate content for end users and for admins.

[jancborchardt]

@blizzz oh sorry, that was a misunderstanding: By splitting into two parts I meant only the code, not the content. I don’t necessarily think we need separate 3 changelog points for admins and users. That will double the workload of app developers, and I don’t see the reason why the messages should be any different. Admins are users too?

[blizzz]

The thought behind is that for admins it makes sense if some behaviour changed, setting was added, manual operation is necessary, while this is all irrelevant for end users.

[blizzz]

We had a discussion today with @jancborchardt and @MorrisJobke

• the change info should be written into a new file inside appinfo, e.g. changes.xml
• on app update the appstore parses this file and stores the data
• the app server provides the whats new information with the other meta data (translated)
• vue component for presenting the info in a box absolutely positioned in the lower left corner
  • the server info goes into file app

[MorrisJobke]

vue component for presenting the info in a box absolutely positioned in the lower left corner

I thought lower right, but in the end it shouldn’t matter that much 😅

[blizzz]

that's were in most cases the sidebar is, and the first idea was to put it into it.

Another question that comes to my mind, what to do with it on mobile view? Not showing at all? Would tend to it, unless, i guess in some places / for some people it might not be so uncommon to operate with mobile devices only.

[MorrisJobke]

It seems that this one will not make it to 14, right? Move to 15?

[blizzz]

Yes, no way to get it done in time, sadly.

[skjnldsv]

So in the end, is this done?

[MorrisJobke]

This one is for apps - #10050 is the changelog of the server for users. ;)

[skjnldsv]

Arf, sorry :)

[blizzz]

Updated description according to https://github.com/nextcloud/server/issues/9165#issuecomment-395445072

[MorrisJobke]

@blizzz It seems this didn't made it -> moving to 16.

[MorrisJobke]

Let's move it to 17.

[ghost]

Was just about to add this feature request :) It would be great to have a short changelog directly in the app list/details.

[alexbijma]

any news about this? i see it's added to version 17.0.3 will it be included in that version or do you expect to have it in a later version?

[jancborchardt]

As an update, for users this might be nice for each Nextcloud version, like the firstrunwizard. It could be a simplified version of the release post with a link to the full one included.

[szaimen]

So I thought about multiple ways how to solve this. I came up with three solutions:

1. Having a dashboard widget that shows new features
2. Having a document in your files that sums up new features
3. Putting it in a modal that opens automatically one time once you log in after a minor or major update

My thoughts on the solutions above:

1. Disadvantage: The dashboard widget might be hidden in the overall amount of widgets and not well to discover, also admins might change the default app to something else
2. Disadvantage: Initial files only get copied on user creation. Also on some instances might the root folder not be writeable
3. This is well enough to discover, and actually what the firstrunwizard does. So we could think about putting the summary about new features as an additional page into that --> will be working on a mockup for that as it sounds like the best solution.

[szaimen]

Here is the mockup that I've created. It should be the first page after the introduction video, before the A collaboration platform slide. The firstrunwizard should then open always for each user once after a minor or major update:

cc @nextcloud/designers WDYT? :)

[susnux]

We could also just used the changelog from the app store for that, since the store parses CHANGELOG.md files in the release bundles if they are available.

I would back this, we already parse changelog.md which is pretty standard. So as an app maintainer I would not be happy to have a new file (changes.xml) to also maintain for the same purpose.

[jancborchardt]

@szaimen yeah, the option like the first run wizard seems the best.

• It would best be a separate modal though. "What's new" instead of "Info". People don't want to click through the first run wizard stuff every release :)
• As said above: "It could be a simplified version of the release post with a link to the full one included." – we should much rather do that than paste a changelog. Remember this will be seen by each and every single user, so it's important it goes through editing by marketing @jospoortvliet @cartierbresson
• We can then have 3 slides for "What's new" as well. 1st for the short info like the tweet, 2nd for the video for example, 3rd for additional links like full blog, tweet, toot, etc.

[szaimen]

• It would best be a separate modal though. "What's new" instead of "Info". People don't want to click through the first run wizard stuff every release :)

I disagree but lets discuss this tomorrow in our design call. It can definitely be part of it if it is the first slide after the video imho :)

• As said above: "It could be a simplified version of the release post with a link to the full one included." – we should much rather do that than paste a changelog. Remember this will be seen by each and every single user, so it's important it goes through editing by marketing @jospoortvliet @cartierbresson

Yeah that would indeed make sense

• We can then have 3 slides for "What's new" as well. 1st for the short info like the tweet, 2nd for the video for example, 3rd for additional links like full blog, tweet, toot, etc.

Not sure about that yet. Could also talk about it tomorrow in the call :)

[nickvergessen]

@jancborchardt that then sounds like something for "Hub"/shipped things only.

The idea from back then was an option to have this available for everyone. So also other "bigger" apps like Forms, cookbooks, etc. could show case their stuff to users when publishing their major (not aligned with Nextcloud Hub releases).

I would back this, we already parse changelog.md which is pretty standard. So as an app maintainer I would not be happy to have a new file (changes.xml) to also maintain for the same purpose.

@susnux as per above, this is something very different from changelog.md at least for me. In Talk on a major we have 3 blocks (user, admin, developers) with multiple items each. But we definitely would not want to show all of them prominent like this in the modal. But instead of some them should be there, maybe with a bit more explanation and a screenshot or something.

[jancborchardt]

@nickvergessen yep, but as always we need to start somewhere. :)

Showing a whole changelog, even just max. 3 entries for each app will be unwieldy. There needs to be some editing, especially since this will be shown to every single account.

And we do these great keynotes incl video and social media messaging, so it would be a shame to not re-use this. :)

[jospoortvliet]

I think Jan's proposal is entirely usable.

The content of the first pane (or all 3) can be delivered by marketing, I think (we'll have to sync with Jocelyne ofc but I doubt it's an issue). I like the 1 pane text (and image, pls?), 1 pane video, 1 pane 'links to read more' approach.

There's one concern I have: when the user clicks it away (maybe because they are in a hurry right now) there should be a way to get the dialog back. Perhaps there should be a notification, too, which brings up the dialog. Then you can bring it back upon demand. Or, as notifications are ofc also not persistent, it should after the first time follow the about dialog...

[szaimen]

There's one concern I have: when the user clicks it away (maybe because they are in a hurry right now) there should be a way to get the dialog back.

this is one of the reasons why I would it as additional pages into the firstrunwizard :)

[jancborchardt]

There's one concern I have: when the user clicks it away (maybe because they are in a hurry right now) there should be a way to get the dialog back.

this is one of the reasons why I would it as additional pages into the firstrunwizard :)

@szaimen this is why in our call I mentioned to have an entry "What's new" in the account menu, right below the "About" entry which triggers the firstrunwizard. ;)

• Firstrunwizard/About: Mission & Vision
• What's new: Specific to this latest release

It makes sense to separate this. :)

[szaimen]

It makes sense to separate this. :)

I still disagree. But ss I said, lets discuss this tomorrow in our call :)

[susnux]

So if I get it right, this is now scoped to a "whats new in this hub version"? This dialog is shown instead of the first run wizard if the wizard was already shown - meaning on every update?

So the initial feature request is descoped here, as it was about administrator information "whats new in this app version, so should I update?". And is now a "whats new in this release - what can I now use".

But then this dialog will be bound to core- or shipped-apps as 3rd party apps like forms are updated also between hub releases.

[szaimen]

Good point. Since I am still working on a mockup, i might try to address this point as well if time allows.

[szaimen]

I now created a mockup, first for new Hub releases. Currently under review by the Design team. Will let you know as soon as I have their feedback

[szaimen]

Here is now my final mockup:

Mockups

Please let me know if you have any feedback or question :)

[susnux]

admins should have a brief info on what's new in an available app release

This is implemented already, admins can look at the "changelog" appsidebar tab of the app details.

For users apps currently have to provide their own dialog (like talk is doing).

[sorbaugh]

To add to the current scope, these requirements must be met additionaly:

• Apps can optionally also provide a "what's new" segment when they are updated. App devs decide wether to use this or not.
• Upon an app update, a notification (if available) will be shown to all users of the instance displaying what is new in the app.

[ChristophWurst]

^ should be about this app

[susnux]

^ should be about this app

Think this is about #42547 (And currently just a placeholder)

[nickvergessen]

Unbinding from the feature that was delivered and reopening, as (not-shipped) apps still don't have an option to provide a changelog

[susnux]

Unbinding from the feature that was delivered and reopening, as (not-shipped) apps still don't have an option to provide a changelog

They have. Implemented in https://github.com/nextcloud/server/pull/43967 Documentation on how to use it: https://docs.nextcloud.com/server/latest/developer_manual/app_development/info.html#changelog