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.
