You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just creating a new issue, because I have a general objection to this behaviour. If software always keeps the existing behaviour as the "default", a future variant of the software might appear confusing to new users, because all workflows are only working the way it was working in the early days.
It is hard for end users to discover that a certain behaviour is actually configurable to the demand.
I propose:
When defaults could be changed, we conduct some sort of discussion on whether the old or new style is preferable for the majority of the users. Backward compatibility is kept in mind, but the software not influenced by the personal preferences of only a few individuals
There is a system for migrating old showfiles to preserve the behaviour there. This could mean: If a value is absent in an old showfile, a custom (potentially different) value is used, because the showfile might just be older. New showfiles always save explicit settings to avoid any doubt.
Backward compatibility is important, but the UX for newcomers is, too. Due to the nature of LiSP development, many design choices are heavily influenced by few opinions. If we want to make the software future-proof, decisions should take these multiple aspects into consideration.
The text was updated successfully, but these errors were encountered:
Repository owner
locked and limited conversation to collaborators
May 26, 2023
Originally posted by @FrancescoCeruti in #266 (comment)
Just creating a new issue, because I have a general objection to this behaviour. If software always keeps the existing behaviour as the "default", a future variant of the software might appear confusing to new users, because all workflows are only working the way it was working in the early days.
It is hard for end users to discover that a certain behaviour is actually configurable to the demand.
I propose:
Backward compatibility is important, but the UX for newcomers is, too. Due to the nature of LiSP development, many design choices are heavily influenced by few opinions. If we want to make the software future-proof, decisions should take these multiple aspects into consideration.
The text was updated successfully, but these errors were encountered: