I moved my company over to Zulip a while back and while I'll admit that it's not quite as polished as slack (the mobile app freezing and having a mildly different UX/features for example) -- it is a lot easier to follow conversations and topics.
It takes about a week to get used to, then people don't want to go back.
Bonus: it can be hosted for free (incl. SSO), though I take the path of paying the authors for their hosted version.
I really don't think I'll go back to Slack; Especially as they're owned by Salesforce and I suspect even more lockin in future and especially rent-seeking behaviour- which always comes from these large acquisitions. (people should be mindful of lock-in for those reasons in my opinion).
I also get massively tilted when non-optional changes to clients happen, like when they completely broke markdown formatting for their style bar, yet still had some markdown formatting enabled which messed up your messages randomly; like not being able to exit code blocks. >_<
I agree about not wanting to leave Zulip. I have to use Slack for work and I miss Zulip every day. On Slack, most of the time I can't find messages I just read. It's bad.
Also, I thought I was the only one who couldn't exit code blocks. The fact that that happens makes me irrationally angry.
out of curiosity, is there a GH issue for that behavior? that sounds like a very straightforward "don't do IO on the UI thread" fix but if they don't know about it, I doubt they're looking for the fix
It's frustrating that every single company seems to move away from building powerful software with high information density to gift-wrapped software with low information density. I make practice tracks for my band, and I still use Audacity to do it, which uses 2000-2010-style software design. I like it so much more than MuseScore 4, which recently adopted a lot of the modern conventions of sleek, button-less two-color design.
It's interesting you say Audacity, because to me that program is an example of what you're talking about, it's low information density that came about from the days where most music apps were a screen full of knobs and skeuomorphic buttons.
That's why I view these things as a constantly swinging pendulum. At some point an app gets so bloated that it should probably be reduced. At other points an app is too simple that it's limiting. It keeps swinging back and forth with people hopping to different products when it swings too far one way.
I'm always surprised by these chat apps having less text visible on a full-HD screen than a text-mode IRC client in a 80x25 terminal. I know cramming things in a tiny amount of space is not great either, but having to navigate all the time to find things instead is even worse in my opinion.
There ought to be one of those laws for this. In this case, I think the law is "All apps with bored UX devs eventually look like Apple Mail." We can call it Bityard's Law, I don't mind.
Just to clarify something: Zulip decorates streams with icons hinting the size of the audience for the stream, which can be helpful for considering the level of care that you might want to use in writing your messages.
In particular, Zulip uses hash icons for public streams open to all members of the organization, lock icons for private streams, and globe icons for web-public streams (https://zulip.com/help/public-access-option). So if you're seeing only globe icons, it's because you're in an organization where you only have access to web-public streams.
My favorite chat app and great people. Its weakest point is the mobile client. The way attachments work is a distant second. Still I would not use anything else.
They probably need to optimise the code so it doesn't take 8-10 seconds of watching a spinner to load that page.
Once it does load, I can't see a way to pin a particular thread to the head of the list. So does everything just get shunted down when a new thread arrives?
If you look back at old Usenet software like pan, they had the UX of multiple threads in multiple groups nailed. I would contend that would be a good pattern to imitate.
Not to sound old and complainey... why the hell are we on an endless "Redesign the UI" hype cycle? At the end of the day, these are tools to accomplish a mission and get actual work done, not a piece of art deco for your fkin apartment.
The answer is in the article: their understanding is that the current interface feels chaotic to users, and this new interface will "tame the chaos" and help you focus.
Personally, I suspect it will benefit one type of user (DMs across multiple slack organizations) and hurt others (one workspace, many team channels with focused topics in each). This is where people get upset with redesigns- everything for everyone is suboptimal for everyone, but there's a good chance nothing else is better... that doesn't stop them from trying, though.
I'm in the latter, and from a very brief glance at the new screenshots, I hate it. I'll reserve actual judgement until I have to use it, but I'm not optimistic that I'm the target audience for the new design.
Yeah no. Slack is the communications hub at my company. I want to be able to see and quickly react to everything at once, not having to switch between different views. It was bad enough when they removed split views last month.
This looks like some misguided attempt to appeal to Discord users.
They did replace the split view with opening in new windows which I personally like better since the OS shortcut for switching windows is now useful. I wouldn't be surprised if they kill them and switch to a tabbed interface at some point though.
Odds on this total redesign of everything including incredibly basic features like syntax highlighting in code blocks? Or is that still on the roadmap for FY 2029
> There is a reason why we have multiple communication medium.
> Public articles - Pull requests - Issue trackers - Internal Wiki - Emails - Chat - Phone calls - Visio - Face to face
I believe this to be absolutely true.
Yet at the same time, it creates its own set of problems.
If I could only tally up the lost hours I've spent trying to track down whether a comment was made on the wiki, or in chat, or via email, or in the PR.
Even using Github alone has this problem. Does something exist as an issue, a discussion, a wiki, in the code itself, a comment on the PR? What's the right place for something to go? These aren't trivial questions, especially for large orgs.
To a certain degree this is an indexing problem as much as it is a problem with the communication medium, but if you bring together all of your communication into a central hub you solve this issue plus many others.
You just annoy a small, yet outspoken subset of people while doing it.
> So we have hours longs Slack discussions that spare us minutes of reading a wiki page or discussing on a phone call.
I think Slack sees these problems and attempts to address them, even if it isn't perfect. See Huddles for example.
Disclaimer: I hate using Slack too and personally wish it wasn't a part of my day to day.
Which is unfortunate because I find real-time communication (including in-person) puts pressure on people to appear to either know what they're talking about/arguing against, or to do so as a means of thinking out loud but without any affordance for real dialectic; whereas everytime I've discussed ideas over email, wrestling with interlocuters, it has been significantly smoother sailing conveying and clarifying terms and implications, mutually.
This likely depends on where you work/whom you work with, but nevertheless, "the right tool for the right job" seems betrayed when it comes to communication which affords no implied pause or space for reflection.
I have refused to use any kind of chat/IM based applications for work. Email is sufficient. The "chaos of your workday" is entirely self-inflicted when you decide to use software like Slack.
It really depends on how you use them. Email can be just as chaotic. I disable notifications on both and check for updates on my schedule. In general, I find Slack more focused on a topic. Email has too much dross.
The needless complexity of Teams' and now Slack's interfaces are just a reflection of the needles complexity of communication in Enterprise settings where everything is weirdly reified.
Some day we'll have a decent chat that doesn't give you problems you don't need. I have been building a Discord/Slack/Mumble alternative since 2020, which is something that I wanted to do since around ~2008 but I didn't have the skills back then. The problem is that I made a few mistakes as I started by writing the client in Go + GTK3, and at some point, it was very buggy (especially in Windows) and hard to debug.
Then I decided to rewrite it in Go + Sciter, but when it was becoming usable[1], as it had voice channels, custom avatars, custom themes[2], and layout modification, embedded images, custom user roles, file upload, and Markdown support, Sciter's creator decided to end support of its TIScript version, which was a JS alternative for controlling the UI. This made all the code that I wrote basically useless as it would have to be rewritten in JS to be compatible with the new version (really bad timing for me to write it in Sciter at that time).
After trying the JS version, it felt even buggier than the TIScript version, and at this time I got sick (stomach related) and had to stop developing it for about a year. During this time, while thinking about it, I realized that all the time that I tried to save by avoiding C++ made me waste even more time. I have tried many options: PyQt wasted too much memory and was too hard to deal with async stuff through QThreads. Rust felt like being married as all it does is whine and you can't get rid of it. Nim had no good GUI option. Go's Qt lib took way too long to do anything as my computer is slow. But now I'm doing what I should have done from the beginning.
A bit more than a month ago, I started to write it in C++ with Qt. Currently writing the media embed part[3]. I think by the end of the year, I should have the basics of a modern chat done, as customizing the UI takes way longer. There is no funding, just me and the dream of a native full-featured customizable (colors, size, space, position) bs-less chat.
Slack has become increasingly buggy and janky (I’m very tired of trying to convince the mobile app that I’ve read the unread messages) and now it’s not even supposed to be a chat app anymore? Why can’t we have nice things? Slack 2018 was so simple and usable.
I've been part of a number of organizations that have tried to use Slack as a knowledge base. It works fine when there is a small amount of information that needs to be shared by a small amount of people (say, less than twenty). I find it is really poorly suited for it when you have more people than that and information to be shared.
The biggest Slack I have been on was I think close to 10,000 people. The team that set it up envisioned it to be the place for everything, but it was a big mess. Perhaps separate instances were needed.
A better approach is to make an existing knowledge base work well within Slack. This is something that Microsoft Teams is trying to do, but still doesn't do completely effectively.
FWIW I've been a part of a company where, at a ~60 person engineering team, it worked well as a supplement for documentation. For big projects, planning, etc, we used Confluence and other actual documentation tools. However, for things like debugging, local env stuff, and dev ops tribal knowledge, slack public channels + search was a god send.
It feels strange to imagine using a chat service like Slack as a knowledge base - it feels so ephemeral! How did that work? Does it have an embedded wiki I don't know about?
I've seen creators move their communities off of Slack because the cost got prohibitive, long before 10k people. I can't imagine how much that cost to operate year-to-year.
In both my machines running Wayland Slack simply segfaults when sharing screen, my solution has been to use flatpak and pin to an older commit (065b3e57e9442c9fbaf851a49cbe6e7b1aa0afcab591)
[+] [-] dijit|2 years ago|reply
It takes about a week to get used to, then people don't want to go back.
Bonus: it can be hosted for free (incl. SSO), though I take the path of paying the authors for their hosted version.
I really don't think I'll go back to Slack; Especially as they're owned by Salesforce and I suspect even more lockin in future and especially rent-seeking behaviour- which always comes from these large acquisitions. (people should be mindful of lock-in for those reasons in my opinion).
I also get massively tilted when non-optional changes to clients happen, like when they completely broke markdown formatting for their style bar, yet still had some markdown formatting enabled which messed up your messages randomly; like not being able to exit code blocks. >_<
[+] [-] stavros|2 years ago|reply
Also, I thought I was the only one who couldn't exit code blocks. The fact that that happens makes me irrationally angry.
[+] [-] mdaniel|2 years ago|reply
out of curiosity, is there a GH issue for that behavior? that sounds like a very straightforward "don't do IO on the UI thread" fix but if they don't know about it, I doubt they're looking for the fix
[+] [-] dvngnt_|2 years ago|reply
[+] [-] quacked|2 years ago|reply
[+] [-] gochi|2 years ago|reply
That's why I view these things as a constantly swinging pendulum. At some point an app gets so bloated that it should probably be reduced. At other points an app is too simple that it's limiting. It keeps swinging back and forth with people hopping to different products when it swings too far one way.
[+] [-] gsliepen|2 years ago|reply
[+] [-] saratogacx|2 years ago|reply
Gutter bar... Check
Multi-line selection... Check
Lowered information density... Check
Yep,. it's a 2020's redesign.
[+] [-] wredue|2 years ago|reply
-every single link is just an unlabeled image that you need to guess the meaning of
But it definitely
-move shit from the place everyone expects it to some other random spot, sometimes several clicks deep, just to fuck with your muscle memory
[+] [-] bityard|2 years ago|reply
[+] [-] tiffanyh|2 years ago|reply
https://chat.zulip.org
For those not aware, Zulip has been polishing it's UI to make it feel fresher - yet keep the high info density it's known for.
Check it out live at the link above.
---
EDIT:
What I'd love to see is Zulip:
- stop using 'globe' icons, and instead us '#' (the industry has settled on '#', so might as well embarrass it)
- update the color scheme/theme (or allow users to define their own color theme)
[+] [-] tabbott|2 years ago|reply
In particular, Zulip uses hash icons for public streams open to all members of the organization, lock icons for private streams, and globe icons for web-public streams (https://zulip.com/help/public-access-option). So if you're seeing only globe icons, it's because you're in an organization where you only have access to web-public streams.
See https://zulip.com/help/stream-permissions for more details.
[+] [-] airpoint|2 years ago|reply
I've checked Zulip out a few weeks back and it's just the same outdated, quirky look and feel.
[+] [-] dizhn|2 years ago|reply
[+] [-] dingaling|2 years ago|reply
Once it does load, I can't see a way to pin a particular thread to the head of the list. So does everything just get shunted down when a new thread arrives?
If you look back at old Usenet software like pan, they had the UX of multiple threads in multiple groups nailed. I would contend that would be a good pattern to imitate.
[+] [-] huhtenberg|2 years ago|reply
That aside, their info density is really good.
[+] [-] solarkraft|2 years ago|reply
[+] [-] rpgbr|2 years ago|reply
[+] [-] exabrial|2 years ago|reply
[+] [-] zdragnar|2 years ago|reply
Personally, I suspect it will benefit one type of user (DMs across multiple slack organizations) and hurt others (one workspace, many team channels with focused topics in each). This is where people get upset with redesigns- everything for everyone is suboptimal for everyone, but there's a good chance nothing else is better... that doesn't stop them from trying, though.
I'm in the latter, and from a very brief glance at the new screenshots, I hate it. I'll reserve actual judgement until I have to use it, but I'm not optimistic that I'm the target audience for the new design.
[+] [-] guessmyname|2 years ago|reply
[+] [-] bityard|2 years ago|reply
[+] [-] whalesalad|2 years ago|reply
[+] [-] dcastonguay|2 years ago|reply
> Starting today, the new user experience will begin rolling out to new teams, and will reach our existing users over the coming months.
https://slack.com/blog/productivity/a-redesigned-slack-built...
[+] [-] tchbnl|2 years ago|reply
This looks like some misguided attempt to appeal to Discord users.
[+] [-] brazzledazzle|2 years ago|reply
[+] [-] pie_flavor|2 years ago|reply
[+] [-] EnzymeFestival|2 years ago|reply
[+] [-] anonyme-honteux|2 years ago|reply
Seriously, having Slack as the go-to-option of your team communication is a terrible idea.
There is a reason why we have multiple communication medium.
Public articles - Pull requests - Issue trackers - Internal Wiki - Emails - Chat - Phone calls - Visio - Face to face
They all have pros and cons in any particular situation and we need to reflect which communication medium to use when.
But Slack made group chat so addictive that in many companies all the other communication medium became second-class citizens.
So we have hours longs Slack discussions that spare us minutes of reading a wiki page or discussing on a phone call.
[+] [-] cooperadymas|2 years ago|reply
> Public articles - Pull requests - Issue trackers - Internal Wiki - Emails - Chat - Phone calls - Visio - Face to face
I believe this to be absolutely true.
Yet at the same time, it creates its own set of problems.
If I could only tally up the lost hours I've spent trying to track down whether a comment was made on the wiki, or in chat, or via email, or in the PR.
Even using Github alone has this problem. Does something exist as an issue, a discussion, a wiki, in the code itself, a comment on the PR? What's the right place for something to go? These aren't trivial questions, especially for large orgs.
To a certain degree this is an indexing problem as much as it is a problem with the communication medium, but if you bring together all of your communication into a central hub you solve this issue plus many others.
You just annoy a small, yet outspoken subset of people while doing it.
> So we have hours longs Slack discussions that spare us minutes of reading a wiki page or discussing on a phone call.
I think Slack sees these problems and attempts to address them, even if it isn't perfect. See Huddles for example.
Disclaimer: I hate using Slack too and personally wish it wasn't a part of my day to day.
[+] [-] imbnwa|2 years ago|reply
This likely depends on where you work/whom you work with, but nevertheless, "the right tool for the right job" seems betrayed when it comes to communication which affords no implied pause or space for reflection.
[+] [-] SoftTalker|2 years ago|reply
[+] [-] Tagbert|2 years ago|reply
[+] [-] imbnwa|2 years ago|reply
[+] [-] zacharycohn|2 years ago|reply
[+] [-] UnnoTed|2 years ago|reply
Then I decided to rewrite it in Go + Sciter, but when it was becoming usable[1], as it had voice channels, custom avatars, custom themes[2], and layout modification, embedded images, custom user roles, file upload, and Markdown support, Sciter's creator decided to end support of its TIScript version, which was a JS alternative for controlling the UI. This made all the code that I wrote basically useless as it would have to be rewritten in JS to be compatible with the new version (really bad timing for me to write it in Sciter at that time).
After trying the JS version, it felt even buggier than the TIScript version, and at this time I got sick (stomach related) and had to stop developing it for about a year. During this time, while thinking about it, I realized that all the time that I tried to save by avoiding C++ made me waste even more time. I have tried many options: PyQt wasted too much memory and was too hard to deal with async stuff through QThreads. Rust felt like being married as all it does is whine and you can't get rid of it. Nim had no good GUI option. Go's Qt lib took way too long to do anything as my computer is slow. But now I'm doing what I should have done from the beginning.
A bit more than a month ago, I started to write it in C++ with Qt. Currently writing the media embed part[3]. I think by the end of the year, I should have the basics of a modern chat done, as customizing the UI takes way longer. There is no funding, just me and the dream of a native full-featured customizable (colors, size, space, position) bs-less chat.
[1]: https://i.imgur.com/BFAF2f0.png
[2]: https://i.imgur.com/SagVweI.png
[3]: https://i.imgur.com/nhBUsGh.png
[+] [-] wrs|2 years ago|reply
[+] [-] hahamrfunnyguy|2 years ago|reply
The biggest Slack I have been on was I think close to 10,000 people. The team that set it up envisioned it to be the place for everything, but it was a big mess. Perhaps separate instances were needed.
A better approach is to make an existing knowledge base work well within Slack. This is something that Microsoft Teams is trying to do, but still doesn't do completely effectively.
[+] [-] samschooler|2 years ago|reply
[+] [-] marssaxman|2 years ago|reply
[+] [-] pc86|2 years ago|reply
[+] [-] paxys|2 years ago|reply
[+] [-] cryptonector|2 years ago|reply
[+] [-] Solvency|2 years ago|reply
I honestly cannot believe they planned this, paid for this, and signed off on it. Of all the things to blow your resources on.
[+] [-] whalesalad|2 years ago|reply
[+] [-] badosu|2 years ago|reply
[+] [-] fifteen1506|2 years ago|reply
It works on Gnome Fedora. You'll have to add the app handlers for slack:// or similar. Search on the Internet.
PS: on Fedora 38 works on Gnome but not on KDE :shrugs:
[+] [-] bityard|2 years ago|reply
[+] [-] akmittal|2 years ago|reply
[+] [-] guessmyname|2 years ago|reply
>
> https://slack.com/blog/productivity/a-redesigned-slack-built...