deja-dup-hackers team mailing list archive

[Urban Škudnik <urban.skudnik@xxxxxxxxx>]

Hey,

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
> observations/comments...
>
> * 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
> restore.

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
> UI.

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 (http://dl.dropbox.com/u/1493539/marked-above.png 
 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 http://dl.dropbox.com/u/1493539/marked-above.png 
 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.
>
> Agreed:
>
> [✔] 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 (http://backintime.le-web.org/), Time  
Vault (https://wiki.ubuntu.com/TimeVault) and FlyBack (http://flyback-project.org/ 
). 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 ;)

Cheers,
Urban


> Allan
> --
> aday on irc.gnome.org