Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardize search/find to search #7398

Merged
merged 24 commits into from
Apr 2, 2021
Merged

Standardize search/find to search #7398

merged 24 commits into from
Apr 2, 2021

Conversation

hius07
Copy link
Member

@hius07 hius07 commented Mar 8, 2021

There is File search in the Gesture manager already.
There is Fulltext search in the readermenu.

Some help text added.


This change is Reviewable

There is 'File search' in the Gesture manager already.
There is 'Fulltext search' in the readermenu.
Some help text added.
Co-authored-by: NiLuJe <ninuje@gmail.com>
@Frenzie
Copy link
Member

Frenzie commented Mar 8, 2021

NB

Screenshot_2021-03-08-09-05-47-21_1aff61e6bd981aaa4ba9d0245eb6c04f

@hius07
Copy link
Member Author

hius07 commented Mar 8, 2021

NB

Calibre search would be clear and unified.

text = _("Find a book via calibre metadata"),

@Frenzie
Copy link
Member

Frenzie commented Mar 8, 2021

I would keep Find a file and change it to Find in text.

@hius07
Copy link
Member Author

hius07 commented Mar 8, 2021

Not a simple question)
https://www.dictionary.com/browse/find
https://www.dictionary.com/browse/search
https://www.differencebetween.com/difference-between-search-and-vs-find-and-vs-seek/
Chrome ctrl+f description: 'Open the Find Bar to search the current page"

Based on the definition, Find seems to be a little bit more accurate.
In the meantime, there are many Search results window headers. Can it be unified somehow?

@Frenzie
Copy link
Member

Frenzie commented Mar 8, 2021

The equivalent with search would be something like this:

  • Search for a file
  • Search in text

In the meantime, there are many Search results window headers. Can it be unified somehow?

Most things in the menu are very much on purpose. Plenty of headers are legacy.

@hius07
Copy link
Member Author

hius07 commented Mar 8, 2021

Kindle uses Search everywhere: in text, book names on device, Kindle Store.

These are the similar activities (from a user's point of view):
Text search
File search
Calibre search
Wikipedia search
Dictionary search
And all of them give Search results.

1

Find, search, lookup, look up - the Occam's razor is needed.

@poire-z
Copy link
Contributor

poire-z commented Mar 8, 2021

(No real opinion about these - I think I'd like this uniformity, but I don't know if we should really go toward radical uniformity - and impoverish vocabulary and have users learn/get used to poor english expressions :) From French, I would naturally use "search a word in a dict" - but it seems to me that "look up a word in a dict" feels like better english - and I might now use that after seeing it that often in KOReader :)

@Frenzie
Copy link
Member

Frenzie commented Mar 8, 2021

Text search
File search
Calibre search
Wikipedia search
Dictionary search

Find/search is fairly immaterial. In my mind Find is the canonical KOReader one. But generally it should be an action.

Find/search in text
Find/search for (a) file
Find/search in calibre catalog
Find/search in Wikipedia
Find/search in dictionary

Incidentally, the Apple dictionary app uses all three.

  • Type a word to look up in…
  • Search
  • Find → Search For a New Word…

@hius07
Copy link
Member Author

hius07 commented Mar 14, 2021

We can see the following entries:

1 Text
1.1 Fulltext search main menu
1.2 Enter text to search for dialog header
1.3 Search button in the context (highlight) menu
1.4 Fulltext search dispatcher

2 File
2.1 Find a file main menu
2.2 Search for books by filename dialog header
2.3 Search Results window header
2.4 File search dispatcher

3 OPDS catalog
3.1 Search everywhere

4 Dictionary
4.1 Dictionary lookup main menu
4.2 Enable fuzzy search dictionary settings
4.3 Enter a word to look up main dailog header
4.4 Search dictionary main dialog button
4.5 Search dictionary article button
4.6 Input lookup word additional dialog header
4.7 Lookup additional dialog button
4.8 Dictionary lookup dispatcher

5 Wikipedia
5.1 Wikipedia lookup main menu
5.2 Show image in search results Wikipedia settings
5.3 Enter words to look up on Wikipedia main dailog header
5.4 Search Wikipedia main dialog button
5.5 Searching Wikipedia infomessage
5.6 Input lookup word additional dialog header
5.7 Lookup additional dialog button
5.8 Wikipedia lookup dispatcher

6 Calibre
6.1 Find a book via calibre metadata main menu
6.2 Search settings tools Calibre menu, 5 more search entries within
6.3 Search in calibre metadata dispatcher

To summarize:

  1. Find is used in the main menu for Files and Calibre search only (2 entries).
  2. Lookup/look up is used in the main menu and one dialog for Dictionary and Wikipedia.
  3. Search is used for all settings and results in Dictionary and Wikipedia search.
  4. Search is prevailing mostly everywhere (so far).

Hope this helps you, the code owners, to make the final decision on terminology unification.

@hius07
Copy link
Member Author

hius07 commented Mar 31, 2021

I would be happy to provide further unification based on two decisions:

  • "Search" or "Find"?
  • keep "lookup" for Wiki and Dictionary?

@poire-z
Copy link
Contributor

poire-z commented Mar 31, 2021

