Ability to explore Lemmyverse

[micahmo]

Pull Request Description

This PR adds more exploration by extending the existing the instance search "View all" button to be used for any type of search. This essentially performs an empty search, which returns "everything". There is also a new chip which allows exiting this mode.

Issue Being Fixed

Issue Number: #1053

Screenshots / Recordings

qemu-system-x86_64_qBqLHgINfp.mp4

Checklist

• Did you update CHANGELOG.md?
• Did you use localized strings where applicable?
• Did you add semanticLabels where applicable for accessibility?

[hjiangsu]

I think I understand what the goal of this PR is, but I'm wondering if there's a better way to handle this UX wise - it's a bit hard for me personally to understand what "View all" means in this context.

One idea I have:

• If we switch to other search types (users/posts/comments/instances), there is initially no information present because there is nothing in the search query. Instead of displaying nothing, could we default to displaying the "view all" results?
• This idea won't work on the community search type since we have favourites and trending communities, so we could have a button similar to what you have but be a bit more descriptive (show all communities)
• In a way, this resembles the "Explore instance" behaviour on how you tap on "communities", or "posts", and it displays a default list of unfiltered results (which then the user can adjust using additional filters or search queries)

Maybe @machinaeZER0 also has some ideas or input on this? (sorry I'm cc-ing you so much, do let me know if you'd prefer to not receive these pings 😅)

[micahmo]

We certainly can show all entities by default (we could even do that on communities section, just beneath favorites and trending). I just wasn't sure if we wanted that overhead. Every time you switch types, you'll make an API request. If you intended to actually search (which I think is most likely when using the search page), it might get annoying seeing all those lists. I thought showing all should be an intentional choice. And I think the instance explorer is different because it's not a search.

If the wording is confusing, it could say Show all <type>.

Just my thoughts! I'm curious to hear from @machinaeZER0 as well. 😊

[machinaeZER0]

Y'all make me feel like a celebrity, hahah 😂 always happy to chat! We should get a weekly meeting on the cal 😉

I like the idea of this feature, but I do think something feels a little "off" about it as currently presented. In many ways this has the same information as the "explore instance" tab, but without the "about" page and with actual filtering capabilities, and because of that it feels a bit duplicative to me? Sort of the middle of a venn diagram between search and explore as they are currently set up.

Some options to address this:

• theoretically, this new view could become the "explore instance" experience - I'm into this idea mostly because I like the filtering options it adds. This would raise the questions of what to do with the "about" tab (is there another way to get to this page, currently? could move it into the three-dot menu above the modlog, or as an icon next to the "open in browser"), and whether it's so similar to the normal search experience that it effectively serves the same purpose. In many ways I personally think the current "explore" setup is clunkier without built-in search/filtering, so this would be a step to address that
• per Hamlet's suggestion, showing this information for each category by default within search accomplishes the same/a similar effect, albeit with more api calls (which might be bad for either app performance or the instance's servers - maybe both?). Per Micah's note, this could be a toggleable option like our additional thumbnail scraping to avoid any performance hits - I think I'd err on having everything displayed, though even in the currently implemented instance browser, being able to view all comments seems less useful to me
• if the feature was kept as-is, I do like the idea of expanding "view all" to append the category name in question (view all communities, for example)

Honestly I like the idea of most of these options, but you two might have a better sense of which is most practical/feels right to push forward. I really like the PR, so for me it comes down to whether anything duplicative or overlapping should be cut or merged in to this more flexible system :)

[micahmo]

In many ways this has the same information as the "explore instance" tab, but without the "about" page and with actual filtering capabilities, and because of that it feels a bit duplicative to me? Sort of the middle of a venn diagram between search and explore as they are currently set up.

Keep in mind two key differences between the search page and the instance explorer.

• The instance explorer only shows entities hosted locally on that instance.
• The instance explorer can be pulled up for any instance, not just yours.

I sort of wanted to keep the instance explorer distinct to feel like you're actually visiting another instance's web page.

