Append instance name to the community name when searching

[ExperiBass]

Introduction

Pokin around the app, noticed when i searched "main" that it returned three "mains" with no indication as to which was which.

Requirements

Append the instance name to the community name in the fields.

[buresdv]

This is a problem, since I want to avoid mentioning instances at all. The current plan is to pick the result with the most subscribers and only display that one, hiding the rest by default.

Maybe there would be an option to display the rest in a drop-down menu, but this would not be the default and would be opt-in.

[ExperiBass]

This is a problem, since I want to avoid mentioning instances at all. The current plan is to pick the result with the most subscribers and only display that one, hiding the rest by default.

mrrr, i dont think thats a good plan. especially in my case of lookin for the main group of my instance, its pretty small so itd get hidden. Would it not be better to display the instance in a subheading under the community name, or allow searching by instance? the latter seems to be partially there, i can search "beehaw" and c/support@beehaw.org will pop up, but search immediately breaks on a non-word character.

Maybe there would be an option to display the rest in a drop-down menu, but this would not be the default and would be opt-in.

*shrug* maybe fold all the communities under a name? so the dropdown label is "main" and the options would be "main@instance.a", "main@in.stanceb", etc

[buresdv]

The normal user doesn't understand what an "instance" is. I did research on Mastodon, Twitter, TikTok and in real life, and people just don't understand the concept, and it's keeping them from using Fediverse applications. I know this is a controversial decision and not optimal for the more tech-inclined, but Mlem is aiming for the general audiences, so we have to be going this way.

I'm welcome to other ways of choosing which community shows as the main one. The number of subscribers is just one possibility, as users would be more likely to encounter an active community that way.

[ExperiBass]

The normal user doesn't understand what an "instance" is. I did research on Mastodon, Twitter, TikTok and in real life, and people just don't understand the concept, and it's keeping them from using Fediverse applications. I know this is a controversial decision and not optimal for the more tech-inclined, but Mlem is aiming for the general audiences, so we have to be going this way.

while i see what you mean, it also just seems... odd? my understanding is instances are a core part of lemmy, and the fediverse as a whole. how do you "hide" instances while keeping the fediverse part? there could be two people with the same name, but on different instances, in the same thread. if they both dont have a icon set, how would you tell whos who? likewise, with communities, if someone on instance.a links to a community on instance.b, thered be no indication that the user is in a community on a different instance, other than the link.

I'm welcome to other ways of choosing which community shows as the main one. The number of subscribers is just one possibility, as users would be more likely to encounter an active community that way.

is activity a fetchable metric? a balance between community size and active members would probably be ideal.

[buresdv]

while i see what you mean, it also just seems... odd? my understanding is instances are a core part of lemmy, and the fediverse as a whole. how do you "hide" instances while keeping the fediverse part? there could be two people with the same name, but on different instances, in the same thread. if they both dont have a icon set, how would you tell whos who? likewise, with communities, if someone on instance.a links to a community on instance.b, thered be no indication that the user is in a community on a different instance, other than the link.

This is a very tough situation. Yes, federation is a core part of Lemmy, but it's also something that the average person doesn't grasp, and that's why it needs to be hidden away as much as possible. That's why, when showing communities, for example, only the community name is shown; because it's very likely that c/technology on lemmy.ml is very close in scope to c/technology on beehaw.org, there's no reason to show the instance name, since that's just more for users to get confused over. In Mlem, you can just post on other instances with no interruptions. You don't need to know that you're posting to a different instance, since there's not really anything you gain by knowing. The user just wants to find a cool post to engage with and comment on it. They don't care that it's on a different community, as long as they can engage with it.

And while two people with the identical name showing up on in the comments of the same post is possible and a valid concern, the probability of this is extremely rare. Mlem already fights impersonation somewhat by fetching admins and moderators from the instance itself and then coloring them differently, so people can, at least, not impersonate the admins/moderators. This is, however, a Lemmy-wide problem, and there have been no solutions to this so far, even if the instance address is shown.

