A first round of changes to how search works on WaniKani. Just want to alert you all before the change goes out.
Slight redesign on how search works on WaniKani
Below is a demonstration on how search currently works on WaniKani
This effectively makes every page on the app a search results page.
The input is tied to the parameter query. When present in the URL, nothing happens with the search as demonstrated below.
Every page having the role of a search results page becomes a problem where a browser or search engine ties into a websiteâs search functionality to return results, such as OpenSearch. An addition, it isnât possible to share a link to a search result.
A solution to this is to have one page be the role for search results. The route /search has been implemented using the parameter query as the search term. The navigationâs search bar now does a GET request with the term and loads the search page. The results page is now shareable.
The search page itself is almost a copy of the original search results view. Some minor improvements for readability have been made with the search bar, such as:
Larger text size
Full width input
Contrast improvements
Implementation of OpenSearch support
OpenSearch has been implemented to allow browsers, such as Firefox, add WaniKani as a search engine option on the browser.
Below is a demonstration of WaniKani being available as an OpenSearch option, using WaniKani open search, and adding a keyword shortcut for search. Unfortunately, there is no way to define the keyword shortcut in the XML configuration since its a user specific setting (from my understandingâŚ).
Nice! I know a few users who will love using the shareable search links, as well as the OpenSearch compatibility.
Tangentially related question/comment:
On the search results, as well as on the Vocab lists on level pages, etc., items with a longer Meaning have their meaning abbreviated (e.g. The meaning for ä¸ăă is abbreviated as âPlease GivâŚâ). The abbreviation makes sense to support small screens, but it is also present for full desktop screens, most likely for simplicity.
CSS has a built-in feature:
text-overflow: ellipsis;
which will let the browser decide when ââŚâ is needed.
From what I can tell [here], this CSS feature has excellent browser compatibility, though you may be already aware of it and know of some issues.
Anyway, is that something worth considering for the âto-doâ list?
Out of curiosity, whatâs the advantage of a submit button versus just hitting âenterâ? Just preference/habit? Or a particular use case, like accessibility?
Mainly for accessibility, at least on why I would add it in.
I tried playing around with the ellipsis text overflow. I think itâll take a little HTML restructuring to get it to work. I believe with the way with how the elements and styling are set up at the moment a drop-in with the text overflow isnât going to work.
I tried putting it on some of the elements, but I think the float set on the ul element that encompasses the meaning and reading is making this more difficult than it needs to be. Since it is floated, it it is not respecting the full width of container. The ul could be made full width, but then there is the issue of the differing length for the subject characters on the left side. Basically the issue is the use of float. There needs to be a constraining container that starts on the right side of the subject characters and ends on the right side of the parent container.
I think the best way to address this would be a rewrite, either taking a flexbox or grid structure approach and then using the ellipsis. It is more work that I am willing to put in at the moment.
Having said all of that, I dropped the truncating of text for search results. I donât think itâll be a problem for majority of subjects. And if it is weâll address it.
First, the standalone route for search is great. That allowed me to make an iOS Shortcut that searches WaniKani. The shortcut will search on whatever text is in the clipboard. Or if nothing is in the clipboard it will show a prompt. I find this really useful when the shortcut is added to the Share Sheet. Then you can select text, choose Share, and click on Search WaniKani to open a new browser tab.
Second, my number one request in a future update to search on WaniKani: a keyboard shortcut to open the search bar and focus the input field. That would allow for a quick keyboard driven search from any WaniKani page!
Le bump to say, are we expecting a second round of changes? Or has there already been one and I missed or currently canât find the thread?
Only, I was wondering whether we could have the ability to search for exactly a given string. For example, if I want to see all the kanji with the reading ă, I want it to give me only the kanji with the reading ă and not the thousand-odd vocabulary items which have a ă somewhere in them.
Edit: Just noticed Vietâs the only mod-type who posted in this thread, and is thus likely the only one getting notifications. Sooo⌠@Mods
