Better labels for snapshot Discard/Revert buttons

[MarkCranness]

The labels on the snapshot buttons are confusing and ambigious.

1) Here's the short version:

1a) Relabel 'Revert to Current Snapshot' to:
Revert to Last Snapshot

1b) Relabel 'Discard Current Snapshot and State' to:
Revert to Last Snapshot then Discard Snapshot

1c) Relabel 'Discard Snapshot' for the last ('current') snapshot to:
Discard Snapshot, Keeping Current State

1d) Relabel 'Discard Snapshot' for other than the last ('current') snapshot to:
Discard Snapshot, Keeping Changes

... and while we're at it...

1e) When the last ('current') snapshot is selected, enable these buttons also:
Revert to Last Snapshot
Revert to Last Snapshot then Discard Snapshot

(... why force the user to stumble around the UI looking for the correct option? Just because they have selected the last snapshot rather than the Current State is no reason to disable the two buttons above.)

1f) Consider changing the 'Revert to Last Snapshot then Discard Snapshot' button icon.
Rather than a double up-arrow, how about a single up-arrow and a cross-delete, because this combines the functions of Revert and Discard?

1g) Until such time as the snapshots handle a BRANCHED tree, replace the tree with a simple vertical list.

The axis for snapshots is TIME. A tree, ever wandering off to the right of the screen, is just silly (until VirtualBox handles branched snapshots that is).


2) Longer version, and justification for the above:

2a) 'Revert to Last Snapshot'

One likely reason for the confusing labels is because there is a disconnect between the objects that the VirtualBox developers work with, and the objects 'model' that users expect to see.

VirtualBox developers deal with these objects:
- Snapshots.
- Snapshots store FORWARD differences between that snapshot and the next snapshot.
- Snapshots 'work' by protecting the base virtual HD and all of the previous snapshots, by providing a place to store changes to the VM. With all ongoing changes stored in the snapshot differences, those changes can be undone simply by abandoning the snapshot.
- The LAST snapshot is the snapshot that stores changes to the current state of the VM. In that sense, the LAST snapshot is also the CURRENT snapshot.

Some of the concepts that a VirtualBox developer understands (above) are not applicable to the UI displayed to the end user.
(Unfortunately, some of those concepts have creapt into the UI.)

Users (should) deal with these objects / imagine this 'model' in their heads:

- Snapshots.
Snapshots are logically a complete copy of the entire state of the VM at the time the snapshot was made

- Changes.
Between each snapshot, the VM state changes.
These changes might be stored in the next snapshot as BACKWARDS differences, or they might be stored in the previous snapshot as FORWARD differences, but the user should not have to worry about this implementation detail (I suggest).

- The Current State.
The last/most recent/current state (configuration, contents of disks, etc.) of the VM.

With '-' indicating a point in time, and '>' indicating the passage of time, the snapshot history for an example with 3 snapshots might look like the following to the user:
(I mean in their mind, this is the 'model' they have of how the snapshots work.)

- Base disk
- Snapshot 1
> Changes between snapshot 1 and 2
- Snapshot 2
> Changes between snapshot 2 and 3
- Snapshot 3
> Changes between snapshot 3 and the Current State
- Current State

They may not conciously think about the Changes, and instead just consider the snapshots and the current state.

Note, in the user's mind:

- There is no CURRENT snapshot, but there is a LAST snapshot (= Most Recent).

Consider an example where the three snapshots above were done 1-January, 2-January and 3-January, and it is now November.
Is one of those January snapshots 'CURRENT'? Not in the mind of the user.
The word 'Current' should not be used to describe snapshots.
Instead 'Last' should be used (or when the branched snapshot tree eventually arrives: 'Parent').

Thus: 'Revert to Last Snapshot'

2b) 'Discard Current Snapshot and State' -> 'Revert to Last Snapshot then Discard Snapshot'

Users may be familiar with using the snapshot 'Discard Snapshot' menu to remove snapshots.
Past experience has taught them that the 'Discard Snapshot' feature only deletes the snapshot, BUT the CURRENT STATE is retained.
Suppose, intending to discard the last snapshot, BUT RETAIN the current state, they click on Current State in the tree (for whatever reason).
Button 'Discard Current Snapshot and State' is enabled.
On the face of it, that seems to be the same as 'Discard Snapshot', or very similar...
There is the extra '... and State' on the end, but WHAT STATE? They think: "perhaps the last snapshot has some mysterious internal State associated with it?"
It doesn't say 'Current State', so I should be safe?

They click it, intending only to delete the snapshot, but instead end up Reverting the current state also.

'Revert to Last Snapshot then Discard Snapshot' emphasises the main function of this feature (Revert).

(But that feature doesn't work that way I hear you say?:
http://forums.virtualbox.org/viewtopic.php?f=9&t=23249)

2c) Discard Snapshot, Keeping Current State

The current label only tells half the story about what this feature does, which can lead users to make the wrong choice.

Suppose a user takes a snapshot, makes an experimental change and then decides to abandon the change, and the snapshot.
Perhaps not sure what button to use to undo the experiment and delete the snapshot, but knowing that they must revert back to the last snapshot, they SELECT THE LAST SNAPSHOT.
A button is then available:
'Discard Snapshot'
They know they want to discard the snapshot, but they ALSO want to revert the changes.
The button does not make it clear what will happen to the current state.
They think: Anyway, Discard that snapshot is what I want to do...
They click the button and end up NOT reverting their changes, but instead RETAINING their changes.

2d) Discard Snapshot, Keeping Changes

The current label only tells half the story about what this feature does, which can lead users to make the wrong choice.

- 'Keep'/'Keeping' versus 'Merge'/'Merging'

When Discarding a snapshot, the changes either side of it (preceeding it and following it) must be merged.
Because in VirtualBox the changes are stored in the older snapshot, as Forward differences, the changes must be merged into the PREVIOUS snapshot.

But consider a different way that a user might think about the differences: They may be familiar with incremental file-system backups, or an incremental database backup (backing up a SQL Server transaction log which clears the log). In those cases the 'differences' stored in the 'backup', or 'snapshot' (the backup could in sosme way be consider to represent a snapshot), are BACKWARD differences, in that they are the changes that happened BEFORE the backup was made.
Hypothetically, If one of those backups/snapshots were to be discarded, the changes would have to be merged into the FOLLOWING backup.

For this reason, I suggest it is preferable to NOT make a distinction of which DIRECTION any differences are merged (to the PREVIOUS snapshot or to the FOLLOWING snapshot).
(MUST the differences/changes be associated with the previous snapshot IN THE UI? I suggest not, i.e. DO NOT mention merge direction in the UI.)

Mentioning 'Merge' at all in the UI raises the question of "Merge what with what?", and is a technical / internal issue that the user probably needn't be bothered with.

I suggest that '...Keeping Changes' tells the user about the most important fact about the changes, without 'opening the merge can-of-worms'.


3) And ... VirtualBox developers: Thank you for the great software!

Edit: Ticket created: http://www.virtualbox.org/ticket/5183

[Sasquatch]

Will be worked on for 3.1.0, as I've stated in your other topic. Because this one looks a lot like your other, I'm locking this one. There are other topics about this if you search a bit.

[Sasquatch]

Is it really that hard to look a bit further down the list? I believe this thread explains everything in a lot less words than what you've written. This post is near book size, and I don't mean a simple child book but something like JRR Tolkien.