Building a Discord replacement is easy. Getting millions of people to switch their entire communities away to an unproven platform with spotty documentation, no existing network effect, no meaningful moderation tools, and no meaningful user support is fucking impossible.

This isn't a dig at people using Discord. This is a dig at projects that are completely unaware of or interested in what the actual challenge of building something usable by people that
dont and will never care about computers is.
If your project is aiming for adoption by lots of people (and plenty aren't and that's also okay) then you need to really grapple with the fact that the overwhelming majority of people have other important things in their lives that are dramatically wildly more important than end to end encryption, federation, or "a hacker ethos."
Like, even signal is too high a bar for many people and it's probably the easiest to understand of almost all the available alternatives (and it doesn't even meet most people's requirements.)
@amy my union branch moved off Signal because some people found it too difficult to use. My union branch is specifically a tech branch. If we had to shift back to WhatsApp, I can't blame anyone else for sticking with the big platforms.
@amy seriously, software folk need to understand that a user thinking about your software is a failure.

If they are thinking about your software while not actively using it you almost certainly have a bug of some kind to cause that.

@amy @mindpersephone this is an extremely problematic way of thinking.

Sure that's the dream of UX, but except for very simple tools, no software can work that way.

Technology is complex and we cannot possibly shield the user from 100% of that complexity.
A lack of digital literacy is already a massive societal issue. Let's not pretend that this is a problem that can and should be solved entirely on the software side

@nightoo @mindpersephone I don't think we've seen nearly enough software where UX people were allowed to actually prioritize the people using the software to make such a statement. The majority of software that people interact with is tied to corporations trying to extract ongoing value instead of trying to make something that solves what someone actually cares about. This is about actually doing the job of designing tools, which is what software is, that are fit to purpose by understanding what people are actually trying to do. Having helped do this before it's a phenomenally large undertaking but is by no means intractable.

We took a large complex time series analysis tool (web UI, APIs, and CLIs) and reduced the learning curve from months (and two full days of training that I personally ran for classes of 20+ people) to weeks. This tool had a large amount of necessary complexity on account of it being a very complex domain, but adapting the interfaces to manage that complexity more effectively directly improved the experience for users with simple needs
and our most niche power users because they weren't spending most of their time fighting to figure out how to do what they wanted.

@amy @mindpersephone
I fully agree with most of what you say. But to stay with your example, it sounds like after putting in a massive concentrated effort, the best you could do is reduce the training time to *weeks*.

To get back to the original statement:
> seriously, software folk need to understand that a user thinking about your software is a failure.

Do you think that, even given infinite time, you could have reduced that time to zero?

@amy
I don't think that this is possible for *any* project, except perhaps for those tools that perform exactly one task and nothing else.
You cannot get around thinking about a software you use, unless that software is implementing processes devoid of any complexity themselves.
@nightoo @mindpersephone I don't think it's reasonable to take what Persephone said as implying that learning curves should be zero. But that they should be pretty damn close to zero if you're implementing a consumer chat app.

There's a difference between necessary and unnecessary complexity. The time series analysis tool has a huge amount of necessary complexity because doing that analysis is complex work and the job of the tool is to make that complexity as tractable as possible. A consumer chat app should be close to virtually zero complexity because it's a well explored problem space with a large body of existing design language that people are familiar with. If you break from that design language it's important for that break to be accommodating necessary complexity that users care about interacting with.
@amy @nightoo pretty much this

No one thinks "yay I'll get to use $chat_app later" they think "yay I'll get to talk to my friend later"

we think about the problem we are trying to solve not the tool we are going to use to do it most of the time.
@mindpersephone @amy @nightoo The amount of times I've seen chat apps, like, not even bother with proper Mac OS/iOS support is, like, way too high. Yes, tech nerds don't tend to use them much, but not all of my friends are tech nerds and the whole point of a chat app is that I can talk to my friends. And, like, that's just one example of how these supposedly technically brilliant projects have massive issues getting in the way of them catching on

@amy I have a hacker ethos.

Federation and decentralization for real-time chat in friends groups or communities of even up to a few hundred people?

What a horrible idea, you're hereby required to attend Computer Science 101.

(I'm rooting for Stoat at this point.)

@amy Guilded was promising, until the sold out to Roblox. Revolt (renamed to Stoat in October) looks promising.