A core requirement of any social app is to be able to communicate. The first part of this process is a post (what the conversation revolves around). After that there's the reply, where others join in. Before starting this I thought the hard part would be the design of the schema (lexicon in atproto speak) but it turns out that's quite simple. The hard part is the UX!
Threads
Craftsky is going to be a community of like-minded people that share a passion in a textile craft or two. I want the app to be able to facilitate more than a reaction and a "Great job" (although, nothing wrong with that). I want people to be able to have a conversation about whatever was originally posted. This means they'll be more than just 1 reply. They'll be a reply to a reply. And then a reply to that reply. And so on... They'll also be multiple of these on a single post.
The question is how will Craftsky allow people to do this while maintaining usability, clarity and accessibility on what I expect will be a mobile focused audience?
Instagram style
As much as I abhor the platform, offering an experience similar to what most people are already using definitely has merits (as long as it's good, both morally and literally). The way Instagram handles replies is that when clicking into a post you see a list of all top level replies (called comments). You can then click to expand each reply to reveal a second level of replies. This is as far as it goes though. If you then reply to a 2nd level reply it just mentions the user and your reply stays at a 2nd level.
Pros
Simple UI
Minimal nesting
Easy to scan to see which replies/comments to view and be part of
Cons
More than 2 or 3 people conversing in a reply becomes hard to follow
Bluesky style
The Bluesky app (and code) is my go to for inspiration or ideas on anything to do with the ATProtocol because, I would assume, they know what they're doing. In Bluesky the replies are fully threaded. This means you can go as many layers deep as you want. In the app this is handled quite elegantly where clicking on a reply (let's say one that 3 layers deep) navigates to a new page/route where that reply is at the top of the page. You can scroll up to see the reply's parents (all the way up to the original post) and down to see further replies.
It does do this thing where it will show nested replies but only for the longest reply chain.
Pros
UI always uses full width
Chain of the thread is easy to navigate
Cons
Some replies get buried
Not so easy to scan
Reddit style
Very similar to Bluesky but replies are indented and a lot more are shown at once. Even on mobile you can go about 5 layers deep before it reloads the page and hones in on that thread.
Pros
Can have longer conversations
Easier to see context
Cons
Visually dense
A lot of replies are hidden
Outcome
At the start of this, I was convinced I was going to implement something with near-infinite nesting but I came to the following conclusion.
Social sites like Instagram/Facebook are more about the OP communicating with their followers. Sites like Reddit/Hacker News are about discussing the information shared by the OP (e.g. a news article). In the former case, there's no need for deep nesting as its more like lots of 1-1 conversations rather than the latter n-n discussions.
To prioritize visual inspiration and ease of browsing for mobile users, I am prioritizing a shallow UI, while retaining the technical capability for deep threading in the backend.
Some useful research
https://socialhub.activitypub.rocks/t/discussing-bonfire-thread-ux/2161
https://elezea.com/2015/09/how-to-display-threaded-discussions-on-the-web/
https://blog.codinghorror.com/web-discussions-flat-by-design/