Hacker News Reader

First off, that's super good to hear. Secondly, I'm absolutely flabbergasted that this reaction wasn't obvious to them from the get-go. This isn't the first time some silly addition of a wysiwyg feature has ended in outrage. What's even more astounding is that I don't think there are many features as despised as wysiwyg. It's up there with comic sans. Why make your entire UI revolve around one of the most despised features in the UX world?

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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/

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

Just for anyone who'd like some confirmation of this. Their official Twitter account it's also saying the same[1]

I'm glad they listened to the feedback but their attitude towards people who wrote in with bugs/criticism should also be learned from. Being told 'We know what's best for you, we're not reverting the changes' was pretty insulting.

[1] https://mobile.twitter.com/SlackHQ/status/119764013617293721...

It's extremely insulting and this is why I think Slack is hostile towards its users.

And in more than one place, viz., https://mobile.twitter.com/SlackHQ/status/119764819999085772...

And something that occurred to me: if it's true that "in the future everyone will code (to some degree)," don't you think it's OK to start the baby steps of textual thinking?

C'mon, it's markup with like six modes, people. Practice for half as long as you're on <time_wasting_social_app> in one day and you'll be fluent.

> Practice for half as long as you're on <time_wasting_social_app> in one day and you'll be fluent.

To be fair, you could learn almost anything in that amount of time;)

Funny how different the response I got from them yesterday versus what you got today. “Not in our roadmap to have an option to go back” is rather dramatically different. Power of outcry I guess, I’ll take it!

I wonder if this article being on the front page of HN for so long had a direct impact?

To put the scale of the outrage into context, this is one of the most upvoted articles since the MacOS High Sierra "log in as root by typing no password" bug.

That one got a total of 3000 points. At the time of this comment, this is still on the front page with over 2.6k and counting. It's already surpassed the news of Julian Assange's arrest, which fell slightly short of 2.4k.

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.

Microsoft has only just implemented (in preview) the ability to change the name/URL of your SharePoint site[0], a feature that has been widely requested for well over a decade.

Atlassian users might have a while to wait yet :-)

[0] https://docs.microsoft.com/en-us/sharepoint/change-site-addr...

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.

Shocking to hear them be so responsive, given their track record. It took them five (!) years to implement dark mode from when people started publicly asking for it. I guess a walk-back is different from a new feature, but still, this isn't the first change they've made that's upset people who they've then proceeded to ignore.

I think the difference here is that paying customers have threatened to walk away.

> it's this team's top and only priority, however, and we expect to have it available on the desktop within a couple of weeks, with Android following shortly thereafter

Does this seem unreasonably long? I get that large corps have longer development time, but wouldn't this be behind a internal feature toggle anyways? How do they deploy versions really? Did they already ripped out the code and are unable to go back? They need to rewrite the functionality or something like that?

Probably only someone with insight into this specific problem can answer but would be interesting to hear about it...

Rich text editors are a nightmare to implement, especially on the web, mainly because formatting a substring requires creating a new nested element, so you have to constantly synchronize a flat string with a tree structure. It's possible that they dodged this problem by storing the in-progress message as a tree and just intercepting keyboard events to directly manipulate that. If so, the core data structure would've changed and it might not be a clean swap between two different widgets that both just operate on a string.

That's just a guess though; I don't work at Slack.

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 the feature flag is activated) so you can toggle it back/forth as needed.

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.

If I had to guess, it might not take two full weeks, they're just releasing it as part of a normal sprint cycle, not as a hotfix.

I just got the same copy sent to me. Our collective rage is working

yup, got the same reply back as well. Glad that our voice was heard

Can confirm. I got the same reply as well from their support team.

Yup, I got the exact same reply. There is hope after all.