Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature addition/removal message #122

Open
GBKS opened this issue Nov 7, 2024 · 1 comment
Open

Feature addition/removal message #122

GBKS opened this issue Nov 7, 2024 · 1 comment
Labels
idea Further information is requested

Comments

@GBKS
Copy link
Contributor

GBKS commented Nov 7, 2024

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:

  1. First offer it as a secondary feature available via "..." options.
  2. In a later update, actually tell people the feature exists, but keep it in the options
  3. Then make both address types (single use and reusable) easily accessible in the primary UI (toggling via tabs, for example)
  4. 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?

@GBKS GBKS added the idea Further information is requested label Nov 7, 2024
@rabbitholiness
Copy link
Contributor

@GBKS here are some initial drafts of how such messages could look like. The examples are made up, but should illustrate the different categories.

1 - Decision is needed
Decision needed

2 - Dismissible warning
Dismissible warning

3 - Pure info
Info

4 - New feature
New feature

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idea Further information is requested
Projects
Status: Todo
Development

No branches or pull requests

2 participants