Live data from Hacker News

The Matrix Trashfire

blog.koehntopp.info

121–130 of 217 posts

Re: The Matrix Trashfire

#121
post #27

Developers could also do these processes. And they probably do, often. But they usually have their heads so far up their asses that they don't see how inscrutable this onboarding process is even for very technical users. It's like when you use one of those Linux phones and your reaction all along is "ew". Do developers not notice how bad this is? No, they don't. Some of them haven't used a good UI ever. They can't fa…

Nowadays companies win because of better marketing and then network effect. The quality of the product does normally not play a big role for capturing a market

Bullshit. Discord absolutely gained traction among gamers (and then other communities) due to being a good product that Just Worked.

Re: The Matrix Trashfire

#122

I mean, this is quite silly. Matrix is the open-source network infrastructure, Element is the client. Of course if you go to the Matrix web-page, it's not particularly user-friendly - if you expect to just use the thing, you should be going to Element. The ActivityPub page won't exactly help you sign up to Mastodon either. There are plenty of problems with Element and Matrix (I say that as someone who has been trying…

The ability of some in the FOSS community to always blame the user for poor UX design is truly impressive.

Do we need to test and simplify our onboarding? No, it's the confused users who are wrong!

Re: The Matrix Trashfire

#123
post #58
post #18

This kind of process is extremely valuable and should be done by devs more often. Start from the start and follow whatever your application tells you to do . Note down when it doesn't tell you where to go or what to do. You'd be surprised by just how many things you do automatically while working because you know the little tricks and things to get by, and that wording doesn't necessarily match what the app requires…

QA is a massively underappreciated position. A QA person that knows when to automate, when to manually test, and how to report and file issues relevant to the project can save a significant proportion of hours on a project overall. I wish many more companies included budget for QA, it saves developers a lot of time. A bit of a side-note: this sort of analysis is a great answer to "I want to contribute to open source,…

Good QA people are hard to find and it's a weird balance to strike.

I've seen QA get run over by aggressive developers.

I've seen QA people who were so good, detailed and provided clear reproduction steps that developers couldn't wait to see them work.

I've seen QA people who were completely unwilling to work on efficiency improvements, automation or even testing things in parallel so they became a bottleneck to the entire organization.

I've seen QA people who just fall into a routine, do exactly what is asked of them and never try to improve.

Like with anything, it comes down to the person in the job. If you get QA people who are really committed to the work, take pride in what they do and are always trying to improve it's the dream.

When you don't have that, it's a very mixed bag.

Re: The Matrix Trashfire

#124

I really don't like the forced end to end encryption of chats. I do not care that much about the security of my chats to justify the complications of end to end encryption -- verifying devices, constant "reset" prompts that I don't even know what they do, but they seem like they are very destructive. I trust my homeserver, since I host it myself. I do not need end to end encryption. I understand this is an issue of t…

tbh the best thing about Matrix is that you have a hope in hell of actually federating it.

XMPP had that promise but due the XEP situation it quickly became difficult to actually federate as most XEPs are optional or not supported on your federation partners.

Everything you said is true; if you can tolerate centralisation then just stick to XMPP, it's pretty good.

Re: The Matrix Trashfire

#125

Earlier quoted context omitted.

That may be technically correct, but reality is if Matrix wants to catch on (large scale) as a concept, it needs to act as a product in some way. Even if that just means having a good landing page guiding users on how to sign up on a server, install a client, and connect the two - and making sure that this always works.

I think that's one approach, but many other federated systems don't do this. ActivityPub does not do this really, instead Mastodon, a product using ActivityPub, markets itself. Arguably you could look at HTTP and say that HTTP doesn't have a fancy landing page pitching itself to users, browsers have landing pages pitching their experiences to users. Matrix could have a fancy landing page pitching itself to implemente…

Maybe "Matrix" is not the ideal name for it then.

ActivityPub, HTTP, XMPP, etc sound like technical things. If you land on a page talking about the "XMPP specification" then you quickly get the idea that it's not where you want to be as an end user.

"Matrix" does sound a lot like the name of an end-user relevant product of some sort, and a client sending users to matrix.org compounds the issue.

There's a reason why big companies have brand guidelines. They have people on staff that understand that people are confused quite easily and don't want to figure out where "Matrix", "Element" and "Element X" stand in relation to each other.

Re: The Matrix Trashfire

#126

Earlier quoted context omitted.

> Lastly I think comparing an open source project like Matrix/Element to Publicly traded corporations like Slack or Meta, is not fair. If we want to "win" (reach similar/higher adoption), we need to at least come close. It's not easy work, but not doing it and leaving the product that so much good work has ready gone into unusable for a vast number of people would be a bummer.

Not sure we want to "win". If endusers want apps "to just work" without "paying up", then I would recommend them to stay with Whatsapp. That kind of users aren't worth the hassle if they have no money. I personally have better relationships with people that enjoy learning something new, and coming up with solutions for issues themselves, eventually contributing to the ecosystem.

I'm very sympathetic to this line of thought in general, being in a similar position with our own project.

But it's still important not to make people waste their time. End users should be sent to an end-user friendly place, and developers should be quickly sent off to usable development documentation.

It doesn't help anyone to confuse people and have them figure out the details of the internal organization and convoluted relationships between various pieces before they can even start doing work.

Re: The Matrix Trashfire

#127

Ok, now do XMPP. Or Signal, but with the added requirement that you want to run your own server.

Having set up and administrated both an XMPP and a Matrix server, XMPP is way less a pain in the ass. I've enjoyed dealing with prosody much more than either synapse or dendrite. XMPP doesn't tank my server every time I try to join a new room and it doesn't take forever to start talking in a room after you join it. And provided you're running the server, getting people onto XMPP has not been hard in my experience. I made a basic registration page with simple instructions. I have gotten people with low technical know-how to successfully register accounts and use it without issue. They just create an account, enter their username into a client I recommend, and they're ready to go (I've never even had them complain about OMEMO).