is activity a fetchable metric? a balance between community size and active members would probably be ideal.

Yes, activity is one possible metric with which you can sort the search results. It's "content sorted by hot (posts sorted by a decaying rank), but bumped by new comments up to 2 days".

[ExperiBass]

This is a very tough situation. Yes, federation is a core part of Lemmy, but it's also something that the average person doesn't grasp, and that's why it needs to be hidden away as much as possible. That's why, when showing communities, for example, only the community name is shown; because it's very likely that c/technology on lemmy.ml is very close in scope to c/technology on beehaw.org, there's no reason to show the instance name, since that's just more for users to get confused over. In Mlem, you can just post on other instances with no interruptions. You don't need to know that you're posting to a different instance, since there's not really anything you gain by knowing. The user just wants to find a cool post to engage with and comment on it. They don't care that it's on a different community, as long as they can engage with it.

fair, ig its more of a user education issue.

Yes, activity is one possible metric with which you can sort the search results. It's "content sorted by hot (posts sorted by a decaying rank), but bumped by new comments up to 2 days".

yeah, then a balance between activity and size would probably be best for searching.

[buresdv]

I have an idea how a possible solution might be implemented. I will create a mockup and show you maybe around tomorrow, are you up for providing feedback?

[JJaks]

Just throwing my own hat to the ring. Maybe as a compromise add a customisation option to enable showing search results from all instances and if enabled there would be a small lighter tone text saying which instance the search result was found.

Or if we want to show all search results from all instances, then just sort the search results and put the most popular one first since the first result is usually the most clicked for the regular user. This solution would also mean that there should be a small text saying from which instance the result was found.

[ExperiBass]

I have an idea how a possible solution might be implemented. I will create a mockup and show you maybe around tomorrow, are you up for providing feedback?

sure :3

[ShadowJonathan]

I dont think that you can ultimately hide the nature that some communities will be on different servers, and so imo you have to add the server name.

I was continually confused when i was searching for instance-specific communities, because while !technology on one instance may refer to one community, a good one, a !technology on a larger instance can be toxic as hell, and almost hacker-news like, or something to that degree.

Please just standardize the !<community>@<domain> approach, and users will pick up on it.

---

To put it another way; try to suppress the fact that people are responding from different servers, and you'll basically cause incredibly confusing instances, where people will say that they dont believe that that person is coming from another instance, andsoforth.

It'll also cause dissonance with users who do know and do want to see this being the case, and would like to be informed when the person replying is from their own server, or from a troll server, that should be reported to get blocked, or something.

[buresdv]

I present an idea:

When more than one search result has a name identical to another search result, at first, only the search result with the most subscribers / most activity / whatever other metric we choose shows in the search result list. When tapping the result row, the user will be taken to that top result.

They can, however, expand that result to see a list of all the alternatives, along with the instance address

[ShadowJonathan]

nit: if the last one (or any single result) is on a different instance than the local one, it should show that @, imo

that way the app is preferring the local server, and if the local server doesn't federate, it could act like it doesn't know or care about any other server, but it should make it clear that it is reaching across the fediverse when it does so

[buresdv]

nit: if the last one (or any single result) is on a different instance than the local one, it should show that @, imo

I don't think this should be the case. For the end user, posting to a federated instance is no different than posting on their own. When I'm replying to people on Mastodon, for example, I don't case that they are on a different instance, because it doesn't change anything in the way I iteract with them.

Introducing this would add unnecessary complexity, and users would be wondering why some communities have that @ and some don't.

[ShadowJonathan]

Well, the user would be wondering why the ones in those multiple results would show the @, and why the ones outside dont. It'll be inconsistent behaviour, and the user would be frustrated to wrangle the app into showing where exactly it is taking them.

I think it'd be better then to always enable the @, unless the app detects (via GET /site) that the server doesn't federate, in which case showing @ wouldn't be necessary

