Jeff Sikes
Mastodon's latest version has the ability to fetch missing replies from a conversation (under an experimental flag, not enabled by default).
This is a big deal, especially for smaller instances. Mastodon joins other platforms - of which I know of: Streams, GoToSocial, IceShrimp.NET and Bonfire - that pull back replies on request.
The hard work on the backend is done, and now there needs to be a discussion about how this interaction works as part of the user experience.
Jeff Sikes
Right now the experience is a bit awkward on most platforms:
* Open a post detail view
* This triggers a request to pull down missing replies in the background.
* Sit and wait X number of seconds/minutes, hope the reply task is finished, refresh the screen - and maybe some/all of the extra posts are downloaded.
Not the best user experience.
Jeff Sikes
What is needed to improve it? A streaming endpoint? A "pull all replies" button that auto-updates, displays them as they come in?
This will require front end updates to every client, which will obviously each handle this a bit differently.
What we've seen in the past tho, like with post quotes, is that once a single app figures out a way to represent the process, the others follow suit.
Kristoffer Lawson
@box464 I fundamentally believe the correct way to do this is a button:
* Showing only the replies an instance knows about by default is a kind of social filter mechanism — you or your close network (instance) has been made aware of these replies. Fair chance they are the most relevant to you. Like AI selectors on other platforms, but better.
* But then able to fetch more on request. An interaction people are used to.
* Saves bandwidth by only fetching upon request
Tim Chambers
@Setok @box464 Can someone mock this up visually? I can fully imagine Phanpy doing this first… @cheeaun
Kristoffer Lawson
@box464 same logic for live updates. Don’t mess around with what’s being shown (UIs that change uncontrollably are a bit of a nightmare). But ping in background ‘Are there new replies?’. If there are, offer user a button saying there are new replies and that by clicking, they will be fetched. But it’s in their control. User having the feeling of control is key.
Kristoffer Lawson
@box464 a certain amount can be fetched, with a further ‘fetch more’ as needed. This can also work into the deeper nooks (branches) of a conversation. Much like how Reddit does it (again, meaning this model is familiar). So upon request the fetcher follows to a certain depth. It then indicates more can be fetched.
Ideally ‘Fetch More’ should not appear if there are no more new replies. But that would require at least a ‘are there more?’ ping.
Chee Aun 🤔
@tchambers @Setok @box464 I'm aware of this https://github.com/mastodon/mastodon/pull/35210
Tim Chambers
@box464 If enabled by a server now, what is the user experience now on say Mastodon web? Does it “work” at all now or is this just plumbing in place for hopefully near future?
Tim Chambers
Very cool: can't wait to see how you use this, always impressed with your UX choices.
Kristoffer Lawson
@cheeaun @tchambers @box464 I don't think this provides the functionality that I was thinking of:
* Only show known replies by default
* User can request to show all replies, upon which they are fetched (spinner etc while fetching) and shown when they have been retrieved (or a certain threshold has been reached, after which more can be retrieved)
I think there are good reasons to do it this way. Gives user control and 'best' replies first.
Kadsepfösch
@tchambers @Setok @box464 @cheeaun Wafrn (https://app.wafrn.net) has this. It loads the conversation with all known responses and displays a button "Fetch more external replies".
Tim Chambers
@Glatorius @Setok @box464 @cheeaun
Just me by my own prefernce would be a UX message: "Updating this post to get all replies...." that goes away when all messages are in... without having to click a button. Or if there IS a button that it is a "stop fetching latest replies."
Tim Chambers
@Setok @Glatorius @box464 @cheeaun I could imagine UX thst just said “fetching the full conversation, click here to stop fetch…” automatically without users kicking it off — and then a graceful refresh only after everything set. No bouncing around, etc.
Kristoffer Lawson
@tchambers @Glatorius @box464 @cheeaun if it constantly fetches then the replies screen would randomly bounce around, potentially by quite big steps?
Also you’d lose the benefit of the ‘social filter’ on replies (your server and network defining which replies appear first).
I kind of like the latter. We don’t have algorithms defining what is important, we have our neighbourhood. So to speak :)
Tim Chambers
@Setok @Glatorius @box464 @cheeaun I think my POV on this is that imitating a full complete view of a conversation shouldn’t be MY job, it should be a task the social platform itself just does, but I should have agency to stop it if I don’t care.
Kristoffer Lawson
@tchambers @Glatorius @box464 @cheeaun why would you prefer fetch automatically rather than fetch in request?
Tim Chambers
@Setok @Glatorius @box464 @cheeaun My own take on that is the incompleteness of replies due to my own federation view is in practice a bug and not a feature. My slice of the fediverse view doesn't really add security or value in seeing replies, it just adds opacity. A better filter for me is not seeing those I block, but think we get that now and in this model too. Just my $.02.
Kristoffer Lawson
@tchambers @Glatorius @box464 @cheeaun ok, fair enough. I take it you don’t see value in the ‘social filtering’ that you get with showing only known replies initially? (A bit like FB ‘Most Relevant’ replies)
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.