Re: The Matrix Trashfire

#128

Earlier quoted context omitted.

Matrix and Element are no longer the same entity. Element (New Vector Ltd) is the core behind the Matrix protocol, but they're distinct from the organisation that manages the protocol. If Matrix does ever take off, this will be an extremely valuable distinction to have.

I understand that completely, I even considered including a "Before anyone jumps in with 'akshually that's Element', [..]" disclaimer but decided nobody would be that pedantic. Element is the same team as the Matrix.org foundation, with the same objectives. I understand why they maintain a separation of concerns at the institutional level, but for someone to say "Matrix offers hosted servers" and to act confused like…

No, they aren't the same team (anymore), and there isn't just Element as a service provider

Re: The Matrix Trashfire

#129
post #128

Earlier quoted context omitted.

I understand that completely, I even considered including a "Before anyone jumps in with 'akshually that's Element', [..]" disclaimer but decided nobody would be that pedantic. Element is the same team as the Matrix.org foundation, with the same objectives. I understand why they maintain a separation of concerns at the institutional level, but for someone to say "Matrix offers hosted servers" and to act confused like…

No, they aren't the same team (anymore), and there isn't just Element as a service provider

And yet Thib, mentioned in the article, does say in an another comment that they are employed by Element but working for The Foundation, making it quite hard to know the difference between the two: https://news.ycombinator.com/item?id=39369239

If you dig a bit, I'm sure you'll find this is true for quite a bit of the people either in Element or in The Foundation.

Re: The Matrix Trashfire

#130

Earlier quoted context omitted.

I always give the power to my QA team to block any release no matter what and to give higher priority to tickets than product manager. If CEO wants to override, I cover them and take the blame. This is not a guarantee that there will be no bugs in production, but it saved us a few times.

The Japanese testers were the best I'd ever seen. They never reported a "NotABug." They could back up every report, and give exact reproduction steps. They found weird, obscure corner cases, and that was by hand (they hated automation tools). They had 3,000-line Excel spreadsheets. If even one of those rows failed, the whole shooting match (like an entire product line) could come to a halt (so that meant they had to…

I worked with NTT Docomo years ago for a short time. First time I ever got to see a CMM Level 5 organization. It was insane. No wonder Japanese cars were so much better than everyone else for so long.

If you ever get the chance, take it - you will learn way more about software quality than you thought existed!

Post reply on HN