First round of changes to search

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…).


This is really cool! Will probably use this a lot. Highly appreciated!


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?


I am now imagining a pidgin that uses “please giv” in place of 下さい e.g. “here-at waiting please giv”.


Can you also add a mouse-clickable button for “ok, start the search”?


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?

Search button incoming.


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.


Mostly laziness, because when I’m sitting back just using the mouse, I don’t want to have to reach forward for the keyboard. :stuck_out_tongue:


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!


But, if you’re sitting back, just using the mouse, how did you type your search term? Or am I missing something, here?

Ah, I just thought of one way: copy and paste.

1 Like

Aye, that. :slightly_smiling_face:


Thank you! The statelessness of search was a big pain point for me. I’m so excited to be able to use my back button now!