Live data from Hacker News

Slack’s new WYSIWYG input box is terrible

quuxplusone.github.io

991–1000 of 1001 posts

Re: Slack’s new WYSIWYG input box is terrible

#991

Earlier quoted context omitted.

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

You want I should email back and forth during an incident rather than using instant messaging?

Re: Slack’s new WYSIWYG input box is terrible

#992
post #985

Earlier quoted context omitted.

Sure, I understand the complexity of implement rich text editors / WYSIWYG. However, when implementing and deploying something like this, you usually put it behind a feature toggle (so, if you have a "text editor" component, you start by extracting old text editor into something like "raw text editor" which "text editor" uses by default. Now you can add "rich text editor" to the "text editor" component, but only if t…

My point is that abstracting things that way may have carried deceptively significant overhead, and if they intended to move everyone to the new editor without a toggle (which they clearly did), they may just gone forward with deep, incompatible changes instead. So now they'd have to go back and re-structure everything to make it modular in that way so that the two versions can coexist.

> may just gone forward with deep, incompatible changes

Yeah, this would be my assumption as well, which is why this is so unreasonable. Any serious company will deploy changes that are easy to rollback (especially when it comes to UI changes) and that Slack can't do that, speaks a lot about their engineering talent. But then again, they never been famous for their software engineering exactly.

Re: Slack’s new WYSIWYG input box is terrible

#993
post #105
post #50

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 thum…

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…

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

It was amazing.

Re: Slack’s new WYSIWYG input box is terrible

#994
FWIW, the editor they use, at least on the web, seems to be https://github.com/quilljs/quill.

I'm guessing Slack implemented something a-la https://github.com/patleeman/quill-markdown-shortcuts, but not very well...

In general the model of allowing separate positions for cursor inside vs outside a span is a huge improvements over WYSIWYG assigning "sticky formatting" to characters. (Hat tip to TeXmacs which was maybe first time I've met that UI pattern.) But you have to do it consistently. E.g. end of literal block has separate inside/outside but start doesn't.

(Of course, in source editing, it comes for free – formatting is delimited by characters like * or ` and cursor is clearly before or after the delimeter.)

----

I believe there is a saner middle ground — formatting as syntax highlighting. You're still editing the source, no hidden state, just immediate in-place feedback. (Nowdays some call this "WYSIWYM" though it's not exactly same) Examples: https://stackedit.io/, https://codemirror.net/demo/variableheight.html, https://simplemde.com/, https://laobubu.net/HyperMD (the latter is borderline, hides too many formatting chars IMHO, but does reveal them when you move cursor to edit.)

Re: Slack’s new WYSIWYG input box is terrible

#995
post #111

This reminds me of Atlassian's god-awful WYSIWYG editor. In both cases, I get that some users can't or don't like to use a machine grammar/markup, however simple. For some people markup is bad UX. Give them a WYSIWYG; that's fine. But don't remove the markup editor if your WYSIWYG editor is anything but a perfect one-two-one replacement for markup (and I have never seen one that satisfies that). IIRC there was a time…

They're currently trying to force this into pull requests in Bitbucket. Right now you can revert to the old-style pull requests with Markdown support, but that is going to go away once the new system is out of beta. I really regret going with Atlassian here; I would have advised against it if I knew about this. I will definitely advise against it in the future.

I work on this specific issue at Atlassian. Can you email me at jcolli2@atlassian.com to talk more, would love to discuss your markdown use cases for things like comments.

Re: Slack’s new WYSIWYG input box is terrible

#996
post #953
post #948

Earlier quoted context omitted.

Just because millions of people use WYSIWYG editors every day, does not mean that they don’t absolutely despise it. I haven’t ever heard anyone comment on how enjoyable Word is to use.

...Word doesn't at the same time allow markdown input and autoformats it impredictibly! If you know how bad Word is (or was, haven't touched it in a while), imagine how bad a Word version with multimodal input would be!

>Word doesn't at the same time allow markdown input and autoformats it impredictibly!

Word can't even auto-format plain text input predictably. If you try anything at all complex involving spacing our outline formats it gets completely turned around.

Re: Slack’s new WYSIWYG input box is terrible

#997

Earlier quoted context omitted.

Given that Microsoft Teams is literally an existential threat, they really want to listen to feedback internally!

Microsoft Teams is pretty horrible

"Pretty horrible" + easy integration with Sharepoint and Exchange + cheap if you're already knee deep into O365 is a tradeoff many large Enterprise IT folks are perfectly happy to make.

Re: Slack’s new WYSIWYG input box is terrible

#998

Earlier quoted context omitted.

On the topic of the old, am I the only one who found the switched behaviour of enter/shift-enter inside/outside a ``` block somewhat annoying?

This you can actually fix - check out Settings -> Advanced -> Input Options for enter behaviour in code blocks.

Oh thanks! Appreciated.

Re: Slack’s new WYSIWYG input box is terrible

#1000
post #901

Supposedly this feature is being walked back now. I just received the following from their support. I'm ecstatic to hear this and hope their Product Management has reassessed the importance of non-WYSIWYG inputs. >>> We really appreciate your feedback, and we hear your frustration. We're sorry for the impact this is having on your ability to communicate with your team and on your overall productivity. We made a mista…

Now, if only Atlassian could solve "CLOUD-7184: More Easily Change Atlassian/JIRA Cloud URL Domain" https://jira.atlassian.com/browse/CLOUD-7184 With 740 companies asking for it ;) Submitted in 2014.

Theres a note on the ticket that domain renames can be requested via support and this process does work - I've tried it on my own site :)

I've had some visibility of the internals of this work and it has involved touching a very large number of systems across a lot of teams. If you're interested in this issue, do also follow CLOUD-6999 which tracks custom domains and has a number of updates which are related.

Post reply on HN