The first thing I looked for was a comparison with the official Slack client in terms of performance, since that's the only reason why I'd consider using this. Numbers for CPU load, memory use, time to perform certain actions, crashes. Doesn't seem to be anything available on the site regarding this, which is a shame.
It is a user experience choice. Most decent native macOS apps adhere to system conventions. Text editing works as one would expect in a system text field. Keyboard shortcuts behave as expected. Custom keyboard shortcut definitions from the Keyboard section in Preferences actually work. And on and on.
Slack in particular is extremely, extremely slow, even by Electron standards. I can't expand it to the full-height of a 4K (running at 1080p) portrait monitor without typing becoming unbearably laggy, so I either have to keep it at 1/3 monitor height, or have to use another application for writing the text.
it also has multiple accessibility issues for low vision users. I'd happily switch to a native client because using native widgets instead of HTML would likely address most, if not all, of my accessibility needs.
I've literally never had or heard of Slack crashing, across Windows, Ubuntu and macOS, regardless of memory available (8-32GB) and use. Do people really have Slack regularly crash on them or is that just something that gets attached to Electron (for some reason).
A slack crash would be the window going white and reloading.
I get them occasionally.
An electron crash would kill the window. I get these sometimes too when I try to run natively in wayland, which I’m aware is unsupported so I’m not blaming anyone for that.
No offense, but you must have blinders on then. On a fresh install on a new machine it’ll do it in the first day.
> It's crash-free for me, running 24x7.
There was a person who legit got struck by lightning multiple times in their life and lived, so anything is possible. Your claim is comparatively improbable though, but still has the possibility of being true.
I have experienced few crash like scenario with network issues on my Mac. If my wifi is poor for a minute, slack will permanently stop working unless I force reload using menu or restart it. Messaging apps are basically meant to not have permanent connection, but I have seen very few that could work with this assumption.
Slack regularly crashes with an empty window on my Mac. Not like a process crash, but the whole window going empty, needing to quit the process and reopen.
Slack crashes (unresponsive white window -> hard reload) for me at least once a day on the latest MacOS and Intel MBP, and it seems a common occurrence for many of the coworkers I talk to.
An even better reason would potentially be security. Exploits in electron are pretty common, which may be a result of its ubiquity making it a big target. But also it's just a complicated platform to secure.
If I was worried about security then I think I'd probably move to using the web client (or a web wrapper) instead of switching to a third party native application.
That's a common refrain I hear that Electron apps aren't secure. It was more true in the past and less-so now. I've been maintaining a secure Electron template for 2 years that's got traction in the community, if you are interested - https://github.com/reZach/secure-electron-template.
>Slack is one of the most secure Electron apps currently in existence at the moment, they have been...
And from your other comment
>we in the Slack Desktop team
Seems misleading to declare something like this without a disclaimer that you work for the company in question, especially when phrasing it as if you are definitively not a part of said company.
Most of the point of skipping electron is memory usage, which is a major issue with having a full separate installation of Chrome just to handle a webpage, which is what Slack is.
It's funny to see how basically all the official mainstream IM clients like AIM, MSN, ICQ, etc. used to be 1-window-per-conversation, but then in some odd wave of "modernity" (for lack of a better term) that was all dispensed with, and then now, multiple windows is somehow heralded as a new feature again.
To me, it's just common sense that each conversation should be in its own window, instead of stuffing them all into one window that only shows one at a time.
There's another comment here about how Teams' multiple windows is confusing, but I think that's more to do with it being Teams than anything else; as I mentioned above, all IM clients were originally multiple-window and people certainly didn't have trouble using them.
Clients like Adium (on Mac OS) and Pidgin (elsewhere, but honestly nothing is as nice as Adium), had a great solution for this. A window with tabs, but you can just drag tabs out and have more than one window. Plus you could style messages client-side. Nice and easy, better than anything popular today.
Adium was everything an IM client should be. I wish it would return to relevance, but with the dominance of closed messaging protocols that seems unlikely at best.
I remember when a lot of software had heaps of windows. Like graphics editing apps, logic, Final Cut etc. Been a huge cutting back on windows for apps.
It’s more to do with having a unified experience with mobile - slack pretty much has the exact same UI on all devices (only change is whether the side bar is visible, which just depends on screen size). For better or worse, not judging here.
On a Mac, Teams doesn't obey many of the user interface guidelines, so multi-window use is unintuitive and difficult.
Of course nothing in Mac Teams is nearly as bad as their incoming call notification - calls pop up under all your existing calendar/email/... notifications, which you have to furiously click away in order to answer the call.
That sounds ridiculously frustrating. Does Cmd + ` pull up the call? I'm guessing no since Teams go out of its way to make notifications un-native and clunky, but maybe worth a shot.
> Do you end up sending messages in the wrong chat often?
Yup. It’s probably my most frequent mistake (and can be embarrassing). I make the same mistake with messages.
What I have done to mitigate the issue, is give each workspace a different color theme. At least, it helps me to avoid crosstalk between organizations.
I’m not a “native slacker,” so I’m probably not a particularly good candidate for a focus group.
> What I have done to mitigate the issue, is give each workspace a different color theme. At least, it helps me to avoid crosstalk between organizations.
Ok yeah the different workspaces in one window is more of a pain than just different channels and chats in one window for me, at least the way it's done in Slack. I haven't felt that way on IRC, for whatever reason.
I just navigate Slack entirely by search and redirect all conversations to public channel as as much as possible, and I find that pretty natural. CTRL+K to navigate between convos and channels, CTRL+F to find things based on content (if I don't want to think about whether something was in a DM or a channel, and just go back to the same one).
On Macos Chrome you can still do hamburger menu -> More Tools -> Create Shortcut... and enable "open as window", and Chrome will create a .app file that, when you run it, opens that site as a PWA. Additionally it gets the favicon of the site by default as its app icon (you can change that) and then it shows up in the cmd-tab list as an app completely separate from Chrome. This works really nicely with Slack, especially if you're usually only in a few slack teams. Inside the PWA Chrome apps you can do cmd-N to create a new window if you want to see multiple channels / threads side-by-side from the same slack team. It's a great user experience and pretty much the only reason I keep Chrome around.
Thanks, that's interesting but I'm not so anti-Chrome that I'm going to use a "custom modified Firefox runtime" just for PWAs. I don't even use the above trick these days; I've gone back to just using Slack.app.
I'd love to have multiple windows. At some point in the last few months Slack broke the command-up/command-down shortcuts that would take you to the next conversation with an unread message -- if you restart it'll work for a short while and then break again. Having multiple windows would resolve this and other annoyances.
Oof, I feel like just one of those would be a deal breaker for most, but all those missing together makes it feel more like a proof of concept than anything else.
I would also expect the authors are going to have a hard time keeping up with Slack. One of Slack's goals in picking their architecture was to allow for experimentation, iteration, and expansion. Reverse-engineering an API inevitably means being behind. And given the number of engineers Slack has, it could well mean being further and further behind over time.
When you're building on someones platform, you take a risk. When you're actively integrating with a fast moving platform, you add more risk. When you build on a platform which doesn't want you there, you add even more.
When you're having to reverse engineer a platform to build something, you're asking for a special kind of hell.
Yes, it is used and developed. Just not very actively. Most importantly Shrugs does not yet support “XOXC” tokens, which are often required by company Slack installations. We are interested in adding this feature, but there is no timeline yet.
Ripcord survived C&D letters because it didn't charge. I feel bad for OP for putting all this work in, because it's really cool - but you're going to get sued.
I'm of the opinion that using unofficial clients for any online service should be a legal right (unless those unofficial clients cause harm to the respective service, but existing laws/regulations around that would already cover such cases). That doesn't mean the service has to specifically support the unofficial client, but they just can't intentionally block it (or forbid its use).
I am pretty certain that I can prove any client as harmful. I have been on the receiving end of apps misbehaving plenty of times, no matter which platform (JS, iOS, Android). And these were official apps with dedicated development teams.
Endless loops which flood you with API calls are a common issue, managing state is hard. Rate-limiting does not completely solve this.
Plus you can land in a situation where a user might associate bad experiences with an unofficial client with the actual service and thus leave with a bad impression overall.
This is the same argument AT&T used to forbid third party telephones on their network. It didn’t convince then, and it does not convince now. Tolerating third party clients should just be part of the cost of doing business and part of the design of robust protocols.
Doesn't your API have a problem if it can be misused that way? In other words, shouldn't your backend by default distrust the client using its API, no matter whether it's the official one or anything else? Even the official client can have bugs that bring down your backend.
it sucks that you could be sued if you are using a "public" api like this to write a client.
I would like to think that as long as you do not brand yourself as slack or violate any trademarks, you should be able to write an app like this. Things like email clients would fall into this category.
The point is it's not fair that Terms of Service can impose that restriction. Just like it wasn't fair when you were only allowed to use phones that you rented from your phone company.
Why isn't it fair? They run the service. What gives other people the right to tell them how to run it? If you don't like their terms, there are about 100 alternative projects you can use.
There are pretty clear, practical reasons you might want to control the client of a commercial network service.
Phone companies are different in that they were monopolies with special legal status. Slack, on the other hand, is just one of many private companies offering roughly equivalent services.
You can still argue your case, of course, but phone companies are a bad analogy here.
The phone company is the sole-source provider and you couldn't opt for another platform. The more relevant analogy is soda fountains in a restaurant - the provider chose Coke, but I want Pepsi. (My OSS founder wanted Slack, I want discord.)
That's a different medium, although I understand your point: Slack is the sole source provider of communicating on the Slack network. Personally, I don't think this is a problem or should be fixed because of how I see the tradeoffs and side effects. Similarly, I want Apple to run their own app store and not allow sideloading because I prefer the set of tradeoffs that come with that, versus the other reality.
The value of Slack Inc is their API, which is currently de-facto locked to their client. People would still pay for Slack if they could use alternative clients, because the client is not the value.
You can argue that their client is not as good as it could be, that you have greater skills to deliver a better product, etc. But it has value, otherwise we'd all be using curl to access the Slack API with no downsides. That's clearly not the case by far.
i do agree it's fair, but it's also true that the service provider could argue that they are supposed to be in total control of the service, including the front-end.
It's by societal consensus that this can be made fair, and to convince people that it is fair, there needs to be a logical, indisputable argument that it's fair. Otherwise, the service providers can always just hide behind the counter-argument of being in control and TOS etc.
In the case of Discord, for example, the terms of service doesn't even mention third-party clients. Also, these services are accessible from web browsers, which are made by third parties. There are more reasons, like users being able to run whatever they want on their own computers, but just the ones above are enough.
Ripcord isn't a derivative work, both practically and in the legal sense. It's implemented from scratch. Ripcord isn't a resell of their service or a sublicense of their service.
I assume your argument is that Slack has the "freedom of contract", the right to create and offer you contracts of their choosing (and you are free to accept or decline them). That right is not absolute. Workers rights limit it, sanctions limit it, cartel and competition laws limit it. There is no reason society can't agree to limit the options of keeping an API locked down in such contracts, especially for well established companies like Slack.
And I think the advantages of such a law are very clear: More competition on front-ends could very likely create much better user experience (better organization of chats, better message and image editor, better notifications, show users whether messages have actually been sent).
Laws are made to serve the public [1]. Being nice to companies is a means to an end, not the goal itself, and the discussion about whether API should be legally accessible to third party vendors (or devices/cars/… should be legally repairable by third party repair shops) should focus on whether we get better user experience, service, and so on, and have the question of whether companies will still want to offer backend-service like Slack under such a law as a facet.
[1] At least they should be and everybody complaints when they aren't.
IMO lawsuits are less of a concern than your end users getting banned, especially since slack is typically used for work. If your existing customers are loudly angry about you in public it's gonna make it hard to get new ones
I would be confused as to how an add-on service such as a premium Slack client would compete with Slack. It seems it would be complementing it and the use of the client would not compete but fundamentally cooperate with Slack as a service.
Sincere question: is an alternate app competing with Slack’s services? We pay for each user who uses Slack, whether it’s by phone, desktop, or web. The client is 100% free; the right to connect to their service is what costs money. Slack makes exactly the same whether I use their app or an alternative.
I’m definitely not a lawyer, but it’s not clear to me that this would violate the ToS.
You keep commenting one-line sentences without any argument supporting your sentence. You may even be right, but am I supposed to blindly trust you, a random commenter from the internet?
I mean, you don't have to. I appreciate the skepticism. I am the actual author of Ripcord. I've had an account here for many years. You will not find someone with better firsthand knowledge about Ripcord surviving or not surviving legal challenges.
I'd be interested to hear more about what sort of challenges you have faced, and if/how you responded to them, if you have the time.
Regardless of the upthread "well, just switch [your company/government/entire friend network] to an open/permissive service" non-answer, I think there's going to be ever-more need for unofficial clients for some of these services, and a big part of that is going to be how to avoid having them shut down immediately by service providers...
They are based in Germany. They would need to be sued in Germany. Germany has legal insurance where you can get insurance and it will cover your legal bills and liabilites. On top of that Germany has legal restrictions on how much a case can cost. Slack/Saleforce would not have much benefit in a legal challenge due to their size and legal costs. Furthermore, Slack would have to have a legal case. Which they most likely won't have.
I was trying to remember the name of ripcord while reading this. Thanks. I used it for a while for both slack and discord and it wasn’t bad. However they did sell licenses. I just don’t think they required them. I just double checked and I bought a $20 license for it. Good software and definitely worth it as far as I was concerned.
hopefully people at Slack are smart and they hire the dude
but since they spit buggy electron shit for decade already, i think you are right, they'll do everything possible to shut this down and keep with their inefficient and bloated electron way
I wouldn't be so sure. IRCCloud offers Slack connectivity (using Slack's API, not the IRC bridge that was closed long ago) and it costs money. I've used it for a couple of years now.
To be fair, I'd love to see a case like this brought to court. I'm not sure there's great precedent here. I think a case could be made that Slack was not harmed through this work.
I'd like to hear a lawyer (HN has several) corroborate this "Slack must articulate harm" claim, because there is a whole branch of civil law that exists to enforce contracts in the absence of torts; as I understand it, it's called "contract law".
This is true, and not all contracts are valid. It's why I'd love to see a good case brought. I feel like every time this happens the little guy just folds instead of doubling down.
But agree, would love to see some lawyers weigh in.
This is just wrong lol. Cancel has never received C&D orders for Ripcord, and it does charge $20 for the Slack features. Please don't spread misinformation you're not even informed correctly on, dude. If they were going to order a C&D order to Cancel, then they would've done it around the project's start (around 6ish years ago). Actually research this stuff before posting posts like these, plz.
> Over the years I've found writing on HackerNews, Reddit and other online sites has given me an outlet to get creative and engage with folks in a way that will shift discourse towards something I'm more interested in.
I regularly lie and pretend I know about topics and areas I have zero experience in. I began noticing I received more upvotes and engagement
Should clarify: the comment above me by @amedvednikov is referring to this comment chain's original poster -- @Mandatum -- not the parent or link submitter, and the post mentioned is: https://news.ycombinator.com/item?id=30838788
Ah, ok, I would call that a “submission” but it’s an “Ask HN” so I see where you came up with “post”.
Note that the submission page is sorted chronologically, not by karma. So the concept of “top” is really more like “first”.
It seems you meant to point out that @Mandatum admitted to lying but the way you phrased it really made it difficult to verify the claim and came across to me like you were accusing @jessefied123.
There were some very strong responses [1] to your accusation and I’m concerned that anger may be directed at the wrong person. When making these kinds of accusations you should try to be more clear. Use names and provide links. Also consider if the benefit of the accusation is worth the risk of misunderstanding.
Maybe I'm just jaded but as someone that used to be gungho about alternative, native clients like these. I've just given in and used the official clients. I'm tired of being the person who doesn't have specific feature or w/e.
Ripcord is great and I use it for Discord and Slack, but it is far from feature complete. Important to note that Ripcord is developed by one person. Some major things that are lacking:
* No search (Slack/Discord)
* No huddles in Slack
* Thread support in Discord
For these reasons, I typically navigate to Discord/Slack in the browser when I need access to those features. Not ideal, but the snappiness of Ripcord over the slow bloat of Slack/Discord make it worth it to me.
Ripcord has had search support in Slack for a while, it's under the Workspace menu. Otherwise, yeah. It's unfortunate to have to open the browser to do some of this stuff but the day-to-day experience of using it is great.
Agree to disagree. Selecting a channel in Slack takes like 300ms for me almost every time. There seems to be an inherent UI lag with Slack and Discord. Ripcord, on the other hand, is instantaneous.
Wholeheartedly agree that that's not acceptable performance, but blaming electron, which runs on chromium which is famously fast (despite its other issues) seems misguided.
To me it sounds like an artifact of architectural choices, eg by polling before rendering to avoid flicker, lack of client side caching, or possibly just bloat. Companies won't stop their poor software practices even if they switched to native.
The post I responded to mentioned the Electron; I was talking about the client performance in the browser, but I've had similar experiences with the Electron clients for Discord and Slack.
I don't doubt you can make a performant snappy chat GUI with Electron/web tech, but more often than not, in my experience, Qt apps (like Ripcord) perform much better and are less RAM hungry.
I use Ripcord to access Slack daily and it’s… very mediocre. It uses Qt, so it looks terrible (but at least it’s not a web browser). It’s more native than an electron app, but not by a lot. It doesn’t even use native scroll bars which can be really irritating at times. All images are thumbnail size and if you click to enlarge, it dumps you to the web, which slack.com just ignores. It logs you in and then doesn’t take you to the image or file you clicked on.
I don’t hate it (as much as I hate using Slack in a web browser or electron app), but I certainly don’t love it. I’ll be giving Shrugs a try, but it sounds like it’s missing a lot, too, so I’m not hopeful.
Video calls are somewhat involved, and no third-party implementation exists to my knowledge. Discord uses WebRTC over the browser, but the desktop app uses a native module written in C++ that I assume handles decoding, audio screensharing, and other related functionalities. It's not impossible of course, but the cognitive barrier is much higher than simply observing the WebSocket and HTTP requests to get text chat working.
Not necessarily, although this gets routinely brought up in the Ripcord Discord server. Ripcord essentially just uses the browser APIs, so it's not really different from opening Discord in Firefox.
That being said, Discord can ban people at random for whatever reason they choose, and this has happened before.
For the record, I've been using Ripcord with the same Discord account for 3 years, daily.
It's probably against their terms of service, so maybe. It probably depends on a combination of (over)zealous automation and whether they feel it's in their expedient interest to crack down on.
Their client exists almost entirely to collect data about you (chiefly what games you're playing and with whom.) That's one reason they are so quick to ban non-official-client users.
No way I would use this for internal company stuff. Is it safe? Probably. But it's not worth the risk to me personally unless the IT/management people agree to it first. At the company I work for (and I suspect many others) Slack is a treasure trove.
> We do not offer refunds. Please make sure that you can login into your Slacks and that the app works for you by using the free test version.
From my experience when someone says they don't offer refunds it's generally a sign that lots of people ask for their money back. I've not once dealt with a company that had a no refunds policy that was a good company to deal with.
I run a very small audio plugin company as a side-hustle/just for the love of it. Refunds through my payment platform cost me money. I offer a very generous trial (3 weeks unrestricted, nag screens after that). I think because of that no-one actually asks for refunds (or perhaps my plugins are good enough that everyone who buys is satisfied). I do offer refunds for accidental double purchases though (usually I'm the one who notices and pro-actively contacts the customer).
I understand that refunds cost money. I have a SaaS boilerplate (https://getparthenon.com) with a 30-day free trial and then still offer a 6-month refund policy (6-months if you pay for the year, the full currente month if you're paying monthly). Why? Because I believe in my product. I also don't want people to go around regretting buying it, if they try to make something it doesn't go well for them then they can have their money back. Also, not many people actually ask for refunds. So mostly, it's just a good policy to have that costs me very little.
> Also, not many people actually ask for refunds. So mostly, it's just a good policy to have that costs me very little.
Actually this is a very good point and I think I very well may reconsider my position, because since no-one actually ever asks for a refund perhaps it would "look" better if I didn't explicitly insist that there are "no refunds".
It has a free version you can use. I am not sure if refunds for software purchases is the norm. Does Microsoft offers Windows or office purchase refunds?
It has a free version that is limited to the #general room which would mean for my random communities I wouldn't be able to test this out on the generic happenings. Nevermind a full blown work slack.
> I am not sure if refunds for software purchases is the norm. Does Microsoft offers Windows or office purchase refunds?
It is indeed the norm in the indie hacker world which this developer and product is part of. I don't think I've saw a software product that didn't come with a X-days money back promise.
The demo version now actually supports multiple rooms (I think the 4 or 5 last you clicked).
The bigger issue usually is the lack of XOXC support (as the general API gateway lacks a lot of API features).
BTW: You can also get a refund. This is more to make sure that people actually try the thing before blindly buying something. Shrugs _does_ have limitations, so it's important to first test whether it fits the needs.
It’s an interesting start, but it’s missing some pretty vital features the official Slack client has.
I get how development works and I understand needing funding to support development, but I’ll be holding off on this until there is at least a much closer feature parity.
I suppose I’m getting too old to beta test daily driver software.
It’d be cool if there was a kind of “feature escrow”. You might pay $20 today, but $5 of that is held and paid to the developer once a specific feature you want is implemented.
There’s probably too much overhead to be useful, but it’d be an interesting way of prioritizing features.
it's an obscenity that somebody pasting one high frame rate GIF into a slack channel can cause a quad-core, tenth generation core i7 laptop CPU to peg itself at 85% usage and begin wasting battery, heating up, spinning fans, etc.
if somebody told me twenty years ago how powerful this CPU was, relative to what I was using at the time for a desktop PC, and that a chat application could pretty much max out the CPU and use multi gigs of RAM, I would have laughed...
> it's an obscenity that somebody pasting one high frame rate GIF into a slack channel can cause a quad-core, tenth generation core i7 laptop CPU to peg itself at 85% usage and begin wasting battery, heating up, spinning fans, etc.
There’s a setting to disable animated gifs. Which also disables party parrots and other animated crap emojis.
I also got tired of this especially when I wasn't even looking at Slack but it was not hidden, so it kept animating gifs and emoji etc that I can't see. Hammerspoon let me just disable them whenever I was on battery power:
It's not just high framerate stuff, it's pervasive.
Folks used to post walls of dancing bananas in phpBB and my Pentium III could handle that without breaking a sweat.
The exact same wall of dancing bananas makes any modern CPU jump to ridiculous two-digit usage relative to the task at hand.
I was also chatting over IRC from a Palm Pilot which had something on the order of 1MB of RAM, connected over RS232 to a GPRS phone, and the current experience of chat performance is basically on par with that, which boggles the mind given that I now have ten thousand times the RAM, an internet connection that can't be saturated in practice, and latency largely bound by the speed of light.
Slack's requirements are completely ludicrous in regard of what it's set to achieve.
> it'll be the same on every application.
Except, it's not. Counterexamples of chat apps with reasonable to stellar performance abound over the last two decades.
I think you'll notice the CPU cannot play 4K 60fps in GIF format. Maybe the problem is literally the format itself, which is terrible. It's too bad something like MPEG or some of the animated PNG / JPEG / WEBM formats never took off for meme-y animated images.
For a very long time (ive not checked recently) slack used more memory that my IDE on a multimillion line c++ project. I used to have to shut down slack to compile on a machine with 128GB ram.
It definitely has improved. It was clear from the memory usage vs community size that they were doing something that scaled with community size. This is a guess, but something like loading every single user and their profile icon into memory.
At least in my case, I once caught Slack.exe on windows using 40GB of RAM. (My machine had 32GB, so you can imagine how well things were running.) The allocated space seemed to have mostly been zeroes since the Windows Kernel was able to compress a bunch of the pages to avoid running out, but it was putting so much strain on things that audio playback was dropping out.
After trying microsoft teams, slack feels like a thing from the future.
But try using weechat+weeslack (+ url_hint, so that you can download urls and see images with a single shortcut) as one example of how I consider a chap app should feel.
I remember pidgin being in a similar ballpark, but I haven't used it in years.
It's a shame most other modern chat clients (ripcord, and most matrix clients) do not come even remotely close.
Well, it's a problem for me, though definitely less than it was, so I'm personally very happy that this exists. "voting with our wallets" might make Slack put it on the prio board.
Right now I'm using wee_slack.py which integrates weechat with slack; though with the obvious trade-offs.
I get the value of using native clients but the interface design would be a hurdle for me. For example, the message window has no visual hierarchy. The spacing between each message and the space between the username and message content are nearly the same with the font size being the same— just with a heavier weight. Without being able to easily visually separate each message into a block, it just looks like a bunch of lines of text when you first look at it. It's tough to see without looking for it, but the Slack client is fantastically visually parsable. It fits a whole lot of functionality in there with very little interface clutter.
One awesome UI feature of slack is that if you paste a url onto selected test it will automatically create a hyperlink. GitHub markdown does this too. Once you use, it is frustrating when clients don’t implement it. Looking at you, Jira.
I don't think slack bans clients. They even document their API…
I maintain an IRC gateway and have never been harassed (except by users using whatever strange distribution and being unable to figure out how to run the thing… they could just get debian but noooo)
Shrugs paying customer here - I emailed the devs about several significant bugs that were pretty much ignored. The client doesn’t support some important features, making it basically not useful as a daily driver.
It also has weird unread flagging behaviors that just drive you nuts.
> If you take more than a few minutes to think out how it works (I know, not popular for the typical HN poster)
Such a condescending remark. This kind of thing is not good PR for your company, product or workplace. Would I want to work with colleagues who publicly disparage a whole community like that? If you communicate like that publicly, how can I expect your internal work atmosphere to be?
I know you're probably an engineer at Slack and not in the PR department, but you may want to re-think your communication strategy. I know that my employer would have been unhappy with me for such a comment, and rightfully so.
Judging by other comments in this thread, folks have apparently thought out how it could work for "more than a few minutes", so not just the style but even the content of your message are clearly off. You are getting community feedback here and competent people are giving suggestions -- for free. Embrace that.
> There is nothing about Electron that constrains it to a single window, what a weird idea.
"Native" means both using the right UI toolkit and being a good citizen by supporting features that are table stakes for apps on the platform. Slack happens to do neither. Look, I understand that UI design is hard, but there's a lot of options that are better than "let's not do it at all". Shrugs has picked one and I think it's all the better for it.
From a UX perspective, it could be useful to have different windows with different recurrent/common conversations. I always interact with the same people and channels, and I find myself constantly Cmd-K to those convos. If I could have several chat windows, I'd just arrange them on my second monitor and have the top-3 laying out there, so I just rotate my head, focus on the right convo, type and submit.
Same as for reading, sometimes I just receive a quick message (like: "changes deployed"). I have to Cmd-K, losing focus of my current conversation just to switch to the other window and see that.
The UI would be the same except the tab would be fixed a specific conversation. Perhaps worth an experiment. I know the purist UX view would want to adapt it to then make the new tabs seamless and so on but I would expect most users just really want to have tabs per conversation or chat or thread and be able to cycle tabs instead of cycling conversations using shortcuts. You are discounting how much comfort the brain gets from a mental model you are used to, and the most common app for people to use is the web browser, which works with tabs for conceptual separation of topics, which is a great analog to different conversations or threads.
The commenter said they worked at Slack in the Desktop app team. He quoted the app page where it says that Shrugs.app supports multiple windows because it's a native app and said that nothing prevented Electron (or the official Slack app) to have multiple windows. It was just that they decided not to do it because of UX reasons.
As much as I hate the slack electron app, I'm not completely sure I have a need for a native Mac app also if its not the official client with full feature parity. Also, I don't want more windows please.
