When IRC looks like this https://quasseldroid.info/assets/images/phone.png or this https://blog.irccloud.com/static/2018-05-14-slack-integratio... and people still complain about IRC’s UI or usability, then what more can we IRC devs do?
So I had an android IRC app for a bit, some top paid one, and get booted from a bunch of my favorite channels because apparently it was just sat in my pocket cycling my connection and flooding the channel with join/unjoins.
That, plus the weird way to authenticate doing /msg Nickserv identify. That might be just how the server I was connecting to was implemented, but it felt fucky.
That's what SASL has been for for over a decade nowadays :)
IRC was designed, mostly, for two types of users: A) Large institution users who had a fixed link to the internet and ran in their shell on a mainframe. B) Dial-in users, who's devices mostly stayed connected, and when they disconnected, usually required manual intervention to get back on.
Anyone, and I mean ANYONE using a mobile phone SHOULD be using a 'bouncer' or other gateway to access a live communications environment. This would be more like use case A where someone has a small agent on a slice of a server they 'trust' and that maintains state (for their client) and stateful connection (for links to other servers and users).
IIRC, Quassel IRC has such a client/server model for the client, there are probably others too.
It occurs to me that if IRC networks hosted their own bouncers, but that these bouncers were written efficiently to exchange data directly with the IRC servers' and their database rather than keep individual logs and so on, we might have something close to the "open-the-app-and-see-past-messages-without-needing-to-be-permanently-connected" quality that people have come to expect from instant messengers, Slack, Discord, etc.
(but then you might as well just write such functionality directly into the IRCd)
Nah, such a thing would make most sense as a separate daemon that uses the server-server protocol to connect to the ircd (ie. it appears to the rest of the network as just another ircd).
It wouldn't be hard to build such a thing, the hard part would be convincing an existing IRC network to run it.
The goal is to get rid of the historic interfaces which required a lot of RTFM, and instead to allow users to discover functionality through the UI easily.
If you have any suggestions on what to improve regarding UX of Quasseldroid (my main project), I'd love to hear suggestions, as I'm always interested in improving its UX and learning more about UX design. After all, I, as quasseldroid maintainer, am just one student, not a team of highly paid UX designers.
(And personally, I'm a huge fan of tools like Zulip, Mattermost and Matrix as well — we're all fighting on the same side, after all :)
And I'm personally working on Quasseldroid, improving its UI to make it much more usable.
If you have suggestions on how to make Quasseldroid usable for the people that refuse to use IRC, I'd love to hear them :)
Sure, but the reason all the developers at my workplace use Slack is because we have to communicate with a lot of people who aren't developers.
Slack's good UX extends beyond the basic chat interface to configuration, administration, and initial signup. It's significantly easier for someone nontechnical to toss money at Slack to get a new private space than it is with IRC. The first page of "IRC hosting" search results on Google for me are mostly shell accounts; nothing turnkey and professional looking that a business person could/would use.
https://rocket.chat/
https://zulipchat.com/
https://matrix.org/
https://mattermost.com/And honestly, of all the alternatives, IRC is by far the most popular one (and the other alternatives have IRC bridges) hence the most likely to stay around the longest.
Also the simplest to implement, which helps a lot too.
I've used IRC quite a bit but Slack is light years beyond in terms of the UX of even the nicest IRC clients. I think Discord is probably even better than Slack though.
And personally I consider the slack UI, especially due to the different workspaces, relatively unintuitive.
Matrix is an incredibly centralized service masquerading as an easily self-hosted distributed service. The moment you try to get a non-technical user connected to a homeserver other than matrix.org, all hell starts to break loose.
It's bad enough that both France (tchap) and Purism have created their own client forks to make on-boarding somewhat tolerable at the expense of really painful rebases against upstream Riot, while Riot tries to get it's shit together on the non-matrix.org user story.
Mattermost has a slightly less painful situation -- they provide a relatively easy to brand/preconfigure client (and fantastic docs on how to do so: https://docs.mattermost.com/mobile/mobile-compile-yourself.h... ), but you lose out on federation and self-service sign-up, leaving your community isolated (sometimes a pro, sometimes a con).
I've personally run 3 homeservers for communities formerly centered around Facebook, only one of which was technical. For the non-technical communities the workflow was the one provided by riot-web when a mobile user visits the homeserver.
Neither of the non-technical communities saw more than 5% adoption in the org. The technical community constantly complained about the login flow.
When I deployed Mattermost with a custom app for the first non-technical community I saw 40% adoption within a week, and 80 within the month. The second community has looked at the first as an example, and I can expect 80%+ adoption within a week or two of deployment.
I've asked repeatedly in both #ios:matrix.org and #android:matrix.org about assistance in putting together docs similar to mattermost's and was completely ignored.
I've asked if the Riot folks would be open to deep-links providing the homeserver to mobile apps, and was shut down by somebody who insisted deferred deep links were the only kind of deep links, and that they would only ever be supported by a Google Play on-boarding flow.
I really want to love Matrix, but y'all make it fucking difficult sometimes.
Meanwhile, if you go to Riot/Web on mobile for a custom deployment, you should see a page like this https://webchat.kde.org/mobile_guide/ which guides you through the process.
Deeplinking from web into the app is hard, as the only way to do so vaguely reliably is by fingerprinting the browser using something like branch.io, which is distasteful from a privacy perspective. Meanwhile, affiliate links in google play seem to only work about 30% of the time, given the planets have to be in precisely the right orientation for the association to not get lost.
Mattermost might be doing something smarter (perhaps letting you install the app generically, and then getting you to click a custom URI handler link from the web to provision the correct config on the client?) - but would be useful to know which of these failure modes people were falling into?
This is exactly whay I was getting at before. Please stop fixating on the deferred form of deep links. The play store need not even be involved for deep linking to an already installed app.
The mobile_guide instructions are where most people bail out.
"Yeah, no. This is too complicated." is the response when they see
"Install an app, then click on a check box that changes the UI, then enter https://foo.bar:8448, then register".
That's a massive turn off before your app is even installed. A flow of "Install this app, then return to this web page" is significantly easier. Or if/when branded builds of Riot are possible, it becomes "Install this app."
If you think that you can't do free software development without relying on all the capabilities of Slack, then the honest thing to do is to quit and spend the rest of your days just working on proprietary stuff. You obviously prefer the solution which has features over any other concern, so why would you waste your time having anything to do with free software?
Richard Stallman obviously used proprietary software. But not past the point when he had replace it, even imperfectly: "I began work on GNU Emacs in September 1984, and in early 1985 it was beginning to be usable. This enabled me to begin using Unix systems to do editing; having no interest in learning to use vi or ed, I had done my editing on other kinds of machines until then." [https://www.gnu.org/philosophy/fsfs/rms-essays.pdf] This tells us that Stallman used Unix. Well, why wouldn't he have; what other practical way was there to code anything? (One supposes he could have started from the bootloader on up, like the Unix guys before him.)
Stallman wouldn't use Unix today, since it has been replaced by free software, and he wouldn't use arguments like, well, such and such proprietary Unix has better memory management or faster I/O, so I will still use that.
If you're using things like Slack or Github without the slightest intent of working toward replacing them, yet using them for free software activities, then that is a comically conflicted position.
I totally get the value of a non-corporate, non-centralized solution. It just needs to have at least as good of a UX for me to switch back to using it.
https://www.gnu.org/philosophy/open-source-misses-the-point....
> A pure open source enthusiast, one that is not at all influenced by the ideals of free software, will say, “I am surprised you were able to make the program work so well without using our development model, but you did. How can I get a copy?” This attitude will reward schemes that take away our freedom, leading to its loss.
> The free software activist will say, “Your program is very attractive, but I value my freedom more. So I reject your program. I will get my work done some other way, and support a project to develop a free replacement.” If we value our freedom, we can act to maintain and defend it.
Relying on Slack, Github and what have you is clearly not to "get my work done some other way, and support a project to develop a free replacement.” It aligns with attitude exemplified by the "pure open source enthusiast".
Being technically the best (or the best in 'freedom') doesn't seem relevant to anyone.
IP, TCP, SMTP, HTTP, these are fundamentally technologies of federation. They succeeded and continue to succeed spectacularly. However, with the commercialization of the Internet there are much stronger countercurrents. I still expect federated solutions to succeed, but adoption will be slower and punctuated, and in the interim there'll be countless proprietary also rans.
I think you can see some evidence of what people thought were development machines by the fact that Lisp Machines only seem to have been NFS servers, not NFS clients.
I don't see a big difference between sending the message :rose: in Slack and having the client display it as a picture of a rose, vs sending the message :rose: in IRC and having the client display it as a picture of a rose. Emoji don't enter into it.
Reactions, maybe.