Re: [Deja-dup-hackers] Partial restore, take 2


On Jul 18, 2010, at 11:49 PM, Allan Day wrote:

Hi Deja-Dup crew! :)

Allan Day, as our resident usability advocate, what do you think of
this and the previous partial restore mockups?  I would appreciate a
more experienced viewpoint than my own.

The design seems to be heading in the right direction, though it still
seems overly complex. This could do with a proper design person (ie. not
me ;) ) to have a look at it. I do have a few ideas though - I'll try
and get something together to show soon. Until then, some general

* Nautilus integration would be great. It should be possible to access
previous versions of a file or directory from the file browser.

As far as I got with my research, this is quite hard. To do this we would need to show files that don't exist (any more) and as far as I understood it's API for extensions this is not possible - you can only use files that are already there.

That said, implementation of this would be possible if we would a make a patch for Nautilus or make this integral part of Nautilus, which could take a lot of time. If this is highly desired I might do some research in this direction. This then of course offers high degree of integration but also brings other problems (demanding, release cycle become linked to Nautilus, ...) but offers other rewards.

If this is what we want I have no problem of doing appropriate research and work (for a start I pinged one of Nautilus hackers but haven't got his response yet).

* It would be nice to be able to open and copy from backups as well as

I'm not quite sure what you mean by this? If I understand you correctly this is what we want to achieve with this feature? ;)

* Restoration should be undoable - ie. a backup should be done as part
of the restoration process. Restorations should be marked in the restore

Undoable how - that there shouldn't be cancel button? Depends, I would say this needs testing how fast we can do restore - if restore can be made instantaneous then yes, I would agree, however, if we have more then 3-5 seconds per file, then we are in a bit of a gray area that may require cancel button, especially if user selected a large number of files.

* Users will probably be interested in seeing the changes between
backups. Is it technically feasible to display this kind of information
(either as diffs, number or size of changes) in the UI?

Yes, but only on request, otherwise it is too slow. Basically we need to restore all versions for which user is interested in, restore them to temporary location, display diffs and only after user selects the version that he would like to restore that we actually copy from /tmp to original location. How to implement diffs into all this requires a bit more thought.

I've got some comments below for this v2 mockup.  It's a nice and
flashy mockup overall.

1) I'm not sure how the "select a date range" option works either as
you try to enter one or visually after you select one.

You either click on calender and select a specific date or you slide back (we mark the most interesting dates). Later on I got the idea of using a separate mark on the top ( with "tuki" replaced by date in production version of course) that would show the date of backup that user selected (and remove the input fields for date and only leave small calender button if user really want specific date selection.

Yes, we can probably come up with a better widget for this. I've got a
few ideas here.

Well, the idea is that we have a slider that is configured depending on how far from first backup we are. First two options are "hard coded" (latest revision and last backup) since they represent probably the most interesting feature for our users. To give users a hint that they can slide back in time, it would probably also be good to include another "hard coded" version "First backup".

Gtk.Scale seems nice but is not quite what I want (because it fills itself from start value) - a widget that would not fill itself and still offer a mark at current value would be a better option. For now, to keep things simple, I kept the Gtk.Scale (see for how it looks).

2) You probably don't need two buttons for "Queue directory" and
"Queue file".  For example, what would happen if you selected a
directory?  Which button would you press?  The GTK+ file dialog
handles this by choosing the current directory if no files are
selected or otherwise choosing the files or folders selected.

Is it necessary to queue then restore? I suspect that it generally
isn't, and that it adds unnecessary complication when a single or small
number of selections are being restored.

It is unnecessary when you have a single file yes, but on the other hand if user wants to restore multiple files from different directories (and possibly different dates) he would need to rerun the wizard for each directory and/or date.

Other solution would be to add some kind of drag and drop solution so that user would drag files to nautilus directory to which he would like to restore. I haven't done any research in this direction, it might be interesting, it might be confusing.

3) I don't believe the size of the files to restore is actually known
before restoring.  Which sucks and would be good to fix, but isn't
going to happen soon.  So we don't need a column for that.

True, will not be included.

4) The phrase "Restore Point" is odd.  Maybe like "Restore Date" or
even "Version"?

Yes, 'Version'. Or 'Backup' maybe?

Possible, but a minor detail.

5) In the "restoring to" widget, the default should probably be
"previous location" and then offer to let them choose a directory to
put all files in.  This is because (A) if we default to a directory,
we have to translate the directory name and that's kind of odd and (B)
I think it's more common that a user just wants the files back where
they should be.


[✔] Replace current version
 Restore destination: [ Home ]

This could probably be moved to next screen with two radio buttons (original location, custom location [Choose - file selector]).

Are there any similar interfaces that we could look at for inspiration?

The simplest of them would be arguably be Time Machine for OS X, on Linux there is Back in Time (, Time Vault ( and FlyBack ( ). My personal opinion is that none of Linux programs resolved the issue quite satisfactory enough (after all, that was one of the reasons why I applied for GSOC with this project ;)).

Time machine has a slider for going back in time and does restore by selecting a file and, IIRC, pushing a restore button.

Back in Time seems to offer a large list of snapshots with which you browser to desired snapshot, select the file(s) and click restore button.

Ideally we would probably want to support drag and drop and restoring by adding to queue.

Thats it from me at this hour, hope I didn't made too many logical conflicts ;)


aday on

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]