The gist of it is that they "canonicalize" the DOM selection when you have two adjacent inline elements, so that it can only ever be at the ending edge of the first inline element. Which makes certain selection states impossible. And on top of that, they don't draw the cursor in the right spot when doing the canonicalization. So for instance, it might look like your cursor is here:
I don't know how much the take "starring" into account, but it can't hurt to star them in the hopes they're fixed sooner.
Edit: If you want to see the craziness in action, check out this sandbox:
1. Try to put your cursor at the end of the word "one"
2. Try to type a character at the start of the word "two"
What sort of out of control process let this get out, and also let them ignore bug reports for so long?
This significantly lessens my opinion of Slack and their internal culture. In prior threads there were rumors that Slack employees were hesitant to give negative feedback internally, due to culture. I don't put much stock in rumors, but I'll be paying attention now to that possibility.
I'd expect there to be 2 positions between the "e" and the "t" that the cursor would stop at so I can either insert text with the formatting of "one" or "two"
A string that ends in *bold!*
You can then pretty quickly see what goes wrong here:
A string that have *_italic bold_ and bold!*
I think you could turn any of these into interesting box forms like one of the links in this thread that has two colored boxes, and you could have text somewhere (like between A & B in the second example here) and delete that text, and suddenly not be able to get a cursor back there, short of laying some text down and reformatting it.
Markdown, and other markup/syntax based inputs, make this trivially obvious, to a large degree. (Some ambiguities in the syntax can cause issues, but those seem to be rarer than issues w/ Slacks WYSIWYG editor.)
It's not. Tap on the caret and the menu will show up without selecting anything.
Yes, I agree it should be fixed. Most WYSIWYG editors do have issues though. Just tried Pages (apple's word processor. abc <b>def</b>. Putting the cursor before after the space before the d I would personally think is more intuitive to insert bold but it inserts plain. As it is there is no way to type bold at the front of the bolded word. You either have to type new text and bold it OR you have to insert after the d, type a new text and an extra d then delete the leading d. Yes you can press Cmd-B then type but of course if the text had more styling applied that would get cumbersome to reapply styling so you're left with the previous solution of inserting new text in the middle and deleting the leading character.
My very wise coworker made every effort to avoid that minefield. I thought he was wrong for many years, but I have been forced to agree, content editable is completely and utterly useless and should be avoided at all costs.
I agree though, whenever I included a full WYSIWYG editor to a CMS the end users created unimaginable havoc. "Hey it's Word, I know this".
I’ve noticed this in the past, when a previous employer got rid of their Markdown interface for interview candidate feedback. In response to everyone’s angry comments about their flaky piece of garbage WYSIWYG replacement, they responded “please file bugs if our Markdown-like shortcuts aren’t working right!”
They were completely missing the point since even if their tool was 100% bug free (which it wasn’t, and I’m sure still isn’t), WYSIWYG editing will NEVER feel like text editing, and I NEVER want it in a critical work tool.
Honestly people thinking their WYSIWYG editor “supports markdown” because “Star Star” is an alternate shortcut for Ctrl+B seems to be so severely missing the mark that I wonder if they’re deliberately insulting my intelligence.
They are, but in cases like these you should always ask yourself if you're the target market. Frankly, if you're not the one deciding whether to adopt Slack at your workplace, you're probably not...
Sadly, you're probably right that most people aren't in that boat...
Yes, I do want to leave asap.
Toggling bold should function identically to toggling caps lock: if I press the bold button, any letters I type should be bold until I press the bold button again. Caps lock does not disable itself when I click into a non-all-caps block of text, and neither should bold.
This would be annoying sometimes, but it would help far more often than it would hurt. For some reason, however, nobody does it this way.
Yes! You'd need to press ⌘B to enter bold mode, and then begin typing.
It's ever-so-slightly more effort, to be sure. But, I loose so much more time trying to add non-bold to the end of a bold section, or vise versa.
I can learn to use systems which behave in repeatable and understandable ways. Once a system starts making decisions for me based on information I can't see—like invisible markup tags—everything becomes much harder.
The alternative is of course to make the markup visible, but for writing prose, I appreciate the clean look of WYSIWYG editors. Visible markup can feel messy.
Text color, background color, strikethrough, superscript, etc.? If I'm typing in a block of red text, is my new text black unless I tell it again to be red? If I'm editing a superscript, do I type normal text in the middle of it and then need to select it and make it superscript afterward? Editing text that was highlighted with a yellow background?
It might be an easy toggle for bold/italic/underline but there's a lot of other text formatting that would either need to behave differently or would become a huge pain. Personally I'd rather keep it consistent.
> CodeMirror 1 was heavily reliant on designMode or contentEditable (depending on the browser). Neither of these are well specified (HTML5 tries to specify their basics), and, more importantly, they tend to be one of the more obscure and buggy areas of browser functionality—CodeMirror, by using this functionality in a non-typical way, was constantly running up against browser bugs.
The team the size of Slack should/could have easily worked around that.
It is a very, very, very small victory, and if I was going to choose a victory, Slack's Markdown editor would not be very high on my list of priorities -- but I'll take it.
That's not what I'm getting at though; I'm not saying everything is awesome, or that public backlash is even the best way to currently enact change -- I just want to push against the occasional criticism I see that complaining about stuff doesn't help, that consumer backlash is ultimately just virtue signalling, that boycotts don't ever work, and that it's all just a waste of time.
To be clear, some types of complaining are harmful, problematic, or worthless: this is complicated, it isn't black-and-white. But it's not universally worthless to publicly push back on company policies. There are a nontrivial number of stories about consumer backlashes actually causing companies to change course. What that suggests is that on more important issues (just for one example, arbitration), we could see real movement if the backlash was large enough and unified enough.
i wasn't happy with the script that they were required to use, but at least it was better than any twitter-based support i've received, well, except alaska airlines which has (had?) amazing twitter support.
Isn't that more or less what you should do as a company? Build things and then adjust your strategy based on how the market likes or dislikes it?
Everyone would have been totally fine with it being behind a toggle, even if on by default.
Broken in the sense that Slack kept going forward even after the complaints kept rolling in. How hard would it have been to pull the latest release?
So they were not necessarily reacting ONLY on public outcry - they have direct feedback from paying customers as well.
> "I apologize for the disruption to your existing workflows. Our aim is to build an editor that works for all Slack users to better format their messages and clearly communicate in channels, regardless of their technical expertise. While we are taking all feedback on board, disabling the new formatting tool isn't an option that we will be offering."
It is of course possible that your particular request was super persuasive and caused them to change their mind, but the more likely explanation is the scale of the public backlash forced them to reconsider.
Their channel listing is generally crap though, I gave up on trying to navigate it and just use `ctrl-k` jumping for everything, which isn't terrible because it means I spend less time on the mouse.
Okay, someone built an emacs plugin for slack, it doesn't look like a very usable version of slack, but I'm pretty sure it'd be quite possible to fix this up a bit, prettify the UI, and end up with a much more performant version.
This means that when you browse the channel itself, each individual line represents a conversation on a specific topic. You can essentially browse the "headlines" of the day all in one screen (for most channels), and if you care to hear more about how Bob resolved his problem with those third party build dependencies then you can view the conversation in the subthread.
This also enables folks to opt-in to notifications for channels, if they so desire, without getting overwhelmed with every new message that comes in.
Threads should behave like nested channels. Today, that works okay if you click on the "5 replies" link under a message, though it opens up a cramped sidebar instead of taking you to something that feels "nested".
But when there are multiple threads, the only way to juggle them is that "Threads" entry in the man sidebar. It leads to a weird page that doesn't behave like a regular channel. For one, new messages don't come in automatically; it just shows "1 unread reply" or whatever which has to be clicked. Secondly, if you have multiple threads active at once, the view crams all of them into a single scrollable pane.
Threads should, in my opinion, show up as separate entries in the sidebar. And Slack should support having multiple windows open for separate threads and channels, which would make it easier to have multiple conversations going on at the same time.
Even if this worked, it's just a nice step toward a full comment tree (like HN or reddit). I get the impression some people find that format confusing, but I think it's vastly superior. I assume programmers generally prefer it.
How would HN or reddit look like if every reply to a post also had a single level nested thread that actually consisted of multiple subthreads of conversations with everything at the same level of nesting? It would be much more difficult to follow different subtopics of interest since it would be impossible to filter out posts that aren't pertinent to it.
I don't know how I'd feel about all channels being this way (since visibility and notification control are much weaker in this format) but for time limited discussions that may warrant revisiting it's quite helpful.
Our slack channels have at most a dozen active members and my channel list has approximately a dozen channels with permutations of the same dozen people organized topically. I have turned off almost all notifications as they are so ridiculous and look at the sidebar once in a while to see which channels are active.
I consider slack content ephemeral, even if slack disagrees. If I want to track issues, I use an issue tracker. If I want a threaded conversation, I'd probably write an email still. If I want to find content, I search a wiki or an email archive.
My preference for threads is as appears in my old school mail client or my fading memories of the "trn" threaded news reader for usenet. Threads do not hide messages, they only reorder them into a hierarchical index. It is easy to move back up the index to skim prior content in the tree, but it is also trivial to press a key and jump to the next unread message sorted first by thread and next by message time (to break ties or decide which thread to visit next after exhausting one).
Recently I had the absurd situation of someone using threaded replies in a direct message channel. It was astounding to me that this person thought this was a good idea, and also that the slack UX could so completely obfuscate an attempt at communication...
My colleagues and I sometimes discuss far-ranging topics in temporal proximity. While in the heat of the chat I can keep replies straight in my head, it helps to have them grouped for later review; furthermore, they reduce the need for segues in and out of conversational contexts, which I find incredibly liberating.
Otherwise I think dedicated team interaction channels are the biggest of ours and we try and keep those pretty small still.
I've been on this site since 2007, I've been around the block a few times ;)
Channels may exist for each corporate customer, of which there may be a hundred or more, where CS reps subscribe to subsets that they're focused on, country managers subscribe to those that are local, product managers subscribe broadly by vertical but only scan to get a feel, sales may subscribe by function or region, etc. This is an easy way to get a large number of useful channels that simultaneously cuts down on noise.
BTW, you're surprisingly dictatorial in what you say. Emergent behaviour is far more interesting to me, because - along with conscious reflection - it evolves uses that can't easily be foreseen. Where did you get your rules handed down from on high, how were they justified, and what right do you have to think they are correct?
Sorry, you're right. Nothing is set in stone, all rules have their exceptions, etc.
My point was that having too many channels can lead to a constant sense of urgency, FOMO, and increased anxiety. If you have a carefully defined way of using them, without a sense of urgency, and without a need to see everything, it may work.
They allowed a half-baked (if that) feature to be shipped out and then wouldn't back down from it for a week.
This reeks of PMs pushing a feature that isn't ready yet.
The rollout happened over multiple weeks, no? I know it was multiple weeks between I first saw it on any slack and it was on all of my slacks anyway.
The outcry was “ignored” (or rather, “we know what’s best” attitude) for about a week though.
It's not a matter of changing my code, too, because I want to see the images posted by _other_ people
I don't mean to bash slack too hard, but it honestly feels like the performance has gotten worse over time for me. Certain actions like Up Arrow (edit previous message) and loading threads on the "Threads" page seem to take way longer than they used to.
This happens at work, home, and my laptop.
Performance has never got better for me, just worse, but I keep hearing about performance improvements?!?
The other 2 amount to solving self-inflicted problems.
You are kind.
Very few non techy people know what markdown even is. (From my own experience asking friends etc.)
AFAIK Facebook, Instagram, Snapchat, Twitter doesn't have a WYSIWYG editor.
Are there some hidden users that send font size 30 all capitals red colored text in Times New Roman to each other ?
There is no step 2, that’s literally all you need to do.
That's not to say that I think we should be dumbing down software for them. In fact, we should be doing the exact opposite.
(There's a reason OpenBSD and macOS are both alive and well.)
Sure, maybe it's faster or more efficient or whatever now, but what it is at heart is the _exact_ same thing it was on Day 1.
I don't want Slack to be a different or more comprehensive tool.
I’d like to see a slack version ticket tracking for example — not a slack feature, just a separate product.
The per-user cost is only Silicon Valley reasonable - it's nearly as high as GSuite which provides a lot more value, and if so many other major business suite companies (Google, MSFT) weren't absolutely terrible at building chat applications I'm pretty sure Slack would be forced out of the market (or to actually compete).
One could start reducing the engineering and sales force, focus on polish and maintenance, gradually reduce price and collect on a successful useful product. That kind of declaring victory doesn't happen though so products get engineered into uselessness and get bought out by companies who collect on them by neglecting them until only people who happened to get stuck are still using them and everybody moved on to the next hot thing.
It's hard to justify CEO and management salaries when you decide your product is finished so instead they just keep doing things and end up ruining something great.
Staying focused is orthogonal to continued innovation.
Aside from bugfixes, I'm sure they could have done absolutely nothing since launching and be profitable and useful.
If they used a native toolkit this bug wouldn't exist, no?
Still, I'll take it over the WYSIWYG editor which was a nightmare for code snippets.
A smaller one: https://news.ycombinator.com/item?id=21591950
I really wish they'd just highlight your markup in the appropriate style while leaving the markup intact. That would solve the "I want to see what the markup I just typed will do" without any of the problems of the WYSIWYG approach. Basically just syntax highlighting for markup.
I've found this quote extremely true, but not just with programming language but with all things. People complain about Slack because they use Slack a lot, so minor quibbles become a daily frustration.
It is when people go quiet about a product that you should really worry. They're either extremely happy or aren't using it, might be critical to find out which.
Sometimes users belonged to one of the first two categories, but often not. Companies that pivot from selling to people who use the product to selling to enterprise organizations pivot from building things for users, to building things for decision-makers and decision-influencers.
So it’s not only that management are choosing products for users, but the products themselves evolve to please managers at the expense of users.
> I've found this quote extremely true
My impression of Python, Ruby, etc. hasn't been that they're in either of those categories, though I'll grant you that they don't compete in the same space as C++...
People complain about Ruby being dead, or don't talk about it at all because it's not relevant anymore.
But then every time they change something, unless it is just 100% obviously better for everyone, like a speedup, it's gonna annoy some people.
No idea what conclusion should I draw from it, if any at all, but surprising for me at least.
For people who are in it for money or status or feeling successful it's not a big deal. For the people who care about products, tools, elegance, and candor, it's absolutely maddening.
It especially doesn't help for a company to spew fake bullshit when it pointlessly changes something. What would it take to get a little candor? Why do all the corporations end up being so candorless? Why does working in this field have to be so depressing?
It blows me away that there are almost 2000 people working at Slack. The product feels like it is done and they should be able to downsize to a skeleton crew and slip into maintenance mode.
lots of hn slack users disliked the feature
lots of hn slack users who disliked the feature went straight to hn to vote up any post complaining about it
that's how communities around tech broadly tend to work
They closed the loop, folks!
The correlations here is astounding. I'm the kind of person who will vocally speak out about emacs vs vi or the pronunciation of "c-out" vs "sow-t", but the WYSIWYG editor didn't fundamentally break my mental model of Slack. I just learned to adapt, but seeing the blowback.. holy cow.
Wait, "cout" from C++? "Clout" is a real English word, I always figured it was pronounced the same minus the "l", which is neither of the versions you have there.
I'm sure it is perfectly fine if you just bold stuff sometimes, but it's so wonky with anything slightly complicated, and completely messes with my muscle memory compared with every other application I use that doesn't mess around with this stuff.
1. Their customer support emphatically told me they wouldn’t make this an option AND
2. They didn’t even need to do a new release to turn on the option.
At least their engineering team is still making good decisions :)
Took me a bunch of time to track down the issue, as it worked for a few people, but the bot would completely ignore other people – including my boss.
I have thought about why ggl hangouts at my current employer has been ok. We mostly only use direct, 1 to 1 windows so any activity is certainly to be relevant, and nothing important scrolls off screen.
I really struggle to comprehend it, would it not be better to just have some sort of "standard" we all can go after?
Genuinely interested in knowing what companies are thinking, is it feedback-driven?
With IRC, there is no simple, just-works-for-non-techies way to receive messages if you aren't online; running irssi in tmux is not such a solution. No proper history to scroll through to catch up on what's happened on your day off, or search for that analysis summary someone posted back in June.
No way to embed images or code snippets in a way that makes them visible without clicking a link or DDC-sending things.
No custom emoji, e.g. for making alert messages easier to scan (like, aws icon, server icon, triple exclamation mark -> EC2 instance(s) have issues and someone should check this right now).
Security and data protection are terrible by default in all ircds I know. Last time I checked, securing channels was a very cumbersome interaction with some custom network bot.
It's harder to get alerts sent to IRC; everyone and their mother offer Slack integration nowadays, and you can literally curl some text against a webhook if none is offered. We do that a lot.
No emoji reactions, e.g. checkmark on someone else's request to say "I did this, everyone else don't bother" or for thumbsup-thumbsdown voting on lunch places or for some sometimes-much-needed comical relief. We use gifs very, very seldomly, but they, too, are great for some comical relief.
No treads, like for "I just finished this analysis, this is the summary, details in thread" – extremely useful.
No functioning way to edit or delete messages for everyone after the fact (and see the edit history if needed) – great for "oops wrong channel", "i copy-pasted the wrong numbers", etc.
Yes, some could be improvised on IRC in some way, others could be replaced by lots of redundant messages, and if everyone agrees to use the same client (like irssi in tmux), and you sink enough time into hacking your ircd, it might even come somewhat close – but I vastly prefer the ready-to-use UX candy. Well worth the cost of the Slack premium package, IMO.
Alice: “But why do you use it? It doesn’t do so much!”
Bobbi: “Exactly why I love it.”
With the ability to stay online 24/7, why would you go offline? My work machine stays on all the time and I had no problem scrolling back through messages that were sent when I wasn't there. As for the analysis summary example, how easy is it to search for a post that was made half a year ago? Would it be easier to find if that had been sent via email?
> No way to embed images or code snippets in a way that makes them visible without clicking a link or DDC-sending things.
With my current settings using Slack, I have to click on the image link to expand it. Otherwise, I would have a window with multiple animated gifs running in the background to serve as a signficant distraction. Slack also seems to have a low limit on the number of lines you can post in a code snippet. At least a lot lower than what pastebin allows in my experience. And the new WYSIWYG editor made posting them far more annoying than using pastebin and pasting the link.
> No custom emoji
I actually disable rendering them with my current settings in slack. For :), I see :slightly_smiling_face: instead. Animated emojis, like gifs are distracting to me.
> Security and data protection are terrible by default in all ircds I know.
There's nothing that prevents applying company security policies to the servers that are running ircd on site. On the other hand, if Slack suffers a data breach, then what will your company do?
> It's harder to get alerts sent to IRC; everyone and their mother offer Slack integration nowadays, and you can literally curl some text against a webhook if none is offered.
Not everything needs to be sent via a HTTP request. There are plenty of tutorials out there to write a simple IRC bot that can handle the scenario of sending messages to an alert channel. This blog compares the Slack way with setting up an IRC bot: https://drewdevault.com/2018/03/10/How-to-write-an-IRC-bot.h...
> No emoji reactions, e.g. checkmark on someone else's request to say "I did this, everyone else don't bother"
What's wrong with just sending an actual response?
> No treads, like for "I just finished this analysis, this is the summary, details in thread" – extremely useful.
Threads? If I want threads, I would stick to email or usenet. Websites like this one and Reddit largely implemented threads correctly such that they're useful. Websites like Slack and Facebook did not. Having a single level thread under a response with multiple subtopics within that thread makes it much harder to follow what's going on in an otherwise threaded conversation.
> No functioning way to edit or delete messages for everyone after the fact
I've always used the convention of posting a sed style subtitution command right after I realize my error. E.g.,
I think it's easy enough. A different convention is to just post the correct spelling with an asterisks. Every chat client I've seen worked that way without any issues and people understood what the correction was for.
FWIW, I've used IRC, AIM, MSN messenger, and other proprietary messaging clients and platforms and none have been as sluggish and unintuative to use as Slack.
You think slack is bad, wait until they force you to switch to teams.
There is also a slack mode for emacs.. and also ripcord.
Slack will never bring back the IRC gateway, so these are our best solutions.
But slack's strength for me comes from decent unfurling of links, threading and history searching - I could live without threading, but link unfurling is a hill I'll die on.
Otherwise, all the major networks are still around and two or three of the really really really hardcore old school users from the 90s may still be around. I still ask random geeks I meet if they used to hang in #FreeBSD back in the day, hoping to reunite with old peoples.
Not really. Google/Apple also have a connection (or more) open to their servers, but IRC would kill the battery? It's the usage, not that the connection is open.
IRC is devastating to your battery and back in the 2006-2008 times no one created such a service and thus no one could IRC on the go without a hot phone a dead battery after 2 hours.. pretty limiting to a communication platform if I would say so myself
But at least with the WYSIWYG you can see before you send what parts of the markup it got wrong.
just start with a backtick escaped piece and then try to add extra text at the beginning of the line...
How would I go about adding something new to the beginning of a backticked area placed at the beginning of a line? That would either be impossible, or there would be a move of the cursor that doesn't move a character (to go in and out of the backtick/code segment.)
Isn't that just how it always is when working in WYSIWYG? The same struggle is real in word or google docs, where you constantly have to add a remove formatting when editing around inline blocks with styles or formatting.
* sigh * this was disappointing
being turned into a list.
That's a common pitfall many companies, including Google, seem to be falling into. Everyone uses tools a bit differently. Imagine that each feature is an axis in the space of all the ways to use the tool. Every person will be a different point somewhere in that space. If you try to enforce only one way to use the feature, you carve a slice in the useful space of your tool. And the more features you have, the smaller is the space defined by the intersection of all those "works for all" features, and the fewer users it actually helps !
The "one tool that works for everyone" simply does not exist. Thankfully they realized that this time, but it's more often not the case.
Good luck with that. Trying to make one product powerful enough for the techies yet simple enough for the normies is the software equivalent of Napoleon attacking Russia.
Having the WYSIWYG thing as an option is nice - forcing everyone into it less so.