Android: Search File - When you click on "abort cross" or back button, it doesn't re-display files list

[Shagequi]

Hi,

When you search a term in files list and want to go back, the ONLY WAY to retrieve the list of all the files (in their original state), is to "double click" the cross on top right.
If you click once on the cross, or if you use "onBack" button (top or bottom), the current SEARCH status will stay.

The expected behaviour is, when you click on "back" or "cross", the search term is erased, and we go back to the files previous state.

V : 3.9.2

[stale[bot]]

This request did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[Shagequi]

up, @AndyScherzinger @tobiasKaminsky

[AndyScherzinger]

I agree for "back" while "cross" should just clear the search field (see for example gmail, or https://material.io/develop/android/components/text-input-layout/#text-clearing (scrolling up a little) since the "x" is the text clearing icon) also cc @nextcloud/designers @jancborchardt for UI/UX input

[Shagequi]

I don't think that's an UX/UI choice but just a bug ^^

[AndyScherzinger]

As for the "double-click action"? I think it is by design as in first click: clear, second click: close. While it just closes the search... While that doesn't answer your question ;) So it is wrong atm but I can't say for sure how it would be right, your proposal would be one solution and I don't know if there are other ways. GMail for example shows me the search term history if I hit the cross icon.

[jancborchardt]

Fully agree with @AndyScherzinger’s comment at https://github.com/nextcloud/android/issues/5000#issuecomment-573733860
Additionally there is no double-clicking the x, because clicking the x

• clears the input field
• removes the x
• resets the list to initial state cause there’s no filter set
• keeps the keyboard open

[AndyScherzinger]

@jancborchardt unfortunately, no. If you do this on the file list view and hit search (server call, so you might need to wait a little bit), you can click the x twice (1st: clear, 2nd: close) while it just closes the search field but keeps the result shown...

[jancborchardt]

Yes, so what I’m saying is that this is not how it should behave. :) Pressing the x once should clear the search field, reset the list, and remove the x. It basically means "I want to search for something else".

[AndyScherzinger]

Yes, so what I’m saying is that this is not how it should behave. :) Pressing the x once should clear the search field, reset the list, and remove the x. It basically means "I want to search for something else".

Ah, gotcha! 👍

[stefan-niedermann]

i agree with everything except

and remove the x.

Have a look at Gmail, like Andy said - The X stays and can be used to close the search when the text has been removed.

[jancborchardt]

Have a look at Gmail, like Andy said - The X stays and can be used to close the search when the text has been removed.

I did – both on Tobias’ emulator and Marios phone: When you press the x, the x vanishes and makes way for the microphone icon so you can then put in a new search term either by microphone or keyboard. Closing the search is done via the back arrow in the top left.

Or what am I missing? :D

[stefan-niedermann]

My fault, i compared it with an outdated AOSP mail client...

[jancborchardt]

Talked with @Shagequi @tobiasKaminsky and:

• For the x we do as commented above at https://github.com/nextcloud/android/issues/5000#issuecomment-573878976 (which is same as Gmail)
• For the back button we do the same as Gmail or Android apps in general: Goes back to the state that was there before you pressed the search icon (stay in same folder). :)

[Shagequi]

Working on it now

[Shagequi]

@jancborchardt
Good morning,

I would like to get more informations.
in iOS Nextcloud app, the search is performed after user input, in Android the search is performed only after "enter" press.

So when you click on the cross in Android, you only clear the search field, but you don't display "nothing" or a search instruction, you keep the same result.
In my opinion, the best search view behaviour would be this one :

• When user clicks on "search" icon button (magnifying glass), the files list is cleared and a "search" instruction (like on iOS app) is shown, with something like "Type something to search (2 characters min.)"
• When user types something, 300ms after end of typing (debounce), the term is searched (or early if user press enter on keyboard)
• If user clicks on "X" (cross) on right of field, we return to the original RESEARCH state ("Type something to search [...]")
• If user clicks on arrow/back, it cancels the research and return to the original FILES LIST state.

What do you think about that ?

[jancborchardt]

As iOS is also not the right benchmark, here’s an adjusted behavior we should go for: :)

1. When user clicks on "search" icon button (magnifying glass), the file list stays like it is. The keyboard is shown. iOS needs to adjust as well.
2. We can very quickly filter the local file list shown in this folder. This we should do instantly.
3. For the server call: When user types something, 300ms after end of typing (debounce), the term is searched (or early if user press enter on keyboard)
4. If user clicks on "X" (cross) on right of field, we return to the original search state with empty field like in step 1, with search field focused and keyboard open.
5. If user clicks on arrow/back, it cancels the research and return to the original FILES LIST state _before_ step 1, without keyboard or search field.

cc @tobiasKaminsky @AndyScherzinger and also @marinofaggiana for iOS.

[Shagequi]

@jancborchardt

Hello,
Thank you for your answer.

About the step 1 and and 4, I think we really need a "search instruction" like on iOS (currently), for three main reasons :

1. For Android app, there are two separated fragment between the "original files list" and the "filtered files list based on research". If we ask the app to retrieve all the files by clicking on the cross, this is the same result as clicking on the back button, because we either return to the original activity ("view") which was displaying all the files or we redo a query to the server to display all the files in the "filtered files fragment". So... there's a huge redundancy by doing that, and it'll be slow (unless we cache/memory the list of files, which will have the effect of not refreshing anything new files at all).

2. The "standard" behaviour of Google, is to show a history or your researches (i.e. YouTube), or to show main files types like documents, pictures, etc. (Google Drive) for "initial search state". At no time will the files be shown, except when the search is "consistent" (more than 2 characters, files exist, etc.).

3. The major flaw of the application at the moment is its lack of fluidity in my opinion, the less things are displayed on the screen, and the less things are requested from the server or logic to compute, the more the application will gain in stability and fluidity. And the behaviour you expect is not, in my opinion, the most optimal in terms of performance.

[JorisBodin]

@jancborchardt
Step 1:
What you describe is the current behavior, it suggests that this search is ONLY in the current activity list. And not a global search of the whole drive.
For me we should have the same behavior as on iOS (or a majority of applications). We must show the specific search view. Because we're going to search on the whole drive. And not just in the local folder.

Step 2:
Indeed that would be the expected behavior with the current ergonomics (at the first click on the search button). But for me it's 2 things well separated. Local search and search on the whole drive.

Step 3:
Ok :)

Step 4:
We have to go back to step 1. But the one I'm describing.

Step 5:
Yes, we back to the preview view.

[AndyScherzinger]

@Shagequi fixed via your (merged) PR, right?

[Shagequi]

@AndyScherzinger Partially fixed, two bugs have been fixed, but the "features part" is delayed due to layout change

[Shagequi]

https://github.com/nextcloud/android/issues/5402 is the new issue for behaviour.
We may now close this issue :)