Feature addition/removal message #122
Description
In the design call 102, this PR about gracefully handling UPnP support came up. We are looking for design approaches to both the current QT GUI, and the new Bitcoin Core App.
For Qt, we should work with existing UI patterns and elements. We may also want to split this out into its own issue.
For the core app, we should try to generalize this pattern. In future updates, other features may be added or removed, and we should let users know about those changes. Some of that can happen on the download page, but the application can also do its part.
In this scenario for UPnP, a feature was removed, and there is an alternative one the user can migrate to. The application can do this for the user automatically.
Other scenarios and considerations:
- Different severities: Is this a critical change that the user should act on? Maybe the application should not even start or allow for other interactions until it is resolve. Or is it a "nice-to-know"?
- Is an automatic migration path available or not? Or a manual one?
- Should messages appear on every start? Or just once?
Related, we also spoke about gradual feature introduction based on adoption levels. For silent payments, for example, we may want to:
- First offer it as a secondary feature available via "..." options.
- In a later update, actually tell people the feature exists, but keep it in the options
- Then make both address types (single use and reusable) easily accessible in the primary UI (toggling via tabs, for example)
- Later make silent payment address the default and regular addresses only accessible via the "..." options
This is just an idea. And whether it's silent payments or some other feature, it would be good to bring users along as adoption happens (or not).
@rabbitholiness, you mentioned you already have an idea for this?