Not that I would want that feature, but what’s a good reason against it? I don’t see it hurting anything by being able to customize that, and if someone wants to why is that a problem? It seems a weird hill to die on is all
It’s a very well known problem in interface design. If you include every option that someone could possibly want, you’ll have three thousand options in the settings, and it will be impossible to find anything without getting severe fatigue from looking at all the toggles.
Consider Windows: with many advanced options, one has to click through a couple dozen dialogs in search of where that option is, getting RSI in the process. You can also take LibreOffice’s or old KDE’s settings as examples.
MacOS solves that pretty simply: settings that most people use are in the control panel under comparatively few categories and typically readily available in there. Settings that are unlikely to be changed by anyone outside power users are still modifiable through the command-line utility for that — which is actually responsible for all the settings, making MacOS very fit for automatic setup with Ansible or somesuch.
However, that’s just the design issue. There’s also the programming issue: every option increases pathways that the code may take, and thus the possibility of bugs and regressions, and the complexity of the code and tests.
A well-known approach that many companies take is to include only the functionality and settings that conform to the main vision, and focus on that working well instead of trying to serve everyone. This gets them a dedicated customer base to whom the product is tailored, instead of corporate sales made on the breadth of features, wherein the end users need only a tenth of the functions but have to wade through the whole interface. 37signals is one such example of a narrowly-focused company. Github’s issues system is likely used by way more people than Jira, Bugzilla and such, despite being quite poor in functionality in comparison — but it also doesn’t need a two-hundred-pages manual to use.
But if this is in a config file for an individual app or piece of software, I’d assume it would be importing the default, system-wide settings in some capacity. Even if it wasn’t a default setting in the config, being able to add modifiers to otherwise default settings isn’t the same thing as burying a setting under several layers of menus.
It can be shipped with a default mode of “this is how we intend this software to be set up and used”, and then the 500 page manual for “customize at your own risk”.
It just seems like there are several steps between “all the options” and “no options”. And changing cursor speed, for example, could be an accessibility thing. Needing to be slower/less sensitive for a sliding bar in a specific gui menu, but can be normal speed for the rest of the system.
Or if I want to change the colors of different windows. Whether for organization purposes, or to fit a theme, or whatever. I just thing getting to play around with and customize some of that stuff is neat, so it’s nice to hear the other side of why that customization wouldnt be allowed, even if I’m still unconvinced in this instance.
slower/less sensitive for a sliding bar in a specific gui menu
I’ve never heard of such a requirement for any reason, and I’ve been around for a while and tend to read more than a little. As I wrote in another comment, I’ve only heard of the originally mentioned scrolling speed being a nuisance when the app doesn’t follow the system-wide settings. So the tradeoff of the demand to cost of implementation and support isn’t in your favor.
Configuring this would be quite cumbersome — the user would need to specify the whole hierarchy of UI elements for the specific window, including intermediate invisible elements. Whereupon the app would just offload that to the GUI framework, which presumably would handle the functionality and add that to the myriad of aspects that it must handle already.
However, this is probably already possible to implement in MacOS without any need for ridiculous configs on the part of the app: via a separate app using accessibility APIs. Iirc those APIs can report the UI elements that the user is engaged with — and if it reports the cursor hovering too, then the app could change the cursor speed dynamically. It’s possible even that Hammerspoon, programmable in Lua, can do something like that. Of course, apps not made with the native Cocoa framework break this and other accessibility functionality.
As for the colors of the windows, there comes a time in the life of a man when they realize they’d like to get shit done instead of fiddling with customization, and for the UI to fade away and do its thing quietly. I’ve seen it happen.
Not that I would want that feature, but what’s a good reason against it? I don’t see it hurting anything by being able to customize that, and if someone wants to why is that a problem? It seems a weird hill to die on is all
It’s a very well known problem in interface design. If you include every option that someone could possibly want, you’ll have three thousand options in the settings, and it will be impossible to find anything without getting severe fatigue from looking at all the toggles.
Consider Windows: with many advanced options, one has to click through a couple dozen dialogs in search of where that option is, getting RSI in the process. You can also take LibreOffice’s or old KDE’s settings as examples.
MacOS solves that pretty simply: settings that most people use are in the control panel under comparatively few categories and typically readily available in there. Settings that are unlikely to be changed by anyone outside power users are still modifiable through the command-line utility for that — which is actually responsible for all the settings, making MacOS very fit for automatic setup with Ansible or somesuch.
However, that’s just the design issue. There’s also the programming issue: every option increases pathways that the code may take, and thus the possibility of bugs and regressions, and the complexity of the code and tests.
A well-known approach that many companies take is to include only the functionality and settings that conform to the main vision, and focus on that working well instead of trying to serve everyone. This gets them a dedicated customer base to whom the product is tailored, instead of corporate sales made on the breadth of features, wherein the end users need only a tenth of the functions but have to wade through the whole interface. 37signals is one such example of a narrowly-focused company. Github’s issues system is likely used by way more people than Jira, Bugzilla and such, despite being quite poor in functionality in comparison — but it also doesn’t need a two-hundred-pages manual to use.
But if this is in a config file for an individual app or piece of software, I’d assume it would be importing the default, system-wide settings in some capacity. Even if it wasn’t a default setting in the config, being able to add modifiers to otherwise default settings isn’t the same thing as burying a setting under several layers of menus.
It can be shipped with a default mode of “this is how we intend this software to be set up and used”, and then the 500 page manual for “customize at your own risk”.
It just seems like there are several steps between “all the options” and “no options”. And changing cursor speed, for example, could be an accessibility thing. Needing to be slower/less sensitive for a sliding bar in a specific gui menu, but can be normal speed for the rest of the system.
Or if I want to change the colors of different windows. Whether for organization purposes, or to fit a theme, or whatever. I just thing getting to play around with and customize some of that stuff is neat, so it’s nice to hear the other side of why that customization wouldnt be allowed, even if I’m still unconvinced in this instance.
I’ve never heard of such a requirement for any reason, and I’ve been around for a while and tend to read more than a little. As I wrote in another comment, I’ve only heard of the originally mentioned scrolling speed being a nuisance when the app doesn’t follow the system-wide settings. So the tradeoff of the demand to cost of implementation and support isn’t in your favor.
Configuring this would be quite cumbersome — the user would need to specify the whole hierarchy of UI elements for the specific window, including intermediate invisible elements. Whereupon the app would just offload that to the GUI framework, which presumably would handle the functionality and add that to the myriad of aspects that it must handle already.
However, this is probably already possible to implement in MacOS without any need for ridiculous configs on the part of the app: via a separate app using accessibility APIs. Iirc those APIs can report the UI elements that the user is engaged with — and if it reports the cursor hovering too, then the app could change the cursor speed dynamically. It’s possible even that Hammerspoon, programmable in Lua, can do something like that. Of course, apps not made with the native Cocoa framework break this and other accessibility functionality.
As for the colors of the windows, there comes a time in the life of a man when they realize they’d like to get shit done instead of fiddling with customization, and for the UI to fade away and do its thing quietly. I’ve seen it happen.