XYplorer Beta Club

highend wrote:Con:
You don't see if a file is e.g. 1kb or 10kb large (you'd only see a 1-2 pixel large block of the top color).

Don't know if the con is solvable at all with the limited length of the size bar

i really like this idea! more informative.
and solution for Con is easy: let user be able to set this 5 ranges of size.(tweak would be enough)

for ex i'd set for myself it as:
0bytes = empty file no color=white
bytes aren't represented due to fact that such tiny files are rear. as non-empty file they can be colored blue
1Kb -100Kb blue
100KB-1Mb green
1Mb-100Mb yellow
100Mb-1Gb orange
1Gb-100Gb red
and if you have 100+Gb files - you're a monster

admin wrote:I can see it well here. You might need to calibrate your monitor. Which color is it that you cannot see?

you guessed it right, the light blue of empty parts.

If I may add my thought as well:

1) I am not sure, what *real* benefit the bars actually serve. I mean in which real live scenario does it bring a real benefit. For me it is has just been a nice thing that adds some color, is nice to look at and can be played around with. To find a solution which will work for most users, this question of course must be thoroughly answered first: Which real live benefit do most users really hope to get our of these bars (and with as muc detail as possible: in which real life scenarios)? I would be interested in the results / answers.

2) Even if doing such a "survey" it seems almost already clear that the opinions will differ. In this thread alone it became clear that some like it linear, some like it logarithmic and some like it relative (probably also linear) to only the files (and maybe folders?) in the current location. Some (or most?) would like to be able to have different colors and be able to adapt these to their own intuition. So, from this perspective, really the point #1 above could be skipped and the bars could be made completely user defineable in the settings dialog, giving the user control to make the bars behave in any of the just mentioned ways.

BTW, dividing the bar into sub-bars, is IMHO a very good idea.

Thanks for the input. ATM I'm not inclined to go back to a color system. That's where we came from after all. I'm quite happy with the current solution. Let's give it some time to settle. BTW, logarithmic scales are not that un-human. See "Why do we perceive logarithmically?" at https://rss.onlinelibrary.wiley.com/doi ... 13.00636.x

What *real* benefit the bars actually serve? I think a graphic representation of file sizes lets you grasp them from the corner of the eye, without focusing. That's harder to do with mere numbers, which again depends on the Size column format and the font. So you will become a little faster, get the rough information a little easier, you will spot patterns and breaks in patterns quicker.

E.g., the characters for "3" and "8" are quite similar (depending on the font as well, of course). Graphics can help here:

BTW, logarithmic scales are not that un-human. See "Why do we perceive logarithmically?

Aha. So, did you ever placed a 3 inside the middle of 1 - 10? And if you did that as a 3 or 4 year old child, do you still do it as a grown-up?

Log isn't something that people "easily grasp". Take loudness measurement. DB is a log value. How many people do you know who can answer
the question +what DB represents the *2 factor in loudness? That's why linear systems (e.g. like Sone) were developed because people can easily grasp that * 2 times a value means it's twice as loud...

What does a bar that has a fill value of 75% tell me about the size of a file when in reality it is only one third (like your last picture for 330 kb .jpg files) of the belonging range? Does that graphical representation tell the user anything at all about the real size?

For the real size you have the numbers. The graphics show whether a file is bigger or smaller than the other files in view.

For the real size you have the numbers. The graphics show whether a file is bigger or smaller than the other files in view

Yeah, the question is only: By what margin? I can agree that the fourth and the second files must be some min / max values in a specific range (in this case: MB).
But is it easily visible / understandable that the first is 1/10 of the second or 10 times larger than the third? Imho: No, it isn't

"In general" there is no "better" for linear or logarithmic.
It's about what you want to see!

If you have (among others) 2 files of 100B and 10KB, it *may* look strange if these (differing by 10000%) both look like empty. So there *can* be an advantage for logarithmic.
And I've seen many diagrams in logarithmic scale, that wouldn't have been of interest if made linear.

