Some enhancements and suggestions on the search functions

[uahnbu]

Part 1

About the instant search function (shallow search on current folder, not the search bar), I've had some research about it. I find the one of VSCode, which highlight all matches on shallow search, creative. However, it lacks the ability to navigate through matched files. That's why I prefer to stick with the behavior of Windows File explorer (WFE) (idk if other os are the same). I'd therefore make suggestions based on WFE.

1. The scrollbar should be updated when an item is focused. The function scrollIntoView without parameters on HTML elements is fully supported on most platform.
   However the option to scroll the element to the center is not supported by many devices. If you got time, take a look at my manual scroller which supports centering, smooth scrolling, and focusing nested target (e.g. child-div in overflown parent-div in overflown viewport)
2. The time for the search state in WFE is 1000ms, which is ridiculous. I'm a snail irl yet still feel it is a decade before I can search again. My suggestion, taken from previous project experiences, is that it should be around 700-800ms.
3. There's actually an exception in WFE. If the search string is only 1 letter long, and if the next input is the same as the first letter, then WFE will instead navigate to next matched file (i.e. the next file starting with that first letter, or the first one if there's no match left).
   For example, pressing dd will navigate to the second file starting with d, meaning that there's no way to get to dd.txt before navigating through all da-, db-, and dc-started files.
   Therefore, I'd like to bring this feature to the next level by introducing more rules:
   • In the search state (SS), pressing keys will add letters to the search string as usual.
   • After the search state ends (i.e. 720ms after there's no more input), it proceeds to the navigation state (NS), where pressing the key that matches the last letter of the search string will allow navigating through matched files.
   • If any key other than that last letter is pressed, then the search string resets and a new SS occurs.
   • For example in the SS I typed de, then if I press e again after 720ms, I'll in turn navigate through all the debouce.txt, decision.txt, decode.txt, deepfake.txt, etc. files.
   • For anyone who may ask, "Isn't up/down arrow enough?", I'd say that it's not applicable when the files are sorted by date, size, etc. instead of name.
   • There will be the case where you're at a de-started file, then you want to search for egg.txt next instead. To do that, you'll have to press another key, e.g. f, to move to a new SS, then wait some time for it to switch to NS, before being able to press e to begin searching for egg.txt. This is why I used the 720ms interval, which should suit both slow typers and active searchers.

Part 2

In this part I'll talk about some ideas of my own that WFE doesn't have. (applicable for both search functions)

1. For language convenience you could remove the accents/diacritics. For example đếm_cừu.txt should be searchable with dem_cuu.txt. The conversion can be achieved by using normalize function on string, as in this article. Idk but I think that even Chinese can be search using this method, as I heard they write words by typing Latin pronunciations before converting them to Chinese characters.

Part 3

In this part I'll talk solely about the search bar.

1. I love the idea that you show all the filepath of the search's results. However, they all share a root (i.e. the folder in which you're searching). Therefore it's better to omit that part.
2. I once looked at the search result and wondered what was so wrong but I didn't notice.
   
   At last I found out that you missed this bar:
   
   "What's the role of it?", you may ask. When you double click an edge of a column, it will expand that column to fit all the filename, which is really convenient.
3. I find the search a bit slow. Have you implemented trie or any other techniques?

[kimlimjustin]

Part 1

1. The scrollbar should be updated when an item is focused. The function scrollIntoView without parameters on HTML elements is fully supported on most platform.
   However the option to scroll the element to the center is not supported by many devices. If you got time, take a look at my manual scroller which supports centering, smooth scrolling, and focusing nested target (e.g. child-div in overflown parent-div in overflown viewport)

Good point, but I think the point of scrolling element into the center is not supported does not apply here, cuz actually Xplorer uses MS Edge's webview to handle the frontend (you may notice when installing Xplorer, the installer asks you to update/install edge's webview), and Edge is supported, so I think I might keep the thing simple.

2. The time for the search state in WFE is 1000ms, which is ridiculous. I'm a snail irl yet still feel it is a decade before I can search again. My suggestion, taken from previous project experiences, is that it should be around 700-800ms.

I set it as 500ms for now, should I change it to 720ms?

