Test: User experience when searching for something in the wiki

Test: User experience when searching for something in the wiki
Example: User wants to know something about 'webserver', possibly how to install one or something else.

  • go to https://openwrt.org/
  • search for 'webserver', 'web server' and 'http server' (without the single quotes)
  • report back if your expectations on the search were met by the results and how long it took you to find what you might have been searching for.

Other examples are welcome!

Works well.

Using web server and http server returned results for both web and server and http and server (as expected).

Using double quotes returned exact matches (as expected).

gretap is a pretty rare term, so it works well -- though returns Korean pages as well. At least when looking into 802.11s a year or so ago, only a page in Korean had content (which I found useful).

802.11s is more "typical" of what I find, having many results of low relevance (especially as it splits into two tokens). The page hit is good; that the content linked is outdated is not a search issue.

"802.11s" has better relevance in the content hits, but doesn't return https://openwrt.org/docs/user-guide/wifi/mesh.80211s as a page hit, per se, though it is in the results. Today was the first time I've noticed the "page hits" section at all.

Given the nature of the content on the site, the search results seem "reasonable" to me, in general.

Edit: The results for _orig_ifname are pretty useless, with or without quotes. Not sure if its a lack of content or a search issue. Given that LuCI writes that into config files, I would hope its documented somewhere.

Edit: Add to the list of "challenging, but shouldn't be" searches:

  • bridge config
  • bridge UCI
  • switch config
  • switch UCI

Edit: No love searching for:

  • config LED
  • config LED default
  • config system
  • config system LED

Another test: Improving search experience via clever pagenames

  • go to https://openwrt.org/
  • search for 'multi hop ssh'. Do not copy&paste this into the search field, but type it manually and see what pops up after you type 'multi', and after that 'hop', ...
  • Which page link are you offered in the popup?
  • Which other similar pages are you offered if you press enter after 'multi hop ssh'?

@bobafetthotmail Sometimes improvement can be very simple :slight_smile:

1 Like

multi hop

Search

multi hop ssh offers the same matching pagenames.

If you press enter, you come to the search results:
grafik

multi_hop_ssh leads to a direct hit on the pagename
multi-hop-ssh does not lead to a direct hit

-> multi-hop-ssh is no good choice as a pagename

Heh, searching for the exact keyword found in the page name. Also in the same order. And if there are "-" it breaks. Really I'm not into changing stuff if the search engine is so dumb.

Try to search for "ssh multi hop", and the popup does not show up, while the search after I press enter still works fine.

OK, I didn't test this extensively, just made the observation that "-" as a word separator is a bad choice.

@bobafetthotmail I installed the iframe plugin. Take a look at your test page:
https://openwrt.org/playground/search_engine_test

Thanks for that, I didn't ask for that yet because I got stuck before iframe support in the wiki was an issue.

It seems duckduckgo can't distinguish from openwrt.org and wiki.openwrt.org, probably because there is some redirection going on end it gets confused.

I specify to search within openwrt.org allright, I try to have it exclude results from wiki.openwrt.org, but I can't get it to do a proper search, it will find things from both the new wiki and the old wiki (with a preference on the old wiki), which isn't acceptable.

If someone has any idea, please chime in.

Will try with Google Custom search next.

I remember you mentioned that earlier, but forgot about the details.
Anything special required to make that work?

It seems to require me to do the following to integrate the search button (yeah had to use a code formatting here because the forum would freak out due to div and body tags):

Get code
Copy the following code, and paste it into a <div> element in your site's <body> section, where you want both of the search box and the search results to render._
Note: For the most cross-browser compatibility, it is recommended that your HTML pages use a supported doctype such as <!DOCTYPE html>. CSS hover effects require a supported doctype.

and this is the code

<script>
  (function() {
    var cx = '013405046179207320088:a7nosrvs8cy';
    var gcse = document.createElement('script');
    gcse.type = 'text/javascript';
    gcse.async = true;
    gcse.src = 'https://cse.google.com/cse.js?cx=' + cx;
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(gcse, s);
  })();
</script>
<gcse:search></gcse:search>

It does seem to pull a javascript with a specific ID and execute it, I don't know how this can be integrated in the wiki, but I didn't look into that yet.

On the positive side, it does seem to work properly and search only within the actual wiki.

This is the link to its own page (which I'm using currently to configure and test it) https://cse.google.com/cse/publicurl?cx=013405046179207320088:a7nosrvs8cy

Is there an option to select a "two-page layout" in the Google CSE Control Panel?

Reason for asking: https://lotar.altervista.org/wiki/tips/google-cse

I'm experimenting with this in my demowiki.

FYI: With a Dokuwiki update from today we got new functionality on the search page - an added "Toggle Search Tools" button.

grafik

You can now refine your search very easily, e.g. restrict to a certain namespace with a click.

grafik