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

Revise snapshot feature copy #132

Open
GBKS opened this issue Dec 16, 2024 · 2 comments
Open

Revise snapshot feature copy #132

GBKS opened this issue Dec 16, 2024 · 2 comments

Comments

@GBKS
Copy link
Contributor

GBKS commented Dec 16, 2024

There's a thread (make sure to read this) in a dev PR, related to the copy used in the snapshot feature, that has gotten somewhat long, that I'd like to hereby extract from that PR and turn into a separate discussions.

I suggest we resolve this here and in design first. Once we're happy, we can then create a new PR with those tweaks.

I'll keep this description short. I still need to catch up with the latest (longer) comment and will do so in a reply. But feel free to take it away.

@yashrajd
Copy link

here's the background:

Sjors pointed out that the copy in snapshot section is inaccurate:

It's not really "transactions up to", it's all coins (utxo set) that exist at the snapshot height.

Maybe say something like:

It contains a snapshot as of block %1. Once loaded, all blocks from %2 to the present are download. After that Bitcoin Core > is ready to use, while all historical blocks from genesis to %2 are downloaded and validated in the background.
(intentionally leaves it vague what's in the snapshot)

His directional suggestion was:

I think it's better to be incomplete than incorrect. The nice thing about being vague is that it's clear to the reader there's more to learn.

Christoph provided his rationale, summarised roughly in:

We don't need to be 100% technically accurate and I'm not sure users are well-served if we're completely vague about this either. They should be able to form a good enough mental model for making decisions and understanding their impact.

I sympathise with both of these views, so I provided some context on the existing copy being the way it is: maintaining the mental model that's established by prior copy. But I also suggested some potential changes to the copy in line with Store's suggested approach (see comment below).

@yashrajd
Copy link

yashrajd commented Dec 17, 2024

Quoting myself below, short-circuited with my view that current copy is not egregious in any way, and can be retained in the interest of time.

"Load snapshot" screen that gives more detail about how it works.

This screen can omit mention of transactions "The snapshot allows you to start using the application more quickly. Once loaded, it will be automatically verified in the background. Learn more" instead of "You can start using the application more quickly by loading a recent transaction snapshot. It will be automatically verified in the background."

"Snapshot loaded" screen state that informs people what was imported, what to keep in mind and what will happen next (this is the screen that we are talking about in this thread)

I'd suggest something like "The loaded snapshot contains data up to [some date]. The initial download will continue now. > The snapshot is verified in the background." instead of "It contains transactions up to September 10, 2023. Newer transactions still need to be downloaded. The data will be verified in the background."

edit: fixed quotation level

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants