Non-standard - and in fact, really awful - list display

Discussion & Support for xplorer² professional

Moderators: fgagnon, nikos, Site Mods

Post Reply
aml
Member
Member
Posts: 39
Joined: 2012 Sep 18, 08:24

Non-standard - and in fact, really awful - list display

Post by aml » 2018 May 05, 09:23

In the regular panes 1 and 2: Whenever, from the currently-displayed file-folder-list, you display a folder content, by pressing "Enter", within the same pane, and if you then go back to the original list, x2 unfortunately does not "remember" the previous list display, which would obviously be the very best solution to the problem described here: Ideally, x2 should then display the "original" list the same way as it had displayed it before that "look-in" into some listed folder.

Such behavior would be ideal since often, you look for some content in some folder, and then, for the same, or for similar / related content, within adjacent / the "following" folders, of the same list (i.e. the same "parent" directory). Thus, when "going back" to that "parent" folder, there would not be any ambiguity "where you are" currently, and by simply pressing, once or several times, the "down" key, then "Enter" again, you could easily browse those other, "sibling" folders.

Instead of presenting this ideal behavior, x2 does exactly the opposite: It invariably display the "parent" folder you are returning to, in a way that the folder you "come back from" is now displayed as the very last entry in the ("parent") list, thereby hiding all subsequent folders / entries in that list.

This is absolutely awful, since a simple "down" key pressing will just show then the very next entry, and then again, another "down" key pressing showing the very next entry only, and so on: You don't have any overview of that GROUP of folders upon which to decide to "look up" which one of those within that group.

Instead, in in order to GET such an overview, you must press "pgdn" (in order to get your "starting target" to position 1 of the list display), then "pgup" (in order to get the cursor to that "starting target", since you want it there, certainly not at the very possible max distance to it (last entry is selected, instead of target entry, which is the very first entry)), and THEN only you can begin with pressing the "down" key, in order to select your next "target folder to look into", and that's what you will have to do for every single such folder.

That's really quite unbearable since people will "check" such folder groups from top to bottom, not from bottom to top (except probably for countries where you "read" from bottom to top and from right to left - Japan?).

Thus, if the ideal solution described above is not possible to implement for some reason (which one?), it should at least be possible to do some "when reverting to previous parent folder, list current folder as very first, not very last one".

