2776 points by ingve 2293 days ago | 1077 comments on HN
| Mild positive Editorial · v3.7· 2026-02-28 11:20:29 0
Summary Digital Autonomy Advocates
This blog post criticizes Slack's removal of user choice in input methods and advocates for freedom of choice in communication tools. The content exercises freedom of expression by publicly challenging corporate product decisions and demonstrating how such advocacy can influence policy change. The article's themes of user autonomy and freedom of choice align with principles of human dignity and freedom of expression in the UDHR.
It is infuriatingly terrible. A regression. So many times I've had similar woes with the code block and quote block mechanisms too.
Another truly bizarre feature I noted and sent a bug report about was that when adding an image to an "Action" the _minimum_ size requirement is 512px by 512px. For an image that is never rendered larger than 64x64.
Reading their non-replies on Twitter feels like I'm reading something specifically designed to piss me off. Smarmy apologies, low empathy, cocksure of how correct their vision of a chat service should be.
This one in particular[1]:
> The goal is for workflows to evolve, but we realize change can be a bit of a pain.
"Stupid peasant, we are only here to help you. Once you see the glorious vision we have you will thank us."
Amusingly, for https://riot.im we just shelved our WYSIWYG editor efforts after trying two completely separate implementations over the years (one via Draft.js, the other via Slate.js) because: a) it's a nightmare to get right, b) nobody used it anyway (it was optional), c) chat isn't a wordprocessor, d) markdown (commonmark) + floating formatting toolbar is good enough.
Our current editor was written from scratch (codenamed CIDER), and seems to work pretty well for markdown input + some semantic elements like prettified usernames, room names, etc.
At the risk of sounding like a shill, I'd like to shill Zulip. We started using it instead of Slack, and it has been amazing. It's fast, everything is designed to help you get to conversations quickly, keyboard accessibility is second to none and the streams is a much better default than rooms.
I can't recommend it enough, it's well worth the money even though they have a nice free tier and are OSS so you can self-host.
This is funny because I work across the street of Slack’s office in Vancouver, Canada and two Slack engineers who I frequently chat with during our daily commute already told me they —and a handful of other employees— hate the WYSIWYG input box too, but were afraid to express their feelings because their role is irrelevant compared to the people who made the decision to ship it.
The funny thing is that I am sure most of the people who work at slack know it's terrible, but no one asks them. There is a small cohort of product managers who probably have a plausible-sounding reason to do it, and they need to do something to justify their jobs, so they alienate everybody else because no one stops them.
I am, to put it lightly, familiar with this in other companies.
Specific bug gripes aside: I see this editor as emblematic of Slack's broader shift away from what I think it should be (primarily synchronous chat; irc with a friendlier ui and integrated bouncer features) towards what many people seem to want to use it as (async-heavy pseudo-replacement for email where I get to sit and watch the "...is typing" indicator flicker while somebody writes an essay at me).
My rule of thumb generally is: if I need significant rich text formatting in a message I'm writing, it should probably just be an email.
I feel like this increasing hybridization of sync/async comms is largely counterproductive and especially harmful to work-life balance, so it's unfortunate that companies like Slack are apparently unable to focus on core competencies and instead must shoot for disruptive growth via poorly-executed junk like this editor.
This reminds me of Atlassian's god-awful WYSIWYG editor.
In both cases, I get that some users can't or don't like to use a machine grammar/markup, however simple. For some people markup is bad UX. Give them a WYSIWYG; that's fine.
But don't remove the markup editor if your WYSIWYG editor is anything but a perfect one-two-one replacement for markup (and I have never seen one that satisfies that).
IIRC there was a time when Confluence axed their markup, and inevitably a table or a template would get completely screwed, and there was nothing you could do but recreate it. TERRIBLE design.
The exact same happened with the draft feature. The importance of habit forming UI is very well documented, going back at least as far as Jef Raskin's The Humane Interface and the draft feature completely breaks it -- if you as much as accidentally leave a character in there, you can't find the channel/DM at its normal place. Despite repeated calls to make it optional, nothing.
Threads are also broken, has always been. For example, if you get a notification in mail and it's in a thread, you can't jump to it, clicking the link dumps you into the channel and you are left wondering. Previously (as in, going back at least to '90 or so with IRC) you were able to skim the entirety of discussion in backscroll, now you'd need to open every thread on its own. As a senior developer, this was tremendously helpful to everyone because I could just skim a larger batch of discussions at a time and give some advice later as needed. Both of these problems could be solved if threads could be opened, you know, thread style into the channel. But... no. Also, if you answer in the special "threads" view then you will need to click the new answers link every time someone answers. It's terrible UX.
It used to be that adding a text snippet was right in the "add" menu you opened on the right hand side of the text, now it's in a submenu, seriously slowing down creating one. The menu wasn't getting large at all, no reason to do this.
It's very strange, they are the top dog, with immense inertia but it doesn't mean a younger, more eager, better UX, slimmer chat won't replace them. Digg to Reddit, remember? Until then, does anyone want to write a "Better Slack" collection of scripts injected into the app? I pledge 20 USD to fix these three problems, anyone else?
I've been suffering from this one too so I'll share the most annoying part for me. I frequently have reasons to type out glob patterns generally in backticks. The interface for this is completely broken in the new WYSIWYG editor. Here's what happens when I try to type: `/<asterisk>/<asterisk>`, things work normally up until the second "<asterisk>" at which point the "/" between them becomes gets bolded, which makes no sense, because you can't bold text inside of backticks. Then when I input the second "`" it becomes a monospace block containing `//` and the "<asterisk>"s have completely ceased to exist.
They also somehow broke the tab key for tabbing through users when you're trying to @ someone, after the first tab it just starts refocusing your input boxes rather than selecting different users.
Edit: Ironically, HN's built in markdown seems to understand asterisks, but not backticks, which leads to behavior similar to Slack's that I'm ranting about, I've replaced them with <asterisk> to make it clear.
I suppose a new acronym would be suitable for this situation: WYSIWYGBNWYW, What You See Is What You Get But Not What You Want.
With the availability of detailed API documentation (https://api.slack.com ) that seems to make it relatively easy to write your own client (and they even link to some thirdparty clients as an example of what you can do), their refusal to change could almost be interpreted as "no, you fix it".
If I had the need and time, I could probably write a native Win32 Slack client in a very short time; in fact I'm a bit surprised that one hasn't appeared yet because I was expecting that to happen. Maybe it will, if they keep messing around with the official client.
Slack’s old formatting syntax was Markdown-like but not exactly Markdown, just similar. In case anyone from Slack is paying attention to their technical users here, this is a great opportunity to move to CommonMark formatting for technical users and wysiwyg for non-technical users: just make this optional and switch the format syntax for the non-wysiwyg mode to CommonMark. I can understand that changing the formatting on people previously would have been disruptive, but that is no longer a viable excuse: you have already disrupted the lives of programmers far worse than changing to CommonMark would have done and switching markup formats won’t affect people who stay in wysiwyg mode at all. If you reintroduce Markdown mode now using CommonMark, programmers will just be happy that they can use Slack effectively again and as a bonus, you’ll match GitHub and everywhere else programmers hang out.
Regarding Slack’s attitude about technical users whose life this disrupts, I can see that the calculus may appear to favor the non-technical users: there are probably far more users who have no idea what Markdown is and never need to share code snippets on Slack and who are happy with the new wysiwyg editor since it’s closer to what they get from MS Word and Gmail. However, technical users have massively outsized influence over the choices of technology at most companies. The IT dept is full of technical users who share code fragments all the time. Don’t you think they’ll be keeping an eye out for new chat platforms after this change? Tech startups are (almost by definition) mostly technical users. Do you think any new tech startups will willingly use Slack after this change? Some of those would have been paying customers and a few of them would have become huge paying customers. Now they won’t. I know I’m actively looking for alternatives now and I have controlling influence over what gets used in several paying and non-paying Slack instances.
In their defence (not the defence of the WYSIWYG box itself) - they quite likely have done lots of user testing that has shown clear desirability, improved value to user, improved usability, etc etc.
You have to remember Slack's target persona is probably no longer the Engineer (If it ever was) - it's more likely a much less tech-savvy employee who finds WYSIWYG editors very handy to create rich text inputs.
I guess my point is - I'd wager this wasn't "rail roaded" through by some senior stakeholder that no-one can speak up too, but was probably a decision made by a product team who have the data to back up their decisions.
Now if the above isn't true (and perhaps the opposite is true) - then agreed, those are the signs it's time to leave.
I want to encourage everyone who doesn't like the WYSIWYG input box to use `/feedback` directly from within Slack to let the folks over there know about it. I believe this is one of those occasions in which tons of user feedback is crucial to at least make that awful thing optional.
This is not one of those "oh, that's annoying, i'll have to remember that and learn to work around it" issues. It's more like "I want to immediately stop using this software but have no choice". Its driving me crazy - Slack is all text input. Don't break text input dummy!
I have contacted them, and they replied me with this
Lucas (Slack)
Nov 20, 9:15 PM PST
Hi there,
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. If there are any specific examples of how these changes are impacting your daily work, please let me know. The more detail you can share about your experience, the better we can understand how to keep making it better.
Regards,
Lucas.
Anyone know how to reverse engineer Slack desktop client?
Did Slack ship a buggier version of this yesterday? I have it on one of my workspaces, and it's fine.
I can still type `backticks` in the editor, with the exact same combinations of keystrokes I used before, it's just that they render as they will on the channel, rather than showing me the backticks (and only when I type the closing backtick. GIF here: https://i.imgur.com/o3wPWN0.gif)
Triple backtick does the same, and I can easily type another triple backtick to exit the code block, same as before. It's literally identical ergonomics to the previous editor, except it's showing me the formatting I can expect.
I have to think that maybe they issued some hotfixes to the wysiwyg editor in the past 24 hours to some workspaces? Or people are just way too up in arms about something that has literally no impact other than maybe some wasted screen real estate showing formatting buttons...
Mattermost CEO here. In my mind Slack’s target persona is no longer an engineer (if it ever was) - It is more likely a less tech savvy person who wants a WYSIWYG editor for rich text inputs.
For what it’s worth, Mattermost is an open source alternative built for engineers by engineers. The interface is markdown.
Supposedly this feature is being walked back now. I just received the following from their support. I'm ecstatic to hear this and hope their Product Management has reassessed the importance of non-WYSIWYG inputs.
>>>
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.
Smells of bad UX/design process - some senior "wants" this particular solution, despite their users showing direct feedback that it doesn't work for their needs.
You know what else has a terrible WYSIWYG editor? Microsoft Teams. It's kind of sort of like Markdown, except when it isn't, or when it breaks. At least it's a step up from Lync.
On a high-density display, that 64px x 64px image covers a lot more surface area than 64x64 actual pixels on the physical display. I suspect that this 512x512px requirement is related to scaling factors on devices with high DPI displays.
I personally have no problem with the hybridization of sync/async communication. That's where everything is headed. People send emails and sometimes expect them to be delivered and/or read immediately. OTOH, people send messages over these "chat" services that aren't time sensitive, simply because it's easy and available.
My problem is that all these networks are proprietary and isolated. When someone comes up with a really bad idea in their UI, you're SOL until they decide to fix it. When someone comes up with a really good idea, you have to hope their competitors re-implement it. And all they can do is gently try to guide their network into the place they want to occupy on the sync-async spectrum via features.
Looking back at the history of computing, I see that when a protocol is open and has many competing implementations, it lives on far beyond what the original designers ever intended. When a protocol is proprietary and implemented only by a single proprietary UI, it has a fairly short lifespan. What I can't tell is if these companies don't know their history, or if they think they're going to be the first ones ever to beat this trend, or if they don't care and just want to grab money while they can.
All code sucks now, not just blocks. Inline code screws up at least half the time I use it; it tries to guess what I want, and sometimes doesn't end when I close it with another backtick. And, when going back and editing it sometimes carries the formatting outside of where I put the backticks.
So frustrating. I hate having to think every time I insert code and re-do it about half the time; I'd rather have no formatting (just show me the markdown as-is) than this mess.
Especially if you have a team of 1500 people. One person trying to make a browser WYSIWYG is bad enough; can you imagine how buggy it would be if 1500 people worked on it?
That's likely due to HiDPI displays. A regular display is probably in the 100 DPI range, but we have phones that are in the 400 DPI range, so that icon size suddenly isn't so big anymore.
Zulip looks great, but it also looks like the sort of thing I'd have trouble convincing everyone to switch over to because even though it might be more useful in the long term, in the short term its a bit more complicated (even though we're on the free slack, so we're looking to move elsewhere)
That style of communication where a corporate entity pretends to be friendly and concerned even as they're downright shutting you down is extremely annoying. It comes across as dishonest and condescending. I wish this type of PR would go away.
If someone who's reading this works in social media, here's what would have been less annoying:
- Saying "it's not possible right now, but you have a point and we'll reevaluate this" (even if it's a lie)
This new hive mind of corporations empathising with the poor common man needs to stop. It is outrageously frustrating, condescending and patronising. Every CS rep is trained to say “I understand” more often than they breathe. Corporate blog posts wax poetic about their understanding of the struggle of modern life in the first world. How sorry they are to be doing exactly the opposite of what somebody would do, who actually empathised.
I will be the first to admit to a temper, but honestly if I hear one more CS drone tell me how much they understand, I swear to god I will reach through that phone and quiz them on it. Do you really? Explain it to me. In detail. So help you God if you forget anything.
Ugh.
You know, say what you will about the mob; at least they don’t treat you like you’re three years old.
I'll just go ahead and admit to shilling. Zulip is amazing and I tried to get my company to switch to it. The only thing that stopped us from switching is well, the fact that people have to switch. They have to learn another tool, and Zulip sadly is not too friendly when you first start using it, though it's amazing for power users.
I literally believe it's the future of enterprise chat. There's no better tool for getting actual work done.
edit: I guess I should clarify about the shilling part. I contributed a single feature to zulip, once. So I guess I'm not really a shill, but I love the product.
This exchange is a pretty good summation of one of the biggest purely practical reasons why I'm so obsessive about tools, and why I'm so willing to put up with the initial cost of learning systems like Linux and Vim/Emacs.
Outside of fundamentally better workflow improvements, most professional fields don't randomly change their tools. If you gave a professional artist a new pencil that had to be gripped differently for no reason, they'd throw it in the trash.
But in software, we tolerate buggy tools that change all the time for no discernible reason. We tolerate software that simultaneously targets professionals and casual users, serving both segments poorly. We tolerate software that can't be customized or adapted for specific workflows. It's tough to put into words, but if you watch a musician or a painter interact with their tools, there's a very clear difference that emerges, and over time you start to realize how much better all of their stuff is.
In most professional artistic settings, workflow changes only happen because they have a clear benefit -- drawing from your shoulder instead of your wrist, changing your embouchure if you play an instrument. And even in those fields, it's generally accepted that over time people will end up with very specialized setups that are very consistent and refined and that remain constant for years and years.
Only in the software industry would someone tell me that my professional tools should change because change is inherently good. Only in commercial software would an elegant, consistent interface like Markdown that allowed me to build up decades of muscle memory until my computer was an extension of my fingers and I didn't need to think about the way I typed -- only in software would that be considered a bad thing.
I've had these exact same problems with Slack and every application that evolves and makes decisions for you. Usually they have the right idea, but sometimes they take decisions way too far and don't let us as users decide for ourselves.
I understand the concept of continual updates but these are some breaking changes and it scares me that they just show up overnight with no warning.
> IIRC there was a time when Confluence axed their markup, and inevitably a table or a template would get completely screwed, and there was nothing you could do but recreate it. TERRIBLE design.
There was. I was using Confluence at the time, and it broke a lot of things. There was a wonderful filed bug at the time with a lot of angry people on it, where they promised to bring the old mechanism back as an option, and they never did. That told me everything I needed to know about Atlassian.
The changing behaviour of enter/shift+enter in code block drives me absolutely crazy.
Normally, shift+enter is newline, enter is send. However, inside a code block, it's the opposite. I constantly forget this and press shift+enter for a newline while in the code block and accidentally send a half-finished message.
Sad to see the new WYSIWYG editor does exactly the same thing.
The next step that also seems to happen more often than not: Despite user outcry, the company digs in, becomes defensive, and dismisses complaints with platitudes or snark like “you’ll get over it”. See also: Slashdot redesign, Fark redesign, Reddit redesign, Digg redesign, and so on.
I actually love that drafts are brought to the top; it keeps things from getting lost for me. I even sometimes will write one character as a reminder I need to finish. But still, I understand your frustration.
That being said, search makes it really easy to solve this. I rarely do anything other than Cmd+K/Ctrl+K, and type a character or two. For me, it's become second nature, and I never find myself searching around for where to go. For me, the left sidebar is more of a status report, while Cmd+K is how I navigate.
I stopped using confluence the moment I realized the markdown editor was removed. I don't care so much about the flavor, but there's something very annoying about needing to get fancy with the way I edit text to preserve formatting.
I would bet a lot of money I already know the pitch. It's the same one that the Confluence PM I'm sure made. "We have done very well selling to technical programmers and hip startups, but the market is so much bigger. shows Office 365 revenue numbers vs Slack revenue numbers. We have an opportunity to take this to the next level. We need to make this the goto office communication platform. cheers. Markdown may seem easy to use to us, but our user research shows that 90% of fortune 500 employees don't even know what markdown is. We need a more familiar interface to break into this lucrative new market and continue our growth."
There's probably a degree of forward-compatibility intended with that requirement. Slack may only display the image at 64x64 (128x128 at 2x dpi) right now, but they want to avoid requiring you to upload a new image if, at some point in the future, they implement a UI with larger action images.
The draft feature positively boggles my mind. The intention seems to be to collect all your drafts into one location. But that comes with the assumption people will have multiple drafts for ... chat channels? Do people really work that way?
If the actual intention is to remind you you have a half written message, seems some kind of indicator on the channel would suffice. Having my channel “disappear” on me is maddening.
The article explicitly advocates for freedom of choice in communication and criticizes corporate removal of user options. It exercises freedom of expression by publicly critiquing a product and calling for accountability. The author states 'I wish Slack would provide a way to disable the WYSIWYG' and asks readers to share the post with Slack employees, demonstrating advocacy for freedom of expression and user agency in communication tools.
FW Ratio: 57%
Observable Facts
The article directly advocates: 'I wish Slack would provide a way to disable the WYSIWYG rich-text-input box.'
The author exercises freedom of expression by publishing detailed criticism of a corporate product decision.
The article explicitly calls on readers: 'If you know someone who works at Slack, please feel free to send them a link to this post.'
The update notes that the article influenced change: 'As of 2019-12-03, Slack has added an option to the browser version.'
Inferences
The article advocates for the user's freedom to choose their communication method, a fundamental dimension of freedom of expression.
The website's public accessibility and the article's widespread influence demonstrate how freedom of expression enables citizens to hold corporations accountable.
By criticizing forced interface changes, the author implicitly asserts that freedom of choice in communication tools is necessary for meaningful freedom of expression.
The article advocates for user autonomy and choice in communication tools, aligning with the preamble's principle of recognizing inherent dignity and agency in all persons.
FW Ratio: 50%
Observable Facts
The article states 'I wish Slack would provide a way to disable the WYSIWYG rich-text-input box,' directly advocating for user choice.
The author characterizes Slack's action: 'If you prefer the old interface… well, screw you, says Slack,' framing the removal of choice as disrespectful to user agency.
Inferences
The advocacy for user autonomy is implicit support for recognizing individuals' dignity and right to self-determination.
The article's framing suggests that removing user choice violates a principle of respect for individual agency.
The article mentions how the broken interface impacts work efficiency and forces users to adapt their work practices. The author states 'I'm already starting to reduce the amount of formatting I use on Slack... just so that I can maintain typing speed,' suggesting the tool undermines efficient work. This tangentially relates to the right to work under reasonable conditions.
FW Ratio: 50%
Observable Facts
The author describes work impact: 'I'm already starting to reduce the amount of formatting I use on Slack... just so that I can maintain typing speed.'
Inferences
The article implicitly advocates for work environments and tools that enable rather than impede productivity, relating to fair working conditions.
The blog enables free expression through public accessibility and open discussion. No barriers prevent the author from publishing criticism or readers from accessing it. The article's viral success and influence on Slack's policy demonstrates the practical value of the platform's support for freedom of expression.
The blog itself is freely accessible and allows the author to exercise free expression without barriers, demonstrating support for the preamble's principles.
The article mentions how the broken interface impacts work efficiency and forces users to adapt their work practices. The author states 'I'm already starting to reduce the amount of formatting I use on Slack... just so that I can maintain typing speed,' suggesting the tool undermines efficient work. This tangentially relates to the right to work under reasonable conditions.
build 1ad9551+j7zs · deployed 2026-03-02 09:09 UTC · evaluated 2026-03-02 10:41:39 UTC
Support HN HRCB
Each evaluation uses real API credits. HN HRCB runs on donations — no ads, no paywalls.
If you find it useful, please consider helping keep it running.
