Flat versus tree file structure

[proehm3555]

Please consider adding a button to switch between the tree view of the file structure and the older flat file structure. The descriptive nature of my folder names pushes the filenames off past the right of the windows.

[Wagner]

I prefer the tree structure, but it has errors in the display.

I don't complain about the program, because it is the best I've seen in many years of using Windows (since the first one). I also agree to be able to choose the display mode.

[GeriH]

I agree to Wagner and proehm3555. There must be some way to choose the display-mode. Most of my files/pathes are not shown (I mean: only empty lines are shown) in the tree view.
If I were not experienced in this (btw: GREAT!) program for years, I wouldn't dare to press the "synchronize"-button only seeing what is to see now in this version...

[shinji257]

I'm in agreement. I registered purely so I could put in my input. This is by far the best program but I am far more preferential to the older flat style that you had before for the file listing. The new tree view looks broken in comparison.

[Larry]

I'm in agreement with the others. Like @shinji257, I registered solely to add my in input. The flat file structure was far more usable for me. The new tree structures obscures the information I am most interested in. A option toggle would seem to be the way to go so folks could pick their poison. Regardless, this is an awesome program! Keep up the good work!

[randomofamber]

I prefer Flat structure.
I would be most comfortable with the design, where files had an Item Name and directories had Relative or Full Paths. See my suggestion in attachement in topic viewtopic.php?t=7392 ...

[lawrence-dol]

