On 21 Nov 2007, at 06:40, Anton B. Rang wrote: > How does the ability to set a snapshot schedule for a particular > *file* or *folder* interact with the fact that ZFS snapshots are on > a per-filesystem basis? This seems a poor fit.
It's a poor fit for people who understand ZFS filesystems, but I'd argue that's not the case for Jo User who just wants to safeguard her stuff. The intention with the mockups is posted is that, eventually, filesystems would be created or destroyed on the fly as required, to match what the user wanted to back up. For a Phase 0 release, though, you would have to do that work yourself, and the GUI would only be a fairly thin veneer on top. > One possibility would be for the "enable snapshots" menu item to > implicitly apply to the root of the file system in which the > selected item is. So in the example shown, right-clicking on > "Documents" would bring up a dialog labeled something like > "Automatic snapshots for /home/cb114949". Yes, that might be a good idea, at least until we can automagically manipulate the filesystems in the background to match what the user *really* wants to do. > I don't think it's a good idea to replace "Enable Automatic > Snapshots" by "Restore from Snapshot" because there's no obvious > way to "Disable Automatic Snapshots" (or change their properties). > (It appears one could probably do that from the properties dialog, > but that's certainly not obvious to a user who has turned this on > using the menu and now wants to make a change -- if you can turn it > on in the menu, you should be able to turn it off in the menu too.) Yes, that's a valid point. I was hoping to avoid adding more than one ZFS-related item to the menu as it's already rather long, but you've spotted the flaw. Another possibility would be to remove the "Enable Automatic Snapshots" menu item as well, i.e. have the only on/off switch be the one in the Properties dialog. On its own, this would have the disadvantage of hiding the functionality completely, so you'd probably also want to do something like adding a Snapshot Properties item to the toolbar and/or menu bar-- this would open the Properties dialog for the selected file or folder, with the Snapshot tab frontmost. > If "Roll back" affects the whole file system, it definitely should > NOT be an option when right-clicking on a file or folder within the > file system! This is a recipe for disaster. I would not present > this as an option at all -- it's already in the "Restore Files" > dialog. Well, it was only a suggestion :) As I said in the accompanying text, if we *were* to have it there, it would have to be accompanied by a dire warning and a confirmation step, so there shouldn't really be any more chance of a disaster here than there is in the Restore Files dialog. But I'm inclined to agree, for the sake of saving the user an extra click on some occasions (when they *know* which snapshot they want to roll back to), the risk probably isn't worth it. > Also, "All files will be restored" is not a good description for > rollback. That really means "All changes since the selected > snapshot will be lost." I can readily imagine a user thinking, "I > deleted three files, so if I choose to restore all files, I'll get > those three back [without losing the other work I've done]." Fair comment... all the text in the GUI should, of course, be written (or at least scrutinised) by a technical writer in any final design, to avoid this sort of ambiguity. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:calum.benson at sun.com GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems
