Replies: 10 comments 7 replies
|
A good idea that I agree should be part of Monize. Here are some thoughts: Phase 1
Phase 2
This could also be useful as a New User Introduction |
|
All will works if someone make big upgrade, for example from 1.13 to 1.18? |
|
No, it will just show the release notes for the latest version. Otherwise, it will get very large, very quickly. They will have to look at the release notes for previous releases, if they really want to. |
|
Got an initial walkthrough done. Currently building the "What's new" feature highlight for foreign currency transactions. Will have the beta ready in a few hours |
|
Beta is updated. Try it out and let me know if you see any issues |
|
After end multicurrency tutorial i dont know how to open changelog to see other tutorials. It reopen when i remove pods. When i want to click "Show me" in Whats new section, what new window going out. |
|
I think they attachments should have short tutorial, to show how charged are in this release. Also, I think that new features should we release in major (X.Y) upgrades, not minor (X.Y.Z) |










Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Problem
After a container upgrade, the app says nothing. Features ship silently and users discover them by accident (or never) -- e.g. the loan overpayment simulator's goal-seek, or the support backup, are easy to miss unless you read the GitHub release page. We already tell users an update is available (
UpdateAvailableBanner+UpdatesService), but nothing tells them what they just got once they've upgraded.Proposal: a "What's New" screen after upgrade
Phase 1 -- release-notes digest
On app load, when the running version is newer than the version the user last saw, show a What's New dialog with the release notes for every version they skipped, and stamp the seen version on dismiss.
Almost all the plumbing already exists:
UpdatesServicealready knowscurrentVersion(backend package.json) and there is a per-user version-stamp precedent:user_preferences.dismissed_update_version. Phase 1 adds a siblinglast_seen_version.docs/release-notes/<version>.md(CI publishes them as the GitHub release body). They ship inside the image, so a small backend endpoint can serve the digest for the traversed version range with no network dependency -- unlike the update check, this works fully offline.user_preferences. The tour offer from Phase 2 respects the same switch.Phase 2 (optional) -- a short in-app tour of what changed
The What's New dialog can additionally offer a "Show me" tutorial: a lightweight spotlight overlay that walks through the release's highlights in the UI itself -- navigate to the changed screen, highlight the new control, one sentence of copy, next.
Open questions
If the approach sounds right I'm happy to build Phase 1 first as its own PR, with Phase 2 as a follow-up once the manifest format is agreed.
Research and drafting AI-assisted (Claude Code); grounded in the current
UpdatesService/ release-notes pipeline.All reactions