I really rather prefer the new tree structure, especially since it makes much better use of the available display space when the files are nested (each folder's contents indented by a small, uniform amount, instead of by the the length of the parent's name.

But it would really helpful to be able to not display the file icons. For me they are simply visual clutter and don't help me in any way. It seems like a few view options could be beneficial.

[bgstack15]

But it would really helpful to be able to not display the file icons. For me they are simply visual clutter and don't help me in any way. It seems like a few view options could be beneficial.

You can right-click the column titles, and uncheck the option for "Show icons."

[lawrence-dol]

@bgstack15 : I hunted everywhere for that. Thank you!

[lawrence-dol]

Actually, I take back my comment about better use of space; it's a visual improvement, but the contents are still indented by the length of the parent folder name, so the file name will still quickly end up past the length of the field when nesting gets deep, maybe even more so because the graphic divider is wider than a slash.

I would really prefer a traditional tree, files sorted first, like this:

root-folder1
  |- file1
  |- file2
  |- subfolder1
  |    |- file3
  |    |- file4
...
root-folder2
...


[gvp9000]

I prefer Flat structure.
I'm willing to try the new mode so give us the option to choose between those two.

[Zenju]

There are in fact two major visual differences between the old and new view:

1. "compressed tree view". This is basically identical to the old layout, except that it gets rid of the redundancy, i.e. instead of showing parent folder paths each and every time, it just shows them once and connects via lines.

No information is lost, and row width is basically the same as before:

compressed tree.png (31.93 KiB) Viewed 81545 times

2. Rows are truncated differently now. Instead of always cutting from the right, thereby removing the most important information, the new variant first truncates the parent paths, and only after that starts to truncate the item name.

As a result more relevant information is shown than before:

item-priority.png (32.72 KiB) Viewed 81545 times

That said, maybe further improvements are still possible. Rather than talking in the abstract, I'd like to see some pictures!

[lawrence-dol]

@zenju

What you show for the tree is very different from mine:

ffs_gui.png (12.62 KiB) Viewed 81523 times

Notice the way that a lot of horizontal space is sacrificed by placing children aligned to the end of the parent.

Even in your screenshot the amount of indent is excessive, and variable; this would be vastly improved if the indent for children was uniformly about 16 to 20 pixels (enough to align at the middle of the first character with the icon shown), and if each parent had its own line.

[khamilton80]

This tree layout is unusable. Please give an option to disable it. My left side has no names or images just lines. The right side has names and images but is very widely spaced horizontally.

[shinji257]

I just checked and I found you can get a flat listing like we used to have by right clicking on Relative path and changing it to Item name. This may work for some of us. I find it sufficient for my needs.

[Wagner]

@zenju

What you show for the tree is very different from mine:


ffs_gui.png


Notice the way that a lot of horizontal space is sacrificed by placing children aligned to the end of the parent.

Even in your screenshot the amount of indent is excessive, and variable; this would be vastly improved if the indent for children was uniformly about 16 to 20 pixels (enough to align at the middle of the first character with the icon shown), and if each parent had its own line.

this is the structure AS IT HAS TO BE! the best!

[bgstack15]

Please add a way to use the old method. I like to see the full (or relative) path on each and every line of the output! I am sticking to 10.24 for now.

[Slooby]

Yes please give us an option to use the previous layout before 10.25 Tree View.

I updated last night, is there a quick way to revert back to the previous version?

[Larry]

This is why I retain every setup file. I reverted to 10.24 and will stick with that as long as the only display option is the new tree view.

Regardless, this is a GREAT free app and appreciate its availability!

*** Update: It just dawned on me to look and yes, FFS does retain an archive on the website. The previous versions are available.

[Darth Agnon]

I'm glad I got the donation edition for 10.24 (just in time!). I don't like the new tree view either - it's more confusing. The old view allows me to tell at a glance where a file is located relative to other files. The new tree view forces me to search around, follow lines, until I find what is nested within what.

I'd appreciate the option to switch back to the old view. As is, I will be downgrading back to 10.24 as my maximum version.

[klaus_kraemer]

Please let users choose whether thy wanna see it flat or as a tree view.

Well meant is not always well done...

[xarlibrau]

I just love FreeFileSync but, with this new tree view, a quick glance at what has changed is not so trivial. I vote for an option to disable it. In the meantime, I'm sticking to version 10.24.

[bazbsg]

I am very happy with this program in general. I did support the tree view idea in another post some time ago. Thank you to the developer(s) for listening and responding to the users.

However I to do not find this implementation very useful. It removes some of the redundancy of seeing the same folder name repeated. But it doesn't save any horizontal space. And it doesn't add any functionality.

I haven't done much Windows programming since MSVC++ 6.0 and I used that way longer than was recommended. In that, MFC had a tree view control. It put a folder at the same horizontal lever as the files at its same level. Then under that folder, all the files and folders contained within were indented a small amount. Importantly, there was a + sign in a square that could be used to collapse and expand that folder to hide the detail under the folder. Excel has an addition at the top and left of it's specialized tree view for row and column grouping that allows to collapse and expand everything at that same level. And if the checkbox in the center was also available at the folder item, then unchecking it would remove the entire folder and all its files and subfolders. Although in this case I would prefer to see that the check box just disables synchronization of unchecked files and folders rather than removing them from the list. They could remain on the list after a synchronization in case one wants to check them and make a second pass.

Thanks for listening...

[VladimirII]

I´m too for an option between flat (old) and tree.
Albeit I also see a use and sense in the tree layout, especially in 21:9 or wider screen setups. Plus some improvements.
On a 5:4 screen it shocked me to see it and go register. A look like Zenjus second picture on the left is useless to me and not helpful. The cut off filenames get visible when moving the bar. Then they are aligned straight under each other. Names different in just one symbol can only be seen this way (Right of Zenjus picture).

If I need the full file path or not differs from task to task. And so if it is usefull in the way how it is now.

- for a better tree look. Why haven´t you used the way microsoft is doing it in his explorer-tree-view ever since [For the younger 'Navigation-pane']? It would save up a lot of this white space immediately. What bazbsg says relates to that.

[phhowe17]

@shinji257

I prefer the relative path, it's just the the the indent levels run off crazy when you have long path names.

[Zenju]

i miss the ability to select a folder in the OVERVIEW area on the left and have the effected files marked on the right frame with the blue highlighting to the left of the effected items.

It's still there, but not on the left anymore. I assume you've hidden it unwittingly by having too wide columns, which are then truncated (including the blue highlight). Anyway I've found a way to restore the old location, which was complicated by the changes required due to the new tree layout.

Is this really how the new interface is supposed to be working? It's completely unreadable :(

File names are always visible with this design, while they were truncated and thous not visible at all in the old variant. The "price" is some degree of confusion with file names being moved horizontally. Horizontal position is also an indication of "level", so maybe this price is too high? The next version will only prioritize showing the file icon and not both icon and filename.

I have many deep directories, and mostly I just see whitespace now after running a COMPARE. It's very confusing to attempt to determine what the differences are, and what's going to be copied or not.
[...]
I would rather see full pathnames instead of whitespace and dangling thin lines.

I agree there is a problem here. It's hard to distinguish if 1. no file exists or 2. a file does exist but it's very long path was truncated. Even though in the old version the full path name was also truncated and didn't add much relevant information, at the very least it *did* convey the information that an item exists at this place. I've added background colors to make case 1 more clear.

The Relative Path doesn't contain enough information to tell where a file lives. Please change the Relative Path column to FULL path.

There is already an option to switch between relative/full path. It's in the column context menu and it's been there for years...

This is the reason why "adding just another option" is bad design most of the time. Most users won't find/look for it, and this is absolutely okay! Fixing the underlying issue is better anyway than adding more and more options.

It put a folder at the same horizontal lever as the files at its same level. Then under that folder, all the files and folders contained within were indented a small amount.

That's what Unison does. The special rule for the first file item however looks confusing: viewtopic.php?t=7209

Why haven´t you used the way microsoft is doing it in his explorer-tree-view ever since [For the younger 'Navigation-pane']? It would save up a lot of this white space immediately.

It saves horizontal space but at the expense of bloating up vertical space for all items that have their parent folder items filtered out (which is *most of the time* in the context of a synchronization where files change more often than folders).

Don't use horizontal dashes to separate directory components. Use back-slashes (or forward in Linux). The view is very confusing when directories and filenames actually contain dashes.

The updated grid view will use slashes again. (this wasn't possible with the new tree view, unless allowing inconsistent horizontal positions)

I don't like the new tree view either - it's more confusing. The old view allows me to tell at a glance where a file is located relative to other files. The new tree view forces me to search around, follow lines, until I find what is nested within what.

I agree. The tree view is free of redundancy, but it comes at the price of additional mental overhead required to decipher it. I went back to the drawing board and came up with a less reduced variant: Instead of grouping hierarchically and stripping all redundant parent path information (and indicating it with lines), the new view will only group the leaf elements (=files). Additionally these groups are separated in boxes using full horizontal lines. It's much easier on the eyes now.

tree-v2.png (33.47 KiB) Viewed 79686 times

I'm going to release the next FFS version with these changes and a bunch of others. I think it's a great improvement over the last version, and also the older ones. 11.0 will be the new base for further discussions. Looking forward to hearing more feedback, especially if it's not just about adding an option, but new design ideas on how to improve!

[Bacchus66]

Any chance 11.0 will ahve the interface (tree vs grid) user selectable? As I suggested on this thread: viewtopic.php?t=7446&p=25105#p25105.

I'm optimistic that 11 will be better, but still prefer the grid, I think. I'd at least like to have the option to use that without having to revert to 10.24.

[Musenka]

Your new design is quite OK - I can confirm that.

One remark. Do you really need such huge horizontal spacing for filenames. Does this amount of horizontal spacing mean anything? Why can't it be replaced by minimal spacing as an option for maximum horizontal space economy?

Here is the example based on your screenshot:

Horizontal Space Saved.png (49.44 KiB) Viewed 79667 times

I understand that some vertical space is lost - but what impressive horizontal space saving. And for this example, vertical space extension is not so significant. May be you can consider this as just some TABBING OPTION? It is not required for small paths, but it may be very useful for long paths where current tabbing will produce worse results as compared to minimal tabbing saving horizontal space.

It's just an idea. Your current layout is quite good (but it still may be "broken" for too long paths and filenames).

[lawrence-dol]

@Musenka,

Just what I was going to suggest. Collapse *folder* and *subfolder* names to a single line, but list their contents on separate lines with minimal indenting. Like most good code editors do for empty interstitial folders.

[VladimirII]

Musenka
For the example you show I suggest.
- left side item view, right side relative path
- change column order to everything before the path column
e.g size | date | relative path

Does this save you space viewing through one line of output?

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

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

[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 (59.76 KiB) Viewed 68223 times

11.0 (invalid representation):

Screenshot_20200722_111834.png (68.59 KiB) Viewed 68223 times

It's really a bug, it's not a drawback, etc.

[pooper]

The first screenshot is a demonstration (amongst a lot others) that the tree view is just horrible...

[Musenka]

The first screenshot is a demonstration (amongst a lot others) that the tree view is just horrible...

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

[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 (7.38 KiB) Viewed 68207 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).

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

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

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

[VladimirII]

An 10.24 to 11 comparison with comments.

The tree layout has still optical clutter. What, is written by now in the screenshot.

[VladimirII]

This red line is interesting. As we say 'ein roter Faden' -> "A red yarn" [to follow].

from Directory Opus 12

[randomofamber]

Here is the example ...

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.

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

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


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

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

[Darth Agnon]

Guessing from the comments that 10.24 is still needed for the old file view?

[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 (241.99 KiB) Viewed 67808 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 (163.5 KiB) Viewed 67814 times

[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

[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 :-)