5 ms·

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

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.

deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
Kalium 7y ago
> 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.
- aprdm 7y ago
  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...
danShumway 7y ago
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.
cosmie 7y ago
> 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.
fragmede 7y ago
Survivorship bias. 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.
- Exuma 7y ago
  what happened with ebay color
  - coremoff 7y ago
    https://theuxblog.com/blog/redesigning-user-experience https://theuxblog.com/blog/redesigning-user-experience

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

Kalium 7y ago

> 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.

aprdm 7y ago
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...

danShumway 7y ago

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.

cosmie 7y ago

> 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.

fragmede 7y ago

Survivorship bias. 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.

Exuma 7y ago
what happened with ebay color
- coremoff 7y ago
  https://theuxblog.com/blog/redesigning-user-experience https://theuxblog.com/blog/redesigning-user-experience