4 ms·

> It's not just the FOSS community, look at how non technical people react every time gmail, outlook or excel makes a tiny change to the UI This seems to point

> It's not just the FOSS community, look at how non technical people react every time gmail, outlook or excel makes a tiny change to the UI This seems to point to the general situation of change fatigue. If you pick up a random Android device, what does the "settings" app icon look like? Individually, these things are small, but the small impedances these changes introduce does take a toll on people, especially when you're trying to just get stuff done. I don't think there's an easy answer here when the developer needs to make fundamental changes, though.

gregmac 6y ago
> Individually, these things are small, but the small impedances these changes introduce does take a toll on people, especially when you're trying to just get stuff done. One of the problems is a parity disconnect. A developer/PM often has very different perspective from their users: They see the new changes as they're happening and so they're all small, incremental changes, plus they're closely following development. A lot of users only infrequently update and/or infrequently use certain features, and so for them, all these small incremental features add up to be massive change for the sake of change. This will often manifest as "Every time I go to do x, it's totally different and I have to re-learn everything!". I find a lot of software -- especially FOSS -- also communicates change poorly. Release notes are the primary way to get across changes, yet there are several bad things people do that make it basically impossible to read: * List every change or commit message, especially without categorizing or simplifying the wording * Don't properly highlight feature changes (eg with screenshots and/or reasoning) * Have dozens of betas/pre-releases, but don't consolidate the release notes into a final "here's what's changed since the last main release" document Some examples of exceptionally good release notes: Visual Studio Code [1], Jira [2], Gitlab [3] (though if they only provided their changelog [4] it would be a good example of being overly verbose to the point of unusable). [1] https://code.visualstudio.com/updates/v1_52 https://code.visualstudio.com/updates/v1_52 [2] https://confluence.atlassian.com/jirasoftware/jira-software-release-notes-776821069.html https://confluence.atlassian.com/jirasoftware/jira-software-... [3] https://about.gitlab.com/releases/categories/releases/ https://about.gitlab.com/releases/categories/releases/ [4] https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/CHANGELOG.md https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/CHAN...
fpoling 6y ago
In many cases the UI changes are driven by the desire to attract new users under assumption that the previous UI was not sufficiently attractive.
- GoOnThenDoTell 6y ago
  All UIs are clunky in some way or another. Most people are just happy to accept it once they’ve learned it. Changing it every five seconds makes it easier for them to try a competitor, as they’ve lost all the muscle memory

gregmac 6y ago

> Individually, these things are small, but the small impedances these changes introduce does take a toll on people, especially when you're trying to just get stuff done. One of the problems is a parity disconnect. A developer/PM often has very different perspective from their users: They see the new changes as they're happening and so they're all small, incremental changes, plus they're closely following development. A lot of users only infrequently update and/or infrequently use certain features, and so for them, all these small incremental features add up to be massive change for the sake of change. This will often manifest as "Every time I go to do x, it's totally different and I have to re-learn everything!". I find a lot of software -- especially FOSS -- also communicates change poorly. Release notes are the primary way to get across changes, yet there are several bad things people do that make it basically impossible to read: * List every change or commit message, especially without categorizing or simplifying the wording * Don't properly highlight feature changes (eg with screenshots and/or reasoning) * Have dozens of betas/pre-releases, but don't consolidate the release notes into a final "here's what's changed since the last main release" document Some examples of exceptionally good release notes: Visual Studio Code [1], Jira [2], Gitlab [3] (though if they only provided their changelog [4] it would be a good example of being overly verbose to the point of unusable). [1] https://code.visualstudio.com/updates/v1_52 https://code.visualstudio.com/updates/v1_52 [2] https://confluence.atlassian.com/jirasoftware/jira-software-release-notes-776821069.html https://confluence.atlassian.com/jirasoftware/jira-software-... [3] https://about.gitlab.com/releases/categories/releases/ https://about.gitlab.com/releases/categories/releases/ [4] https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/CHANGELOG.md https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/CHAN...

fpoling 6y ago

In many cases the UI changes are driven by the desire to attract new users under assumption that the previous UI was not sufficiently attractive.

GoOnThenDoTell 6y ago
All UIs are clunky in some way or another. Most people are just happy to accept it once they’ve learned it. Changing it every five seconds makes it easier for them to try a competitor, as they’ve lost all the muscle memory