3. There's actually an exception in WFE. If the search string is only 1 letter long, and if the next input is the same as the first letter, then WFE will instead navigate to next matched file (i.e. the next file starting with that first letter, or the first one if there's no match left).
   For example, pressing dd will navigate to the second file starting with d, meaning that there's no way to get to dd.txt before navigating through all da-, db-, and dc-started files.
   Therefore, I'd like to bring this feature to the next level by introducing more rules:

• In the search state (SS), pressing keys will add letters to the search string as usual.
• After the search state ends (i.e. 720ms after there's no more input), it proceeds to the navigation state (NS), where pressing the key that matches the last letter of the search string will allow navigating through matched files.
• If any key other than that last letter is pressed, then the search string resets and a new SS occurs.
• For example in the SS I typed de, then if I press e again after 720ms, I'll in turn navigate through all the debouce.txt, decision.txt, decode.txt, deepfake.txt, etc. files.
• For anyone who may ask, "Isn't up/down arrow enough?", I'd say that it's not applicable when the files are sorted by date, size, etc. instead of name.
• There will be the case where you're at a de-started file, then you want to search for egg.txt next instead. To do that, you'll have to press another key, e.g. f, to move to a new SS, then wait some time for it to switch to NS, before being able to press e to begin searching for egg.txt. This is why I used the 720ms interval, which should suit both slow typers and active searchers.

So basically the idea is to check if the user type the same letter as he/she typed before, and if it is, then searches for the next name for the same query, otherwise, push the char user typed into the query, do I got it correctly?

Part 2

In this part I'll talk about some ideas of my own that WFE doesn't have. (applicable for both search functions)

1. For language convenience you could remove the accents/diacritics. For example đếm_cừu.txt should be searchable with dem_cuu.txt. The conversion can be achieved by using normalize function on string, as in this article. Idk but I think that even Chinese can be search using this method, as I heard they write words by typing Latin pronunciations before converting them to Chinese characters.

This is a really good point, will surely implement it. However, for the Chinese character, I don't think we can implement it (tried the StackOverflow answer in console too, and does not work), cuz Chinese character is completely different from English and its family, Some Chinese characters have multiple pronounciation, for example "乐" can be spelled as lào, liáo, lè, luò, yào, yuè which is really hard to normalize it with English character, except using some library out there, but as a cost it will make the process heavier and slower, so maybe I'll just support English family language.

Part 3

1. I love the idea that you show all the filepath of the search's results. However, they all share a root (i.e. the folder in which you're searching). Therefore it's better to omit that part.

Ah ye, forgot to handle it (really got almost no time to code so yeahh), will omit the folder user searching in

2. I once looked at the search result and wondered what was so wrong but I didn't notice.
   
   At last I found out that you missed this bar:
   
   "What's the role of it?", you may ask. When you double click an edge of a column, it will expand that column to fit all the filename, which is really convenient.

I think this will be another feature request, I'll do this in the new year holiday maybe.

3. I find the search a bit slow. Have you implemented trie or any other techniques?

Idk if you noticed it but the search technique is by using the glob pattern, it might take a bit slow, but I think searching in WFE also take some time right? maybe the place to improve is the function to render the file into the webview, current approach is by whenever there're 100 glob matches, it will send it into the webview to render it, do you have any suggestion with this?

Overall, I really appreciate your researches on this, and I'll surely improve it when I got time (act need to wait until the new year holiday to get free time tho, cuz I'm having exam in this 2 week).

[uahnbu]

I don't too lol. 750ms then as it's 3/4 of 1 sec 😉

[uahnbu]

Xplorer uses MS Edge's webview to handle the frontend (you may notice when installing Xplorer, the installer asks you to update/install edge's webview), and Edge is supported, so I think I might keep the thing simple.

You can choose between Chrome/MSEdge view? That's cool. I did see MSEdge webview installed. So I'll always get the latest version of webview, rite?

So basically the idea is to check if the user type the same letter as he/she typed before, and if it is, then searches for the next name for the same query, otherwise, push the char user typed into the query, do I got it correctly?

Yeah you got most of them right. Actually when you type the same letter fast (before that 750ms), e.g. bee, you'll search for bee- instead (as it's still in the search state SS).

Some Chinese characters have multiple pronounciation, for example "乐" can be spelled as lào, liáo, lè, luò, yào, yuè which is really hard to normalize it with English character

