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.

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
  <dict>
   <key>Label</key>
   <string>NAME.OF.FILE</string>
   <key>RunAtLoad</key>
   <true/>
   <key>ProgramArguments</key>
   <array>
    <string>sh</string>
    <string>-c</string>
    <string>launchctl setenv SLACK_DEVELOPER_MENU true</string>
   </array>
  </dict>
  </plist>

@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 wonder if the people who complain about Electron apps will refrain from doing this out of principle.

well, they can use the browser version and have this snippet working without any extra steps

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?

Some users prefer having a separate app with its own icon and window instead of another tab in a browser. It keeps things Separate

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.

Huh, that's incredibly useful. I'll have to keep that in mind!

You can just create a shortcut with a custom icon that opens slack in a new browser window then.

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.

This is all I want from an electron app, and is basically the main reason I really want PWAs to take off.

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.

That is all available in WebRTC.

> That is all available in WebRTC.

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.

[0]: https://chrome.google.com/webstore/detail/chrome-remote-desk...

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.

I think you can do that without involving Chromium, but I am not well-versed in the ways of full-stack enterprise-ready desktop apps.

> It is "dd" but uses 200MB of RAM. Say no more. I am sold.

Does it actually include any native code, or does it just wrap `dd`?

I tried this app and it was beyond awful. I went back to `dd`.

Apparently it uses some native code to get the necessary permissions on Windows: https://github.com/balena-io/etcher/blob/master/src/os/win32...

I like having a separate app as I can use the window class in X to manipulate which desktop it opens on without too much fucking about.

I think it can do screen sharing in calls, whereas the browser app can only do voice calls (and maybe video, I can't recall).

They could implement screen sharing in the browser version via webrtc.

This is incredible.

I set the env variable but I can't seem to get the access to devtools?

Only regular menu appears on right-click.

Try quitting Slack and just running this from the console.

It worked for me:

export SLACK_DEVELOPER_MENU=true

open /Applications/Slack.app

Instead of using open you can just run the binary inside Slack.app directory:

SLACK_DEVELOPER_MENU=true /Applications/Slack.app/Contents/MacOS/Slack

That's not a great idea. If you don't use open, the app won't show up in the Finder app switcher.

Good point! Thanks for mentioning that.

Small nitpick, though. The dock is what runs the app switcher, not the Finder.

That only works for the Bourne shell. Using `env` is more portable.

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?

good tip, thank you!

Same for me on macOS.

Try like this:

SLACK_DEVELOPER_MENU=true /Applications/Slack.app/Contents/MacOS/Slack

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.

For mobile users:

>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.

>For mobile users:

Damn near impossible to read on my 4k desktop monitor too. Is there a reason people are so insistent on using the monospace formatting for quotes?

I tried using a quote first, but the fact that you need to double-space between paragraphs, even when using the > symbol broke the formatting.

To avoid spending too much time figuring it out, I switched to blockquote. Sorry!

Good use case for a WYSIWYG editor!

I laughed. But perhaps instead for Hacker News to make `>` an actual formatting character?

Really frustrating seeing them repeat the "disrupting your workflow" bit.

It's not a "workflow" app, it's a chat app.

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).

Slack was being jerks telling everyone change is hard and to suck it up. Now, they backpeddled.

This is what hostility looks like. They think they know better than their users. They don’t.

This is what "opinionated" looks like.

Something something Steve Jobs

See, Steve Jobs could get away with this because he was exceptionally good at making the right choices, at least in the later part of his life.

When others try to emulate him, it doesn't go as well.

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.

Maybe if they start getting enough emails/tweets they will reconsider this...emailing them now...

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.

> what you think is irrelevant

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.

> they are only 2-3 years from getting overtaken by a disruptor

There are literally dozens to hundreds of cases that prove otherwise. Look at all the current tech giants...

I don't use slack so the issue isn't on my radar, but if this has made it to the top of HN.... I guess Slack reeeealy effed up.

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.

Nothing gold can stay

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

It’s a tempest in a teapot. Yes, the new editor is horrible. But at best it is a minor annoyance, and most users learn to work around it.

"Yes, the new editor is horrible. [...] most users learn to work around it."

What a time to be alive.

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.

Ya, reminds me of "bike shedding". People give disproportionate attention to trivial issues that it's easy to have an opinion about.

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

oooh so that's it! I could figure out the issue everyone was having with this.

Similar problem with quotes.

Seems weird, but I'll get used to 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.

> we expect to have it available on the desktop within a couple of weeks,

A couple of WEEKS???

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.

Wouldn't this make more sense as a tampermonkey / greasemonkey userscript?

That way it loads automatically when you visit slack, no need to repeat anything.

Disadvantage would be that you need a browser extension.

Shouldn't be hard to copy-paste the provided code into Tampermonkey.

Could be that some organizations disable browsers addons/extensions on their workers' browsers. Still, the option would be nice.

I'm not going to do this on every refresh. I predict the market/ecossytem for guerrilla browser extensions targeting technical Slack users hotting up.

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.

At that point, you might as well just use the slack API...

Isn't it the old functionality with the "Aa" toggle button? At least I don't have any problems with that after pressing it.

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 :(

Do you still have issues with monospaced and fenced blocks if you refresh Slack?

I tested and it was very buggy when I read the other HN thread this morning (I'm in Europe), but as of right now I can't reproduce the issues.

Ah, true. I rarely use any markdown so I didn't notice any difference :)

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.

Does html work? Why not use it instead?

No, HTML is not part of how you can format text in Slack.

HTML would also be a pretty verbose way to format text I'm typing out to coworkers, etc.

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.

You should be able to press Cmd+Shift+I and open the developer console.

Doesn't work for me, just opens the channel info window.

run slack with SLACK_DEVELOPER_MENU=1 and then right click and hit "inspect element"

Just got another note from them:

  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.

Thank you. It was kind of Broken. I copy pasted a text with code tags and it didn't recognized. Quite painful overall.

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.

This isn't working for me on Firefox 68 (I have a newer version on my other laptop I'll try out later).

I get CSP errors: `Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).`

I doubt it's something that can be fixed without writing a plugin / user script.

Kudos for figuring out how to disable it though!

I made a firefox/chrome extension based on this script.

  * Firefox Addon: https://addons.mozilla.org/en-US/firefox/addon/disable-slack-wysiwyg/
  * Chrome Extn: Pending Review
  * Source: https://github.com/pocc/no-wysiwyg

edit: formatting

I guess the fact that this is some absurd string-based-programming code is bonus entertainment. '[19] Bulk add experiment assignments to redux'!

This is the content I come here for. True hacker news.

Don't forget to complain using /feedback !

I for one love it.

That is all.

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.

Get ready for cease&desist from Slack: https://news.ycombinator.com/item?id=17869249

You can just toggle the old minimal input by clicking the first/third button from the right (Aa - Hide formatting).

The toggle only hides the UI, bad behaviour stays the same.

If slack made toggling off the UI also toggle off the behaviour, no one would be complaining.