Not speaking here of the sub-alternative to BOTH alternatives ("remembering" the previous list position", and "previous sub-folder as first entry") to even position the cursor to the "next" line (which in alternative 2 would be line 2 then) then since after reverting back to the parent folder, which would spare the user the, or their very first, "down" key press which would be otherwise needed in most cases.

These four variants could be handled by options in case, but the current "solution" is just awful, as said.

User avatar
nikos
Site Admin
Site Admin
Posts: 14537
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Non-standard - and in fact, really awful - list display

Post by nikos » 2018 May 05, 12:42

I'm not sure what are you talking about, is it the folder tree or the regular folder pane to the right that bothers you?

at any rate xplorer2 doesn't control the scroll location of the focused item, it just asks for it to be visible and then windows (the OS) decides where to put it. I suppose MS after usability studies decided on such a behavior. To be honest I never noticed anything bothersome

for each user that "doesn't like" the way things are, there is at least another that likes it exactly as it is now. Sad but true. Perhaps you can consider browsing your folders backwards so you get lots of forward context as things are. Just an idea

aml
Member
Member
Posts: 39
Joined: 2012 Sep 18, 08:24

Re: Non-standard - and in fact, really awful - list display

Post by aml » 2018 May 05, 15:37

We're well speaking of the regular display panes 1 and 2, not of the tree pane, see intro of my first post here:

"In the regular panes 1 and 2: Whenever, from the currently-displayed file-folder-list..."

Frankly, I can NOT imagine that anybody (!*) prefers this weird behavior of x2 (I don't know what Windows itself does, but obviously, most file manager developers add their own code in order to avoid this awful, allegedly Window-generic, behavior:

Even free FreeCommander displays the list, after manual reverting to it (as explained above), as it had been before!

((Paid) SpeedCommander does do it correctly, also, i.e. it displays the - always deemed "long" - list (i.e. with "enough" items before and after the current item, in order to not interfere because of "start of list" of "end of list" being to near) as before.

Ditto for (paid) XYplorer: reverts to previous display after having looked into some folder entry.

And even people who speak a language where they read from bottom to top, and/or from right to left, will NOT prefer this awful behavior of x2 here, since in their texts, the ORDER of the "items" (there: things to read) is reversed, too, while in x2, this order of items is NOT reversed for them, so even they are forced, by x2, to "check" their folder lists "upside down":

sort order, and in this order ANYBODY would like to check:
a
aa
aaa

x2 displaying:
...
a
aa
aaa
....

x2 after opening a:
a (= now last item on "page" = visible part of list)
(aa and aaa hidden on "next page")

So even for Japanese (if they are concerned by right-to-left and/or bottom-to-top):
aa and aaa are hidden from them by x2, whilst they would want it perhaps sorted (which is possible of course):

aaa
aa
a
(= reading a, aa, aaa, NOT aaa, aa, a!)

Thus, whenever Japanese opt for inverted sorting (and even for them, under this sole condition!), x2 is acceptable for them in this respect (while probably they'd prefer it the FC, SC, XY way though, like anybody else), whilst for people reading from left to right and from top to bottom, even inverted sorting would not solution the problem - let alone your idea to "check" folder groups upside-down just because x2 - seemingly alone in this among all relevant file managers - hides all the other currently relevant folders from them, otherwise!

No need to say that I have written a macro that intercepts the backspace key in x2 and replaces it with "backspace, pgdn, pgup, down", but you can easily image the visual flicker that creates for me, every time.

It's simply not true that for every way of doing things, be they really bad in case, there are people who prefer them being done that way, except of course when they get secondary benefit, e.g. developers who thus avoid to write the code lines needed for doing it better. It's not necessarily a question of preference, sometimes it's a question of quality.

User avatar
nikos
Site Admin
Site Admin
Posts: 14537
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Non-standard - and in fact, really awful - list display

Post by nikos » 2018 May 05, 16:41

clearly we don't agree on the severity of this issue :)
if you want to work with the next folder you'll press the down arrow and the folder will appear. I am not sure what will you gain by "seeing ahead"

anyway I searched the code and there is a menu command Mark > Selection > Show that puts the selected item on top

if there are other people "offended" by this trivia I will consider changing it for the next version

EMathews3
Member
Member
Posts: 54
Joined: 2014 Aug 23, 12:54

Re: Non-standard - and in fact, really awful - list display

Post by EMathews3 » 2018 Jun 05, 01:24

I share this complaint - about the Tree pane. When drilling down and navigating folders, I can select the next step in the path by typing the first letter or two of the folder name. The most-used folders have single digits at the start of their names. This means they always appear at the top of the list, always in the same order, and are selected with a single keystroke. This is fast - no reading or thinking.

However sometimes the selected folder expands/opens in the tree view, and its contents are displayed in the regular pane, but its sub-folders are invisible off the bottom of the tree view list. This is silly. I opened the folder, so I want to see as many of its subfolders *as will fit in the tree pane* without scrolling the folder off the top of the list. As it is, I have to scroll down to see *any* sub-folders! I'm not done navigating yet, so there's no reason to look at the files pane yet. There's no way to see, using the same control, how many down-arrows I should press, or what next digit(s) to type, or what next letter(s) to type, to continue navigating into lower sub-folders. This is the worst case.

Another sub-optimal case is less unreasonable, but still could be given better Usability. When the folder opens and the tree auto-scrolls down enough to show all of its sub-folders, that is only the minimum it should do. Even better would be to scroll the tree down until the newly-opened folder is at the top of the visible list, perhaps leaving one preceding neighbor also in view above it. This lets me see peripherally what folders / keystrokes are coming up soon, and discards the folders I have already seen and won't look at again during this task. Without this feature, I have to scroll down with the mouse wheel, or do the PageDown+PageUp trick, or switch to the Files pane. This costs time and interrupts the workflow.

Also it's an Accessibility feature. My monitor is placed up high so I can see it without bending my neck down at all. Working in the lower part of the screen causes physical pain, so all my files have whitespace at the bottom, and the cursor is usually in the middle of the screen vertically.

So, here is the request to see about auto-scrolling newly-opened folders to the top of the Tree pane :) The only exception would be at the actual end of the tree list. In that case, anchoring the list-tail to the bottom of the Tree control would be okay.

aml
Member
Member
Posts: 39
Joined: 2012 Sep 18, 08:24

Re: Non-standard - and in fact, really awful - list display

Post by aml » 2018 Jun 05, 15:52

"Also it's an Accessibility feature. My monitor is placed up high so I can see it without bending my neck down at all. Working in the lower part of the screen causes physical pain, so all my files have whitespace at the bottom, and the cursor is usually in the middle of the screen vertically."

Exactly, and for "I am not sure what will you gain by "seeing ahead"":

To immediately decide upon IF I want to look in that folder, or not:

It makes a big difference if "next" folder is hidden beneath the currently-displayed folders, and only visible - and thus, "decidable" for me by "down", and then the next folder again accessible by "down" again, and the next again needing pressing "down", etc., up to the possibly 5th or 6th of similar folders I really need to look into, OR if I see the list of all those possibly 10 folders "in a row" and can then decide upon which one(s) need(s) attention immediately (down, decide, down, decide...) is much slower and visually impairing than deciding by having the whole group before your eyes), so the current behavior simply forces me to do it by the above-described macro. Btw, I've got a fast pc, so the flicker is minimal in practice, WITH that macro, but without the macro, I simply couldn't do it.

Btw, this is not the only occasion where the "then-newly-current-line" is, instead of being the very first one on top, or somewhere-in-the-middle, the very-last-one on the screen, by navigating within x2; but since I stopped trying x2 for everything, but have open concurrently several other file managers, fur further navigation - just 2 active (!) panes are simply not enough for me, and x2's containers do not fill that need -, I cannot give specifics here; all I can say is that I wasn't happy and would have needed to implement other macros to straighten it out in the open, "on-screen", where original bad positioning should have been sorted out behind the scenes: It's all about we Westerners working from top to bottom, so the bulk (!) of what we need to see at every given moment is highly probably below of the "current element", so hiding precisely that part from our view isn't the optimal strategy.

This being said, the exclamation point behind "bulk" stands for "but, most of the time, not the total amount of the entries/items":

The other file managers mentioned above try to "get you back" "where you left", which often can indeed be a previous position which is less than optimal, e.g. in that last quarter of the screen height; my macro I needed so much to overcome x2's behavior puts the next entry at the top of (the displayed part of) the list, simply because that was easy to write for me as a macro.

But in most instances, the ideal position for the current item would be at the bottom of the first third of the screen height, i.e. with 1/3 of the adjacent items (whatever they be) above, and 2/3 beneath it, since, indeed, you sometimes even need to just see and or also work on some of those items, but the bulk of your work (whatever it will be) will be done upon your current item and on those beneath it; it's evident that in programming a file manager, that would be the "retrieved position" to aim for, whilst for achieving this with an external macro, this would imply, at the beginning of the macro (and in the case of this x2 behavior), doing around 20 times "down" (for a screen displaying around 60 items in a row), then the rest of the macro as shown above, and then again the same number of "downs" from top, in order to select that (old, or new, i.e. 21 downs if the "previously current" item is 20 down): lots of "on-screen work" for the macro indeed.

Ditto for the tree and my experience with it; as implied above, I don't use x2 anymore for "global" navigation, so don't use the tree anymore either, but "only" for my main work directory and its sub-folders, whilst here, thoroughly indeed, because of its brilliant "Comment" column; DO's "Comments" aren't processable from the outside either, and are (as far as I have seen in my recent trial of that) just visible one-by-one, which is a similar problem of hiding "valid adjacent" information from the viewer, so x2 really excels here, by comparison.

EMathews3
Member
Member
Posts: 54
Joined: 2014 Aug 23, 12:54

Re: Non-standard - and in fact, really awful - list display

Post by EMathews3 » 2018 Jun 06, 15:04

Agree; the ability to auto-position a Tree's current item at one-third down the screen / window / client area would be great. One-fourth down would be even better. Point is, the default Windows-way is not good enough, and not consistent enough.

Also Mark > Selection > Show is annoyingly "not applicable for the tree pane".

aml
Member
Member
Posts: 39
Joined: 2012 Sep 18, 08:24

Re: Non-standard - and in fact, really awful - list display

Post by aml » 2018 Jun 06, 16:17

Well, after reading you, that'll be simple.

I also wasn't so sure about the optimal positioning; 24 % could be a little bit "short a previous list" sometimes, but 33 % is often shortening the list of "next" items unnecessarily indeed.

Since we both speak of percentages, not numbers, and since we certainly agree that according to the number of possible items / height and resolution of the screen (office / home office vs laptop(s) of various sizes), the number (i.e. the numbers above and beneath the then-current-item) should remain reasonable, and which means that the percentages and numbers must vary with with the screen "offerings" anyway, it's evident that the program would need, not only upon start, but then also, after any window resizing, character resizing, etc.), determine the number of visible items ("lines"): much too complicated for very little effect.

HENCE: Why not do a command instead (accessible by menu, i.e. by shortkey, i.e. easily adjustable by the user, which would not be the case with a global setting) "current-item default-position on line n", the default being position "1", and then the user can adjust that position to their - then current - needs, perhaps even just "11" with 10 entries above and around 50 entries below.

Since that would be easy to implement, just have an internal switch "if the (said) variable is NOT 1, do some additional, internal scrolling (of n-1 lines), before updating the pane display" (not if there aren't enough lines to display, from the amount of further items that is).


Of course, some additional goodies could be imagined: Whenever the user has been working on some list for some time (even with interruptions by going forth to other, target lists, and then back again), and then reaches the bottom 30 % of the screen, do an automatic scroll of 30 % of visible-items-number up...

BUT the real problem in that lies elsewhere: Currently, the user must either position the mouse very precisely and do the manual scroll there, which preserves the current item in scrolling but which comes very unhandy.

Or they must press the down and pgup keys - most of the time, they will do a combination of both, first a pagedown, then some 20 lines by pressing "down", and since this keyboard "solution" invariably LOSES the current item (you then press "up" for some time in order to get there again, it's a lot of fiddling around), you AVOID doing it as far as possible, then only do all the necessary work when it'll have become unavoidable.

In other words, a perfect file manager or other program handling long lists would have an option which automatically did a 1-line scroll for every "down" of the user, the then-current item remaining at position n (see above) then. ;-)

EMathews3
Member
Member
Posts: 54
Joined: 2014 Aug 23, 12:54

Re: Non-standard - and in fact, really awful - list display

Post by EMathews3 » 2018 Jun 06, 16:37

Reading your posts gives me a headache.

Some high-usability systems are known for ... the Scroll-Down and Scroll-Up arrow keys move the control's "background", so the cursor / highlight effect does not move vertically, but the data items behind it *do* move. This would solve the whole problem, eh? The highlighted item changes, but the highlight itself stays in exactly the same spot visually.

aml
Member
Member
Posts: 39
Joined: 2012 Sep 18, 08:24

Re: Non-standard - and in fact, really awful - list display

Post by aml » 2018 Jun 06, 17:57

Yes, that's right, you see scrolling of just the background, however they do it technically. Depending on the software and the length of the list in question, the lists are not necessarily held within work memory / variable, but fetched again from the source, so there are lots of variants how to do it, but it's all about scrolling the list while leaving the current-item alone.

Let me give an example for not-immediate list updating: Sometimes, in order to see the correct updates of my "Comment" tags (which are displayed immediately) also within the symbolic links of the original files, I have to close and reopen x2, while at other times, they appear just after switching to another folder, then back to the folder in question, or even after switching to another part of my long list of entries within the same folder, for example at the position of the link; in other words, sometimes, the info appears in time, sometimes not but only after non-connected "updates".

Fact is, programs which "scroll the background" intelligently may exist, but I've never encountered any of them, so I thought it worthwhile to mention it could be done. Fact is, the regular functioning of the "pagedown" button (anywhere) is really, really bad for "natural browsing" of long lists, and the same applies to such lists in web browsers, "naturally". In fact, most of the time, the VERY FIRST pressing of the pgdn button does NOT what the user would want, really, whilst only the subsequent pressings of that key, in a row, will do what you want:

Their technical doing is the same, while there should be two different functions indeed, but it's possible to intelligently combine them in just 1 key in that kind of "first pressing" vs. "further pressings" (not immediately one after the other, just no other key in-between), since even for the situation that you want to see "further pages", the above-described functionality on first pressing is not harmful, while, when you think about it, in 99 p.c. of all real-life use cases, the current functionality of pgdn, on FIRST press, it completely useless, and could easily integrate the (systematically-needed) second pressing, too, as well as an immediately following pgup, in many cases, but not in all indeed, since causing a necessary pgdn if you don't find what you need on that second "page"), so what I have in mind would be MUCH progress, for everybody.

Subsequent pgdn-presses should come with functionality similar to the currently-regular functionality, since for browsing long lists of "pages", users wouldn't that much like to always have 1/4 or 1/3 or previous, already discarded items, but the second press should of course not just go down either, as the first press does now, but should intelligently show a completely-new "page" "below" maxnumber-of-current-page. In other words, first pgdn only presents you with 3/4 of "new" items, while second and further presses will give "full pages" after the last entry of that second, 3/4-only "page", reached by first press, while "current item" would stay at 25% or whatever, convenient stable position.

If you know programs (which cannot be another file manager since I knew it then) which do it intelligently, please tell me, I'd like to trial them just for the fun of it.

namsupo
Member
Member
Posts: 49
Joined: 2007 Aug 29, 02:02

Re: Non-standard - and in fact, really awful - list display

Post by namsupo » 2018 Jun 07, 08:14

because of its brilliant "Comment" column; DO's "Comments" aren't processable from the outside either, and are (as far as I have seen in my recent trial of that) just visible one-by-one, which is a similar problem of hiding "valid adjacent" information from the viewer
What does that mean? Of course DO has a Comment column.

aml
Member
Member
Posts: 39
Joined: 2012 Sep 18, 08:24

Re: Non-standard - and in fact, really awful - list display

Post by aml » 2018 Jun 07, 09:27

Please see my answer in viewtopic.php?f=18&t=11604&p=72639&hilit=ADS#p72639 here in this forum; I abhor spaghetti code, and I'd like to prevent spaghetti discussion, too. Entirely my fault up to now, btw. (If you see this post immediately after my posting, by some alert, please allow for some 10 minutes before reading over there.)

Post Reply