I never had a problem with formatting code in slack until this release. And the hotkey (Shit+Cmd+C) doesn't work for me, although that might be my window manager interfering.
I guess they reach point where they are trying to improve something that was already good enough.
For me most annoying is that they removed setting that allowed me to configure to have up arrow to repeat the last command (like on IRC) this is very useful if you do ChatOps.
I've given up entirely on the Slack desktop app and use Ripcord exclusively. Much faster, more responsive and easier to use for 99% of my time spent on slack.
The speed difference between Ripcord and Slack is just night and day. I had forgotten applications can respond faster than I can type, yet here we are.
I'm pretty sure there are others in that list which are also standalone thirdparty clients, but clearly they would not be listing those on their own site and providing plenty of API docs if they forbid them.
Pah. Next you'll tell us that once Ripcord shows you some messages, its "N new messages in this chat" notification actually goes away. Now that would be a killer feature, if Slack managed to implement it.
Sadly they aren't going to implement some of my most used features from slack in ripcord so I stopped using it. Was ready to pay a ton of money to the dev as well.
My main complaint about Ripcord is that it's non-FOSS, which is somewhat concerning to me (the price is a non-issue; I'd be happy to pay the $20 if that comes with source code access). Sure, Slack itself ain't FOSS either, but I'm more inclined to make it as FOSS as possible (e.g. via Rambox or in an actual browser like Firefox) than to switch clients.
It also doesn't seem to acknowledge my starred channels; while the bookmarks are better anyway, those don't carry over to my phone or my other computers.
I just tested ripcord and it didn't seem to work very well on Gnome. Didn't do dpi scaling so it looked tiny on my main monitor and the notifications showed up pretty broken.
Gnome should probably have the correct DPI values, since it's a complete DE, but I'm guessing something has gone wrong with the way the Qt version that Ripcord uses is reading the DPI values.
It would be better if this always worked out-of-the-box 100% of the time, but Linux desktop environments are quite varied and it's hard to handle every case while also not limiting support to specific desktop environments and versions.
I just checked the screenshot. It reminds me of Windows 95.
What I feel like one app can't fit all. Some people want a faster response time rather than a modern design and vice-versa.
Talking about slack new input box.
The non-technical person would be more than happy with it. Because they don't know markdown and something that works like MS Word is good enough.
Not exactly the same thing but GChat used to have a mini drawing UI where you could send a quick doodle and it super useful. No one else seems to have picked up on it.
Yeah, I've always hoped they would change their position on supporting markdown. Their big report on it says they will never support it. Looks like this might be why.
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.
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'm not even sure why we refer to logical pixels (a.k.a. CSS pixels, etc.) anymore, for exactly the reason you mentioned. We should be saying things like "this only needs to be 512px x 512px because it's never rendered larger than two degrees of viewing angle" or something to that effect. But I guess that's hard to think about... ems could be a good compromise.
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.
The worst thing about it is how fucking easy it would be to fix. Just treat the backticks as characters when backspacing or navigating with the arrows, that way you can 'enter' or 'exit' a code block reliably, and all previous muscle memory from the markdown editor would carry over.
But no, apparently that's too hard for a company that's worth more dollars than the number of seconds any of us have been alive.
I think there's a battle between nerds and non-nerds, and maybe in between is the worst place to land. I know some of my projects' users complain a lot about the lack of a WYSIWYG editor in our forums and issue tracker (we use Markdown, displayed plain until previewed or saved). Some people hate it. But I would hate a standard WYSIWYG editor, so we just accept the hate. Every Markdown-ish WYSIWYG editor I've tried has sucked...so I don't know that it actually is easy to get right (if it is even possible, where is the good example?).
Slack serves a mix of nerds and non-nerds, with non-nerds becoming a bigger and bigger portion of their user base over time. I can only assume it will become less and less enjoyable for nerds in service to the goal of serving their growing non-nerd users. For my own projects, I don't foresee myself ever using Slack (I use it for work). It feels like a decent product getting worse with time as it tries to be all things to all people.
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.
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.
I definitely don't remember ever seeing or changing that setting, but it is 1000 times better with it off. Guess it's worth looking through an app's settings every once in a while, no matter how long you've been using it, just to see if there's anything new (or maybe forgotten) that would improve things for you.
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.
Another annoying and broken design decision: because I live in Japan the first link redirects me automatically to the Japanese version of the article. There is no option to choose the language, and manually changing the language-code in the URL still redirects me to the Japanese version. My browser is set to English and French as main languages...
Their stock has been decimated. Tempted to still short it at this price. Very clear it’s not much more than a feature that has quickly been commoditized.
If I type an inline `foo()` it converts to WYSIWG as soon as I type the closing back-tic and everything I type after is back in normal text mode. If I left-arrow to have the cursor inside the formatted div but before "f" and type "bar." I wind up with the expected effect `bar.foo()`.
It takes one extra arrow press to move the cursor beyond the invisible back-tic to shift from the inline code to plain text regions before or after the block.
I preferred the old input just because I don't like having content jump around while typing. I'd still rather hit the preview tab to see it rearrange itself.
I use Firefox and I've had nothing but trouble from the text box. It's just atrocious, I don't know why they'd do this when the previous box worked so well. At least make it an option!
> I think the only way to insert text at the beginning of a code span in the WYSIWYG editor is to highlight the first character of the span and type over it
This seems better than what I was doing: put the cursor after the first character, type the new beginning, add the same character and remove the same character from the beginning. Thanks for the tip!
It is pretty astonishing how much Slack was able to grow from their initial 2 years of being ahead of the curve in UX, despite being mediocre/bad on every other front since.
So if only 50% of the users have this, we should assume that it's only 50% done, and that by the time everyone has this thing, it will be perfect?
More seriously, while "this doesn't work right" is part of the complaint, the larger complaint is "this is fixing something that wasn't really broken." If Slack wanted to improve their editor, that'd be great, but they could have done that without losing what people liked about the old system. It's not like there's a lack of "quasi-WYSIWYG" Markdown editors out there to take cues from.
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."
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.
I'd push back on your last point; there's a zero-sum feedback process here that is invisible. You're seeing the negative feedback from a vocal set of minority power users; the positive feedback from people isn't going to be known or seen in anything other than usage metrics.
You say "users": how many, what percentage, what cohort..you get the idea.
How do you tell the difference between unpopular features and ones that are mostly liked? In both cases, only "a vocal set of minority power users" would say anything.
With the state of statistics literacy in this industry, "usage metrics" often mean whatever the person citing them want, with no malice or deception intended. Accidental, inadvertent p-hacking is shockingly common.
This attitude to their rollout reminds me of the recent rollout of Twitter's maligned new desktop UI, the new YouTube Studio Beta, and reddit's new UI.
There is almost a meme of online platform service providers not understanding their users and their workflows, and rolling out new revisions that hamper or outright remove functionality that those users rely on.
I guess the canonical example would be that one Digg redesign that nuked the whole platform, or Snapchat's redesign a year ago that stunted their growth.
Luckily, we haven't had to experience this at Hacker News thus far ;)
> There is almost a meme of online platform service providers not understanding their users and their workflows, and rolling out new revisions that hamper or outright remove functionality that those users rely on.
True, but there's also a meme of people screaming bloody murder over a redesign for a day, and then being fine with it, e.g. [0]. Some complaints are worth investigating and some are just who-moved-my-cheese griping that can and should be ignored. It can be tricky to tell which is which though.
> online platform service providers not understanding their users and their workflows
In regards to the Reddit redesign, I think the people complaining that "they ignore their users" are stuck inside a bit of a bubble.
I have a lot of friends who recently discovered the site, and they much prefer the redesign to the old one.
I forgot where I read it, but I vaguely remember stats backing this up, or at least increase in engagement or a reduction in churn for new users following the redesign.
Something like 50% of Reddit users are on mobile, for which the redesign is targeted (I believe)
Re: Slack, I know many non-techies who struggle with markdown and would welcome a WYSIWYG editor with open arms and wide smiles.
Exactly... You don't have to expire the old front-end, you can build a new front-end on top of the old API, maybe introduce a few new functions in the API to support both old and new.
What are they using reddit for, though? Serious question. You can probably find 10x-100x the number of people who would use a site just for amusing cat GIFs vs. a location for actual discussion, but the users of each are looking for fundamentally different things. Reddit built itself on being a text-forward group of forums. The new redesign is, frankly, a dark-pattern horrorshow designed for eyeballs at the expense of deeper engagement. They're keeping old.reddit around for a reason.
I really wouldn’t mind the new UI, if it weren’t this goddamn slow (it’s at the point of unusable right now). My choice of using the old UI isn’t even a choice at this point.
It can’t be for people on mobile: the UI is buggy (especially back and forth navigation) and constantly nagging to download the native app. That’s super annoying.
I say this as someone who doesn't mind the redesign on desktop: The redesign is a shitshow on mobile. It's slow and constantly nags you to install the app.
> Something like 50% of Reddit users are on mobile, for which the redesign is targeted (I believe)
The re-design just launched on mobile last week, while it has been on desktop for a very long time, so it is way too early to say what mobile users think. Personally I think that it is even worse on mobile.
It reads more to me like whoever they hire to run their twitter doesn't have the authority/knowledge to engage with complaints other than being nice and saying "I'll pass that on". This would be fine normally, but not really when they've shipped a feature that everyone hates.
I know. I try to give the social media people leeway since they're almost always just the messengers. This thread in particular just seemed laser targeted to aggravate me.
If you are taking a job with you are specifically being paid to be a human shield, I am not going to hold back from treating you like the face of the company you are. The more abuse these mercenaries take, the more the corp has to pay to staff them, and the more the owners feel the pain of their misdeeds.
Actually, the cmd/ctl-z advice is actually moderately useful. If you type it immediately after the closing formatting character it undoes the wysiwyg formatting. (I'm not arguing against a way to turn the wysiwyg input window off, however.)
Is there any way that tweet could have been written that would have satisfied you, without actually agreeing to change course right away?
To me the tweet's tone says that they honestly care and don't want people to be inconvenienced, but also want to at least see if people will warm to it.
There has to be some kind of healthy balance between listening to user feedback and never changing anything.
The extreme version of listening to user feedback is: https://xkcd.com/1172/
> Is there any way that tweet could have been written that would have satisfied you, without actually agreeing to change course right away?
Not passive-aggressively suggesting that the problem is with the user and not the tool. "The goal is for workflows to evolve" effectively means "this is how it's going to be, you'll have to adapt (even if it's worse for you)".
My workflows have thankfully "evolved" to use different tools. Zulip and Discord both still use markdown input, and I no longer use Slack for anything.
That's a surefire path to irrelevance. Nobody wants groupware. Nobody uses it unless forced.
On the bright side, that would leave a hole in the market for an enterprising chat developer to fill, hopefully with something less annoying and resource intensive.
> Nobody wants groupware. Nobody uses it unless forced.
Surely you're talking about some very specific crapware subset of groupware, because plenty of people choose to use, and very much enjoy using, all sorts of groupware. Distributed version control, issue trackers, simultaneous editing of documents... just to name a few examples of incredible groupware.
But yes, generally when it claims to do all the things, it does none well. This is orthogonal.
The problem isn't implementing the features, the problem is making the UX/UI intuitive to people who call Microsoft's tech support when Firefox displays a "cannot connect to internet" message because they unplugged their router because they needed the socket for something else.
IRC is objectively superior to slack as a distributed chat client, but goddamned if the first step into slack isn't significantly shallower than the first step into IRC.
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.
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.
And they are all scrambling to data mine every arbitrary slice of the data to make it look like the musical chairs of features somehow drove conversion and the lack of bottom line fiscal performance is some other department’s fault for handwavy reasons.
This is honestly a major contributor to the badness of software in general.
Ideal software would be continually fine-tuned and shrunk -- there'd be no bi-annual massive redesign, no change for change's sake alone. Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points, a well-run project would make something work well and then they'd leave well enough alone, focusing only on bugfixes, performance, and other "boring" projects that don't make for big press releases. Changes to working products should be as surgical and minimal as possible.
A good compensation structure that would prioritize stability and consistency would pay an ongoing royalty to the relevant technical people based on the product's performance, uptime, and minimal crash/bug occurrence. "Hours worked" would be minimally relevant. One wonders if so many people would be so desperate to desecrate their production infrastructure if a high-quality work product and compensation were actually correlated.
But because we can't break out of the assembly-line 40-hours-per-week mentality, we pay developers as if they're line workers, and there's always got to be something on the line to keep those worker bees buzzing, regardless of the aggregate negative impact of constant uncoordinated meddling in complex systems.
> Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points
This hits painfully home for me. I learned a few weeks ago that some of my coworkers did something akin to this. They were working on what was frankly a mostly-silly project to preserve the relevance of increasingly irrelevant internal tools. Once they had produced something working, they stopped. Then they re-implemented the whole thing in Rust.
Which few in the company know or use. There are no clear benefits to this except exciting resume points for the developer in question.
In 1995, Niklaus Wirth wrote "A Plea for Lean Software" - abstract "Software's girth has surpassed its functionality [..] The paper discusses some causes of "fat software" and considers the Oberon system whose primary goal was to show that software can be developed with a fraction of the memory capacity and processor power usually required, without sacrificing flexibility, functionality, or user convenience"
That was discussed on HN in 2014[1] and right in the top comments is "I think one factor that leads to bloated, ruined software was missed... I don't know how common it is overall, but I have personally seen it ruin several very good products. And that is the simple fact that employers want their employees to remain busy. If a piece of software reaches a point of exceptional quality - the developers working on it still have to fill 40 (likely more) hours a week to appease bosses. And so they do the only thing available - they ruin the product."
The crazy thing to me is that if they rolled out a native desktop app that was maybe a little bit lacking in features and used ~20MB RAM and had this particular misfeature in it and called it beta, people would applaud them for it, especially here on HN.
Instead they spent actual time, effort, and money making their product worse.
My company has certain deficiencies, but one of our core principals is that we'll never break a workflow, even if the workflow is dumb, even if the "feature" is actually a bug that an enterprising user abused in a way we didn't anticipate. The bad news is that we're saddled with a ton of legacy crap that can't be rewritten. The good news is that we've grown into one of those behemoths that dominates a niche specialized industry and won't be unseated by a product that is only, say, twice as good as ours. It's not as fun as iterating fast and breaking things, but the low stress is nice.
After this change I really want to develop a native chat application on Windows and OS X. I think it’s almost to the point where someone who did they could make a killing.
Your comment is a punch to the gut for me, I've been developing an internal CRM for two years that embodies many of the philosophies you describe. But while it is somewhat depressing, I'm left with questions about how bad it really is.
First, is it possible to develop software without inconveniencing business users with temporary (let's assume the ultimate products are better then the linux/vim/emacs they are superseding) regressions and inconveniences? And what is the cost in terms of time to route around such pitfalls? Would we still be able to have startups at all if products required thousands of hours of QA or perfect test suites in order to launch?
Second, if we were to set a hard rule 20 years ago that all software was to avoid this phenomenon during its development, what valuable tools and services would never have been developed at all? Would we still have Twitter? Reddit? Steam? Whatsapp? I don't have to dig far into the history of any of those tools to find near revolutions by their userbases over braindead UI or adversarial practices in the name of "vision".
I don't know, these are open questions. I just think avoiding all such frustrations you mentioned is wishful thinking and at some point it is just part of the process of experimentation and iteration. Or perhaps this process is entirely different in a small corp. versus a big corp. environment.
> Would we still have Twitter? Reddit? Steam? Whatsapp?
How many of those broke old workflows to introduce new ones with no clear benefits?
But that's not the point. We're not talking here about broad services like Reddit, Twitter, or Steam. We're talking about something more akin to a libary. You shouldn't break interfaces in a library without a strong, compelling reason.
Do things need to change eventually? Absolutely. Do they need to change today, because someone decided that the old workflows they don't like need to break for everyone? Maybe not. There's perhaps some room between the two.
It's been my experience that business software often represents a deep investment in a given workflow. Sometimes to the point where businesses are willing to spend a great deal of money to preserve those workflows and integrate new things into them - MuleSoft springs to mind.
Which is not to say that you're wrong. It's absolutely possible to develop new, improved software that's better in critical ways. Sometimes people and businesses are willing to put up with temporary regressions and inconveniences to gain substantial improvements. To use the above comparison, I've seen artists invest the time in learning how to draw all over again in order to jump from paper to digital.
What Slack has done is take away what was a perfectly functional workflow for many people. This doesn't look like a temporary regression or inconvenience. This looks like a permanent, hard break without substantial obvious benefits for people who used the old workflow. Communicating with users in a way that telegraphs very clearly that Slack doesn't care at all is just gilding the lily.
That's a place where the benefits of open source and hosting your own stuff pay off.
I can stay in older functional versions for a long time without being forced to upgrade and disrupt everyone's workflow because someone in a company thought they knew better how we should work.
Jenkins, Gitlab, rocketchat, review board all open source tools that you can be running years old ( on an isolated network please ) without upgrading and being very functional...
I'm not saying that all change should be avoided. I'm saying that all change is an annoyance to your users, all change has a cost. So if you do want to force your users to change, provide them with an escape hatch so professionals can avoid that, or be really certain that the change is genuinely making things better.
Imagine that every change you're making is like hitting your user in the face with a brick. If you're going to give me something amazing that makes my life better, I may let you hit me in the face with a brick so I can get it. But if you hit me in the face with a brick and then you give me something worse than what I had? Don't do that.
Learning the basics of Vim was a really big, hard change for me, but it was an adjustment to my workflow that was made for a specific reason, that made my life better and that made me more productive, and that (importantly) was a decision I made voluntarily. It was not change for its own sake.
> Would we still be able to have startups at all if products required thousands of hours of QA or perfect test suites in order to launch?
On the contrary, how many more interesting, better chat apps would we have if every one didn't feel the need to reinvent Markdown? Wouldn't it have been more useful if instead of rebuilding their editor for no reason at all, Slack's engineers instead added new API endpoints, or experimented with encryption, or added new search tools, or addressed any of the pain points that actually get raised by professionals using their product?
I would also push back against the idea that this is simply the cost of experimentation. Vim/Emacs are much more experimental editors than Word, yet even modern remixes of those editors like Spacemacs put more thought into user customization and consistency than Word does. Spacemacs' keybindings evolve -- but they never force you to accept that evolution if it would break something fundamental to your workflow. And Spacemacs is doing way more experimental, interesting stuff than Slack is.
To add further onto that idea, prioritizing future innovation over the productivity of real users is a very software-specific philosophy about how a professional field should work. New animation techniques come out all the time, but we don't look at people like Miyazaki and say, "that man is holding us back." It seems to be a software-specific scenario where a change is proposed, users say, "I don't like it", and then engineers get somehow upset about that fact, rather than just saying, "cool, it was an experiment. Let's revert and move on."
I did not get into programming because I love computer interfaces. For me, being treated like a professional means that a company makes me specifically more productive. I don't care if a change makes things better for someone else if that change is making it harder for me to do something I love. As a professional developer, it is OK to demand tools that work well for you. Again, this is the case for every other field -- no one expects a professional woodworker to switch to a new measuring system that they don't want to use, even if that system is popular with some people.
Of course no field gets this perfect, but virtually everyone gets it better than us. I'm not demanding a theoretical utopia I can only imagine. I'm looking at every other professional field and saying, "why can't we have the stuff that they have right now?" It's very much a feeling that's informed by how good it feels today to work with physical mediums as an artist, and how utterly crappy it feels by comparison to use Skype or Windows 10.
And if that means that software moves slower, who cares? It's not theoretical to me. Other mediums are better to work in -- so whatever they're doing, we should copy, because they're better than us.
Good clarification -- when I talk about change, I mean a workflow change. XKCD aside, I don't believe that every code change breaks someone's workflow, or at least I believe that some code changes break workflows in such a minimal way that none of your users will care.
To expand on your point, how many bugs and crashes do we tolerate in software simply because rebuilding features has priority over refining features or handling more edge-cases?
Slack's new interface isn't just different, it's buggier. Stuff like copy-paste is broken. So it's not just that we have to adapt to a new workflow, we're also accepting a lower-quality piece of software that is less reliable than what we had before. And in theory a refactor or rewrite might be so valuable that I could tolerate that, but I don't see that value here.
> First, is it possible to develop software without inconveniencing business users with temporary ... regressions and inconveniences?
The trick is to avoid introducing change without simultaneously introducing perceived value to the user. Predictability and reliability are incredibly important for business users, because they're going to build processes and documentation and training around however they interface with your system. This includes both directly interfacing with your system and creating supplementary processes outside of your system to work around deficiencies your system has in supporting whatever need they have. If you introduce change, you inherently reduce the temporary predictability and reliability of the system, and the friction created for end users needs to be perceived as worth whatever value your change provides. If they perceive a benefit to themselves, it'll incentivize them to embrace and adapt to the change. If they perceive it as a regression to their processes/needs, they'll fight it and it'll eventually lead to resentment and friction between the business users and the developers.
Slack's WYSIWYG input box is a prime example - it unlocks capabilities which is convenient from Slack's perspective, and is potentially generating value for users not familiar with Markdown and are used to traditional GUI-based rich-text editors. Helping them better support the type of corporate-wide adoptions that are lucrative for them. But due to Slack's origins, a large chunk of their user base prefers the older, Markdown-based editor and perceive a decrease in value from the change. If you're going to introduce changes such as this which will be perceived as a regression by a large enough subset of users, then you need to account for that in your change management process such that it isn't abrasively disruptive.
Another thing in Slack that has annoyingly changed (without an option to toggle off) is: its "Drafts" feature - where leaving a channel with an unfinished message means that the channel itself gets moved to the top of the left sidebar. This completely breaks my flow, because 1.) you can no longer use up/down hotkeys to reliably go between specific channels, and 2.) I frequently have to do a double take and ask, "where did that channel go?" - especially if you Star specific DM channels, because those go under the drafts section but above the rest of the channels, meaning the Drafts section is out of view most of the time.
Long ago I created a Chrome extension that reordered things nicely, but their CSS changes frequently which made it a maintenance hassle, and I read on HN another dev saying doing so is against their terms of service anyway. Not a fan of that anti-tinkering attitude.
SLACK: don't make dramatic changes to a user's workflow without giving a simple toggle to preserve old behavior.
I get it, most users probably love this feature. My wife does, for example, and she works at a big organization, which has different needs from my workplace. But even if dramatic changes to product are approved of by 75% of users, every time you do so, you create whiplash for the other 25%, and prevent many from ever loving your product. Rinse and repeat that whiplash too many times and product design rants on HN with 600+ upvotes will be a regular occurrence...
I use Slack very often, and I also get annoyed that Drafts features often tugs a frequently-used channel to a different spot in sidebar. "Where did that channel go?"
I am so glad you said this! It drives me mad. I think of the lists of users/channels in slack alphabetically so even now that I'm aware of the "drafts" change I still go through this shock every.damn.time.
If we embraced this philosophy none of us would be typing quickly on touch screen phones. Steve Jobs knew it beat a physical keyboard, and when pressed by people who complained about the new iPhone's touchscreen keyboard, he grinned and said "You'll get used to it." And oh boy, did they ever.
No, they didn't. They just stopped typing. Hence, bullshit UI's like Instagram.
> Steve Jobs knew it beat a physical keyboard
Yes, if by 'beat' you mean 'made it too expensive for general use'. But in general it was a huge blow to usability, productivity and general global intelligence.
But to that point, how many professional transcriptionists or programmers are using a touchscreen keyboard to do professional work now? Have we all switched over to touchscreen keyboards on our laptops yet?
Your mistake here is confusing a consumer device with something designed for a professional workflow. Touch screen keyboards are, objectively, not faster to type on than a physical QWERTY keyboard. It's like arguing that because my mom got used to a using a cellphone for photography that physical lenses are obsolete.
Again, this is (in my mind) something that mostly only happens in the software industry. A professional racer drives with a manual transmission. When automatic transmissions came out, nobody argued that professional racers were holding back the auto-industry. Meanwhile in the software industry, mention that your workflow benefits from corded headphones, and suddenly you're jeopardizing the future of progress.
Slack's voice is great when they're saying positive things, but God is it exhausting when they are replying to negative feedback. It's like listening to Ned Flanders, only with some extra patronizing emoji to rub it in
Did their engineering team not dogfood this change? What Slack engineer or product manager tried to share a `snippet of code` with a peer and thought, "yes, that was a pleasant experience. we should ship that."
lol product managers are such a bane for tech companies. they have to keep shipping features which no ones wants but they have to show they came up with and are shipping something. i think tech companies should try and avoid product managers and designers for as long as possible.
Users are to blame. There always has to be something new, even if its no better or even worse. It just has to change regularly or people think its stale and move on. We see this loads in phones where totally useless features like samsungs curved edge or foldable phones and the removal of loads of useful features.
There is this long-standing bug on mobile versions of slack where large swaths of messages just disappear. The only way to get them back is to sign out and sign back in. This is supposed to replace business email?
You know what largely replaced business email AND these crappy chat applications for us? GitHub issue threads. We do a very large part of our collaboration right next to the code now. Email & chat is now mostly to just asynchronously notify regarding one or more issue numbers. Managers, developers, everyone. If you want something discussed or handled, make an issue. It's got a single numeric identifier that's trivial to pass around, even to clients and end users. Labeling systems applied to issues can quickly turn a messy bucket into a well-oiled software factory. If you use GitHub, this is also a strong argument for a monorepo, as you could have 1 unique identifier for anything across the entire org scope that also links into your code contexts seamlessly.
The UX around GitHub must be incredible for non-developers, because I am watching project managers with zero engineering/coding background learn markdown syntax almost accidentally. In all of our time using GH issues as a collaboration tool, I have heard exactly ZERO complaints regarding anything being broken or unfriendly to use.
We now look back on Teams/Slack/Skype/Email usage as dark days. "How the hell did we ever get anything done?" is the usual take when one of us talks about it.
Know what's better than Github issues? A directory in the tree named Issues. Create files there. They all stay with the project. Append comments to them. Code snippets. What have you.
Github could have put all the issues into the same repository, and built on top of that for the sake of managers, but that would make projects too portable. Having important project metadata in their domain aids lock-in.
The OP said they felt the person should be reassigned. This is hardly a call for termination. It was also accompanied by constructive points about productivity software relevant to the post at hand. I do not believe there was anything unkind in suggesting that maybe the person was in over their head.
I agree it's much better than saying explicitly they should be fired or (as internet users often do) worse. Still, there's no need to get personal. Organizational failures are almost never one person's doing, and having an indignant thread sitting at #1 talking about how ugly your baby is is punishment already.
That's for them to decide, not for HN users to prescribe. Internet commenters underestimate the impact their personal comments have on the targeted person by at least 100x. It's just not nice.
It's unlikely that the person in question is reading this HN thread, but there's a chance that they are, and that means we should do better.
Here's the thing: maybe we don't owe "a lead at a company as high profile at Slack" any better, but we owe ourselves better in order to have a decent community. That's what https://news.ycombinator.com/newsguidelines.html is about.
I think this may have changed, very recently. Now when I paste any of the example strings in the post, I get an alert that I've pasted markdown, with options to apply formatting, or not ask again[1]. After that, it recommends using a new shortcut, (Cmd/Ctrl)+Shift+F[2].
Since moving companies, I have traded slack for microsoft teams.
Teams is pretty terrible in comparison, one of the most annoying "features" is it's WYSIWYG editor, I have no idea why slack would want to copy one of the worst elements about teams.
Teams is way worse than Slack. So's Facebook's Business Chat offering, which I find less horrible than Teams at least but it tags along with their "business social" application, and those are always useless crap.
Though it's been a year since I used Slack and from the look of things on here, they're trying their best to catch up in the bad-UX department. The drafts thing that moves channels around seems awful, too.
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.
So true, I was annoyed all day and didn't know why. Had no idea they had "upgraded". I thought I had inadvertently hit a toggle that put it out of adult mode. I was too busy to fuss with it. Every time I went into that box I came out a little more angry, a little older, and farther from the feeling of good flow that Wednesday typically brings.
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.
All I want is consistent syntax for links, italics, and bulleted lists, bonus points for numbered lists, bold, and code blocks. I don't want to have to click stuff when typing, and I don't want to remember keyboard shortcuts with subtle differences between different services.
Markdown is good enough, yet for some reason, each platform finds it necessary to do something slightly differently. I really don't care about a WYSIWIG editor, as long as I can use straight text if I want. Basically, I want Reddit comments in instant messaging and bug trackers.
That plus a nice table syntax. So many times I need to put a table in a jira comment or chat, but not often enough to remember how for the particular context.
It seems every text input box across the product line has a different input method: BB, Jira, and Confluence. You'd think they might standardize with one to be less user hostile.
Jira still has two different WYSIWYG implementations on different pages. On the "classic" issue form, you still enter `{code}this is code{code}`, but if you open that issue in the sidebar of the backlog page, it's Markdown.
Luckily I don't have.to use it anymore. It's 2+ years, but my memory wants to tell me that I hated it, because Confluence worked differently than JIRA.
We are using Gitlab now. It's much more limited than JIRA, but for what it does much more coder friendly.
On the topic of the text box, gitlab saves the content if I start typing, get distracted, go somewhere else and come back later. That's handy. Unfortunately there is some inconsistency that it doesn't work everwhere, was it so that in Wiki pages it didn't work?
I _so badly_ want Jira and Confluence to support just plain old markdown. Their editor is a nightmare; every programmer where I work hates it but all of management seems to love it.
Confluence used to have it. Or a similar syntax at least. They went WYSIWYG around 2010 or so. It was a dark day; I still remember the plaintive cries echoing from engineer cubes (we had whole cubes back then!).
The new Confluence they are rolling out is pretty good at converting Markdown to WYSIWYG on the fly. Not without glitches, of course, but I'm thoroughly impressed.
Not to even mention the annoying one-click-to-edit fields that lose your scroll position in the ticket and you cannot escape away. I'm furious every time this happens.
It can, but dealing with raw html, so white / black listing html tags is incredibly difficult and error prone.
I think it'd require whole team that'd maintain that and a lot of tests on different browsers cuz browsers try to "fix" html and it may vary between them, meanwhile it may lead to some bugs(probably)
I'd suggest to try stay away from html as hard as you can and use those cool *down parsers instead :P
This is my experience as well. Moving over to their new editor has left the markdown support in limbo between different views. I.e it varies between the view when creating an issue, editing an issue and commenting on an issue.. It's really infuriating. I asked them about it on Twitter and it's apparently a work in progress?
Oh man, Lync. The re-skin of MSN Messenger that nobody wanted.
I remember when I couldn't change my status from "Away" for some reason. On my computer it would always show me as "Online," but to everyone else I had been away for 300+ days.
Riot's CIDER is pretty much an internal codename though, and it's not split out (yet) for anyone else to use. So hopefully it's not too bad a namespace clash.
We chose ProseMirror after doing a lot of research (TinyMCE, Slate, Draft, Medium toolbar) and have been very happy with what it’s enabled us to do so far. We’ll probably write a blog post about it at some point.
It's even sadder because Org-Mode demonstrated how to do WYSIWYG right.
Apply the styling in real time, but then also show the formatting characters around it! That way you lose all of the weird WYSIWYG edge cases (will this character I type at the edge of a bold segment also be bold?), and you also teach WYSIWYG users Markdown in a natural way.
Ugh. No. This really breaks up the flow of the text.
I’m sure it’s fine for org-mode’s intended audience, but for people not from a coding background, it’s horrid. And there’s no need to “teach WYSIWYG users Markdown” when WYSIWYG is fine for them.
It could remove the Markdown once the message has been sent, and only show it in editing mode. Then readers wouldn't have their flow disturbed, and authors could edit their messages in a sane way.
No, it doesn't. It's just syntax highlighting for markup. Disappearing formatting characters, which is what I switched Org to myself, is another story - it has some of the problems introduced by WYSIWYG.
In my experience it doesn't particularly break up the flow of text. And as for "people not from a coding background", inline styling with visible formatting characters is exactly how Whatsapp implements its rich text editing. Considering it's an app with a billion and a half MAU, I think you might find that you have an unrealistically low opinion of non-developers' intelligence.
The fact that this industry turned to a proprietary low-quality solution like Slack when Riot/Matrix have already existed tells the full story about what a bunch of incompetent idiots we all are.
Everyone frustrated with the new Slack input box deserves what they got. Me included.
The reason for Slack's success is probably because it's a "turn key solution": you register your company, invite your employees, enter your CC, and you're good to go.
With a lot of these open solutions things are more complex. I think we should really focus on providing a good UX here if we want more adoption.
(also, I don't know if Riot is that much better; opening https://riot.im/app/ makes Firefox use 100% CPU and my laptops fan spin; I closed it after 10 seconds of just a loading animation)
https://modular.im gives a turnkey hosting solution for Riot/Matrix for what it’s worth.
Riot should be lighter weight than Slack, but launch (particularly if you haven’t used it in ages) can be slow, plus we’re chasing a startup perf regression on firefox atm. The main reason Riot’s better is that you can use your own server, participate in an open network, and have control over the software if some feature gets pushed out that you dislike. And you get E2E encryption :)
I think the messaging on modular.im could be a lot better, IMO. I don't know what the relations between all the different organisations/people are here, but having all of "Matrix", "Riot", "Modular" is just confusing branding/marketing. It would be much better to have just "Matrix protocol", "Matrix self-hosted", and "Matrix hosted", for example.
Right now, it's not even immediately clear that hosted Matrix is an option from just looking at the Riot and Matrix websites.
Just my 2c from a casually interested potential Modular customer.
It's true this is how a typical centralized commercial solution would be marketed. However, it's a bit trickier for Matrix since it's an open protocol with a neutral governing foundation and many client implementations.
Although New Vector (the company behind Modular) is currently driving most of the development of Matrix and Riot (the first and reference client), matrix.org itself is supposed to be a neutral network-related site. Notice the remark that it's controlled by the Matrix Foundation at the bottom of the page, and not New Vector.
That said, Riot does have a reference to Modular, but it's buried here: https://about.riot.im/free. I'd personally be fine with it being displayed somewhere more prominently (or at least under a more intuitive section name than "Free!"). I also think it would also be a good idea if the Riot page mentioned Matrix (or the Matrix logo) somewhere above the fold.
sorry, i think if a tech company can't maintain an install for something that is crucial , then it shouldnt be a tech company.perhaps it s a marketing shop or sth.
it's as if tech is delegating so much away that in the end there will be nobody left willing to actually do the tech
Maybe consider that we have literally hundreds of priority tasks, all of which are legitimately very important, and that while we can spend the time necessary to install and maintain non-turnkey solutions, we’d really prefer to work on one of the other priorities with that time.
There’s no such thing as general tech priorities, it’s just an amalgam of a bunch of individual priorities. In most of the cases I’ve seen those priorities are very reasonable. If you start a tech company and prioritize fiddling with internal messaging software over building your product, you’re going to fail. Prioritizing tech doesn’t mean yak shaving every random task, it means outsourcing as many non-essential tasks as you possibly can so that you have as much time and attention as possible for the one specific technical task that matters: building your product.
I don't think priorities shifted away from tech, they just moved up the value chain. Tech companies should focus their limited resources on building their core product, not managing "plumbing" like email servers or chat.
I can definitely maintain an install of whatever is needed. Why would I use time doing something that doesn't create value over and above just using a paid for solution?
I don't think it's sad; I've worked for a lot of small companies. Spending a few days learning and setting up tools is a lot of investment, never mind maintenance. I want to focus on creating business value, not "plumbing" like setting up chat tools.
Small companies sometimes turn in to large ones, but migrating from the tools everyone is used to is often not received well. There is a lot of inertia here.
> it's kinda sad that it has come to be that tech companies will consider installing matrix "complex".
I go to the Matrix website and there's a lot of "blah blah blah" about how it's an open network, a decentralized messaging protocol yada yada yada" Nothing about "how to actually start using the thing"
> More importantly, you don't need to get IT or Procurement involved to try slack.
Are you implying you do have to do so to try out Matrix? You can simply use the web version of Riot hosted here (https://riot.im/app) and sign up for a free account on matrix.org.
There's a link to this accessible from the "Try Matrix Now" page you referenced above. Admittedly, it seems the words inviting you to try Riot "on the web" were linked to https://matrix.org/docs/projects/client/riot instead of to https://riot.im/app/. That's probably a mistake and should be fixed.
You can create your own rooms (which are like IRC channels) which can be invite-only.
The counterpart to Slack workspaces/"servers" would be Matrix communities. They allow you to group a bunch of rooms and users together for discoverability. The feature exists today and is usable but still not as polished as one would hope for, but I think work on this is coming up soon.
In particular, I think better community front pages (describing the community, supplying related URLs and such) and access control (such the ability to restrict joins to community rooms to community members without having to invite each user to the room separately) are things that will be worked on.
to be fair, Slack predates Riot (and Riot has only got properly usable as a Slack replacement since hitting 1.0 in Feb this year).
But yes, very frustrating to see folks forced by a proprietary product to suck up something like the Slack editor change when there are FOSS options where you can just roll it back, set a config flag to get what you want, or worst case fork it.
There is a chicken-and-egg problem with matrix. It's clearly nice, but the more people use it, the easier it will become to install/maintain. That's how wordpress wins over commercial blogging platforms.
One thing i found it hard to do is integrate matrix with an existing database of users. It would be perfect for our community chat.
I'm going to take the opposite of this argument, and for bonafides, I run the product team for a 1000+ person company.
I'm going to assume that this thing was tested out the wazoo, both qualitatively and behind enough feature-flags and buckets to keep Optimizely in business for a year. So I have no doubt that this wasn't just a hunch on their part, but something that they meticulously tracked. If I'm wrong, definitely let me know.
Anyway, the main point, what percentage of people do we think knows markdown to such an extent where it's easier for them to use than a WYSIWYG editor would be? I'd venture on HN alone that number is <10%, and considering Slack is used by a far wider and less-savvy audience than on here, I don't have much of a problem with the reasoning behind the change.
I think the lack of backwards-compatibility is a legit criticism, and sure, an opt-out would be nice, but I don't think for a second that this is as egregious as people are making it out to be.
It's logical from a short-sighted perspective as I'm sure it looks good to investors to have a longer checklist of features. But shipping a broken feature is eroding customer trust.
Everyone that was using slack was clearly aware of backticks, underscores, and stars, which is really the most you need, and probably 99% of everything used.
Surrounding some text with these marks to achieve some formatting is hardly rocket science. If someone doesn’t do it it is really because they don’t want to understand.
If you however make an editor that fucks up using any of these marks? Well, that’s a big time failure.
Exactly, all the cool kids were using backticks, underscores and stars. Naturally the lesser users would figure it out just to fit in. Everyone feels mildly powerful being able to wield a tool like this as trivial as it is. Now we're all just back to being bottom feeding piker fish toiling away on word docs.
>Anyway, the main point, what percentage of people do we think knows markdown to such an extent where it's easier for them to use than a WYSIWYG editor would be?
Well, Slack supported so little of Markdown that this is a moot point.
I work with a bunch of non-tech people. I get what they're doing. The techy people are the only ones who bother using ` for anything. I have no idea if non-techies will start now that there's a button for it, but typing it is now really annoying for everyone who has been using it.
I kinda reminds me when Confluence added their WYSIWYG editor--or using Frontpage. I basically /had/ to go to code view to get the page to look consistent. So far Discourse has been my favorite implementation, with preview being off to the side. I'm sure that would eat up too much real estate for Slack.
As someone who runs the product team for a 1000+ person company, the concept of intransigent minorities should be of interest to you. [1]
The gist of it is that an intransigent minority can often dictate the choices of a flexible majority. It is unwise to make decisions based solely on majority rule, as stubborn minorities can affect complex systems in ways that you do not expect. The phenomenon can be verified in a variety of situations across history.
To put this into context for Slack, I believe technical users have been particularly important for the app. Tech users were early adopters for Slack - I'm sure a lot of corporate accounts started out with engineering teams. Tech users wrote the chat bots and integrations that Slack is known for. They got people to use Slack, and they can get people to stop using it.
Let's say you're changing the way a certain feature in your application works. The majority of users are happy or indifferent about the change (but weren't particularly bothered by the old behaviour). A minority of users not only reject the change, but are vocal in how much they hate it. They will not tolerate the new behaviour, and will try to get other users to abandon your product unless you resolve the situation. What do you do? You can ignore them for now, but can you predict the long term effects of turning your back to the intransigent minority?
And I'd add that inclusion is especially important for a tool that's supposed to connect everybody in the company. Thinking that one can ignore a chunk of the audience because they have no choice but to keep using your product is at best confused, and at worse displaying enormous arrogance. It's the sort of enterprise-grade nonsense that Slack was initially seen as an antidote to.
I get that things that want to be popular quite often shiv the early adopters as they become mainstream, as a) that particular orange has been well juiced, and b) satisfying early-adopter needs really can get in the way of that holy grail, maximizing revenue.
But here I don't think there's a big conflict. There are a bunch of ways this could have been done to make everybody happy. It could have been opt-in for a while and then opt out. Or as others point out, there are apparently good WYSIWYG experiences already out there. With a market cap of $12 billion, Slack could afford to buy one, or at least the team behind it.
The only explanation I see is that it was rushed out the door to meet some executive's goals. Which suggests that Slack is becoming the sort of clueless, sales-driven, user-contemptuous company the initially aimed to overthrow.
If they had all those metrics and that many test users, how could such obvious backtick issues exist?
Even simple dog-fooding by their own internal coding team should have revealed that issue.
If they had a test group, it was definitely a group that didn't use those features to begin with and basically didn't use them in the new UI either. Meticulously tracking the wrong sample group simply leads to reams of bad data.
1,115 comments
[ 3.0 ms ] story [ 382 ms ] threadI never had a problem with formatting code in slack until this release. And the hotkey (Shit+Cmd+C) doesn't work for me, although that might be my window manager interfering.
For me most annoying is that they removed setting that allowed me to configure to have up arrow to repeat the last command (like on IRC) this is very useful if you do ChatOps.
> Voice chat (Discord OK, Slack WIP)
It also lists this 'feature' which I think is hilarious:
> Not made from a web browser
Edit: Why am I being downvoted? https://old.reddit.com/r/discordapp/comments/8tukek/ripcord_...
https://api.slack.com/community
we find
"terminal-slack - Terminal client for Slack"
"Slacker - Simple Slack client for the CLI"
"scudcloud - Ubuntu client for Slack"
I'm pretty sure there are others in that list which are also standalone thirdparty clients, but clearly they would not be listing those on their own site and providing plenty of API docs if they forbid them.
"(D) attempt to reverse engineer or otherwise derive source code, trade secrets, or know-how of our APIs or Services;"
I'm pretty sure the voice feature is not part of the public API.
For me it was the video chat and voice chat though it seems he changed his tune on voice, as the last time I checked it was a 'Never'.
It also doesn't seem to acknowledge my starred channels; while the bookmarks are better anyway, those don't carry over to my phone or my other computers.
Gnome should probably have the correct DPI values, since it's a complete DE, but I'm guessing something has gone wrong with the way the Qt version that Ripcord uses is reading the DPI values.
Try something like:
It would be better if this always worked out-of-the-box 100% of the time, but Linux desktop environments are quite varied and it's hard to handle every case while also not limiting support to specific desktop environments and versions.Talking about slack new input box. The non-technical person would be more than happy with it. Because they don't know markdown and something that works like MS Word is good enough.
Especially proper list support is missing (ordered and unordered lists), also markdown links.
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.
> never rendered larger than 64x64
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.
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.
But no, apparently that's too hard for a company that's worth more dollars than the number of seconds any of us have been alive.
Slack serves a mix of nerds and non-nerds, with non-nerds becoming a bigger and bigger portion of their user base over time. I can only assume it will become less and less enjoyable for nerds in service to the goal of serving their growing non-nerd users. For my own projects, I don't foresee myself ever using Slack (I use it for work). It feels like a decent product getting worse with time as it tries to be all things to all people.
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.
When typing code with ```, Enter should not send the message. With this checked use ShiftEnter to send.
Might be an easy fix :)
I definitely don't remember ever seeing or changing that setting, but it is 1000 times better with it off. Guess it's worth looking through an app's settings every once in a while, no matter how long you've been using it, just to see if there's anything new (or maybe forgotten) that would improve things for you.
https://slack.com/help/articles/202288908-format-your-messag...
And
https://api.slack.com/changelog/2019-09-what-they-see-is-wha...
If I type an inline `foo()` it converts to WYSIWG as soon as I type the closing back-tic and everything I type after is back in normal text mode. If I left-arrow to have the cursor inside the formatted div but before "f" and type "bar." I wind up with the expected effect `bar.foo()`.
It takes one extra arrow press to move the cursor beyond the invisible back-tic to shift from the inline code to plain text regions before or after the block.
I preferred the old input just because I don't like having content jump around while typing. I'd still rather hit the preview tab to see it rearrange itself.
This seems better than what I was doing: put the cursor after the first character, type the new beginning, add the same character and remove the same character from the beginning. Thanks for the tip!
This seems like literally one bug.
More seriously, while "this doesn't work right" is part of the complaint, the larger complaint is "this is fixing something that wasn't really broken." If Slack wanted to improve their editor, that'd be great, but they could have done that without losing what people liked about the old system. It's not like there's a lack of "quasi-WYSIWYG" Markdown editors out there to take cues from.
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."
[1]: https://twitter.com/slackhq/status/1192147475672510474?s=21
You say "users": how many, what percentage, what cohort..you get the idea.
A bit like the teams editor, which was forced upon me and is absolutely horrendous.
Personally, I think the importance of not upsetting the established userbase far outweighs the probability of maybe growing that userbase a little.
Not to mention, unintentional threats.
There is almost a meme of online platform service providers not understanding their users and their workflows, and rolling out new revisions that hamper or outright remove functionality that those users rely on.
I guess the canonical example would be that one Digg redesign that nuked the whole platform, or Snapchat's redesign a year ago that stunted their growth.
Luckily, we haven't had to experience this at Hacker News thus far ;)
True, but there's also a meme of people screaming bloody murder over a redesign for a day, and then being fine with it, e.g. [0]. Some complaints are worth investigating and some are just who-moved-my-cheese griping that can and should be ignored. It can be tricky to tell which is which though.
[0]: https://theoatmeal.com/pl/state_web_winter/facebook_layout
In regards to the Reddit redesign, I think the people complaining that "they ignore their users" are stuck inside a bit of a bubble.
I have a lot of friends who recently discovered the site, and they much prefer the redesign to the old one.
I forgot where I read it, but I vaguely remember stats backing this up, or at least increase in engagement or a reduction in churn for new users following the redesign.
Something like 50% of Reddit users are on mobile, for which the redesign is targeted (I believe)
Re: Slack, I know many non-techies who struggle with markdown and would welcome a WYSIWYG editor with open arms and wide smiles.
The re-design just launched on mobile last week, while it has been on desktop for a very long time, so it is way too early to say what mobile users think. Personally I think that it is even worse on mobile.
This is the one that got me. Yeah thanks, I've been using text boxes since the 90s, I know how to undo.
Now we'll get to find out if _they_ know how to undo.
To me the tweet's tone says that they honestly care and don't want people to be inconvenienced, but also want to at least see if people will warm to it.
There has to be some kind of healthy balance between listening to user feedback and never changing anything. The extreme version of listening to user feedback is: https://xkcd.com/1172/
Not passive-aggressively suggesting that the problem is with the user and not the tool. "The goal is for workflows to evolve" effectively means "this is how it's going to be, you'll have to adapt (even if it's worse for you)".
My workflows have thankfully "evolved" to use different tools. Zulip and Discord both still use markdown input, and I no longer use Slack for anything.
On the web site they put it this way "Slack is the collaboration hub that brings the right people, information, and tools together to get work done."
[1] https://en.wikipedia.org/wiki/Collaborative_software
On the bright side, that would leave a hole in the market for an enterprising chat developer to fill, hopefully with something less annoying and resource intensive.
Surely you're talking about some very specific crapware subset of groupware, because plenty of people choose to use, and very much enjoy using, all sorts of groupware. Distributed version control, issue trackers, simultaneous editing of documents... just to name a few examples of incredible groupware.
But yes, generally when it claims to do all the things, it does none well. This is orthogonal.
Like one days work for 1 person?
IRC is objectively superior to slack as a distributed chat client, but goddamned if the first step into slack isn't significantly shallower than the first step into IRC.
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)
- Saying nothing
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.
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.
Translation: "we're paying all these engineers and product managers and they need something to do"
Ideal software would be continually fine-tuned and shrunk -- there'd be no bi-annual massive redesign, no change for change's sake alone. Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points, a well-run project would make something work well and then they'd leave well enough alone, focusing only on bugfixes, performance, and other "boring" projects that don't make for big press releases. Changes to working products should be as surgical and minimal as possible.
A good compensation structure that would prioritize stability and consistency would pay an ongoing royalty to the relevant technical people based on the product's performance, uptime, and minimal crash/bug occurrence. "Hours worked" would be minimally relevant. One wonders if so many people would be so desperate to desecrate their production infrastructure if a high-quality work product and compensation were actually correlated.
But because we can't break out of the assembly-line 40-hours-per-week mentality, we pay developers as if they're line workers, and there's always got to be something on the line to keep those worker bees buzzing, regardless of the aggregate negative impact of constant uncoordinated meddling in complex systems.
This hits painfully home for me. I learned a few weeks ago that some of my coworkers did something akin to this. They were working on what was frankly a mostly-silly project to preserve the relevance of increasingly irrelevant internal tools. Once they had produced something working, they stopped. Then they re-implemented the whole thing in Rust.
Which few in the company know or use. There are no clear benefits to this except exciting resume points for the developer in question.
That was discussed on HN in 2014[1] and right in the top comments is "I think one factor that leads to bloated, ruined software was missed... I don't know how common it is overall, but I have personally seen it ruin several very good products. And that is the simple fact that employers want their employees to remain busy. If a piece of software reaches a point of exceptional quality - the developers working on it still have to fill 40 (likely more) hours a week to appease bosses. And so they do the only thing available - they ruin the product."
[1] https://news.ycombinator.com/item?id=8301511
Instead they spent actual time, effort, and money making their product worse.
My company has certain deficiencies, but one of our core principals is that we'll never break a workflow, even if the workflow is dumb, even if the "feature" is actually a bug that an enterprising user abused in a way we didn't anticipate. The bad news is that we're saddled with a ton of legacy crap that can't be rewritten. The good news is that we've grown into one of those behemoths that dominates a niche specialized industry and won't be unseated by a product that is only, say, twice as good as ours. It's not as fun as iterating fast and breaking things, but the low stress is nice.
First, is it possible to develop software without inconveniencing business users with temporary (let's assume the ultimate products are better then the linux/vim/emacs they are superseding) regressions and inconveniences? And what is the cost in terms of time to route around such pitfalls? Would we still be able to have startups at all if products required thousands of hours of QA or perfect test suites in order to launch?
Second, if we were to set a hard rule 20 years ago that all software was to avoid this phenomenon during its development, what valuable tools and services would never have been developed at all? Would we still have Twitter? Reddit? Steam? Whatsapp? I don't have to dig far into the history of any of those tools to find near revolutions by their userbases over braindead UI or adversarial practices in the name of "vision".
I don't know, these are open questions. I just think avoiding all such frustrations you mentioned is wishful thinking and at some point it is just part of the process of experimentation and iteration. Or perhaps this process is entirely different in a small corp. versus a big corp. environment.
How many of those broke old workflows to introduce new ones with no clear benefits?
But that's not the point. We're not talking here about broad services like Reddit, Twitter, or Steam. We're talking about something more akin to a libary. You shouldn't break interfaces in a library without a strong, compelling reason.
Do things need to change eventually? Absolutely. Do they need to change today, because someone decided that the old workflows they don't like need to break for everyone? Maybe not. There's perhaps some room between the two.
It's been my experience that business software often represents a deep investment in a given workflow. Sometimes to the point where businesses are willing to spend a great deal of money to preserve those workflows and integrate new things into them - MuleSoft springs to mind.
Which is not to say that you're wrong. It's absolutely possible to develop new, improved software that's better in critical ways. Sometimes people and businesses are willing to put up with temporary regressions and inconveniences to gain substantial improvements. To use the above comparison, I've seen artists invest the time in learning how to draw all over again in order to jump from paper to digital.
What Slack has done is take away what was a perfectly functional workflow for many people. This doesn't look like a temporary regression or inconvenience. This looks like a permanent, hard break without substantial obvious benefits for people who used the old workflow. Communicating with users in a way that telegraphs very clearly that Slack doesn't care at all is just gilding the lily.
I can stay in older functional versions for a long time without being forced to upgrade and disrupt everyone's workflow because someone in a company thought they knew better how we should work.
Jenkins, Gitlab, rocketchat, review board all open source tools that you can be running years old ( on an isolated network please ) without upgrading and being very functional...
Imagine that every change you're making is like hitting your user in the face with a brick. If you're going to give me something amazing that makes my life better, I may let you hit me in the face with a brick so I can get it. But if you hit me in the face with a brick and then you give me something worse than what I had? Don't do that.
Learning the basics of Vim was a really big, hard change for me, but it was an adjustment to my workflow that was made for a specific reason, that made my life better and that made me more productive, and that (importantly) was a decision I made voluntarily. It was not change for its own sake.
> Would we still be able to have startups at all if products required thousands of hours of QA or perfect test suites in order to launch?
On the contrary, how many more interesting, better chat apps would we have if every one didn't feel the need to reinvent Markdown? Wouldn't it have been more useful if instead of rebuilding their editor for no reason at all, Slack's engineers instead added new API endpoints, or experimented with encryption, or added new search tools, or addressed any of the pain points that actually get raised by professionals using their product?
I would also push back against the idea that this is simply the cost of experimentation. Vim/Emacs are much more experimental editors than Word, yet even modern remixes of those editors like Spacemacs put more thought into user customization and consistency than Word does. Spacemacs' keybindings evolve -- but they never force you to accept that evolution if it would break something fundamental to your workflow. And Spacemacs is doing way more experimental, interesting stuff than Slack is.
To add further onto that idea, prioritizing future innovation over the productivity of real users is a very software-specific philosophy about how a professional field should work. New animation techniques come out all the time, but we don't look at people like Miyazaki and say, "that man is holding us back." It seems to be a software-specific scenario where a change is proposed, users say, "I don't like it", and then engineers get somehow upset about that fact, rather than just saying, "cool, it was an experiment. Let's revert and move on."
I did not get into programming because I love computer interfaces. For me, being treated like a professional means that a company makes me specifically more productive. I don't care if a change makes things better for someone else if that change is making it harder for me to do something I love. As a professional developer, it is OK to demand tools that work well for you. Again, this is the case for every other field -- no one expects a professional woodworker to switch to a new measuring system that they don't want to use, even if that system is popular with some people.
Of course no field gets this perfect, but virtually everyone gets it better than us. I'm not demanding a theoretical utopia I can only imagine. I'm looking at every other professional field and saying, "why can't we have the stuff that they have right now?" It's very much a feeling that's informed by how good it feels today to work with physical mediums as an artist, and how utterly crappy it feels by comparison to use Skype or Windows 10.
And if that means that software moves slower, who cares? It's not theoretical to me. Other mediums are better to work in -- so whatever they're doing, we should copy, because they're better than us.
Except for the changes like "reduce memory usage" or "fix crash when X happens" --- those are true improvements.
To expand on your point, how many bugs and crashes do we tolerate in software simply because rebuilding features has priority over refining features or handling more edge-cases?
Slack's new interface isn't just different, it's buggier. Stuff like copy-paste is broken. So it's not just that we have to adapt to a new workflow, we're also accepting a lower-quality piece of software that is less reliable than what we had before. And in theory a refactor or rewrite might be so valuable that I could tolerate that, but I don't see that value here.
The trick is to avoid introducing change without simultaneously introducing perceived value to the user. Predictability and reliability are incredibly important for business users, because they're going to build processes and documentation and training around however they interface with your system. This includes both directly interfacing with your system and creating supplementary processes outside of your system to work around deficiencies your system has in supporting whatever need they have. If you introduce change, you inherently reduce the temporary predictability and reliability of the system, and the friction created for end users needs to be perceived as worth whatever value your change provides. If they perceive a benefit to themselves, it'll incentivize them to embrace and adapt to the change. If they perceive it as a regression to their processes/needs, they'll fight it and it'll eventually lead to resentment and friction between the business users and the developers.
Slack's WYSIWYG input box is a prime example - it unlocks capabilities which is convenient from Slack's perspective, and is potentially generating value for users not familiar with Markdown and are used to traditional GUI-based rich-text editors. Helping them better support the type of corporate-wide adoptions that are lucrative for them. But due to Slack's origins, a large chunk of their user base prefers the older, Markdown-based editor and perceive a decrease in value from the change. If you're going to introduce changes such as this which will be perceived as a regression by a large enough subset of users, then you need to account for that in your change management process such that it isn't abrasively disruptive.
What happened to Digg? Myspace? UI isn't the only reason, but it's definitely a contributing factor in their demise.
The eBay story about changing the color of the banner should be followed for new features as well.
Long ago I created a Chrome extension that reordered things nicely, but their CSS changes frequently which made it a maintenance hassle, and I read on HN another dev saying doing so is against their terms of service anyway. Not a fan of that anti-tinkering attitude.
SLACK: don't make dramatic changes to a user's workflow without giving a simple toggle to preserve old behavior.
I get it, most users probably love this feature. My wife does, for example, and she works at a big organization, which has different needs from my workplace. But even if dramatic changes to product are approved of by 75% of users, every time you do so, you create whiplash for the other 25%, and prevent many from ever loving your product. Rinse and repeat that whiplash too many times and product design rants on HN with 600+ upvotes will be a regular occurrence...
Speaking of muscle memory, I still remember these … and — from the time when most web apps understood HTML. Too bad they stopped…
No, they didn't. They just stopped typing. Hence, bullshit UI's like Instagram.
> Steve Jobs knew it beat a physical keyboard
Yes, if by 'beat' you mean 'made it too expensive for general use'. But in general it was a huge blow to usability, productivity and general global intelligence.
I cannot wait until the MBP 2025 with the whole keyboard replaced by the touchbar..
Who needs tactile feedback?
Your mistake here is confusing a consumer device with something designed for a professional workflow. Touch screen keyboards are, objectively, not faster to type on than a physical QWERTY keyboard. It's like arguing that because my mom got used to a using a cellphone for photography that physical lenses are obsolete.
Again, this is (in my mind) something that mostly only happens in the software industry. A professional racer drives with a manual transmission. When automatic transmissions came out, nobody argued that professional racers were holding back the auto-industry. Meanwhile in the software industry, mention that your workflow benefits from corded headphones, and suddenly you're jeopardizing the future of progress.
How do you like this reply to tweet: https://twitter.com/qbixapps/status/1197332922807865344
A good product manager can make a world of difference.
The UX around GitHub must be incredible for non-developers, because I am watching project managers with zero engineering/coding background learn markdown syntax almost accidentally. In all of our time using GH issues as a collaboration tool, I have heard exactly ZERO complaints regarding anything being broken or unfriendly to use.
We now look back on Teams/Slack/Skype/Email usage as dark days. "How the hell did we ever get anything done?" is the usual take when one of us talks about it.
git grep finds them.
Github could have put all the issues into the same repository, and built on top of that for the sake of managers, but that would make projects too portable. Having important project metadata in their domain aids lock-in.
Productivity tools need to be very careful about radical change. Especially when the change won’t make anyone more productive.
It's hard enough for people to hear criticism or fix mistakes without their head, or a colleague's head, being called for.
The rest of the GP comment was fine.
It's unlikely that the person in question is reading this HN thread, but there's a chance that they are, and that means we should do better.
Here's the thing: maybe we don't owe "a lead at a company as high profile at Slack" any better, but we owe ourselves better in order to have a decent community. That's what https://news.ycombinator.com/newsguidelines.html is about.
Share and Enjoy.
Not the best improvement, not the worst.
1. https://i.imgur.com/QXHWMpF.png
2. https://i.imgur.com/Ksrjvf1.png
Though it's been a year since I used Slack and from the look of things on here, they're trying their best to catch up in the bad-UX department. The drafts thing that moves channels around seems awful, too.
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.
https://github.com/matrix-org/matrix-react-sdk/blob/develop/... tells all about CIDER, and https://blog.riot.im/riot-web-1-5/ gives the full context if anyone cares :)
Markdown is good enough, yet for some reason, each platform finds it necessary to do something slightly differently. I really don't care about a WYSIWIG editor, as long as I can use straight text if I want. Basically, I want Reddit comments in instant messaging and bug trackers.
It seems every text input box across the product line has a different input method: BB, Jira, and Confluence. You'd think they might standardize with one to be less user hostile.
We are using Gitlab now. It's much more limited than JIRA, but for what it does much more coder friendly.
On the topic of the text box, gitlab saves the content if I start typing, get distracted, go somewhere else and come back later. That's handy. Unfortunately there is some inconsistency that it doesn't work everwhere, was it so that in Wiki pages it didn't work?
So, markdown?
Every website has its own flavor of it. Just reading some of the answers around here you can read "to do markdown better we made our own markdown".
Maybe because it is shitty. Just let users use HTML.
I think it'd require whole team that'd maintain that and a lot of tests on different browsers cuz browsers try to "fix" html and it may vary between them, meanwhile it may lead to some bugs(probably)
I'd suggest to try stay away from html as hard as you can and use those cool *down parsers instead :P
I remember when I couldn't change my status from "Away" for some reason. On my computer it would always show me as "Online," but to everyone else I had been away for 300+ days.
https://github.com/clojure-emacs/cider
It likely doesn't as they seem unlikely to be confused.
Riot's CIDER is pretty much an internal codename though, and it's not split out (yet) for anyone else to use. So hopefully it's not too bad a namespace clash.
I've heard good things about it and it seems to have a decent implementation for hybrid WYSIWYG + Markdown.
https://prosemirror.net/examples/markdown/
We chose ProseMirror after doing a lot of research (TinyMCE, Slate, Draft, Medium toolbar) and have been very happy with what it’s enabled us to do so far. We’ll probably write a blog post about it at some point.
I looked through all of the links in the original post and couldn't really find any mentions of specific limitations.
Just trying to learn more about this space.
Apply the styling in real time, but then also show the formatting characters around it! That way you lose all of the weird WYSIWYG edge cases (will this character I type at the edge of a bold segment also be bold?), and you also teach WYSIWYG users Markdown in a natural way.
I’m sure it’s fine for org-mode’s intended audience, but for people not from a coding background, it’s horrid. And there’s no need to “teach WYSIWYG users Markdown” when WYSIWYG is fine for them.
Everyone frustrated with the new Slack input box deserves what they got. Me included.
I for one am showing the middle finger here; when forced to talk on Slack, I use Ripcord as a client.
With a lot of these open solutions things are more complex. I think we should really focus on providing a good UX here if we want more adoption.
(also, I don't know if Riot is that much better; opening https://riot.im/app/ makes Firefox use 100% CPU and my laptops fan spin; I closed it after 10 seconds of just a loading animation)
Riot should be lighter weight than Slack, but launch (particularly if you haven’t used it in ages) can be slow, plus we’re chasing a startup perf regression on firefox atm. The main reason Riot’s better is that you can use your own server, participate in an open network, and have control over the software if some feature gets pushed out that you dislike. And you get E2E encryption :)
I think the messaging on modular.im could be a lot better, IMO. I don't know what the relations between all the different organisations/people are here, but having all of "Matrix", "Riot", "Modular" is just confusing branding/marketing. It would be much better to have just "Matrix protocol", "Matrix self-hosted", and "Matrix hosted", for example.
Right now, it's not even immediately clear that hosted Matrix is an option from just looking at the Riot and Matrix websites.
Just my 2c from a casually interested potential Modular customer.
Although New Vector (the company behind Modular) is currently driving most of the development of Matrix and Riot (the first and reference client), matrix.org itself is supposed to be a neutral network-related site. Notice the remark that it's controlled by the Matrix Foundation at the bottom of the page, and not New Vector.
That said, Riot does have a reference to Modular, but it's buried here: https://about.riot.im/free. I'd personally be fine with it being displayed somewhere more prominently (or at least under a more intuitive section name than "Free!"). I also think it would also be a good idea if the Riot page mentioned Matrix (or the Matrix logo) somewhere above the fold.
it's kinda sad that it has come to be that tech companies will consider installing matrix "complex".
FLOSS software needs hosted, supported, reasonably priced versions with security updates to be competitive.
it's as if tech is delegating so much away that in the end there will be nobody left willing to actually do the tech
Small companies sometimes turn in to large ones, but migrating from the tools everyone is used to is often not received well. There is a lot of inertia here.
I go to the Matrix website and there's a lot of "blah blah blah" about how it's an open network, a decentralized messaging protocol yada yada yada" Nothing about "how to actually start using the thing"
Then you get here finally https://matrix.org/docs/projects/try-matrix-now/
> To get started using Matrix, pick a client and join #matrix:matrix.org. You can also check the Matrix Clients Matrix to see more detail.
Or then there's this which looks more like it: https://matrix.org/docs/guides/introduction/
Compare this with going to Slack's web page and clicking "Try Slack".
More importantly, you don't need to get IT or Procurement involved to try slack.
Are you implying you do have to do so to try out Matrix? You can simply use the web version of Riot hosted here (https://riot.im/app) and sign up for a free account on matrix.org.
There's a link to this accessible from the "Try Matrix Now" page you referenced above. Admittedly, it seems the words inviting you to try Riot "on the web" were linked to https://matrix.org/docs/projects/client/riot instead of to https://riot.im/app/. That's probably a mistake and should be fixed.
But when you try the Riot app on a Matrix server, can you create you own private workspace there or it's more like an IRC channel?
Because Slack let you have your own workspace/"server" in the free plan https://slack.com/intl/en-ie/pricing/free?geocode=en-ie&from... (you'll have some limits, but you get your own private space)
The counterpart to Slack workspaces/"servers" would be Matrix communities. They allow you to group a bunch of rooms and users together for discoverability. The feature exists today and is usable but still not as polished as one would hope for, but I think work on this is coming up soon.
In particular, I think better community front pages (describing the community, supplying related URLs and such) and access control (such the ability to restrict joins to community rooms to community members without having to invite each user to the room separately) are things that will be worked on.
But yes, very frustrating to see folks forced by a proprietary product to suck up something like the Slack editor change when there are FOSS options where you can just roll it back, set a config flag to get what you want, or worst case fork it.
One thing i found it hard to do is integrate matrix with an existing database of users. It would be perfect for our community chat.
Anyway, the main point, what percentage of people do we think knows markdown to such an extent where it's easier for them to use than a WYSIWYG editor would be? I'd venture on HN alone that number is <10%, and considering Slack is used by a far wider and less-savvy audience than on here, I don't have much of a problem with the reasoning behind the change.
I think the lack of backwards-compatibility is a legit criticism, and sure, an opt-out would be nice, but I don't think for a second that this is as egregious as people are making it out to be.
Surrounding some text with these marks to achieve some formatting is hardly rocket science. If someone doesn’t do it it is really because they don’t want to understand.
If you however make an editor that fucks up using any of these marks? Well, that’s a big time failure.
Well, Slack supported so little of Markdown that this is a moot point.
I kinda reminds me when Confluence added their WYSIWYG editor--or using Frontpage. I basically /had/ to go to code view to get the page to look consistent. So far Discourse has been my favorite implementation, with preview being off to the side. I'm sure that would eat up too much real estate for Slack.
The gist of it is that an intransigent minority can often dictate the choices of a flexible majority. It is unwise to make decisions based solely on majority rule, as stubborn minorities can affect complex systems in ways that you do not expect. The phenomenon can be verified in a variety of situations across history.
To put this into context for Slack, I believe technical users have been particularly important for the app. Tech users were early adopters for Slack - I'm sure a lot of corporate accounts started out with engineering teams. Tech users wrote the chat bots and integrations that Slack is known for. They got people to use Slack, and they can get people to stop using it.
Let's say you're changing the way a certain feature in your application works. The majority of users are happy or indifferent about the change (but weren't particularly bothered by the old behaviour). A minority of users not only reject the change, but are vocal in how much they hate it. They will not tolerate the new behaviour, and will try to get other users to abandon your product unless you resolve the situation. What do you do? You can ignore them for now, but can you predict the long term effects of turning your back to the intransigent minority?
1. https://medium.com/incerto/the-most-intolerant-wins-the-dict...
I get that things that want to be popular quite often shiv the early adopters as they become mainstream, as a) that particular orange has been well juiced, and b) satisfying early-adopter needs really can get in the way of that holy grail, maximizing revenue.
But here I don't think there's a big conflict. There are a bunch of ways this could have been done to make everybody happy. It could have been opt-in for a while and then opt out. Or as others point out, there are apparently good WYSIWYG experiences already out there. With a market cap of $12 billion, Slack could afford to buy one, or at least the team behind it.
The only explanation I see is that it was rushed out the door to meet some executive's goals. Which suggests that Slack is becoming the sort of clueless, sales-driven, user-contemptuous company the initially aimed to overthrow.
Even simple dog-fooding by their own internal coding team should have revealed that issue.
If they had a test group, it was definitely a group that didn't use those features to begin with and basically didn't use them in the new UI either. Meticulously tracking the wrong sample group simply leads to reams of bad data.