Yeah maybe that. I watched how they type using the phone (they're crazily fast 😂), in which they type in English, then Chinese suggestions appear above. They might have to use some NLP on that, which is indeed costly.

Idk if you noticed it but the search technique is by using the glob pattern, it might take a bit slow, but I think searching in WFE also take some time right?

Yeah I haven't looked at the code yet 😂 Yeah WFE is kinda same, 1-2s more or less. I'd think of a workaround in the future.

When I'm done with my thesis, I'd love to get involved more 😄

[kimlimjustin]

You can choose between Chrome/MSEdge view? That's cool. I did see MSEdge webview installed. So I'll always get the latest version of webview, rite?

No, but Tauri uses MSEdge's webview while Electron uses Chromium, and Xplorer uses Tauri, that's why it uses MSEdge's webview as the frontend look (actually MSEdge is built and modified version of Chromium tho....). For the version, I think it's always install the latest version for the user.

Yeah you got most of them right. Actually when you type the same letter fast (before that 750ms), e.g. bee, you'll search for bee- instead (as it's still in the search state SS).

Okay, will improve it.

Yeah maybe that. I watched how they type using the phone (they're crazily fast 😂), in which they type in English, then Chinese suggestions appear above. They might have to use some NLP on that, which is indeed costly.

I think some keyboards use NLP for processing that and some others use the brutal way, by checking one by one Latin character user type in into the dictionary, and it's easier to convert from Latin to Chinese than from Chinese to Latin, cuz some Chinese Characters got many pronunciations as I said above, what Chinese user need is to type one of the pronunciation and they will search it, but in this case, the thing is I have no idea how to handle this, cuz when there's many Latin corresponding of a Chinese char, I got no idea of what to pick, except by NLP which have a lot of costs. Also, just say we done the Chinese things, what about Korean, Japanese, Arabian etc 😂

When I'm done with my thesis, I'd love to get involved more 😄

Haha, actually you can just open a PR if you got anything to improve, cuz I have little time to code this two weeks.

[kimlimjustin]

Implemented it, could you please give it a try? @uahnbu

[uahnbu]

@kimlimjustin Actually it's quite laggy? Sometimes navigating doesn't work (at the first letter, and I've waited for some time), it keeps staying at one place and I've had to spam the letter 2-3 times, which may also lead to skipping a file sometimes.
I haven't seen navigating at the 2nd, 3rd, etc. letter work yet? For example i typed da, then waited for some time, then pressed a again, it jumped to adobe.txt instead of navigating to data.txt

[uahnbu]

@kimlimjustin I have some more ideas of improvement for the functionality:

• The search time for the first letter is 500ms, and other letters 750ms, then it'll be easier to navigate at the first letter. It's because users in general type 1 key twice at a faster speed (below 500ms), whereas the duration for users to press 1 key twice to navigate is longer (above 750ms)
• You can change the placeholder of the search bar with the instant search string (if the string is not empty). Yet the search string should reset when anywhere on the screen is pressed (including the search bar)

Actually I'm really excited about the app and these features in particular. I'm on 🔥 to get them work as expected as soon as I finish my works 😂

[kimlimjustin]

The search time for the first letter is 500ms, and other letters 750ms, then it'll be easier to navigate at the first letter. It's because users in general type 1 key twice at a faster speed (below 500ms), whereas the duration for users to press 1 key twice to navigate is longer (above 750ms)

Do you mean, after the first typing, listen for 500ms for the second letter, then 750ms for others, do I get it correctly?

You can change the placeholder of the search bar with the instant search string (if the string is not empty). Yet the search string should reset when anywhere on the screen is pressed (including the search bar)

I'm not sure about this tbh, cuz the search bar thing will be a recursive search and it's glob pattern, so idk what to show tbh.

[uahnbu]

Do you mean, after the first typing, listen for 500ms for the second letter, then 750ms for others, do I get it correctly?

Yeah you do

I'm not sure about this tbh, cuz the search bar thing will be a recursive search and it's glob pattern, so idk what to show tbh.

I mean that you show the instant search string for user to know what they've typed.
In VSCode the instant search string is shown at the top right corner as below:

Instead of creating a new floating div just for showing the instant search string, you can bind it to the search bar. Just display something like Instant search: da

[kimlimjustin]

ah okay, got it, will implement it