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.
Teams biggest "Feature" is that is part of the Office 364 Suite, a lot of the layout and other issues are simply forgiven since there are no additional licensing or costs to use it over Slack if you are already on Office 364 Enterprise
Teams is "good enough" for most organizations and is improving,
Yep. My large, distributed government agency was a free-for-all for several years. After letting everyone try things out, they've now decided to standardize on O365 and dozens of team-specific Slacks are getting torpedoed in favor of the agency-wide Teams instance.
That's never stopped enterprise IT from rolling out tools to their users.
Teams is free as part of an Office 365 subscription (just like Sharepoint and all the other crap they bundle with it), which is what definitely makes it an existential threat to Slack, because now Slack is competing with Microsoft's very strong Office monopoly.
Teams has some UI issues (please make the chat more compact) but they have a pretty powerful tool for normal users who are already in the Office landscape.
The fact that you can create a group with some channels, add your files there and edit them together, have a wiki, have a (not very good) kanban board etc. makes it a pretty complete experience. Some of the tools they release needs more polish and some tools are by themselves much worse than stand alone competitors but having everything in one is pretty nice.
The best word I have for teams is ‘clusterfuck’. The files which were already spread around different locations, now have one more location to be added.
Then there is sharepoint, oh, and onedrive, and they all come in the same package so everyone uses something else.
I don't like Teams much but the calendar integration is really nice. If I get a calendar invite for a meeting via outlook I can tab over to teams and it's right there in the calendar view with a join button. Much easier to keep track of compared to the old way (calendar invite, tab over to slack and find the appropriate channel or group chat to start/join the call)
At a previous company, we had slack and MS Teams side by side, to trial out MS Teams. Everyone preferred Slack by a huge margin. We were told to get use to Teams, because Teams is free.
Guess what, it was fine.. no notable productivity lose going from slack to teams. If anything, team's sharepoint file integration is much better than slack, for keeping a single source of truth.
Teams is fine, but Slack is pleasant. I don’t really know how to qualify the difference, but I guess it’s somewhat similar to ‘death by a thousand cuts’.
Endless notifications. I use Teams daily and it drives me insane. Especially every notification you get for a thread you already explicitly told you don't want notifications for. I stopped wishing people happy birthday but cause I would get notifications on three devices for days. Even though I said I don't want notifications for that thread.
Teams is a buggy mess they will never get fixed because they only follow the votes on User Voice.
Same here. Yes, it's buggy and annoyingly messing up the formatting of messages, especially when trying to use WYSIWIG Markdown. Since we're running on Office365 due to Management preferences, we started using Teams. With Franz, it's usabale on Linux. It's bad compared to Slack ofc, but not so much worse that it would justify an additional 11,75€ per user and month.
It doesn't matter. It's part of the Microsoft enterprise offerings. If you don't want to get replaced by one of their products, which the CIO will do just to make his/her own life easier, then you better make a product everyone wants.
Doesn’t matter. Orgs are moving to Teams in droves. I personally know four 50k+ orgs moving to Teams just in the last 6 months. Slack’s pricing is not helping them either.
"Pretty horrible" + easy integration with Sharepoint and Exchange + cheap if you're already knee deep into O365 is a tradeoff many large Enterprise IT folks are perfectly happy to make.
In my company (not a small one) and in any previous ones, I’ve never even thought that people could be afraid of giving honest feedback. I’ve seen internal feedback causing change, I’ve also seen it being ignored (sometimes to be listened to later after all, sometimes it turned out that things weren’t as bad as they seemed), but I’ve never perceived any potential for negative repercussions.
So if that is indeed the case here, then it does indicate some problems.
Uh, that’s actual the default behaviour I’ve witnessed at small and large companies I’ve worked for: complain or be critical of the shiny bright path that executives push you onto, and you’ll be branded a nuisance to suppress. Rule n.1 of survival has always been “don’t rock the boat”. The one time I felt safe enough to speak my mind without filters, I eventually paid the price for it.
Sure, my point is that it makes little sense to jump to these conclusions with so little information, especially since this is not the point of the article.
> Why stay at a place that doesn't value your ability to think? Or, worse, doesn't value the thoughts of anybody below a certain rank?
That's the over reaction part. The fact that two engineers feels uncomfortable expressing their feelings, says very little about the culture or values in their company.
It could be that they are just too introverted or insecure to speak up about most things, or that they have a good relationship with the fellow engineers in that other team, and don't feel like ruining it by telling them, that their contributions to the product sucks.
If the original commenter had said, "if any two engineers feel uncomfortable, you should definitely quit right away", then you'd be right.
But that's not what was said. It was correctly described as a possible management problem, a signal. If your notion is that one should leave at the first signal, that's something you bring to it.
Anyhow, we have evidence that the problem is more widespread. It's obvious from the HN reaction that quite a lot of people hate this feature, engineers especially. But still it was released. If you want to hypothesize a situation that makes that unimportant, you have to dream up a lot more than two extremely insecure engineers.
While I can appreciate some healthy skepticism on how widespread the practice is, welcoming honest input from rank and file members of any company can be extremely valuable to improving the quality of products, and many successful companies realize this and encourage such feedback
I complain via my company's slack so they know the observation is from a paying customer
Don't get me wrong, the "you'll get an answer" is almost always the same "thank you for your input" but at least it creates a Zendesk ticket from a paying customer, in contrast to whining on HN or Twitter, where I am about dead certain no corporate OKR is influenced
This sounds just like how my friends at Google reacted when Gmail and Google Docs were given the "Kennedy" makeover some years ago. Apparently there were a lot of memes going round to the effect of "still have one tab with the old Gmail open; praying Chrome doesn't crash".
The flow of pasting such strings is not great either. Previously you could paste a string with backticks and it would be formatted correctly on send.
Now the behaviour is to ask you every time to apply formatting. There is an option for "don't ask again" which I tried assuming it would make autoformatting the default, but it turns off the behaviour completely with no way to get it back!
Only if you care about that level of specificity of the results; and given that non-technical people love pasting code snippets into slack without the code fences, I'm guessing this change isn't even wanted by non-technical people, and only made detail-oriented folks upset
You don't need the key combo, just as you said, you just need another line, with text or a blank line. I guess before now you could but them right back-to-back? This has never been my use case, but if it was, I can see how this is annoying.
Yet again this sounds like the pet project of a VP trying to make his bones while ruining the product, and nobody at the company is powerful enough to overrule him.
Good tip on adding the ‘+’ to the end. Thanks!
To anyone wondering, adding the plus (when logged in to Bitly) displays an info page with the referrers (refererers) and locations by country.
And where the link goes to, obviously. No idea if this counts toward the Bitly link open rate.
As others have said it means "Highest Paid Person's Opinion" but as a little extra.
It is usually used when a company has no actual data to work on and therefore goes with the "obvious" as defined by "the boss" (Hippo).
Not that it is necessarily true. There could be lots of data that some people are not aware of and that only senior people are privy to, but if that is not shared with the team developing the software then that is in itself not a great sign.
Nah, HIPPO works perfectly well in "data-driven" companies: the highest paid person proclaims what the data is supposed to tell, and then lots of data "science" happens to make the data show exactly that.
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 solution.
That input box story is not different. They could have made the WYSIWYG feature compatible with the "old" input method by changing the visual without altering the character flow (eg: The <star>brown<star> fox). Apparently, no one thought of that...
If I'm imagining it correctly, it should work like this:
writing `help` will render it inline. A rendered `help`^H becomes an un-rendered `help
The rendering doesn't need to show the backticks, but it seems to me that it's perfectly reasonable to have it exist from the text-editing perspective.
The real problem might be that hitting <star><star>help<star><star><LEFT_KEY> can either move invisibly between one of the two stars (technically correct), or jump a star to place the cursor just after p (visually correct).
I would think the best solution is to have all editing keys (eg backspace, delete, insert-then-type) be technically correct, and all movement keys (eg arrow keys) be visually correct.
I think this is also how Typora does its markdown rendering, which was functionally intuitive in my experience (I stopped using it because it slowed down severely with any file larger than like 300 characters, so a worthless text editor, but UI-wise it worked well)
On another topic, someone recently posted this youtube video of a Norwegian engineer explaining her views on tech worker ethics, how we've got here and maybe a way to fix it or atleast improve on the current situation. I'd recommend showing it to your commute buddies.
It really resonated with my thoughts, how I've viewed the tech world and my (tiny) part in it.
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 mistake by forcing everyone into this feature without providing an opt-out for customers like you: people for whom the existing behavior was working just fine.
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, with Android following shortly thereafter.
We will follow up with another note when this option is available to you, and we'll include instructions on how to enable it.
Again, we're sorry for the disruption and we're grateful for the feedback. We missed the mark on this feature! We will do our best to learn from this and avoid similar mistakes in the future.
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.
...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:
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.
...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
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.
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.
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.
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.
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.
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 :-)
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.
> 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.
This reminds me of Atlassian's god-awful WYSIWYG editor.
In both cases, I get that some users can't or don't like to use a machine grammar/markup, however simple. For some people markup is bad UX. Give them a WYSIWYG; that's fine.
But don't remove the markup editor if your WYSIWYG editor is anything but a perfect one-two-one replacement for markup (and I have never seen one that satisfies that).
IIRC there was a time when Confluence axed their markup, and inevitably a table or a template would get completely screwed, and there was nothing you could do but recreate it. TERRIBLE design.
> This reminds me of Atlassian's god-awful WYSIWYG editor.
Oh my goodness: triggered.
I've barred the use of Confluence at our company specifically because of this.
"But, but, we used it at blah company."
"Yes, so did I at blahblah company, and it was unbelievably crappy and made me angry every time I had to edit a document: we're not using it."
I DO NOT want to have to use what amounts to an extremely buggy, capricious, and neutered version of Microsoft Word 6 to edit the contents of a web page.
I will become extremely displeased with you if you waste my time by trying to persuade me it's a good idea. It's not.
Yeah, the very first time I used Confluence I was in shock of how developer's at one time could have thought this was a good or useful product for discussing/planning code changes.
For ticketing software, I find Clubhouse to be much better than JIRA. Normal markdown that doesn't drive you insane. Much slicker all around.
Concerning Clubhouse.io, it looks great, is there a download version? I know “Cloud is the way to go”, but I work in Men’s Rights (DV abuses, etc) and it is usually something that cloud companies don’t want on their platform, so we’re constantly at risk of being revoked.
No modern software works locally, it's always all in the cloud. That's why most large companies (and some cases like yours) stick with the big guys like Atlassian and Microsoft; the new competition doesn't support their data requirements.
The SPLC determined that the most famous of them were “promoting hate”, so PayPal pulled service, and it’s always the roulette on what is going to be pulled next. Each year the International Conference on Men’s Issues had to change venues at least once, and one year the venue pulled out less than a month before the conference.
Don’t say it doesn’t exist. And saying “All men are pigs” is apparently not a reason to pull support from the female equivalent. As much as “Women should be sentenced to smaller prison times than men” is apparently not a hindrance to staying head of the judges of UK’s Supreme Court.
> Its editorial position is strongly antifeminist and frequently accuses feminists of being misandrist.
somewhat different to things like the white ribbon campaign that it tried to hijack. There's plenty of charities and organisations working to stop domestic abuse of men. This looks like something that would fit well with breitbart.
In the Wikipedia article, the prominent example being used was an write (Paul Elam?) saying that victim of domestic abuse should strike back. SPLC interpreted it in context of mens right to mean that the writer is inciting violence against women. Technically true.
I wonder if in any feminist writing there are feminist who argue that victims should fight back against their attackers. How should that be interpret? Todays news in Sweden we had the first court day of the person who initiated the Swedish metoo movement. She posted a message on social media about a coworker who she said raped her. The prosecutor filed charged against her, arguing defamation as it caused emotional and economical damage to the named person. Technically this is correct and the expected result of the law suit is actually a guilty verdict for the accuser. It also mean that technically anyone who encouraged similar behavior, in the context of feminist writing, is guilty of inciting violence against men.
Swedish defamation law is also a bit different from UK/US laws in that the truthfulness is not a saving criteria. Causing someone harm through trial by media is illegal with only a few exceptions when dealing with major public figures. In the view of the legal system, harm is harm, and it is rarely justified.
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 matches how people think about work. Add a capability for estimation (for the love of $deity, in durations, not dates!), and you can pull a critical path diagram straight out of it.
Is it so hard to make software like this? Why nobody does? And how come that some project management packages (like JIRA, AFAIR) explicitly mention subtasks as non-features, because they're not "agile enough". The only piece of PM software I've seen that's even capable of what I want is YouTrack by JetBrains, but even there, the graph nature of tasks is only an afterthought; the product tries very hard to look like Jira, with all its bad features.
I also want exactly this and have so far not found an example. I think most software is geared towards "good-enough" problem fitting, where only people who both understand the fundamental structure beneath planning, and care enough to want to implement it correctly, will want a DAG solution. However, I'm already working on quality DAG UI code so I'm tempted to divert temporarily to build such a tool if there's a market for it I'm not aware of.
Perhaps a weekend project/"show HN" to gauge interest would be warranted.
If you have time, please do, and if it's usable enough - task DAG, ability to add estimates in durations ("1 week", and not "2019-11-18 to 2019-11-25"), ability to add labels/tags and to search by it, and the ability to display tasks as a graph with critical path highlighted - you'll have your first paying customer right here.
If you ever get around working on this, or even demoing your DAG UI (I'm interested in UIs for DAGs for other reasons too), please shoot me an e-mail (address in my profile).
Subtasks with intelligent dependencies, durations, and maybe top level item prioritization... I'd give up my hand rolled Google sheets idea in a heartbeat.
Oddly most of these systems will let you specify dependencies, but not show them. Even the good old GANTT chart would let you do that. JIRA has umpteen kinds of "ticket X relates to Y" one of which is "depends on".
I think it's some sort of weird cultural impedance mismatch where the teams have sort of moved over to Kanban or Scrum or whatever, but the managing structures haven't. I used to work somewhere where managers spent a regular big chunk of time manually reconstructing GANTT from Microsoft TFS Kanban boards...
It's a doubly weird cultural impedance mismatch, because I am a dev, and I used to laugh at all the MBA PM gaant PERT mumbo jumbo... until I spent some time re-evaluating my work experience, thinking about what kind of things I'd like to improve in the way my team and I manage our work... and realized I'd very much like a DAG and a GAANT chart and critical path determination.
Have you tried Microsoft Project or the various web SaaS clones? The ones with the task hierarchy on the left (of arbitrary depth) and a Gantt chart on the right. I think they all support entering effort estimates (like “5 days work”), dependencies, and so on.
I wonder if SmartSheet can do this - it’s pretty flexible and let you change visualizations but the underlying data can easily have the relationships you seek since it started as a GANNT tool. I haven’t played with custom templates much but your thoughts might be a good reason to go experiment!
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.
Apparently clubhouse is working on an integrated wiki system[1] too. Can't wait to try it out (alas, beta invite not avail for the free account my company is currently using for evaluation).
Just to let you know, if you haven’t used it in a whole, Confluence (Cloud) has a completely new editor that seems decent, it just rolled out a few weeks/months ago.
For a period, every time I saved changed to a page in Confluence, I had to completely clear cache and session data in my browser because it would just display blank pages until I did. It doesn’t do that anymore, but it’s still a slow, buggy piece of shit.
We also use Bitbucket at work, which is laughably unreliable.
> IIRC there was a time when Confluence axed their markup, and inevitably a table or a template would get completely screwed, and there was nothing you could do but recreate it. TERRIBLE design.
There was. I was using Confluence at the time, and it broke a lot of things. There was a wonderful filed bug at the time with a lot of angry people on it, where they promised to bring the old mechanism back as an option, and they never did. That told me everything I needed to know about Atlassian.
Atlassian Jira/Confluence SUUUUUCKS. They have given up on making anything better. I try to do as much as possible on Markdown files in a GitLab repo using Atom's Markdown preview (e.g., documentation). Gliffy diagrams are still OK.
For sure! One thing to take a look at might be markdown numbering rendering in the browser. E.g., if I use `1. 1. 1. ` I only get ones, not 123 (last I checked).
They're currently trying to force this into pull requests in Bitbucket. Right now you can revert to the old-style pull requests with Markdown support, but that is going to go away once the new system is out of beta.
I really regret going with Atlassian here; I would have advised against it if I knew about this. I will definitely advise against it in the future.
This is why I heavily advocate for not using Atlassian products. I use the "can't trust Australia" statement as a supporting argument but the terrible editor is what started my crusade. My company uses Jira but I do all my tracking in Clubhouse. We have Confluence but most of us write docs in Google Docs because it's less painful. I recently got us moving away from Bitbucket too. If Slack stands by this change (like they did with removing the IRC bridge), I'll be pushing hard to get rid of it before we start growing.
I work on this specific issue at Atlassian. Can you email me at jcolli2@atlassian.com to talk more, would love to discuss your markdown use cases for things like comments.
I stopped using confluence the moment I realized the markdown editor was removed. I don't care so much about the flavor, but there's something very annoying about needing to get fancy with the way I edit text to preserve formatting.
Same here. I'd made some nice (and quite simple) tooling to parse docstrings out of a Python project and turn them into Markdown that I could copy-and-paste into Confluence. It was so convenient to run something like "make documents" to basically compile the project's documentation from inspecting the project itself! But then Confluence broke their editor by making it WYSIWYG-only. And in response, I broke Confluence by convincing our CTO to ditch that now worthless documentation system for something else.
Same here. I had to resort to making all edits in my browser's devtools instead. If a page in our Confluence wiki looks decent, there's a good chance it's because I hand-edited the underlying HTML. (There's also a good chance it's old, because I've largely given up on using Confluence for new articles. I just email distro lists like it's 2001)
When I had to use confluence, I did all my editing in gists and copied the rendered version into confluence. I've done that with jira too but the copy/paste seems to get mangled.
Elsewhere in this thread is the HIPPO acronym, and that's how one ends up with Jira/Confluence: "no one got fired for buying it" combined with "pointy haired bosses love it"
It's been my overwhelming experience that managers love the _idea_ of Jira, but then the day-to-day in the trenches experience of battling its workflow, its markup, its ... everything ... gets pushed down onto busy people, and even if enough engineers revolt, now you have a "well, we're already so committed to Jira we can't leave now" style reply (again, in my experience)
Yes, was looking for this post. I rarely used the markup in the previous editor, but the new editor is so buggy I keep looking for an icon to switch to markup.
Specific bug gripes aside: I see this editor as emblematic of Slack's broader shift away from what I think it should be (primarily synchronous chat; irc with a friendlier ui and integrated bouncer features) towards what many people seem to want to use it as (async-heavy pseudo-replacement for email where I get to sit and watch the "...is typing" indicator flicker while somebody writes an essay at me).
My rule of thumb generally is: if I need significant rich text formatting in a message I'm writing, it should probably just be an email.
I feel like this increasing hybridization of sync/async comms is largely counterproductive and especially harmful to work-life balance, so it's unfortunate that companies like Slack are apparently unable to focus on core competencies and instead must shoot for disruptive growth via poorly-executed junk like this editor.
I personally have no problem with the hybridization of sync/async communication. That's where everything is headed. People send emails and sometimes expect them to be delivered and/or read immediately. OTOH, people send messages over these "chat" services that aren't time sensitive, simply because it's easy and available.
My problem is that all these networks are proprietary and isolated. When someone comes up with a really bad idea in their UI, you're SOL until they decide to fix it. When someone comes up with a really good idea, you have to hope their competitors re-implement it. And all they can do is gently try to guide their network into the place they want to occupy on the sync-async spectrum via features.
Looking back at the history of computing, I see that when a protocol is open and has many competing implementations, it lives on far beyond what the original designers ever intended. When a protocol is proprietary and implemented only by a single proprietary UI, it has a fairly short lifespan. What I can't tell is if these companies don't know their history, or if they think they're going to be the first ones ever to beat this trend, or if they don't care and just want to grab money while they can.
> My problem is that all these networks are proprietary and isolated. When someone comes up with a really bad idea in their UI, you're SOL until they decide to fix it.
Tons of people said this early on, but the people who make decisions for team tooling/workflows apparently didn't think that was as important. Symptomatic of the disconnect between what most engineers think of as "quality" versus others.
At my first programming job, the company had an internal NNTP server which we used for public (within the company) discussions.
At that time, every decent mail client was also a newsreader, so people could easily flip back and forth between private correspondence and public discussion. News lets you write substantial, email-sized posts and replies, but it also plays perfectly well with quick one-liners. It allows threaded discussion, and newsreaders give you simple but effective tools to navigate it. It's fine if threads blow up and die out in a day, or if they live on for weeks. You can cross-post where a discussion touches different areas. You can post-and-mail if you want to attract a specific person's attention. It's easy to index (although i don't think we did that).
« My rule of thumb generally is: if I need significant rich text formatting in a message I'm writing, it should probably just be an email. »
Italic and bold I can do without. But code blocks are absolutely necessary for my day job, especially during a production incident. (Email won't cut it for that!)
Why not? I have my email client set to default to plain-text and I just write markdown in plain-text emails. Other developers don't seem to have any problem parsing it.
The solution is to view Slack messages as completely async, too. If you chat with someone in a different location, you don't know how long they will have time to converse. Maybe they are using Slack on the phone and just replied once to give you quick feedback; but cannot be pulled into a longer conversation.
My memory is fuzzy a bit, but I think I saw Slack being called, or even calling itself, the "e-mail killer". This leads me to believe that the hybridization you mention is on purpose, and its goal is to make profit by destroying the only remaining decentralized communication protocol in widespread use.
I'm pretty sure it was discussed as the "email killer" even here on HN, where there is a tech-savvy audience. You know, in one of those recurring waves of comments to the effect of "email is broken" (and its cousin, "it's time to move past textual representations of code"). Thankfully after all this time email is still used by devs and text remains the primary representation of code -- both for good reasons!
I think they are betting on managers and in this regard it's going to work out well for them. After all Slack is a company thing (slowly turning into corporate thing) i.e. the decision to use it will likely be made by those who like WYSIWYG but hate putting stars or backticks in their messages, or don't understand the concept at all.
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: `/<asterisk>/<asterisk>`, things work normally up until the second "<asterisk>" at which point the "/" between them becomes gets bolded, which makes no sense, because you can't bold text inside of backticks. Then when I input the second "`" it becomes a monospace block containing `//` and the "<asterisk>"s have completely ceased to exist.
They also somehow broke the tab key for tabbing through users when you're trying to @ someone, after the first tab it just starts refocusing your input boxes rather than selecting different users.
Edit: Ironically, HN's built in markdown seems to understand asterisks, but not backticks, which leads to behavior similar to Slack's that I'm ranting about, I've replaced them with <asterisk> to make it clear.
HN does not use markdown, otherwise a lot more formatting would work; it's four leading spaces to code block something, and asterisks for italics, and that's it AFAIK
If you hit ctrl/cmd-z after it automatically changes something you can keep going like you used to. e.g. try typing `foo`, and then hit ctrl-z, it'll revert it to plain text. I've found that useful for getting around the autoformatting.
That's ridiculous, right?. Cmd/Ctrl-z has a defined function. Slack is hijacking that because they've decided that decades of established patterns are wrong and creating another one-off for their very specific use case is the right thing to do. The hubris...
It's not really that radical of a thing to do though. Word has the same sort of behaviour except utilising backspace. If you type " - " in word it creates a bulleted list, hit backspace once and you get the literal text you entered.
I'm not entirely sure which is the less-worse option here but at least it's not a wildly new concept, just a different button.
There are other products out there that put automatic changes on the undo stack. I regularly encounter this behaviour in Visual Studio: pasting code in the editor is decomposed into pasting text and reformatting it. So the first Ctrl-Z reverts the code to the exact text you copied. The second Ctrl-Z will remove it.
The funny thing is that I am sure most of the people who work at slack know it's terrible, but no one asks them. There is a small cohort of product managers who probably have a plausible-sounding reason to do it, and they need to do something to justify their jobs, so they alienate everybody else because no one stops them.
I am, to put it lightly, familiar with this in other companies.
I would bet a lot of money I already know the pitch. It's the same one that the Confluence PM I'm sure made. "We have done very well selling to technical programmers and hip startups, but the market is so much bigger. shows Office 365 revenue numbers vs Slack revenue numbers. We have an opportunity to take this to the next level. We need to make this the goto office communication platform. cheers. Markdown may seem easy to use to us, but our user research shows that 90% of fortune 500 employees don't even know what markdown is. We need a more familiar interface to break into this lucrative new market and continue our growth."
>I would bet a lot of money I already know the pitch. It's the same one that the Confluence PM I'm sure made. "We have done very well selling to technical programmers and hip startups, but the market is so much bigger. shows Office 365 revenue numbers vs Slack revenue numbers. We have an opportunity to take this to the next level. We need to make this the goto office communication platform. cheers.
You're probably right. However, Slack will never be _the_ goto office communication platform until it integrates with AD and that will not happen because MS has competing software (Skype for business previously known as Lync).
> You're probably right. However, Slack will never be _the_ goto office communication platform until it integrates with AD and that will not happen because MS has competing software (Skype for business previously known as Lync).
Integrating with AD (or Azure AD) does not require Microsoft's blessing. Source: the product I'm working on (which is in the same market as Slack and Skype for business) is currently doing that.
Slack works with Okta which works with AD. These days it seems most IT orgs don't want software interfacing with AD directly (mainly because AD is a hot mess to deal with). Also, Teams is free with O365 :(
you're exactly right, but what I want to know is - how many of those enterprise users even know how to do italics in regular email? And is this _really_ the feature that's holding them back from Slack!?
And they probably aren't wrong either. Even at companies made of mostly programmers, those people aren't necessarily the ones making the decision about which communication platform to use.
TBH, for documentation outside of docstrings and READMEs WYSIWYG editors (usually google docs) are the most popular form of documentation for engineers. I've seen this happen naturally at a bunch of corps unless someone made a coherent documentation policy and enforced it.
I bet a large percentage of Slack people _tried super hard_ to stop that cohort of PMs. However, you can only fight upwards so much before you just check out completely, cash the checks, and halfheartedly build whatever nonsense they're forcing through.
It's common for ambitious employees in not-so-ambitious tech companies to lose their jobs over not realizing that the optimal strategy for keeping their job is to just do their work as told, collect a pay cheque, and not innovate.
In these companies, the fastest way to get canned is to believe you are there to help the company succeed by trying to innovate, and in the process of doing so, imply there are flaws with how it's currently being done.
>It's common for ambitious employees in not-so-ambitious tech companies to lose their jobs over not realizing that the optimal strategy for keeping their job is to just do their work as told, collect a pay cheque, and not innovate.
Also known as optimal strategy to get your soul crushed and die inside.
It's really demoralizing to be on a team on which the devs clearly have better design and UX sense than the designer(s) and/or product manager. But not the titles—they're "just" software developers who couldn't possibly understand users or design or common friggin' sense.
Sometimes, the devs can sneak in a hidden fix. For example, remember back when VS 2012 made menus ALL CAPS? Officially, that was the brave new world everybody was supposed to live in (https://devblogs.microsoft.com/visualstudio/a-design-with-al...). Users hated it with a passion.
And then it turned out that there's an undocumented registry key to re-enable the old behavior, that was leaked without much fanfare (https://www.richard-banks.org/2012/06/how-to-prevent-visual-...). It was never mentioned in any official documentation, but word of mouth spread it far and wide, and its existence probably spared the worst in terms of angry user rants.
Ironically, the outcry over the caps was big enough that this setting eventually got an official checkbox in a major release sometime later, and then became the default behavior again.
Maybe they have statistics that indicate that their larges user group by now isn't capable of using markdown? Most non-techies are not aware of markdown.
Maybe they have, maybe they don't. Or maybe they can pull some out of their behinds on the spot when asked (which I suspect is the most likely case).
If non-techies can be taught how threading or bunch of other Slack idiosyncrasies work, they can as easily be taught that surrounding text with characters like *, /, ~, _ and ` changes formatting. It's a trivial concept. Reddit, or countless Internet forums before, never had a problem with teaching that to non-techies.
The next step that also seems to happen more often than not: Despite user outcry, the company digs in, becomes defensive, and dismisses complaints with platitudes or snark like “you’ll get over it”. See also: Slashdot redesign, Fark redesign, Reddit redesign, Digg redesign, and so on.
I accidentally clicked a slashdot links yesterday. They show comments by default, sorted by New, despite having invented the best user-enforced moderation system ever seen on the web, and the #2 comment was 10 screenheights of screeenwide ASCII art swastikas. Hooray for UI redesigns to chase the next million dumber users.
Ditto... It goes to show that high quality PMs are just as important as high quality engineers. I've been in orgs where either side is imbalanced, and the same predictable results happen. When you have poor engineers, nothing is shipped, everything is buggy, the product never works and is eventually rewritten from scratch with the same predictable cycle. When you have poor PMs, you spend all your time shipping products no one will ever want to use, which demoralizes everyone and kills the productivity of your engineering organization.
Or those who grow past it. Power users are not a different species, they do not come from the planet Vulcan. They get created through repeated use of software in order to solve problems.
my experience with Slack technical folk (on some tricky auth bugs and other issues we've hit over the years) has been excellent. They're fast, knowledgeable, never pass the buck, and communicative. If it's the PMs doing this, they're letting down an otherwise great team.
Really unsure why I was downvoted for this. I posted a link to someone else in this thread that has actually talked to Slack employees, it's directly related to the comment I replied to.
Probably for the same reason people downvote when the same comment is copy-pasted all over a thread; I don't need to be linked to somewhere else in the same conversation. I especially don't need to be linked to somewhere else in the conversation that _I have already read because it is higher ranked_. Also possibly: following an opaquish link to find yourself on the very same page is annoying, and kind of the opposite of insightful, which you might be hoping for.
Well I didn't copy and paste the same comment all over, I just posted this link once. The comment I linked was also not higher ranked when I commented, as I commented right around when the original post was made. Every comment in the thread was still getting shuffled around due to upvotes and nothing was stable.
I have contacted them, and they replied me with this
Lucas (Slack)
Nov 20, 9:15 PM PST
Hi there,
Thank you for taking the time to write in and provide this feedback. 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.
We are committed to doing what we can to improve the new experience for you, and will continue to make improvements to the new editor. If there are any specific examples of how these changes are impacting your daily work, please let me know. The more detail you can share about your experience, the better we can understand how to keep making it better.
Regards,
Lucas.
Anyone know how to reverse engineer Slack desktop client?
It's particularly amusing/frustrating/enraging because they have already shown that it's possible! Up until today, I've had some workspaces with the old (and functional!) text entry, and some with the new one — in the same app!
> We are committed to doing what we can to improve the new experience for you
What an insincere message.
If they were committed, they’d offer the option. They don’t want to and that’s their right, but implying they value feedback and just doing what they want is throwing sand in the user’s eyes.
The fact that we _still_ can't disable the drafts "feature" says a lot about how little they listen to user feedback. I've not found a single person who likes that behavior, the behavior doesn't make any sense. There is a good reason almost literally every other chat app with a similar feature simply uses color/icons to indicate the same thing.
There's always alternative clients. Ripcord ( https://cancel.fm/ripcord/ ) is not 100% there yet, but it's definitely usable, tiny, and gets out of the way.
What they're really saying here is "We're ditching the users that got us here for the ones that we're targeting. They generally don't know shit but it's a market we haven't captured yet and that's all we care about"
Frustrating to get such a definitive “not going to change it” response like that. At least with a company like Google they wouldn’t even bother responding. Why even bother offering to accept feedback if they’re not willing to take it to heart? Maybe it’s just an attempt to placate their users. I don’t see why they would have an issue offering some type of preference setting or inline selection for this. What would be the harm in allowing users to so choose?
Seems like it’s becoming another dark pattern whereby developers are forcing their decisions on users a la Chrome not allowing developers to disable the browsers built-in autofill.
Spotify were also definitely not going to bring the Android widget back after removing it. A storm of complaints and cancellations - including mine - later and they changed their minds.
I found other options in the mean time; I didn't resubscribe my 10 year old family sub.
There won't be the same amount of choice re Slack..
I've been using wee_slack.py for some time; if you can add an application token and prefer the weechat UI then it's an appreciable option, but the issues I've had regarding inputting code are not necessarily fixed there since weechat doesn't take multi-line input. :(
Whoops, sorry about that. I'll have to double check I was 90% that was standard in weechat or wee-slack - I've installed very few non-standard plug-ins.
I received the exact same reply.
I suppose by the time you have a canned response for a complaint you should probably realize something was a bad idea.
Mattermost CEO here. In my mind Slack’s target persona is no longer an engineer (if it ever was) - It is more likely a less tech savvy person who wants a WYSIWYG editor for rich text inputs.
For what it’s worth, Mattermost is an open source alternative built for engineers by engineers. The interface is markdown.
Been using a self hosted version of Mattermost for our students as a main form of communication and the markdown support is something I absolutely love. Thanks.
Yes, there's an on-going discussion about going to native clients. One path is React Native going desktop, similar to how we've done our iOS and Android apps. We should probably do something about encouraging some early prototyping.
There’s a lot of speed you can muster out of the different platforms the closer you are to the metal. That said, I would love to help out if it’s an open source project. There are some developments at least on the iOS side, like SwiftUI, that could make writing and maintaining these native apps easier than you may be thinking.
Especially if you have a team of 1500 people. One person trying to make a browser WYSIWYG is bad enough; can you imagine how buggy it would be if 1500 people worked on it?
How do you feel about ProseMirror, and what browser WYSIWYG editor did you work on if you don't mind? I'm using it right now to build a personal notes editor, but there isn't much open source components to model my custom nodes to.
ProseMirror is not a "batteries included" solution, but rather a framework for creating them, so a lot of the UI stuff is missing and I wouldn't advise using it directly.
I worked on CKEditor 4 (very different from v5, which is a rewrite).
Agreed. Part of me wishes you could just embed MS Word in a webpage if you really need WYSIWYG. Similarity to Word is the reason people want it in the first place.
Is this because WYSIWIGs are inherently hard to make, or because of browser-specific challenges? Was this due to compatibility issues between browsers?
I've written my own native Windows WYSIWIG editor and a fair amount of web UI, and was thinking of rolling my own web-based editor.
I'm obviously biased and would probably recommend what I was working on(CKEditor), but here are some observations regarding the various propositions:
CKEditor 4 excels in two things:
-Handling selection - especially tables.
-Editing for accessibility.
I would recommend v5 though, otherwise you'd be potentially giving my one good friend, who's already very busy maintaining v4, even more work. :D
https://textbox.io/ - these guys gave us a run for our money a few years ago with their paste-from-external-source (e.g. Word) capabilities, but I believe they've been since acquired by Tiny.
https://github.com/tinymce/tinymce - I think this one is slowly being cannibalized by TextBox. I remember them receiving a lot of funding at one point, but getting nowhere with it.
Froala - avoid. It's not really open-source, and judging how support for paying customers works you're not getting your money's worth.
Quill - we've never seen them as a threat, so maybe they're not that good? Especially given that Slack thing that's currently unfolding.
To clear up some confusion around TinyMCE and Textbox.io. The products came to be under the same umbrella due to the merger of Ephox and Moxiecode. The combined company was renamed Tiny last year.
TinyMCE version 5, released earlier this year, incorporated much of the Textbox.io features and technology and is the main product moving forward. It is better than Textbox.io in almost every way now and is recommended for new projects.
Tiny did indeed raise $4M in venture capital last year. It has not been squandered by any means. In fact, we have only just started spending it as we were profitable and growing when we first raised the money.
Tiny has a good-sized development team with more than 30 people in engineering, QA, design and product management. Of the many options out there, TinyMCE is a good bet!
Recently integrated Quill into our app and it is fantastic — as fantastic as a WYSIWYG editor can be, I suppose. It produces valid, sensical HTML as the output, in case you need to take the result and use it in email templates (which was our use case). Highly recommend.
The WYSIWYG editor on Slack that everyone is hating on is actually Quill-based. And do note that it's always been based on Quill, they just recently added more Blots/Embeds to it.
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 (codenamed CIDER), and seems to work pretty well for markdown input + some semantic elements like prettified usernames, room names, etc.
You know what else has a terrible WYSIWYG editor? Microsoft Teams. It's kind of sort of like Markdown, except when it isn't, or when it breaks. At least it's a step up from Lync.
All I want is consistent syntax for links, italics, and bulleted lists, bonus points for numbered lists, bold, and code blocks. I don't want to have to click stuff when typing, and I don't want to remember keyboard shortcuts with subtle differences between different services.
Markdown is good enough, yet for some reason, each platform finds it necessary to do something slightly differently. I really don't care about a WYSIWIG editor, as long as I can use straight text if I want. Basically, I want Reddit comments in instant messaging and bug trackers.
That plus a nice table syntax. So many times I need to put a table in a jira comment or chat, but not often enough to remember how for the particular context.
I _so badly_ want Jira and Confluence to support just plain old markdown. Their editor is a nightmare; every programmer where I work hates it but all of management seems to love it.
Confluence used to have it. Or a similar syntax at least. They went WYSIWYG around 2010 or so. It was a dark day; I still remember the plaintive cries echoing from engineer cubes (we had whole cubes back then!).
The new Confluence they are rolling out is pretty good at converting Markdown to WYSIWYG on the fly. Not without glitches, of course, but I'm thoroughly impressed.
It seems every text input box across the product line has a different input method: BB, Jira, and Confluence. You'd think they might standardize with one to be less user hostile.
Jira still has two different WYSIWYG implementations on different pages. On the "classic" issue form, you still enter `{code}this is code{code}`, but if you open that issue in the sidebar of the backlog page, it's Markdown.
Luckily I don't have.to use it anymore. It's 2+ years, but my memory wants to tell me that I hated it, because Confluence worked differently than JIRA.
We are using Gitlab now. It's much more limited than JIRA, but for what it does much more coder friendly.
On the topic of the text box, gitlab saves the content if I start typing, get distracted, go somewhere else and come back later. That's handy. Unfortunately there is some inconsistency that it doesn't work everwhere, was it so that in Wiki pages it didn't work?
Not to even mention the annoying one-click-to-edit fields that lose your scroll position in the ticket and you cannot escape away. I'm furious every time this happens.
This is my experience as well. Moving over to their new editor has left the markdown support in limbo between different views. I.e it varies between the view when creating an issue, editing an issue and commenting on an issue.. It's really infuriating. I asked them about it on Twitter and it's apparently a work in progress?
It can, but dealing with raw html, so white / black listing html tags is incredibly difficult and error prone.
I think it'd require whole team that'd maintain that and a lot of tests on different browsers cuz browsers try to "fix" html and it may vary between them, meanwhile it may lead to some bugs(probably)
I'd suggest to try stay away from html as hard as you can and use those cool *down parsers instead :P
Oh man, Lync. The re-skin of MSN Messenger that nobody wanted.
I remember when I couldn't change my status from "Away" for some reason. On my computer it would always show me as "Online," but to everyone else I had been away for 300+ days.
The fact that this industry turned to a proprietary low-quality solution like Slack when Riot/Matrix have already existed tells the full story about what a bunch of incompetent idiots we all are.
Everyone frustrated with the new Slack input box deserves what they got. Me included.
The reason for Slack's success is probably because it's a "turn key solution": you register your company, invite your employees, enter your CC, and you're good to go.
With a lot of these open solutions things are more complex. I think we should really focus on providing a good UX here if we want more adoption.
(also, I don't know if Riot is that much better; opening https://riot.im/app/ makes Firefox use 100% CPU and my laptops fan spin; I closed it after 10 seconds of just a loading animation)
https://modular.im gives a turnkey hosting solution for Riot/Matrix for what it’s worth.
Riot should be lighter weight than Slack, but launch (particularly if you haven’t used it in ages) can be slow, plus we’re chasing a startup perf regression on firefox atm. The main reason Riot’s better is that you can use your own server, participate in an open network, and have control over the software if some feature gets pushed out that you dislike. And you get E2E encryption :)
I think the messaging on modular.im could be a lot better, IMO. I don't know what the relations between all the different organisations/people are here, but having all of "Matrix", "Riot", "Modular" is just confusing branding/marketing. It would be much better to have just "Matrix protocol", "Matrix self-hosted", and "Matrix hosted", for example.
Right now, it's not even immediately clear that hosted Matrix is an option from just looking at the Riot and Matrix websites.
Just my 2c from a casually interested potential Modular customer.
It's true this is how a typical centralized commercial solution would be marketed. However, it's a bit trickier for Matrix since it's an open protocol with a neutral governing foundation and many client implementations.
Although New Vector (the company behind Modular) is currently driving most of the development of Matrix and Riot (the first and reference client), matrix.org itself is supposed to be a neutral network-related site. Notice the remark that it's controlled by the Matrix Foundation at the bottom of the page, and not New Vector.
That said, Riot does have a reference to Modular, but it's buried here: https://about.riot.im/free. I'd personally be fine with it being displayed somewhere more prominently (or at least under a more intuitive section name than "Free!"). I also think it would also be a good idea if the Riot page mentioned Matrix (or the Matrix logo) somewhere above the fold.
I don't think it's sad; I've worked for a lot of small companies. Spending a few days learning and setting up tools is a lot of investment, never mind maintenance. I want to focus on creating business value, not "plumbing" like setting up chat tools.
Small companies sometimes turn in to large ones, but migrating from the tools everyone is used to is often not received well. There is a lot of inertia here.
> it's kinda sad that it has come to be that tech companies will consider installing matrix "complex".
I go to the Matrix website and there's a lot of "blah blah blah" about how it's an open network, a decentralized messaging protocol yada yada yada" Nothing about "how to actually start using the thing"
> More importantly, you don't need to get IT or Procurement involved to try slack.
Are you implying you do have to do so to try out Matrix? You can simply use the web version of Riot hosted here (https://riot.im/app) and sign up for a free account on matrix.org.
There's a link to this accessible from the "Try Matrix Now" page you referenced above. Admittedly, it seems the words inviting you to try Riot "on the web" were linked to https://matrix.org/docs/projects/client/riot instead of to https://riot.im/app/. That's probably a mistake and should be fixed.
You can create your own rooms (which are like IRC channels) which can be invite-only.
The counterpart to Slack workspaces/"servers" would be Matrix communities. They allow you to group a bunch of rooms and users together for discoverability. The feature exists today and is usable but still not as polished as one would hope for, but I think work on this is coming up soon.
In particular, I think better community front pages (describing the community, supplying related URLs and such) and access control (such the ability to restrict joins to community rooms to community members without having to invite each user to the room separately) are things that will be worked on.
sorry, i think if a tech company can't maintain an install for something that is crucial , then it shouldnt be a tech company.perhaps it s a marketing shop or sth.
it's as if tech is delegating so much away that in the end there will be nobody left willing to actually do the tech
Maybe consider that we have literally hundreds of priority tasks, all of which are legitimately very important, and that while we can spend the time necessary to install and maintain non-turnkey solutions, we’d really prefer to work on one of the other priorities with that time.
There’s no such thing as general tech priorities, it’s just an amalgam of a bunch of individual priorities. In most of the cases I’ve seen those priorities are very reasonable. If you start a tech company and prioritize fiddling with internal messaging software over building your product, you’re going to fail. Prioritizing tech doesn’t mean yak shaving every random task, it means outsourcing as many non-essential tasks as you possibly can so that you have as much time and attention as possible for the one specific technical task that matters: building your product.
I don't think priorities shifted away from tech, they just moved up the value chain. Tech companies should focus their limited resources on building their core product, not managing "plumbing" like email servers or chat.
I can definitely maintain an install of whatever is needed. Why would I use time doing something that doesn't create value over and above just using a paid for solution?
to be fair, Slack predates Riot (and Riot has only got properly usable as a Slack replacement since hitting 1.0 in Feb this year).
But yes, very frustrating to see folks forced by a proprietary product to suck up something like the Slack editor change when there are FOSS options where you can just roll it back, set a config flag to get what you want, or worst case fork it.
There is a chicken-and-egg problem with matrix. It's clearly nice, but the more people use it, the easier it will become to install/maintain. That's how wordpress wins over commercial blogging platforms.
One thing i found it hard to do is integrate matrix with an existing database of users. It would be perfect for our community chat.
So true, I was annoyed all day and didn't know why. Had no idea they had "upgraded". I thought I had inadvertently hit a toggle that put it out of adult mode. I was too busy to fuss with it. Every time I went into that box I came out a little more angry, a little older, and farther from the feeling of good flow that Wednesday typically brings.
It's even sadder because Org-Mode demonstrated how to do WYSIWYG right.
Apply the styling in real time, but then also show the formatting characters around it! That way you lose all of the weird WYSIWYG edge cases (will this character I type at the edge of a bold segment also be bold?), and you also teach WYSIWYG users Markdown in a natural way.
Ugh. No. This really breaks up the flow of the text.
I’m sure it’s fine for org-mode’s intended audience, but for people not from a coding background, it’s horrid. And there’s no need to “teach WYSIWYG users Markdown” when WYSIWYG is fine for them.
In my experience it doesn't particularly break up the flow of text. And as for "people not from a coding background", inline styling with visible formatting characters is exactly how Whatsapp implements its rich text editing. Considering it's an app with a billion and a half MAU, I think you might find that you have an unrealistically low opinion of non-developers' intelligence.
No, it doesn't. It's just syntax highlighting for markup. Disappearing formatting characters, which is what I switched Org to myself, is another story - it has some of the problems introduced by WYSIWYG.
It could remove the Markdown once the message has been sent, and only show it in editing mode. Then readers wouldn't have their flow disturbed, and authors could edit their messages in a sane way.
We chose ProseMirror after doing a lot of research (TinyMCE, Slate, Draft, Medium toolbar) and have been very happy with what it’s enabled us to do so far. We’ll probably write a blog post about it at some point.
Riot's CIDER is pretty much an internal codename though, and it's not split out (yet) for anyone else to use. So hopefully it's not too bad a namespace clash.
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 my point is - I'd wager this wasn't "rail roaded" through by some senior stakeholder that no-one can speak up too, but was probably a decision made by a product team who have the data to back up their decisions.
Now if the above isn't true (and perhaps the opposite is true) - then agreed, those are the signs it's time to leave.
> 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 based on the test.
Has any one else?
To be clear I have seen a designer test themselves and re-design but I've never seen them test with users and re-design. I've also seen them change a design, put it out in limited release, then claim "we didn't get any/many complaints so it must be okay" without a thought that the majority of users never complain (either don't know how, can't be bothered, never considered it might be useful, clicked the feedback but that doesn't actually make it back to the designer, combinations of all of the above)
I agree that there is a temptation to not do it, especially for smaller changes, especially if time is tight, especially if you are a smaller company, and all of that is certainly a problem.
But no user testing? Not changing the design? We just recently drastically changed the design of a new product we are developing because it failed initial user testing (with clients of us who came in for user testing using a paper prototype).
What followed were also several rounds of design critique sessions with the revised design (bringing in internal people who had nothing to do with the design and ask them for their constructive feedback, without aiming to find a solution to what they find during that meeting) and we will bring those original clients back in in December and sit them in front of the then working prototype.
We are a small company and I do agree that we do this far too infrequently but from my viewpoint as someone who makes the design I couldn’t even imagine not reacting to people who clearly have trouble with the design. Because I did the design. I know that it’s made of thousands of little decisions, thousands of little trade-offs you have to make. I know that it’s a hard problem and that it’s easy to make mistakes or to fundamentally misunderstand something about the mental model the users have. So any information about what works and what doesn’t is extremely valuable.
> But no user testing? Not changing the design? We just recently drastically changed the design of a new product we are developing because it failed initial user testing (with clients of us who came in for user testing using a paper prototype).
your company is the exception. Most companies do no user testing. The closest i came was working at a co that did user interviews and ran some mock-ups by them before turning to eng. Once it was in our hands there was no change based on user feedback, because there was no user feedback before release. Not because we weren't willing to, but because ... they just never did.
Most folks i've spoken to do no user testing whatsoever at their companies.
Me neither. I am currently of the belief that most of that "data driven" product development is just bullshit, and not really even data driven. It's too easy to just plug Google Analytics and proclaim you're "data driven". And if all you do is telemetry and A/B tests, it's way too easy to make them favor whatever you want them to favor, either purposefully or accidentally.
I haven't seen much evidence that would say otherwise, but there's plenty of circumstantial evidence favoring my belief. Like this case.
We develop simulations for events and often watch how delegates interact with the UX to determine if things need amending... never called it data driven even though we do track scrolls and clicks within the software to determin user flow and pinch points.
The reason the Windows 95 interface was so much better than what came before it was because Microsoft did loads of user testing and changed their design heavily based on it.
I completely agree. There have been some improvements in the design (XP and Vista's Start Menu changes, XP and 7's Task Bar changes) but they're incremental ones, and Microsoft's attempts at big changes have not gone well.
I work in the UX team for a major online retailer in the UK. We spend a large part of our time testing and validating our designs with real customers - not much goes live without us being sure it's the right thing. If something doesn't work for people, even if we think it's great, then it's gone.
How many times has that actually happened though? I talk to designers all the time who say some variation of this but have literally never done any of those things.
Depends on the task, but if it's for a big project we'll go through multiple rounds of usability lab testing before a design gets built.
Then, after launch we'll do rounds of optimisation based on the data we get back. This bit doesn't happen as much as we'd like as newer projects take priority, but it does happen and we're working on ensuring the Build > Measure > Learn loop is an integral part of the process.
We're lucky as senior management understands the benefit of testing and iteration. One place I used to work, the chief exec thought they knew everything, so didn't understand why we wanted to research and test stuff all the time. So we ended up having to do what they wanted, rather than what we knew the customer needed.
> 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 based on the test
Too, too true. I have seen designers proceed to "educate" their test users (sometimes for weeks at a time) as to why the users' preferences are wrong and the designer's are right.
I work for a relatively large global tech company (100k+ employees), and our UX teams does this all the time. First they come up with a design they _think_ will work, then do user testing, and often the user is confused or doesn't like a specific thing - could be a button color or an entire flow - and we change it. Then repeat.
I think what your UX teams are doing is (or comes across as) the opposite:
1. Come up with a design they think will work
2. Do user testing looking for confirmation that it works.
3. Change things (based on user feedback) in their design until they find confirmation.
I've come across this, and I wouldn't say it's data driven. It's, if anything, data supported, but it is still sounds like the initial design/idea still comes from within and there's a chance that it's down to their taste, interests and convictions. Or worse, a trend. We tend to pitch our ideas along with the data to support them so it's natural to seek confirmation as part of our normal workflows, but that's very different to taking design decisions based on telemetry, user feedback, etc.
Now, it's possible that I'm completely wrong and your UX teams actually does that. For instance:
1. You get support tickets from users about a missing or difficult to use feature.
2. This prompts team to design act. Design decisions are made, user testing happens, feature or changes are released. Once released, you notice from your telemetry data that the feature is rarely used by the wider audience, perhaps some of its UI items are used more than others.
3. UX team goes back to the drawing board to try to improve visibility, and does user testing.
Success rate is usually higher in that situation since you know users actually want that feature or change, and it's just about getting it right.
In Slack's case, I'm left wondering if any users actually wanted this change.
We did the whole bit: Hired a special company that had rooms with one-way mirrors so you could watch the users use the thing.
It was brutal.
One person went to this really cool subpage, and we were all so excited to see what they were going to do. User waved the mouse around for a few seconds and then clicked back. We were jumping up and down in our seats, just losing it. Our special thing was so cool (we thought) and this person literally couldn't begin to understand what it even was.
It's amazing to see a game design fundamentally fall apart when users get a hold of the product and then see the game designers tearing their hair out. They do usually double down and call the gamers dumb or something lol.
Where I work we do a small amount of user testing to validate our design choices. We recently just planned out a release worth of work to improve user experience because we missed the mark with our design.
If we didn't do this we'd lose to the competition.
When I worked at EA we regularly performed user validation, we had a whole room set up for proctored user testing. Hired professionals to conduct the testing. We also invested a heap into A/B testing and had a whole team dedicated to tracking this and analytics in general. This was just for marketing/launch web sites.
I've been working in the industry for 20 years and while the norm is as you describe there are certainly plenty of exceptions, especially when you product lives and dies by UX.
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.
I'm a designer and I do user testing for every feature in the app I'm working on – usually using Sketch or Framer X for cases where better prototypes are needed, and in mostly all cases the design changes because of it. It's very hard to get it right in he first try, and I can't believe I'm the exception here.
Funny thing too: because I usually do the implementation of my own designs (react-native app so not so big of a barrier), I usually discover limitations of the original design and have to tweak it to better fit the medium.
I'll back you up on that. I've had 20 years in the industry, doing mostly front end work across web, mobile, desktop, automotive & TV. Mostly contracts, about 40 clients - mostly small but also some big ones you've heard of. Only three of them did (minimal, small scale) user testing, none of those made any major changes as a result of user testing.
> 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
My teammates just came back from an on-site user test, and the lead designer's own report describes how some features which he had pushed for were not working out for the users.
We have always done user tests, and we have always applied the results if they were meaningful, from balance to UI tuning to, sometimes, scraping entire features. There's plenty of companies that do this, and individual designers that really care about the user more than their own ideas.
Most of the established large tech companies do User experience research sessions while doing several iterations of mocks during the process. This is prior to AB testing. My current and last company both followed this practice.
I happen to know several instances of Google, Amazon, Facebook, and even Apple not doing this. But I guess "established large tech companies" is a big list and GAFA is only 4 companies. I realize that these instances are not 100% of all the work those companies do. Would be nice to read more articles from them on their failed tests and what led to their current designs.
> probably a decision made by a product team who have the data to back up their decisions
lol.. I don’t know how, but this wool has been pulled over everyones’ eyes. These “data driven” decisions are often anything but. The people making them usually don’t even have sufficient background in stats to be capable of making them. They just plug and chug in some NHST framework or A/B testing framework, making all kinds of test errors or even outright cheating since their job incentives, much like failed research incentives, requires a constant stream of new positive results that causally drive growth & engagement. Since they “have to” find these things, then anything which can be politically argued into the product will be made to “have the data to back it up” (even if it doesn’t really).
The bigger the company, the worse this effect gets.
IMHO they missed the fact that power users would have preferred the old behavior and didn't provide the opportunity to switch between the two behaviors
This. Power users (normally engineers) drove Slack usage at my last company. I'm now in an org that uses Teams and all the engineers want to use Slack. Likely won't happen but it's important to note that this feature isn't just annoying a small segment of users, it's annoying the small segment that are most vocal about adopting Slack. And who due to economic power arguably have more influence.
The problem with that is Slack no longer needs a small segment of vocal users. They used to, but now they're a huge established company with plenty of service contracts across tons of industries.
I'm not sure how Oracle really squares with that theory. From what I've seen, courting executives can work pretty well for companies widely hated by users.
They can be vocal about getting people out all the want, won't make them effective at it, especially if most people don't understand why power text editor users hate WYSIWYGs. Once contracts are inked and the whole company gets hooked on something like Slack good luck getting it back out.
"engineers" drove your company to spend money on a chat tool from a company that had leaked private chats, gave no real control over the interface, and used a closed protocol? Now those same people are complaining about it?
Sure, but at least have this a configurable option.
Right now, they just basically blew away something that worked really well for alot of people and are demanding their captive audience adjust.
Whoever at Slack pushed this and threads has a good case of the Jony Ives going on. Thats two UI/UX changes that have met with lukewarm reactions to absolute dislike.
The simple truth is that significant UI features should default on and be possible to disable on launch.
Give me a simple text edit option (heck, even Jira lets you choose between the two because they understand users have different preferences) and I'll be fine.
This video[1] from slack.com front page has 3 chat windows. 1 of them is about two engineers chatting about a git pull request, so I guess 1/3 of their target persona is a developer?
If usability testing was an actual, consistent driver of UX decisions, we'd still have skeuomorphic interfaces. I'm sure somebody crafted a UX test or metric that showed the WYSIWYG editor is superior, but this was probably done to back up an existing product decision, not as good-faith research.
At the risk of sounding like a shill, I'd like to shill Zulip. We started using it instead of Slack, and it has been amazing. It's fast, everything is designed to help you get to conversations quickly, keyboard accessibility is second to none and the streams is a much better default than rooms.
I can't recommend it enough, it's well worth the money even though they have a nice free tier and are OSS so you can self-host.
That's one thing I'm currently missing in Ripcord (the Slack client). Or at least I haven't figured out how to do it. I use Slack from three devices, and sometimes I read a message I want to reply to later from a different device - marking messages as unread was a handy way for ensuring I don't lose them.
I'll just go ahead and admit to shilling. Zulip is amazing and I tried to get my company to switch to it. The only thing that stopped us from switching is well, the fact that people have to switch. They have to learn another tool, and Zulip sadly is not too friendly when you first start using it, though it's amazing for power users.
I literally believe it's the future of enterprise chat. There's no better tool for getting actual work done.
edit: I guess I should clarify about the shilling part. I contributed a single feature to zulip, once. So I guess I'm not really a shill, but I love the product.
Keyboard accessibility is second to Weechat. Weechat responds instantly to all keypresses and never leaves janky UI on the screen.
When reading Zulip threads I frequently mute those I'm not interested in. To do so, you have to hit 'i' to open a menu, then 'M' (there is no shortcut on 'm'), then a popup message slowly animates in saying the thread is muted. If you hit 'n' to go to the next thread, the popup message doesn't clear, so it's covering the top message of the new thread, and the popup menu is still open covering the top 1-3 messages, still listing the last thread's title. So leaving a single thread I know I'm emphatically not interested in takes five seconds. There's a nasty positive feedback loop: catching up on threads is slow and frustrating, so I leave it longer, so there's more threads that take even more time and frustration, repeat.
I reported this buggy workflow ~2 years ago and it's why I've repeatedly given up on a very interesting community's Zulip chat. There's plenty more flaky stuff, like switching messages with j/k sometimes not scrolling the screen, or long messages where you have to take your hand off the home row to scroll up and down because if you hit space the floating nav covers lines you haven't seen, long messages being "closed" so you have to navigate to each individually to read, no keys are customizable, death by a thousand cuts. I have my fingers crossed for a bitlbee integration.
Zulip looks great, but it also looks like the sort of thing I'd have trouble convincing everyone to switch over to because even though it might be more useful in the long term, in the short term its a bit more complicated (even though we're on the free slack, so we're looking to move elsewhere)
That's exactly how I'd explain it. It took me about 3 hours to be extremely comfortable using it and feeling productive. But first impressions by all of my coworkers were "It's so confusing", "There's no way we can use this, it's terrible", etc. But it's amazing. Just absolutely fantastic.
I've been hosting a personal server, a company server, and servers for every one of clients since we started as a web consulting company.
It's far superior to Slack for remote work in our experience because it's designed to be primarily used asynchronously, as opposed to something like Slack/IRC where you have a wall of unread messages all mixed together every time you sign in.
The biggest difference is that every conversation must have a topic title and be put into a stream, giving all the benefits of forums or email threads with subjects. Compare that to Slack/IRC where the the default mode is putting your messages in big firehose channels that don't encourage breaking individual conversions out into separate threads.
Zulip's hosted plans for corporate users have a similar model to Slack's -- there's a free plan with limited access to history, and a paid plan with full access to everything.
Since you mentioned nonprofits, we provide free hosting for open source projects and free or highly discounted hosting (e.g. 15% price) for many other nonprofits.
User interface, information density. Zulip is very verbose and cluttered and after a while it becomes difficult to find information from past conversations, things scroll out of screen very quickly, etc.. And there doesn't seem to be much of a way to customize it, short of going for the source code. For IRC there's a ton of customizability around in the form of various clients, scripts, plugins, etc.
Did Slack ship a buggier version of this yesterday? I have it on one of my workspaces, and it's fine.
I can still type `backticks` in the editor, with the exact same combinations of keystrokes I used before, it's just that they render as they will on the channel, rather than showing me the backticks (and only when I type the closing backtick. GIF here: https://i.imgur.com/o3wPWN0.gif)
Triple backtick does the same, and I can easily type another triple backtick to exit the code block, same as before. It's literally identical ergonomics to the previous editor, except it's showing me the formatting I can expect.
I have to think that maybe they issued some hotfixes to the wysiwyg editor in the past 24 hours to some workspaces? Or people are just way too up in arms about something that has literally no impact other than maybe some wasted screen real estate showing formatting buttons...
To name one: You realize after finishing your code block that the first two lines of it actually shouldn't have been part of the code block, but should have been normal text above.
Go ahead and try to make this change with the new system.
Compare that to what you would have done with the old, plain-text system.
Worse than that -- let's say you start typing in a code fragment inside backticks, but your code fragment includes a constant variable name like MY_COOL_VARIABLE. Because Slack doesn't evaluate the backticks until you add the closing backtick, the WYSIWYG editor turns MY_COOL_VARIABLE into MYCOOLVARIABLE, converting the "COOL" in the middle in italics... and then applies the monospaced styling _on top_ of the italics, so you have a really bizzarre output.
Oh, and you can't easily get the underscores back -- you'll need to retype the variable name.
Sure enough, the rich text formatting is copied. The workaround I have for this is the Get Plain Text app. It strips all formatting from copied text (either automatically or on a keyboard shortcut). Sad it's required for this use case. But at least this works.
Slack can't seriously expect us to apply clumsy workarounds
to their single most important feature (text-entry) that
many of us use hundreds of times per day.
In particular since the solution is
as trivial as adding an off-switch.
> To name one: You realize after finishing your code block that the first two lines of it actually shouldn't have been part of the code block, but should have been normal text above.
* move the cursor to 0,0
* hold shift and hit down-arrow twice to highlight the first two lines
* continue holding shift and hit left-arrow once to deselect the EOL on the second line
* use the keyboard shortcut for toggling code blocks (cmd-alt-shift-c)
It may have been buggier yesterday, but I had the change applied to my desktop client today and it is still buggy. Try to edit an `inline code` section. Or enter two code blocks back to back. Or paste in anything with formatting, especially if there is a code block at the end.
I use the website, and for our workspace I am not seeing the auto-formatting at all now. It appears to be like it was before they rolled out the wysiwyg. Yay I guess. I did not like it at all so I'm happy about it.
Because it now more then a textarea, my mind automatically adapt and expect <enter> to give me a newline, but instead I am filling up channels with premature messages. Weird.
The exact same happened with the draft feature. The importance of habit forming UI is very well documented, going back at least as far as Jef Raskin's The Humane Interface and the draft feature completely breaks it -- if you as much as accidentally leave a character in there, you can't find the channel/DM at its normal place. Despite repeated calls to make it optional, nothing.
Threads are also broken, has always been. For example, if you get a notification in mail and it's in a thread, you can't jump to it, clicking the link dumps you into the channel and you are left wondering. Previously (as in, going back at least to '90 or so with IRC) you were able to skim the entirety of discussion in backscroll, now you'd need to open every thread on its own. As a senior developer, this was tremendously helpful to everyone because I could just skim a larger batch of discussions at a time and give some advice later as needed. Both of these problems could be solved if threads could be opened, you know, thread style into the channel. But... no. Also, if you answer in the special "threads" view then you will need to click the new answers link every time someone answers. It's terrible UX.
It used to be that adding a text snippet was right in the "add" menu you opened on the right hand side of the text, now it's in a submenu, seriously slowing down creating one. The menu wasn't getting large at all, no reason to do this.
It's very strange, they are the top dog, with immense inertia but it doesn't mean a younger, more eager, better UX, slimmer chat won't replace them. Digg to Reddit, remember? Until then, does anyone want to write a "Better Slack" collection of scripts injected into the app? I pledge 20 USD to fix these three problems, anyone else?
The draft feature positively boggles my mind. The intention seems to be to collect all your drafts into one location. But that comes with the assumption people will have multiple drafts for ... chat channels? Do people really work that way?
If the actual intention is to remind you you have a half written message, seems some kind of indicator on the channel would suffice. Having my channel “disappear” on me is maddening.
It did suffice! There used to be a pencil indicator next to the channel name in its usual spot, and it worked great. It maybe could have been more visually obvious, since leaving a draft in a chat so really is a rare phenomenon, but it was still massively preferable to the capricious ordering it does now.
It’s so simple. They could add the channel/DM to the Drafts list while also keeping it in its normal spot. I cringe with sympathetic embarrassment just thinking about how ridiculously obvious this is and how easy it would be to implement.
I can't imagine anyone who has a job that doesn't consist mostly of talking to people doing that. But people with manager or sales-type jobs? I bet they could really love this feature. Start typing your message, discover you're missing info, task someone with finding that info. get back to the message whenever.
Still though, making it break the sort should really be a setting. Or even better, just show people twice if there's a draft open. Once in their normal place and once under the draft header.
> Or even better, just show people twice if there's a draft open.
Exactly. There's no rule that says user interfaces have to be in 3rd normal form. You could just leave a visible indicator next to the channel name, and have a separate page/tab with list of all unfinished messages.
I actually love that drafts are brought to the top; it keeps things from getting lost for me. I even sometimes will write one character as a reminder I need to finish. But still, I understand your frustration.
That being said, search makes it really easy to solve this. I rarely do anything other than Cmd+K/Ctrl+K, and type a character or two. For me, it's become second nature, and I never find myself searching around for where to go. For me, the left sidebar is more of a status report, while Cmd+K is how I navigate.
The thing with floating to the top is that it doesn't have to be an either/or proposal. Bring a copy of the channel to the top but also leave it in the list.
The infuriating thing is that these would be some of the easiest possible features to add a toggle for. There's nothing wrong with liking drafts that float to the top, or rich text editing, but when a significant portion of your users is extremely upset about a tiny UX behavior like this, even if they end up being a minority, there's no excuse to not add an opt-out.
The real problem is that companies seem to think that users hate toggles. It's extremely hard for me to understand how valid this might be since I have techy people around me most often, but even when I don't, I've never heard someone complain about excess toggles. Ever. Is this a thing people do? I hear orders of magnitude more complaints about lack of toggles.
I don't have any justification for this, but my gut feeling is that this trend was started by Chrome. They (compared to, say, Firefox) offer the bare minimum of settings, and even the feature flags they do offer are deprecated and removed in a couple versions at most. It just reeks of a paternalistic "we know what you want better than you do" attitude to have about your user-base.
You can tell that this is the Chrome team's philosophy when you go onto their bug tracker and see the vast ocean of WONTFIXes. You might even extend the philosophy to all of Google, when I think of things like "ignoring" "even" "words" "in" "quotes" come to think of it...
I'd say one problem is that toggles make your code more complicated and harder to test. And the more toggles there are the more combinations for potential issues to pop up.
As a user I'd prefer to see more toggles, but if I had to maintain a product I'd probably try to make good decisions instead of leaving things open.
I hear this time and time again and it is the biggest fucking cop-out. We write code for all stakeholders, not just for us. A product manager's (or worse, a focus group's) "good decisions" are more-often-than-not lowest-common-denominator drivel that has lead us to the current reality of terrible software -- it's like a tragedy of the commons where everyone acting in their own rational self-interest ends up overfishing the lake and then suddenly the town is facing starvation.
Boo-fucking-hoo, write the extra test case.
I'd be less bitter if I didn't feel this sentiment was almost single-handedly responsible for the death of "options for power users"
It's not "the extra test case." It's literal exponential growth in the number of test cases as you add more and more toggles.
It can still be justified to add configuration options, but you can't safely test one feature in isolation and assume that it will never interact with any others.
We don't necessarily need every case to be testable, and even so thoughtful use of occams razor or something can prevent the kind of exponential worst-case scenarios that almost nobody wants.
My problem is that contemporary software design seems to draw that line at a place that allows for few use-cases. It seems to be especially prevalent in modern enterprise stuff like Slack or Skype -- with the latter being a very good example of the old ways (e.g. original skype clients) regressing into the new ways (e.g. latest skype version).
If you practice the minimum of separation of concerns then it won't be O(m*n) just O(m+n). Do you really need to test email notifications twice just because the channels no longer jump around in the channel list?
Then bury them so deep they will never see it. There's already a Preferences // Advanced tab. Do whatever you need to appease the wide population. It appears only in desktop app or browser even though it's under advanced? Deal! I will still be happy. Is it a CLI option? Fine. I have been using Unix-ish command lines since 1993. I can deal with an option or two. Yeah that wouldn't work on mobile but the primary audience here is not mobile -- and I could see that toggle saved and applied across platforms as well. Make it a slash command. If need to be, I will hexedit the living shit out of your Electron app, I have first written assembly code in 1987 and while it's been a very, very long time since I've done so, I am on good terms with hex editors still. Whatever. Just give us the options, 'mkay?
Most of the time toggles are done poorly in that I can’t tell if they are on or off. There’s no consensus on if that is left or right. Or lit up or darkened. It is maddening.
In my opinion the right way to do toggles is to have area below it that is either enabled / expanded for On or grayed out / collapsed for Off. That way I can also read what the toggle implies. I suppose that can be done in mouse over if there are space constraints.
I've had these exact same problems with Slack and every application that evolves and makes decisions for you. Usually they have the right idea, but sometimes they take decisions way too far and don't let us as users decide for ourselves.
I understand the concept of continual updates but these are some breaking changes and it scares me that they just show up overnight with no warning.
At some point the product is no longer about pleasing users, it’s about the product managers getting kudos and promotions.
I believe this is what we’re seeing now. Someone at Slack has a strong incentive to change things for changes sake and they will spin this as being wildly successful and get a bonus.
What's wrong with the drafts feature? I tend to use it if I'm messaging someone and I don't have all the info yet or I might have forgotten to reply :)
I want to encourage everyone who doesn't like the WYSIWYG input box to use `/feedback` directly from within Slack to let the folks over there know about it. I believe this is one of those occasions in which tons of user feedback is crucial to at least make that awful thing optional.
Thanks for sharing your experience with our new formatting UI. I'm sorry to hear it's been a little disruptive so far.
There isn't a way to revert to the old formatting method, I'm afraid.
We don't currently have plans to make the new formatting configurable
though we are carefully considering all our customers' feedback.
Got the same message. Let's see if "carefully considering all our customers' feedback" means "hey, lots of people are annoyed by this" or "ignoring all our customers' feedback".
>Thanks for sharing your experience with our new formatting UI. I'm sorry to hear it's been a little disruptive so far. There isn't a way to revert to the old formatting method, I'm afraid. We don't currently have plans to make the new formatting configurable though we are carefully considering all our customers' feedback.
I suppose a new acronym would be suitable for this situation: WYSIWYGBNWYW, What You See Is What You Get But Not What You Want.
With the availability of detailed API documentation (https://api.slack.com ) that seems to make it relatively easy to write your own client (and they even link to some thirdparty clients as an example of what you can do), their refusal to change could almost be interpreted as "no, you fix it".
If I had the need and time, I could probably write a native Win32 Slack client in a very short time; in fact I'm a bit surprised that one hasn't appeared yet because I was expecting that to happen. Maybe it will, if they keep messing around with the official client.
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 us."
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 pencil that had to be gripped differently for no reason, they'd throw it in the trash.
But in software, we tolerate buggy tools that change all the time for no discernible reason. We tolerate software that simultaneously targets professionals and casual users, serving both segments poorly. We tolerate software that can't be customized or adapted for specific workflows. It's tough to put into words, but if you watch a musician or a painter interact with their tools, there's a very clear difference that emerges, and over time you start to realize how much better all of their stuff is.
In most professional artistic settings, workflow changes only happen because they have a clear benefit -- drawing from your shoulder instead of your wrist, changing your embouchure if you play an instrument. And even in those fields, it's generally accepted that over time people will end up with very specialized setups that are very consistent and refined and that remain constant for years and years.
Only in the software industry would someone tell me that my professional tools should change because change is inherently good. Only in commercial software would an elegant, consistent interface like Markdown that allowed me to build up decades of muscle memory until my computer was an extension of my fingers and I didn't need to think about the way I typed -- only in software would that be considered a bad thing.
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...
I use Slack very often, and I also get annoyed that Drafts features often tugs a frequently-used channel to a different spot in sidebar. "Where did that channel go?"
I am so glad you said this! It drives me mad. I think of the lists of users/channels in slack alphabetically so even now that I'm aware of the "drafts" change I still go through this shock every.damn.time.
The crazy thing to me is that if they rolled out a native desktop app that was maybe a little bit lacking in features and used ~20MB RAM and had this particular misfeature in it and called it beta, people would applaud them for it, especially here on HN.
Instead they spent actual time, effort, and money making their product worse.
My company has certain deficiencies, but one of our core principals is that we'll never break a workflow, even if the workflow is dumb, even if the "feature" is actually a bug that an enterprising user abused in a way we didn't anticipate. The bad news is that we're saddled with a ton of legacy crap that can't be rewritten. The good news is that we've grown into one of those behemoths that dominates a niche specialized industry and won't be unseated by a product that is only, say, twice as good as ours. It's not as fun as iterating fast and breaking things, but the low stress is nice.
After this change I really want to develop a native chat application on Windows and OS X. I think it’s almost to the point where someone who did they could make a killing.
This is honestly a major contributor to the badness of software in general.
Ideal software would be continually fine-tuned and shrunk -- there'd be no bi-annual massive redesign, no change for change's sake alone. Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points, a well-run project would make something work well and then they'd leave well enough alone, focusing only on bugfixes, performance, and other "boring" projects that don't make for big press releases. Changes to working products should be as surgical and minimal as possible.
A good compensation structure that would prioritize stability and consistency would pay an ongoing royalty to the relevant technical people based on the product's performance, uptime, and minimal crash/bug occurrence. "Hours worked" would be minimally relevant. One wonders if so many people would be so desperate to desecrate their production infrastructure if a high-quality work product and compensation were actually correlated.
But because we can't break out of the assembly-line 40-hours-per-week mentality, we pay developers as if they're line workers, and there's always got to be something on the line to keep those worker bees buzzing, regardless of the aggregate negative impact of constant uncoordinated meddling in complex systems.
> Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points
This hits painfully home for me. I learned a few weeks ago that some of my coworkers did something akin to this. They were working on what was frankly a mostly-silly project to preserve the relevance of increasingly irrelevant internal tools. Once they had produced something working, they stopped. Then they re-implemented the whole thing in Rust.
Which few in the company know or use. There are no clear benefits to this except exciting resume points for the developer in question.
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."
And they are all scrambling to data mine every arbitrary slice of the data to make it look like the musical chairs of features somehow drove conversion and the lack of bottom line fiscal performance is some other department’s fault for handwavy reasons.
If we embraced this philosophy none of us would be typing quickly on touch screen phones. Steve Jobs knew it beat a physical keyboard, and when pressed by people who complained about the new iPhone's touchscreen keyboard, he grinned and said "You'll get used to it." And oh boy, did they ever.
No, they didn't. They just stopped typing. Hence, bullshit UI's like Instagram.
> Steve Jobs knew it beat a physical keyboard
Yes, if by 'beat' you mean 'made it too expensive for general use'. But in general it was a huge blow to usability, productivity and general global intelligence.
But to that point, how many professional transcriptionists or programmers are using a touchscreen keyboard to do professional work now? Have we all switched over to touchscreen keyboards on our laptops yet?
Your mistake here is confusing a consumer device with something designed for a professional workflow. Touch screen keyboards are, objectively, not faster to type on than a physical QWERTY keyboard. It's like arguing that because my mom got used to a using a cellphone for photography that physical lenses are obsolete.
Again, this is (in my mind) something that mostly only happens in the software industry. A professional racer drives with a manual transmission. When automatic transmissions came out, nobody argued that professional racers were holding back the auto-industry. Meanwhile in the software industry, mention that your workflow benefits from corded headphones, and suddenly you're jeopardizing the future of progress.
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 superseding) regressions and inconveniences? And what is the cost in terms of time to route around such pitfalls? Would we still be able to have startups at all if products required thousands of hours of QA or perfect test suites in order to launch?
Second, if we were to set a hard rule 20 years ago that all software was to avoid this phenomenon during its development, what valuable tools and services would never have been developed at all? Would we still have Twitter? Reddit? Steam? Whatsapp? I don't have to dig far into the history of any of those tools to find near revolutions by their userbases over braindead UI or adversarial practices in the name of "vision".
I don't know, these are open questions. I just think avoiding all such frustrations you mentioned is wishful thinking and at some point it is just part of the process of experimentation and iteration. Or perhaps this process is entirely different in a small corp. versus a big corp. environment.
> Would we still have Twitter? Reddit? Steam? Whatsapp?
How many of those broke old workflows to introduce new ones with no clear benefits?
But that's not the point. We're not talking here about broad services like Reddit, Twitter, or Steam. We're talking about something more akin to a libary. You shouldn't break interfaces in a library without a strong, compelling reason.
Do things need to change eventually? Absolutely. Do they need to change today, because someone decided that the old workflows they don't like need to break for everyone? Maybe not. There's perhaps some room between the two.
It's been my experience that business software often represents a deep investment in a given workflow. Sometimes to the point where businesses are willing to spend a great deal of money to preserve those workflows and integrate new things into them - MuleSoft springs to mind.
Which is not to say that you're wrong. It's absolutely possible to develop new, improved software that's better in critical ways. Sometimes people and businesses are willing to put up with temporary regressions and inconveniences to gain substantial improvements. To use the above comparison, I've seen artists invest the time in learning how to draw all over again in order to jump from paper to digital.
What Slack has done is take away what was a perfectly functional workflow for many people. This doesn't look like a temporary regression or inconvenience. This looks like a permanent, hard break without substantial obvious benefits for people who used the old workflow. Communicating with users in a way that telegraphs very clearly that Slack doesn't care at all is just gilding the lily.
That's a place where the benefits of open source and hosting your own stuff pay off.
I can stay in older functional versions for a long time without being forced to upgrade and disrupt everyone's workflow because someone in a company thought they knew better how we should work.
Jenkins, Gitlab, rocketchat, review board all open source tools that you can be running years old ( on an isolated network please ) without upgrading and being very functional...
> 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.
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 going to give me something amazing that makes my life better, I may let you hit me in the face with a brick so I can get it. But if you hit me in the face with a brick and then you give me something worse than what I had? Don't do that.
Learning the basics of Vim was a really big, hard change for me, but it was an adjustment to my workflow that was made for a specific reason, that made my life better and that made me more productive, and that (importantly) was a decision I made voluntarily. It was not change for its own sake.
> Would we still be able to have startups at all if products required thousands of hours of QA or perfect test suites in order to launch?
On the contrary, how many more interesting, better chat apps would we have if every one didn't feel the need to reinvent Markdown? Wouldn't it have been more useful if instead of rebuilding their editor for no reason at all, Slack's engineers instead added new API endpoints, or experimented with encryption, or added new search tools, or addressed any of the pain points that actually get raised by professionals using their product?
I would also push back against the idea that this is simply the cost of experimentation. Vim/Emacs are much more experimental editors than Word, yet even modern remixes of those editors like Spacemacs put more thought into user customization and consistency than Word does. Spacemacs' keybindings evolve -- but they never force you to accept that evolution if it would break something fundamental to your workflow. And Spacemacs is doing way more experimental, interesting stuff than Slack is.
To add further onto that idea, prioritizing future innovation over the productivity of real users is a very software-specific philosophy about how a professional field should work. New animation techniques come out all the time, but we don't look at people like Miyazaki and say, "that man is holding us back." It seems to be a software-specific scenario where a change is proposed, users say, "I don't like it", and then engineers get somehow upset about that fact, rather than just saying, "cool, it was an experiment. Let's revert and move on."
I did not get into programming because I love computer interfaces. For me, being treated like a professional means that a company makes me specifically more productive. I don't care if a change makes things better for someone else if that change is making it harder for me to do something I love. As a professional developer, it is OK to demand tools that work well for you. Again, this is the case for every other field -- no one expects a professional woodworker to switch to a new measuring system that they don't want to use, even if that system is popular with some people.
Of course no field gets this perfect, but virtually everyone gets it better than us. I'm not demanding a theoretical utopia I can only imagine. I'm looking at every other professional field and saying, "why can't we have the stuff that they have right now?" It's very much a feeling that's informed by how good it feels today to work with physical mediums as an artist, and how utterly crappy it feels by comparison to use Skype or Windows 10.
And if that means that software moves slower, who cares? It's not theoretical to me. Other mediums are better to work in -- so whatever they're doing, we should copy, because they're better than us.
Good clarification -- when I talk about change, I mean a workflow change. XKCD aside, I don't believe that every code change breaks someone's workflow, or at least I believe that some code changes break workflows in such a minimal way that none of your users will care.
To expand on your point, how many bugs and crashes do we tolerate in software simply because rebuilding features has priority over refining features or handling more edge-cases?
Slack's new interface isn't just different, it's buggier. Stuff like copy-paste is broken. So it's not just that we have to adapt to a new workflow, we're also accepting a lower-quality piece of software that is less reliable than what we had before. And in theory a refactor or rewrite might be so valuable that I could tolerate that, but I don't see that value here.
This new hive mind of corporations empathising with the poor common man needs to stop. It is outrageously frustrating, condescending and patronising. Every CS rep is trained to say “I understand” more often than they breathe. Corporate blog posts wax poetic about their understanding of the struggle of modern life in the first world. How sorry they are to be doing exactly the opposite of what somebody would do, who actually empathised.
I will be the first to admit to a temper, but honestly if I hear one more CS drone tell me how much they understand, I swear to god I will reach through that phone and quiz them on it. Do you really? Explain it to me. In detail. So help you God if you forget anything.
Ugh.
You know, say what you will about the mob; at least they don’t treat you like you’re three years old.
That style of communication where a corporate entity pretends to be friendly and concerned even as they're downright shutting you down is extremely annoying. It comes across as dishonest and condescending. I wish this type of PR would go away.
If someone who's reading this works in social media, here's what would have been less annoying:
- Saying "it's not possible right now, but you have a point and we'll reevaluate this" (even if it's a lie)
This attitude to their rollout reminds me of the recent rollout of Twitter's maligned new desktop UI, the new YouTube Studio Beta, and reddit's new UI.
There is almost a meme of online platform service providers not understanding their users and their workflows, and rolling out new revisions that hamper or outright remove functionality that those users rely on.
I guess the canonical example would be that one Digg redesign that nuked the whole platform, or Snapchat's redesign a year ago that stunted their growth.
Luckily, we haven't had to experience this at Hacker News thus far ;)
> online platform service providers not understanding their users and their workflows
In regards to the Reddit redesign, I think the people complaining that "they ignore their users" are stuck inside a bit of a bubble.
I have a lot of friends who recently discovered the site, and they much prefer the redesign to the old one.
I forgot where I read it, but I vaguely remember stats backing this up, or at least increase in engagement or a reduction in churn for new users following the redesign.
Something like 50% of Reddit users are on mobile, for which the redesign is targeted (I believe)
Re: Slack, I know many non-techies who struggle with markdown and would welcome a WYSIWYG editor with open arms and wide smiles.
What are they using reddit for, though? Serious question. You can probably find 10x-100x the number of people who would use a site just for amusing cat GIFs vs. a location for actual discussion, but the users of each are looking for fundamentally different things. Reddit built itself on being a text-forward group of forums. The new redesign is, frankly, a dark-pattern horrorshow designed for eyeballs at the expense of deeper engagement. They're keeping old.reddit around for a reason.
I say this as someone who doesn't mind the redesign on desktop: The redesign is a shitshow on mobile. It's slow and constantly nags you to install the app.
Exactly... You don't have to expire the old front-end, you can build a new front-end on top of the old API, maybe introduce a few new functions in the API to support both old and new.
> Something like 50% of Reddit users are on mobile, for which the redesign is targeted (I believe)
The re-design just launched on mobile last week, while it has been on desktop for a very long time, so it is way too early to say what mobile users think. Personally I think that it is even worse on mobile.
I really wouldn’t mind the new UI, if it weren’t this goddamn slow (it’s at the point of unusable right now). My choice of using the old UI isn’t even a choice at this point.
It can’t be for people on mobile: the UI is buggy (especially back and forth navigation) and constantly nagging to download the native app. That’s super annoying.
> There is almost a meme of online platform service providers not understanding their users and their workflows, and rolling out new revisions that hamper or outright remove functionality that those users rely on.
True, but there's also a meme of people screaming bloody murder over a redesign for a day, and then being fine with it, e.g. [0]. Some complaints are worth investigating and some are just who-moved-my-cheese griping that can and should be ignored. It can be tricky to tell which is which though.
Smells of bad UX/design process - some senior "wants" this particular solution, despite their users showing direct feedback that it doesn't work for their needs.
I'd push back on your last point; there's a zero-sum feedback process here that is invisible. You're seeing the negative feedback from a vocal set of minority power users; the positive feedback from people isn't going to be known or seen in anything other than usage metrics.
You say "users": how many, what percentage, what cohort..you get the idea.
How do you tell the difference between unpopular features and ones that are mostly liked? In both cases, only "a vocal set of minority power users" would say anything.
With the state of statistics literacy in this industry, "usage metrics" often mean whatever the person citing them want, with no malice or deception intended. Accidental, inadvertent p-hacking is shockingly common.
Slack's voice is great when they're saying positive things, but God is it exhausting when they are replying to negative feedback. It's like listening to Ned Flanders, only with some extra patronizing emoji to rub it in
Did their engineering team not dogfood this change? What Slack engineer or product manager tried to share a `snippet of code` with a peer and thought, "yes, that was a pleasant experience. we should ship that."
Actually, the cmd/ctl-z advice is actually moderately useful. If you type it immediately after the closing formatting character it undoes the wysiwyg formatting. (I'm not arguing against a way to turn the wysiwyg input window off, however.)
That's a surefire path to irrelevance. Nobody wants groupware. Nobody uses it unless forced.
On the bright side, that would leave a hole in the market for an enterprising chat developer to fill, hopefully with something less annoying and resource intensive.
> Nobody wants groupware. Nobody uses it unless forced.
Surely you're talking about some very specific crapware subset of groupware, because plenty of people choose to use, and very much enjoy using, all sorts of groupware. Distributed version control, issue trackers, simultaneous editing of documents... just to name a few examples of incredible groupware.
But yes, generally when it claims to do all the things, it does none well. This is orthogonal.
The problem isn't implementing the features, the problem is making the UX/UI intuitive to people who call Microsoft's tech support when Firefox displays a "cannot connect to internet" message because they unplugged their router because they needed the socket for something else.
IRC is objectively superior to slack as a distributed chat client, but goddamned if the first step into slack isn't significantly shallower than the first step into IRC.
It reads more to me like whoever they hire to run their twitter doesn't have the authority/knowledge to engage with complaints other than being nice and saying "I'll pass that on". This would be fine normally, but not really when they've shipped a feature that everyone hates.
I know. I try to give the social media people leeway since they're almost always just the messengers. This thread in particular just seemed laser targeted to aggravate me.
If you are taking a job with you are specifically being paid to be a human shield, I am not going to hold back from treating you like the face of the company you are. The more abuse these mercenaries take, the more the corp has to pay to staff them, and the more the owners feel the pain of their misdeeds.
Is there any way that tweet could have been written that would have satisfied you, without actually agreeing to change course right away?
To me the tweet's tone says that they honestly care and don't want people to be inconvenienced, but also want to at least see if people will warm to it.
There has to be some kind of healthy balance between listening to user feedback and never changing anything.
The extreme version of listening to user feedback is: https://xkcd.com/1172/
> Is there any way that tweet could have been written that would have satisfied you, without actually agreeing to change course right away?
Not passive-aggressively suggesting that the problem is with the user and not the tool. "The goal is for workflows to evolve" effectively means "this is how it's going to be, you'll have to adapt (even if it's worse for you)".
My workflows have thankfully "evolved" to use different tools. Zulip and Discord both still use markdown input, and I no longer use Slack for anything.
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.
All code sucks now, not just blocks. Inline code screws up at least half the time I use it; it tries to guess what I want, and sometimes doesn't end when I close it with another backtick. And, when going back and editing it sometimes carries the formatting outside of where I put the backticks.
So frustrating. I hate having to think every time I insert code and re-do it about half the time; I'd rather have no formatting (just show me the markdown as-is) than this mess.
The worst thing about it is how fucking easy it would be to fix. Just treat the backticks as characters when backspacing or navigating with the arrows, that way you can 'enter' or 'exit' a code block reliably, and all previous muscle memory from the markdown editor would carry over.
But no, apparently that's too hard for a company that's worth more dollars than the number of seconds any of us have been alive.
I think there's a battle between nerds and non-nerds, and maybe in between is the worst place to land. I know some of my projects' users complain a lot about the lack of a WYSIWYG editor in our forums and issue tracker (we use Markdown, displayed plain until previewed or saved). Some people hate it. But I would hate a standard WYSIWYG editor, so we just accept the hate. Every Markdown-ish WYSIWYG editor I've tried has sucked...so I don't know that it actually is easy to get right (if it is even possible, where is the good example?).
Slack serves a mix of nerds and non-nerds, with non-nerds becoming a bigger and bigger portion of their user base over time. I can only assume it will become less and less enjoyable for nerds in service to the goal of serving their growing non-nerd users. For my own projects, I don't foresee myself ever using Slack (I use it for work). It feels like a decent product getting worse with time as it tries to be all things to all people.
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.
I definitely don't remember ever seeing or changing that setting, but it is 1000 times better with it off. Guess it's worth looking through an app's settings every once in a while, no matter how long you've been using it, just to see if there's anything new (or maybe forgotten) that would improve things for you.
On a high-density display, that 64px x 64px image covers a lot more surface area than 64x64 actual pixels on the physical display. I suspect that this 512x512px requirement is related to scaling factors on devices with high DPI displays.
I'm not even sure why we refer to logical pixels (a.k.a. CSS pixels, etc.) anymore, for exactly the reason you mentioned. We should be saying things like "this only needs to be 512px x 512px because it's never rendered larger than two degrees of viewing angle" or something to that effect. But I guess that's hard to think about... ems could be a good compromise.
There's probably a degree of forward-compatibility intended with that requirement. Slack may only display the image at 64x64 (128x128 at 2x dpi) right now, but they want to avoid requiring you to upload a new image if, at some point in the future, they implement a UI with larger action images.
That's likely due to HiDPI displays. A regular display is probably in the 100 DPI range, but we have phones that are in the 400 DPI range, so that icon size suddenly isn't so big anymore.
This is not one of those "oh, that's annoying, i'll have to remember that and learn to work around it" issues. It's more like "I want to immediately stop using this software but have no choice". Its driving me crazy - Slack is all text input. Don't break text input dummy!
I’ve already put my money where my mouth is and sent an email saying I intend to cancel all future payments to Slack unless they give the option to disable it, I suggest everyone else does the same.
I expressed my discontent to them as well and just received this reply:
"I'm afraid there is no way to disable this at the moment, and it's not in the roadmap to roll back on this feature. That said, we're still in the initial stages here, so our focus right now is listening to feedback as we consider certain changes for improvement as we move forward. You've raised some fair points here, so I've shared your feedback with my team for consideration in the future."
So their rollout methodology here was to go live with beta software, on production servers, to paying customers, and force them to find the bugs. Brilliant!
I'm sorry to say, but this is incorrect. Clicking that button hides the strip of formatting buttons, but does not return to the old text input behavior.
This is another argument against using proprietary SaaS solutions for such crucial purposes as business communication. There are free open source alternatives which give you full control and privacy: Mattermost, Riot.im, Rocket.chat, Let's Chat.
In >15 years what I have seen is that OSS comes with a huge cost of attention - that you'd be better off focusing on your business need.
Running most of these OSS even at a medium employee count scale is a full-team-commit-nightmare. It essentially means your it department now needs a specialist who will be able to handle your org quirks, remember the tweaks and keep baby sitting it. Not to mention many OSS teams (I don't know about the above listed) are ever so sneakily introducing enterprise clauses about usage in their EULA.
I don't want to name names, but even with paid software we are seeing this problem everywhere in trying to host: But at least here, we got the actual developers and experts on a call who can walk us through why x employees are fine and x+1 nukes their system.
Open protocols without OSS tend not to be particularly robust. In this instance, we have both: open protocols like Matrix.org, XMPP & IRC - and open source servers & clients (like synapse & Riot.im on the Matrix side), which are no longer an opensource curiousity but ready for primetime as Slack/Discord replacements. Just as Apache is ready for primetime as an IIS replacement.
We've had a perfectly good open chat protocol since... gosh, I don't even know. It's called IRC and it's so simple you can implement a server or client in python in under an hour.
This is what happens when you over-engineer things.
Slack just freaks out when I'm offline (or it even thinks I am). To the point I often just end up writing an email as it's less painful than using slack.
So corporate users can set up an IRC server; a network of per-user bouncers for offline state maintenance; an internal file hosting network for uploads; a bunch of server-based logging stuff and a central search repository to check history; train every middle manager to be an IRC server admin in order to add and remove people from channels for new projects; somehow intervene to disable DCC and other methods users could use to circumvent server-side logging; maintain their own fork of an IRC client in order to implement inline code, images, website previews, etc; break IRC's protocol in their client and server to allow text in excess of the maximum line length; and separately find a SAAS video/audio chat vendor or roll their own...
... all to save $7/month/person (or less for some competitors like MS Teams) because Slack is, like, too proprietary.
They could easily pay someone else to handle all that stuff just like we do with HTTP servers. We're not talking about the service, we're talking about the protocol.
> maintain their own fork of an IRC client in order to implement inline code, images, website previews, etc
These already exist. No need to maintain a fork unless you want to add features that don't exist in it. And since IRC is so trivial a protocol, that's not even hard.
> break IRC's protocol in their client and server to allow text in excess of the maximum line length
You don't have to break shit. Just split lines into multiple messages and piece together messages from the same user when they were also the last one who said anything, or use a character that means "message continues", or any of probably a dozen other ways you could implement that on top of the already existing protocol and that will still gracefully degrade on clients that don't support it.
Every time someone on HN says "you don't need x, just do a, then b, then c and you'll get something similar" I'm reminded of this comment: https://news.ycombinator.com/item?id=9224
Dropbox is just a hosted rsync server really [0]. The service has value, the technology didn't really require a new protocol except for lock in purposes.
I'm not saying that a service that takes existing ideas and makes them easier for people to use is bad, I'm saying that the open protocol people are calling for already exists, but because they have tech-brain they'd rather build a completely new protocol because it's more fun.
I dug around many years ago into dropbox. I actually found rsync was being used in at least some of its functionality. I doubt that remains the case, but it made me smile when I found it as it made a lot of sense at the time.
They certainly DON'T interoperate. I have a mail-tester score of 100, use SPF, DKIM and DMARC, yet Microsoft still sends all my emails in the spam folder. There's nothing I can do about it, it's a black box. The only suggestion from them is that I subscribe to some paid program with another company in order to maybe, or maybe not, increase the trust in my mail server.
I don't know about the rest of the software but Mattermost is easy to administer and requires minimal babysitting. I have it deployed with a simple docker-compose file which I only touch when I want to upgrade it, and there are Helm charts if you want a more production grade deployment. If I were to deploy it for my company I'd probably use the helm chart + a cloud hosted Postgres as the database and would likely never have to touch it between upgrades.
But you don’t want to go full ducking SaaS with things as well, where you don’t know what is coming until the ‘improvement’ is foisted upon you. Software gone mad. Spoken as a SaaS vendor
> In >15 years what I have seen is that OSS comes with a huge cost of attention - that you'd be better off focusing on your business need.
That’s not even wrong because nowadays almost all software comes with some OSS contained. So the non oss set is basically empty. I wonder if HN comes with a huge cost of attention because it runs on some OSS lisp?!
If you mean with "you" the operator of the tool, then yes I agree partially. But in this context it's more like "you" the user and then using open source alternatives doesn't make a big difference. Updates (which you generally want for security/good features/fixes/x) will still break your workflow regularly.
It's about how the service handles change (e.g. options to use the old interface etc.) that make the difference and not open source or proprietary.
There are many examples in FOSS that made user interfaces arguably worse and you have a hard time dealing with it, if you still need/want to run the newer version for other reasons.
Exactly that. There was an interview with Basecamp founder here a few days ago and he highlighted that even now when the current version is Basecamp 3 they still maintain Basecamp 1 for clients who don't want to make the change.
It being open-source (under your control) or not does make a difference here.
In an open-source thing, with this sort of productivity-harming breakage, you could worst-case just pay a random freelancer to fix it for you. You don't have that option with Slack.
That’s how you end up with critical apps which are full of known security issues because now upgrading requires reverse-engineering and migrating a bunch of one-off customizations. This approach only works if you’re committed to paying regularly to maintain your fork.
“upstream your fixes” only works if the upstream wants them. If you charge in saying “you're all dummies (per OP); here's a patch which goes against your project direction which I want you to maintain in the future”, that's probably not going to be very successful.
Thank you! I didn't know about Ripcord, and so far it is great. I am amazed how fast it is. I'm also depressed that this amazes me, as it basically does what mIRC did for me over a decade ago.
This is developed in QT by one person, and it looks pretty feature-complete to me. I really don't understand why a company the size of Slack invests all their development effort into such a subpar platform as Electron, when a native solution is clearly doable with very limited resources.
I really don't understand why a company the size of Slack invests all their development effort into such a subpar platform as Electron, when a native solution is clearly doable with very limited resources.
Several things I can think of: "quantity is not quality"; JS developers far outnumber everyone; making web apps look exactly the way they want is easy, and they are not interested in platform-native functionality, preferring a "consistent" UI across platforms instead; "premature optimisation" dogma that means no one cares about efficiency anymore.
Microsoft Teams and (later versions of --- they actually moved away from perfectly decent native Win32) Skype also use Electron, and that's Microsoft. That says the size of the company and its resources matters little in things like this.
Ehhh for Skype it's mostly a Skype thing. Pretty much every decision made about Skype be it platform, features, ... Is wrong. I'm convinced Skype within Microsoft is now some middle step they put their product managers through for a year or two without paying much attention to them, and each tries to implement his "own mark" on it as some sort of achievement. The alternatives to that theory are too scary.
> making web apps look exactly the way they want is easy
Its easy peasy with Qt as well. I am the only dev for https://www.sostronk.com/app and it looks (and behaves) _exactly_ as our designer wants it to. (Oh, and this is when I'm also spending time working on backend stories).
> no one cares about efficiency anymore.
That is not true. Discord and friends spend a lot of time for efficiency because they're using Electron. It is not impossible to have a (relatively) efficient application with Electron (VSCode for example), it just takes more effort. Compare that with Qt where performance is free of cost - in the last 5 years at SoStronk, I've hardly ever needed to spend dedicated effort for improving performance.
Another example, and I wasn't aware of this till very recently, is the Telegram Desktop app which is Qt as well.
But yeah, I do agree with your first point, the only reason Electron is in use is because JS developers are a plenty. At the end, cost is the #1 thing when businesses make decisions.
> as it basically does what mIRC did for me over a decade ago
When Atlassian finally pulled Hipchat last year I was tasked with finding the replacement. Turns out the one that met everybody's needs best was a local IRCd and whatever desktop client for it people liked.
Some problems have been solved correctly for a while; chat is one of them.
I am an old-time IRC user, but IRC is missing tons of features I use literally every single day in Slack. It does not have well-functioning and reliable file transfers. It does not keep history of discussions. It does not have media embedding.
"It does not have well-functioning and reliable file transfers."
I've never had a problem with DCC transfers, but I suspect I'm in the minority.
"It does not keep history of discussions."
Actually, there were several servers which had "MsgServ" bot which would remember your last logout time, and could go back to retrieve all those messages from its logs and auto-relayed them to you, all you did was ask it to replay missed content from x channel and you got it.
"It does not have media embedding."
If you used pIRCh98 as your client you had live video capability and could easily do a quick desktop share through OBS or similar software, but that did rely upon everyone using pIRCh98.
Slack is basically a modernized version of a mix of the best features that IRC clients and daemons and bot creators had.
The only thing slack hasn't seemed to copy yet from all the old IRC stuff is the ability to use mIRC as a desktop file system browser (that was fun to see being coded.)
If you have control of the entire IRC stack (the daemon, the bouncers, etc) you can work around a lot of those issues.. though at that rate, it's probably a lot less work to just host something like Riot..
Forcing each user to maintain an always-online machine is not really a good solution compared to just... having the history available to everyone, always.
Slack is more CYA than a store of knowledge. Yes, it's really great for pointing fingers: you can literally link to a specific message, saying "here, this dude made the call".
> It does not have well-functioning and reliable file transfers.
If only there were some sort of Universal scheme for denoting the Location of a Resource. That would let you map a relatively short string to one of many possible file access services, and put that string in a text chat channel, rather than conflating two distinct problem domains.
Also every server I know and most clients do logging.
I concede the snark and withdraw it, but my point remains: one tool for one job. There are tools for sharing files, and URLs allow those files' locations to be shared over text channels. One tool for one job.
I was about to ask the same. One of the things I badly needed was persistent logs. I googled around and found https://github.com/davisonio/awesome-irc which lists bouncers that serves the purpose.
Not really looking for replacement though (team is currently on Mattermost)
> I really don't understand why a company the size of Slack invests all their development effort into such a subpar platform as Electron, when a native solution is clearly doable with very limited resources.
A lot of reasons... a solution 1) grows to match the size of its budget constraints 2) becomes more complicated the more people with long titles have a say in it 3) becomes more difficult to implement the more people that are working on it 4) becomes less useful the more people there are that can dictate what it does and how 5) fulfills more of the letter than the spirit of its requirements as more hierarchies of people manage it 6) becomes less user friendly as fewer typical users are involved with its development
Though the actual answer is "somebody with power just wanted electron for personal reasons and nobody had the power to turn the ship once it started on its course"
Keep in mind that Ripcord only needs to implement support for whatever Slack has already decided to implement. They don't need to do the whole "iterative design" process (which Slack is doing for them), which is precisely the part where C++/Qt things tend to fare poorly.
That doesn't explain why Slack seemingly can't do it. They could literally hire the Ripcord author and pay him to continue development, and sell Ripcord as Slack Lite. It would be peanuts for them, and it would vastly improve their product offering.
Wee-slack was my go-to for the longest time but can no longer use it and it makes me sad... The problem with it now is that they had to migrate off the legacy API tokens. You now need an administrator to authorize wee-slack as an application for your organization. Not all organizations are willing to do this.
I seem to remember reports of people having their accounts suspended for using third-party clients (though I may be thinking of Discord accounts). Either way, I've used ripcord a bit and though it's not much to look at, it certainly gets the job done. I'm personally grateful for an alternative.
WRT. Ripcord, from what I've heard (I can't find the source now :/), it was Discord, the bans were due to a bug, and were promptly lifted after contact with support. But perhaps there were other bans I haven't heard of.
Same here. I've already mostly adapted to the new editor. There's some annoyances, but I love not having to send to myself just to see what the message will look like and how Slack's version of Markdown will interpret my formatting.
I wouldn't have a problem with this _if_ this were configurable. Its not. This is two pretty good UI/UX screwups in a row by Slack (this, and threads)
Slack's good at engineering and development. They used to be good at UI/UX, but whoever over there in the text entry product design slot is having a case of the Jony Ives.
I bet the majority (like 95%+++) of users are like that. I'm technical and while I've only used it for 1 day so far I still sent multiple code blocks and used formatting as usual. Maybe I'll run into problems but so far it's very much a whatever situation IMO.
A “preview” button would have facilitated this. Or even better, let users edit in the preview input if they want or the regular editor, switching back and forth as desired.
Funny enough, I kind of like it better - the way that the enter key changed in and out of a ``` block would always screw me up and I'd end up sending messages before I wanted to, and then instead of bugging someone for 1 message I have to send 3 with the middle being "sorry, hit enter too soon".
I feel like this is the way of things with Slack: poorly implemented new features are introduced with no way to disable them, and a significant portion of their users end up needing to work around them. I'd love to have time to research replacements for my employer's use of Slack because they clearly care more about being "innovative" than meeting the needs of their existing userbase.
Other examples:
* The UX around threads is still horrendous, and there's no way to turn it off.
* There's no way to turn off "drafts", which still causes me to lose messages I'm working on.
What don't you like about threads? I think they're actually my favorite Slack feature. I find myself missing them in more casual chat apps like Discord.
Threads turn every slack channel into a multi-headed hydra. Now, in addition to keeping up with updates on slack channels, you're also having to keep up with updates to threads in slack channels. Worse than that, if you're looking for an old thread you have to remember the channel it's in and the first message that started it if you want a hope in hell of finding it, since the threaded responses don't (normally) show up in the channel itself.
While I understand why this change can be annoying to the tech savvy folks of hackernews, it can be quite helpful for those who aren't that tech savvy and want easy ways to bold, italicize texts (that make up majority of the slack user base). Heck I am sure most of the slack users wouldn't even know it was possible to bold, italicize on slack using markdown.
Why does everything need to cater to idiots instead of making them learn? If we continue down this trend we’ll end up with keyboards with a single button to cater to some monkeys out there who can’t manage to use a proper keyboard, at the expense of everyone else’s productivity.
Because they’re not idiots but rather people with different priorities and backgrounds who were underserved previously. You might disagree that this is helpful but it’s unlikely that you know more about Slack’s users than their UX team. Treating everyone involved with respect is a much better strategy than what you’re doing.
Why does that justify conforming the user to the software? Software, especially web software, has this magical quality of doing different things for different people even at the same time.
> Treating everyone involved with respect is a much better strategy than what you’re doing.
They're not treating the users who prefer markdown formatting with respect at all. It's basically: "fuck those guys, we want to cater to a different audience".
in my experience it is not uncommon for product development to involve assertions that “some of the users are not the most tech savvy”. i’ve seen this as justification for cutting scope, which i can agree with in many situations even if i disagree with the reasoning. over all, cutting scope had been the right move.
that said, i take exception with these claims that the user is “an idiot”. it comes off as arrogant to me.
Wasn't the target audience of Slack, at least initially, tech-savvy IT teams? If they take away plain text and markdown -- or make them harder to use -- they are alienating their early adopters.
Not sure what their user base looks like now, though.
I've seen it used in some surprising places. Last time I had my contact prescription checked, the staff used Slack to communicate between the doctor/assistants in room and the front desk.
Why does anyone (tech savvy or otherwise) need to bold or italicize anything.
In my mind bolding/italicizing are nice-to-haves alongside emoji. You wouldn't compromise the entire functional user experience of the central feature of your app for nicer emojis. (at least I hope not).
Please reread my comment. Italicising is, as I said, a nice-to-have. I did not need to italicise need; it's an optional extra in my comment, but I can still communicate effectively without it.
Or, as your reply has highlighted, even with the additional emphasis, people will still fail to read it the way it was intended.
Honestly, the unsatisfying answer is simply because they (i.e. those of us who didn't grow up on IRC, like marketing teams) want to, and are used to being able to do it elsewhere. I'm sure the people who include images in email and set their own fonts and stuff are happy with the upgrade; I can especially relate to that since I used to do some marketing and sales work myself.
I also hate the new input field but I understand why they turned it on globally. But a strong enough want is often indistinguishable from a need.
I myself use them sometimes to emphasize certain parts of the message. They can be very helpful. Many people like bolding certain words in an email as well to emphasize them.
Uh... you just have to press the right arrow to get out of the code block when you type. Seriously, that's not even one more key press, that's just pressing "right" instead of `
If it is the primary method of communicating within your team/company, then you will find it difficult to not use it, or rather you will be left out of major decisions/changes.
You’ve described the pathology and first reason to NOT use chat for anything important. What am I supposed to do? Sit on the chat all day so I don’t miss anything? I’m on a team that does this now. I ignore the 100 to 1000 plus messages and memes a day and I have missed “important decisions”. It’s a net negative imo.
I work on a remote small team, but we work on a highly complex, large code base.
We rarely pick up a phone, and we do not use email. Everything is 100% Slack.
This works well for us. You can bring in only the people you need, you can "star" messages and channels that are important, and none of us have any time to spam/meme the channels, so it's 100% business. We integrate the JIRA slackbot to keep abreast of what is going on in JIRA.
If your team is sending memes all day, that's a cultural problem. Slack is exposing the problem, not creating it.
My employer uses Slack. Our team channels are almost completely devoid of cruft. There are office/location based channels that contain more bloat, but those are easy to ignore and typically don't contain critical information. All of the "all employee" type channels are locked down.
This comment literally illustrates the pathology described by its parent. Not all organizations are cults run by cliche fascists who crush subordinates who make that kind of criticism.
Funnily enough I was hired on a 12 month contract as a software developer.
Four months into that contract I was moved over to a struggling 'Slack' enabled project, to help them work through their ever growing backlog.
I knew someone working on that project and discussed with them the project's use of Slack only to realise it was nothing more than a talk fest and not for me.
So when the project manager approached me, asking if I would like to join in on the Slack discussions, I declined.
Needless to say that did no go down so well.
However, I stuck to my guns and 12 months on my contract was renewed.
To this day Slack is still not part of my daily development life.
99% of the time, Slack is nothing more but a glorified, shitty messaging client. And most people I know don't even know why they're using slack, it's just that it's the tool they think everybody uses, and they don't really see why they should look elsewhere.
Why so snarky? The parent poster asked a valid question, and "my organization relies on it and de-facto mandates its use" would have been a good answer.
> I'm confused, do you honestly believe the person I was replying to doesn't know that Slack is critical comms infrastructure at a LOT of companies?
As the person asking that question, no. I've heard it's used by some people ... for things.
Just like I've heard some companies use IRC for chat, and some open source projects use Discord where you can join if you feel like it.
I have no idea what its primary use-case is, who its primary audience is, and to what degree it's more critical than IRC or email or intranets to anyone.
Your comment started off about you and was dismissive of Slack. Saying "How so?", in general, is not handled by people as a genuine and sincere question, it's usually laden with an "I don't believe you" vibe, especially with the dismissive nature of the lead-in.
If you had asked instead:
> "I've haven't really used slack, didn't really see the use case. Why can't you stop using it?"
> Saying "How so?", in general, is not handled by people as a genuine and sincere question, it's usually laden with an "I don't believe you" vibe, especially with the dismissive nature of the lead-in.
I don't believe that. I think it is a perfectly fine question, and don't find anything wrong with the way the post was worded. Based on my personal experience, I think my interpretation is the general one.
From my 30 years management experience, your personal experience is not what I've seen. Maybe works in small teams but not with strangers; too short, too abrupt and provides little to no context about the desired answer.
For example, in the case above, was the "How so?" directed at the "immediately stop using it" part or the "have no choice" part? Both?
> Saying "How so?", in general, is not handled by people as a genuine and sincere question, it's usually laden with an "I don't believe you" vibe
That sounds like an extremely regional interpretation, and does not consider that the question was asked in good faith, something the HN guidelines specifically ask you to assume[1].
Why would this person know that? Speaking from personal experience, I myself did not know how critical it is for some as I do not use it day to day (I heard some anecdotes sometimes, but that's it), rarely ever used it, and only recently experienced it in a setting were it was Slacks all the down.
They previously looked at Slack and never found it appealing, they are replying pretty deep into a massively popular HN thread and their question was a pretty snarky "How so?". Maybe my snark was unjustified but I'm comfortable with it.
"How so?" isn't snarky at all to me. It's a rather legitimate question one may pose to somebody who just said they'd stop using a product but can't. The answers could be one of a wide variety, like vendor lock-in, network effect, contractual obligations, or company policy, no viable alternatives (because...), or something entirely unexpected.
I'd actually be interested in the answer from grand-poster as well, if only because I am a curious asshole.
I've never worked at a company that uses Slack. I don't particularly understand what people use it for or how what as far as I can tell is a glorified IRC channel is allegedly so important to some teams. Get a whiteboard.
They all use the same "interface". XMPP/IRC would be different interfaces. I can use whatever client I want, not some client that is specifically coded for Slack.
I don't need ANY changes in my XMPP/IRC client to connect to a server.
But the reason why Slack discontinued XMPP/IRC is clear. They want people to use their shitty app/website.
In a conversation thread that’s all about “UI interfaces”, feels a bit pedantic to me to harp on defining “API interface” as your only valid “interface” definition, especially as there’s a plugin (https://github.com/wee-slack/wee-slack) for a popular IRC client to integrate with Slack’s “websocket interface”.
Actually, that’s not clear either (even if it was GP’s intent), it’s simply your bias coloring your perspective. Other folks could easily define interface as the Slack apps, especially in the context of this thread.
Many folks I’ve talked to don’t realize there are alternative ways to connect to Slack still once the XMPP / IRC endpoints died. They think the only way is using the Slack developed apps. Thankfully, that’s becoming more and more not true each day.
"connect" seems clear to me. But anyway, doesn't really make much of a difference.
>Many folks I’ve talked to don’t realize there are alternative ways to connect to Slack still once the XMPP / IRC endpoints died. They think the only way is using the Slack developed apps. Thankfully, that’s becoming more and more not true each day.
Which are? Using a proprietary Websockets API is not "another" way if even the Slack app is using that (not sure). The main difference to XMPP/IRC is, that with the later ones not a single line of code needs to be written (not from me and not from IRC/XMPP developers). Just use the client you like, set server and credentials and you are done. That's why there are protocols.
>Slack uses Websockets. Websockets != to HTTP.
port 443 is close enough and http is needed to start anyway :P
Slack’s old formatting syntax was Markdown-like but not exactly Markdown, just similar. In case anyone from Slack is paying attention to their technical users here, this is a great opportunity to move to CommonMark formatting for technical users and wysiwyg for non-technical users: just make this optional and switch the format syntax for the non-wysiwyg mode to CommonMark. I can understand that changing the formatting on people previously would have been disruptive, but that is no longer a viable excuse: you have already disrupted the lives of programmers far worse than changing to CommonMark would have done and switching markup formats won’t affect people who stay in wysiwyg mode at all. If you reintroduce Markdown mode now using CommonMark, programmers will just be happy that they can use Slack effectively again and as a bonus, you’ll match GitHub and everywhere else programmers hang out.
Regarding Slack’s attitude about technical users whose life this disrupts, I can see that the calculus may appear to favor the non-technical users: there are probably far more users who have no idea what Markdown is and never need to share code snippets on Slack and who are happy with the new wysiwyg editor since it’s closer to what they get from MS Word and Gmail. However, technical users have massively outsized influence over the choices of technology at most companies. The IT dept is full of technical users who share code fragments all the time. Don’t you think they’ll be keeping an eye out for new chat platforms after this change? Tech startups are (almost by definition) mostly technical users. Do you think any new tech startups will willingly use Slack after this change? Some of those would have been paying customers and a few of them would have become huge paying customers. Now they won’t. I know I’m actively looking for alternatives now and I have controlling influence over what gets used in several paying and non-paying Slack instances.
If you reintroduce Markdown mode now using CommonMark, programmers will just be happy that they can use Slack effectively again and as a bonus, you’ll match GitHub and everywhere else programmers hang out.
Please please do, Slack. I filed a support request already asking how to turn off the new editor.
While we're at it, let's have syntax highlighting of inline non-snippet code blocks.
Slack probably has statistics which indicate that by now their largest user group is non-techies. And i'm assuming that if you look at paying customers, the amount of non-technies is probably even larger. People who are probably not even aware of this thing called markdown. So if you need to increase revenue replacing markdown with wysiwyg will make sense to UX and product management.
Sadly I think this is just another case of product adoption largely being driven by techies in the early stages because they loved it, and later in its growth stages realising their market is now way more mainstream and designing their features as such. And now we're alienated by the same product we helped spread.
Twitter is another obvious example I can think of.
Nothing to do with self respect This is a completely accepted and promoted way of growing your product. See for example the strategies outlined in “crossing the chasm”. Techies are in this case the early adopters, and now that slack has crossed the chasm, they are targeting a completely new user group, the early adopters, with a new set of needs and wants.
Time to move to a new product which still focuses on techies.
As a member of user minorities - the "tech savvy" niche and "knows software can be ergonomic, and expects that" niche - I'm already avoiding using new "innovative" products. The story is always the same - people with needs are used as tools to drive initial adoption, and then the product self-destructs trying to chase the lowest common denominator.
FWIW, I wouldn't even be using Slack if I weren't forced to, like probably most of its users. Regular employees don't have much say in what companies use for chat, nor do most people in communities in what tool was used to start them.
I'd do it for a boatload of cash but not any less. Your core tech users are still selling your product for you, free of charge. Unless it's abuse/fraud/security mitigation there's usually a way to keep your technical customers happy along with your new user base. It obviously has a cost but if you're making dramatic changes that alienate your early adopters I'm sure that those changes are going to do some needle moving in terms of increasing your profits. No one would do something like that on a whim...
That cost does need to stay within reason though. And something crazy like maintaining divergent architectures/infrastructure isn't really reasonable either. But on the bright side the technical folks might be understanding of these sorts of tradeoffs.
Why not try to satisfy both kinds of users? Options and customizability are a thing. One-size-fits-all seems to be the current software trend, but it wasn't always like that. Maintaining a piece of UI that was already there shouldn't be that expensive.
They don't have to. It can default to simple behavior, with the "techy-friendly" options hidden behind a "Settings - Advanced" menu or tab that regular users won't even visit.
Most people I know don’t even know WhatsApp supports Markdown.
That said, none of them are complaining because it’s a chat program. You don’t need heavy formatting in a chat program, it’s meant for short and fast messages, unlike email.
As such, I don’t believe people will spend a lot of time formatting their input in Slack, unless they really are thinking people will replace their email with Slack.
It's by far the most popular messaging platform in Brazil[0][1]. In other places in South and Central America it's also about as popular as in Brazil, so I suspect the majority of internet-connected people in America use it.
That said, WhatsApp is not a tool I use mostly on the computer to talk to my tech friends and co-workers, where I need efficient ways to communicate both using pre-formatted/code lines and in natural language, where things like bold, italic, quotes, etc become important tools to convey the right message.
In English, “America” refers to the USA, 99.9% of the time. (This is not just true in the US but also in the UK and I am pretty sure other English-speaking countries too).
What is called “América” in Spanish and Portuguese, we call “the Americas” and consider to be two continents (North America and South America), not one.
I have no opinion on which usage is “correct”. Just pointing out that the person you’re replying to almost certainly used “America” to mean the USA, not the land mass that includes Brazil.
I’m always a little wary about these claims. For example I worked at a Fortune 500 before and I created a setup on an app like Slack using my corporate email account.
There is a big difference between “used by company Y” and “used by tiny team X inside company Y” (probably without IT approval).
Agreed, just saying x is used at y is meaningless, especially when that company is a multi headed hydra like google or MS. I see it so often with languages these days but I'm pretty sure you could find a team in a huge company like MS programming in TCL all day.
We're getting teams which I'm a bit excited for since it is going to be a company wide replacement for Lync/Skype for business and no developer here has ever used Slack, IRC or anything like this.
Sorry to end your excitement, but it's basically identical to Skype for Business.
As I understand it MS has been covering the two (in both features and design) so that at some point one or other will be deprecated, but that in practice all that means is a name change for those users.
Group chats in Skype don't happen, messages are stowed away in outlook under past conversation history and everything you send on Skype for business is a new conversation @tagging the recipient (singular in almost all cases). And everything to be brought up with multiple people thus ends up being an email chain after the Skype convo.
It's COBOL, but my first software development job. It's a good pay for a novice-dev in Sweden ($44k/yr and our currency has dropped by 1/3 compared to the USD).
I like the language and environments, and it's fine that almost all developers are close to retirement, they are great libraries of knowledge after having worked in the system for 20+ years.
It's mostly the legacy ways of working around here that are an annoyance, communication by email and having to wait for order- and project numbers before starting any development, instead of being allowed to develop improvements that can just be implemented when/if they get the ok.
The wait time does allow me to create some automated tests of which we had absolutely none, that other young developers here also benefit from.
I'm gaining knowledge and the system seems to be getting replaced in not that long, at which point my fiancée wants to move back home to the states, but health insurance woes has kept me from looking into that.
I am in a similar position. It is almost always the technical people in a company that sets this stuff up, thus you are losing the goodwill of the decision-makers, which is unfortunate.
You can submit feedback to Slack using "/feedback" command. The nice thing it appears they have real people give you real replies. I encourage people to use it.
I asked them for the option to turn it off. An excerpt from their response.
> ... we understand that this has caused a disruption in workflows for some of our more technical users. While we don't have any active plans to make this configurable at the moment, we are in the process of collecting user feedback so that we can find a way to make it work for everyone.
> 'While we don't have any active plans to make this configurable at the moment, we are in the process of collecting user feedback so that we can find a way to make it work for everyone.'
It's like the answer to the second half is in the first half of their statement.
There are definitely several things that I don't like about Slack, but their support has been very responsive. I've reported at least two issues, and they have always taken my input seriously.
A while back, I reported a bug with copy/paste, and they asked questions, acknowledged it, and had it fixed by the next release.
More recently, I had a question about why the UI behaves in a certain way I didn't expect, and they took the time to explain that it was intentional, and what their reasoning was for doing it their way instead of how I expected.
All of these experiences are way better than average for our industry, which in my experience usually just brushes you off without trying to understand your issue and tries to placate you with a non-answer or answer to something other than what you asked.
I agree. Usually Slack's support is wonderful. But with this awful WYSIWYG input debacle, their support has been... subpar. A whole lot of non-answers and dismissive "we're collecting user feedback".
Just remember, the people who read and respond to you are probably not the people who either implemented or designed features and bugs you may run across.
Yes. Its crap, but telling them so will achieve nothing (management obviously think its wonderful).
I'd love to know whose idea it was, though.
Maybe next time you could try congratulating them on "clever self-disruption of a successful product" or something similar to draw them out into the open.
The journey from hacker-friendly comms tool to mainstream train wreck must be quite a story.
I wish Enterprise software or anything where I have to pay money to use had strict contracts about changes and mandatory opt-ins.
It's ridiculous that in this day and age, we have to be worried about some PM deciding for large swathes of users what's best for them.
I just want my tools to be predictable and usable and not have to relearn every bit of quirk someone fancied.
And it's insanely myopic that software companies don't understand that stability and predictability is a feature you best not mess with when it comes to _tools_.
Could not agree more. I hate the world we are building with SaaS type software where the user (me) has no control at all over versions, when/where, etc. I honestly think I may prefer the old "buy a shrink-wrapped copy" approach. Back then it was rare to run into bugs, and nobody ever "upgraded" me without me knowing and radically changed the UI. Maybe I'm just being grouchy and "get off my lawn"ish, but dang.
I'm going to take the opposite of this argument, and for bonafides, I run the product team for a 1000+ person company.
I'm going to assume that this thing was tested out the wazoo, both qualitatively and behind enough feature-flags and buckets to keep Optimizely in business for a year. So I have no doubt that this wasn't just a hunch on their part, but something that they meticulously tracked. If I'm wrong, definitely let me know.
Anyway, the main point, what percentage of people do we think knows markdown to such an extent where it's easier for them to use than a WYSIWYG editor would be? I'd venture on HN alone that number is <10%, and considering Slack is used by a far wider and less-savvy audience than on here, I don't have much of a problem with the reasoning behind the change.
I think the lack of backwards-compatibility is a legit criticism, and sure, an opt-out would be nice, but I don't think for a second that this is as egregious as people are making it out to be.
As someone who runs the product team for a 1000+ person company, the concept of intransigent minorities should be of interest to you. [1]
The gist of it is that an intransigent minority can often dictate the choices of a flexible majority. It is unwise to make decisions based solely on majority rule, as stubborn minorities can affect complex systems in ways that you do not expect. The phenomenon can be verified in a variety of situations across history.
To put this into context for Slack, I believe technical users have been particularly important for the app. Tech users were early adopters for Slack - I'm sure a lot of corporate accounts started out with engineering teams. Tech users wrote the chat bots and integrations that Slack is known for. They got people to use Slack, and they can get people to stop using it.
Let's say you're changing the way a certain feature in your application works. The majority of users are happy or indifferent about the change (but weren't particularly bothered by the old behaviour). A minority of users not only reject the change, but are vocal in how much they hate it. They will not tolerate the new behaviour, and will try to get other users to abandon your product unless you resolve the situation. What do you do? You can ignore them for now, but can you predict the long term effects of turning your back to the intransigent minority?
And I'd add that inclusion is especially important for a tool that's supposed to connect everybody in the company. Thinking that one can ignore a chunk of the audience because they have no choice but to keep using your product is at best confused, and at worse displaying enormous arrogance. It's the sort of enterprise-grade nonsense that Slack was initially seen as an antidote to.
I get that things that want to be popular quite often shiv the early adopters as they become mainstream, as a) that particular orange has been well juiced, and b) satisfying early-adopter needs really can get in the way of that holy grail, maximizing revenue.
But here I don't think there's a big conflict. There are a bunch of ways this could have been done to make everybody happy. It could have been opt-in for a while and then opt out. Or as others point out, there are apparently good WYSIWYG experiences already out there. With a market cap of $12 billion, Slack could afford to buy one, or at least the team behind it.
The only explanation I see is that it was rushed out the door to meet some executive's goals. Which suggests that Slack is becoming the sort of clueless, sales-driven, user-contemptuous company the initially aimed to overthrow.
Everyone that was using slack was clearly aware of backticks, underscores, and stars, which is really the most you need, and probably 99% of everything used.
Surrounding some text with these marks to achieve some formatting is hardly rocket science. If someone doesn’t do it it is really because they don’t want to understand.
If you however make an editor that fucks up using any of these marks? Well, that’s a big time failure.
Exactly, all the cool kids were using backticks, underscores and stars. Naturally the lesser users would figure it out just to fit in. Everyone feels mildly powerful being able to wield a tool like this as trivial as it is. Now we're all just back to being bottom feeding piker fish toiling away on word docs.
I work with a bunch of non-tech people. I get what they're doing. The techy people are the only ones who bother using ` for anything. I have no idea if non-techies will start now that there's a button for it, but typing it is now really annoying for everyone who has been using it.
I kinda reminds me when Confluence added their WYSIWYG editor--or using Frontpage. I basically /had/ to go to code view to get the page to look consistent. So far Discourse has been my favorite implementation, with preview being off to the side. I'm sure that would eat up too much real estate for Slack.
>Anyway, the main point, what percentage of people do we think knows markdown to such an extent where it's easier for them to use than a WYSIWYG editor would be?
Well, Slack supported so little of Markdown that this is a moot point.
If they had all those metrics and that many test users, how could such obvious backtick issues exist?
Even simple dog-fooding by their own internal coding team should have revealed that issue.
If they had a test group, it was definitely a group that didn't use those features to begin with and basically didn't use them in the new UI either. Meticulously tracking the wrong sample group simply leads to reams of bad data.
It's logical from a short-sighted perspective as I'm sure it looks good to investors to have a longer checklist of features. But shipping a broken feature is eroding customer trust.
Since moving companies, I have traded slack for microsoft teams.
Teams is pretty terrible in comparison, one of the most annoying "features" is it's WYSIWYG editor, I have no idea why slack would want to copy one of the worst elements about teams.
Teams is way worse than Slack. So's Facebook's Business Chat offering, which I find less horrible than Teams at least but it tags along with their "business social" application, and those are always useless crap.
Though it's been a year since I used Slack and from the look of things on here, they're trying their best to catch up in the bad-UX department. The drafts thing that moves channels around seems awful, too.
Fuck slack. They're hostile to user choice and preferences, pushing a one-size-fits all attitude. Communication preferences are extremely personal and must be respected.
I have a custom ssl proxy to intercept slack.com and modify their api, eliminating what I believe to be dark patterns. Some things I do:
* Force dark mode always
* Disable favicon.ico updating when there are notifications in DnD
* Group channels based on name prefix (stealing behavior from an add-on)
* Ignore bots
It's hard to keep this up to date so it's not really that robust. If I open source it I know I'll get legal pressure from slack, not to mention they'll probably try to block it.
What is currently driving me crazy about slack is that:
1) Slack constantly makes subtle changes the UX that always takes a bit of time to figure out, I don't want to read update notes to find out how a critical comms tool has changed eg. yesterday the mac chat became psuedo wysiwhg and it broke my muscle memory and stuff bounces around while I'm typing, eg2. Drafts: FU, I didn't ask for you to reorder my UI around so I can't find stuff, DON"T CHANGE MY MENUS
2) Bugs, I left hipchat because they couldn't stop breaking stuff with every update. Many of Slack's changes are "breaking stuff" until you figure out what they've changed.
Right! Thanks for the reminder. I don't understand why drafts weren't just a list of links to the draft and LEAVE the original channels where I explicitly put them when I was curating my channels.
It's such a common problem with graphical interfaces in general. If only we gave our users the same affordance we give developers with versioned API's. We shouldn't be breaking interfaces haphazardly, and that includes the visual interface.
Yeah, I've always hoped they would change their position on supporting markdown. Their big report on it says they will never support it. Looks like this might be why.
I tried speaking to support to find out if I could downgrade, some of my colleagues don't have this feature. They couldn't(/wouldn't) tell me how to.
One thing that isn't mentioned is the behaviour with pressing up to edit a previous comment, it will put you into the span if the span goes to the end of the message.
I've also had numerous times where the span hasn't closed correctly leading to things in backticks not being formatted correctly (I'm guessing timing issue due to their move to react for this stuff).
It's incredibly annoying. If I didn't have to use slack for work I'd probably bin it.
After reading this post, I don't really know what this new feature is. I'm part of the 'enterprise' crowd and we tend to lag behind in 'features'. I do know about Slack's 'deal with it' attitude, though.
When the new 'draft' feature came out I desperately wanted to turn it off(I really hate it). I opened a support ticket and spoke with one of their team members. I basically got an "It's what our customers want" kind of reply. I am the customer. Why can I not disable/enable it in an options menu somewhere?
This post says it all: 'If you prefer the old interface… well, screw you, says Slack. ... I wish Slack would provide a way to disable the WYSIWYG rich-text-input box. I don’t think it’s useful, and it’s extremely annoying...'
I want to chime in with one editor that I think nailed a markdown WYSIWYG: https://www.typora.io/
It's hard to explain the concept with just words, but I will try: While you're typing, markdown is fully exposed, but when you move the cursor away, the formatting characters disappear and you just see pretty formatted text. As soon as you move the cursor back to the formatted text, the markdown reappears so you can edit the plain markdown syntax.
I've been using this editor for two years and I think the developers were really clever in this implementation; I've never experienced any unexpected issues. Slack, on the other hand, has been driving me absolutely crazy. (Try changing an inline code block after you've created it. Easy in Typora, a nightmare in slack.)
I just tried typora. One gotcha is say I'm in a triple backtick code block and you accidentally start typing the next non-code paragraph in the code block. There seems to be no way to end the code block (eg the equivalent of typing the ending triple backtick somewhere) without deleting the trailing text accidentally added to the code block.
That example worked fine for me, the second example (a variation on the first) worked as the article described. Once foo() was "code", I couldn't update it (at least I couldn't discover how to do so outside of killing that bit).
I'd bet the first example didn't work at some point, and then was quickly patched.
The second example worked correctly seamlessly for me as well. I can easily edit text inside a code block in the WYSIWYG editor. Maybe they just patched that too?
Hmmm... possibly testing a patch... I still can't get it to work and checked for updates before trying. There could naturally be a difference in our sequence of steps, too. Once "foo()" is entered and detected as code, I can't add "bar." after the fact. I can add new code text in the middle of the detected code.
I've given up entirely on the Slack desktop app and use Ripcord exclusively. Much faster, more responsive and easier to use for 99% of my time spent on slack.
Pah. Next you'll tell us that once Ripcord shows you some messages, its "N new messages in this chat" notification actually goes away. Now that would be a killer feature, if Slack managed to implement it.
The speed difference between Ripcord and Slack is just night and day. I had forgotten applications can respond faster than I can type, yet here we are.
My main complaint about Ripcord is that it's non-FOSS, which is somewhat concerning to me (the price is a non-issue; I'd be happy to pay the $20 if that comes with source code access). Sure, Slack itself ain't FOSS either, but I'm more inclined to make it as FOSS as possible (e.g. via Rambox or in an actual browser like Firefox) than to switch clients.
It also doesn't seem to acknowledge my starred channels; while the bookmarks are better anyway, those don't carry over to my phone or my other computers.
I just tested ripcord and it didn't seem to work very well on Gnome. Didn't do dpi scaling so it looked tiny on my main monitor and the notifications showed up pretty broken.
Gnome should probably have the correct DPI values, since it's a complete DE, but I'm guessing something has gone wrong with the way the Qt version that Ripcord uses is reading the DPI values.
It would be better if this always worked out-of-the-box 100% of the time, but Linux desktop environments are quite varied and it's hard to handle every case while also not limiting support to specific desktop environments and versions.
I just checked the screenshot. It reminds me of Windows 95.
What I feel like one app can't fit all. Some people want a faster response time rather than a modern design and vice-versa.
Talking about slack new input box.
The non-technical person would be more than happy with it. Because they don't know markdown and something that works like MS Word is good enough.
Sadly they aren't going to implement some of my most used features from slack in ripcord so I stopped using it. Was ready to pay a ton of money to the dev as well.
I'm pretty sure there are others in that list which are also standalone thirdparty clients, but clearly they would not be listing those on their own site and providing plenty of API docs if they forbid them.
I've found "developers", people who work extensively with plain text and mark up languages, mostly hate WYSIWYG. Because it just gets in the way of / works differently than the skills/knowledge they already have.
I presume people who primarily work in Word/OpenOffice/Whatever Apples thing is, feel the opposite.
If your customers include both, UI is basically impossible to get right for everyone.
1. I used to administer a mediawiki instance for R&D at a mid-size enterprise software company. It was used by perhaps 300 people. Many, many developers disliked wikitext and wanted a visual editor and/or word-to-wiki converter. Some people just prefer wysiwyg over markup.
2. If your customers include a meaningful population of both, _include both_. Make the 'friendly' editor the default, with a preference to use the old (presumably stable) editor. Obviously this doesn't work for all features, but it seems like the text entry box in the Slack app is one that could be easily configured this way (maybe not?).
If they didn't care what designers thought when they shipped a new logo featuring a colorful pinwheel of erect, stubby penises and dangling testicles, then they won't care what users think when they deploy the equivalent feature.
I never had a problem with formatting code in slack until this release. And the hotkey (Shit+Cmd+C) doesn't work for me, although that might be my window manager interfering.
I guess they reach point where they are trying to improve something that was already good enough.
For me most annoying is that they removed setting that allowed me to configure to have up arrow to repeat the last command (like on IRC) this is very useful if you do ChatOps.
To be fair, at least one of the most annoying features reported in the blog post (not respecting closing backticks) appears to be fixed, at least for me.
But in general I agree with the sentiment that this feature should have been easy to make optional (none of the underlying data changes, it's just a UI control), so I think Slack deserves the scorn for this one.
Related, rhe absolute one saving grace feature that I commend reddit for is old.reddit.com. It may be "ugly", but it also lets me be extremely fast when browsing (not a ton of extraneous whitespace like I can't stand in the new interface). IMO lots of "designer-led redesigns" killed many a previous chat forum (looking at you Slashdot). A common thread is many of these redesigns are built to appeal to a less expert-level user. But by doing this in a way that is not optional, you are guaranteed to piss off the folks who are the biggest users of your product. It is no wonder they are vocal!
lol product managers are such a bane for tech companies. they have to keep shipping features which no ones wants but they have to show they came up with and are shipping something. i think tech companies should try and avoid product managers and designers for as long as possible.
Users are to blame. There always has to be something new, even if its no better or even worse. It just has to change regularly or people think its stale and move on. We see this loads in phones where totally useless features like samsungs curved edge or foldable phones and the removal of loads of useful features.
But in general, I'm noticing more and more that some product and UX designers seem to be trying to pass utterly broken stuff as "oh you're just not used to it yet" type of thing, which is extremely annoying. People have been explaining the EXACT problem to Slack on Twitter since Nov 7, and they clearly said that "we don't want that" many times in the thread.
It's not the wrong decision in rolling this out with no opt-out that is the problem, it's the fucking insistince on "no it's just all the thousands of you complaining, and not us" that gets me. And they had many opportunities to admit this.
I feel like a grumpy man yelling about updates like this, but this has been really badly done. Why oh why does it compromise on the existing "power" users usage so that it can provide click boxes for people who will never use it...
This being on top of Hacker News with 600+ comments at the time of writing means that Slack flushed millions of dollars worth of developer productivity down the toilet (i.e. all the people spending time complaining about Slack here).
Not exactly the same thing but GChat used to have a mini drawing UI where you could send a quick doodle and it super useful. No one else seems to have picked up on it.
I feel so blissfully privileged every time Slack comes up here.
Somehow using Slack has never come up in my life. I'm sure not looking forward to it.
(Though I do know the pain of having to use some frustratingly crappy-ass software because working with a client or for an employer makes it non-optional. Come to think of it, I've done my time.)
You know, I can't stand re-designs, and I was agreeing with a lot of the comments here until I got off my phone and was able to click through to the article and to Twitter on my laptop.
The responses are kind of repetitive/grating in that they're non-replies and kind of stonewalling, but I couldn't help but picture some poor soul fighting against the gratuitous negativity. Some (Most?) people were being constructively negative, which I do appreciate, but the Slack employee on Twitter essentially can't give anyone any closure or solution, and is just generally powerless against the whims of the designers or whoever it was that pushed for this change.
I like all my tools just so and have gotten used to them over many years, so I definitely agree with a lot of the sentiment here. It's just that for some reason the human sitting on the other side of the Twitter account was 'visible' to me in this instance.
EDIT: just to say that for the above reason, comments like this one:
make me a little sad. It's one thing to rail on a company, but in the case of Twitter, it's another person. Maybe a team of people; I'm not sure, but I'd say the same in that case too.
Using wee-slack instead of the official Slack client is an easy win on multiple levels, including this one. I sincerely hope they never go out of their way to break/block it.
Another annoying and broken design decision: because I live in Japan the first link redirects me automatically to the Japanese version of the article. There is no option to choose the language, and manually changing the language-code in the URL still redirects me to the Japanese version. My browser is set to English and French as main languages...
Hell yes, it’s awful. I am going to convey to Slack tomorrow I will cancel our account if they don’t fix it in a reasonable timeframe. For my dev team I t has gone from a valuable tool to actively harmful, overnight.
I went ahead and tried to reproduce the article's observations.
> when you do `foo()` it foos the bar.
I typed this exact sequence of characters in the new editor and it formatted exactly as one would expect.
> when you do bar.`foo()` it foos the bar
I was indeed able to reproduce this, and worse: if you put the cursor after the f, delete it, and type f again, the new f will happen before the backticks. One can tell this is about to happen by observing the cursor; even though the cursor is over the little box, it's black (as in for normal text) instead of red/salmon/whatever-that-color-is (as in for code).
That said, one can work around this by selecting all the text to be backtick'd and clicking the </> button (or pressing Ctrl-Shift-C); annoying, but slightly less annoying than having to retype things.
"Thanks so much for the feedback here, we really appreciate it and I'm sorry that the new formatting options have disrupted your flow. There isn't a way to revert to the old formatting method, I'm afraid. We don't currently have plans to make the new formatting configurable though we are carefully considering all our customers' feedback.
If it helps, you can turn off the formatting toolbar by clicking the Aa symbol to the right of the message input field.
The new message formatting is in the initial stages of launch and we're definitely planning on keeping it updated and making changes that make sense to us within the vision of the product."
I really sad to see when a "vision" is more important for a company than the customer feedback.
I went to a Slack workspace I'm in which has had WYSIWYG editing turned on and the first assertion in the article - about the non-closing backticks - isn't true. Since they turned it on last week I've had no issues with anything at all like this - I just type exactly what I would have typed before and it formats correctly every time.
Dealing with quotes is better, even.
Now I didn't need any of this, but it doesn't get in my way at all. In that regard they've done a far better job than Visual Studio, which I just can't seem to persuade not to insert random nonsense from time to time when it thinks it's being "helpful".
Same for Teams. Based on what I've heard I thought I will like it but the input box ruined it for me. It's beyond pathetic how a company the size of MS cannot implement a text-box that outputs text how I want it more than 1 in 10 times.
While I agree that non-technical persons would not get Markdown, not a single non-technical person ever messaged me something with markup. So why not just disable the shitty WYSIWYG and make markdown-formatting a opt-in choice from the sender of messages?
Also: Even Azure Dev Ops suffered from the same problem. I have no idea, how the same company can produce VS (Code or full version) and then release junk like this.
There is this long-standing bug on mobile versions of slack where large swaths of messages just disappear. The only way to get them back is to sign out and sign back in. This is supposed to replace business email?
You know what largely replaced business email AND these crappy chat applications for us? GitHub issue threads. We do a very large part of our collaboration right next to the code now. Email & chat is now mostly to just asynchronously notify regarding one or more issue numbers. Managers, developers, everyone. If you want something discussed or handled, make an issue. It's got a single numeric identifier that's trivial to pass around, even to clients and end users. Labeling systems applied to issues can quickly turn a messy bucket into a well-oiled software factory. If you use GitHub, this is also a strong argument for a monorepo, as you could have 1 unique identifier for anything across the entire org scope that also links into your code contexts seamlessly.
The UX around GitHub must be incredible for non-developers, because I am watching project managers with zero engineering/coding background learn markdown syntax almost accidentally. In all of our time using GH issues as a collaboration tool, I have heard exactly ZERO complaints regarding anything being broken or unfriendly to use.
We now look back on Teams/Slack/Skype/Email usage as dark days. "How the hell did we ever get anything done?" is the usual take when one of us talks about it.
Know what's better than Github issues? A directory in the tree named Issues. Create files there. They all stay with the project. Append comments to them. Code snippets. What have you.
Github could have put all the issues into the same repository, and built on top of that for the sake of managers, but that would make projects too portable. Having important project metadata in their domain aids lock-in.
On the plus side, maybe in a future update they'll make it so that we can do ```somelanguage and the box will have JS active with syntax highlighting and tab indentation appropriate for <language>. Slack's thing hasn't seemed that bad to me. It's true I've deleted a few stray back ticks, but it's so easy to edit mistakes it's not that big a deal. Especially if you use both Jira and Slack, the absolute shitness of Jira's issue text entry UI is a different order of magnitude and Slack's input box seems fine.
Imo, they've been on a roll lately when it comes to annoying designs. Drafts now bubble up in the UI, so if you start a chat want to finish it, it's all the way the top, regardless of where it started. Threads are similarly broken, if you click on a thread link, it won't link to the new addition to the conversation, just the entire thread. There's also weird bugs or possibly design issues where in a thread, you have limited or not the same options as you have in a general chat window.
Slack is at the point where we as long-term customers are wondering what they are working on all day. In fact, we are actively looking for replacements.
We could stand this new editor (even though it’s annoying), but what really drives us nuts are the performance issues on mobile, that there’s no way on iOS to see a screen share or to share the screen and that Slack is not integrated into the iOS call system. And when you have the pleasure to use it on mobile, it always tells you that the connection is bad
It is pretty astonishing how much Slack was able to grow from their initial 2 years of being ahead of the curve in UX, despite being mediocre/bad on every other front since.
Recently wrote about how surprisingly computationally intensive typing in it is (https://juretriglav.si/what-happens-when-you-type-a-single-l...), so it’s doubly surprising that it also doesn’t work as expected. But text editing on the web _is_ hard, and hard to
get right on deploy 1, so I’m sure they’ll iron out the kinks soon.
It's something so simple that they made complex. It's not just code formatting, even things like italics are annoying to escape from if you're used to the old interface.
Also, I totally understand their desire to get rid of the subdomain aspect of slack. As a developer I get it, I really do, but now there is no way to easily go in the browser to the slack that you want. It used to autocomplete now I have to figure out which slack is what and I get confused.
I just saw this pop up in our workspaces at Papa's slack at the end of the day. Haven't had a chance to use it yet. Do you need to use the WYSIWYG or is it still markdown friendly?
Edit: Should've read the article:
>That is, closing backticks are not respected! If you want the proper display, you must hit right-arrow after the closing backtick (but before the space). That’s quite a gymnastic for someone with decades of muscle memory.
This article reminds me of a recent post on HN titled "Text Editing Hates You Too" [1]. WYSIWYG text editing is never easy, and I am sad to see another instance of it taking over a spot where plain text (which still is not immune to the issues in [1]) used to be.
What Slack really should do is have a WYSIWYG editor that keeps the markdown syntax. Just apply rich text formatting to the markdown syntax, but otherwise leave the text alone. This will provide a nice reminder about what the syntax does (I always forget that Slack treats asterisks differently than markdown) but let me edit using all of the muscle memory that I've built over the years.
I wrote this up twenty-two days ago.
Ticket details:
"the new text input is whack."
Support Request #2490163
And I pushed back later after the first round of "yeah, it's the new normal, don't you like it," I wrote back with, "Yeah, no. This is a train wreck." And went on from there.
Heading now to post the URL to this discussion as a supplement to my ticket <hahaonlyserious>.
In general the model of allowing separate positions for cursor inside vs outside a span is a huge improvements over WYSIWYG assigning "sticky formatting" to characters.
(Hat tip to TeXmacs which was maybe first time I've met that UI pattern.)
But you have to do it consistently. E.g. end of literal block has separate inside/outside but start doesn't.
(Of course, in source editing, it comes for free – formatting is delimited by characters like * or ` and cursor is clearly before or after the delimeter.)
----
I believe there is a saner middle ground — formatting as syntax highlighting. You're still editing the source, no hidden state, just immediate in-place feedback.
(Nowdays some call this "WYSIWYM" though it's not exactly same)
Examples:
https://stackedit.io/, https://codemirror.net/demo/variableheight.html,
https://simplemde.com/,
https://laobubu.net/HyperMD (the latter is borderline, hides too many formatting chars IMHO, but does reveal them when you move cursor to edit.)
I'm guessing they are copying medium? Which also sucks for code. Sure, do whatever is best for non-coders but please give coders a markdown option as it's what we're using every place else.
I recently did my first post on medium. I wrote the post offline in markdown, copied and pasted it in. Was first disappointed medium didn't support markdown so I had to go reformat all of it. That sucked and had several of the same issues mentioned in the linked article, like for example putting the cursor at the start of a `inline-code-block` and typing puts what you're typing outside the block. The only way to edit the start of the block is put the cursor between `i` and `n` in `inline`, type your new text including a new `i` and then delete starting `i`.
Another issue is it changed all '' and "" to ‘’ and “” which I didn't notice and made all the code blocks not copy and pastable from the article.
------------My support request to slack------------
Alex
Oct 31, 2:26 PM PDT
As a software developer I want to be able to use slack to communicate mono-spaced text within messages that I write without having to touch the mouse.
The recent addition of dynamic text formatting in slack breaks the preexisting markdown functionality because it is not possible for the rendering engine to guess what my intent might be on the fly.
for example if I type this message:
The uuid portion is `D6B9E544-2306-41E7-9841-FF7E2AE0A5A4`_filename.txt
but then realize that I actually wanted a hyphen instead of an underscore before the word 'filename' there is no way to accomplish this without deleting and retyping "-filename.txt" (or doing a fancy trick where you add "f-filename.txt" and then delete the leading f)
This is not a failing of your system which is quite well implemented, it is simply a matter of WYSIWYG systems not being capable of rendering text with the same precision as markdown systems.
I suggest that you make the WYSIWYG text formatting a toggleable feature for people in the software development community.
---------their very nice but not helpful response--------
Hey Alex,
Thanks for writing in, though I'm sorry to hear WYSIWYG formatting is not working for you and your team as developers. It's not currently possible to turn this off, but I can certainly understand your reasoning here, and will share this feedback with the team so that we can best understand what the right solution is.
Please note, I can't promise that we'll be making this optional anytime soon, but will let the team know why it's not working in your case.
Sorry this isn't the answer you were looking for today Alex, but thanks again for taking the time to share your feedback with us.
It’s very annoying how it handles backticks via some sort of autocomplete.
Questions I ask myself about this:
- Why is this not an “opt-in” feature? I could see it being useful for people not acquainted with markdown-like syntax
- What PM / UX’er thought this was a great idea? I’m sure there was internal feedback that this was less than ideal
I just received this from Slack support and want to table flip.
> I'm afraid there isn't a way to revert to the old formatting method. We don't currently have plans to make the new formatting configurable though we are carefully considering all our customers' feedback.
This has been slowing me down immensely. I would have figured an easy workaround would be to copy/paste any fancy markdown stuff I needed to use from my text editor or IDE, but that only results in completely unformatted text. At least slack is good with their /feedback command.
Hmm I am actually not experiencing either of these bugs. The backtick character works as I'd expect. I definitely prefer the pre-WYSIWYG interface that is currently loaded in my Electron client though! Markdown is the perfect level of abstraction for styling without getting in my way!
We have to move the Web from a feudal society to a free market. To do that we need a some platforms and micropayments systems that work across borders to unify identity, social networking and commerce. Otherwise Facebook, Amazon et al will do it!
Note: the token described there is optional to the system, but without a native micropayment system we have to bolt on various payment solutions like Patreon or live with ad-supported platforms. The original Xanadu vision was hypermedia with micropayments.
I wanted to mention an interesting bit of engineering outside the pure programming space. It is not enough to design the web-based payment system, but we must take regulations into account as well. In order not to be encumbered with securities laws, the token must be designed in such a way that no one rational would purchase it for speculative purposes. In Switzerland, there is a FINMA legal framework for classifying tokens as securities or not. In the US, this is achieved by fitting within no-action letters of the SEC:
In short, a lot goes into a system like this, and it has to be in place to allow a free market by small entities able to compete with feudal lords. (Open source is a free market with a huge gift economy, ie many things are produced without a profit motive.)
Remember AOL, CompuServe, MSN? That was a Feudal society. You had to have AOL keyword Facebook, Amazon etc. The Web browser and HTTP invented by Tim Berners-Lee is what disrupted those centralized networks so you could simply use DNS and build on your own domain. Now you could have Facebook.com, Amazon.com and that is how they were even able to get their start. Do you think AOL would have allowed “keyword GMail” as an alternative email?
These bugs are typical of wysiwyg implementations. The only true, great, wysiwyg (but not really) editor is Bear, which is actually mostly markdown, but done in a way that lay person could use it without ever remembering any markdown. It’s simply delightful (and works on the phone!!)
While I've been happily using Slack's pseudo-markdown for a long time, a lot of the less technical users on our slack have never posted messages with any formatting, which makes things like copy-pasted error stacktraces a pain to read.
Yay if we get more formatted messages on slack, and not just from technical users that have learned markdown.
Nay if I have to struggle to get my messages to format the way I actually want them to format. Having the new WYSIWYG editor show me the wrong formatting while editing doesn't make the new experience any less painful.
Slack formatting UX is now different from GitHub. Having to deal with Confluence/Jira formatting was already terrible enough - I now have to figure out how to type the same things three different ways.
Agree it's terrible. Start a sentence with inline code and then try to go to beginning of line to add words that are non-code. It'll think you're trying to edit the inline code and you have to manually press the GUI buttons now to turn off code mode.
Does anyone know if this will affect the desktop client as well, or just the browser interface?
Personally I prefer the browser interface because I find the Desktop notifications and the Angry Red notification icon very distracting. But it sucks to lose markdown.
If I type an inline `foo()` it converts to WYSIWG as soon as I type the closing back-tic and everything I type after is back in normal text mode. If I left-arrow to have the cursor inside the formatted div but before "f" and type "bar." I wind up with the expected effect `bar.foo()`.
It takes one extra arrow press to move the cursor beyond the invisible back-tic to shift from the inline code to plain text regions before or after the block.
I preferred the old input just because I don't like having content jump around while typing. I'd still rather hit the preview tab to see it rearrange itself.
I use Firefox and I've had nothing but trouble from the text box. It's just atrocious, I don't know why they'd do this when the previous box worked so well. At least make it an option!
Press the "Aa" button and the row of icons goes away.
Based on the title, I was dreading checking this out but... I kind of like it; Keyboard accelerators for dropping in and out of the various block and list modes, quick action for code etc.
Unusable input boxes are rather common nowadays. I know several web sites for which I know from experience I should edit my text somewhere else and then paste it in, then delete and repaste if I need to change anything.
In general, I've never met a WYSIWYG system that I've found satisfactory. Admittedly, I do have a rather low anger threshold for stray invisible formatting.
At an even higher level of generality, isn't it a bit sad that we still don't have a good way of handling text on computers, something that lets you portably handle typographic emphasis but doesn't allow stray double spaces and crap like that?
If you use Apple’s App Store you’ll notice that they have provided exactly zero markup to help you make your changelogs. I think the only thing it respects is line breaks. And I’m kind of okay with that after seeing this mess.
I really wish the tech community would stop encouraging "this and that is terrible"-style articles. It toxifies the whole atmosphere, and it doesn't have to be like this if we don't want to.
Still can’t believe Drafts can’t be turned off. It’s been a feature for months now and I still find having the chat I’m working on fly to the top of the list as confusing and distracting as it was on day one.
Only now realising that something had changed. I've spent days thinking I did something wrong that has made Slack more annoying. But of course more annoying is basically the spec for every new feature.
I can understand how you might want this feature for all the non-techies that use slack nowadays. But give me a damn checkbox to disable it at least?? Whoever made this decision deserves a real life slap
I feel like they grossly underestimated how many users regularly use back ticks in their Slack messages – the rest of the formatting stuff seems to work fine, but the back tick handling is just horrible.
It is not a troll comment. I tried to get my org to move to slack from whatsapp groups. People (non tech) love them flexibility and UI etc. However they were quickly disenchanted due to the various issues with the system like it eats a few GBs on desktop, push notifications don't work on some phones, some UI elements are very irritating (when you upload a picture, it vanishes to a progress bar, trying to type anything with a / makes slack believe I am typing a command etc etc).
It does the right thing for me. This was the case yesterday and it still is today.
It's possible that the author got a different release. It's also possible that the author was trying other very similar scenarios that behave differently, e.g. backquotes behaves differently at word boundaries and inside a span that has already been converted to the code-formatted rendering.
Overall it's pretty confusing, but the simple case that the original article points out works fine.
I think this may have changed, very recently. Now when I paste any of the example strings in the post, I get an alert that I've pasted markdown, with options to apply formatting, or not ask again[1]. After that, it recommends using a new shortcut, (Cmd/Ctrl)+Shift+F[2].
I've just had this change hit my desktop client, so it isn't web only. It is very broken. Jira's new issue formatting is probably still worse, but I use Jira less than Slack.
Well I dont really understand why all of you are complaining, yes a product manager tried to improve the way we can write things because 95% of people don't know Markdown or something like that and the first iteration is not perfect for code users.
But they will probably correct the pain points listed in this article, why would they revert back their change if this is the best for Slack overall ?
Coming here is good to draw the attention on those issues so that they can fix it, but this is not the end of the world !
Slack is quickly becoming the kind of enterprise software I hate having to use.
If you’re on multiple Slacks, as is becoming increasingly common these days (I have 23 Slack accounts, five of which I’m logged in to on a daily basis), the UX is terrible. Whenever you switch from one Slack to another, you have to wait for the whole UI to reload, often takes several seconds.
You’d think all that VC money would make them able to afford building a proper desktop client instead of this Electron shovelware crap.
Slack should understand their market advantage is targeting development communities (with their partnership with Atlassian for instance).
Microsoft, Facebook, and others are going to eat their lunch as a generic workplace chat tool.
And if your clients are developers than they're going to have different needs and wants than your average non-tech user. They understand markdown, they don't want the editor overriding their intent.
I still maintain that JIRA has the worst WYSIWYG and syntax highlighting support, of any major code platform. It amazes me they are so dominant among developers.
His second big gripe is you can't position your cursor before a styled phrase and add to the front of it. That's a legitimate annoyance, but tbf Google docs and TextEdit behave the same way.
I'm 1000x more annoyed with the features taken away from ScreenHero than this stuff. Or the channels jumping over to some "draft" list.
I understand they want to make text easier for non-tech folks, but they mess with the feature only tech folks actually use
``` blocks are such a pain in the ass to edit now.
Say you have
```aaa bbb``` and you decide you actually want...
```aaa```
```bbb```
You get stuck in the stupid codeblock editor, to actually leave it, you need to insert newlines and extra ``` until it splits AND YOU END UP WITH MORE ```. Slack...please fix this garbo
I was mad reading this this morning, but now that I have (Electron app, macOS) Slack open and try it - it's fine. I'd be fine without it, but I don't need to tap arrow after closing a `` code block, and I can click or arrow back into it and insert new code at the beginning/middle/end no problem.
I didn't need it, but it's not broken (any more?) as described and as I feared reading earlier.
Yeah... it annoys me to no end. I cant fathom why they wouldn't support triple-backtick syntax like literally every other modern chat/notes/forums app.
What we needed was IRC with history. Nothing else. Slack keeps adding features and making things complicated, even cutting ties to XMPP and IRC on top of that.
On top of that it's running a terrible (yet seemingly good, so people are fooled by its looks) Electron app, when all you wanted as a native app.
If I can find a good alternative to Slack tomorrow I'll move my entire organization.
> I think the only way to insert text at the beginning of a code span in the WYSIWYG editor is to highlight the first character of the span and type over it
This seems better than what I was doing: put the cursor after the first character, type the new beginning, add the same character and remove the same character from the beginning. Thanks for the tip!
I love reading the responses here about how these decisions are made. I've watched a CEO at a unicorn constantly parade his vision past the UX and design team until they all quit or were fired. He got what he wanted. Customers were constantly battling the interface. And now he's worth sen digits so he must have been right... Right?
I long for the day I can just write reformatted code in Markdown, GitHub style -- with three backticks and a language declaration --- and Slack syntax highlights the colours correctly within chats.
This is such an obvious improvement for developers who share code constantly via Slack.
In fact, such an improvement, I would seriously switch chat apps to get it.
Seems like formatting characters are ignored in multi-line blocks (triple backticks) but not inline blocks (single backticks). Most people are upset about the latter.
Exactly the same thing happened to WordPress in version 5 when they changed the default editor. I am surprised that innovation is not embraced but it is met with strong opposition most of the time.
What amuses me is that no one switched from X to Slack because of the editor but some will switch from Slack because of it.
I think Slack should use the GitHub model for dealing with markdown. Allow the user the "preview" the changes. I can see Slack adding a new option to default to preview mode or not. This way, those that just want to see the markdown they've typed can default to no `preview mode`.
The OP said they felt the person should be reassigned. This is hardly a call for termination. It was also accompanied by constructive points about productivity software relevant to the post at hand. I do not believe there was anything unkind in suggesting that maybe the person was in over their head.
I agree it's much better than saying explicitly they should be fired or (as internet users often do) worse. Still, there's no need to get personal. Organizational failures are almost never one person's doing, and having an indignant thread sitting at #1 talking about how ugly your baby is is punishment already.
That's for them to decide, not for HN users to prescribe. Internet commenters underestimate the impact their personal comments have on the targeted person by at least 100x. It's just not nice.
It's unlikely that the person in question is reading this HN thread, but there's a chance that they are, and that means we should do better.
Here's the thing: maybe we don't owe "a lead at a company as high profile at Slack" any better, but we owe ourselves better in order to have a decent community. That's what https://news.ycombinator.com/newsguidelines.html is about.
Is there a way to continue "using slack" but actually rewrite your own client with Markdown support... maybe something that is actually NOT using Electron and gobbles up resources.
I had a quick glance at the API. It does look possible. What's the catch? Am I missing something?
That's why since yesterday on my French AZERTY typing a ` results in "`. Thanks a lot slack! Another reason that proves and allows me to keep saying that Slack is just a bad copy of IRC that's able to display useless gifs and consumes 1 to 2GB of ram for nothing :]
Slack is dead, they just don’t know it yet. Give Microsoft 2 years to keep grinding on Teams, continue to drive corporate adoption and slowly kill off Slack’s income.
I’m not a fan of Teams, but at work we’re switching Slack because we get it as part of our licensing agreement (3,000ish users.)
I just see we got the feature too, everything still works. can type the markup like before and it just works, even the triple backtick to end the codeblock. Also when pasting I get a popup asking me if I want to paste the literal text or apply formatting.
In addition to all the issues that others have raised here, I find that the new widget chews up valuable screen real estate, especially in the "Threads" view. They render the input widget for every single thread that you've recently participated in.
Always wondered why more markdown editors don't use the https://stackedit.io/ approach to WYSIWYG + formatting symbols. Seems like the best of both worlds to me
Slack in itself is terrible these days. For a company allegedly worth billions, it is a terrible application and is starting to show its age. Even the threads feature they added was horrible from a UX perspective and felt like an afterthought.
The main issue is it is not consistent with Jira, Github, and other famous services. I think these services should create a cross-editor and all other services should use it. it is really socks to use a different editor in each place
I'm clearly in the minority here, but I like the new text input on their desktop app. Visually seeing the text change when I create a code block or bold text right away, rather than after I submit the message, is very helpful.
So there is no way to off and switch back to markdown?
Extremely dumb way to roll out something without an option to disable it, especially with the excuse "we are listening to your feedback". They literally are not listening to it.
Devs aren’t the only Users nor are they most of slack users. Finally something more useful for non-technical folks. Markup or other shouldn’t be a gatekeeper for non-tech folks to get the most out of their software.
WYSIWYG in general is terrible as it tries to hide the underlying structure rather than show it. We really need an UX expert to rethink how these editors should behave so we can move forward with editing rich text
I feel the same about the new Nextcloud MD editor, it's great, until you make a formatting mistake or want to correct formatting. As a rule these auto-md-renderers should come with a plain text editing mode.
I don't know. It's really not that bad. No one is forcing you to click on these new buttons. The old markdown(ish) syntax still works, and even formats live as you type it, which for me is awesome.
I am so glad I am not the only person this enrages. I have all but stopped using Slack for the time being simply because its too painful to use the input.
Sure roll out a WYSIWYG editor but make it optional via a config flag.
I guess, for non-tech people this is better, for tech people the markdown input was better. That is why I don't understand why Slack doesn't give you the option to switch between the two …
The changes are so obviously ill considered, and, without having the data to prove this, I believe it’s trying to solve a problem that very few people had with the previous solution.
As the author states, you should just be able to toggle between WYSIWYG and plain text and everyone is happy. This is the nature of all WYSIWYG editors so why does slack not follow this approach?
Seems like these guys need to learn the concept of consent, i.e. that if you try to force someone to do something they don't want, they aren't going to stick around with you.
Oooh I hope they try to support bulleted lists. There is nothing more painful than trying to implement that correctly. Every time it works in Google docs I am god damn amazed.
Right now this has ~1,000 comments. That's... a lot for a post on HN on something so mundane. That must mean that Slack users care a great deal about this. Food for thought.
It's fascinating to see how tools turn into environment people wanna live in. Its a god damn tool, dont commit your lives to it. Use it, abuse it, it doesnt work - toss it.
I can't reproduce the example given in this blog post -- when I type out the same thing in the new Slack input box, it renders correctly. Can others reproduce the problem?
It seems to be equally bad to the WYSIWYG that Microsoft Teams provide, which also has similarly MarkDown shortcuts. However the one from Teams isn’t even deterministic.
I’m willing to be that this change was motivated by investors. With Slack going public there is going to be pressure to develop mass-market appeal and not be focused on their earlier, more technical users. And maintaining multiple versions — one for engineers, one with wysiwyg training wheels, and more — becomes a headache in short order but might be the best approach to making easier to use spins on the core product.
I just tried the new web client for the first time: Both issues highlighted in the blog post seem to have been fixed already. As it stands it does not actually feel all that disruptive to me.
It's a bit annoying that there is no way to toggle the WYSIWYG rendering, but for me personally there have been countless times when I was missing some kind of preview while editing. For instance to align stuff in preformatted blocks...
oh my god, thank you, I thought it was me going insane, I can't make code snippets with syntax highlighting, when pressing the three graves (```) the entire line (and only the line I'm on) becomes a monospace block, it totally breaks how I use slack.
I actually like the new backtick to codeblock style. It is three backticks instead of six. I do agree the overall input box could be smaller.
My personal pet peeve is threads. The feature I didn't ask for, but can die in a fire. Or they could make an option to have it auto flatten all threads.
It seems pretty cool to me to work at a place where so many people use and care about your work, but... It must suck to just open Hacker News, or even a link someone sent to you, and be greeted with someone off-handedly dismissing your work as terrible.
I think we need all to calm down on this one. I was irritated in the beginning as well, but I am sure I will get used to it. Change is always difficult but part of progress.
So if only 50% of the users have this, we should assume that it's only 50% done, and that by the time everyone has this thing, it will be perfect?
More seriously, while "this doesn't work right" is part of the complaint, the larger complaint is "this is fixing something that wasn't really broken." If Slack wanted to improve their editor, that'd be great, but they could have done that without losing what people liked about the old system. It's not like there's a lack of "quasi-WYSIWYG" Markdown editors out there to take cues from.
At MongoDB, we were supposed to be on it at all times. It was a continuous source of stress and broken concentration. It is what I left behind most eagerly.
Curiously, Google Chat has not become similarly stress-inducing. Yet. Gmail has become moreso lately, though. At least once a week it manages to conceal an important message.
Since Google Chat works, I expect them to drop it soon.
Google Chat is quite stress-inducing for me as well. Maybe I don't know how to use it properly, but when I get a notification it is so hard for me to find the message that triggered it. Our Google Chat has a lot of messages, so sometimes I could have to scroll through hundreds of messages and thread to find it. It's not highlighted or anything to make it easy, either.
Because I often can't find the message that pinged me, it's extremely stressful. I worry people think I ignored them, when in reality I never saw their message, despite actively looking for it.
At my office, we have mostly only individual chats, plus a customer-crisis chat ("Who's helping XYZ?" "On it"). So if there is any activity, it is relevant, and it actually reduces interruptions, because when we're deep in something, we don't look, and somebody with a question doesn't need to hang about waiting.
Their stock has been decimated. Tempted to still short it at this price. Very clear it’s not much more than a feature that has quickly been commoditized.
What a bunch of whining babies.
Are you really this upset with such a tiny change? :D
I like the new editor.
They shouldn't revert the changes. Like any change on any software, people will complain first, some issues will be solved, and then will adapt and stop complaining.
I've just received the update this morning, I "complained" for a moment but to be honest it's not that bad neither the end of any world. Plus, I can't really reproduce (or maybe understand?) the Markdown problem he's reporting about "when you do `foo()` it foos the bar". It work as previously did and as the author expects on my computer.