On the other hand, the search page shows everything across the fediverse (that's federated with your instance, at least), which is why I thought it made sense to use it for #1053. It has almost everything it already needs, except for the ability to run an "empty" search.

[machinaeZER0]

Ah, gotcha - I had a feeling there was a nuance there that I wasn't picking up on 😅 I don't know if my ignorance speaks at all to the broader user experience, but maybe food for thought (and if so, more a reflection on coming to terms with the fediverse at large, moreso than with thunder itself.

Would it make sense to take the more verbose "view all" text that Hamlet proposed as a baseline step?

[hjiangsu]

Thanks for the thoughtful comments @machinaeZER0!

I feel like my ideal scenario would look like this (and by any means, it doesn't mean that we necessarily have to stick with this vision or even implement this right now)

• The "Search" tab can be changed to an "Explore" tab
• When we navigate to the Explore tab, it shows both the current instance information, as well as all communities/post/comments/users that are currently federated with the given instance (this is equivalent to the "empty" search)
  • This new explore page would look quite similar to a merged version of the current Search page, and the instance explorer.
  • In the explore page, we can switch between different instances to "explore" what it looks like on those instances
  • We should also keep all the current functionality of the explore - seeing modlogs, etc.
• The search feature would still be there, but I would maybe make it more of a secondary action
  • My idea behind this is that I often find being able to explore new communities more useful than searching for a particular community/user. The search page is nice, but it requires me to know what to search for in the first place, which is where the explorer comes in!
  • When the search is tapped, it'll return a result of all search results (communities, users, posts, comments) - this is somewhat similar to how lemmy search works, but we possibly organize it a bit better UI-wise. Or, we could reuse the current search as well (it'll depend on what we think is more useful)

I tried to do a few mockups of the potential vision I had, but forgive me if it doesn't look too well 😅

Mockup A - where we have the search and explore as "primary" actions. My worry with this is how we would handle filtering the search results

Mockup B - where the search is more of a secondary action. This allows more vertical space to be used to see explored content

If we do this correctly, then we could theoretically make the explore page "standalone", where it can work with any instance that we pass into it. Of course, at the end of this, I'd like to have all your inputs on what you think! While this is my overall vision, I'm always up to discuss your ideas on how we can make this feature more cohesive 😄

[machinaeZER0]

I was legit originally going to suggest changing Search to Explore, but I didn't know if that was too radical an idea 🤣 I think that makes a lot of sense, and I like the reasoning behind both mockups/approaches. Always a fan of saving vertical real estate, so I do find that appealing in the second example, but the first one minimizes additional clicks which may make it the better option. What do you think, Micah?

[CTalvio]

I'm behind turning the second tab into primarily an "explore" tab with access to search. Search was obviously the priority to get implemented first, but now that we have that, having it be a subset of an explore page makes sense to me.

Discoverability is one the weaknesses of the fediverse, and whatever features we can build around solving that problem should be front and center.

I've also brought this up before, but I feel like chucking favorites in with the explore/search page is a categorical mismatch. They fit in better with the subscription list but as the drawer is harder to reach I find myself accessing favorites using the search page.

What if favorites were accessible via an account switcher style popup that could be brought up by long pressing the feed icon (does anyone use the return to top on it now that the FAB exists?), from the FAB, or by pulling up on the bottom bar?

[micahmo]

For devs: keep in mind that it'll be a pretty big effort to merge search and explore (which is why I haven't tackled it yet 😆). Despite the similar appearance, the logic is pretty different. One thing in particular is that the explore page has a lot of object resolution included so that you can open entities returned from other instances on your instance. If we merge, we'll have to decide which bloc/cubit wins, and then bring over a lot of logic from the other.

But in terms of the UI/UX proposed, I'm all on board. 😊

[hjiangsu]

it'll be a pretty big effort to merge search and explore

Definitely! This idea of switching Search with Explore will take some time, especially because we'll need to consolidate a lot of logic together to make it work seamlessly.

I'm thinking maybe we can take this in steps:

• Create a whole new directory explore, and start building out blocs and UI from scratch while taking ideas from our existing implementation
• Create a way to switch between Search and Explore. We can hide this under an experimental flag that is toggle-able in the settings page to allow users to switch back and forth and give any feedback
• Slowly migrate more and more features to bring the explore page to parity with what we have currently
• Completely switch over to using the new Explore page as the default

I can also help with parts of this as well, so don't be afraid to ask me to help with building certain portions!

Explore is somewhat similar to how the feed works, so we can take a lot of inspiration from there 😆

[micahmo]

Hey, just checking in here! I think we're all agreed that a more unified "explore" page would suit all of our needs in Thunder! However, since that will be a pretty big change that (I'm assuming) none of us have been able to commit to yet, what do you think about merging this PR as is? It provides a function that is not currently available via any other mechanism in Thunder, so it would satisfy a need in the short term. Any thoughts on that?

If the "View" word is confusing, it can be updated to "View all communities", for example.

[machinaeZER0]

That seems reasonable to me!

[hjiangsu]

I'm also okay with that!