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 47963 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 47963 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 47941 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 46104 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 46085 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?