In a recent discussion it was mentioned that the search function in Lemmy is awkward to use and could be improved. As a result I already made two small changes:
- Change community selector to use
[!community@example.com](/c/community@example.com)format (#3218) - Search field in community sidebar (#3217)
Are there any other UI or UX changes you can think of to improve searching in Lemmy? Im mainly looking for frontend changes, such as reorganizing the input positions, changing default values etc.
I'm not a UI or UX expert, but I wonder if it would make the search page nicer if instead of the search target (form select) would be tabs instead of a dropdown since it is distinct selection from the other filters in the search?
using bootstrap tabs (I didn't put any effort into styling just added bootstrap tabs and removed the form select butto dropdown):
Edit: now that I think about it, the tab might be kinda confusing unless also the other dropdowns are slightly altered to give more context in the current form selection tab, e.g. (text changes):
But yeah I just wanted to throw out ideas, I'm not sure about them myself. The search inside a community is nice addition!
One thing that would be helpful about not using drop-down boxes for static options: Fewer clicks required to set up a search. Each of the drop-down boxes in use now requires the user to:
The first drop-down box (search type) contains only five options, which could be replaced by buttons like the existing Subscribed/Local/All buttons. It would make discovering the available options easier because they would no longer be hidden behind a drop-down, and it would reduce the number of actions required of the user.
The second drop-down box (sort type / time frame) might be a good candidate for this change, too.
As for whether tabs would be a better choice than the button-style approach currently used by Subscribed/Local/All: I'm not sure right now, as I haven't had much time to consider it. But I think things would get messy and possibly confusing if more than one of these input elements were converted to tabs, because it would mean nesting tabs within tabs. On the other hand, using a row of buttons for each category would allow them to coexist neatly, fit the existing visual style, and avoid adding the complexity of another widget type for users to navigate.
I had a look and determined I need bit more time for this all than just today (long work day and a lot of additional info + need to get into lemmy-ui codebase a bit).
You've got some good points there, thank you! I'm not a UI or UX expert but it's a bit of a challenge reducing the amount of clicks and still keeping it mobile friendly without creating a screen full of options with several scrolls needed to reach the actual search, but I agree the goal should be less-actions.
I think once I have a bit of a grasp on the project I'll try and submit my suggestion.