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

221–230 of 1001 posts

Re: Slack’s new WYSIWYG input box is terrible

#221

Post by swader999 »

dang wrote: post #32
nemo44x wrote: post #25

The product manager for this should be reassigned. To not even have the option to opt-out and use the classic input box is ridiculous. Productivity tools need to be very careful about radical change. Especially when the change won’t make anyone more productive.

Please don't cross into personal attack in HN comments. It breaks the site guidelines ( https://news.ycombinator.com/newsguidelines.html ). Note this one: Be kind. It's hard enough for people to hear criticism or fix mistakes without their head, or a colleague's head, being called for.

It's in their ultimate best interest to find a new vocation. You can't just hit undo or tab out of this one.

Re: Slack’s new WYSIWYG input box is terrible

#222

Post by netsharc »

guessmyname wrote: post #46

This is funny because I work across the street of Slack’s office in Vancouver, Canada and two Slack engineers who I frequently chat with during our daily commute already told me they —and a handful of other employees— hate the WYSIWYG input box too, but were afraid to express their feelings because their role is irrelevant compared to the people who made the decision to ship it.

Can we start calling it the WYTIWYG (What you type isn't what you get) editor...

Re: Slack’s new WYSIWYG input box is terrible

#223

Post by michaelmrose »

Arathorn wrote: post #35

Amusingly, for https://riot.im we just shelved our WYSIWYG editor efforts after trying two completely separate implementations over the years (one via Draft.js, the other via Slate.js) because: a) it's a nightmare to get right, b) nobody used it anyway (it was optional), c) chat isn't a wordprocessor, d) markdown (commonmark) + floating formatting toolbar is good enough. Our current editor was written from scratch (c…

CIDER is also the Clojure Interactive Development Environment that Rocks if it matters

https://github.com/clojure-emacs/cider

It likely doesn't as they seem unlikely to be confused.

Re: Slack’s new WYSIWYG input box is terrible

#224

Post by cosmie »

ben_jones wrote: post #165
danShumway wrote: post #139

Earlier quoted context omitted.

> The goal is for workflows to evolve This exchange is a pretty good summation of one of the biggest purely practical reasons why I'm so obsessive about tools, and why I'm so willing to put up with the initial cost of learning systems like Linux and Vim/Emacs. Outside of fundamentally better workflow improvements, most professional fields don't randomly change their tools. If you gave a professional artist a new penc…

Your comment is a punch to the gut for me, I've been developing an internal CRM for two years that embodies many of the philosophies you describe. But while it is somewhat depressing, I'm left with questions about how bad it really is. First, is it possible to develop software without inconveniencing business users with temporary (let's assume the ultimate products are better then the linux/vim/emacs they are superse…

> First, is it possible to develop software without inconveniencing business users with temporary ... regressions and inconveniences?

The trick is to avoid introducing change without simultaneously introducing perceived value to the user. Predictability and reliability are incredibly important for business users, because they're going to build processes and documentation and training around however they interface with your system. This includes both directly interfacing with your system and creating supplementary processes outside of your system to work around deficiencies your system has in supporting whatever need they have. If you introduce change, you inherently reduce the temporary predictability and reliability of the system, and the friction created for end users needs to be perceived as worth whatever value your change provides. If they perceive a benefit to themselves, it'll incentivize them to embrace and adapt to the change. If they perceive it as a regression to their processes/needs, they'll fight it and it'll eventually lead to resentment and friction between the business users and the developers.

Slack's WYSIWYG input box is a prime example - it unlocks capabilities which is convenient from Slack's perspective, and is potentially generating value for users not familiar with Markdown and are used to traditional GUI-based rich-text editors. Helping them better support the type of corporate-wide adoptions that are lucrative for them. But due to Slack's origins, a large chunk of their user base prefers the older, Markdown-based editor and perceive a decrease in value from the change. If you're going to introduce changes such as this which will be perceived as a regression by a large enough subset of users, then you need to account for that in your change management process such that it isn't abrasively disruptive.

Re: Slack’s new WYSIWYG input box is terrible

#225

Post by userbinator »

danShumway wrote: post #214
ben_jones wrote: post #165

Earlier quoted context omitted.

Your comment is a punch to the gut for me, I've been developing an internal CRM for two years that embodies many of the philosophies you describe. But while it is somewhat depressing, I'm left with questions about how bad it really is. First, is it possible to develop software without inconveniencing business users with temporary (let's assume the ultimate products are better then the linux/vim/emacs they are superse…

I'm not saying that all change should be avoided. I'm saying that all change is an annoyance to your users, all change has a cost. So if you do want to force your users to change, provide them with an escape hatch so professionals can avoid that, or be really certain that the change is genuinely making things better. Imagine that every change you're making is like hitting your user in the face with a brick. If you're…

I'm saying that all change is an annoyance to your users, all change has a cost.

Except for the changes like "reduce memory usage" or "fix crash when X happens" --- those are true improvements.

Re: Slack’s new WYSIWYG input box is terrible

#227

Post by jodrellblank »

Swizec wrote: post #157
danShumway wrote: post #139

Earlier quoted context omitted.

> The goal is for workflows to evolve This exchange is a pretty good summation of one of the biggest purely practical reasons why I'm so obsessive about tools, and why I'm so willing to put up with the initial cost of learning systems like Linux and Vim/Emacs. Outside of fundamentally better workflow improvements, most professional fields don't randomly change their tools. If you gave a professional artist a new penc…

> Only in the software industry would someone tell me that my professional tools should change because change is inherently good Translation: "we're paying all these engineers and product managers and they need something to do"

In 1995, Niklaus Wirth wrote "A Plea for Lean Software" - abstract "Software's girth has surpassed its functionality [..] The paper discusses some causes of "fat software" and considers the Oberon system whose primary goal was to show that software can be developed with a fraction of the memory capacity and processor power usually required, without sacrificing flexibility, functionality, or user convenience"

That was discussed on HN in 2014[1] and right in the top comments is "I think one factor that leads to bloated, ruined software was missed... I don't know how common it is overall, but I have personally seen it ruin several very good products. And that is the simple fact that employers want their employees to remain busy. If a piece of software reaches a point of exceptional quality - the developers working on it still have to fill 40 (likely more) hours a week to appease bosses. And so they do the only thing available - they ruin the product."

[1] https://news.ycombinator.com/item?id=8301511

Re: Slack’s new WYSIWYG input box is terrible

#228

Post by [deleted] »

gregmac wrote: post #166
Jestar342 wrote: post #8

It is infuriatingly terrible. A regression. So many times I've had similar woes with the code block and quote block mechanisms too. Another truly bizarre feature I noted and sent a bug report about was that when adding an image to an "Action" the _minimum_ size requirement is 512px by 512px. For an image that is never rendered larger than 64x64.

The changing behaviour of enter/shift+enter in code block drives me absolutely crazy. Normally, shift+enter is newline, enter is send. However, inside a code block, it's the opposite. I constantly forget this and press shift+enter for a newline while in the code block and accidentally send a half-finished message. Sad to see the new WYSIWYG editor does exactly the same thing.

[deleted]

Re: Slack’s new WYSIWYG input box is terrible

#229

Post by spenvo »

danShumway wrote: post #139
jakebasile wrote: post #19

Reading their non-replies on Twitter feels like I'm reading something specifically designed to piss me off. Smarmy apologies, low empathy, cocksure of how correct their vision of a chat service should be. This one in particular[1]: > The goal is for workflows to evolve, but we realize change can be a bit of a pain. "Stupid peasant, we are only here to help you. Once you see the glorious vision we have you will thank…

> The goal is for workflows to evolve This exchange is a pretty good summation of one of the biggest purely practical reasons why I'm so obsessive about tools, and why I'm so willing to put up with the initial cost of learning systems like Linux and Vim/Emacs. Outside of fundamentally better workflow improvements, most professional fields don't randomly change their tools. If you gave a professional artist a new penc…

Another thing in Slack that has annoyingly changed (without an option to toggle off) is: its "Drafts" feature - where leaving a channel with an unfinished message means that the channel itself gets moved to the top of the left sidebar. This completely breaks my flow, because 1.) you can no longer use up/down hotkeys to reliably go between specific channels, and 2.) I frequently have to do a double take and ask, "where did that channel go?" - especially if you Star specific DM channels, because those go under the drafts section but above the rest of the channels, meaning the Drafts section is out of view most of the time.

Long ago I created a Chrome extension that reordered things nicely, but their CSS changes frequently which made it a maintenance hassle, and I read on HN another dev saying doing so is against their terms of service anyway. Not a fan of that anti-tinkering attitude.

SLACK: don't make dramatic changes to a user's workflow without giving a simple toggle to preserve old behavior.

I get it, most users probably love this feature. My wife does, for example, and she works at a big organization, which has different needs from my workplace. But even if dramatic changes to product are approved of by 75% of users, every time you do so, you create whiplash for the other 25%, and prevent many from ever loving your product. Rinse and repeat that whiplash too many times and product design rants on HN with 600+ upvotes will be a regular occurrence...

Re: Slack’s new WYSIWYG input box is terrible

#230

Post by LilBytes »

somebodythere wrote: post #187
jdoliner wrote: post #155

I've been suffering from this one too so I'll share the most annoying part for me. I frequently have reasons to type out glob patterns generally in backticks. The interface for this is completely broken in the new WYSIWYG editor. Here's what happens when I try to type: `/ / `, things work normally up until the second " " at which point the "/" between them becomes gets bolded, which makes no sense, because you can't…

There's some delicious irony in those slashes getting swallowed by HN's markdown parser.

I spent far too long looking at that and thinking why is the first or second slash drunk.
Post reply on HN