I don't use the 2 "Find..." so I won't notice the change - I'm fine with the current "Search" ones.
I'm also fine with the "lookup" where it's used (the switch to "search" feels not necessary to me - may be just because I'm used to them :)

@hius07
Copy link
Member Author

hius07 commented Mar 31, 2021

File search
Fulltext search (or just a Text search?)
Calibre search
Dictionary lookup
Wikipedia lookup

Very nice imho.

@hius07 hius07 marked this pull request as draft April 1, 2021 03:01
@hius07 hius07 changed the title Change 'Find a file' to 'File search' for consistency Standardize search/find to search Apr 1, 2021
@hius07
Copy link
Member Author

hius07 commented Apr 1, 2021

Search - a noun and a verb, lookup - a noun, Look up - a verb.
Enter smth to search for in all InputDialog titles, except Dict/Wiki: to look up
No results everywhere when nothing found.

Sorry, don't understand a conflict with opdsbrowser.lua.

@hius07 hius07 marked this pull request as ready for review April 1, 2021 16:37
@Frenzie Frenzie added this to the 2021.04 milestone Apr 1, 2021
@Frenzie Frenzie added the i18n label Apr 1, 2021
@@ -1199,7 +1199,7 @@ function DictQuickLookup:lookupInputWord(hint)
end,
},
{
text = _("Lookup"),
text = _("Look up"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto

@@ -706,13 +706,11 @@ end

function OPDSBrowser:browseSearchable(browse_url, username, password)
self.search_server_dialog = InputDialog:new{
title = _("Search OPDS catalog"),
title = _("Enter author or title to search for"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit reductive, you can arguably match on tags in a Calibre catalog.

(i.e. , I prefer the previous title + hint combo, possibly with minor tweaks).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer the previous title + hint combo

Do you mean input_hint?
There is just a hint in the code

hint = _("Search string"),

but I cannot find it in the InputDialog so I've removed it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly there was a typo in the field name, yeah, but I know the feature exists ;p.

@hius07
Copy link
Member Author

hius07 commented Apr 2, 2021

What do you think about unified lookup input dialog?
1

It's just a prototype, not a working code.

@Frenzie
Copy link
Member

Frenzie commented Apr 2, 2021

What do you think about unified lookup input dialog?

I generally prefer simpler dialogs where possible, with a simple and obvious left = cancel, right = the action, without any middle.

That way the menu may be more complex but the dialog is simpler. It's a trade-off.

@hius07
Copy link
Member Author

hius07 commented Apr 2, 2021

Thank you.
The reason is that this input dialog is the same in all 3 modules: Dict, Wiki and search results DictQuickLookup.
BTW, what ok_button is recommended in DictQuickLookup (where ok_button action depends on the previous search)?

Now we have a very-long-press easter egg for switching between Dict and Wiki

-- but allow switching domain with a long hold

so the idea of domain switching is in the air.
Three buttons allow simple switching and show unified accustomed dialogs.

If not agreed, as a compromise it might be
Search Dictionary in Dict lookup, Search Wikipedia in Wiki lookup, and three buttons in DictQuickLookup.

@Frenzie
Copy link
Member

Frenzie commented Apr 2, 2021

The reason is that this input dialog is the same in all 3 modules: Dict, Wiki and search results DictQuickLookup.

I suspect it's not (except visually), but that's an interesting point.

@hius07
Copy link
Member Author

hius07 commented Apr 2, 2021

except visually

Yeah, it's hard for a developer to stand at the average user's point of view. He knows what's under the hood.

@hius07
Copy link
Member Author

hius07 commented Apr 2, 2021

what ok_button is recommended in DictQuickLookup (where ok_button action depends on the previous search)?

Answer myself: we can have the same Dict/Wiki search button, depending on domain.

@hius07
Copy link
Member Author

hius07 commented Apr 2, 2021

Since this PR is about wordings only, let's postpone redesign of the search input.
If anybody likes three buttons (for the purpose of simple domain switching), please let me know, I'll make the propositions.

@poire-z
Copy link
Contributor

poire-z commented Apr 2, 2021

If anybody likes three buttons (for the purpose of simple domain switching), please let me know, I'll make the propositions.

When would we see it? Only when hitting the little pencil icon at top right of any lookup result (that I can figure from you screenshot), or elsewhere too?

@hius07
Copy link
Member Author

hius07 commented Apr 2, 2021

When would we see it?

As we have one combined search results window (DictQuickLookup), we can have one combined input invoked from the main menu. Calling it from the DictQuickLookup allows switching domains for a new search.

@hius07
Copy link
Member Author

hius07 commented Apr 2, 2021

I'm done with wordings, all reprimands fixed. Thank you very much.

@poire-z
Copy link
Contributor

poire-z commented Apr 2, 2021

So, the little pencil icon + the menu. Is that all ?

When you say "main menu", I assume you mean the 2 entries Dictionary lookup and Wikipedia lookup , right ?

If these 2 would become a single menu item Lookup, it would be a little less clear in this menu, as we currently have 3 items related to dictionary, a separator, 3 same items related to Wikipedia.

Or do you see us keeping that existing menu, and both "lookup" items launching that same dialog with both buttons ? (If yes, do you see these buttons inverted, so the one related to the menu item hit is the right most one?)

@hius07
Copy link
Member Author

hius07 commented Apr 2, 2021

So, the little pencil icon + the menu. Is that all ?

Yes, I thought about these 3 modules and to have just one main menu entry for lookup.
Let me think more over it, I see that the advantages (besides of input dialog unification) are no so obvious.

@Frenzie Frenzie merged commit 052e19e into koreader:master Apr 2, 2021
@hius07
Copy link
Member Author

hius07 commented Apr 2, 2021

Great, thanks!

@hius07 hius07 deleted the patch-3 branch April 2, 2021 16:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants