Flat versus tree file structure

Discuss new features and functions
Posts: 5
Joined: 20 Jul 2020

pooper

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.
Posts: 25
Joined: 25 Apr 2020

Musenka

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...
Posts: 25
Joined: 25 Apr 2020

Musenka

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):
Screenshot_20200722_111743.png
Screenshot_20200722_111743.png (59.76 KiB) Viewed 36094 times
11.0 (invalid representation):
Screenshot_20200722_111834.png
Screenshot_20200722_111834.png (68.59 KiB) Viewed 36094 times
It's really a bug, it's not a drawback, etc.
Posts: 5
Joined: 20 Jul 2020

pooper

The first screenshot is a demonstration (amongst a lot others) that the tree view is just horrible...
Posts: 25
Joined: 25 Apr 2020

Musenka

The first screenshot is a demonstration (amongst a lot others) that the tree view is just horrible... pooper, 22 Jul 2020, 08:25
Your comment (by the way, I absolutely disagree with you about that - but it doesn't matter) just proves my previous statement
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
User avatar
Posts: 18
Joined: 25 Mar 2020

lawrence-dol

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:
OptimalTree.png
OptimalTree.png (7.38 KiB) Viewed 36078 times
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).
Posts: 11
Joined: 19 Dec 2019

bazbsg

"(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.
Posts: 33
Joined: 14 Jul 2020

VladimirII

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.
Posts: 305
Joined: 7 Jan 2018

bgstack15

@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

VladimirII

An 10.24 to 11 comparison with comments.

The tree layout has still optical clutter. What, is written by now in the screenshot.
Attachments
FreeFileSync Vergleich comment.png
FreeFileSync Vergleich comment.png (493.69 KiB) Viewed 36021 times
Posts: 33
Joined: 14 Jul 2020

VladimirII

This red line is interesting. As we say 'ein roter Faden' -> "A red yarn" [to follow].
Image
from Directory Opus 12
Posts: 10
Joined: 9 Aug 2018

randomofamber

Here is the example ... Musenka, 21 Jul 2020, 21:04
Your example is in fact Name view but has a little space before file name and path in directory...
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

VladimirII

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.
User avatar
Posts: 18
Joined: 25 Mar 2020

lawrence-dol

@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:
|                         |            |    Left     |    Right    |
| Filename                | Action/Cat | Date | Size | Date | Size |
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:

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

Grinch843

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

VladimirII

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.
User avatar
Posts: 27
Joined: 26 Nov 2017

Darth Agnon

Guessing from the comments that 10.24 is still needed for the old file view?
Posts: 25
Joined: 25 Jul 2020

JPringle

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?
Capture_FFS.JPG
Capture_FFS.JPG (241.99 KiB) Viewed 35679 times
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.

syncbackfree2.jpg
syncbackfree2.jpg (163.5 KiB) Viewed 35685 times
Posts: 33
Joined: 14 Jul 2020

VladimirII

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
Posts: 25
Joined: 25 Jul 2020

JPringle

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 :-)
User avatar
Posts: 2248
Joined: 22 Aug 2012

Plerry

... Everybody is used in everyday life to the green=OK, red=danger correspondence.JPringle, 25 Jul 2020, 12:32
This is culturally bound and certainly not universal. In some Asian countries the reverse applies. They are generally however aware of our western "bias".

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.
Last edited by Plerry on 27 Jul 2020, 12:38, edited 1 time in total.
Posts: 33
Joined: 14 Jul 2020

VladimirII

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

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?
User avatar
Posts: 55
Joined: 15 Feb 2018

JDB

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

Sonik_C

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

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

phhowe17

@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.
Posts: 27
Joined: 19 Aug 2019

Sonik_C

@Sonik_C

you can click on the headers to switch to the old view.phhowe17, 01 Aug 2020, 16:36
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

pooper

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!
Posts: 25
Joined: 25 Jul 2020

JPringle

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. VladimirII, 27 Jul 2020, 09:40
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.
Posts: 33
Joined: 14 Jul 2020

VladimirII

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.
Posts: 11
Joined: 19 Dec 2019

bazbsg

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.