[arrrg]

How did you come to the conclusion that WYSIWYG are “one of the most despised features in the UX world”?

That seems completely unfounded to me. WYSIWYG editors can be extremely bad … but millions of people use WYSIWYG editors all the time and wouldn’t ever think of exchanging them for plaintext editors with Markdown or something like that.

You comment seems completely disconnected from any semblance of reality.

[nnq]

...problem is combining WYSIWIG with Markdown: that can't ever work well, you need a small toggle to let users choose toggle/choose between WYSIWIG (default) and Markdown, and have it remember the last setting the user used.

Best for new users and advanced ones.

If you have BOTH in one editor it's like you've built some kind of Vim-like UI that randomly jumps between modes, it will confuse the shit out of everybody all the time!

[lytefm]

I don't agree that a WYSIWIG Markdown editor can't ever work well. I've been using Typora and MarkText a lot over the last year and usually only had to revert to the plain text view when doing larger formatting changes in enumerations/lists. Writing seems much more productive and less distracted that with a split view or plain Markdown/ LaTeX.

That being said, also Microsoft Teams is pretty awful when it comes to `code highlighting`. I haven't exactly figured out why it sometimes renders and sometimes not, it usually works when appending the ` to a letter and then pressing space, but not in other cases.

Just because BigCorps fail to deliver a good solution and then shove it down the user's throat anyway, it's not a bad idea per se. I'd love to have Google Docs & Slides with WYSIWIG Markdown.

[KajMagnus]

With both in one editor, did you mean both Markdow and WYSIWIG in the same editor simultaneously, at the same moment in time, at different parts in the editor?

Otherwise, ProseMirror supports both WYSIWIG and Markdown, and toggling between those two modes. Look:

https://prosemirror.net/examples/markdown/

[healsjnr1]

It's not necessarily WYSIWYG that is the problem. It's auto formatting markdowns in an editor.

I've never seen this done well. You constantly end up fighting the formatting. You end up having to learn obscures combinations of key strokes to make it do what you want. Or you just give up and format the text after you've written it all.

That to me is a real loss. I highly value being able to format on the fly.

[Aeolun]

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.

[nnq]

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

[naravara]

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

[rvnx]

We've started working on a preference that will let you return to the previous message composer. We don't have a specific release date to share right now — it's this team's top and only priority, however, and we expect to have it available on the desktop within a couple of weeks

===

"team's top and only priority"

I guess they need to learn how to be efficient if they need several weeks to add a checkbox to change one setting

[barrkel]

Product plan; UI design mock up; technical implementation plan; task breakdown; implementation; code review; QA; build and release.

The larger a product is, and the more people involved, the more steps and phases are needed to keep everything running smoothly. A dev shop with fewer people can be more efficient because there's less communication overhead, individuals wear more hats. But it doesn't scale.

It's also an artifact of Agile, SCRUM especially. If you keep a fungible pool of devs who can be redirected on a weekly basis, they don't necessarily have knowledge or expertise in the area of code they're working on, so there needs to be extra investigation time, sync on technical details, and more QA to cover omissions and unwanted interactions from lack of total knowledge. Component ownership is less susceptible to this but you lose some agility as dev fungibility is reduced.

[dredmorbius]

Good design, planning, and management would include a feature toggle. Switch on to enable, switch off to roll back.

(If a feature / deploy rollback itself isn't possible.)

The advantage of SaaS is that software can be upgraded rapidly, uniformly, and for all users, on the fly.

The disadvantage of SaaS is that software can be upgraded rapidly, uniformly, and for all users, on the fly.

[anaphor]

It's probably more the layers and layers of bureaucracy they have to go through to push any changes. They probably need at least 3 meetings, and several people to sign off on it.

[_asummers]

Charitably, there's (e.g.) accessibility issues that need to be addressed on "new" features like the menus, and they need to be sure they're not going to be reamed for the new feature in the same way they are for this. Also testing. Several weeks is still high but not ridiculous.

My (entirely speculation) suspicion is that the old editor had a lot of tech debt, that the team was excited to delete, and since they're now having to put it back, having to make it compatible with the new editor.

[d0mine]

It probably assumes that the target audience for slack are developers that might prefer markdown. Look at github, stackoverflow.