Slack’s new WYSIWYG input box is terrible
quuxplusone.github.io
quuxplusone.github.io
High Importance Person Pushing Own (desires??)?
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.
The concept seems to originate from Netscape's CEO and the acronym exists since 2006, according HiPPO FAQ: http://bitly.com/HIPPOExplained
And where the link goes to, obviously. No idea if this counts toward the Bitly link open rate.
1) don’t need to be logged in for the + to work
2) I’ve not seen it increment the clicks by visiting the + stats page, but can’t speak authoritatively on that.
At least for me, that's a time-to-leave signal.
Not only is that a miserable experience, but I think it's also a recipe for a product that only gets worse.
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.
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.
So if that is indeed the case here, then it does indicate some problems.
I’m amazed that I’m still talking about this :)
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,
That is microsoft current plan, be "good enough"
Out of curiosity, what do you think of the Stylish userscript that enables a compact mode in Teams and offers dark and light themes?
I still prefer an App instead of the browser, but that's just personal preference.
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.
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.
Then there is sharepoint, oh, and onedrive, and they all come in the same package so everyone uses something else.
Doesn't matter, since it comes with Office so it basically costs $0.
It's crap, but that's not stopping my employer from replacing literally everything they can with it. Even our desk phones, purportedly.
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.
The Android app in particular has trouble. And muting is all-or-nothing.
I've also had corrupted channels, I even escalated to Microsoft once.
```
one
```
```
two
```
Still...I could have swore I had tried that anyway. Huh.
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!
Unfortunately it must be done every time, no autoformatting by default it seems.
The trick seems to be to add a blank final line, otherwise, it will not include the last line you typed in a code block.
e.g.
> * My quoted bullet point
Glad my only use is a comms channel for my Ingress group.
Terrible UI choice. It makes no sense.
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
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)
It really resonated with my thoughts, how I've viewed the tech world and my (tiny) part in it.
>>> 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.
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.
[1] https://mobile.twitter.com/SlackHQ/status/119764013617293721...
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.
To be fair, you could learn almost anything in that amount of time;)
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.
I haven’t ever heard anyone comment on how enjoyable Word is to use.
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.
===
"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
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.
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.
(If a feature / deploy rollback itself isn't possible.)
The advantage of SaaS is that software can be upgraded rapidly, uniformly, and for all users, on the fly.
The disadvantage of SaaS is that software can be upgraded rapidly, uniformly, and for all users, on the fly.
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.
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!
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.
Otherwise, ProseMirror supports both WYSIWIG and Markdown, and toggling between those two modes. Look:
https://jira.atlassian.com/browse/CLOUD-7184
With 740 companies asking for it ;)
Submitted in 2014.
Atlassian users might have a while to wait yet :-)
[0] https://docs.microsoft.com/en-us/sharepoint/change-site-addr...
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.
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.
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...
That's just a guess though; I don't work at Slack.
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.
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.
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.
Open source core supporting WYSIWYG, Markdown, Code and more.
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.
Menu Administration -> Settings -> General tab
There's a drop down for Text formatting which you can set to Markdown.
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.
For ticketing software, I find Clubhouse to be much better than JIRA. Normal markdown that doesn't drive you insane. Much slicker all around.
Whilst not an actual answer to your question, I thought it might be a good direction for you to look into.
Also, I've seen Redbooth (formerly Teambox) we'll recommended and since it's OSS it can be self hosted pretty easily.
Do you have any links to any cloud or other hosting company kicking out any mens rights sites?
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.
So yeah, we need to avoid using cloud services.
In this UK it's probably "mankind", hosted on a microsoft owned IP, I assume azure.
> for profit
And
> 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.
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.
It's also very easy to self-host.
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.
Perhaps a weekend project/"show HN" to gauge interest would be warranted.
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.
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...
Was there something you didn’t like about them?
I used https://liquidplanner.com/ for a bit, it was clunky and slow and expensive, but did get the job done for what I needed.
It's worse than literally every other wiki I've ever used; even worse than phpBB.
We also use Bitbucket at work, which is laughably unreliable.
If you're interested in having self-hosted service for that, just drop us an e-mail here [2].
[1]: https://github.com/kovetskiy/mark/ [2]: https://mark.reconquest.io/
As I have been fiddling with ProseMirror I've found out that their editor is the most extensive PM-based editor out there.
It's quite annoying.
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)
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.
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.
This is how I use Slack as well. It works nicely for me personally.
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.
Also text = async. Use the phone when sync is needed.
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).
It was amazing.
So, in the end it's a very clever move.
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!)
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.
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.
The upside is that it's now possible to have bold passages in monospaced text. I missed that before.
The web client on Firefox works better, though: https://imgur.com/a/X53iIlm
Edit: On Chrome it's broken for me too....
I think the concern is mostly about what Slack was actually trying to achieve.
Good to see that they are shipping improvements to it now.
I am, to put it lightly, familiar with this in other companies.
In the future how do you suggest I handle this?
"someone else in this thread said that they know some slack employees and it's true: <link> "
that way people scanning know what the link is and why it's there.
But it's only a few downvotes, and I think that total downvote count effect is limited to only a few points per post? So don't sweat it.
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.
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).
Teams, not Skype for Business, is Microsoft's Slack competitor.
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.
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.
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.
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.
Also known as optimal strategy to get your soul crushed and die inside.
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?
Link to wee-slack: https://github.com/wee-slack/wee-slack
EDIT: Turns out, I spoke too soon, there is no such option according to docs or from reading the code, maybe you have another plugin doing this?
EDIT2: found it: https://github.com/keith/edit-weechat
(not my code)
Not saying you’ll have the same issues, but definitely turned me off. :/
Hi Dijit,
Highly appreciate the feedback. Definitely want you to have an amazing experience on Mattermost, and I'm sorry you're having issues.
If you go to "About" can you see which build you're running, whether it's a stable or unstable release?
Odd number releases are stable "Quality Releases", e.g. 5.17, even number releases are unstable "Feature" releases, e.g. 5.16.
Also, we probably need to add more diagnostics into our clients, as some issues come from how people choose to deploy the backend server.
Well, that's odd !
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.
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..
Our aim is to build an editor that works for all Slack users
disabling the new formatting tool isn't an option that we will be offering
...unless their goal is to reduce "all Slack users" to "only those who don't need the option"...
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.
Then run this
require('electron').BrowserWindow.getAllWindows()[0].webContents.executeJavaScript(` javascript:(_ => { const redux = slackDebug[slackDebug.activeTeamId].redux; const {wysiwyg_composer, wysiwyg_composer_ios, wysiwyg_composer_webapp, ...payload} = redux.getState().experiments; redux.dispatch({ type: '[19] Bulk add experiment assignments to redux', payload }); })(); `)
to disable rich text editor. Going to hack together a node launch script for slack here in a little bit :P
Commitment to users means respecting that people have different preferences, and options let you respect that.
For what it’s worth, Mattermost is an open source alternative built for engineers by engineers. The interface is markdown.
imo a fast native client, that doesn't look like a sad slack clone (which teams currently does) would put you streets ahead of the entire field.
I know it means increasing code complexity.
but by golly would it be nice to have a truly nice client.
Highly appreciate the feedback,
1. Browser WYSIWYGs are really hard to make.
2. All browser WYSIWYGs are terrible.
Avoid rolling your own WYSIWYG if you can. Even if you have a team of 1500 people at your disposal.
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.
Edit: Formatting.
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!
(disclosure: I am a founder and the CEO at Tiny)
I worked on CKEditor 4 (very different from v5, which is a rewrite).
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.
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.
https://github.com/matrix-org/matrix-react-sdk/blob/develop/... tells all about CIDER, and https://blog.riot.im/riot-web-1-5/ gives the full context if anyone cares :)
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.
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.
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?
So, markdown?
Every website has its own flavor of it. Just reading some of the answers around here you can read "to do markdown better we made our own markdown".
Maybe because it is shitty. Just let users use HTML.
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
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.
https://github.com/clojure-emacs/cider
It likely doesn't as they seem unlikely to be confused.
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.
I've heard good things about it and it seems to have a decent implementation for hybrid WYSIWYG + Markdown.
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.
I looked through all of the links in the original post and couldn't really find any mentions of specific limitations.
Just trying to learn more about this space.
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.
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.
Everyone frustrated with the new Slack input box deserves what they got. Me included.
I for one am showing the middle finger here; when forced to talk on Slack, I use Ripcord as a client.
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)
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.
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.
it's kinda sad that it has come to be that tech companies will consider installing matrix "complex".
FLOSS software needs hosted, supported, reasonably priced versions with security updates to be competitive.
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
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.
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"
Then you get here finally https://matrix.org/docs/projects/try-matrix-now/
> To get started using Matrix, pick a client and join #matrix:matrix.org. You can also check the Matrix Clients Matrix to see more detail.
Or then there's this which looks more like it: https://matrix.org/docs/guides/introduction/
Compare this with going to Slack's web page and clicking "Try Slack".
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.
But when you try the Riot app on a Matrix server, can you create you own private workspace there or it's more like an IRC channel?
Because Slack let you have your own workspace/"server" in the free plan https://slack.com/intl/en-ie/pricing/free?geocode=en-ie&from... (you'll have some limits, but you get your own private space)
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.
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.
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.
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.
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 haven't seen much evidence that would say otherwise, but there's plenty of circumstantial evidence favoring my belief. Like this case.
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.
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.
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.
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.
98 and XP were basically just flavors of win95 and those were everyone's favorite, UI wise.
I still think Windows 3.1 was peak UI though ;)
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.
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.
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.
They never backed up their claim with any data, and instead released a very partial plugin to shut up dissent.
Basically all they do is look at Adobe UIs and copy them, even if IDEs and Photoshop are not used by the same people and not for the same usage ...
Whether it's useful really comes down to who is personally attached to the design in question and how much institutional power they have.
I've seen games trashed in testing only to have the lead designer double down on their designs; which always goes about as well as you'd expect.
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.
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.
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.
That doesn't mean everything necessary gets chucked out immediately. Sometimes we'll then test individual parts of a design (failed or otherwise) to see if those do better on their own. And complete redesigns with similar aims do sometimes get created (but they're usually completely different in colour scheme, layout, text, etc).
We also do user testing for the same stuff. That too is more important than a designer's opinion would be.
So yeah, it does happen.
Do you remember Skype? Everyone used to be on Skype. Who uses Skype anymore today?
I get little pangs of dread a split second before I realize I'm about to have to spend 10-30 seconds figuring out new formatting since it shipped.
And as a response, I'm less reluctant to use it, meaning my messages are less detailed, meaning longer conversation, less precision.
It's a "convenience" for non-power users, on a feature only used by powerusers
Of course, it's not unlikely that they weren't so much afraid as that they thought nothing would be done with it anyway.
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.
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.
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.
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?
[1] - https://a.slack-edge.com/085e3/marketing/img/channels/vid/ch...
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.
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.
I think that's critical for a communication app when you want to ensure that you've answered all things that need answering.
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.
So Zulip doesn't hide chats over a certain amount like Slack does eh? This could make it extremely useful for cash strapped non-profits.
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.
See https://zulipchat.com/for/open-source/ for more details.
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.
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.
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.
(Or I guess Cmd+Shift+V)
* 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)
EDIT: formatting
Oh, and you can't easily get the underscores back -- you'll need to retype the variable name.
They are clearly moving towards WYSWYG-only, markup is minimally supported now to facilitate transition.
Sad.
I wonder, if they introduced a keyboard shortcut that cleared all formatting, would that be a reasonable compromise?
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?
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.
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.
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.
There is no other. (Thank God, one is enough of me. Too much, oftentimes :P)
> If so, thanks for your contributions.
YW!
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...
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.
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.
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 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.
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 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.
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.
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.
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.>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.
/remind me every day at 10am to remind Slack about the awful WYSIWYG input box
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.
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."
[1]: https://twitter.com/slackhq/status/1192147475672510474?s=21
You say "users": how many, what percentage, what cohort..you get the idea.
A bit like the teams editor, which was forced upon me and is absolutely horrendous.
Personally, I think the importance of not upsetting the established userbase far outweighs the probability of maybe growing that userbase a little.
Not to mention, unintentional threats.
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 ;)
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.
[0]: https://theoatmeal.com/pl/state_web_winter/facebook_layout
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.
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.
This is the one that got me. Yeah thanks, I've been using text boxes since the 90s, I know how to undo.
Now we'll get to find out if _they_ know how to undo.
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/
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.
On the web site they put it this way "Slack is the collaboration hub that brings the right people, information, and tools together to get work done."
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.
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.
Like one days work for 1 person?
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.
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)
- Saying nothing
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.
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.
Translation: "we're paying all these engineers and product managers and they need something to do"
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.
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.
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."
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.
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.
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.
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...
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.
Except for the changes like "reduce memory usage" or "fix crash when X happens" --- those are true improvements.
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.
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.
What happened to Digg? Myspace? UI isn't the only reason, but it's definitely a contributing factor in their demise.
The eBay story about changing the color of the banner should be followed for new features as well.
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...
Speaking of muscle memory, I still remember these … and — from the time when most web apps understood HTML. Too bad they stopped…
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.
I cannot wait until the MBP 2025 with the whole keyboard replaced by the touchbar..
Who needs tactile feedback?
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.
How do you like this reply to tweet: https://twitter.com/qbixapps/status/1197332922807865344
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.
> never rendered larger than 64x64
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.
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.
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.
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.
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.
When typing code with ```, Enter should not send the message. With this checked use ShiftEnter to send.
Might be an easy fix :)
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.
Personally, I recommend switching to Ripcord as a Slack client. That's what I did some time ago, and I couldn't be happier.
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.
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.
Which specific daemon did you settle on?
Not really looking for replacement though (team is currently on Mattermost)
It is very far from a solution in 2019.
IRCd - real time, ram buffering of messages. Quassel - reads and stores buffers in a database, allows users to retrieve them.
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.
So dial back the snark.
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.)
How does IRC handle end-to-end encryption in groups?
How does IRC handle editing messages?
Servers can re-send history when a client join. At least InspIRCd supports this (though it's not enabled by default.)
Blowfish normally.
Press up arrow, retype message, or type *correction.
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.
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.
A lot of reasons... a solution 1) grows to match the size of its budget constraints 2) becomes more complicated the more people with long titles have a say in it 3) becomes more difficult to implement the more people that are working on it 4) becomes less useful the more people there are that can dictate what it does and how 5) fulfills more of the letter than the spirit of its requirements as more hierarchies of people manage it 6) becomes less user friendly as fewer typical users are involved with its development
Though the actual answer is "somebody with power just wanted electron for personal reasons and nobody had the power to turn the ship once it started on its course"
As someone who never got into slack, and never found it appealing... How so?
I'd actually be interested in the answer from grand-poster as well, if only because I am a curious asshole.
As the person asking that question, no. I've heard it's used by some people ... for things.
Just like I've heard some companies use IRC for chat, and some open source projects use Discord where you can join if you feel like it.
I have no idea what its primary use-case is, who its primary audience is, and to what degree it's more critical than IRC or email or intranets to anyone.
Does that answer your question?
Your comment started off about you and was dismissive of Slack. Saying "How so?", in general, is not handled by people as a genuine and sincere question, it's usually laden with an "I don't believe you" vibe, especially with the dismissive nature of the lead-in.
If you had asked instead:
> "I've haven't really used slack, didn't really see the use case. Why can't you stop using it?"
You would have received a better response.
I don't believe that. I think it is a perfectly fine question, and don't find anything wrong with the way the post was worded. Based on my personal experience, I think my interpretation is the general one.
For example, in the case above, was the "How so?" directed at the "immediately stop using it" part or the "have no choice" part? Both?
That sounds like an extremely regional interpretation, and does not consider that the question was asked in good faith, something the HN guidelines specifically ask you to assume[1].
Four months into that contract I was moved over to a struggling 'Slack' enabled project, to help them work through their ever growing backlog.
I knew someone working on that project and discussed with them the project's use of Slack only to realise it was nothing more than a talk fest and not for me.
So when the project manager approached me, asking if I would like to join in on the Slack discussions, I declined.
Needless to say that did no go down so well.
However, I stuck to my guns and 12 months on my contract was renewed.
To this day Slack is still not part of my daily development life.
If it is the primary method, you'll miss stuff.
Whether it should, is another matter, and running a one-man rebellion from within is probably not the most effective way to change that.
We rarely pick up a phone, and we do not use email. Everything is 100% Slack.
This works well for us. You can bring in only the people you need, you can "star" messages and channels that are important, and none of us have any time to spam/meme the channels, so it's 100% business. We integrate the JIRA slackbot to keep abreast of what is going on in JIRA.
It all "just works" for us.
My employer uses Slack. Our team channels are almost completely devoid of cruft. There are office/location based channels that contain more bloat, but those are easy to ignore and typically don't contain critical information. All of the "all employee" type channels are locked down.
Not true. There’s several alternative clients.
I don't need ANY changes in my XMPP/IRC client to connect to a server.
But the reason why Slack discontinued XMPP/IRC is clear. They want people to use their shitty app/website.
>so the only way to connect to is via the official interface.
was clearly not about the UI but rather their HTTP way of accessing Slack. And right now there is no other way besides that.
Many folks I’ve talked to don’t realize there are alternative ways to connect to Slack still once the XMPP / IRC endpoints died. They think the only way is using the Slack developed apps. Thankfully, that’s becoming more and more not true each day.
Pedantic Point:
Re: > rather their HTTP way of accessing Slack
Slack uses Websockets. Websockets != to HTTP.
>Many folks I’ve talked to don’t realize there are alternative ways to connect to Slack still once the XMPP / IRC endpoints died. They think the only way is using the Slack developed apps. Thankfully, that’s becoming more and more not true each day.
Which are? Using a proprietary Websockets API is not "another" way if even the Slack app is using that (not sure). The main difference to XMPP/IRC is, that with the later ones not a single line of code needs to be written (not from me and not from IRC/XMPP developers). Just use the client you like, set server and credentials and you are done. That's why there are protocols.
>Slack uses Websockets. Websockets != to HTTP.
port 443 is close enough and http is needed to start anyway :P
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.
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.
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.
This is what happens when you over-engineer things.
IRC is not perfectly good or it would still be used.
IRC doesn't do that, true, but there's a bunch of ways around it.
> saves history, has notifications, search
Trivial to implement in the client.
> IRC is not perfectly good or it would still be used
IRC is still used. Almost everything any fancier messaging protocol does can, and has, been implemented as a client-side feature with little hassle.
... all to save $7/month/person (or less for some competitors like MS Teams) because Slack is, like, too proprietary.
> 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.
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.
[0] Not literally, I have no idea what it uses.
Edit: spelling
You can use paid services, or not. It's up to you, but they all interoperate.
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?!
Slack's good at engineering and development. They used to be good at UI/UX, but whoever over there in the text entry product design slot is having a case of the Jony Ives.
>When typing code with ```, Enter should not send the message.
>With this checked use ShiftEnter to send.
So they didn't really provide anything new here, just changed the default behavior.
edit: formatting
"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."
[0] https://github.com/kfahy/slack-disable-wysiwyg-bookmarklet/b...
How can anyone remain a customer of such idiots?
In my mind bolding/italicizing are nice-to-haves alongside emoji. You wouldn't compromise the entire functional user experience of the central feature of your app for nicer emojis. (at least I hope not).
I also hate the new input field but I understand why they turned it on globally. But a strong enough want is often indistinguishable from a need.
That's why tech people italicize stuff.
Or, as your reply has highlighted, even with the additional emphasis, people will still fail to read it the way it was intended.
Is this the future we really want?
They're not treating the users who prefer markdown formatting with respect at all. It's basically: "fuck those guys, we want to cater to a different audience".
that said, i take exception with these claims that the user is “an idiot”. it comes off as arrogant to me.
Not sure what their user base looks like now, though.
There is no way to opt-out of this change, essentially forcing everybody into entering text this way.
Other examples: * The UX around threads is still horrendous, and there's no way to turn it off. * There's no way to turn off "drafts", which still causes me to lose messages I'm working on.
Regarding Slack’s attitude about technical users whose life this disrupts, I can see that the calculus may appear to favor the non-technical users: there are probably far more users who have no idea what Markdown is and never need to share code snippets on Slack and who are happy with the new wysiwyg editor since it’s closer to what they get from MS Word and Gmail. However, technical users have massively outsized influence over the choices of technology at most companies. The IT dept is full of technical users who share code fragments all the time. Don’t you think they’ll be keeping an eye out for new chat platforms after this change? Tech startups are (almost by definition) mostly technical users. Do you think any new tech startups will willingly use Slack after this change? Some of those would have been paying customers and a few of them would have become huge paying customers. Now they won’t. I know I’m actively looking for alternatives now and I have controlling influence over what gets used in several paying and non-paying Slack instances.
There is a big difference between “used by company Y” and “used by tiny team X inside company Y” (probably without IT approval).
I like the language and environments, and it's fine that almost all developers are close to retirement, they are great libraries of knowledge after having worked in the system for 20+ years.
It's mostly the legacy ways of working around here that are an annoyance, communication by email and having to wait for order- and project numbers before starting any development, instead of being allowed to develop improvements that can just be implemented when/if they get the ok.
The wait time does allow me to create some automated tests of which we had absolutely none, that other young developers here also benefit from.
I'm gaining knowledge and the system seems to be getting replaced in not that long, at which point my fiancée wants to move back home to the states, but health insurance woes has kept me from looking into that.
As I understand it MS has been covering the two (in both features and design) so that at some point one or other will be deprecated, but that in practice all that means is a name change for those users.
Group chats in Skype don't happen, messages are stowed away in outlook under past conversation history and everything you send on Skype for business is a new conversation @tagging the recipient (singular in almost all cases). And everything to be brought up with multiple people thus ends up being an email chain after the Skype convo.
You can prove anything with case studies.
Please please do, Slack. I filed a support request already asking how to turn off the new editor.
While we're at it, let's have syntax highlighting of inline non-snippet code blocks.
Just stick to CommonMark, for god's sake. Atlassian, Slack, take a look at Github's editor experience because it's fantastic compared to yours.
Twitter is another obvious example I can think of.
Time to move to a new product which still focuses on techies.
As a member of user minorities - the "tech savvy" niche and "knows software can be ergonomic, and expects that" niche - I'm already avoiding using new "innovative" products. The story is always the same - people with needs are used as tools to drive initial adoption, and then the product self-destructs trying to chase the lowest common denominator.
FWIW, I wouldn't even be using Slack if I weren't forced to, like probably most of its users. Regular employees don't have much say in what companies use for chat, nor do most people in communities in what tool was used to start them.
That cost does need to stay within reason though. And something crazy like maintaining divergent architectures/infrastructure isn't really reasonable either. But on the bright side the technical folks might be understanding of these sorts of tradeoffs.
Well, actually more like 3 newer, better, competitors.
And then we'll have endless arguments and religious wars about which newer, better, competitor is the best.
But we seem to enjoy that, so all good I guess. Go team Geek :)
It's still really annoying though.
It's by far the most popular messaging platform in Brazil[0][1]. In other places in South and Central America it's also about as popular as in Brazil, so I suspect the majority of internet-connected people in America use it.
That said, WhatsApp is not a tool I use mostly on the computer to talk to my tech friends and co-workers, where I need efficient ways to communicate both using pre-formatted/code lines and in natural language, where things like bold, italic, quotes, etc become important tools to convey the right message.
[0] https://labs.ebanx.com/en/articles/special/whatsapp-in-brazi... [1] https://hbr.org/2016/04/the-rise-of-whatsapp-in-brazil-is-ab...
What is called “América” in Spanish and Portuguese, we call “the Americas” and consider to be two continents (North America and South America), not one.
I have no opinion on which usage is “correct”. Just pointing out that the person you’re replying to almost certainly used “America” to mean the USA, not the land mass that includes Brazil.
Excel also happens to be the software with the most arcane UI on Earth.
'Making sense' is not the issue here, motivation is.
And I don't think removing a power-user feature and replacing it with something half-baked will motivate your user base.
P.S. WhatsApp uses a markdown-like UI for formatting: https://faq.whatsapp.com/en/android/26000002/
Somehow, its non-techie users aren't complaining.
That said, none of them are complaining because it’s a chat program. You don’t need heavy formatting in a chat program, it’s meant for short and fast messages, unlike email.
As such, I don’t believe people will spend a lot of time formatting their input in Slack, unless they really are thinking people will replace their email with Slack.
I asked them for the option to turn it off. An excerpt from their response.
> ... we understand that this has caused a disruption in workflows for some of our more technical users. While we don't have any active plans to make this configurable at the moment, we are in the process of collecting user feedback so that we can find a way to make it work for everyone.
I'll be sending this as my follow-up.
edit: oh nm i only noticed the ui, not that it totally broke typing
> 'While we don't have any active plans to make this configurable at the moment, we are in the process of collecting user feedback so that we can find a way to make it work for everyone.'
It's like the answer to the second half is in the first half of their statement.
A while back, I reported a bug with copy/paste, and they asked questions, acknowledged it, and had it fixed by the next release.
More recently, I had a question about why the UI behaves in a certain way I didn't expect, and they took the time to explain that it was intentional, and what their reasoning was for doing it their way instead of how I expected.
All of these experiences are way better than average for our industry, which in my experience usually just brushes you off without trying to understand your issue and tries to placate you with a non-answer or answer to something other than what you asked.
I'd love to know whose idea it was, though. Maybe next time you could try congratulating them on "clever self-disruption of a successful product" or something similar to draw them out into the open.
The journey from hacker-friendly comms tool to mainstream train wreck must be quite a story.
Anyway, the main point, what percentage of people do we think knows markdown to such an extent where it's easier for them to use than a WYSIWYG editor would be? I'd venture on HN alone that number is <10%, and considering Slack is used by a far wider and less-savvy audience than on here, I don't have much of a problem with the reasoning behind the change.
I think the lack of backwards-compatibility is a legit criticism, and sure, an opt-out would be nice, but I don't think for a second that this is as egregious as people are making it out to be.
Surrounding some text with these marks to achieve some formatting is hardly rocket science. If someone doesn’t do it it is really because they don’t want to understand.
If you however make an editor that fucks up using any of these marks? Well, that’s a big time failure.
Well, Slack supported so little of Markdown that this is a moot point.
I kinda reminds me when Confluence added their WYSIWYG editor--or using Frontpage. I basically /had/ to go to code view to get the page to look consistent. So far Discourse has been my favorite implementation, with preview being off to the side. I'm sure that would eat up too much real estate for Slack.
The gist of it is that an intransigent minority can often dictate the choices of a flexible majority. It is unwise to make decisions based solely on majority rule, as stubborn minorities can affect complex systems in ways that you do not expect. The phenomenon can be verified in a variety of situations across history.
To put this into context for Slack, I believe technical users have been particularly important for the app. Tech users were early adopters for Slack - I'm sure a lot of corporate accounts started out with engineering teams. Tech users wrote the chat bots and integrations that Slack is known for. They got people to use Slack, and they can get people to stop using it.
Let's say you're changing the way a certain feature in your application works. The majority of users are happy or indifferent about the change (but weren't particularly bothered by the old behaviour). A minority of users not only reject the change, but are vocal in how much they hate it. They will not tolerate the new behaviour, and will try to get other users to abandon your product unless you resolve the situation. What do you do? You can ignore them for now, but can you predict the long term effects of turning your back to the intransigent minority?
1. https://medium.com/incerto/the-most-intolerant-wins-the-dict...
I get that things that want to be popular quite often shiv the early adopters as they become mainstream, as a) that particular orange has been well juiced, and b) satisfying early-adopter needs really can get in the way of that holy grail, maximizing revenue.
But here I don't think there's a big conflict. There are a bunch of ways this could have been done to make everybody happy. It could have been opt-in for a while and then opt out. Or as others point out, there are apparently good WYSIWYG experiences already out there. With a market cap of $12 billion, Slack could afford to buy one, or at least the team behind it.
The only explanation I see is that it was rushed out the door to meet some executive's goals. Which suggests that Slack is becoming the sort of clueless, sales-driven, user-contemptuous company the initially aimed to overthrow.
Even simple dog-fooding by their own internal coding team should have revealed that issue.
If they had a test group, it was definitely a group that didn't use those features to begin with and basically didn't use them in the new UI either. Meticulously tracking the wrong sample group simply leads to reams of bad data.
Though it's been a year since I used Slack and from the look of things on here, they're trying their best to catch up in the bad-UX department. The drafts thing that moves channels around seems awful, too.
I have a custom ssl proxy to intercept slack.com and modify their api, eliminating what I believe to be dark patterns. Some things I do:
* Force dark mode always
* Disable favicon.ico updating when there are notifications in DnD
* Group channels based on name prefix (stealing behavior from an add-on)
* Ignore bots
It's hard to keep this up to date so it's not really that robust. If I open source it I know I'll get legal pressure from slack, not to mention they'll probably try to block it.
- Create and trust a CA
- Issue SSL for api.slack.com
- Deploy something like https://github.com/chimurai/http-proxy-middleware/issues/97 with your code to modify the response body
- Strip HPKP headers, if present
- Strip CAA in DNS, if present
1) Slack constantly makes subtle changes the UX that always takes a bit of time to figure out, I don't want to read update notes to find out how a critical comms tool has changed eg. yesterday the mac chat became psuedo wysiwhg and it broke my muscle memory and stuff bounces around while I'm typing, eg2. Drafts: FU, I didn't ask for you to reorder my UI around so I can't find stuff, DON"T CHANGE MY MENUS
2) Bugs, I left hipchat because they couldn't stop breaking stuff with every update. Many of Slack's changes are "breaking stuff" until you figure out what they've changed.
Especially proper list support is missing (ordered and unordered lists), also markdown links.
One thing that isn't mentioned is the behaviour with pressing up to edit a previous comment, it will put you into the span if the span goes to the end of the message.
I've also had numerous times where the span hasn't closed correctly leading to things in backticks not being formatted correctly (I'm guessing timing issue due to their move to react for this stuff).
It's incredibly annoying. If I didn't have to use slack for work I'd probably bin it.
When the new 'draft' feature came out I desperately wanted to turn it off(I really hate it). I opened a support ticket and spoke with one of their team members. I basically got an "It's what our customers want" kind of reply. I am the customer. Why can I not disable/enable it in an options menu somewhere?
This post says it all: 'If you prefer the old interface… well, screw you, says Slack. ... I wish Slack would provide a way to disable the WYSIWYG rich-text-input box. I don’t think it’s useful, and it’s extremely annoying...'
I miss IRC.
Please upvote parent to the top!!
It's hard to explain the concept with just words, but I will try: While you're typing, markdown is fully exposed, but when you move the cursor away, the formatting characters disappear and you just see pretty formatted text. As soon as you move the cursor back to the formatted text, the markdown reappears so you can edit the plain markdown syntax.
I've been using this editor for two years and I think the developers were really clever in this implementation; I've never experienced any unexpected issues. Slack, on the other hand, has been driving me absolutely crazy. (Try changing an inline code block after you've created it. Easy in Typora, a nightmare in slack.)
``` when you do `foo()` it foos the bar. ```
Looks fine for me? Only the `foo()` is highlighted, not the entire line as shown. Have they pushed out a fix for this already?
Perhaps this is mostly hyperbole to change. I mean, Markdown is amazing. But as stated it was only a `lite` implementation of the editor.
The new editor seems fine for me so far, though I'll gladly be proven wrong.
FWIW I'm unable to reproduce both examples in the blog post - they work correctly for me in my Slack web interface.
I'd bet the first example didn't work at some point, and then was quickly patched.
> Voice chat (Discord OK, Slack WIP)
It also lists this 'feature' which I think is hilarious:
> Not made from a web browser
Edit: Why am I being downvoted? https://old.reddit.com/r/discordapp/comments/8tukek/ripcord_...
https://api.slack.com/community
we find
"terminal-slack - Terminal client for Slack"
"Slacker - Simple Slack client for the CLI"
"scudcloud - Ubuntu client for Slack"
I'm pretty sure there are others in that list which are also standalone thirdparty clients, but clearly they would not be listing those on their own site and providing plenty of API docs if they forbid them.
"(D) attempt to reverse engineer or otherwise derive source code, trade secrets, or know-how of our APIs or Services;"
I'm pretty sure the voice feature is not part of the public API.
For me it was the video chat and voice chat though it seems he changed his tune on voice, as the last time I checked it was a 'Never'.
It also doesn't seem to acknowledge my starred channels; while the bookmarks are better anyway, those don't carry over to my phone or my other computers.
Gnome should probably have the correct DPI values, since it's a complete DE, but I'm guessing something has gone wrong with the way the Qt version that Ripcord uses is reading the DPI values.
Try something like:
QT_SCALE_FACTOR=2 QT_AUTO_SCREEN_SCALE_FACTOR=0 ./Ripcord.AppImage
Talking about slack new input box. The non-technical person would be more than happy with it. Because they don't know markdown and something that works like MS Word is good enough.
I presume people who primarily work in Word/OpenOffice/Whatever Apples thing is, feel the opposite.
If your customers include both, UI is basically impossible to get right for everyone.
1. I used to administer a mediawiki instance for R&D at a mid-size enterprise software company. It was used by perhaps 300 people. Many, many developers disliked wikitext and wanted a visual editor and/or word-to-wiki converter. Some people just prefer wysiwyg over markup.
2. If your customers include a meaningful population of both, _include both_. Make the 'friendly' editor the default, with a preference to use the old (presumably stable) editor. Obviously this doesn't work for all features, but it seems like the text entry box in the Slack app is one that could be easily configured this way (maybe not?).
I never had a problem with formatting code in slack until this release. And the hotkey (Shit+Cmd+C) doesn't work for me, although that might be my window manager interfering.
For me most annoying is that they removed setting that allowed me to configure to have up arrow to repeat the last command (like on IRC) this is very useful if you do ChatOps.
But in general I agree with the sentiment that this feature should have been easy to make optional (none of the underlying data changes, it's just a UI control), so I think Slack deserves the scorn for this one.
Related, rhe absolute one saving grace feature that I commend reddit for is old.reddit.com. It may be "ugly", but it also lets me be extremely fast when browsing (not a ton of extraneous whitespace like I can't stand in the new interface). IMO lots of "designer-led redesigns" killed many a previous chat forum (looking at you Slashdot). A common thread is many of these redesigns are built to appeal to a less expert-level user. But by doing this in a way that is not optional, you are guaranteed to piss off the folks who are the biggest users of your product. It is no wonder they are vocal!
A good product manager can make a world of difference.
But in general, I'm noticing more and more that some product and UX designers seem to be trying to pass utterly broken stuff as "oh you're just not used to it yet" type of thing, which is extremely annoying. People have been explaining the EXACT problem to Slack on Twitter since Nov 7, and they clearly said that "we don't want that" many times in the thread.
It's not the wrong decision in rolling this out with no opt-out that is the problem, it's the fucking insistince on "no it's just all the thousands of you complaining, and not us" that gets me. And they had many opportunities to admit this.
Somehow using Slack has never come up in my life. I'm sure not looking forward to it.
(Though I do know the pain of having to use some frustratingly crappy-ass software because working with a client or for an employer makes it non-optional. Come to think of it, I've done my time.)
Thanks a lot to Kevin for sharing that, you're savior.
The responses are kind of repetitive/grating in that they're non-replies and kind of stonewalling, but I couldn't help but picture some poor soul fighting against the gratuitous negativity. Some (Most?) people were being constructively negative, which I do appreciate, but the Slack employee on Twitter essentially can't give anyone any closure or solution, and is just generally powerless against the whims of the designers or whoever it was that pushed for this change.
I like all my tools just so and have gotten used to them over many years, so I definitely agree with a lot of the sentiment here. It's just that for some reason the human sitting on the other side of the Twitter account was 'visible' to me in this instance.
EDIT: just to say that for the above reason, comments like this one:
https://news.ycombinator.com/item?id=21590681
make me a little sad. It's one thing to rail on a company, but in the case of Twitter, it's another person. Maybe a team of people; I'm not sure, but I'd say the same in that case too.
Developer focused tool becomes mainstream.
Suites come in to maximize profit, engagement, in-app usages.
Early adopters leave looking for new developer focused tool.
Can't wait until slack gets snapchatitized features so I can put a cool filter and sticker on the code block messages in #devs
https://slack.com/help/articles/202288908-format-your-messag...
And
https://api.slack.com/changelog/2019-09-what-they-see-is-wha...
Share and Enjoy.
> when you do `foo()` it foos the bar.
I typed this exact sequence of characters in the new editor and it formatted exactly as one would expect.
> when you do bar.`foo()` it foos the bar
I was indeed able to reproduce this, and worse: if you put the cursor after the f, delete it, and type f again, the new f will happen before the backticks. One can tell this is about to happen by observing the cursor; even though the cursor is over the little box, it's black (as in for normal text) instead of red/salmon/whatever-that-color-is (as in for code).
That said, one can work around this by selecting all the text to be backtick'd and clicking the </> button (or pressing Ctrl-Shift-C); annoying, but slightly less annoying than having to retype things.
If it helps, you can turn off the formatting toolbar by clicking the Aa symbol to the right of the message input field.
The new message formatting is in the initial stages of launch and we're definitely planning on keeping it updated and making changes that make sense to us within the vision of the product."
I really sad to see when a "vision" is more important for a company than the customer feedback.
(I'm not affiliated with this project in any way, just thought the HN audience might find it useful)
Firefox Addon: https://addons.mozilla.org/en-US/firefox/addon/disable-slack... Chrome Extn: Pending Review
Per Sean0-'s comment, it looks like this might not be necessary though.
Edited: formatting
[1]: https://github.com/pocc/no-wysiwyg [2]: https://github.com/kfahy/slack-disable-wysiwyg-bookmarklet
Dealing with quotes is better, even.
Now I didn't need any of this, but it doesn't get in my way at all. In that regard they've done a far better job than Visual Studio, which I just can't seem to persuade not to insert random nonsense from time to time when it thinks it's being "helpful".
While I agree that non-technical persons would not get Markdown, not a single non-technical person ever messaged me something with markup. So why not just disable the shitty WYSIWYG and make markdown-formatting a opt-in choice from the sender of messages?
Also: Even Azure Dev Ops suffered from the same problem. I have no idea, how the same company can produce VS (Code or full version) and then release junk like this.
The UX around GitHub must be incredible for non-developers, because I am watching project managers with zero engineering/coding background learn markdown syntax almost accidentally. In all of our time using GH issues as a collaboration tool, I have heard exactly ZERO complaints regarding anything being broken or unfriendly to use.
We now look back on Teams/Slack/Skype/Email usage as dark days. "How the hell did we ever get anything done?" is the usual take when one of us talks about it.
git grep finds them.
Github could have put all the issues into the same repository, and built on top of that for the sake of managers, but that would make projects too portable. Having important project metadata in their domain aids lock-in.
https://twitter.com/krudolph9/status/1197180483185995776?s=2...
Here is a link to a reddit post. Please tell them this is obnoxious https://www.reddit.com/r/Slack/comments/dmyn45/does_anyone_k...
We could stand this new editor (even though it’s annoying), but what really drives us nuts are the performance issues on mobile, that there’s no way on iOS to see a screen share or to share the screen and that Slack is not integrated into the iOS call system. And when you have the pleasure to use it on mobile, it always tells you that the connection is bad
Also, I totally understand their desire to get rid of the subdomain aspect of slack. As a developer I get it, I really do, but now there is no way to easily go in the browser to the slack that you want. It used to autocomplete now I have to figure out which slack is what and I get confused.
Edit: Should've read the article:
>That is, closing backticks are not respected! If you want the proper display, you must hit right-arrow after the closing backtick (but before the space). That’s quite a gymnastic for someone with decades of muscle memory.
This is trash.
And I pushed back later after the first round of "yeah, it's the new normal, don't you like it," I wrote back with, "Yeah, no. This is a train wreck." And went on from there.
Heading now to post the URL to this discussion as a supplement to my ticket <hahaonlyserious>.
I'm guessing Slack implemented something a-la https://github.com/patleeman/quill-markdown-shortcuts, but not very well...
In general the model of allowing separate positions for cursor inside vs outside a span is a huge improvements over WYSIWYG assigning "sticky formatting" to characters. (Hat tip to TeXmacs which was maybe first time I've met that UI pattern.) But you have to do it consistently. E.g. end of literal block has separate inside/outside but start doesn't.
(Of course, in source editing, it comes for free – formatting is delimited by characters like * or ` and cursor is clearly before or after the delimeter.)
----
I believe there is a saner middle ground — formatting as syntax highlighting. You're still editing the source, no hidden state, just immediate in-place feedback. (Nowdays some call this "WYSIWYM" though it's not exactly same) Examples: https://stackedit.io/, https://codemirror.net/demo/variableheight.html, https://simplemde.com/, https://laobubu.net/HyperMD (the latter is borderline, hides too many formatting chars IMHO, but does reveal them when you move cursor to edit.)
I recently did my first post on medium. I wrote the post offline in markdown, copied and pasted it in. Was first disappointed medium didn't support markdown so I had to go reformat all of it. That sucked and had several of the same issues mentioned in the linked article, like for example putting the cursor at the start of a `inline-code-block` and typing puts what you're typing outside the block. The only way to edit the start of the block is put the cursor between `i` and `n` in `inline`, type your new text including a new `i` and then delete starting `i`.
Another issue is it changed all '' and "" to ‘’ and “” which I didn't notice and made all the code blocks not copy and pastable from the article.
Alex Oct 31, 2:26 PM PDT
As a software developer I want to be able to use slack to communicate mono-spaced text within messages that I write without having to touch the mouse. The recent addition of dynamic text formatting in slack breaks the preexisting markdown functionality because it is not possible for the rendering engine to guess what my intent might be on the fly.
for example if I type this message:
The uuid portion is `D6B9E544-2306-41E7-9841-FF7E2AE0A5A4`_filename.txt
but then realize that I actually wanted a hyphen instead of an underscore before the word 'filename' there is no way to accomplish this without deleting and retyping "-filename.txt" (or doing a fancy trick where you add "f-filename.txt" and then delete the leading f)
This is not a failing of your system which is quite well implemented, it is simply a matter of WYSIWYG systems not being capable of rendering text with the same precision as markdown systems.
I suggest that you make the WYSIWYG text formatting a toggleable feature for people in the software development community.
---------their very nice but not helpful response-------- Hey Alex,
Thanks for writing in, though I'm sorry to hear WYSIWYG formatting is not working for you and your team as developers. It's not currently possible to turn this off, but I can certainly understand your reasoning here, and will share this feedback with the team so that we can best understand what the right solution is.
Please note, I can't promise that we'll be making this optional anytime soon, but will let the team know why it's not working in your case.
Sorry this isn't the answer you were looking for today Alex, but thanks again for taking the time to share your feedback with us.
All the best,
Susie
Questions I ask myself about this: - Why is this not an “opt-in” feature? I could see it being useful for people not acquainted with markdown-like syntax
- What PM / UX’er thought this was a great idea? I’m sure there was internal feedback that this was less than ideal
> I'm afraid there isn't a way to revert to the old formatting method. We don't currently have plans to make the new formatting configurable though we are carefully considering all our customers' feedback.
I think I'd rather have Clippy shoved in my face.
Here are some ideas: https://qbix.com/token
Note: the token described there is optional to the system, but without a native micropayment system we have to bolt on various payment solutions like Patreon or live with ad-supported platforms. The original Xanadu vision was hypermedia with micropayments.
I wanted to mention an interesting bit of engineering outside the pure programming space. It is not enough to design the web-based payment system, but we must take regulations into account as well. In order not to be encumbered with securities laws, the token must be designed in such a way that no one rational would purchase it for speculative purposes. In Switzerland, there is a FINMA legal framework for classifying tokens as securities or not. In the US, this is achieved by fitting within no-action letters of the SEC:
https://www.sec.gov/divisions/corpfin/cf-noaction/2019/turnk...
In short, a lot goes into a system like this, and it has to be in place to allow a free market by small entities able to compete with feudal lords. (Open source is a free market with a huge gift economy, ie many things are produced without a profit motive.)
Remember AOL, CompuServe, MSN? That was a Feudal society. You had to have AOL keyword Facebook, Amazon etc. The Web browser and HTTP invented by Tim Berners-Lee is what disrupted those centralized networks so you could simply use DNS and build on your own domain. Now you could have Facebook.com, Amazon.com and that is how they were even able to get their start. Do you think AOL would have allowed “keyword GMail” as an alternative email?
Yay if we get more formatted messages on slack, and not just from technical users that have learned markdown.
Nay if I have to struggle to get my messages to format the way I actually want them to format. Having the new WYSIWYG editor show me the wrong formatting while editing doesn't make the new experience any less painful.
Slack formatting UX is now different from GitHub. Having to deal with Confluence/Jira formatting was already terrible enough - I now have to figure out how to type the same things three different ways.
Personally I prefer the browser interface because I find the Desktop notifications and the Angry Red notification icon very distracting. But it sucks to lose markdown.
- https://bugs.chromium.org/p/chromium/issues/detail?id=608393
- https://bugs.chromium.org/p/chromium/issues/detail?id=608162
If you star/comment on them to increase the understanding for Chrome's team that they are incredibly frustrating that would be amazing!
If I type an inline `foo()` it converts to WYSIWG as soon as I type the closing back-tic and everything I type after is back in normal text mode. If I left-arrow to have the cursor inside the formatted div but before "f" and type "bar." I wind up with the expected effect `bar.foo()`.
It takes one extra arrow press to move the cursor beyond the invisible back-tic to shift from the inline code to plain text regions before or after the block.
I preferred the old input just because I don't like having content jump around while typing. I'd still rather hit the preview tab to see it rearrange itself.
What I do like about it is that I'm forever pasting code snippets ``` code .. ``` and it saves me the time of entering the 3 backticks.
Based on the title, I was dreading checking this out but... I kind of like it; Keyboard accelerators for dropping in and out of the various block and list modes, quick action for code etc.
In general, I've never met a WYSIWYG system that I've found satisfactory. Admittedly, I do have a rather low anger threshold for stray invisible formatting.
At an even higher level of generality, isn't it a bit sad that we still don't have a good way of handling text on computers, something that lets you portably handle typographic emphasis but doesn't allow stray double spaces and crap like that?
It is not a troll comment. I tried to get my org to move to slack from whatsapp groups. People (non tech) love them flexibility and UI etc. However they were quickly disenchanted due to the various issues with the system like it eats a few GBs on desktop, push notifications don't work on some phones, some UI elements are very irritating (when you upload a picture, it vanishes to a progress bar, trying to type anything with a / makes slack believe I am typing a command etc etc).
We all went back to WA groups
when you do `foo()` it foos the bar.
It's possible that the author got a different release. It's also possible that the author was trying other very similar scenarios that behave differently, e.g. backquotes behaves differently at word boundaries and inside a span that has already been converted to the code-formatted rendering.
Overall it's pretty confusing, but the simple case that the original article points out works fine.
Not the best improvement, not the worst.
But they will probably correct the pain points listed in this article, why would they revert back their change if this is the best for Slack overall ?
Coming here is good to draw the attention on those issues so that they can fix it, but this is not the end of the world !
If you’re on multiple Slacks, as is becoming increasingly common these days (I have 23 Slack accounts, five of which I’m logged in to on a daily basis), the UX is terrible. Whenever you switch from one Slack to another, you have to wait for the whole UI to reload, often takes several seconds.
You’d think all that VC money would make them able to afford building a proper desktop client instead of this Electron shovelware crap.
Microsoft, Facebook, and others are going to eat their lunch as a generic workplace chat tool.
And if your clients are developers than they're going to have different needs and wants than your average non-tech user. They understand markdown, they don't want the editor overriding their intent.
when you do `foo()` it foos the bar.
His second big gripe is you can't position your cursor before a styled phrase and add to the front of it. That's a legitimate annoyance, but tbf Google docs and TextEdit behave the same way.
I'm 1000x more annoyed with the features taken away from ScreenHero than this stuff. Or the channels jumping over to some "draft" list.
``` blocks are such a pain in the ass to edit now. Say you have ```aaa bbb``` and you decide you actually want... ```aaa``` ```bbb``` You get stuck in the stupid codeblock editor, to actually leave it, you need to insert newlines and extra ``` until it splits AND YOU END UP WITH MORE ```. Slack...please fix this garbo
I didn't need it, but it's not broken (any more?) as described and as I feared reading earlier.
Slack really is just such a frustrating tool to use (or rather be forced to use).
backtick backtick backtick command-v
It doesn't seem perfect but come on, it's isn't terrible either. I do see however it as the perfect storm for HN crowd :)
On top of that it's running a terrible (yet seemingly good, so people are fooled by its looks) Electron app, when all you wanted as a native app.
If I can find a good alternative to Slack tomorrow I'll move my entire organization.
This seems better than what I was doing: put the cursor after the first character, type the new beginning, add the same character and remove the same character from the beginning. Thanks for the tip!
This is such an obvious improvement for developers who share code constantly via Slack.
In fact, such an improvement, I would seriously switch chat apps to get it.
Productivity tools need to be very careful about radical change. Especially when the change won’t make anyone more productive.
It's hard enough for people to hear criticism or fix mistakes without their head, or a colleague's head, being called for.
The rest of the GP comment was fine.
It's unlikely that the person in question is reading this HN thread, but there's a chance that they are, and that means we should do better.
Here's the thing: maybe we don't owe "a lead at a company as high profile at Slack" any better, but we owe ourselves better in order to have a decent community. That's what https://news.ycombinator.com/newsguidelines.html is about.
I had a quick glance at the API. It does look possible. What's the catch? Am I missing something?
I’m not a fan of Teams, but at work we’re switching Slack because we get it as part of our licensing agreement (3,000ish users.)
Argh.
Extremely dumb way to roll out something without an option to disable it, especially with the excuse "we are listening to your feedback". They literally are not listening to it.
Sure roll out a WYSIWYG editor but make it optional via a config flag.
The changes are so obviously ill considered, and, without having the data to prove this, I believe it’s trying to solve a problem that very few people had with the previous solution.
- just
- a
- simple
- list
If I needed anything more complex that that, Slack was already the wrong tool
Annoyances like this is not enough to make me toss it but it is still an annoyance that could have been fixed by giving user an option
when you do `foo()` it foos the bar.
I do observe the second issue re trying to edit `foo()` to `bar.foo()`
- paste some code
- go to the top and add ```
- go to the bottom and add ```
Now to make this work you have to
- add ```
- only then paste the code
It's a "first world problem" but many small issues like this make stuff annoying as hell
It's a bit annoying that there is no way to toggle the WYSIWYG rendering, but for me personally there have been countless times when I was missing some kind of preview while editing. For instance to align stuff in preformatted blocks...
Does anyone know why it only shows on one of my two Slack workspaces?
My personal pet peeve is threads. The feature I didn't ask for, but can die in a fire. Or they could make an option to have it auto flatten all threads.
This seems like literally one bug.
More seriously, while "this doesn't work right" is part of the complaint, the larger complaint is "this is fixing something that wasn't really broken." If Slack wanted to improve their editor, that'd be great, but they could have done that without losing what people liked about the old system. It's not like there's a lack of "quasi-WYSIWYG" Markdown editors out there to take cues from.
Can’t you just tap on the “Aa” icon to hide it?
The new behavior is maddening.
At MongoDB, we were supposed to be on it at all times. It was a continuous source of stress and broken concentration. It is what I left behind most eagerly.
Curiously, Google Chat has not become similarly stress-inducing. Yet. Gmail has become moreso lately, though. At least once a week it manages to conceal an important message.
Since Google Chat works, I expect them to drop it soon.
Because I often can't find the message that pinged me, it's extremely stressful. I worry people think I ignored them, when in reality I never saw their message, despite actively looking for it.
Note: No affiliation with Mattermost.
I like the new editor. They shouldn't revert the changes. Like any change on any software, people will complain first, some issues will be solved, and then will adapt and stop complaining.
How can this have such an impact in your lives?
Stop slacking and work ;)