Specific bug gripes aside: I see this editor as emblematic of Slack's broader shift away from what I think it should be (primarily synchronous chat; irc with a friendlier ui and integrated bouncer features) towards what many people seem to want to use it as (async-heavy pseudo-replacement for email where I get to sit and watch the "...is typing" indicator flicker while somebody writes an essay at me).
My rule of thumb generally is: if I need significant rich text formatting in a message I'm writing, it should probably just be an email.
I feel like this increasing hybridization of sync/async comms is largely counterproductive and especially harmful to work-life balance, so it's unfortunate that companies like Slack are apparently unable to focus on core competencies and instead must shoot for disruptive growth via poorly-executed junk like this editor.
I personally have no problem with the hybridization of sync/async communication. That's where everything is headed. People send emails and sometimes expect them to be delivered and/or read immediately. OTOH, people send messages over these "chat" services that aren't time sensitive, simply because it's easy and available.
My problem is that all these networks are proprietary and isolated. When someone comes up with a really bad idea in their UI, you're SOL until they decide to fix it. When someone comes up with a really good idea, you have to hope their competitors re-implement it. And all they can do is gently try to guide their network into the place they want to occupy on the sync-async spectrum via features.
Looking back at the history of computing, I see that when a protocol is open and has many competing implementations, it lives on far beyond what the original designers ever intended. When a protocol is proprietary and implemented only by a single proprietary UI, it has a fairly short lifespan. What I can't tell is if these companies don't know their history, or if they think they're going to be the first ones ever to beat this trend, or if they don't care and just want to grab money while they can.
> My problem is that all these networks are proprietary and isolated. When someone comes up with a really bad idea in their UI, you're SOL until they decide to fix it.
Tons of people said this early on, but the people who make decisions for team tooling/workflows apparently didn't think that was as important. Symptomatic of the disconnect between what most engineers think of as "quality" versus others.
At my first programming job, the company had an internal NNTP server which we used for public (within the company) discussions.
At that time, every decent mail client was also a newsreader, so people could easily flip back and forth between private correspondence and public discussion. News lets you write substantial, email-sized posts and replies, but it also plays perfectly well with quick one-liners. It allows threaded discussion, and newsreaders give you simple but effective tools to navigate it. It's fine if threads blow up and die out in a day, or if they live on for weeks. You can cross-post where a discussion touches different areas. You can post-and-mail if you want to attract a specific person's attention. It's easy to index (although i don't think we did that).
« My rule of thumb generally is: if I need significant rich text formatting in a message I'm writing, it should probably just be an email. »
Italic and bold I can do without. But code blocks are absolutely necessary for my day job, especially during a production incident. (Email won't cut it for that!)
Why not? I have my email client set to default to plain-text and I just write markdown in plain-text emails. Other developers don't seem to have any problem parsing it.
The solution is to view Slack messages as completely async, too. If you chat with someone in a different location, you don't know how long they will have time to converse. Maybe they are using Slack on the phone and just replied once to give you quick feedback; but cannot be pulled into a longer conversation.
My memory is fuzzy a bit, but I think I saw Slack being called, or even calling itself, the "e-mail killer". This leads me to believe that the hybridization you mention is on purpose, and its goal is to make profit by destroying the only remaining decentralized communication protocol in widespread use.
I'm pretty sure it was discussed as the "email killer" even here on HN, where there is a tech-savvy audience. You know, in one of those recurring waves of comments to the effect of "email is broken" (and its cousin, "it's time to move past textual representations of code"). Thankfully after all this time email is still used by devs and text remains the primary representation of code -- both for good reasons!
I think they are betting on managers and in this regard it's going to work out well for them. After all Slack is a company thing (slowly turning into corporate thing) i.e. the decision to use it will likely be made by those who like WYSIWYG but hate putting stars or backticks in their messages, or don't understand the concept at all.
My rule of thumb generally is: if I need significant rich text formatting in a message I'm writing, it should probably just be an email.
I feel like this increasing hybridization of sync/async comms is largely counterproductive and especially harmful to work-life balance, so it's unfortunate that companies like Slack are apparently unable to focus on core competencies and instead must shoot for disruptive growth via poorly-executed junk like this editor.