You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So right now the search system is basically a text box where you enter URL parameters, that get added to the request call, like intitle:goons "stairs" username:"lol"
That's how search works on the site, and at least with the app you can click on options to paste in the keyword part, but you still have to edit by hand and there's potential to mess things up
Anyway, it would be better to keep those details in the background. Allow the user to add filter items, where the keyword is internal and they can only edit the actual data part. When it's time to run the query, each item can convert itself into a key-value parameter.
We can keep the text box for the search text, and something like a list or set of chips for the filters, a basic UI design that's easy to work with. We could also let the user save the current set, to create search "recipes" they use often (like "who's quoted me today"). This also ties into the navigation system - you can open the Search fragment with a set of search filters, which acts like a recipe and populates the UI as appropriate
The text was updated successfully, but these errors were encountered:
I have a branch where this is all done on the backend, it just needs a decent UI 3023155
right now there's a recyclerview with swipe-to-delete and edit functionality (except where the filter has no editable data, i.e. "My username"). This really needs to be hideable, so the search results can fill the screen (on the mobile layout anyway) and be brought back into view when you need to change something
One option is to have collapsible filter and result sections, maybe with an extended FAB to switch between the two
That way you'd configure the search, with the "Do the search" button at the bottom. Then the filter part could collapse, with the FAB moving up to the top of the screen and changing to "Edit search" or something, and the results filling the screen below. So the view is switching between two areas, above and below, by pressing the FAB
That way the query part and the results are on separate layers, you can drag up if you want to make changes to the filters, and it's easy to show one or the other (like when you click search, you want the query part to get out of the way). Instead of a big list of filter items, we could use chips instead
I'm in favor of all of this. Especially if you can either get bottom sheets working or find a library that supports custom views. The current botomsheetsbuilder one only displays lists or menus.
So right now the search system is basically a text box where you enter URL parameters, that get added to the request call, like
intitle:goons "stairs" username:"lol"
That's how search works on the site, and at least with the app you can click on options to paste in the keyword part, but you still have to edit by hand and there's potential to mess things up
Anyway, it would be better to keep those details in the background. Allow the user to add filter items, where the keyword is internal and they can only edit the actual data part. When it's time to run the query, each item can convert itself into a key-value parameter.
We can keep the text box for the search text, and something like a list or set of chips for the filters, a basic UI design that's easy to work with. We could also let the user save the current set, to create search "recipes" they use often (like "who's quoted me today"). This also ties into the navigation system - you can open the Search fragment with a set of search filters, which acts like a recipe and populates the UI as appropriate
The text was updated successfully, but these errors were encountered: