Hello,
Sorry for the delay, I've been busy. Here are some of the ideas I've had while working with your creation.
--------------------------------------------------------------------
Adding a "Name" column to the "Pair" entity and present it in the comparison window as a column. So that, in a multiple pairs situation, one can easily recognize the source pair in the main comparison window, by a name field much shorter than the "Base Folder" one.
During a "Pair" creation by the user (drag/drop), this name should be automatically filled with an auto number. The user can later fill it the way he wants, in the idea that he will find it as a disposable column in the comparison window.
For instance, the folders I want to mirror are "C:\Users\Mathieu\Desktop", "C:\Users\Mathieu\Documents", "C:\Users\Mathieu\Pictures". When I create the pairs of folders in FFS, I decide to name them respectively "Desk", "Doc" and "Pict". Next, I choose the pair name column to appear in the comparison window, which will help me to easily recognize the absolute path of the files with this short column.
--------------------------------------------------------------------
Right clicking on one or many items in the Configuration window.
The only things that can be done on this items are double clicking to make comparison and deleting in the right click contextual menu. I think that this menu is the regular place to put all things about one or many configuration files, that are presently only placed in the "main bar": Compare, setting(s) and Synchronize. This function allows the advanced user to close the Main Bar window in a regular usage.
--------------------------------------------------------------------
General reflection about versioning.
The folder can become silently huge. I see no solution from the soft, but it is a problem. Let's say that if the folder were "officiated" somewhere, it could be accompanied by some size alerts. I think that you also should give examples for a proper usage of this function, or that a little more structuration could be an opportunity to enhance this very good solution.
Other thing, the file names can become too long to be deleted (in Windows 7.0), I experienced this problem without finding an idea to solve it.
--------------------------------------------------------------------
The (excellent) drive name idea could be enhanced by the search of a given folder or file in the connected drives list.
For instance, if I put [\Backup\Type32GO] (the first backslash indicating a file contrary to a drive name as [MYDD32GO]) then the program will scan all present drives in search of this very file, just like it searches for a drive name.
I generate two backups types, one for the current work that I want to hold on a 32GB card, the other for archive with no size expectation less than a Tera. With this trick, I could easily assign a support to a given usage with no obligation to name conventionally my backup supports. The little problem that comes with this idea, is that many drives can have the same file present : the program should choose arbitrary one of them or should propose an input choice.
--------------------------------------------------------------------
Other reflections that I had have a less productive scope than those I show here. They are more critics and debates that I'm sure you already had many times before and that might bore you, I'm afraid. I'll take the time to write them down if you show some interest. They talk about the View Settings window which is a problematic and difficult part (only for ergonomics), and some other secondary thoughts.
Reflections and propositions
- Posts: 4
- Joined: 28 Aug 2014
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
> Sorry for the delay, I've been busy
Dito, sorry for the delay. You make excellent points, and they will eventually be considered, even when it takes a while sometimes. Thank you for your feedback!
> During a "Pair" creation [...] this name should be automatically filled with an auto number
FFS already has an algorithm to generate "nice" folder pair names, which is currently used in the overview panel, e.g.:
%AppData%\Mozilla\Firefox -> [Backup]\Programme\Backup\Firefox
FFS will detect this as folder pair "Firefox". I think this heuristic is sufficient in almost all cases, which saves us to complicate matters by asking the user for additional input.
I agree this information is currently missing on the grid view, to allow a quick association from file name to folder pair, latter of which is often also correlated to a FFS configuration file (ffs_gui, ffs_batch).
So while I'm not sure if it's required to have an association from file to configuration name, too, at least the folder pair name really seems required.
> Right clicking on one or many items in the Configuration window.
> I think that this menu is the regular place to put all things about one or many configuration files
Providing "compare" and "sync" options in the config panel context menu seems natural. But it won't be enough; the basic operations are: compare, sync, comparison settings, filter, synchronization settings.
I'm not sure if the latter three belong into the config panel or not. But anyway there is a better, more discoverable place anyway: the menu bar. Under menu "file" there are "compare" and "sync" options already. Maybe the best overall solution is to rearrange the menu bar, include these three additional operations, and place all five operations into a separate "Action" menu.
> The folder can become silently huge. I see no solution from the soft
That's true, but it's not a huge problem: I hardly get any feature request in this regard at all since introduction of the two naming conventions "replace" and "time stamp". This is a strong indication that the current solution is going into the right direction, even though it does not provide for an automatic way to clean up - quite contrary: FFS had already implemented an automatic cleanup based on the number of versions per file and removed it when introducing the "naming convention" feature, but instead of receiving complaints, the number of feature requests dropped to almost zero. So the old automatic cleanup was not as useful after all. Indeed, it's difficult to come up with a comprehensive solution in first place: no matter if based on total disk space consumption or number of versions per file, it's insufficient in general, where the requirements of a particular user scenario cannot be tied to these observable metadata.
It's good that there is no pressure in this area right now. This allows to find and research for a fundamental solution to the automatic cleanup problem, without beeing forced to implement a half-baked one, that will be hard to get rid of later because users started to depend on it. Anyway it is yet an open question how a proper solution should look like.
>you also should give examples for a proper usage
Did you sees the "Show examples" link to the help file when "Versioning" is used? This is supposed to give concrete, easy-to-follow examples.
> the file names can become too long to be deleted [...] without finding an idea to solve it.
This is a problem for other software, not FFS. Anyway, you can use FFS to delete files with long paths (> 260 chars).
> The (excellent) drive name idea could be enhanced by the search of a given folder or file in the connected drives list.
I don't know of any problems that such a feature would solve, except for not requiring a unique volume name for the backup drive, which is a very weak requirement in practice.
> Other reflections that I had have a less productive scope than those I show here. They are more critics and debates that I'm sure you already had many times before and that might bore you.
Maybe, maybe not :) I won't dismiss any possible feedback, before I've read it. Even if "signal to noise" is low, it's better than nothing.
Dito, sorry for the delay. You make excellent points, and they will eventually be considered, even when it takes a while sometimes. Thank you for your feedback!
> During a "Pair" creation [...] this name should be automatically filled with an auto number
FFS already has an algorithm to generate "nice" folder pair names, which is currently used in the overview panel, e.g.:
%AppData%\Mozilla\Firefox -> [Backup]\Programme\Backup\Firefox
FFS will detect this as folder pair "Firefox". I think this heuristic is sufficient in almost all cases, which saves us to complicate matters by asking the user for additional input.
I agree this information is currently missing on the grid view, to allow a quick association from file name to folder pair, latter of which is often also correlated to a FFS configuration file (ffs_gui, ffs_batch).
So while I'm not sure if it's required to have an association from file to configuration name, too, at least the folder pair name really seems required.
> Right clicking on one or many items in the Configuration window.
> I think that this menu is the regular place to put all things about one or many configuration files
Providing "compare" and "sync" options in the config panel context menu seems natural. But it won't be enough; the basic operations are: compare, sync, comparison settings, filter, synchronization settings.
I'm not sure if the latter three belong into the config panel or not. But anyway there is a better, more discoverable place anyway: the menu bar. Under menu "file" there are "compare" and "sync" options already. Maybe the best overall solution is to rearrange the menu bar, include these three additional operations, and place all five operations into a separate "Action" menu.
> The folder can become silently huge. I see no solution from the soft
That's true, but it's not a huge problem: I hardly get any feature request in this regard at all since introduction of the two naming conventions "replace" and "time stamp". This is a strong indication that the current solution is going into the right direction, even though it does not provide for an automatic way to clean up - quite contrary: FFS had already implemented an automatic cleanup based on the number of versions per file and removed it when introducing the "naming convention" feature, but instead of receiving complaints, the number of feature requests dropped to almost zero. So the old automatic cleanup was not as useful after all. Indeed, it's difficult to come up with a comprehensive solution in first place: no matter if based on total disk space consumption or number of versions per file, it's insufficient in general, where the requirements of a particular user scenario cannot be tied to these observable metadata.
It's good that there is no pressure in this area right now. This allows to find and research for a fundamental solution to the automatic cleanup problem, without beeing forced to implement a half-baked one, that will be hard to get rid of later because users started to depend on it. Anyway it is yet an open question how a proper solution should look like.
>you also should give examples for a proper usage
Did you sees the "Show examples" link to the help file when "Versioning" is used? This is supposed to give concrete, easy-to-follow examples.
> the file names can become too long to be deleted [...] without finding an idea to solve it.
This is a problem for other software, not FFS. Anyway, you can use FFS to delete files with long paths (> 260 chars).
> The (excellent) drive name idea could be enhanced by the search of a given folder or file in the connected drives list.
I don't know of any problems that such a feature would solve, except for not requiring a unique volume name for the backup drive, which is a very weak requirement in practice.
> Other reflections that I had have a less productive scope than those I show here. They are more critics and debates that I'm sure you already had many times before and that might bore you.
Maybe, maybe not :) I won't dismiss any possible feedback, before I've read it. Even if "signal to noise" is low, it's better than nothing.
