Size Bars visual should be improved
Re: Size Bars visual should be improved
One bar element is 11 px large (100% dpi, 1920x1200) so 10% size difference is just a damn single pixel (for the linear graphic part).
The old bar length is ~50px, -> 5px per 10% *sigh*
Where exactly is the problem that full colorized bars (with user definable colors!) don't solve?
Linear, enough space to display size differences and everyone is able to see the difference between
e.g. orange (for GB) and red (for TB) without the necessity to count bar elements. And if they are
color blind they can choose different colors that match their needs...
The old bar length is ~50px, -> 5px per 10% *sigh*
Where exactly is the problem that full colorized bars (with user definable colors!) don't solve?
Linear, enough space to display size differences and everyone is able to see the difference between
e.g. orange (for GB) and red (for TB) without the necessity to count bar elements. And if they are
color blind they can choose different colors that match their needs...
One of my scripts helped you out? Please donate via Paypal
-
- Site Admin
- Posts: 60602
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Size Bars visual should be improved
The relation between color and size is not intuitive, the relation between length and size is.
FAQ | XY News RSS | XY Twitter
Re: Size Bars visual should be improved
Colors require no counting, bar elements do. And the relation between length and size is displayed via theThe relation between color and size is not intuitive, the relation between length and size is.
fill grade of the bar and that with a much higher resolution: 5:1
One of my scripts helped you out? Please donate via Paypal
Re: Size Bars visual should be improved
Hi, it's me again,
Really both systems have their pros and cons. I can also kind of understand why you, highend, want the old way back. But at least the argument about "bars counting" is nonesense. No one needs to count bars. Its a visual impression, more bars = more visual impression. Otherwise, one could use the same logic to say about one long solid bar, that you have to count the pixels. Really.
Regarding the old way about colors:
Even if I could define the colors myself, I could never remember which color is for which size range.
Suggested solution:
A combination of both systems, but in a different way than now (because now needs too much eye training and also highend is right with the scaling issue). I would suggest to have both systems not on top of each other but 1) side by side and 2) again with colors, BUT to have each block in the "logarithmic" bar colored according to the color specified for that range. Then the linear bar on the side of it would be kind of a linear "magnification" of the size range in which the size of file "falls into". In effect, the linear bar would be exactly like it was before.
Benefit:
This way you have the "logarithmic" approach there (as well) and it would be easy to remember the colors for each size range because they would always be there in the "logarithmic" bar. (Ofc, the user should be able to turn each bar off individually, if so desired.)
I attached an illustration: Ofc, this is only a suggestion, as you know. Probably there are better ideas.
Really both systems have their pros and cons. I can also kind of understand why you, highend, want the old way back. But at least the argument about "bars counting" is nonesense. No one needs to count bars. Its a visual impression, more bars = more visual impression. Otherwise, one could use the same logic to say about one long solid bar, that you have to count the pixels. Really.
Regarding the old way about colors:
Even if I could define the colors myself, I could never remember which color is for which size range.
Suggested solution:
A combination of both systems, but in a different way than now (because now needs too much eye training and also highend is right with the scaling issue). I would suggest to have both systems not on top of each other but 1) side by side and 2) again with colors, BUT to have each block in the "logarithmic" bar colored according to the color specified for that range. Then the linear bar on the side of it would be kind of a linear "magnification" of the size range in which the size of file "falls into". In effect, the linear bar would be exactly like it was before.
Benefit:
This way you have the "logarithmic" approach there (as well) and it would be easy to remember the colors for each size range because they would always be there in the "logarithmic" bar. (Ofc, the user should be able to turn each bar off individually, if so desired.)
I attached an illustration: Ofc, this is only a suggestion, as you know. Probably there are better ideas.
[AHK] redirecting Windows Explorer to XY, [XYS] Mini Tree with open tabs (cur loc expanded, tab folders highlighted), [AHK] customInlineRenameKeys, [AHK] clipboardHelper_and_XYEscToList
-
- Site Admin
- Posts: 60602
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Size Bars visual should be improved
Thanks, but I'm quite happy with the one-color-only solution in the current version. There are already so many colors with different meanings all over the place. Your solution would also take more space.
FAQ | XY News RSS | XY Twitter
Re: Size Bars visual should be improved
Yes, I can agree now.admin wrote:... And it works surprisingly well... ... and it's fascinating to see how the two scales complement each other.
Re: Size Bars visual should be improved
How should be interpreted the last square now?
(PS: a couple of things:
- circles for folders are brown, shouldn't bars be the same?
- bars don't mantain their aspect ratio in Touchscreen Mode)
(PS: a couple of things:
- circles for folders are brown, shouldn't bars be the same?
- bars don't mantain their aspect ratio in Touchscreen Mode)
Tag Backup - SimpleUpdater - XYplorer Messenger - The Unofficial XYplorer Archive - Everything in XYplorer
Don sees all [cit. from viewtopic.php?p=124094#p124094]
Don sees all [cit. from viewtopic.php?p=124094#p124094]
-
- Site Admin
- Posts: 60602
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Size Bars visual should be improved
- The darker the bigger.Marco wrote:- How should be interpreted the last square now?
- circles for folders are brown, shouldn't bars be the same?
- bars don't mantain their aspect ratio in Touchscreen Mode
-
-
FAQ | XY News RSS | XY Twitter
Re: Size Bars visual should be improved
You mean the fuller the bigger, right? But how are you filling it, exactly? I see there's a bottom half and a top half...
- Attachments
-
- Appunti-20180817.png (4.81 KiB) Viewed 2445 times
Tag Backup - SimpleUpdater - XYplorer Messenger - The Unofficial XYplorer Archive - Everything in XYplorer
Don sees all [cit. from viewtopic.php?p=124094#p124094]
Don sees all [cit. from viewtopic.php?p=124094#p124094]
Re: Size Bars visual should be improved
See the beta notes..Marco wrote:But how are you filling it, exactly? I see there's a bottom half and a top half...
v19.10.0107 - 2018-08-14 13:10
* Size Graphics: Now the upper half of the bar is linear, the lower half is
logarithmic. Both scales nicely complement each other and you get a pretty
well spread resolution.
Windows 11, 23H2 Build 22631.3447 at 100% 2560x1440
Re: Size Bars visual should be improved
Oh yes, silly me!
Tag Backup - SimpleUpdater - XYplorer Messenger - The Unofficial XYplorer Archive - Everything in XYplorer
Don sees all [cit. from viewtopic.php?p=124094#p124094]
Don sees all [cit. from viewtopic.php?p=124094#p124094]
Re: Size Bars visual should be improved
Or the history of this forum thread.klownboy wrote:See the beta notes..Marco wrote:But how are you filling it, exactly? I see there's a bottom half and a top half...
"Logarithmic" in this context means each pixel stands for a file size twice as much as the pixel before (so always x2 for each pixel). Need to wrap your brain around it, e.g. the log bar filling the MB-range-box almost completely with only one pixel missing, does NOT mean that the file is almost 1 GB BUT that it is about 500 MB (about 1/2 GB) - two pixels missing from the full MB-range-box - still an almost full box - means that it is about 1/4 GB.
Both scales have their pros (and cons). Actually they really do compliment each other nicely. Thx for the implementation, Don.
QUESTION, though, Don:
What are the exact size ranges for each logarithmic pixel? Lets say the first box (byte range) is full: What is the exact range of bytes that the file could have? Is it >= 768 and < 1536 bytes?
[AHK] redirecting Windows Explorer to XY, [XYS] Mini Tree with open tabs (cur loc expanded, tab folders highlighted), [AHK] customInlineRenameKeys, [AHK] clipboardHelper_and_XYEscToList
-
- Site Admin
- Posts: 60602
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Size Bars visual should be improved
Good you asked! I got curious, made some checks and found rounding errors. From next beta it's like this:autocart wrote:QUESTION, though, Don:
What are the exact size ranges for each logarithmic pixel? Lets say the first box (byte range) is full: What is the exact range of bytes that the file could have? Is it >= 768 and < 1536 bytes?
The first size that completely fills the first bar is 963 bytes:
9.5 * 1024/10 = 972,8
The last size that completely fills the first bar (and nothing else) is 1023 bytes:
10 * 1024/10 - 1 = 1023
For the other bars you replace 1024 (1 KB) with 1 MB, 1 GB, 1 TB ...
FAQ | XY News RSS | XY Twitter
Re: Size Bars visual should be improved
grey would be nice as well.Marco wrote: - circles for folders are brown, shouldn't bars be the same?)
-
- Site Admin
- Posts: 60602
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Size Bars visual should be improved
Already used for "empty".Filehero wrote:grey would be nice as well.Marco wrote: - circles for folders are brown, shouldn't bars be the same?)
And brown is a beautiful color: earth, wood, skin, nuts, hair, whiskey...
FAQ | XY News RSS | XY Twitter