Android: Full Next Search: UI displaying search results

[tobiasKaminsky]

If full next search is enabled, we can use this to search within files.
The result is then the file with one (or more) search exerpts, e.g:

Nextcloud Manual.pdf with search "test":

"\/\/nextcloud\ndavfs user,rw,auto 0 0\n\n8. Then test that it mounts and authenticates",

" to Internet Options, Content Tab, Clear SSL State.\n\n17. Close browser, then re-open and test.\n\nProblem",

", as this scenario illustrates:\n\n1. User1 shares a folder “test” with User2 and User3\n\n2. User2",

" (the recipient) deletes a file\/folder “sub” inside of “test”\n\n3. The folder “sub” will be moved"

This is the current search result:

@jancborchardt

[AndyScherzinger]

I'd say

• add the excerpts to the list items
• have some white space between them (8dp or 16dp)
• make the search term/hits bold
• use grey for the font color (like the size, timestamp).

what do you think @jancborchardt ? To me the found file is the most important information thus still black while the excerpts just give you an idea "what" has been found and you likely have to open the file anyways, so grey sounds good to me. Looking at search engine results it is also like that meaning the excerpt have less contrast/focus.

[tobiasKaminsky]

Your ideas sound great!
If @jancborchardt is fine with this, do you have time ant want to help me with the UI thing? 👍

[AndyScherzinger]

Sure thing! If there is a branch that already has the UI definitions as far as being able to display anything, then I can pimp it 😁

[jancborchardt]

Sounds good! :) I would actually say to add it in the style of the second row where size and date is shown. As that info is not important in the search results we can cut it, and rather put several lines of that in there, each line a result inside the file, which on tap could open the file and scroll-navigate to the position of the result and highlight it. (Or am I asking for too much here?)

[AndyScherzinger]

@jancborchardt yes, that is what I had in mind, minus the scroll to the position part since I am not sure if that can be implemented that easily while it should be possible technically but probably needs more effort and might have to be postponed.

[tobiasKaminsky]

Regarding the scroll part: this might work with txt files as we display them inline, but imagine a word document or a pdf file. As we show both types of files only with external apps we cannot scroll to anything ;-)

[tobiasKaminsky]

Do we want to have line breaks in search results?

• pro: it is exactly what the real text looks like
• con: it blows up the view

With linebreaks:

Without linebreaks:

searching for "nextcloud" gives also results/highlight for "Nextcloud", neat :-)

Many thanks to @AndyScherzinger who did the layout 🎉

[jancborchardt]

Ideally it should be one row per result in the file, with somewhitespace between the rows.

Every hit should for context have some text before (max until a line break) and some behind it (also max until a line break).

(If needed I can mock it up later, but am mobile atm at dentist. ;)

[comradekingu]

How about only the lines that have any content? So the whole text, rendered as is, sans empty lines.

Or the whole sentence the word was in, possibly the prior and following one too.

Possibly with some indication of where the occurrence is.

Bonus, clickable link for copying where the occurrence is. In either a link or plaintext.

[AndyScherzinger]

Ideally it should be one row per result in the file, with somewhitespace between the rows.

That is still the idea, yes. Haven't had the time to check for a possible implementation (technical pov) but still plan to do :)

[daita]

Nice work !

What about displaying no excepts, or just a first line, and show more on long tap on the result

[daita]

@tobiasKaminsky some changes in the JSON of the result:

this is the _old_ format:

  "more": {
    "webdav": "00006918ocrdh3dnsj8m",
    "path": "/folder _ test . das/local2g test.txt",
    "timestamp": 1526033859,
    "mimetype": "text/plain",
    "modified_timestamp": 1526033859,
    "etag": "da93277a52668ccecc7e2c037b3f9810",
    "permissions": 27,
    "size": 15,
    "favorite": false
  },

This is the NEW format:

 "info": {
    "type": "file",
    "file": "phrase.txt",
    "path": "\\/tet",
    "mime": "text\\/plain",
    "size": 55,
    "mtime": 1528377613,
    "etag": "d0dd964176fcef46a2dad3205d74ae7f",
    "permissions": 27,
    "webdav": "00007078ocrdh3dnsj8m",
    "favorite": false
  },

This modification is only about the meta data

[mario]

@daita was the change in format exposed in any way by say capabilities or something?

[daita]

no, the format change only apply to result sent on search request.

[mario]

@daita Sure, but that's a breaking change xD Anyway, nothing some checks can't solve, but an elegant way would be to expose it in an API version or in our case capabilities or something else.

[daita]

it's not a breaking change if the feature is not available yet. Or am I missing something ?

Is the fulltextsearch already available into the Android Client ?

[AndyScherzinger]

Is the fulltextsearch already available into the Android Client ?

Nope, it is a pending work in progress #1928

[dd-fxaver]

@AndyScherzinger Any news regarding Full Text Search in Android Client? It would be really helpful to have the same search as we have online...

[AndyScherzinger]

No news yet unfortunately. The work has been started a while ago but not been picked up again. Everybody is welcome to pick up the open PR and we are all happy to assist of course.