Mmmmm, not sure that "tree v2" will be really better...
* Still very confusing and slow to visually crawl. Especially when there's a lot of small folders.
* The "path redundancy" of previous versions doesn't harm. It's helpful actually.
* The code of previous versions is probably much simpler.
* Misses the ability to select a folder then sync/exclude the folder with its content.
Flat versus tree file structure
- Posts: 5
- Joined: 20 Jul 2020
- Posts: 25
- Joined: 25 Apr 2020
I think all these discussions and opposing ideas about proper visual representations prove that it's quite impossible to implement "one and only very best optionless design for everybody". Some options are unavoidable. Because there are different use cases even for the same user, not speaking about personalk preferences of different users :)
For example, some option like "condensed horizontal space" that saves horizontal space but loses some vertical space would be very helpful for long path hierarchies, but at the same time it would be neither required nor comfortable for simpler use cases without long paths. And it is not related to personal preferences - it is related to specific use cases.
It's quite impossible to avoid any options and use one fixed design IMHO...
For example, some option like "condensed horizontal space" that saves horizontal space but loses some vertical space would be very helpful for long path hierarchies, but at the same time it would be neither required nor comfortable for simpler use cases without long paths. And it is not related to personal preferences - it is related to specific use cases.
It's quite impossible to avoid any options and use one fixed design IMHO...
- Posts: 25
- Joined: 25 Apr 2020
I was forced to revert back from 11.0 to 10.25 because of the following bug at least for Linux version.
10.25 (valid representation):
11.0 (invalid representation):
It's really a bug, it's not a drawback, etc.
10.25 (valid representation):
- Screenshot_20200722_111743.png (59.76 KiB) Viewed 45346 times
- Screenshot_20200722_111834.png (68.59 KiB) Viewed 45346 times
- Posts: 5
- Joined: 20 Jul 2020
The first screenshot is a demonstration (amongst a lot others) that the tree view is just horrible...
- Posts: 25
- Joined: 25 Apr 2020
Your comment (by the way, I absolutely disagree with you about that - but it doesn't matter) just proves my previous statementThe first screenshot is a demonstration (amongst a lot others) that the tree view is just horrible... pooper, 22 Jul 2020, 08:25
I think all these discussions and opposing ideas about proper visual representations prove that it's quite impossible to implement "one and only very best optionless design for everybody". Musenka, 22 Jul 2020, 08:11
-
- Posts: 18
- Joined: 25 Mar 2020
It seems to me that there is a good compromise that balances optimal horizontal and vertical space. Like code editors do with "collapsing" folders with no files:
In the case of FreeFileSync, that would be folders with no contents which are different. One line is used for the path, and one line each for each file/folder which has a change.
This would far and away be my preference, regardless of the kind of comparison (obviously not with the collapse/expand arrows -- I am using this only for the visual example).
- OptimalTree.png (7.38 KiB) Viewed 45330 times
This would far and away be my preference, regardless of the kind of comparison (obviously not with the collapse/expand arrows -- I am using this only for the visual example).
- Posts: 11
- Joined: 19 Dec 2019
"(obviously not with the collapse/expand arrows -- I am using this only for the visual example)."
Actually I would like the collapse / expand option as well as a checkbox to disable the foldr / file but not remove it from the list as there is no way to restore it to the list that I've found.
Actually I would like the collapse / expand option as well as a checkbox to disable the foldr / file but not remove it from the list as there is no way to restore it to the list that I've found.
- Posts: 33
- Joined: 14 Jul 2020
Musenka
Is this folder jumping into second row after scrolling down?
This is what I see here.
After all the Fuss, I think the biggest problem with tree view was the right to left alignment to always show the hole filename regardless of window and column size situation.
11 is deffinetly an improvement to 10.25.
Next thing is how can more horizontal space be safed?
Is the best way to accommodate different use cases with an option?
Adding one point to the right click menu into the 'fullpath, relative path, item view' block probably works. My name idea was 'save horizontal space', Musenka´s 'condensed ...'. Who is activating it will be able to deactivate it also.
I still vote best way to safe horizontal space is explorer-tree-view and what lawrence posted.
Folder jumping into another row might be confusing, better just lose one file or more to show up. Or you say people have to get used to this kind of view.
Is this folder jumping into second row after scrolling down?
This is what I see here.
After all the Fuss, I think the biggest problem with tree view was the right to left alignment to always show the hole filename regardless of window and column size situation.
11 is deffinetly an improvement to 10.25.
Next thing is how can more horizontal space be safed?
Is the best way to accommodate different use cases with an option?
Adding one point to the right click menu into the 'fullpath, relative path, item view' block probably works. My name idea was 'save horizontal space', Musenka´s 'condensed ...'. Who is activating it will be able to deactivate it also.
I still vote best way to safe horizontal space is explorer-tree-view and what lawrence posted.
Folder jumping into another row might be confusing, better just lose one file or more to show up. Or you say people have to get used to this kind of view.
- Posts: 309
- Joined: 7 Jan 2018
@Zenju, thank you for working on the grid layout! Would you please, please, provide an option to show the selected path format (full path or relative path) on each and every line? The new indent is better than before, but sometimes I really want to see the path for every single entry in the list.
- Posts: 33
- Joined: 14 Jul 2020
An 10.24 to 11 comparison with comments.
The tree layout has still optical clutter. What, is written by now in the screenshot.
The tree layout has still optical clutter. What, is written by now in the screenshot.
- Attachments
-
- FreeFileSync Vergleich comment.png (493.69 KiB) Viewed 45273 times
- Posts: 33
- Joined: 14 Jul 2020
This red line is interesting. As we say 'ein roter Faden' -> "A red yarn" [to follow].
from Directory Opus 12
from Directory Opus 12
- Posts: 10
- Joined: 9 Aug 2018
Your example is in fact Name view but has a little space before file name and path in directory...Here is the example ... Musenka, 21 Jul 2020, 21:04
I ask this view here viewtopic.php?t=7392 and I would be very happy for my or even your file display solution.
- Posts: 33
- Joined: 14 Jul 2020
That Musenkas cutout looks like that is just by chance.
Look on my screen, for a part it looks exactly the same.
Relative path or full path isn´t any close to only name view. Or you´re suggested change.
Look on my screen, for a part it looks exactly the same.
Relative path or full path isn´t any close to only name view. Or you´re suggested change.
-
- Posts: 18
- Joined: 25 Mar 2020
@Zenju
I have another observation from using FreeFileSync, and that is that with the relative view having the filename in both halves of the view is entirely redundant.
It's quite possible that much better horizontal space utilization (and note, I have a 50" 4K monitor) could be achieved by doing something like:
And supporting as current hover to display the full details, including both full filenames. Additionally, clicking on any given row might expand the row to display full details as well.
A sync root option could be added as well that displays the synch root path once, whenever it changes, like this:
I have another observation from using FreeFileSync, and that is that with the relative view having the filename in both halves of the view is entirely redundant.
It's quite possible that much better horizontal space utilization (and note, I have a 50" 4K monitor) could be achieved by doing something like:
| | | Left | Right |
| Filename | Action/Cat | Date | Size | Date | Size |
A sync root option could be added as well that displays the synch root path once, whenever it changes, like this:
| | | Left | Right |
| Filename | Action/Cat | Date | Size | Date | Size |
| <a sync root spanning all columns> |
| a/relative/path | [XX] <-> | .... | .... | .... | .... |
| another/relative/path | [XX] <-> | .... | .... | .... | .... |
| and/so/on | [XX] <-> | .... | .... | .... | .... |
| <another sync root spanning all columns> |
| a/relative/path | [XX] <-> | .... | .... | .... | .... |
| another/relative/path | [XX] <-> | .... | .... | .... | .... |
| and/so/on | [XX] <-> | .... | .... | .... | .... |
- Posts: 17
- Joined: 23 Jan 2019
Just throwing my 2 cents in but I would much rather have the old view or at least a way to switch between them.....
- Posts: 33
- Joined: 14 Jul 2020
The tree layout can be better, but the details are not worked out, yet.
From that, a beta testing group to get this done would have been best from the beginning.
Now this topic is here for that.
From that, a beta testing group to get this done would have been best from the beginning.
Now this topic is here for that.
-
- Posts: 27
- Joined: 26 Nov 2017
Guessing from the comments that 10.24 is still needed for the old file view?
- Posts: 25
- Joined: 25 Jul 2020
Hi,
First of all, congratulations for FreeFileSync. I have been using it for a long time and I am very satisfied with it.
However, like many, I am not convinced by the tree file structure in 10.25 and 11.0 versions.
I would like to suggest some improvements for FFS regarding the display of file names: why not take inspiration from SyncBackFree, which displays full names (directories + file) as in FFS 10.24, but cutting left if it's too long :
example : .../directory1/directory2/directory3/directory4/myfile.ext
And while we're watching SyncBackFree, a quick word about colors in FFS: OK for the green arrows, but why the weird purple arrows?
Everybody is used in everyday life to the green=OK, red=danger correspondence.
So put green arrows for a copy and red crosses for an erase, but especially highlight the filenames in green if they are kept and in red if they are going to be erased, either on the right or on the left. In my opinion, this allows to immediately spot the files that will be impacted, especially when erasing, by the synchronization.
First of all, congratulations for FreeFileSync. I have been using it for a long time and I am very satisfied with it.
However, like many, I am not convinced by the tree file structure in 10.25 and 11.0 versions.
I would like to suggest some improvements for FFS regarding the display of file names: why not take inspiration from SyncBackFree, which displays full names (directories + file) as in FFS 10.24, but cutting left if it's too long :
example : .../directory1/directory2/directory3/directory4/myfile.ext
And while we're watching SyncBackFree, a quick word about colors in FFS: OK for the green arrows, but why the weird purple arrows?
- Capture_FFS.JPG (241.99 KiB) Viewed 44931 times
So put green arrows for a copy and red crosses for an erase, but especially highlight the filenames in green if they are kept and in red if they are going to be erased, either on the right or on the left. In my opinion, this allows to immediately spot the files that will be impacted, especially when erasing, by the synchronization.
- syncbackfree2.jpg (163.5 KiB) Viewed 44937 times
- Posts: 33
- Joined: 14 Jul 2020
O_o ??
Conflicts are a thunder
Deletions are a bin with a red minus
Green is from left to right
Purple is from right to left
Conflicts are a thunder
Deletions are a bin with a red minus
Green is from left to right
Purple is from right to left
- Posts: 25
- Joined: 25 Jul 2020
Yes VladimirII, I use FFS for a long time, I know that :-)
What I say is that there is no need to use green and purple to specify the right/left direction. What synchronization does is create, delete or update files so just highlighting right and left modified files is enough. And doing this by using the green and red, which are associated with OK/KO warning.
The very best would be that users can customize the UI :-)
What I say is that there is no need to use green and purple to specify the right/left direction. What synchronization does is create, delete or update files so just highlighting right and left modified files is enough. And doing this by using the green and red, which are associated with OK/KO warning.
The very best would be that users can customize the UI :-)
-
- Posts: 2453
- Joined: 22 Aug 2012
This is culturally bound and certainly not universal. In some Asian countries the reverse applies. They are generally however aware of our western "bias".... Everybody is used in everyday life to the green=OK, red=danger correspondence.JPringle, 25 Jul 2020, 12:32
Regarding the Purple vs Green background:
I like that you can instantly recognize the sync direction by the background color, without the need to look at the direction of the arrow.
And in either direction, still the "+" (plus) signs are green and the "-" (minus) signs red.
- Posts: 33
- Joined: 14 Jul 2020
It is, I´m very glad FFS is two coloured. Also that it has both sides in its view and not a single view as some other software shown here. That distinguishs FFS from other software.What I say is that there is no need to use green and purple to specify the right/left direction. What synchronization does is create, delete or update files so just highlighting right and left modified files is enough. And doing this by using the green and red, which are associated with OK/KO warning. JPringle, 26 Jul 2020, 14:31
You also wrote like red should replace purple ;)
Deletion is normal not a K.O. - what to improve highlighting nontheless -, discrepancies are problematic.
That FFS is not only a backup software also has everyone in mind?
-
- Posts: 55
- Joined: 15 Feb 2018
Please just reinstall the old flat format. I tried version 11 and I can't decipher its meaning. I am back to 10.24 now.
- Posts: 27
- Joined: 19 Aug 2019
I'm also hoping we get an option to bring back the flat view. Not liking the tree view at all, to be honest. Tried both v10.25 and v11 and still not a fan of it. Flat view is just quicker and easier for me to compare.Please just reinstall the old flat format. I tried version 11 and I can't decipher its meaning. I am back to 10.24 now. JDB, 29 Jul 2020, 07:03
If the flat view has been completely removed in all future versions, I will just have to stick with v10.24. I don't understand why we can't have the option to keep the old view though?
- Posts: 9
- Joined: 7 Jul 2020
@Sonik_C
you can click on the headers to switch to the old view.
but even in v11, the horizontal spacing in the new view sucks. It really should be a fixed indent per directory level, not this offset to the end of the previous level's folder name.
you can click on the headers to switch to the old view.
but even in v11, the horizontal spacing in the new view sucks. It really should be a fixed indent per directory level, not this offset to the end of the previous level's folder name.
- Posts: 27
- Joined: 19 Aug 2019
That doesn't really fully restore the old view though, as I like to see the paths. Unless I'm missing an option somewhere?
- Posts: 5
- Joined: 20 Jul 2020
No, there are no other options (for the time being).
phhowe17 just keeps posting this answer, disregarding the fact that the paths are entirely missing...
Most users don't just like to see the paths, but have to see them!
phhowe17 just keeps posting this answer, disregarding the fact that the paths are entirely missing...
Most users don't just like to see the paths, but have to see them!
- Posts: 25
- Joined: 25 Jul 2020
Sorry, I misspoke: I didn't mean red as a color when FFS has a problem but when, through synchronization, the user can delete a file. Flashing it in red shows a warning, it's up to him to see if that's what he really wanted to do.You also wrote like red should replace purple ;)What I say is that there is no need to use green and purple to specify the right/left direction. What synchronization does is create, delete or update files so just highlighting right and left modified files is enough. And doing this by using the green and red, which are associated with OK/KO warning. JPringle, 26 Jul 2020, 14:31
Deletion is normal not a K.O. - what to improve highlighting nontheless -, discrepancies are problematic. VladimirII, 27 Jul 2020, 09:40
- Posts: 33
- Joined: 14 Jul 2020
After working on other syncs with 10.24 I recognized a thing.
For log files, of installers or the FFS log, its crucial that it contains repetitive lines and characters.
Thus makes it possible to read the line even during scrolling or sometimes even jumping (PgDw/Up). Also to spot errors while scrolling.
The same applies in a kind to the Folder-Paths.
If every folder has only up to 10 files it does not realy apply.
If the most folders contain dozens of files, the folder name can be read during scrolling, if the filenames are consecutive they also.
With the tree view where only at on place the folder name is you have to spot it, stop, read it, maybe remember it - even it stays on most upper line.
For some or half this habit, to read while scrolling, is convenient. Tree view is taking this away.
Sorry Musenka you where not 'used' to this usage.
As already sad, tree view has it´s pro in a cleaner look and the possibility to save horizontal space (after more tweaking).
There is clearly a reason to have an option to choose between tree and full-line view.
For log files, of installers or the FFS log, its crucial that it contains repetitive lines and characters.
Thus makes it possible to read the line even during scrolling or sometimes even jumping (PgDw/Up). Also to spot errors while scrolling.
The same applies in a kind to the Folder-Paths.
If every folder has only up to 10 files it does not realy apply.
If the most folders contain dozens of files, the folder name can be read during scrolling, if the filenames are consecutive they also.
With the tree view where only at on place the folder name is you have to spot it, stop, read it, maybe remember it - even it stays on most upper line.
For some or half this habit, to read while scrolling, is convenient. Tree view is taking this away.
Sorry Musenka you where not 'used' to this usage.
As already sad, tree view has it´s pro in a cleaner look and the possibility to save horizontal space (after more tweaking).
There is clearly a reason to have an option to choose between tree and full-line view.
- Posts: 11
- Joined: 19 Dec 2019
I completely agree Vladimir11. My comment and request was to add a tree view (like WIndows, not like we have now in version 10.25) but to keep list view and to be able to toggle between them in real time, without having to repeat the compare stage. Having more than two views or options within the views is of course acceptable.
