Custom Query (16363 matches)
Results (1225 - 1227 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #5183 | invalid | Better labels for snapshot Discard/Revert buttons | ||
| Description |
The labels on the snapshot buttons are confusing and ambigious. 1) Here's the short version: 1a) Relabel 'Revert to Current Snapshot' to:
1b) Relabel 'Discard Current Snapshot and State' to:
1c) Relabel 'Discard Snapshot' for the last ('current') snapshot to:
1d) Relabel 'Discard Snapshot' for other than the last ('current') snapshot to:
... and while we're at it... 1e) When the last ('current') snapshot is selected, enable these buttons also:
(... 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).
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 / conceptual 'model' that users expect to see. VirtualBox developers deal with these objects:
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 are logically a complete copy of the entire state of the VM at the time the snapshot was made
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 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.)
They may not conciously think about the Changes, and instead just consider the snapshots and the current state. Note, in the user's mind:
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?: 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.
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'. |
|||
| #2308 | fixed | Bi-directional clipboard failed to work | ||
| Description |
I have VirtualBox 2.0.2 installed on my Mac OS X 10.4.11, I am running Windows XP Pro with all latest patches on VirtualBox, with guest addons installed. When I have bi-directional clipboard enabled, copying texts from Mac (host) to Windows (guest) is impossible, and the function will make copy & paste text in Mac OS X (host) fail to work too; after copying text in Mac OS X (host), some strange characters, instead of copied text, will be stored in clipboard. |
|||
| #5368 | worksforme | Bi-directional clipboard not working (Win <-> Win) | ||
| Description |
|
|||

