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.comformat (#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.
The tabs could make sense, but then they should be between the search bar and results, because each tab has the same buttons. You can make a pull request with what you have so far and then we can discuss it in detail.
Ah good point!
I’ll hopefully manage to set up lemmy-ui locally at home after work and make that pull request - I edited that in with webdev tools since didn’t want to lose that thought before I get home (sorry if this just pollutes the discussion).
No worries. Make sure to follow the documentation on join-lemmy.org for development, and use the
release/v0.19branch for both lemmy and lemmy-ui as the main branch is currently broken due to 1.0 changes.Will do, thank you!
I think if you do this, then the tabs for communities, users, and URL would no longer have the drop down to choose community because it’s meaningless for them. They probably wouldn’t have the “Top All Time” filter either. There could probably be more differences for each tab, maybe this is the way to go.
Yeah there’s a lot to consider here, good points. The language specific texts too to make it more search selection context based. This would need to be thought through to not make it more confusing.