[buresdv]

Well, the user would be wondering why the ones in those multiple results would show the @, and why the ones outside dont.

That's why, by default, we would only show the most active community. Most users would just go there and do their posting at that instance, and those who really want to go to a specific instance, can always expand the search result. The average user would never see that @.

One edge case would be the user subscribing to a community that's not the top result through clicking it on the "All" feed, but this can be solved by checking if the user is subscribed to that community, and then overriding the default most active search result with that subscribed community.

I think it'd be better then to always enable the @, unless the app detects (via GET /site) that the server doesn't federate, in which case showing @ wouldn't be necessary

Then we can check if the server is de-federated and disable the @ format completely.

[buresdv]

Another idea I just had (WAY out there, but I'm just throwing it in): show only one search result. When the user taps on that result and opens that community (gaming, for example), all communities called "gaming" across all federated instances get shown in that single feed.

Similarly, when subscribing to "gaming", the user would be automatically subscribed to all communities called "gaming" across all federated instances.

This can go wrong on a lot of levels, but it's still an idea 😅

[ShadowJonathan]

Ehhh... if it's not communicated to the user that this is happening, then it would be confusing and disorienting.

I don't think it's a good idea, we would be trying to cover up a lot of things the app is doing behind the scenes, that the user would likely not want it to do, if they'd understand the paradigms of the fediverse.

I also personally think that it's a fallacy to try to make it "Reddit-like", or "simple". Mastodon tried this, but it flopped and led to ignorant behaviour that alienated the incoming Twitter users with the existing user base.

Imo we should be focusing on making the experience with multiple communities (with the same name) on multiple servers speak with its own paradigms ('every community is unique, no matter if they share the same name'), and possibly give users the tools (something like a multireddit, that allowed a view into multiple subreddits at a time) to allow something to the same effect.

Ultimately, I think that if we try to hide simple facts like this, we will alienate or confuse the user more.

Providing them this information is one thing, then understanding it is another, but understanding can't come without information, and so if we hide this information, we basically kneecap possibility for any understanding at all.

[buresdv]

You have a lot of good points, but ultimately, the average user doesn't care and doesn't want to understand the intricacies of the fediverse, no matter how much information you present. If we add the @instance format everywhere, they'll be just as confused, but this time because we're showing them too much information. They'll think "huh, this community has a different @ than mine, I guess something is wrong with it and I can’t engage with it. Better look somewhere else!"

This is where Mastodon is currently flopping; they leaned in way too hard into the federation paradigm and forced users to choose their own server. This failed in bringing in users who wanted to "just use" Mastodon; now they had to choose an instance? And what the hell is a "federation", I just want to post for God's sake!

All these federated services ultimately fall to the same fallacy: their developers think that every user thinks like them and is interested in the tenets of the fediverse; but the truth is, the average user doesn't care, as has been proven by Mastodon completely failing to take off for anyone who isn't a tech nerd. Of course, I'm not saying that you're in any way wrong! You're very much right in all your points, and if I didn't know just how much of a disengaged, mindless "consoomer" the average user is, I'd implement your idea verbatim right now.

Ultimately, the average user does not think of Mlem as a gateway to Lemmy. They will not tell their friends "Get on Mlem to access Lemmy," they will stop at "Get on Mlem". As far as they're concerned, Lemmy is just a part of Mlem.

This is unfortunately why we will have to "dumb down" and abstract away many of the intricacies of Lemmy and federation as a whole if we don’t want to be stuck with only tech nerds as Lemmy users. We will have to make a lot of assumptions and difficult choices to abstract a lot of things away, but that's the price we'll have to pay to achieve any sort of mass adoption.

I would just like to mention that my girlfriend, who is a really gifted and smart person, has been using Reddit on her phone for the last couple of years. Until now, she didn't realize that Reddit is not just an app on her phone, but it's also a service you can access online through the browser. And she will have a PhD soon, so it's not like she's dumb. The average user will just think that they're using this "Mlem" app that has all this content, and they will never care enough that it's just a gateway to a wider world of Lemmy.

I'm sorry for maybe a little bit of an off-topic rant, but we have to get into the mindset of the average user and not think of all our users as engaged tech experts who will care about "federation" and "instances." My research on other platforms confirmed that.

[ShadowJonathan]

Hmmmm....

I think you have a good point, I'll admit that my knowledge of the average user is fairly limited, and while I want to raise the point that chasing passive majorities (the "lurkers") over active minorities (the "creators", and also tech-savvy people) wouldn't really be fulfilling or engaging, I do agree that lowering the barrier to Lemmy for "the average user" would ultimately keep a lot of them on this side of the fence, rather than the likes of Reddit or other corporations. (But, keep in mind that people on the other side of that fence, corporations, like to play cat-and-mouse with features, and to please ignore that, and instead focus on core features and polish).

However.

Pretty much a selfish request I have, then, and one I'm also sort-of making for the users of Apollo, is to allow "advanced" features and knowledge like extra instance information, or extra information overall, to be toggle-able.

While the average user doesn't care, it is still critical information for some savvy user like me, and for moderators, who need to be a little more savvy than the average user. (One aspect of moderation could be to ban entire instances from interacting with a community, if that instance would show a pattern of abuse. This is the case on Mastodon.)

I know that's extra development time, but I think that with this, you'll also get a lot of passionate and engaged users. The same ones that chose Apollo over the default Reddit app, the ones that actually care.

[peruginiandrea]

I also think that extra information should be toggable (opt-in). While I understand wanting to make it simpler for mainstream usage, as of now and for the foreseeable future, Lemmy users will be more likely to be "power users" and they wouldn't appreciate Mlem if it hides this stuff. Without these power users, the app won't get popular now, I'm afraid.

[ShadowJonathan]

(Exactly what I wanted to say, thanks for rephrasing it 💚 )

[buresdv]

I absolutely agree that this should be a choice for the user to make! That's a great idea.

Perhaps we could create an issue for tracking exactly what would be a part of this "advanced" mode.

I agree that both the "active minority" and "lurking majority" have valid points. I, personally, think that it would be best to focus on the majority, because if you give access to everyone, many of them will be hooked and slowly, over time, become a part of the "active minority." Because people want other people to hear what they think 😂

One fun idea I've had was to make a special "developer" icon that, when used, would unlock this "advanced" mode.

[ShadowJonathan]

I dont think that it should be locked behind a "developer" flair, I think that it should be something like "Power Mode", or "Advanced Mode", or something along those words.

Making an additional issue discussing the elements which would be "advanced" and which ones would be "basic" would be amazing, yeah :)

[buresdv]

I really like "Power mode," let's call it that 😊

I propose an idea for the roadmap: for now, we do the quick and dirty thing and append the @instance to all search results so we capture the initial wave of power users, and down the road, we can "dumb down" the app for the more average user as they start rolling in. What do you think?

[ShadowJonathan]

Sounds good! Still, we should have that issue where we collect those innocuous "this was too overwhelming for me" feedback and put that there to apply when "dumbing down" the app, while keeping those features with power mode.

[buresdv]

I will get on that once my internet gets fixed

[peruginiandrea]

How are we going to track the features that are overwhelming? Users leaving feedback on GitHub are already more tech savvy than the average so we would miss a few things; and there’s no easy way to leave feedback in-app. So I guess you’re suggesting that we only consider the advanced features we (plan to) add?

[ShadowJonathan]

I meant feedback through channels like the Mlem community (on Lemmy), in the matrix room, or in App Store reviews, basically actively listen to users being annoyed by the extra information, or explicitly asking where they feel it's too busy.

[peruginiandrea]

Okay perfect, that sounds good

[ExperiBass]

woke up and caught up, sounds good :3

[buresdv]

What do you guys think about this?

[ExperiBass]

perfect :D