Reading their non-replies on Twitter feels like I'm reading something specifically designed to piss me off. Smarmy apologies, low empathy, cocksure of how correct their vision of a chat service should be.
This one in particular[1]:
> The goal is for workflows to evolve, but we realize change can be a bit of a pain.
"Stupid peasant, we are only here to help you. Once you see the glorious vision we have you will thank us."
This exchange is a pretty good summation of one of the biggest purely practical reasons why I'm so obsessive about tools, and why I'm so willing to put up with the initial cost of learning systems like Linux and Vim/Emacs.
Outside of fundamentally better workflow improvements, most professional fields don't randomly change their tools. If you gave a professional artist a new pencil that had to be gripped differently for no reason, they'd throw it in the trash.
But in software, we tolerate buggy tools that change all the time for no discernible reason. We tolerate software that simultaneously targets professionals and casual users, serving both segments poorly. We tolerate software that can't be customized or adapted for specific workflows. It's tough to put into words, but if you watch a musician or a painter interact with their tools, there's a very clear difference that emerges, and over time you start to realize how much better all of their stuff is.
In most professional artistic settings, workflow changes only happen because they have a clear benefit -- drawing from your shoulder instead of your wrist, changing your embouchure if you play an instrument. And even in those fields, it's generally accepted that over time people will end up with very specialized setups that are very consistent and refined and that remain constant for years and years.
Only in the software industry would someone tell me that my professional tools should change because change is inherently good. Only in commercial software would an elegant, consistent interface like Markdown that allowed me to build up decades of muscle memory until my computer was an extension of my fingers and I didn't need to think about the way I typed -- only in software would that be considered a bad thing.
Another thing in Slack that has annoyingly changed (without an option to toggle off) is: its "Drafts" feature - where leaving a channel with an unfinished message means that the channel itself gets moved to the top of the left sidebar. This completely breaks my flow, because 1.) you can no longer use up/down hotkeys to reliably go between specific channels, and 2.) I frequently have to do a double take and ask, "where did that channel go?" - especially if you Star specific DM channels, because those go under the drafts section but above the rest of the channels, meaning the Drafts section is out of view most of the time.
Long ago I created a Chrome extension that reordered things nicely, but their CSS changes frequently which made it a maintenance hassle, and I read on HN another dev saying doing so is against their terms of service anyway. Not a fan of that anti-tinkering attitude.
SLACK: don't make dramatic changes to a user's workflow without giving a simple toggle to preserve old behavior.
I get it, most users probably love this feature. My wife does, for example, and she works at a big organization, which has different needs from my workplace. But even if dramatic changes to product are approved of by 75% of users, every time you do so, you create whiplash for the other 25%, and prevent many from ever loving your product. Rinse and repeat that whiplash too many times and product design rants on HN with 600+ upvotes will be a regular occurrence...
I use Slack very often, and I also get annoyed that Drafts features often tugs a frequently-used channel to a different spot in sidebar. "Where did that channel go?"
I am so glad you said this! It drives me mad. I think of the lists of users/channels in slack alphabetically so even now that I'm aware of the "drafts" change I still go through this shock every.damn.time.
The crazy thing to me is that if they rolled out a native desktop app that was maybe a little bit lacking in features and used ~20MB RAM and had this particular misfeature in it and called it beta, people would applaud them for it, especially here on HN.
Instead they spent actual time, effort, and money making their product worse.
My company has certain deficiencies, but one of our core principals is that we'll never break a workflow, even if the workflow is dumb, even if the "feature" is actually a bug that an enterprising user abused in a way we didn't anticipate. The bad news is that we're saddled with a ton of legacy crap that can't be rewritten. The good news is that we've grown into one of those behemoths that dominates a niche specialized industry and won't be unseated by a product that is only, say, twice as good as ours. It's not as fun as iterating fast and breaking things, but the low stress is nice.
After this change I really want to develop a native chat application on Windows and OS X. I think it’s almost to the point where someone who did they could make a killing.
This is honestly a major contributor to the badness of software in general.
Ideal software would be continually fine-tuned and shrunk -- there'd be no bi-annual massive redesign, no change for change's sake alone. Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points, a well-run project would make something work well and then they'd leave well enough alone, focusing only on bugfixes, performance, and other "boring" projects that don't make for big press releases. Changes to working products should be as surgical and minimal as possible.
A good compensation structure that would prioritize stability and consistency would pay an ongoing royalty to the relevant technical people based on the product's performance, uptime, and minimal crash/bug occurrence. "Hours worked" would be minimally relevant. One wonders if so many people would be so desperate to desecrate their production infrastructure if a high-quality work product and compensation were actually correlated.
But because we can't break out of the assembly-line 40-hours-per-week mentality, we pay developers as if they're line workers, and there's always got to be something on the line to keep those worker bees buzzing, regardless of the aggregate negative impact of constant uncoordinated meddling in complex systems.
> Instead of bored devs sitting around an office looking for ways to integrate $FRAMEWORK_OF_THE_MONTH and get those coveted resume points
This hits painfully home for me. I learned a few weeks ago that some of my coworkers did something akin to this. They were working on what was frankly a mostly-silly project to preserve the relevance of increasingly irrelevant internal tools. Once they had produced something working, they stopped. Then they re-implemented the whole thing in Rust.
Which few in the company know or use. There are no clear benefits to this except exciting resume points for the developer in question.
In 1995, Niklaus Wirth wrote "A Plea for Lean Software" - abstract "Software's girth has surpassed its functionality [..] The paper discusses some causes of "fat software" and considers the Oberon system whose primary goal was to show that software can be developed with a fraction of the memory capacity and processor power usually required, without sacrificing flexibility, functionality, or user convenience"
That was discussed on HN in 2014[1] and right in the top comments is "I think one factor that leads to bloated, ruined software was missed... I don't know how common it is overall, but I have personally seen it ruin several very good products. And that is the simple fact that employers want their employees to remain busy. If a piece of software reaches a point of exceptional quality - the developers working on it still have to fill 40 (likely more) hours a week to appease bosses. And so they do the only thing available - they ruin the product."
And they are all scrambling to data mine every arbitrary slice of the data to make it look like the musical chairs of features somehow drove conversion and the lack of bottom line fiscal performance is some other department’s fault for handwavy reasons.
If we embraced this philosophy none of us would be typing quickly on touch screen phones. Steve Jobs knew it beat a physical keyboard, and when pressed by people who complained about the new iPhone's touchscreen keyboard, he grinned and said "You'll get used to it." And oh boy, did they ever.
No, they didn't. They just stopped typing. Hence, bullshit UI's like Instagram.
> Steve Jobs knew it beat a physical keyboard
Yes, if by 'beat' you mean 'made it too expensive for general use'. But in general it was a huge blow to usability, productivity and general global intelligence.
But to that point, how many professional transcriptionists or programmers are using a touchscreen keyboard to do professional work now? Have we all switched over to touchscreen keyboards on our laptops yet?
Your mistake here is confusing a consumer device with something designed for a professional workflow. Touch screen keyboards are, objectively, not faster to type on than a physical QWERTY keyboard. It's like arguing that because my mom got used to a using a cellphone for photography that physical lenses are obsolete.
Again, this is (in my mind) something that mostly only happens in the software industry. A professional racer drives with a manual transmission. When automatic transmissions came out, nobody argued that professional racers were holding back the auto-industry. Meanwhile in the software industry, mention that your workflow benefits from corded headphones, and suddenly you're jeopardizing the future of progress.
Your comment is a punch to the gut for me, I've been developing an internal CRM for two years that embodies many of the philosophies you describe. But while it is somewhat depressing, I'm left with questions about how bad it really is.
First, is it possible to develop software without inconveniencing business users with temporary (let's assume the ultimate products are better then the linux/vim/emacs they are superseding) regressions and inconveniences? And what is the cost in terms of time to route around such pitfalls? Would we still be able to have startups at all if products required thousands of hours of QA or perfect test suites in order to launch?
Second, if we were to set a hard rule 20 years ago that all software was to avoid this phenomenon during its development, what valuable tools and services would never have been developed at all? Would we still have Twitter? Reddit? Steam? Whatsapp? I don't have to dig far into the history of any of those tools to find near revolutions by their userbases over braindead UI or adversarial practices in the name of "vision".
I don't know, these are open questions. I just think avoiding all such frustrations you mentioned is wishful thinking and at some point it is just part of the process of experimentation and iteration. Or perhaps this process is entirely different in a small corp. versus a big corp. environment.
> Would we still have Twitter? Reddit? Steam? Whatsapp?
How many of those broke old workflows to introduce new ones with no clear benefits?
But that's not the point. We're not talking here about broad services like Reddit, Twitter, or Steam. We're talking about something more akin to a libary. You shouldn't break interfaces in a library without a strong, compelling reason.
Do things need to change eventually? Absolutely. Do they need to change today, because someone decided that the old workflows they don't like need to break for everyone? Maybe not. There's perhaps some room between the two.
It's been my experience that business software often represents a deep investment in a given workflow. Sometimes to the point where businesses are willing to spend a great deal of money to preserve those workflows and integrate new things into them - MuleSoft springs to mind.
Which is not to say that you're wrong. It's absolutely possible to develop new, improved software that's better in critical ways. Sometimes people and businesses are willing to put up with temporary regressions and inconveniences to gain substantial improvements. To use the above comparison, I've seen artists invest the time in learning how to draw all over again in order to jump from paper to digital.
What Slack has done is take away what was a perfectly functional workflow for many people. This doesn't look like a temporary regression or inconvenience. This looks like a permanent, hard break without substantial obvious benefits for people who used the old workflow. Communicating with users in a way that telegraphs very clearly that Slack doesn't care at all is just gilding the lily.
That's a place where the benefits of open source and hosting your own stuff pay off.
I can stay in older functional versions for a long time without being forced to upgrade and disrupt everyone's workflow because someone in a company thought they knew better how we should work.
Jenkins, Gitlab, rocketchat, review board all open source tools that you can be running years old ( on an isolated network please ) without upgrading and being very functional...
> First, is it possible to develop software without inconveniencing business users with temporary ... regressions and inconveniences?
The trick is to avoid introducing change without simultaneously introducing perceived value to the user. Predictability and reliability are incredibly important for business users, because they're going to build processes and documentation and training around however they interface with your system. This includes both directly interfacing with your system and creating supplementary processes outside of your system to work around deficiencies your system has in supporting whatever need they have. If you introduce change, you inherently reduce the temporary predictability and reliability of the system, and the friction created for end users needs to be perceived as worth whatever value your change provides. If they perceive a benefit to themselves, it'll incentivize them to embrace and adapt to the change. If they perceive it as a regression to their processes/needs, they'll fight it and it'll eventually lead to resentment and friction between the business users and the developers.
Slack's WYSIWYG input box is a prime example - it unlocks capabilities which is convenient from Slack's perspective, and is potentially generating value for users not familiar with Markdown and are used to traditional GUI-based rich-text editors. Helping them better support the type of corporate-wide adoptions that are lucrative for them. But due to Slack's origins, a large chunk of their user base prefers the older, Markdown-based editor and perceive a decrease in value from the change. If you're going to introduce changes such as this which will be perceived as a regression by a large enough subset of users, then you need to account for that in your change management process such that it isn't abrasively disruptive.
I'm not saying that all change should be avoided. I'm saying that all change is an annoyance to your users, all change has a cost. So if you do want to force your users to change, provide them with an escape hatch so professionals can avoid that, or be really certain that the change is genuinely making things better.
Imagine that every change you're making is like hitting your user in the face with a brick. If you're going to give me something amazing that makes my life better, I may let you hit me in the face with a brick so I can get it. But if you hit me in the face with a brick and then you give me something worse than what I had? Don't do that.
Learning the basics of Vim was a really big, hard change for me, but it was an adjustment to my workflow that was made for a specific reason, that made my life better and that made me more productive, and that (importantly) was a decision I made voluntarily. It was not change for its own sake.
> Would we still be able to have startups at all if products required thousands of hours of QA or perfect test suites in order to launch?
On the contrary, how many more interesting, better chat apps would we have if every one didn't feel the need to reinvent Markdown? Wouldn't it have been more useful if instead of rebuilding their editor for no reason at all, Slack's engineers instead added new API endpoints, or experimented with encryption, or added new search tools, or addressed any of the pain points that actually get raised by professionals using their product?
I would also push back against the idea that this is simply the cost of experimentation. Vim/Emacs are much more experimental editors than Word, yet even modern remixes of those editors like Spacemacs put more thought into user customization and consistency than Word does. Spacemacs' keybindings evolve -- but they never force you to accept that evolution if it would break something fundamental to your workflow. And Spacemacs is doing way more experimental, interesting stuff than Slack is.
To add further onto that idea, prioritizing future innovation over the productivity of real users is a very software-specific philosophy about how a professional field should work. New animation techniques come out all the time, but we don't look at people like Miyazaki and say, "that man is holding us back." It seems to be a software-specific scenario where a change is proposed, users say, "I don't like it", and then engineers get somehow upset about that fact, rather than just saying, "cool, it was an experiment. Let's revert and move on."
I did not get into programming because I love computer interfaces. For me, being treated like a professional means that a company makes me specifically more productive. I don't care if a change makes things better for someone else if that change is making it harder for me to do something I love. As a professional developer, it is OK to demand tools that work well for you. Again, this is the case for every other field -- no one expects a professional woodworker to switch to a new measuring system that they don't want to use, even if that system is popular with some people.
Of course no field gets this perfect, but virtually everyone gets it better than us. I'm not demanding a theoretical utopia I can only imagine. I'm looking at every other professional field and saying, "why can't we have the stuff that they have right now?" It's very much a feeling that's informed by how good it feels today to work with physical mediums as an artist, and how utterly crappy it feels by comparison to use Skype or Windows 10.
And if that means that software moves slower, who cares? It's not theoretical to me. Other mediums are better to work in -- so whatever they're doing, we should copy, because they're better than us.
Good clarification -- when I talk about change, I mean a workflow change. XKCD aside, I don't believe that every code change breaks someone's workflow, or at least I believe that some code changes break workflows in such a minimal way that none of your users will care.
To expand on your point, how many bugs and crashes do we tolerate in software simply because rebuilding features has priority over refining features or handling more edge-cases?
Slack's new interface isn't just different, it's buggier. Stuff like copy-paste is broken. So it's not just that we have to adapt to a new workflow, we're also accepting a lower-quality piece of software that is less reliable than what we had before. And in theory a refactor or rewrite might be so valuable that I could tolerate that, but I don't see that value here.
This new hive mind of corporations empathising with the poor common man needs to stop. It is outrageously frustrating, condescending and patronising. Every CS rep is trained to say “I understand” more often than they breathe. Corporate blog posts wax poetic about their understanding of the struggle of modern life in the first world. How sorry they are to be doing exactly the opposite of what somebody would do, who actually empathised.
I will be the first to admit to a temper, but honestly if I hear one more CS drone tell me how much they understand, I swear to god I will reach through that phone and quiz them on it. Do you really? Explain it to me. In detail. So help you God if you forget anything.
Ugh.
You know, say what you will about the mob; at least they don’t treat you like you’re three years old.
That style of communication where a corporate entity pretends to be friendly and concerned even as they're downright shutting you down is extremely annoying. It comes across as dishonest and condescending. I wish this type of PR would go away.
If someone who's reading this works in social media, here's what would have been less annoying:
- Saying "it's not possible right now, but you have a point and we'll reevaluate this" (even if it's a lie)
This attitude to their rollout reminds me of the recent rollout of Twitter's maligned new desktop UI, the new YouTube Studio Beta, and reddit's new UI.
There is almost a meme of online platform service providers not understanding their users and their workflows, and rolling out new revisions that hamper or outright remove functionality that those users rely on.
I guess the canonical example would be that one Digg redesign that nuked the whole platform, or Snapchat's redesign a year ago that stunted their growth.
Luckily, we haven't had to experience this at Hacker News thus far ;)
> online platform service providers not understanding their users and their workflows
In regards to the Reddit redesign, I think the people complaining that "they ignore their users" are stuck inside a bit of a bubble.
I have a lot of friends who recently discovered the site, and they much prefer the redesign to the old one.
I forgot where I read it, but I vaguely remember stats backing this up, or at least increase in engagement or a reduction in churn for new users following the redesign.
Something like 50% of Reddit users are on mobile, for which the redesign is targeted (I believe)
Re: Slack, I know many non-techies who struggle with markdown and would welcome a WYSIWYG editor with open arms and wide smiles.
What are they using reddit for, though? Serious question. You can probably find 10x-100x the number of people who would use a site just for amusing cat GIFs vs. a location for actual discussion, but the users of each are looking for fundamentally different things. Reddit built itself on being a text-forward group of forums. The new redesign is, frankly, a dark-pattern horrorshow designed for eyeballs at the expense of deeper engagement. They're keeping old.reddit around for a reason.
I say this as someone who doesn't mind the redesign on desktop: The redesign is a shitshow on mobile. It's slow and constantly nags you to install the app.
Exactly... You don't have to expire the old front-end, you can build a new front-end on top of the old API, maybe introduce a few new functions in the API to support both old and new.
> Something like 50% of Reddit users are on mobile, for which the redesign is targeted (I believe)
The re-design just launched on mobile last week, while it has been on desktop for a very long time, so it is way too early to say what mobile users think. Personally I think that it is even worse on mobile.
I really wouldn’t mind the new UI, if it weren’t this goddamn slow (it’s at the point of unusable right now). My choice of using the old UI isn’t even a choice at this point.
It can’t be for people on mobile: the UI is buggy (especially back and forth navigation) and constantly nagging to download the native app. That’s super annoying.
> There is almost a meme of online platform service providers not understanding their users and their workflows, and rolling out new revisions that hamper or outright remove functionality that those users rely on.
True, but there's also a meme of people screaming bloody murder over a redesign for a day, and then being fine with it, e.g. [0]. Some complaints are worth investigating and some are just who-moved-my-cheese griping that can and should be ignored. It can be tricky to tell which is which though.
Smells of bad UX/design process - some senior "wants" this particular solution, despite their users showing direct feedback that it doesn't work for their needs.
I'd push back on your last point; there's a zero-sum feedback process here that is invisible. You're seeing the negative feedback from a vocal set of minority power users; the positive feedback from people isn't going to be known or seen in anything other than usage metrics.
You say "users": how many, what percentage, what cohort..you get the idea.
How do you tell the difference between unpopular features and ones that are mostly liked? In both cases, only "a vocal set of minority power users" would say anything.
With the state of statistics literacy in this industry, "usage metrics" often mean whatever the person citing them want, with no malice or deception intended. Accidental, inadvertent p-hacking is shockingly common.
Slack's voice is great when they're saying positive things, but God is it exhausting when they are replying to negative feedback. It's like listening to Ned Flanders, only with some extra patronizing emoji to rub it in
Did their engineering team not dogfood this change? What Slack engineer or product manager tried to share a `snippet of code` with a peer and thought, "yes, that was a pleasant experience. we should ship that."
Actually, the cmd/ctl-z advice is actually moderately useful. If you type it immediately after the closing formatting character it undoes the wysiwyg formatting. (I'm not arguing against a way to turn the wysiwyg input window off, however.)
That's a surefire path to irrelevance. Nobody wants groupware. Nobody uses it unless forced.
On the bright side, that would leave a hole in the market for an enterprising chat developer to fill, hopefully with something less annoying and resource intensive.
> Nobody wants groupware. Nobody uses it unless forced.
Surely you're talking about some very specific crapware subset of groupware, because plenty of people choose to use, and very much enjoy using, all sorts of groupware. Distributed version control, issue trackers, simultaneous editing of documents... just to name a few examples of incredible groupware.
But yes, generally when it claims to do all the things, it does none well. This is orthogonal.
The problem isn't implementing the features, the problem is making the UX/UI intuitive to people who call Microsoft's tech support when Firefox displays a "cannot connect to internet" message because they unplugged their router because they needed the socket for something else.
IRC is objectively superior to slack as a distributed chat client, but goddamned if the first step into slack isn't significantly shallower than the first step into IRC.
It reads more to me like whoever they hire to run their twitter doesn't have the authority/knowledge to engage with complaints other than being nice and saying "I'll pass that on". This would be fine normally, but not really when they've shipped a feature that everyone hates.
I know. I try to give the social media people leeway since they're almost always just the messengers. This thread in particular just seemed laser targeted to aggravate me.
If you are taking a job with you are specifically being paid to be a human shield, I am not going to hold back from treating you like the face of the company you are. The more abuse these mercenaries take, the more the corp has to pay to staff them, and the more the owners feel the pain of their misdeeds.
Is there any way that tweet could have been written that would have satisfied you, without actually agreeing to change course right away?
To me the tweet's tone says that they honestly care and don't want people to be inconvenienced, but also want to at least see if people will warm to it.
There has to be some kind of healthy balance between listening to user feedback and never changing anything.
The extreme version of listening to user feedback is: https://xkcd.com/1172/
> Is there any way that tweet could have been written that would have satisfied you, without actually agreeing to change course right away?
Not passive-aggressively suggesting that the problem is with the user and not the tool. "The goal is for workflows to evolve" effectively means "this is how it's going to be, you'll have to adapt (even if it's worse for you)".
My workflows have thankfully "evolved" to use different tools. Zulip and Discord both still use markdown input, and I no longer use Slack for anything.
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