Use "search" or "page" URL parameters, depending on the intent

[waldyrious]

21 and #34 implemented a way to control the interface of Primerpedia via a URL parameter, which is currently named "search".

Here's a use case where the current behavior may be confusing:

• When I enter a search term, the search box keeps the entered text, but the URL shows the title of the page; if I then click the random link twice, the URL changes each time to reflect this, and the search box is emptied. All this is fine and expected.
• But if I now click the back button on the browser, the search field gets filled with the value of the URL, which is redundant for pages loaded via the random function, and is incorrect for pages loaded via the search function (since the search terms typically do not match the title of the article exactly, even if only in capitalization).

I'm wondering if we shouldn't set the url parameter to search= and page=, respectively, in order to be able to make the interface behave as expected in both cases, i.e. only fill the search box automatically for pages loaded via search, and show the search terms rather than the actual article title.

Of course, if both parameters are present simultaneously, one must take precedence: we could either (1) fill the search terms back into the search input without triggering a search (and perform a search with the exact page title to load it), or (2) ignore the page title and execute a search with the provided terms, hoping that it results in the same page (which most of the time it probably will). For a URL like ...?search=united_states&page=canada, the first approach would show the Canada article, while the second approach would show the United States article.

[waldyrious]

The last paragraph above was adapted from this comment; it also continues to say:

Maybe a better implementation for the original issue would be to replace the history entry with the found page (thus changing the URL from ?search=something to ?page=some_thing. In which case I would favor search= before page= because the first one is dependable.

If I read that correctly, this matches option (1), but I'm hoping @Jan-Ka will clarify if there are nuances escaping me.

[Jan-Ka]

I should have added my thoughts here instead of back in the PR. Let's continue this discussion here :)

There is a slight difference I did not manage to make obvious.

If the url is ?search=united_states&page=canada, I would drop the page parameter and instead trigger a search for the contents of search, which would of course be put into the search input.

When the search succeeded, I would replace the current URL (and history entry) with ?page=united_states_of_america. The search input is still around because we do not clear it.

Coming back to or entering a url with a page parameter will not put anything in the search bar since In my understanding we do not search for the page but just open the result again.

Keeping the search information around does nothing for us (that I can think of at the moment). I can repeat them of course by calling the url with an appended search parameter.

(Copy of the linked comment at the time of this comment)

[waldyrious]

You know, you can simply delete the comment over there and edit this one as if you wrote it here in the first place :)

(If you do, you can delete this one as well, as it'd lose context.)

[waldyrious]

Keeping the search information around does nothing for us (that I can think of at the moment).

As a user I think showing both the search terms in the input field and the actual article found by performing the search would be less surprising.

In other words, I'd be able to go back and forth through history and all three pieces (URL, search box and displayed article) would remain identical, regardless of whether I got to that page by typing in the search field, opening an URL someoneone else gave me, or going back and forth in the browser history.

I think this helps ground the user as they navigate across multiple pages, and makes the application more predictable.

[Jan-Ka]

Sounds reasonable. Let's do it that way.