News for hackers. Stuff that matters.
Re:Settings are not a design failure by xg15 on Wednesday February 02, 2022 @03:42PM (#30183756)
I love settings.

I hate losing settings and having to fiddle with everything all over again.

I remember, back in pre-windows XP days, me and some of my friends would spend ages going through the appearance options and customisimg pretty much everything. Even later, I knew of people who had a meticulous desktop ordering or spent substantial amount of time ordering favourite icons in the browser.

All that was great fun until the first time, the settings were lost. Maybe you had to reinstall the OS (or got a new PC) or maybe the program updated and simply erased the settings. In any case, trying to redo everything you had arranged before looked to be an enormous amount of work and not fun at all. So after the second time, this happened, we gave up and accepted the standard.

But this eas not because we didn't want customisation, it was because the experience was too frustrating.

My impression is that in modern UX, not only do opportunities for customisation become less and less, the results are also increasingly ephemeral. E.g., there is still no option under Windows to save the arrangement of desktop icons - but there is a menu shortcut which will instantly rearrange everything and render your own arrangement moot. I think this shows a pretty clear priority of the designers.

My impression is that customisation opportunities are simply conflicting with a lot of priorites of moders software developers, much more so than their users: Companies want the freedom to frequently change the UI and control overy tiny detail about the "experience" - customisation runs directly counter to that. In some extreme cases, companies even want the freedom to build deliberately unpleasant designs (dark patterns).

Additionally, an inflexible UI also provides more opportunity to present some minor improvements as significant new features ("twitter now has three different colour schemes!", "iOS now can show two apps at the same time!").

Last but not least, an inflexible UI lets you actually sell certain adjustments as a premium feature - e.g. YouTube letting you listen to a video in the background.

All of this are strong incentives for software companies to get rid of settings, but none of it has to do with users not liking settings.

Re:Settings are not a design failure by f1refly on Thursday February 03, 2022 @04:17AM (#30190406)
> I hate losing settings and having to fiddle with everything all over again.

> I remember, back in pre-windows XP days, me and some of my friends would spend ages going through the appearance options and customisimg pretty much everything. Even later, I knew of people who had a meticulous desktop ordering or spent substantial amount of time ordering favourite icons in the browser.

> All that was great fun until the first time, the settings were lost. Maybe you had to reinstall the OS (or got a new PC) or maybe the program updated and simply erased the settings. In any case, trying to redo everything you had arranged before looked to be an enormous amount of work and not fun at all. So after the second time, this happened, we gave up and accepted the standard.

I was like this, and felt exactly the same. When I discovered the magic of unix windows managers, it felt like a miracle. Suddenly, I could adjust every frivolous detail to my liking, and _have it reproducable_ in a version control somewhere. When my laptop broke, I just reintroduced my package list, inserted the config and it was just like the old one! I think it's a shame so relatively few people will ever reap the benefits of a customized system over the fear of losing it randomly to a hardware failure.

Re:Settings are not a design failure by gknoy on Wednesday February 02, 2022 @03:55PM (#30183943)
It seems like a good reason to have settings be something that are _automatically exported / stored_, so that you can put them in version control and re-fetch them later, or at least export/import.
Re:Settings are not a design failure by jagged-chisel on Wednesday February 02, 2022 @07:11PM (#30186348)
Or something like a Settings Sync
Re:Settings are not a design failure by bluedino on Wednesday February 02, 2022 @08:16PM (#30187014)
One thing I discovered about the Mac, coming from Windows, was that was far easier to spend less time tweaking crap in the OS, and just going straight to work.
Re:Settings are not a design failure by spacexsucks on Thursday February 03, 2022 @02:03AM (#30189562)
BS. Mac defaults dont work for me. The mac natural scroll is anythig but. The default auto screen brightness rarely works right. Same for screen resolution. The text correction always over corrects for me. The smart power manager refuses to start even on pwoer. I could go on. It is landmine of over thinking on my behalf. The cmd tab is not reliable when switching from something to a maximized full screen app and back. I could go on about how i have to fight mac everyday.
Re:Settings are not a design failure by ixmerof on Thursday February 03, 2022 @03:30AM (#30190071)
I agree, once I had that time with my only apple device I was constantly looking for settings/tweaks/hacks to disable most of default annoyances. Most of them required hacking through the system files as there is almost none of available options to configure
Re:Settings are not a design failure by bluedino on Thursday February 03, 2022 @08:06AM (#30191914)
Those are things I change right away but I don't really count things like that.

In windows I was changing fonts, sizes, window colors, sizes of things like title bars...

Re:Settings are not a design failure by CRConrad on Saturday February 05, 2022 @08:27PM (#30228322)
> In windows I was changing fonts, sizes, window colors, sizes of things like title bars...

And was the reason that you didn't do this on the Mac that nobody would ever want to do that, or that you just couldn't?

Re:Settings are not a design failure by Underphil on Wednesday February 02, 2022 @07:44PM (#30186737)
I love settings, and I particularly despise removed settings. The logic already exists in the code to process that setting so why remove it after the fact?