You can do it in the desktop app as well. If you run it with SLACK_DEVELOPER_MENU=true in env vars, it'll enable you to right click to Inspect Element, open devtools and run this code snippet there
Alternatively, you can run `launchctl setenv SLACK_DEVELOPER_MENU true` and then the dev menu will work if you launch slack from anywhere, and will persist until you log out.
If you create the following plist in ~/Library/LaunchAgents, macOS will set that env variable every time you log in (except if you tell it to reopen windows when logging back in). Change "NAME.OF.FILE" to the plist's filename without the .plist extension.
@ihuman Is this really an "alternative"? To me it is a platform-specific "howto" (in that case, Mac OS X) that implements a platform-neutral recommendation (parent post).
I don't understand the point of electron for applications whose functionality is entirely dependent on being online anyway. At that point, just use a browser as it's one fewer item to install. Is the Electron version of Slack capable of anything beyond the browser version?
Specifically it makes it easier to get straight to the chat app.
I suppose I could use Hammerspoon to script hotkeys that jump straight to a Chrome tab with the right title, but that sounds like a lot more work than just binding a key combo to focus "Slack.app" (which is what I currently do).
You can do this already for slack in chromium browsers. Click Menu -> More Tools -> Create Shortcut. The app will run in an app window and NOT a tabbed browser window, just like a PWA, with it's own dock icon and cmd-tab icon.
Missing the point. I don't want it in my browser. My browser is used for reference materials and things like that. My chat app is its own separate thing and easily switched to.
You can do this already for slack in chromium browsers. Click Menu -> More Tools -> Create Shortcut. The app will run in an app window and NOT a tabbed browser window, just like a PWA, with it's own dock icon and cmd-tab icon.
You can do this already for slack in chromium browsers. Click Menu -> More Tools -> Create Shortcut. The app will run in an app window and NOT a tabbed browser window, just like a PWA, with it's own dock icon and cmd-tab icon.
> I don't understand the point of electron for applications whose functionality is entirely dependent on being online
I’ve made electron apps that load a website I have no control over and added features to it, including new styling, keyboard shortcuts, and command-line flags.
I would have built a native app, but documentation on making macOS app is awful while electron’s documentation is top notch.
You can include native code in Electron apps. I am not sure it is actually needed in any of the messaging Electron apps (Slack, Discord), but the capability is there.
My favorite Electron app is Balena Etcher. It is "dd" but uses 200MB of RAM. It is AMAZING.
> You can include native code in Electron apps. I am not sure it is actually needed in any of the messaging Electron apps (Slack, Discord), but the capability is there.
Discord has options for streaming your game to others, identifying running processes to display games as your status, downloading and launching games, and displaying a chat overlay on top of external game processes.
Some of those can be accomplished in a roundabout way without native code, but I think it's safe to say Discord benefits from that ability.
Seriously? I thought it was just a networking protocol. Can you please provide some examples so I can dig in further?
* streaming your game to others - I know that there are window capture APIs in browsers now, or at least in WebExtensions[0]. Then you stream the result over WebRTC, makes perfect sense to me.
* identifying running processes to display games as your status - Does WebRTC really have access to inspect running processes? That's horrifying.
* downloading and launching games - By downloading here I meant managing your installed games like an app store. They had everything from 2D games like Hollow Knight to open world 3D games that require a decent amount of horsepower like Saints Row. It looks like they've actually killed this feature, but either way I'm not really sure how WebRTC helps manage installed applications.
* displaying a chat overlay on top of external game processes - I can imagine how you'd accomplish this via WebRTC for games that expose an API to enable it, but rendering on top of an arbitrary game doesn't seem like something WebRTC allows.
Hmm, that doesn't seem totally fair - it's 'dd' but with guardrails so that schoolchildren who want to flash raspbian onto an SD card don't accidentally overwrite their boot disk.
slack tends to keep a process in the background that needs to be killed and restarted when you "close" it. did you run `pkill slack` or similar and then restart?
I've been struggling with the new editor for the past week or so. I finally sent this feedback to Slack today:
Hi there, when the WYSIWYG editor rolled out, I was pleased to see it could be disabled with the "Aa" button in the bottom right. I quickly realized it's not disabled, the toolbar is just hidden.
Here are the problems I run into:
1. Typing ``` and then pasting and typing it again (force of habit from *every other service that uses Markdown* including Slack up until this point), leaving me with an extra ``` inside my code block.
2. Typing >, pasting, and hitting enter too quickly that it doesn't seem to register. Or it registers for one line, but not the rest. Then I have to fix the rest. I'd prefer the old method of simply typing > in front of each line, consistently. But even when I try this, sometimes > doesn't get converted to quotes.
3. Typing :emoji_name: often times results in me typing the name too quickly, and, similar to the bad auto-selection of @-names, it chooses an emoji whose name I didn't type (even though I typed an emoji name exactly). Please just don't touch it until the full thing is parsed on send.
4. *foo*, _foo_, etc. -- again, I type very quickly (~158wpm when going my fastest) and these aren't getting converted. I'd expect if they don't get converted when I type it, they'd at least get converted on send. They don't.
Please give me a way to opt out of this or drastically improve it. Thank you.
I was disheartened to hear that Slack is adamant they will not allow this to be disabled:
Thank you for taking the time to write in and provide this feedback. I apologize for the disruption to your existing workflows. Our aim is to build an editor that works for all Slack users to better format their messages and clearly communicate in channels, regardless of their technical expertise. While we are taking all feedback on board, disabling the new formatting tool isn't an option that we will be offering.
We are committed to doing what we can to improve the new experience for you, and will continue to make improvements to the new editor. Thank you for sharing these specific examples as we're carefully reviewing all feedback and passing it over to our product team.
>Hi there, when the WYSIWYG editor rolled out, I was pleased to see it could be disabled with the "Aa" button in the bottom right. I quickly realized it's not disabled, the toolbar is just hidden.
>Here are the problems I run into:
>1. Typing ``` and then pasting and typing it again (force of habit from every other service that uses Markdown including Slack up until this point), leaving me with an extra ``` inside my code block.
>2. Typing >, pasting, and hitting enter too quickly that it doesn't seem to register. Or it registers for one line, but not the rest. Then I have to fix the rest. I'd prefer the old method of simply typing > in front of each line, consistently. But even when I try this, sometimes > doesn't get converted to quotes.
>3. Typing :emoji_name: often times results in me typing the name too quickly, and, similar to the bad auto-selection of @-names, it chooses an emoji whose name I didn't type (even though I typed an emoji name exactly). Please just don't touch it until the full thing is parsed on send.
>4. foo, _foo_, etc. -- again, I type very quickly (~158wpm when going my fastest) and these aren't getting converted. I'd expect if they don't get converted when I type it, they'd at least get converted on send. They don't.
>Please give me a way to opt out of this or drastically improve it. Thank you.
I was disheartened to hear that Slack is adamant they will not allow this to be disabled:
>Thank you for taking the time to write in and provide this feedback. I apologize for the disruption to your existing workflows. Our aim is to build an editor that works for all Slack users to better format their messages and clearly communicate in channels, regardless of their technical expertise. While we are taking all feedback on board, disabling the new formatting tool isn't an option that we will be offering.
>We are committed to doing what we can to improve the new experience for you, and will continue to make improvements to the new editor. Thank you for sharing these specific examples as we're carefully reviewing all feedback and passing it over to our product team.
Slack is extremely hostile towards user feedback. I sent them comments on what I believe to be a terrible feature and they also told me it will never be changed.
"extremely hostile" sounds hyperbolic. Unless you were somehow attacked, threatened, sent a C&D, or had an account disabled, they simply steamrolled over your opinions.
And they are far from the first consumer-facing company to deal with user backlash when a new feature came out. Facebook notoriously got an onslaught of negative opinions and sometimes press when a feature in the UI changed. The UI never caused any significant migration away from Facebook, only the privacy/surveillance concerns, vitriol, and the "embarrassed by my parents" un-cooling of the platform caused users to leave.
From what I read here and elsewhere about feedback from customer service, I suspect there is a push from management down to product to hit certain targets (I don't have visibility into Slack's internal metrics, but this is exactly how it presented in my previous company).
Yes. For instance, Apple's spent the last couple of years emulating his visionary design decisions, focused specifically on "get thinner and thinner until you can't actually do your job anymore".
Apple has spent the last couple of years focused on one thing that Jobs frequently pushed for, without stepping back and looking at the whole product in the manner I'd have expected from Jobs.
We'll never actually know unless someone finds a way to raise the dead, but I personally believe that Jobs would never have allowed those butterfly keyboards out the door.
Slack is an enterprise product. You aren't the guy who buys it, so what you think is irrelevant. They don't care anymore, user experience won't affect their bottom line unless it somehow becomes a Powerpoint bullet vs. some other enterprise competitor, which by definition is equally unconcerned about end-user opinions for the same reasons.
Atlassian is the same way now, providing any kind of feedback to them is equivalent to sending it to /dev/null.
The other thing here is the beauty of a SaaS model once you are an established player. Some product manager inside Slack or Atlassian can upend the user experience of millions of people almost instantly and they can't escape it - an origanization can't just decide to stay on an older version or roll back. Your only choice to drop a subscription for a service in use across your whole organization and which will require going through huge organizational inertia to change. It's ultimately bad for the SaaS companies as well since they never get any real feedback on how their product is perceived (subscription revenue is stable!) until their junk gets so bad that a new competitor without the baggage comes in and suddenly upends the market. Kind of like ... Slack, five years ago. It can happen fast.
If Slack thinks this, they are only 2-3 years from getting overtaken by a disruptor. I don't think they do.
How much sway angry emails have over actual usage is a different question. Facebook notoriously used analytics and A/B tests to decide if feature changes stayed, not angry complaint messages.
I think it's the product of popularity and the impact of the bug. Slack is exceedingly popular, so any change is going to come under a lot of scrutiny.
It is not clear to me how many new features Slack needs. Clearly people were able to successfully use the old text-entry UI; there was no shortage of Slack messages.
I feel like it would be better for them to focus on things that will add value to their platform without affecting people that are already using the core product. Meeting scheduling, corporate directory, video conferencing... nobody is in a better position to do that than them. And you can add those things, charge extra money for them, and not upset your existing customers.
Sometimes software is "done". The core of Slack is done.
hilariously and non-ironically i complained about this to my co-workers today. I was like yo did slack change their shit or am i going crazy? Now i'm on here seeing 800 comments and i'm laughing my butt off at how upset people are.
i get it, i typed a couple snippets already with backticks and it did weird stuff. took 5 minutes and guess what dont care
Chances are the people concerned enough by this change to write a strongly worded letter could immediately improve their performance by closing Slack for at least half their work day.
I think where they really messed up is how they've been responding to people about it. They're literally telling people that they'll listen to feedback but also that they won't change anything, all in the same response. The way they treat their customers is really going to hurt them in the long run, especially as other solutions come out (Microsoft Teams already has significantly more monthly users than Slack does).
There are browser plugins like Greasemonkey or Tampermonkey that manage these kind of patches.
I'm often removing some "functionality" of a website I visit often (e.g. removing annoying chat boxes)
There are also repositories of scripts like GreasyFork (https://greasyfork.org). I suggest that maybe your script could be ported to Tampermonkey instead of distributing it as a bookmarklet.
I personally don't mind the new WYSIWYG. Doesn't get in the way much at all really.
The only thing it's weird with I find is the code blocks, (previously 3 backticks, linebreak, code, linebreak, 3 backticks). Not a massive fan of how after 3 backticks it now puts an inline code format 'block', seems a bit weird.
The three backticks is what got me, I tend to paste blocks in and then put backticks around them, which is just broken now as it just inlines the first line and does nothing to the last line, I'll just disable it for now and set a reminder for sometime soon to see if they've fixed it
Good news, they're backpedaling. Just got this in a support request:
>We really appreciate your feedback, and we hear your frustration. We're sorry for the impact this is having on your ability to communicate with your team and on your overall productivity. We made a mistake by forcing everyone into this feature without providing an opt-out for customers like you: people for whom the existing behavior was working just fine.
>We've started working on a preference that will let you return to the previous message composer. We don't have a specific release date to share right now — it's this team's top and only priority, however, and we expect to have it available on the desktop within a couple of weeks, with Android following shortly thereafter.
>We will follow up with another note when this option is available to you, and we'll include instructions on how to enable it.
>Again, we're sorry for the disruption and we're grateful for the feedback. We missed the mark on this feature! We will do our best to learn from this and avoid similar mistakes in the future.
I can't tell if you think that's fast or slow. They're not just rolling back the feature; they have to add a new user preference, and replace the A/B test with the ability to run either way. Add in testing and such, and given Slack's scale, getting that released in a couple weeks sounds about right.
How hard would it be to run Slack in a special VM that brokered UI events from another application?
I.e. the latest Slack would be running in a VM that made everything seem normal to it, but in reality the UI input and output would be supplied by another application which was presenting a "Slack Classic" interface to the actual user.
Fenced blocks and `monospaced` stuff still behave frustratingly whether I have the "Aa" button toggled or not. I hate it -- wish they'd just add support for plain markdown as an option :(
And that's the heart of the issue. This is a "convenience" introduced to make markdown easier for people who didn't really use markdown, at the cost of adding a pain point for people who are heavy users of the markdown features.
Doing some security debugging on Slack desktop a year or so ago, I saw that you could easily open up a Chrome debugger port via CLI option to use with puppeteer/chromedp/etc. I haven't checked lately, but in theory it should be easy enough to connect to the debug port and run this short script to get the same benefit in the Electron app.
We really appreciate your feedback, and we hear your frustration.
We're sorry for the impact this is having on your ability to communicate with your team and on your overall productivity.
We made a mistake by forcing everyone into this feature without providing an opt-out for customers like you: people for whom the existing behavior was working just fine.
We've started working on a preference that will let you return to the previous message composer.
We don't have a specific release date to share right now — it's this team's top and only priority, however, and we expect to have it available on the desktop within a couple of weeks, with Android following shortly thereafter.
We will follow up with another note when this option is available to you, and we'll include instructions on how to enable it.
Again, we're sorry for the disruption and we're grateful for the feedback.
We missed the mark on this feature! We will do our best to learn from this and avoid similar mistakes in the future.
I'd imagine that once this "experiment" is rolled out to 100% of the user base and no longer an "experiment" they will remove the feature flag and the code for the old input box.
The fact that surrounding a word with tildes ~like so~ works in the initial message editor but not when editing a sent message is completely illogical.
