h
h copied to clipboard
hypothesis
Unlozengified text gets lozengified on deleting an existing lozenge
This one seems difficult to fix. Deleting the "foo" lozenge submits the search form and does a full page reload for the URL /search?q=bar. When the new page loads, there's no way for the code that takes the contents of the ?q=... and turns it into lozenges to know the difference between something that was a lozenge on the previous load of the page, something that was un-lozengified text, or even something that the user has manually typed into the URL's query param (for example you can just open http://localhost:5000/search?q=bar and "bar" will be lozengified, as you would want to).
If we didn't submit the form on clicking an x, but just deleted the lozenge, then we wouldn't have this problem (but to delete a lozenge and update the search you'd have to click on an x and then hit Enter).
The Trello card has this to say about this issue:
Lozenges contain a × button (see mockup) which, when clicked, takes the user to the page with all the query terms except that represented by the lozenge which was clicked. Any unfinished text in the search box is ignored.
But I'm not sure what "Any unfinished text in the search box is ignored" means. Does it mean that, in the GIF above, when you click x to delete "foo" then "bar" should just disappear (no longer either in the search box or as a lozenge)?
I would say, clearing the text in the short term is the better experience than lozengifying it. That said, ajax support for delete/load is the real fix here.
This problem also occurs when you click on any other form submit button (to delete a static lozenge, clicking on a username or tag in the sidebar to add it to the search query, the more info/back buttons, the group leave button...)
I don't think it'd be very good to just ignore (and lose) any unlozengified text in the search input when any of these buttons is clicked. (And when JavaScript isn't available then all text in the search input is unlozengified.)
One fix might be to mark, in the q value that is submitted to the server, what has been lozengified and what hasn't: lozenge(tag:foo) lozenge(group:bar) lozenge(gar) har (har at the end is not lozengified). When JavaScript updates the value of the hidden input, it should wrap things in lozenge(...) as necessary. lozenge(...) wouldn't be considered part of the actual search query, would be stripped before sending to the search engine, but would be used by the app only in order to know what ought to be lozengified on page reload and what not.
Alternatively if we didn't lozengify every single word this problem (while technically still present) would be far more minor. If we turned only completed group:, tag: url: and user: facets into lozenges and left non-facet search words as normal text in the <input>. This would arguably be a better user experience in other ways as well (for example easier to go back and edit your search query; not confusingly dividing consecutive search words that the user considers related into separate lozenges).