Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slack’s new WYSIWYG input box is terrible

quuxplusone.github.io

Post reply on HN
Print view View original

981–990 of 1001 posts

Re: Slack’s new WYSIWYG input box is terrible

#981

Post by _bxg1 »

capableweb wrote: post #980
sean0- wrote: 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…

> 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? T…

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.

Re: Slack’s new WYSIWYG input box is terrible

#982

Post by d0gbread »

capableweb wrote: post #980
sean0- wrote: 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…

> 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? T…

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.

Re: Slack’s new WYSIWYG input box is terrible

#983

Post by KajMagnus »

nnq wrote: post #952
arrrg wrote: post #945

Earlier quoted context omitted.

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.

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

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/

Re: Slack’s new WYSIWYG input box is terrible

#984

Post by capableweb »

_bxg1 wrote: post #981
capableweb wrote: post #980

Earlier quoted context omitted.

> 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? T…

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…

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.

Re: Slack’s new WYSIWYG input box is terrible

#985

Post by _bxg1 »

capableweb wrote: post #984
_bxg1 wrote: post #981

Earlier quoted context omitted.

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…

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.

Re: Slack’s new WYSIWYG input box is terrible

#986

Post by lima »

TeMPOraL wrote: post #481
tnolet wrote: post #419

Earlier quoted context omitted.

Was super skeptical about all those Jira replacement SaaS’s out there. But Clubhouse is actually pretty good. For people on the fence, give it a try.

I for one am still waiting for usable task management SaaS - one that doesn't limit me to "epic/project/task" split, but instead recognizes that the work is being decomposed recursively , and has dependencies. All I really want is a system that lets me arrange my tasks into a DAG. B is a subtask of A. C and D are subtasks or B. E is a subtask of D. F is a subtask of A, but depends on D being complete. It's simple and…

Phabricator does this! It even renders a nice outline view of all your task dependencies. You can built arbitrary m:n graphs between your tasks and view them as a table with current state and so on.

Re: Slack’s new WYSIWYG input box is terrible

#987

Post by pbreit »

rerx wrote: post #760
indosauros wrote: post #699

Earlier quoted context omitted.

Here's a gif of the second issue from the blog post, just reproduced on my client https://i.imgur.com/X8FZJhi.gif

Ah, earlier today the Slack app on my Mac had not updated yet -- there I experience the same issue. The web client on Firefox works better, though: https://imgur.com/a/X53iIlm Edit: On Chrome it's broken for me too....

Well, that just looks like a bug then.

I think the concern is mostly about what Slack was actually trying to achieve.

Re: Slack’s new WYSIWYG input box is terrible

#988

Post by d0mine »

arrrg wrote: post #945
lovehashbrowns wrote: post #923

Earlier quoted context omitted.

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

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.

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

Re: Slack’s new WYSIWYG input box is terrible

#989

Post by Fiahil »

tripzilch wrote: post #978
Fiahil wrote: post #675

Earlier quoted context omitted.

It's genuinely hard to make a good design for something, but if you put the time and effort required, that's the difference between Atom and VS Code. The only way I know how to make a good design, is to have a good Product Owner. Prototyping helps a little bit, User testing absolutely not. You can have five different PO working on the same epic and still get a bad design, but it only takes one to find the perfect sol…

Huh, why do you believe user testing is unhelpful to make a good UX design?

User testing can only help you _validate_ a design, not _create_ one. You can have all testing you want but still end up with a bad design.

Re: Slack’s new WYSIWYG input box is terrible

#990

Post by CM30 »

greggman2 wrote: post #474
Plyphon_ wrote: post #464

In their defence (not the defence of the WYSIWYG box itself) - they quite likely have done lots of user testing that has shown clear desirability, improved value to user, improved usability, etc etc. You have to remember Slack's target persona is probably no longer the Engineer (If it ever was) - it's more likely a much less tech-savvy employee who finds WYSIWYG editors very handy to create rich text inputs. I guess…

> they quite likely have done lots of user testing that has shown clear desirability, improved value to user, improved usability I have never worked at a company that did user testing or if they did it was always done in a way or interpreted in a way to back up the designer's opinion. I don't think I've once in my entire 40 yr career seen a designer test with users, find out something was bad, and change their design…

The company I work for has done this. We constantly A/B new designs, and if the new one loses out to the control, that's it. Back to the drawing board, it's gone.

That doesn't mean everything necessary gets chucked out immediately. Sometimes we'll then test individual parts of a design (failed or otherwise) to see if those do better on their own. And complete redesigns with similar aims do sometimes get created (but they're usually completely different in colour scheme, layout, text, etc).

We also do user testing for the same stuff. That too is more important than a designer's opinion would be.

So yeah, it does happen.

Post reply on HN