You can say: linear shows absolute differences (i.e. 1000 bytes larger), while logarythmic shows relative differences, i.e. 10 time as large. Both *can* make sense.

I'd prefer logarithmic here

while logarythmic shows relative differences, i.e. 10 time as large

So you can deduct from my last screenshot that the first item is 10 times larger than the third?
And that the second item is again 10 times larger than the first?

By doing what, "unlog" that mathematical equation? The only thing that is visible is that one file
is larger than the other, but you can't say: By a factor of 10 / by 100 MB / by ... what?. And if we need to look at the
actual size and can't see how large the real margin is when looking at the graphic, what purpose does this log
presentation serve at all?

Hm - I can see the advantages of seeing absolute sizes.
But: as long as you don't identify a scale you can't "see" (identify) a unit of 10B or 10GB.

Why do you refuse to see the advantages of seeing the relative sizes?
You are right: here you can't identify the factor - be it 2 or 10 or 1000 - if you don't know a scale.

But: as long as you don't identify a scale you can't "see" (identify) a unit of 10B or 10GB

There already a few propositions (based on color) how to do that in this thread.

Why do you refuse to see the advantages of seeing the relative sizes?

What advantage? If a graphical representation doesn't tell me immediately that a file
is 10 times (a factor) or 100 MB (a fixed value) larger than some other file? The only
visible thing is: Something is larger or not. Just by looking at the "Bytes, KB, MB or GB"
for the real size I can see the same info (and don't need to count the number of blocks
inside the size bar).

You are right: here you can't identify the factor - be it 2 or 10 or 1000 - if you don't know a scale

You know the range in this case. 1025 kb - 1023,99 MB.
Just look at item 1 vs item 2. Item 2 is 10 times larger than item 1 (1000 MB vs 100 MB). Can you deduct the
factor or fixed difference in size from the size bar? You can't. -> Pointless representation

Anyhow, I give up. A feature that I wouldn't even call a feature , "Bars" = disabled

I like the current visual and the meaning of boxes, but the logarithmic approach is not my cup of tea, because It shows every files between 35%-75% the same, almost full box, for me it is misleading. I would like to understand why it "works suprisingly well" in case of file sizes.

Edit: I have read about it a bit deeper. Logarithmic approach is for more serious problems, in a nutshell, to show something which cannot be shown well enough by linear scale. There is no underlying meaning behind file sizes, so using anything but linear only makes things more complicated. The main phrases at the end of those articles: "... not always..." and "... hard to understand, so not for all audiences...".

Maybe it's better to combine the old approach with the new one?
About level of the size, I will know by the filled bars, but these bars will be for example 2 pixels long.
About the relative magnitude of the size within the level I will know from the last bar.
The last bar will reach the edge.
The bars will have color as before.

LittleBiG wrote:I would like to understand why it "works suprisingly well" in case of file sizes.

When looking at my folders full of real world files I find that files that to me have a considerable difference in size also show different bars, and files that are rather in the same size "group" show the same bars. Well, maybe I'm a logarithmic kind of guy.

DmFedorov wrote:Maybe it's better to combine the old approach with the new one?
About level of the size, I will know by the filled bars, but these bars will be for example 2 pixels long.
About the relative magnitude of the size within the level I will know from the last bar.
The last bar will reach the edge.
The bars will have color as before.

Code: Select all

||  | ........|     >KB
|| || |.......|      >MB
|| || || |.....|     >GB
|| || || || |..|      >TB

Yes, I had the same idea. It will add resolution to the last bar, which is fine. But it's also a complication of a simple system. Let's give the current solution some time first.

Yet another idea: Have both linear and logarithmic side by side. Now that's revolutionary! And it works surprisingly well... ... and it's fascinating to see how the two scales complement each other. The upper half of the bar is linear, the lower half is logarithmic: