Most people don't love fiddling with settings. People love when software does what they need, and some of them will be willing to fiddle with settings if they have to. Settings are a cost the user pays (just like data entry, loading times, hard drive space, loss of privacy, ads, or the monetary price of the software) in order to get the value. If good defaults mean most users don't have to muck with settings, great, your software is now more valuable. But the only thing worse than having to tweak a setting to get your functionality is not being able to get your functionality at all.
I'm not a designer, but I have done a fair bit with HCI for whatever that's worth. I recently read "The Design of Everyday Things", which I understood to be a seminal text in the UX world. In it, Norman argues that no one-size-fits-all product actually fits all and leaving off 1% of the population is still a rather large number of people, so in the spirit of human-centered designed you should provide options or settings to support those people as well. I've been struggling to reconcile that with UX of many software products in the time since.
The modern UX ethos seems to be that settings indicate a failing of the product and if people don't like the path laid out for them, they're either wrong or they can go use something else. I think the book also makes the argument that constantly breaking workflows isn't very user-friendly either, but SaaS products routinely change their UI and workflows around. I suppose I can see the business justification for that, but that doesn't necessarily make it good UX.
Of course, Norman could just be wrong or my interpretation of his text could be wrong. Either way, something feels off to me with modern UX. I suppose if you've run actual user studies (not just A/B tests), then you have more contextual data than I do. But, I came away from reading the book really wishing more software products (both SaaS and the recent spat of "opinionated" frameworks/tools) followed the principles he championed.
In the 1950s the United States Air Force wanted to figure out what pilot dimensions they should design to. Things like the exact position of the controls and position and size of the seat.
They measured over 4,000 pilots on 140 different dimensions. The hope was that they could design to the average pilot. What a Lieutenant named Gilbert Daniels found was that even if you only looked at the 10 most important dimensions, not a single actual pilot was within 15% of them all. Even just a handful of dimensions would fit almost no-one.
The consequence of this was that everything became adjustable.
This is a great military-design story, along with the one about how you shouldn't put armor over the places where returning airplanes got shot, but the spots that were probably shot on the airplanes that never returned.
I would counter your evolution point. Evolution hates brains and wants them to be as small as possible, because they cost a lot of energy. Saving energy is the reason our brains rely so much on biases and heuristics.
I’d like to find someone with more citations to back up this claim, but my hypothesis is that evolution favors the biggest, baddest, and most intelligent during stable times. In an unstable environment, small stupid generalists are what survive (thanks to their lower caloric needs).
Eh, I don't think your claim about stable and unstable environments works in general. Things are just too diverse in this universe.
For example, just for humans a big, big driver of instability in the last few millennia has been other human brains.
Also keep in mind that (in-)stability and harshness of environment are too almost independent dimensions; if you see instability as something like the variance of outcomes.
Eg if some new opportunities open up, everything is strictly better (so the environment is less harsh), but variance might shoot up dramatically, perhaps because only the clever and resourceful can make use of the new opportunity.
What you say is true, but it's not a counter: it's not at all at odds with what I suggested as far as I can tell.
Evolution only suffers brains to exists, if their advantage outweighs their costs. (Though keep in mind that the example I gave is a bit broader than just brains: any way for an organism to learn would fit the bill. That doesn't necessarily need to be a full sized brain, if fewer nerve cells do the trick, too.)
Similarly, smart and resourceful leaders for your company are only useful if their advantage outweighs their costs.
In any case, read the linked Gwern article for a deeper discussion. I'm just rehashing the main point here, Gwern has more to say.
>> Basically, war (or the threat of war) is what keeps militaries honest.
> It really does not.
I meant 'honest' in the sense of suffering if they bullshit themselves too hard. Not 'honest' in the sense of dealing with third-parties honestly.
Could you expand on your point?
>> Competition and the threat of bankruptcy keeps companies on their toes.
> Only some companies and some of the time.
Maybe. And that suggests that one goal of public policy should be to subject more companies more of the time to these pressures. Eg by abolishing tariffs, lowering barriers of foreign companies entering local markets or buying subsidiaries; allowing WalMart to become a bank, and banks to sell coffee etc.
>> One defense of free markets notes the inability of non-market mechanisms to solve planning & optimization problems.
> s/notes/falsely claims/
Not sure what you are complaining about here? If you read the rest of the introduction, it's rather clear from context that the author agrees with you here. (You don't even need to read the whole article for that insight.)
It might be an over-adjustment from the software designers. In the early days of software, there was a larger fraction of power users, who wanted lots of options and were willing to fiddle with them. However, settings were often an excuse for not having sensible defaults, auto-detection, context-sensibility and other things for a fluid user experience.
Then came a wave of companies focusing on UX with great success, who often dropped settings to focus on "magic" functions etc. This means UX becomes correlated with less settings, but removing options does not help users - on the contrary! But unfortunately it gives the impression that settings are bad for UX.
Options do become dangerous to the team building the UI, though. It's easier to add another option and the keep the previous behavior as default than to do the hard work of figuring out what the best behavior is and then, if the new behavior is better, having the courage to change the default. Having no options is good for discipline as it removes the temptation of doing it the easy way.
There's also the problem of bugs. Software with more settings have more code paths. It's harder to test, and harder to refactor.
Are the different laundry programs on a washing machine due to the design failure? My oven has separate knobs for temperature, heat distribution and grill; is that a design failure?
My car has both a steering wheel and a separate indicator light control; rain sensors and a manual wind screen wiper setting; light sensors and a manual setting for the headlights.
Are these all examples of designers' inability to make decisions?
Often when that decision is made it is taken away from the user. For example when "There are decent sounding arguments for both" it is often exactly the right choice to leave the option available if it doesn't come at too much cost.
Often used ones aside options are generally so hidden away anyway and thus the choice of a sensible or popular default can be made regardless without complicating the main UX.
but if they are either mutually exclusive, or that one must be selected for the operation to work, then the designer/developer has to choose a default.
Often, the user don't even know what they want, and assume the default is the right choice, since it's "professionals" who have chosen it.
Of often they'll be unaware the setting exists or even more likely be unaware that the setting even _might_ exist (and therefore don't even think to Google it).
Though often still theyll be afraid to look around at settings for fear of breaking things.
These are all valid concerns, but UX is purportedly concerned with serving the user. Reducing expenses is a competing concern. Together, they influence the design, but I don't think it follows that removing options leads to a better user experience. It could, but it's not a given.
> It's easier to add another option and the keep the previous behavior as default than to do the hard work of figuring out what the best behavior is and then, if the new behavior is better, having the courage to change the default. Having no options is good for discipline as it removes the temptation of doing it the easy way.
Ideally, you already knew what the trade-offs are before you built the feature. That should have come out of a user study. Human psychology simply doesn't change as substantially or as frequently as modern UX seems to suggest. Of course, things can fall through the crack and you can learn new things (even that previous conclusions were misguided). But, setting up all options as a choice you need to make for the user isn't necessarily helping the user experience. Some portion of the world prefers a 12 hour clock, some portion a 24. If you're adamant about only showing one of those and it's not configurable, you haven't helped the people with a different preference. You're inflicting your design on people without really taking their cultural norms into account. I'd go a step further and suggest changing defaults on people is something that should never be taken lightly because the user experience isn't a point-in-time thing. Changing workflows on existing users is a negative user experience in many cases.
As a concrete example, the ReasonML language forked into another language call Rescript. The code formatting tool in Rescript works almost identically to the one in ReasonML and that's by design, since it's supposed to facilitate migration. But, for whatever reason, the new formatter dropped the option to configure line width. So, if you used to set your line width to 120 characters, too bad. You have to use 80 characters or don't use the tool. Also, you need to chance your workflow and any configurations using the old flag.
Having the option to change a numeric variable is not some overwhelming burden. Forcing a fixed value isn't some courageous decision and it's not based on any human factors studies. It feels like an overreach of "opinionated software" that ultimately made my code harder to read (both languages use annotations that artificially increase line length). In the end I abandoned the migration, which I suppose means if they poll community members, they'll have something of an echo chamber.
> There's also the problem of bugs. Software with more settings have more code paths. It's harder to test, and harder to refactor.
This sounds like a failing of software engineering to me. To the extent that this field's raison d'être is to make computers perform work for humans with minimal fuss, our tooling should be geared towards supporting that goal. Dropping functionality that would be beneficial to people because it's more difficult to support sounds like trying to mold people to the machine rather than the machine to people. Certainly, you can have a product that functions, but it's similar to all the other things we have to put up with because a better option doesn't exist. This take isn't drawn from the book I mentioned, but I think the book has influenced my opinion on the matter. If settings/options lead to a better user experience but our tooling and development processes make adding settings/options difficult, we should try to improve our tools and processes.
With that said, we have to operate with the constraints we have. I just don't think we should convince ourselves it makes for a better user experience. That sort of thinking tends to snowball.
The central problem of modern UX is the same existential crisis architecture had in the 1980s -- whether it's a discipline of artists or scientists.
Nobody wants to admit they're a scientist who follows experimental data at cocktail parties. Everyone dreams of being introduced as a creative genius.
That yearning metastasizes into hubris, which ultimately leads to people making arbitrary changes, just because they can.
Which isn't UX's, or architecture's, fault as a discipline, but is to say that the scientific process runs perpendicularly to our egotistical, flawed selves. And that the only way to avoid it is constant vigilance and pragmatism about what's actually driving a change request.
> In the end I abandoned the migration, which I suppose means if they poll community members, they'll have something of an echo chamber.
Harking back to the survivorship-bias example above (reinforce warplanes in the bits that weren't all shot up on the ones that returned), if they define "community" as the users of the new language, they'll never realise line length was a significant problem: You and all the others like you aren't there to answer the question "Was line length in the code converter a problem for you?" with a resounding "Yes!", they'll get only "No" answers, and not realise what a huge impediment it is.
Perhaps users early in their journey with your product want it to “just work”, because they don’t want to fiddle with loads of settings they don’t understand only to find your product is rubbish.
As they become more proficient with your product, if they can’t tweak behaviour in certain ways, they might consider changing to a different product. And that’s where settings become useful.
> The modern UX ethos seems to be that settings indicate a failing of the product and if people don't like the path laid out for them, they're either wrong or they can go use something else. I think the book also makes the argument that constantly breaking workflows isn't very user-friendly either, but SaaS products routinely change their UI and workflows around. I suppose I can see the business justification for that, but that doesn't necessarily make it good UX.
Yeah, I think the issue is that once you've finished designing an interface or your software is feature complete, the company is faced with a problem: You don't have any actual work, but you absolutely need to maintain your expertise and sales.
What features can you really add to Excel at this point? What do you do when your market analysis says your application and interface are about the best they can possibly be? What do you do with your engineers when your product is, by nearly all measures, complete?
This is the problem that Google search has. And Microsoft's Windows and Office teams. We had basically everything on lock for quite awhile. Changes now are seldom improvements. They're just changes to justify the engineers' salaries that the company has to keep paying because maintaining that is a core competency. Moving all of them to a new project spoils your expertise in your own product so you can't just do that.
At this point, UX design for these products should probably shift to aesthetics, much like the auto industry did. And that's largely exactly what Windows has been since Windows 7. Aesthetic changes.
> What features can you really add to Excel at this point?
Aren’t there actually lots of good features Microsoft added in say the last 19 years (office 2003 having, for this argument, a perfectly capable Excel with all the features)? Off the top of my head:
- Ribbon and context-aware toolbox made it easier for infrequent or novice users.
- good default styles for tables, which is what lots of people actually use Excel for
- Better support for actual tables (ie defined extendable ranges of cells)
- OFFSET/MATCH instead of VLOOKUP (maybe this was a culture change. Not sure when OFFSET or MATCH were introduced)
- improvements to default graph appearance (though I still dislike them for just showing the data)
- Lambda functions
- Relational models for data
- bigger spreadsheets
- flash fill(?) which is a magical programming by example thing
- fancy conditional formatting with colour changing smoothly with values
- possibly faster evaluation. I don’t know if it was actually improved
- maybe someday: collaborative editing
I’d like to point out that some improvements were made for power users and others for more ordinary users.
> - Ribbon and context-aware toolbox made it easier for infrequent or novice users.
But did they have to make it worse for nonnovice users by removing the old menus and toolbars?
> - good default styles for tables, which is what lots of people actually use Excel for
An Excel sheet is already in and of itself a table.
> - Relational models for data
Yeah, thanks, we already have RDBMSes for that. Turning Excel into an RDBMS (or an RDBMS into Excel) only gives you a jackalope: Worthless both as a jackrabbit and as an antelope.
> - flash fill(?) which is a magical programming by example thing
You mean that thing that resolutely refuses to be useful whenever I try to get some "magic" from it?
> I’d like to point out that some improvements were made for power users and others for more ordinary users.
More like against power users in many cases, I'd say. (See the first point.)
offset/match have been there since day 1 AFAICR, that is Excel 4.0 or so, as well as index/match.
Or at least they exist just fine in Spread32 which is a nice tiny spreadsheet tool that was first released in 1999 and born with Excel 4.0 compatibility target.
I believe it is more the "culture change" you mention, the "new" function is Xlookup, introduced recently:
When you added all necessary features and don't know what to add you start to optimize and imporove existing features. Really, Excel could work faster and eat less memory.
It is a no-brainer that software must, in fact, have settings and the modern UX principles are heavily in the wrong.
Having too many options is a curse too however, so that doesn't mean that one should add options without thought nor that sane defaults are unimportant (in fact, they are extremely important). Like most good things in life, the solution is not in either extreme but in the golden middle.
It's simple. Most software today is not created to serve the user. It is created to accomplish certain goals (e.g. obtaining money, attention, data, or prestige from the user) and only serves the user as incidental to accomplish those goals.
I think that's probably true in the SaaS world. I'm seeing the same mentality take hold in the open source world with "opinionated" or "curated" software. Tools that have limited options or actively remove options and expect the developer to conform to them. I think it's being driven by this same notion of "options = bad" that we see in UX in general, but maybe they're coincidental, but unrelated phenomena.
I agree with this. Most software doesn't need to be "opinionated" and would be made better with more options and carefully chosen defaults.
I think it's sometimes appropriate to reduce options, mainly in cryptography libraries. There the library should provide all the secure options and none of the wildly insecure options, maybe with some "secure if used correctly" options behind some heavy warnings. Likewise for anything else that might similarly be used in safety-critical situations: it MUST be easy to use, and hard to misuse. That tends to mean having fewer options, and making very careful choices about defaults.
Haven't read the book but per your comment it occurs that assuming the reality of the 'left off 1%', it is possible that these are distinct market segments. Did Norman or anyone else ever try to correlate demographic aspects with product mis-fit? In other words, the disconnect is possibly at the market/product level and the same unsatisfied with defaults 1% may be perfectly happy with another product that is designed for them (thus having few knobs). Not asserting this but wonder if this is indeed the case.
You know the saying about how majority of users of certain very powerful packages only use a tiny fraction of available functions?
Allegedly Microsoft found out that the problem was that the features covered by that fraction were wildly different in case of MS Office. That is, any cut down, simplification, etc. would result in huge amount of disappointed users, because the used featuresets didn't really overlap outside of certain core. At the same time trying to package it into market segments might just mean you end up with too small niches.
The other problem is that each thing your decide should definitely be "this way and no other" is probably shaving off a different 1% of the population.
I maintain that the Ribbon on office is this problem writ large: I'm sure Microsoft did a lot of user studies, and I'm equally sure that by averaging out all those results they managed to prioritise nothing useful to any actual business - hence why the product feels bizarrely unprofessional these days and is now impossible to configure to suit any specific type of writing.
The real trick with Ribbon is that in MS Office it makes it somewhat easier to find functionality (the search interface helps with that) and it tries to expose keyboard shortcuts easier.
AFAIK the research behind the ribbon showed that 1) there was no way to find features easily 2) Main menu was too cluttered and undiscoverable.
Of course if you actually found the features you wanted before that, it was a big negative change.
Paradoxically the ribbon makes harder the one thing it was supposed to make easier. Nothing lines up, so a visual scan of the whole thing is very hard to accomplish.
In the old interface it may have been hard to find things. But once you found them, they were always in the same place. With modern interfaces, everything jumps around and hides itself depending on some obscure context and the window size.
> A crucial part of Ribbon, as implemented by MS Office, is a search interface.
If the search interface was what was missing, why the fuck didn't they just add that to the old menus and toolbars? (Seems to work on many Macintosh applications, doesn't it? And probably some Windows ones too.)
Because it wasn't the only thing. Ribbon specifically on MS Office was informed by a lot of data gathered from users and attempting to make functionality more visible (also, it kinda promotes keyboard shortcuts - hit alt and look at ribbon)
Of course a lot of applications later "embraced" Ribbon without all that preparation, and to be quite honest, I don't hear much complaints about Ribbon in Office - outside of nostalgia it's rare.
Yeah, well, as far as I am concerned, they pretty much failed on the other bits. You not hearing many complaints about it any more is probably because most of us have stopped mentioning it (outside of discussions specifically about it), because nobody gave a shit then either, any more than you do now.
One such example might be accessibility settings. Such settings are likely only used by a small subset of users, but it might be critical for such users.
Many modern video games start by displaying such settings. The defaults probably suit most users just fine, but being able to easily scale UI text is probably very useful for people with poor vision.
I don't think that he necessarily doesn't address settings. I think it fits into the overall ethos pretty well: it should require as little mental energy as possible to figure out what the settings do and why you would use them.
Where things get murky and become a matter of judgement and data is whether you are exposing settings gratuitously and therefore just making things confusing, or whether you are not offering enough settings and therefore not addressing common use cases.
I don't think there is some absolute law of design* that says all users must be supported. If a startup is still struggling to reach profitability, they generally will invest all their efforts into supporting one niche really well, not create universally useful products.
*There are actual laws that say those without disability must be supported, and I think companies should strive to meet those, but that's more of a moral argument
The point or question I was raising was specifically about UX. Design, which includes UX, isn't done in a vacuum. There's many competing interests and environmental considerations that ultimately influence a product. Norman spends a good deal of time reinforcing that idea, I think mostly to drive home the point that reality doesn't match the platonic ideal. That's what I was alluding when I said "I suppose I can see the business justification for that."
Carving out a niche when getting started is probably quite prudent. But, that doesn't mean it's a good user experience. There's a lot of retorts in this comment section about how any amount of settings is tantamount to total design failure. I think that's too reductive and I'm trying to reconcile that research on the topic.
It seems weird to talk about something as "good user experience" or "bad user experience" in a universal sense without a specific use case in mind. Something can be a good experience for one set of users and a poor experience for others.
Settings allow you to customize a software beyond its developer-intended path, while that doesn't take away from the "default" path, it maximizes the total amount of good experience. That's how it's universal.
My objection was to the view that supporting only 99% of users is "bad" in some absolute way. Obviously 100% is better than 99%, but good and bad are relative, and 99% might be good enough when considering the actual needs of the product that's being developed.
In my experience it's the exact opposite. It's almost always easier to leave product decisions to the user and add a new setting. And if you have very few settings, your software needs to "just work," which means quietly handling edge cases you would normally rely on the user to troubleshoot.
>if people don't like the path laid out for them, they're either wrong or they can go use something else
This is a reasonable limitation. If you implement infinite features, you end up with a bloatware, so some features can't be implemented, and users should use something else.
It’s not about features, parent comment is arguing about adjustments. Sure you don’t need 65535 choice of colors for a chair; but you do need the height to be adjustable(ideally within -327.68 to +327.68 mm).
You may be correct that "most people" don't love settings, but I think we underestimate how many power users there are in the wild. I personally prefer software to be customizable and give me a lot of options to configure and get what I want out of it.
There are a lot of people who are willing to engage with your software and use their critical thinking skills in that process. I think we're losing something valuable by dumbing down all software and all interfaces to the lowest common denominator in the pursuit of "no friction" for users. Some friction is totally fine.
I find it weird that people think settings are only for power users.
Good defaults are very important for non-power-users. But if a non-power-user can Google their problem and change a setting to fix it, then that's a lot better than said user being left with no options at all.
By some definition, a person who does anything besides swearing when a piece of software doesn't work as expected is already a power user.
I see this in many of my relatives. Googling the problem or checking the settings menu is something I do when asked to fix a technical problem in a piece of software I have never seen or used before and this more than they did before handing the problem to me.
It doesn’t even have to add friction. Optimize away for the common use case, that’s great and benefits the power user just as much. Just let people make changes if they really feel the need.
I believe that the way forward isn't complex UIs or things like ribbons. Command palettes [1] solve most of the problems of discoverability while also helping power users by giving them quick access through shortcuts or highly configurable settings.
> I personally prefer software to be customizable and give me a lot of options to configure and get what I want out of it.
In my experience doing support, this is a give them an inch and they’ll ask for a mile situation. Power users are the worst when it comes to asking for more features or more settings. I had better luck with very limited settings and saying take it or leave it. Would just tell them straight up “What you want has a 0% chance of happening. Happy to refund your money.” Hardly anybody took me up on it and it greatly reduced ongoing support conversations that went nowhere.
I'm not sure I understand the rest of your comment, but of course the user has a right to disagree with a company's choices. They express their disagreement by not using it.
If somebody hated our product, I'd send a link to our competitors who I was confident they'd hate more.
For example, my kids endlessly change the icons, colours, sound and many other visual and functional behaviour of their phones, the vast majority of which I would consider ‘settings’. But for them it’s highly important and fun
The defaults are fine for me, but changing those settings isn’t a cost to them, it’s just plain fun.
It’s easy to dismiss that as not real work, but I see the same in workplaces. Being able to customise your tools to be that little bit more bearable can sometimes be the difference between having a great day and crappy day at work. A little bit of control can feel very empowering.
This is exactly what I’ve seen with serious enterprise applications. Where users perform some complex task all day in the software. “User Preferences” are first order feature inclusions. They vary across global levels and down to specific feature settings. I’ve seen multiple occasions of customized layout/grid solutions.
One random thing I’ve wondered is if Excel power users end up implementing a ton of preference customizations. Otherwise it seems like a very well equipped “default-only” UX.
This was true with Windows 3.1. When I finally installed it I soon bought theme packs and delighted it making it into an expression of my interests. Accessibility was also much improved over DOS and even GEM and Geoworks.
Moving to OS X was such a disappointment in comparison.
I guess what's going on here, the reason people are divided, is that on software that you dislike (or are forced to use) people generally hate settings and just want the thing to work. On software that people love (like a piece of software that helps you make music or edit video) then people generally enjoy being able to customize it further and further.
> I guess what's going on here, the reason people are divided, is that on software that you dislike (or are forced to use) people generally hate settings and just want the thing to work. On software that people love (like a piece of software that helps you make music or edit video) then people generally enjoy being able to customize it further and further.
I don't think that's quite it. I think the ability to set the software to work the way you want it to can turn a piece of software from one you dislike into one you love. [EDIT:] Or, vice versa, the lack of the ability to do so can turn a piece of software from one you would have loved into one you dislike. [/EDIT]
Nope. Two of my favourite pieces of software have very few settings because they remember what I do instead of forcing me to go and figure out a setting for it.
Could you explain that? Software that tries to interpret what users are doing and then tries to adapt to itself is on a slippery slope. The first steps in that direction, like a history of visited sites, or recently edited files menu are uncontroversial. But when it moves menu entries around to optimize for assumed workflow of the user, that user gets infuriated very fast.
Software that I cannot adapt to my needs is like an interactive tv. Ultimately I have no control over what is happening. Software that I can adapt to my needs puts the personal in Personal Computer.
Simple example: I used to be the maintainer of Dia, a diagramming program. It remembers what colours, line width, dash style etc you've last used, so you don't have to keep setting that. This can drastically reduce the number of steps needed per desired action, and reduces frustration, but it would not be great in a separate generic settings windows.
Thinking of my users (including myself) as goldfish is useful: if you've just done a thing, it's likely you'll do it again.
Good default settings are great but please let me tweak. I don’t like UIs where i can search only for 1-5, 6-20, 21 and more. Why not allow me to search for 10-12? Sometimes I feel a lot of modern software has authoritarian tendencies “we know better than you what you need”.
The structure of the team gets reproduced in the product. Read "The soul of a new machine" for a great example.
There is an unhealthy elitest hierarchy at many companies which manifests itself as interfaces to users on the assumption they're totally incompetent. It's a reproduction of an insular culture.
The worst part is that it's reinforcing. The thing you've probably heard of is the Stanford prison study but there's many similar ones; essentially you set up a context for how you engage with your customer and the customer plays the roles dictated by the context.
So you treat users like idiots and then they start acting like idiots. It really does work that way.
Let me give an intuitive analogy for those unconvinced. We're going to use a gym, library, and bar. The same person would be exercising, studying, and drinking at those institutions, in specifically that order.
We shape the buildings (create the context); thereafter they shape us.
The core problem of UX is the extreme focus of what kind of user they want as opposed to what kind of context they want to facilitate. The latter is how sustainability, growth, and value happen.
It's the difference between say assuming your customers are alcoholics and then building a bar and saying "it is of public benefit, profitable to our company, whatever, if our users studied so let us make a library and they will rise to the occasion".
So long as it is within reason, this is possible. People will do difficult things of value (such as a gym) if you're willing to adequately facilitate it. We don't need to limit ourselves to a fast food internet. See the project known as wikipedia for an example.
Yes yes yes. You've nailed it so well that I can hardly believe it. I've worked first-hand with a number of different teams and this is exactly what happens.
Around the time I started becoming aware of this, I once brought up in a meeting that I thought we should support keyboard shortcuts for users who prefer keyboard interaction. You would have thought I had desecrated a religious symbol.
I did figure out a hack though. The next time we met I pretended like the previous conversation had never happened, and instead brought up that for a11y we really needed keyboard shortcuts :-D They had no choice but to agree because prioritizing a11y is another religious tenet. I love a good win-win/two birds/etc.
The last product I worked on, we had constant problems sometimes trying to reproduce bugs. Accessing a feature through a keyboard shortcut vs. a menu might take you down a completely different code path, and it was critical to know which way the user was using.
Yes I agree, although having gone through that several times in different frameworks, I am now a believer that you can avoid the majority of issues like that by keeping state centralized (like redux pattern) and building components in a functional-reactive way (no state in components). Of course this doesn't help much if you're using Java Swing, but the vast majority of products that I run into this are web-based. The "always re-render" approach of React can help a ton. With that you have two separate event handlers (one for the click, one for the key press) but both of them simply update the "state" variable for whatever it is. The framework then figures out what needs to change and does it.
You 'get it' in a way that most PMs and designers don't. As a senior product exec in a very large public company with software products used by tens of millions of people, I've been continually stunned by the sheer arrogance of supposedly "user-centric" designers and product managers.
So, I just want to be sure that I got what you mean.
If my app (or whatever) just include what I think is good because users are idiots and I know better than them, then, my app will only attract idiotic users (or attract smart ones, but they'll behave like the idiot one)?
Using the parent example, if I'm an idiot user (or one behaving like that) I wouldn't want a slider that allows me to select the range I want, but I would want a specific button labeled 10-12? Or I wouldn't even want one, because the app creators know better than me?
And in the last paragraph, it's about letting users go on a journey from novice to expert using your app if they want? Like using a tooltip on an icon showing how to the same using a keyboard shortcut.
It's not about that hypothesis. It's a great book but it's more about how projects are products of organizational structures. It's a Pulitzer Prize winner. I'm still waiting for a movie to be made about it. An "all the presidents men" of the 80s minicomputer market.
If only I had infinite time, energy and money; the things I'd do...
To reinforce kristopolous' argument: Even smart users will behave like idiot ones, because with software designed for idiot users, that's usually the only way you can behave. This makes it a self-fulfilling prophecy: "But look, everyone uses only the mouse, never any keyboard shortcuts!" Well, duh, since you didn't make any keyboard shortcuts...
I meant silicon valley. Not as a geographic place these days but as a state of mind, specifically harkening to the classic 1995 essay, The Californian Ideology by Barbrook. https://en.m.wikipedia.org/wiki/The_Californian_Ideology
The question is what if you take that and press the play button for 25 years. You get the nth order derivative; a mix of amplification of the tangible and a dampening of the aspirational under a constantly churning framework of the ideological.
Or to put it in less academic and more literary terms, the reality must die and the dream cannot be born and in this interregnum, a great variety of morbid symptoms appear.
We, like all generations are tasked with building our grandparents dreams and our grandchildrens future. That's the kind of orientation I think we need more of to drive how we choose to use our time.
I don’t like UIs where i can search only for 1-5, 6-20, 21 and more.
This, absolutely this! I recently had to use a web app whose date filtering consisted of nothing but "1 day ago; 1 week ago; 1 month ago; older than 6 months" when I was looking for a record that I knew was in March of 2018. It frustrated me enough to make me exclaim out loud an unabbreviated WTF!? A peek at the API calls it was making showed those options hardcoded directly into the "filter" parameter, so I couldn't just inject my own custom date range --- something which I have done before with success.
I wrote a short script to scrape the (paginated, infinite-scrolling style) API and filter the tens of thousands of records myself, and almost half an hour later of waiting for those records to come back, found the one I was looking for. Doing that filtering on the backend DB would've probably been nearly trivial, and all the UI needed would be two date pickers (a long-solved problem), but because of that idiotic design choice, I wasted both their and my resources.
Sometimes I feel a lot of modern software has authoritarian tendencies
>> But the only thing worse than having to tweak a setting to get your functionality is not being able to get your functionality at all.
Or a setting that once set doesn't stay set. If I arrange the settings for something, especially part of a UI, I do not expect those setting to go back to defaults every time an update happens. Somewhere between functionality and not having functionally is only maintaining functionality through constant user effort to rebuild settings.
Like the rental car I had that constantly reset the heated steering wheel every time I got in. I don't want you to be on. I told you I do not want you on.
So stop turning yourself on every time. THGTTG predicted this frustration decades ago (the Nutrimatic drink machine scene).
I once inherited a software product that had an incredibly complicated data import process that non/semi-technical users were supposed to be able to use. The training for the product spent almost half a day on learning this process (before anything else in the software!) and it was often in the top-3 of user support issues.
I set about analyzing the problem over a period of a week or so and documented my findings with some recommendations. It ultimately boiled down to far too many settings, most of which were footguns, and no sane defaults that served most users most of the time.
In the end, I instructed the development team to make a number of changes which were mostly around picking defaults, or having the import process use some heuristics to make a reasonable guess, but letting users override them if the software did something wrong -- we modeled very heavily off of various MS-Office import processes, particularly MS-Access and MS-Excel. We ended up getting what was something like a 40+ step process down to 3 clicks that more or less eliminated the support tail and turned training into a 3-5 minute show and tell.
One of the problems with lots of software IMHO is the lack of sane defaults, the blizzard of hard to grok options and settings, and the multitude of ways of doing nearly-exactly the same thing.
I think this is also an interesting observation for physical objects too.
I wouldn’t say I like to muck with the settings, but I’d consider it a critical design flaw if my desk chair didn’t let me.
Same with my car’s seat, steering wheel, and so on.
It does make one wonder though to what extent automating that customization optimally might be possible. It would be cool if every time a different driver sat in the car the mirrors, seat, wheel, and whatever else automatically adjusted for maximum comfort and safety.
Who defines maximum comfort? My dad and I are roughly the same size, but we have different ideas about how to adjust the driver's seat! Some cars let you save seat positions, that's definitely the happy medium between starting from scratch every time a new driver gets in the car and a very expensive automation procedure. Now, I agree, pie in the sky, that might be a cool feature to have, but one thing to note is that designers have constraints, like time & money! Driver's seat adjustments are easy to make and happen infrequently compared to most other tasks, so, and this is another thing to note it's probably better for all involved that the design resources be spent on things that would get used more often, like the AC/radio controls, info display, etc.
Now, your office chair's only purpose is to be comfortable for you. There might be some argument for automating the ergonomics (if you can fit it in your budget, of course), but then again, is it worth adding all that cost & R&D for a feature that will only be used once? Maybe if you're targeting a premium market, but likely not. A part of design is thinking about these tradeoffs and working within constraints...
I like your metaphor. A desk chair with no ability to customize is too constrained. One with dozens of dials and knobs is far too fiddly, at least for me. There is a happy medium with just the right amount of configuration for most people.
But most of good apps have the Settings split in categories and advanced sections, you are not forced to see or touch them. It is not like in real world where many options would have to mean 100 buttons,switches and levers always existing there in your face.
I agree that it's easier to have more hidden options in software than in hardware, though my recollection from my IT days was that the "Advanced" section in the settings panel seems to attract the kind of people who have no business changing advanced settings. (Personally I like how Firefox hides them under "about:config" with a warning.)
Having said that, hidden/advanced settings still have a nonzero cost.
Sure. there is a cost but iumagine a GNOME dev /designer getting his hands ona video game:
1 remove the difficulty level settings, we keep medium , like only a small percent use the Super hard so fuck the those customers
2 remove brightness sittings, the game is calibrated for the desgner expensive screen
3 remove settings for FOV, bloom,shitty effects, we force teh customer to endure our preferences, if they fill sick fuck them, they can refund
4 remove Controls settings, we see what most people use and we force everyone to use that, if someone does not like it they can use a third party hacking program to customize the cntrols.
5 Sound and Music volumte, remove them, the Speackers and headphones have buttons for this, the OS has buttons for this...
.....
Sure settings cost but removing or not adding them is a "fuck you" to the customer, you can get away with it if you either are GNOME and your product is forced as default , or if you have no competitors that can provide a similar product with better defaults, options and features.
Btw I am talking about real features and not how round your button corner is, at my work we had 1 customer requesting our app be able to process TRL(right to left) input and output, we probably had 10000 users but we implemented this feature for this 1 customer because we realized that we can do it and we could gain more customers if we have this feature. Now you have an extra button/checkbox for the RTL option in the GUI , the problem is not that this feature exist maybe the problem is the designer that is not competent ernough to make this RTL button fit nicely in the GUI.
Removing explicit difficulty settings doesn't mean everyone gets the same experience. A well-designed game tailors the difficulty to the skill of the player either by providing progressively harder achievements/endings/sidequests or by dynamically altering the difficulty based on the demonstrated skill of the player.
> they fill sick fuck them
Completely agree with you that accessibility settings that minimize animation effects, increasing contrast, etc should be supported in every game that needs them. Having said that, GNOME seems about as good as KDE with respect to accessibility settings -- fine but should be better.
> not adding them is a "fuck you" to the customer
Do you really feel this way? Most games I play do not have some of these settings you mention (bloom, FOV, etc) especially on consoles. I have never felt particularly insulted by this. If anything, I find it more frustrating when I open a new game and the first task I have to complete is "look up three pages of cryptically named settings to get it to run acceptably well" because that makes it feel like the developer gave up 75% of the way through tuning the game for different hardware profiles and just said "screw it, we'll make the player figure it out".
> you can get away with it if you either are GNOME and your product is forced as default
I am skeptical that GNOME is popular solely because someone is "forcing" Linux users to use it. Most GNOME users I know have tried at least a few other alternatives before settling on GNOME as the least bad option. (Especially once they discover that GNOME's equivalent to "Advanced" settings are called "Tweaks" and "Extensions" which is odd at first but seems to work fine in practice.)
> we implemented this feature for this 1 customer
I agree you did the right thing, internationalization is always important, and you're right that the value is not strictly based on the number of people who would use a setting, but also on the necessity to the few people who need it.
The point is not that software should have no settings. That's a strawman, most software needs settings and most software (including GNOME) has settings. Supporting someone's language, accessibility needs, unique hardware, personal preferences, etc is valuable. The point is that settings have a cost for all involved. Products that chronically underestimate this cost typically have a tough time competing with products that are more thoughtful about which settings they support.
>Removing explicit difficulty settings doesn't mean everyone gets the same experience. A well-designed game tailors the difficulty to the skill of the player either by providing progressively harder achievements/endings/sidequests or by dynamically altering the difficulty based on the demonstrated skill of the player.
Dynamically altering with params decided by a some dude, is it really so hard to understand that people are not the same, look at modern games they even give you more options, extremely granular(damage multipliers, crafting multipliers, XP multipliers, ...) tons , we don't need some dev to hard code some numbers in a .cpp file when it can be coded in an .ini/.xml and exposed to the user.
>Completely agree with you that accessibility settings that minimize animation effects, increasing contrast, etc should be supported in every game that needs them. Having said that, GNOME seems about as good as KDE with respect to accessibility settings -- fine but should be better.
GNOME has no choice to support accessibility, I think RH is forced to do it to sell their OS to gov agencies, this why it makes no sense that you allow UI changes only if you label them accessibility, but if a healthy person wants to change the colors or fonts the designer is objecting. I did not moved to Wayland yet but for my case Global Keybord Shortcuts are an acceptability thing, I need to trigger my own scripts (for TTS) with keyboard shortcuts and some time ago this was not supported by Wayland or you needed to do hacks.
>Do you really feel this way? Most games I play do not have some of these settings you mention (bloom, FOV, etc) especially on consoles. I have never felt particularly insulted by this. If anything, I find it more frustrating when I open a new game and the first task I have to complete is "look up three pages of cryptically named settings to get it to run acceptably well" because that makes it feel like the developer gave up 75% of the way through tuning the game for different hardware profiles and just said "screw it, we'll make the player figure it out".
I am not referring to performance tuning, I refer to shit effects that can cause people headache , like camera shake, bloom, weird god rays or flares effects, small FOV or too large FOX, head bobbing.
And 100% I appreciate when a game let's me decide what I should turn off to make the game work smoother, I can give p on grass and other foliage, put shadows on medium or low but I want to keep textures on high. I don't lke whne I don't have a choice. Games like Fallout/Skyurim have a .ini with more tweaks that we players use to turn off reflection, configure grass distance, very good to get the games run on Linux decently and fix weird glitches.
>I am skeptical that GNOME is popular solely because someone is "forcing" Linux users to use it. Most GNOME users I know have tried at least a few other alternatives before settling on GNOME as the least bad option. (Especially once they discover that GNOME's equivalent to "Advanced" settings are called "Tweaks" and "Extensions" which is odd at first but seems to work fine in practice.)
We will never have un-biased data for GNOME but there are studies that show that the default matters a lot. I don't read Linux related articles or podcast anymore so I don't know what is happening, just heard a small rumor that GNOME did something stupid again and it's split it's remaining users again into 2 factions.
So maybe we can agree:
1 settins/features are not free
2 a dev/designer forcing his personal subjective opinion as default and at the same time blocking alternatives is very bad
3 using the majority opinion and forcing it on the minority is also bad, the argument that only 5% use this so let's remove it is stupid, and in fact when features are removed the developers are never transparent with the numbers
4 features for power users need to exist, maybe GNOME can't have a file manager,browser or terminal with Tabs because is too complex but it is stupid to argue that this features are bad in general and this power users are "using it wrong". Better is honesty, "We don't have a file picker because RH pays developers to work on other tickets, and the volunteer want to work on something more sexy, it is a cool feature that we would like to have but we are unable to add it" (really hate the you use the file picker wrong argument)
This does not track with anyone I have met in real life.
People have no problem with settings as long as the settings are reasonably easy to understand and actually help solve the problems they have.
In fact, Apple setup a store that did nothing but sold settings…the iPhone ringtone setting.
Other countries have had mobile companies selling more settings. Wallpapers, hello tunes (messages that play when you call someone instead of a ringtone), etc.
Settings are not inherently bad. Unnecessary settings and bad defaults are bad.
Having good defaults are a benefit and if done well most people don't need to fiddle with settings. For those who are not satisfied with the defaults you have chosen, having settings to customize things can defuse what would otherwise turn into frustration. Even if your defaults are 90% right for 90% of the people, they are likely to each have a different 10% that they are dissatisfied with.
I'm not sure that's true. I usually am far more frustrated when something in an OS isn't customizable. One reason I prefer Linux and Windows over macOS is because macOS tends to be much more rigid in what I can customize.
Yes, I think it really depends on what the software does and what I'm using it for (my willingness to invest time).
If it's something I use every day for years on end to make a living, then I probably want to be able to tweak and customize it (and I won't mind doing it). Just don't make me keep doing it because your evergreen software keeps updating and changing how things work.
If it's something I "barely" use, then I have absolutely no interest in customizing it. It should just work.
For example, if all I want to do is securely share a file with someone, then don't make me jump through hoops to use it. If however I was looking for software that let me share organized groups of files, should sort in a specific way, would expire after a certain amount of time, and to track engagement with these files (downloads / views), then are probably a few settings I will want to tweak.
What I think often happens is software will evolve / pivot to do more (maybe sometimes less?) then it was originally designed to do. Unfortunately that evolution some times lacks a different design perspective. You might have been religious about clean and simple in the original product, but now it's a bit more nuanced, and you'll need to be more flexible. I don't think there's an easy solution. We just need to recognize that as features are added, design still needs to be part of that process.
Imagine there were no mouse/controller sensitivity settings for example. These and many other settings can have huge impact on how usable something is.
There is nothing wrong with configurable parameters.
What users hate are fighting with settings.
In my experience this involves two things: more technical people know what they want to configure but don't know "where the fuck in the settings it is" or less technical people who know what they want to do but do not know that it can be configured/where to do so.
That’s the thing. Not everyone wants the same thing. Provide useful settings, but try to pick the defaults such that most people won’t have to change settings.
People love when software does what they need, and some of them will be willing to fiddle with settings if they have to.
Settings can be well designed or poorly designed though. In a way, settings are really part of the design and should be thought of as such. If the settings are obvious to find and obvious in utility, it's not a matter of willingness to fiddle, it's just part of using the software.
Good default settings and good auto-tuning functions are welcome.
The cars are delivered with handbrakes on, wrapped in with wrapping paper/red ribbon. Some people do not realize they need to release the handbrakes and remove the wrapping paper. They are driving for years with default settings, wondering why the mileage is bad and it smells like burned brake pads.
I think it is wrong to optimize for such users since those are more likely to swallow anything anyway. But you also need to capture the more versed crowd, which will also be required to support the casual users.
Have as much settings as you want, sensible defaults are important though.
Settings are like lines of comments or the weight of an aeroplane. Less is better but sometimes it can’t be avoided. I just hate having to configure things though because I always lose my configuration when I change device or have to factory reset so I’d rather change my expectations to match the defaults than to configure something.
Nobody forces you to change the defaults, if your IDE has a color scheme you don't like you can continue using it, change your own preferences then using a menu and a popup to select a different color scheme. The thing is some users want to change things and some developers are even capable to implement things without hard coding various constants. Most issues appears when designers (like GNOME ones) want to impose a brand or vision.
Good apps will store configuration in a folder/file and they offer import/export functionality. As a person with eye sight problems I would be unable to do my job if a shit designer could force is shitty font sizes and colors on my apps(for some reason slim fonts with light gray on white background is sexy in recent years)
TL:DR nobody forces you to open the settings panel, keep the defaults and don't try to demand or defend removing stuff you personally don't need, you don't understand how other work(use the applications)
>Most issues appears when designers (like GNOME ones) want to impose a brand or vision.
Gnome is by far my favorite DE on linux because its the only one I feel that actually cares about the best out of box experience. I can install any linux distro and pick gnome and it all just works. And it just works really well. While everything else seems to take a significant amount of tweaking to create a nice experience. So I think Gnome is the perfect example of why stripping back configuration works. I like the choice available to pick my DE and OS, but after that I want it to just work.
Another issue I have noticed is the more settings a piece of software has, the less stable and consistent it is. You get issues which only occur when particular settings are set because the devs just haven't used that setting in so long they didn't see the issue. I had some where just setting up volume change keys required configuring keyboard shortcuts to fire bash commands to adjust volume..
I prefer to use software where the designers and developers are bold and put forward their vision on what the right way is. If they are right, I use the software, if they are wrong, I find an alternative that is right. I think LibreOffice is the biggest example of devs held hostage by the community unable to do anything. They have like 4 different UIs available which you can pick from in the settings. Their modern redesign isn't even the default setting. So I prefer something like Google Docs where they have one UI and feel empowered to change it to fit the best possible design.
>I prefer to use software where the designers and developers are bold and put forward their vision on what the right way is
This is stupid, why do games let you configure the controls? Is it because the developers are not bold to impose the right way and force the people into it? Are the people changing the controls "using it wrong"?
I assume you mean themes, there is no right way there, there are people that need larger contrast, larger fonts, different colors so give them the option. So if you are forced by accessibility reasons to offer diffent sizes and colors(even iPhones offer this) then IMO you are a bad developer/designer to hardcode your theme and your are an ashole if you do extra work to prevent teeming by the community.
If you mean missing functionality as a feature , most of the time is because other reasons, like GNOME missing file picker thumbnails and their fake defense of it like "you are using it wrong, just DND the files because this is the right way"
In fact, no proprietary OS offers different colors other than some accent colors.
Which Gnome developers have already said they will bring in future releases.
Heck, they aren’t even against theming. They are taking a wait and see approach to see if they can include more theme customizations without causing remarkably more work for app developers.
In fact, they are absolutely fine with developers who want to provide additional themes doing so. To the point that Gnome developers have themselves added additional theming options to default apps that will be released in Gnome42.
I remember back with XP everyone was installing additional themes and gadgets to completely customise the look of their system. And it worked fine. Why can't it work now?
A computer is part of the room. It's part of the furniture. It's part of the looks. I should be able to decorate the digital desktop, as much as I am able to decorate the surrounding desk and room.
> I remember back with XP everyone was installing additional themes and gadgets to completely customise the look of their system.
That sounds a bit weird: Up to and including Windows 7, you could pretty completely customise the look of your system just using the built-in control panel.
I don't mean you chose colors and corner radius because you want to make your buttons look like candy. I mean features like text sizes and high contrast , go check your iPhone Accessibility section (but only if too many settings won't affect negatively, there are probably many options and labels to read).
My point is that hard-coding fonts,sizes and colors in your app is against accessibility, some fonts are harder to read then others for some people, small sizes is obvious the issue, some people need higher contrast then gray on white to read comfortably. If you are a competent dev or designer you need to understand that your app needs to work if the user wants a different font and different colors, Apple has guidelines. What would be nice is to think about the app as a tool that lets the user do a job and not like a work of art that a desgner needs to add it to a CV,
> In fact, no proprietary OS offers different colors other than some accent colors.
Yeah, and that sucks. Why the fuck don't they? Until fairly recently, "the" proprietary OS -- Windows -- did offer different colours for everything, not just some accent colours. Taking that away (with the introduction of Windows 8) was a humongous dick move.
What makes you think that (previously most, and now all) proprietary OS vendors perpetrating this humongous dick move is somehow an argument in its favour?
> Gnome is by far my favorite DE on linux because its the only one I feel that actually cares about the best out of box experience.
And GNOME is by far my least DE for reasons including the way they only care about out of the box experience, which is to say they firmly believe in no customization, and their defaults disagree with me.
In the bazaar that is the Linux ecosystem, they are bringing another idea to the table. The idea that developers (and therefore users) would benefit from having a reliable and consistent default theme and interface.
Gnome is absolutely not opposed to customization and have already confirmed they will add theme colors, etc. Beyond that they are taking a wait and see approach to see additional customizations they can add based on the actual usage out there.
What Gnome is trying to do is give developers who are not as interested in supporting a variety of UI configurations, a base setting that they can target.
Those developers who do want to provide a more extensive theming system, are absolutely able to do so. In fact, many of the new GTK4 default Gnome 42 apps themselves include additional theming beyond what Gnome 42 and libadwaita support by default.
Didn't GNOME removed the System Tray ? If they offered a choice they could force their GNOME apps not to use the System Tray but support third party apps like say Slack,Skype ,Thunderbird. They decided System Tray is not cool anymore, same for Server Side decorations, they are against supporting legacy GTK applications or cross platform ones - they are not presenting their vision they are forcing it.
But I know fans will excuse with "GNOME team is too busy with removing features to support the System Tray API or keep an SSD compatibility mode but there are some hacky extension or patches on gitHub that worked but probably will stop when you update and let you stuck on a TTY screen"
All too often, especially in the open source world, settings are used as a way to not figure out how to make a good default. When the default is crap, I am forced to go to the settings and spend way too much time finding my way around a gazillion possibilities.
>All too often, especially in the open source world, settings are used as a way to not figure out how to make a good default. When the default is crap, I am forced to go to the settings and spend way too much time finding my way around a gazillion possibilities.
IS there any evidence for this? Like what should be the default font or font size? Is there evidence that there is such a good default?
The problem is you want that the good defaults match your preferences without proof that those defaults are good, Sure there are exceptions where evil or big ego people will force their preference over what the users want.
Do you play video games? , if yes don't you think that sometimes you need to adjust the sound volume, font sizes, difficulty to match you?
Do you listen to radio ? Isn't great you can adjust the volume or change the station?
Do you use and IDE ? isn't great that you can change the color scheme, the code formatting scheme, the keyboard shortcuts, that you can install plugins to add more features to help you with your work?
True story, I installed for my son an emulator and installed a game he wanted to play, after a few hours I ask about the game and he tells me that the controller buttons were weird/reversed but he got used to that. I then went in the menus and found the setting where he could have change those buttons so he do not have to suffer and rewire his muscle memory, the conclusion is we need to teach people to not be afraid to think "this software should work differently, let me check for a setting instead of torturing myself".
P.S was not the emulator program fault, it could not have a default that worked for all game and controller combinations.
I'm not advocating for _no_ settings. I'm saying a limited selection of settings are useful, putting just about everything behind a setting like many FOSS programs do is bad. Accessibility is the biggest one where people have certain strict needs which go against the usual. Font size is an example of this accessibility requirement.
I don't like settings for UI, there usually is one correct or best UI. I don't want to see settings to configure the drop shadow amount. I use an iPhone because its generally just exactly what I want. And in the few cases it isn't there is a setting for it or its not actually important and I deal with it. Moving from android I was upset there wasn't a setting to have the keyboard use the vibration motor rather than a click sound but after a week I didn't care at all and I'm glad there aren't 2 billion settings to make iOS work like Android.
I leave my IDE theme on the default, my wallpaper on the default, ringtone on the default. None of it actually matters for getting work done and living life.
For sure you installed some plugin, enabled/disabled some feature in your IDE.
My terminal apps has tabs and profiles, I have my important server SSH open in a tab with a red color scheme to remind me this is not my local and I should pay attention. Sure more then 50$ of the users don't need this but why should the terminal developers not put this important feature for power users in ? I mean regular users should not open the advanced settings, or if by mistake a GNOME users will open it , will have a short segfault/reboot and then proceed to uninstall the app and installed some crippled software or buy an iPad. Do we really need to hide power user settings under some "Cheat code" so this type of users don't see by accident the options screen? do we need to protect their limited ....?
When I was an engineer on Microsoft Office, users would often request features that the product already had. It was great that their problem was quickly fixed (just point them to the right setting), but it shows the lack of discoverability that happens when the list of settings gets long and you have to dig for them. If you can do the right thing automatically and avoid having a setting, that is an improvement.
My other observation was that everybody said Office had too many features and then asked for two more.
One of my favorite things about OSX are the standardized menus... which includes a search field in the "Help" menu. Searching for things there will show you where the menu is - it's a wonderful tool for both discovery and future optimization. And it's in every application.
I only wish it applied to more places. E.g. it searches help files, but they're basically always worthless, and it doesn't search non-menu things (settings, in-window toolbars, etc). Intellij has a nice cmd-shift-A which does most of this ("search everywhere" iirc), and I use it absolutely endlessly.
This works in Windows too, but with one major flaw. If your Windows are localized (e.g. Czech), you will have to enter the correct name of the setting or service in Czech and entering its English name won't help you.
Which is a problem, because the vast majority of StackOverflow-like Q&As are in English and mention the necessary setting in English, of course.
And you cannot rely on your translational abilities, because many of the translations in Windows are stilted.
What? Windows has nothing in the slightest bit like macOS’s searchable menus. I suspect you may be describing the Settings app which lets you search by name, synonyms or description, and takes you to the appropriate place, but that’s a far cry from a searchable menus across all apps, where the searching also shows you the path to that menu item.
It's really nice: https://imgur.com/a/ZKSSiQc you can click the help entry and it'll act like the real menu too.
It's part of the standard, default menus on almost literally everything. There are ways to hide it if you're determined to be an asshole app (Cisco AnyConnect does this for instance, though there are so few menu items that it's not too horrible), but it's exceedingly rare because you have to explicitly remove it to have that happen. Far, far below 1%, it's mostly just awful corpware.
A Dutch Windows 10 install won't find "control panel", but it will find "configuratiescherm". It won't find "credential manager", it will find "referentiebeheer". At least it was like this when I used windows ~2 years ago. Definitely a pain point.
Shift+Shift on Jetbrains IDEs. The best search feature by far. It fuzzy searches text, symbols, settings, actions, it also works with synonyms. No need to fiddle through settings.
This isn't really the point of the discussion, but I've always found MS Office features particularly hard to discover because even if you Google for it, half the results are for a different version that has a totally different UI from your version.
The other side of this is that you were getting requests for those settings, users wanted to be able to set them. Agreed that discoverability was a problem, but behind the discoverability, people wanted the ability to define custom behaviors or change default behaviors. I think you sum it up perfectly with:
> If you can do the right thing automatically
I think a lot of software will shoot for doing the right thing automatically when they don't actually know what the right thing is. Or they'll remove the options because they think that the users don't want settings at all. But users do often want all of the behaviors (even the contradictory behaviors) that settings enable -- they just also want those settings to be discoverable and intuitive, and ideally they don't want to think about what they're set to most of the time.
As an analogy, as a user I like automatic high beams in my car if they work well. And having an automatic mode that's turned on by default might mean that I don't need to spend as much time messing with my high-beam brightness, and that's great. In a world where they worked perfectly, I might never even need to learn how to adjust the beam brightness myself. But I still want the behavior of different beam brightness in different contexts.
There's a trap designers fall into sometimes where they say, "settings are too hard for users, therefore the headlights should only have one brightness." If a bunch of users are asking you about something, that means they're engaged with and care about the functionality they're asking about. It might of course indicate that different defaults should be set, or that UI should be reorganized. And if you can do the right thing automatically, then you might be able to get rid of a lot of those support calls by doing that instead. But make sure you actually can first, because users are signaling with those support calls that they do care about that feature/behavior.
This isn't limited to software. Many don't know that cars indicate where this the fuel tank is. Or that seatbelts lock if you pull them all the way out.
Really, the list of hidden features on products is such that nobody has solved discovery. Affordances that work are ones that mimic already learned behaviors. But shared learning is not as universal as folks think it is.
Interactive systems that let you ask "what will this do?" Or "why did that happen?" Are very good. But even that is hard to work with sometimes. Consider how few folks use the apropos utility.
> Or that seatbelts lock if you pull them all the way out.
Haha, I'd think only people who were never in a car as a child wouldn't know that. An adult might not mess with them enough to suss out that behavior, but kids loooove playing with seat belts.
Attaching baby car seats, you're supposed to reel it out all the way which triggers the lock (or rather one-way reel) and then reel it in with the guarantee that it won't reel out.
This is no longer true, at least since 2003 in the US. Car seats are now attached using the far-more-secure three-point LATCH system. I never once “used this feature” when installing a car seat for my now-twelve-year-old.
The LATCH system has a maximum combined weight of the carseat plus child of 65 pounds. As a result, the threshold varies with the weight of your carseat and weight of your child, but a typical 4- or 5-year old probably should be using the belt.
Personally, I don't think that was a good threshold to set. I agree that the LATCH anchors are better. In 2003, I suppose people were mostly using carseats for infants and toddlers in little 10-pound styrofoam shells, now we know kids are safer in carseats until they're significantly older and heavier, and they're in 25-pound adjustable, heavily bolstered bucket seat style carseats.
For what it's worth, whilst my car and carseat have the LATCH system, this particular carseat requires use of the seat belt instead of the LATCH lower anchors for kids over 30 pounds.
yeah, I had no idea this was the purpose behind the feature until this thread - my kids are young enough that our cars have always had LATCH since they were born.
> but it shows the lack of discoverability that happens when the list of settings gets long and you have to dig for them.
how many users is this in proportion of the silent majority which has no trouble finding what they want in the menus ? you can't base a judgment on complaints alone
Nor can you assume that the users who are are NOT complaining are happy. They may just be enduring the crappiness until they can jump to something that's better.
"Discoverability" is perhaps not exactly the right word here.
Just because something is "there" (SOMEWHERE) doesn't mean it's discoverable. The users might have completely different vocabulary to describe features that are are present but which have an unexpected name. Or they might have a workflow in mind that doesn't give a name to what they need, but which is nonetheless there.
I think this is hard problem.
With any "complex-enough" tools, one just needs guidance or straight-up training. Fusion-360 comes to mind. It's a very popular and rather nice CAD tool that has enormous, wide-ranging capabilities. Autodesk has a never-ending stream of training videos and courses dedicating to showing users how to do things with it. Without these, its just too difficult for people to "discover" how to use the thing.
Agreed, which is why user studies are (or should still be) a thing. You can't just add telemetry and hope A/B testing will surface the real struggles people have with your products. Likewise, you can't remove the 1% case of "restore backup after critical failure" feature because it's used rarely. It'd be like removing seatbelts from cars or fire extinguishers from kitchens.
I think it's ok that people don't know. Doing better at discovery is obviously better but if there is a manual/help function that explains all the features... good enough.
Some people want to take the effort to become proficient with their tools, others are doomed to wish they had features that are right in front of them.
But being less powerful, efficient, and adaptable to keep the design clean and simple and make everything discoverable should be an anti-pattern for serious apps and tools.
My biggest problem with manual/help is when i don't know how to search for what i need. How is it called in the manual? You might even arrive at a page that explains it, but you may not recognize it. Often manual pages simple explain how to do something, without explaining why and when it is relevant.
> but it shows the lack of discoverability that happens when the list of settings gets long and you have to dig for them.
I wonder to what extent command palettes are the solution. At least for me, they are the pinnacle of discoverability. Throw the list of all settings and actions into an easily discoverable command palette and let the user search for them by filtering the list. Make it fuzzy enough to account for different formulations of the problem. VSCode does it (mostly) right.
>but it shows the lack of discoverability that happens when the list of settings gets long and you have to dig for them. I
A hard to find setting is better than not having the feature to begin with. The main prblen with "modern" UIs is that they are strait up removing feature and acting like its a good thing.
I know it's partially off-topic... but Instagram removing the ability to view content without and account and pretending they did it for the benefit of the users is pure BS and it gets even worse when you consider how agressive they are at requesting your phone number.
> the lack of discoverability that happens when the list of settings gets long and you have to dig for them
Any modern application that has more than 20 settings should have a good search function in its settings menu. That way you can have as many configurable options as you like without them being impossible to find. The defaults should ofc be the most common (or best) ones, but some users really do value customizability and respecting the users is (almost) always a good idea.
They are all kitchen sink apps these days. I want purpose built apps not multi apps. Teams e.g. does not need excel integration. Instead of the engineers moving on to a new app to develop they cram more features into the existing one, until it's a multi app zombocom that can do anything.
Is there any problem whatsoever about users regularly requesting features that the product already has? That doesn't seem distinct from customer support helping you understand how to use the product, which also doesn't seem like a problem. Of course, you could use data about customer service conversations to inform design decisions intended to make certain features more or less prominent in the UI.
Not wild at all if those extra features get in the way and make it harder to do the subset of things you want to do. Those extra features also occupy the developers' attention, leaving less time for them to focus on the things you care about.
It's almost axiomatic that "Users don't read instructions," and a corrolary is that they don't explore settings pages or read the captions and tooltips that may be there.
If the software doesn't do something they want, most users will either use it as-is but be somewhat annoyed, or develop a (possibly manual) workaround. Most will not explore settings or read instructions, so spending a lot of time on "discoverability" is probably time better spent elsewhere.
That is is even a question shows how broken this entire field is, and is everything I hate about modern software development.
It really should not be the goal of "design" to try to create "one experience fits all," because when you do that you create the lowest common denominator, the dumbest experience possible.
If you care at all about allowing grownups to do grownup things with their software; if you care that people should be allowed to push themselves to their own technical and mental limits in order to get things done in a good way for them at all, then yes, you need to allow for things like "settings."
One thing that always frustrates me is that most "redesigns" end up removing useful settings, or hiding them. Hiding complexity doesn't make software less complex to use, it just makes it harder to find what you're looking for.
Sure but think about if a particular setting is used by 0.1% of the user base but takes up 5% of the real estate and confuses the 99.9% of users that have no idea what it is and no intention of ever using it.
Here's what you said, minus the arbitrary numbers:
> Sure but think about if a particular setting is used by a minority of the user base but takes up some of the real estate and confuses the majority of users that have no idea what it is and no intention of ever using it.
Now that we've removed the arbitrary numbers... ;-)
If the way setting is presented is confusing, then that is the problem that needs to be fixed. Remove the confusion, maybe make it less prominent in the UI, but taking away the setting doesn't actually solve the problem, it just breaks the product for the users who need it.
No, the numbers do matter, your modification doesn't.
> Sure but think about if a particular setting is used by a 49.9% of the user base but takes up 0.01% of the real estate and confuses 50.1% of users that have no idea what it is and no intention of ever using it.
> No, the numbers do matter, your modification doesn't.
No they don't and yes it does.
The solution to your new contrived-numbers problem is the same as the GP's to the cleaned-up numberless one: Fix the actual problem in stead of focusing on meaningless made-up numbers.
In addition to the other posts, you also don't know it's really 0.1%. Users may have disabled telemetry - and often, those are specifically the power users that are making the most use of customisation.
> but takes up 5% of the real estate
How would you even manage to do that? Menus are a thing. A setting might as well be hidden in a dialog somewhere if it's reasonably clear how do get to it (e.g. through a well thought-out menu or dialog structure).
Not everything has to be explained through random popup messages that show up at the worst possible time.
But that 0.1% may actually need that setting for the product to work for them. By all means hide the settings, but don't remove them entirely.
A lot of evidence seems to support advanced users having a proclivity toward tweaking, so something like about:config in the browser seems to work fine (as an example).
Seems to me we're regressing to the view they had before this story: "If I just had more data, I could find out the real seat dimensions that will fit everyone! Then I can finally do away with all those pesky knobs and levers!"
Imagine if you couldn't change your ringtone or mute notifications or switch your phone to vibrate. That's what the anti-settings people want to force on you, even if they won't come out and admit it.
It's a battle of optimization to cater to the largest audience, so your market share is larger, so economies of scale work better and they earn higher profit - and arguably at lower design cost as well.
Arguably until users are willing to fund good R&D - and there aren't other unreasonable pressures on the production, and that design isn't perverted by designing to optimize for ad revenues and to capture engagement of a person to unhealthy levels, then it's going to continue to be the status quo.
And to pull the camera back; all those big money words you just used are in no way necessary for people to have a good experience, because software can be free and open.
Obviously, we are well past the naive idea of "just making everything FOSS and all will be perfect," but hey, if I'm not the one making money, then from my user point of view, I will be cheering and helping on the "less money" or perhaps even "no money" projects that are threatening to eat your business model.
Search options for settings. When done correctly, it helps a lot.
For example, in IntelliJ (and other jetbrains products) you can open settings and search for almost anything. It will search in headers, options, values... And you can quickly find what you need, from the hundreds or more settings available.
On the other hand, on Android you can also search, but not only takes very long to actually search, it also duplicates entries and often never finds what you want.
But I guess the main issue is that the ability to search settings requires special base structure that you need to develop from the beginning, but when you start programming the number of options is small and you don't think about adding search until it's late.
VS Code is another program that I think does search in settings very well. I can't think of a program that isn't an IDE that has taken this approach, though.
> I can't think of a program that isn't an IDE that has taken this approach, though.
There aren't many, but on the other side... IDE developers are dog-fooding their product. They want customizability, they know other developers will want that customizability, and they get their wishes granted.
The JAWS screen reader for Windows has had a searchable settings UI for several years. I regret that I and possibly my coworkers, working on a competing product (before I went to Microsoft), used to privately mock that search feature, taking it as evidence that JAWS had gone overboard with settings.
I think Emacs has the same kind of user base and accomplishes the same tasks as IntelliJ or VS Code, so let's call it an IDE for the purposes of this discussion.
I guess the issue is that one of the bigger reasons for not having all these settings is that it makes it more complicated for not only the users but the developers (eg more conditions in which a bug can appear, you know what I mean). Having to add search on top of that means you not only need to maintain all the features, but another feature (search) to manage the features.
Not saying its a bad idea, I just don't think it'd fly with some of the anti-settings camp
I am surprised by the settings skepticism in this thread. By insisting that preferences/settings are indeed a design failure, many here are missing out on relatively easy user delight wins. I think there is an illusory adversarial relationship between good defaults and having user-configurable settings.
Having the ability to configure settings does not need to, and indeed should not, supersede having good defaults. Windows Explorer has the ability to hide file extensions, but that should not be the default.
Instead of removing settings, some design tactics I've found useful in building software:
1. Provide multiple default settings profiles. E.g., beginner, advanced, and expert. The problem with a single, rigid configuration is that you can't satisfy all user types. On the other hand, acknowledging that not every user wants to fiddle with settings, providing a quick way to more closely match their needs via multiple default profiles is a win.
2. Always provide settings import and export, or some form of settings synchronization between instances. One of the main reasons users don't use settings is that they are exhausted by having to re-apply all of their preferences every time they install your app. I've installed Firefox about a hundred times across many computers. If I had to manually adjust it to my preferences, re-install and configure add-ons, and so on, I'd just give up and use more of the defaults. The idea of having to re-train NoScript alone is unbearable.
3. Provide better descriptions of what settings do and why they are offered. This can be inline help within the settings dialog or "show me" buttons, or whatever. A good example you're probably familiar with are video game options panels that say things like, "Enabling this may help increase framerate in the following circumstances: ..." Firefox is similarly pretty good about this. But many apps don't give the user much explanation for settings, adopting a more "if you know, you know" attitude. Don't assume that because your user is a "layperson" that they can't understand what your app's settings do if you take the time to explain them.
>The problem with a single, rigid configuration is that you can't satisfy all user types.
From a user point of view, the problem is that satisfying beginners will get more click/impression/downloads/etc.. If the company is managed by accountants, you end up with products that get shittier every version.
We're finding that having settings has helped us siphon customers from our competition. Love sitting in on sales demos and hearing the prospect go, "You let me control that? Thank you!" or "I can chose my colors? I love it!" Delighting customers and users... that's where you want to be.
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.
> 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.
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.
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.
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.
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
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?
> First of all, remind yourself that users love settings.
> Despite initially being born out of the absence of airplane WiFi, I actually enjoy discovering new settings on my iPhone that will make my life easier or improve my productivity.
> Just look at your own user behaviour:
What do you do when you set up your new computer?
> You change your background image.
> You adjust your mouse speed.
> You set a default browser.
> You make all of those rearrangements not because the operating system is badly designed. You make them to create a more comfortable environment. To feel more at home.
Because he is a designer, or a somewhat more technical person, he may love fiddling with settings, but the vast majority of people do not. They do not change their mouse speed, their background image, their default browser. That's why a meme exists of people thinking the internet is the blue E icon on their desktop.
As a corollary, that is why defaults are so powerful, as evidenced in the book Nudge [0]. If you have sensible defaults, you can make users do actions that you want them to do, such as putting out fresh fruit in a cafeteria closer to the reach of the user than junk food which might be farther away, which increased the number of people eating fruit.
> Because he is a designer, or a somewhat more technical person, he may love fiddling with settings, but the vast majority of people do not. They do not change their mouse speed, their background image, their default browser. That's why a meme exists of people thinking the internet is the blue E icon on their desktop.
Just because most users don't use a thing doesn't mean it's not a useful thing to have. Even if almost never called the emergency services doesn't mean I don't want or need the ability to do so. Further, being able to adjust the cursor speed is great for improving accessibility.
> If you have sensible defaults, you can make users do actions that you want them to do
What about what the users want to do? What entitles you to decide what is good for other people? That's just creepy as fuck.
> What about what the users want to do? What entitles you to decide what is good for other people? That's just creepy as fuck.
It depends. "I want the user to find the useful capabilities of my software" isn't creepy at all. That's just good design. "I want the user to do things that are against their interests but make more money for me" is the core characteristic of a dark pattern.
> Just because most users don't use a thing doesn't mean it's not a useful thing to have. Even if almost never called the emergency services doesn't mean I don't want or need the ability to do so. Further, being able to adjust the cursor speed is great for improving accessibility.
I never said to remove settings entirely, merely to choose sensible defaults.
> What about what the users want to do? What entitles you to decide what is good for other people? That's just creepy as fuck.
This is a strange comment. It's literally the job of the designer to make sure users can do what they need to do in the application, I'm not sure how that's "creepy as fuck." But also, there's a notion of libertarian paternalism [0], ie give people choices but also have defaults that are defaulted to the better, healthier, more beneficial option so to speak, because the designer would know that most people may not change their settings. You wouldn't want your pointer speed to be excessively fast, that would just be annoying, so set the default at a reasonable level and let people change it.
> Sunstein and Thaler state that "the libertarian aspect of our strategies lies in the straightforward insistence that, in general, people should be free to do what they like-and to opt out of undesirable arrangements if they want to do so".[18] The paternalistic portion of the term "lies in the claim that it is legitimate for choice architects to try to influence people's behavior in order to make their lives longer, healthier, and better".
Design is manipulating people into doing what you want, I don't see how you can get away from that. A designer must make choices on what they want to user to see and do, that's what a default is. Perhaps you're thinking of stuff like r/assholedesign?
> Design is manipulating people into doing what you want
I completely disagree. What I want is irrelevant. What matters is what I think the user wants. I present them with information and choices, they tell me what to do. There is never a step where I hold any opinion over what the user should do. Only steps where I help them understand the consequences of their available actions.
> There is never a step where I hold any opinion over what the user should do.
What do you mean "never"? If you've put one button on top of the other, you've just created a hierachy. You are telling the user that button is more important than the lower button.
Have you ever hidden elements until it can be revealed by click on "more" button? That's you telling the user it isn't as important as unhidden elements.
Have you made defaults? That's you nudging the user into what _you_ think is the sensible choice.
In my opinion, design is fundamentally about having an opinion. A refined opinion that matches a lot of users is what is commonly deemed to be "good design", but obviously not a design never match all users.
> What I want is irrelevant. What matters is what I think the user wants.
What you think the user want is still what you want. But I think I get what you mean here, you don't like the anti-patterns and nudges that drive users to do what is "worse" for them. I agree with you there but I would argue that they are all still "design". Design is about manipulating people and whether you do it for good or bad is a moral choice.
> If you've put one button on top of the other, you've just created a hierachy. You are telling the user that button is more important than the lower button.
> Have you ever hidden elements until it can be revealed by click on "more" button? That's you telling the user it isn't as important as unhidden elements.
> Have you made defaults? That's you nudging the user into what _you_ think is the sensible choice.
> In my opinion, design is fundamentally about having an opinion. A refined opinion that matches a lot of users is what is commonly deemed to be "good design", but obviously not a design never match all users.
I think we're on the same page here or close to it. I can have lots of strong opinions about how best to inform the user about their options and what will happen if they choose them. I can have strong opinions about which options are best for accomplishing certain goals. But that's different from me trying to get the user to do something specific or wanting them to. Or even having an opinion about what they "should" do, that depends on their goals and circumstances.
> Design is about manipulating people and whether you do it for good or bad is a moral choice.
I still disagree about this. I would agree if you're creating art, an experience that is meant to be fictional. But if you're providing a tool or resource, then I think design is about informing people about their choices and empowering them to make them. So it should strive to be as far from opinionated or manipulative about those choices as possible.
> I think design is about informing people about their choices and empowering them to make them.
I think we are pretty much are on the same page here too. I agree that design _ought_ to be about informing people. It looks like our definition of 'design' and 'manipulation' vary slightly, which lead to our disagreement.
- Your definition of design is a narrower than mine. (yours include the normative element whereas mine doesnt)
- I've used the word 'manipulation' in a neutral way but it was a negative one for you. (e.g. The engineer manipulated the control panel vs she manipulated him into giving him all this money)
In any case, I'll think more about your definition of design. If more designers used your definition, I think the world would be a better place!
At a high level, there’s good utility in guiding users down the path of a curated experience when the designers know the weak points of the app, or where some given tool has much more general utility than another (in which case they might hide the other tool under a context menu or something).
It’s not necessarily the case that designers guide users down paths that solely benefit the designer, and I think that approach tends to be seen by most as “bad design”. In fact, it might even be bad design by definition.
You can frame it any way you want, but you are manipulating them TO bring utility.
You are making a choice, on their behalf, that influences how they experience something without their knowledge or explicit consent. Just because you might intend them only the best, doesn't change that it is a form of unseen manipulation.
What you describe as utility is manipulating people, in a sense. You won't design a push door with handles implying it be pulled instead, so in a way, you're manipulating a user's action to push the door. I think you're assuming that manipulating people is used pejoratively, when I'm using it to mean "handle or control (a tool, mechanism, etc.), typically in a skillful manner," rather than "control or influence (a person or situation) cleverly, unfairly, or unscrupulously."
When someone sits down to use an app, the app will have higher utility if it makes whatever task they're aiming to do, easier to do. When designing an app's UI, making something easy for users is a matter of understanding what their expectations are and matching what they look for by default when they try to do a thing in your app with what you show them in the UI. That the thing they look for is the thing you show them is both the manipulation and the thing that raises the utility.
Not really. Dark patterns are a subset of nudges that push a user towards doing something they don't actually want. Say you have a 'signup or continue as guest' dialog with a "signup" button and a "later" button that appears when they try to use your app. If a user is seeing it, it's because they want to use your app. Highlighting one of the buttons is a common way of indicating "this is the thing to click to proceed". Highlighting "later" is a user-positive nudge, since it nudges those who are on autopilot, trying to use your app, to get to using your app. Highlighting "signup" is a user-negative nudge, and therefore dark pattern, because it gets in the way of the user's goal, use your app, purely for the sake of your signup rate, since it's optional.
>If a user is seeing it, it's because they want to use your app.
It could be because they want to try your app. It implies nothing about long-term goals.
>Highlighting "later" is a user-positive nudge
The label "later" is itself a dark pattern. It's forcing a user who only wants to try the app to lie, which exploits the principle of consistency (as documented in Cialdini's "Influence: The Psychology of Persuasion") to manipulate them into continuing to use the app.
> It could be because they want to try your app. It implies nothing about long-term goals.
How does "use" imply long term? Is trying an app not at attempt to make use of it?
> It's forcing a user who only wants to try the app to lie
I didn't even notice that as I wrote it, but you're absolutely right. "skip", "continue", or even "not now" would be more neutral. This stuff really gets in your head without you realizing it when its so pervasive.
> he may love fiddling with settings, but the vast majority of people do not.
I used to love to fiddle with settings. I gave up because the constant churn of modern software made it too tedious to maintain non-default settings in most applications.
What use is spending time to make a more comfortable environment when the software will randomly auto-update in two weeks and might undo all my settings, or worse, change its behavior in such a way that my custom settings just make things worse.
But I wonder if this to the authors point. You used to love fiddling with settings (I do as well) but modern software continuously makes that less rewarding.
I don’t think rewarding is the right word. It’s still very rewarding but modern software decides from time to time to undo all your work. Maybe we could say that modern software disrespects their users.
It becomes less rewarding because of the effort wasted. Making the same settings changes over and over is not enjoyable. But saying that modern software disrespects user settings is a very good way to put it as well.
It should be easier than ever to maintain settings; the tooling is so much better now.
Right, I think a lot of people enjoyed customising their first computer, and then when they got a new one or reinstalled Windows because it got slow they couldn't be bothered to do it again.
But maybe things are a bit different nowadays. Web-based software might not have this problem so much, and I think mainstream mobile OSes do a good job of importing your setup when you get a new phone.
This happened to me early on in programming career. Coming out university I had a highly customized emacs environment, that I regularly tweaked. But then on my first job, while I could use emacs on my workstation, our production systems were all Solaris were I could only use vi (not VIM, vi). The cognitive load between them killed me and I retrained myself on vi. Today I use vim, but really only change a few things like the theme.
Non-technical users may not care about settings to begin with, partly because defaults work well enough. But there will be a point where they'll have to change them, so giving them the option is important.
People don't like to spend time setting up things when they run the app the first time, but they also hate not being able to tweak things when they need to.
>> First of all, remind yourself that users love settings.
Maybe this is a better way to explain it: Some users like settings, some users have to change settings to use your product. But most users will not change them if you pick good defaults... for most users.
> he may love fiddling with settings, but the vast majority of people do not.
Funny how often this gets repeated. Usually (as here) with a conspicuous lack of supporting data.
> They do not change their mouse speed, their background image, their default browser. That's why a meme exists of people thinking the internet is the blue E icon on their desktop.
Could just as well be -- and, I think, is -- the other way around: It's not that they're ignorant because they don't change their settings, but that they don't change their settings because they're ignorant. Maybe most (or even all) of them would want to change their mouse speed, background image, and default browser, if only they knew there are settings to do it. Removing the settings wouldn't exactly help with that -- on the contrary, the solution would be to make them more obvious.
Here I am with my default Ubuntu 20.04 setup (I think) with the default hippo wallpaper that looks like a pair of hairy balls.
I'd call myself a power user and to an extent I am (give me a deb or a PPA over snap and the app store any day) but tinkering is just a pain in the ass now.
Enjoy using a music player which doesn't have volume control and a file picker which doesn't have thumbnails. I guess you feel that you don't need those features because "tinkering is just a pain in the ass now".
Or the number of people eating cheapest junk food.
I wish I could align my springboard icons to the bottom. And choose a shiny metal shelf again instead of that acrylic bullshit, but that is just my bad taste.
Defaults should be good enough I agree, but ability to change settings still should be there.
Some settings are even more important than others - like changing default browser in the operating system - that even if no one ever changes them they should be there basically by law.
and then there's the mswindows strategy of never redesigning settings pages, but designing entirely new settings pages that sort-of integrate with the old ones
...but only expose some of the settings, forcing users to go digging through the archeological pit that are older settings interfaces, because windows somehow things the settings they themselves added previously are pointless.
Then, ideally, spend a decade or more to partially and inconsistently replace just a few settings but not all, because somehow that makes sense, and at least that way users are encouraged to each go on their own little archeological dig?
Best of all, the new settings look prettier, but aren't always anymore usable, so it's not even really an upgrade.
Also some things are inherently complex. And there might not be good way to make them simple or pretty... I mostly find need to mess with network stuff on Windows and either way isn't exactly great...
But some of it is just poor UX - like one thing I repeatedly come across in both win10 and win11 iterations of settings is the really poor scrolling UX. First of all, the scrollbar is quite thin and easy to miss entirely. That also makes it hard to click on; which may not be the normal way of scrolling, but is sometimes handy - and settings need to be accessible for all kinds of people. Furthermore, the new larger and prettier padding between UI elements inside the scollpane makes is more common for the last on-screen element to have enough lower padding to make the page look visually complete, even though you're missing half (win11 isn't quite as bad as win10 here, but both are clear regressions vs. older versions).
But worst of all on the scrolling front is the auto-hiding behavior for the scrollbar. That's is just plain user-hostile. The number of times I've had to help non-techies find settings over the phone, vidchat, or even in person just to discover that the person hadn't noticed the small black scrollbar in the second or so it remains visible on screen, and they just couldn't find the setting they needed even after explanation because it had not occurred to them to even try scrolling. What inane designer thought it was a good idea to needless animate something in the first place, and then additionally to hide critical UX for anyone that merely looks at the screen without interacting with it for just 2 seconds or so? A clear, sad case of form over function.
And that's just the scrolling; the incompleteness is a big issue to (though I'm not yet sure how bad win11 is on this front, so let's hope it's at least improved).
Also, at least in win10 there's the inconsistency between settings that are immediately applied, and those that require you to apply them. Most apply immediately, which sort of makes sense, but that makes the rare apply button (which also visually is not really an eyecatcher) easy to miss, and there's no warning when you exit without applying. So far I get the feeling this is better in win11, but I haven't tried actively looking for problem cases yet.
All in all: very much meh, and I'd rather they made settings obvious, and made it easy to review what you've changed, and which settings differ from the defaults, and in general optimize the UI not for making settings changes quick for those that do this all the time (like, nobody?) and rather focus on making them clear for those people trying to change something they rare change and aren't quite sure what they're doing.
Yes but the decision to redesign something might be towards people who haven't figured it out, which if they are a large enough fraction might be worth the tradeoff.
(there are other reasons too of course, sometimes not really good ones)
Yes, it's an exercise for the developer to know their audience and their affinity for settings.
As a user of software, I agree with the author: I am generally happier with software that is highly configurable to my preferences versus software that is rigid and limited to the tastes of the developer.
Of course, this is a continuum; I am not so obsessed with configurability that I build my own customized OS from source. But a healthy settings/options/preferences panel is a way to earn my interest as a user.
> How about this rewrite: Some users love settings.
Yup.
I'm definitely one of those users. Sure, most of the time, the defaults are great. But there are probably so many things some software can do that people don't know because they never even bothered to poke through the settings.
If a piece of software has a slightly annoying behavior of some sort, the first thing I do is go to the Settings to see if it's optional. When I get a new phone, the first thing I do is check out what settings it offers. I'll even enable Developer mode (Mainly for the feature to show a circle on where I touch the screen).
Really? If your software is only used by a very specific kind of person in very specific circumstances, that logic might work. Otherwise, you'll always find two different people, or one person at two different times, with mutually contradictory definitions of annoying behavior.
For example, what should the default volume setting be? (Warning before you answer: if you don't pick the volume I want right now, it'll be annoying!) Okay, what should the default mouse speed be? (Just so you know, I might be 20y.o. with a gaming mouse or 80y.o. with a trackball.) Etc.
Right now, it's generally hard to always know what the default volume should be and I consider that a failure. One day tech will be sufficiently advanced that it can adapt to the environment and user and consistently pick an excellent default volume.
We're improving though. Volume settings are an unnecessary annoyance in a great deal of apps already and you won't need to tweak it in many apps that pick good standard defaults for notification sounds, mic volume, etc. It's grating when apps pick bad default volumes and it immediately assaults our ears. Unfortunately, users sometimes still have to tweak a global/system volume setting, but hey, things aren't perfect and it's good to have a fallback when software fails.
Two people may indeed have different preferences, but that's no excuse to force users to configure a bunch of knobs and switches themselves. Good design adapts to the user. When it doesn't, then settings cleans up after the failure.
>One day tech will be sufficiently advanced that it can adapt to the environment and user and consistently pick an excellent default volume.
This is sadly true, but I really wish it wasn't. There's no way to automatically determine the correct volume without privacy violating brain scanning.
my experience is that users love personalization, but not necessarily "settings". if they have to change a setting to get the functionality they need out of your app, they're going to be frustrated. even if that functionality is one-off weird stuff that makes no sense to be enabled by default.
as long as the app does what they want out of the box, they love unnecessary stuff like setting a custom background image or theme color.
The author is correct, but it's sad that he had to say that.
I am not thrilled with "inviolate rules of thumb," as a general principle.
Don't get me wrong. I have been doing what I do for a very long time, and have developed a huge library of habits, practices, and heuristics, in my work.
It's just that I treat them as guidelines, as opposed to "Thou Shalt Not" commandments. If an old or obscure pattern fits the bill for what I am doing now, I use it. If the problem looks, but is not exactly, like an issue that I have solved in the past, I will see if I can adjust the old solution to fit today's conundrum; even if the old solution is in a "Thou Shalt Not" area. If a current buzzword du jour is nonsensical in my work, I don't use it; no matter how good it looks on my CV.
Basically, because of my experience, I am allowed to color outside the lines.
A lot of times, I need to look at what others have done, and, if I am not an expert in their field, I have a lot less flexibility in what I can do.
For example, in the app I'm developing, the core functionality is pretty much done, and it's time to start gussying it up, putting some lipstick on the porker, theming it, what-have-you.
I was originally trained as an artist, but that was a long time ago, and my stuff tended to have a rather "prime color" palette. Think "Magpie on LSD."
I don't trust my own design sense, when it comes to a palette. I need to look at what others have done. I won't be able to deviate much, as I don't have their design sense. I don't do "subtle," too well...
> One of the small preferences we introduced in the Linear app is not displaying the mouse cursor pointer over links. We want to mimic the feeling you natively have on the desktop with our Mac app.
Hmm. This might actually be an example of settings as a result of design failure.
The text in the screenshot describes the setting as applying not just to links but to "any interactive element". But most native desktop apps (which they're trying to mimic) would use a special cursor for links and a regular mouse cursor for other interactive elements, so it seems that (by entangling links and other interactive elements) the setting allows a choice of two incorrect behaviours instead of just behaving correctly by default.
Are you using one of "pointer" or "cursor" (which are synonyms, to me[1]) to refer to either an I-beam cursor, or the hand cursor, commonly used to indicate a clickable hyperlink?
(I actually dislike how text in native apps doesn't often permit the use of I-beam; it'd be a lot easier to copy/paste errors if one could highlight them.)
In CSS, the hand cursor is called a 'pointer' cursor, so I think that's what was intended. For anyone who hasn't internalized this, including the app's users, I imagine this is quite confusing. :)
IIUC 'regular cursor' is just the default mouse cursor. I don't think anyone meant the I-beam/text cursor, but I agree with your selection comment entirely.
There's more than two types of cursors, it's just that MacOS doesn't support anything but those two (excluding the directional cursors), and Windows supports most, and most GNU/Linux DEs support all.
Jesus. Stop messing with links. Make it more obvious it is a link. Not less. People feel dumb not knowing hwne to click on something or not. A simple underline, a background change with underline, a mouse change help know what is in there and what will happen.
This oversimplification is dumb. My friends and family feel dumb for not knowing how to naivgate the dumb UX decisions
There is a difference between “the app has a pretty UI to set something” and “this setting is configurable”.
One of the great things about the Mac is that there is always the option to defer certain advanced settings to the `defaults` program on the command line (or just things you want to make configurable but do not yet have time to extend the GUI). So if you want a somewhat-streamlined UI with just a few of the most common options, you can do that without completely sacrificing the ability to expose the rest somewhere else.
One thing the Mac doesn't let me configure, even from the command line, is scroll wheel acceleration.
Sure, I can disable pointer acceleration, and I can change the overall scroll wheel speed, but I can't disable acceleration. I feel most comfortable with 1 scroll click being 3 lines of scrolling. It should ALWAYS be that way, no matter how fast I move the wheel. If I quickly flick the wheel and do 5 clicks, that should be 15 lines of scrolling. If I'm very slowly going click....click....click....each click should be 3 lines.
Instead, if I scroll quickly, each click might give 5 lines, and if I scroll slowly, each click is a pixel or two, and there's no option to disable this awful scroll acceleration behavior, even on the command line.
You may want to look into using a third-party tool to remove scrolling acceleration. According to web sleuthing you can change this behavior with SmoothScroll, Mac Mouse Fix, USB Overdrive, SteerMouse, Smooze, or Discrete Scroll. (Disclaimer: I never tried these.)
Having mouse and scrolling acceleration is preferred by almost everyone, and most people enjoy the Mac’s mouse/trackpad behavior. Wanting linear scroll speed is a niche preference, a perfectly reasonable case to leave to third-party utilities.
One of the reasons I love the KDE desktop environment on Linux is because it has settings available to customize nearly everything about it, but it has good default settings out of the box, so you don't have to customize much, but any time you want to customize something, you can go dig around in the settings and find it and change it easily to fit your needs. That's honestly the way it should be. Good settings by default for users who like to just use things as they are, but options readily available to easily change things if you want to.
I love settings. It is the first thing I open if I start a new program. It tells me about the maturity of the program. Whether it is a toy or something really well thought out.
I had a realisation a while ago that one of the first things I do when I start using a new app, or after a significant update, is to look at the settings. It gives me a feel for the "functionality space" of the application and helps me visualise its "boundaries" somehow. Different ways of presenting properties seem to make this harder or easier: I find Android to be less good and (for example) Visual Studio and Lightroom to be better. I'm not sure why.
I came to say the same thing. Although I would never be able to put is so eloquently into words.
For me this goes further. Anytime I rent a car I browse settings. "Oh cool, this car has lane-assist, and radar-powered cruise control". People look at me weird.
I think this is the same mindset that drew me to linux 20 years ago, when compiling and tweaking your own gentoo was not-crazy.
"Let's just say, if your VCR is blinking 12:00 linux is not for you"
I mostly disagree with this. To quote Joel Spolsky [1]:
> Every time you provide an option, you’re asking the user to make a decision.
At least the author differentiates on types of settings:
> There’s a difference between product settings that a product needs to get right by default and preferences that designers deliberately shouldn’t have a strong opinion on.
I can get on board with separating cosmetic choices and non-cosmetic settings.
If you're shipping a product, every setting is a potential bug because you don't test that particular setting necessarily. Worse, every combination of settings is a potential bug. Ideally, settings shouldn't allow you to put your product in an invalid state. That almost always happens with any nontrivial set of non-cosmetic settings however.
I've brought up this example many times but many here won't remember the early days of connecting to Wifi. On Windows this meant answering questions like:
- Encryption type (eg None, WEP, WPA, WPA-PSK, WPA2, WPA2-PSK)
- Passphrase (is this a password? Is it something else? Well, that depends on the encryption type)
- SSID
Apple came along and reduced this to SSID and password.
The principle I take from this is never, ever ask users to enter something that you can figure out on your own. Like you can figure out the Wifi encryption type so why ask?
Another example: why ask me for a state and a ZIP code? The ZIP code tells you the state.
Settings so often fall into this bucket. You have settings for things that don't make sense, that you can figure out the answer to and are dependent on other settings.
Practically speaking, settings become a cultural disease because product and UI/UX people can't agree and someone "compromises" by saying "let's make it a setting" rather than figuring out the right answer.
Design is the art of compromise. Settings are the art of not making a decision.
All of those features that he poo poohs in there are useful and I used them as a newb on Windows. This is Bs gospel. Sure I have had people ask me "dumb" questions but removing the customizavility is not the answer.
Your examples are valid except when zip code lookup fails or wifi lookup is not correct and the systems tries to think for me. It takes away that option. This thinking is a disease and the reason I am left with half assed systems that i ahve to work around for my friends and family everyday.
A friend felt dumb for not knowing how to plugin a line out cable on her iphone because apple decided 3.5 mm is outdated. I told her she isnt dumb and it is not her job to know that.
This is thinking is causing more dumbing down of people than anything else.
My parents feel dumb for not knowing how to use a smartphone. The dumb android dialer calls randomly and goes to background with no way to hangup. My dad cant figure out what to touch to close it. With a physical button he can close it easy. Windows phone was miles ahead than latest ios and android in call screen which is what a phone should be for. So are "feature" phones. As a cutting tech engineer, I prefer those over the ad mining machines that are iOS and android
My mom feels dumb for not knowing how to order on a website because everything now requires a login which requires a unique password and 2fa and a unique workflow with godawful hidden icons that every UX team wants to lay their marks on and eveything useful gets moved to the overflow menu, the gear or hamburger on some random side of the page.
Just have clear wordings with accelerator keys and tab bindings
Also because Joel spolsky is right on some things, doesnt mean we should listen to Everything he says. That leads to a monoculture and people are different and diverse. So should be designs. They should be more accomodating of differences, isntead of the current my way or the highway of restricted UXs and walled gardens
> All of those features that he poo poohs in there are useful and I used them as a newb on Windows.
I'm curious to hear you actually defend the "Find Setup Wizard." It seems to me like a flow so awful even people who mostly like customization would acknowledge its terrible design.
I've tried just asking for zip instead of city and state but then watch people as they type their city and state into the address line. Also theoretically people may mistype their zip and you'll have no way to validate it against what they typed in the city/state. The best is the auto-fill from some list of all valid addresses I'd say.
This article, and many of the comments here, commits a central mistake: declaring things to be true with no evidence. "Users love settings." Umm, prove it. Even more glaring, the author goes on to use his own anecdotal story to make his point. If there's one thing I've learned in decades in software development (and there's not), it's that my opinion is not a satisfactory proxy for "what everyone thinks/does."
At least when I was studying (and later teaching) human-computer interaction years ago it was a bit more complex than this post makes it out to be.
A setting might have been added because the creator legitimately couldn't make up their mind about a feature. Or because end-users have divergent use-cases, preferences, abilities, situations, or hardware. Or because the creator felt that the only way to support two different use-cases was to make two different interfaces with a settings toggle.
Each setting has an incremental cost in terms of development, testing, maintenance, documentation, initial onboarding, finding other settings, etc. The best response is to consider whether each setting is sufficiently valuable, and whether there are any settings that can be eliminated with better defaults or more flexible interfaces.
Because many people don't have time to do that, products typically end up at one of two extremes. Either they have no settings beyond the ones the creator themselves uses, or they are the union of every setting anyone has ever asked for.
It's a common antipattern to design away settings, and practical usability, with artistic purity. OTOH, providing an endless jumble of uncommon settings is overwhelming to almost everyone.
1. Make things work in the common-most use-cases, for power users and novices. I think there's a lack of respect shown to people who have difficult, edge-case, real problems to solve, like batch receiving orders while being forced into narrow pagination and sparse layouts suitable only for casual customers. Usable search and bulk actions are needed in more contexts than originally assumed.
2. If someone asks for it, there could be 100 who didn't speak-up but also want it.
> While I was reorganizing my phone, I had a sudden realization: Settings are typically seen as the result of design failure. The thinking goes that as designers, our goal is to create product experiences that don’t require any adjustments by the user. Consequently, offering customization options is interpreted as a failure to make firm product decisions.
I wonder if the author has ever considered how much users hate when things arbitrarily change as designers try to figure out what the One True Product Experience should be. (Or, more likely, try to optimize some metric management is unhappy about.)
It is both possible and desirable to build into a product a strong set of assumptions and useful defaults which can be easily overridden when your assumptions do not hold for every case.
The problem with settings and option flags is when a user needs to set a great deal of them to get anything done. Smart defaults for the common case are useful. Overrides for the uncommon case expand that utility to more cases. These two ideas are not mutually exclusive. They are, in fact, a pragmatic and helpful combination.
My take: Settings are a last resort. The more settings you have, the less likely a user is to actually find the one they need. So some settings are good, but too many are bad. E.g. dark mode is a setting that just makes sense because different users have different preferences. But it's quite easy to measure what settings almost no one is using, and to axe those. In other cases you may be able to figure out a smarter way to offer the functionality without a checkbox hidden away in a settings page
> But it's quite easy to measure what settings almost no one is using, and to axe those.
The chance is high that the "almost no one" group is actually the ones that use your app the most. Casual users won't care much about some setting five layers deep in the menu, but the ones who are dedicated enough to actually find it will care.
The constant "optimization" by taking features away that "no one" uses is what drives so many users away from installing updates. Please stop that bullshit. I'd like to not fear updates again.
Ha, I knew I would get called out on that. To be honest, in my specific case, I doubt it, I've removed some pretty pointless legacy settings which only had minor cosmetic effects. I know this stuff is in the eye of the beholder, but sometimes there genuinely are settings that someone asked for a decade ago that no one else really wanted, or possibly wasn't even what the person asking meant. But the way this usually works on our app is that the setting is just removed for anyone who has it set to the default value at that moment, so people who previously changed it won't have their stuff messed with.
Firefox forcely remove the separator between tabs in new design because users won't open too many tab in general, and they won't make the tab too small to differ.
And I fxxking hate it.
Because I am the user that will open many tab and make the tab small.
So does this mean I should not use firefox because I use it wrong? It's really a shitty attitude if you are exactly the one that they claims 'not-important'. Pray for you not being lucky enough to be the one 'not-important' if you don't know the pain yet.
Users love settings for things they care about… and abhor and ignore settings on things they don’t care about.
Better get your defaults right. That is: don’t force your users to answer questions they don’t know the answer to.
Also, partition your settings by user concern… that is, don’t confront your users with a bunch of questions they don’t understand or care about (even if the defaults are right).
In some cases they are. Global config needed to support a local module(As in a PHP app depending on proper Apache conf) kinda sucks because it can create conflicts that can only be solved manually or with a container.
Settings that can't be done via GUI suck. I shouldn't have to dig through some other app and copy and paste an IP address to use your thing.
Settings should not have to change for common activities. US vs Metric should be a document property. I should not have to change settings to properly view a certain document.
Settings without sane defaults suck too.
A good setting is "Here's a discovery server, but you can change it". A crappy setting is "Select an API version for this global daemon that 5 other things use, and only 3 can work at the same time".
Anything that can by dynamic and autodetected... probably should be unless there's a really good reason.
I love settings, browsing the settings screen gives me a feeling about how mighty a software is. Software without settings is usually very shallow, only supporting a handful of usecases. But in the modern SaaS world, they still want to charge 5 bucks per month. No thanks.
It's a solved problem there, have profiles : "Low", "Medium", "High", "Ultra High".
They allow for a quick start, then as the user is more aware of the feature, the user can tune the predefined profiles themselves.
You can have independent profiles for each independent feature : input profiles (keyboard/gamepads), graphics profiles, audio profiles, etc
For example, on a Google account, that would be a single drop down list with those options: "Private and no personalized experience" (everything turned off), "Private with personalized experience", "Public"
I think the author might be concluding too much from a period of boredom. Shouldn't we design tools primarily for busy, distracted people who have better things to do than mess around with our UI?
I don’t think so, at least not universally. If your app is a journal, editor, photo library, or a video player it’s not in your interest to have the user diving into other programs or multitasking. In those cases what they’re comfortable with and what works best for them is more important. Since you’ll come back to the program again and again or for deep work, the long term payoff can be worth messing around with the ui.
Just a little bit dumbed down, but this is the absolute correct take. Settings are design features, not bugs. Settings are beneficial to diverse kinds of humans.
Using the word "Settings" is a design failure. For example, when I right click on my so-called modern desktop, there is a longish drop down menu with a "Desktop Settings..." menu item in it which goes to a window named "Desktop" and defaults to the Background tab. On my more antiquated OS, the menu item is named "Change Desktop Background..." which seems more obvious / discoverable.
> a "Desktop Settings..." menu item in it which goes to a window named "Desktop" and defaults to the Background tab. On my more antiquated OS, the menu item is named "Change Desktop Background..." which seems more obvious / discoverable.
So the newer settings dialogue changes more stuff about the desktop than just the background?
How would the menu label "Change Desktop Background..." make all that other stuff more obvious or discoverable than "Desktop Settings"?
Make sure that most users won't ever have to change a thing, but always, always have the settings, and always mark what the default value is, so if someone messes it up, they can find their way back.
Forcing the user to make decisions because it was hard or annoying to find a good default decision is why some people have come to hate settings.
I hate being forced to create a configuration. I love being allowed to change one.
Author then goes on to talk about their own personal love of settings and does not offer any evidence that their actual users want settings.
Whether settings are good or bad depends ENTIRELY on your specific users and their specific needs. Blanket statements like this based entirely on one particular designer’s feelings are not particularly convincing.
The thing I most dislike about settings is that many products once they create settings for a thing then don't put thought into sensible defaults with the logic, "oh they can just change that". So in a way settings can be a crutch.
Does he understand the idea right? The program shouldn't require a change in settings in order to work: it should have reasonably workable default settings. This doesn't preclude customization at all.
Design tip: don't load a 4000px image into a 800px container, it's very wasteful for everyone involved. Or maybe provide some settings so I can adjust it? :)
It's nice to have settings, but you also absolutely need to have defaults which work for the vast majority of the user base who will never open the settings menu.
settings are also a great resolution to behind-the-scenes design conversations
in particular the classic 'PM wants to incentivize a flow, developer thinks it will be annoying as shit and threatens to throw phone out the window'
'let's make this a setting to see if people turn it off' is my favorite compromise for these. (Also simplifies phase two of a gradual rollout, because jealous early adopters can turn the beta setting on manually)
settings are also a liability, a form of technical debt. When you add new settings you have to make sure it works with every (logical) combination of other settings. And you need to keep doing it in the future possibly forever because users hate settings being removed. So, your tests get bigger, adding new features and especially settings becomes costlier.I try to avoid it as much as I can
Ugh. As a not-really-power user I can't stand Gnome 3, not least because I have to Google how to and then install a tool just to make useful settings accessible. Everything in Tweaks should be in the default settings panel.
I remember I dumped GNOME around 2.4, due to discussions about print UI and how close to every setting should be removed from it, possibly retained in Gconf. At the time there was still the idea that "sure, we lost a lot of settings and features in rewrite between 1.4 and 2.0, but we're going to add them back"... and the printing discussion gave me red alert of moving to "developers know best". The further evolution of GNOME only reinforced that feeling.
Ah yes, the "every preference has a cost" philosophy which leads people into deciding things like that everyone on Earth is ok with a One True Colorscheme (Adwaita) and a One True Font (Cantarell). People who suffer from halation due to the contrast of the dark version of Adwaita and people who like fonts besides Cantarell don't exist.
Cramming a big pile of "settings" into your program because you are unwilling to make choices about how things should work is shirking your job as program author/designer, and passing the work along to your hapless users.
In many cases something that is a "setting" could be better handled some other way. (For one thing, only a trivial proportion of users are ever going to actually examine your setting page.) You should strive to find another solution first, and only add a new setting as a last resort.
This is not to say users shouldn’t be allowed to modify the way things work. Allowing customization of keyboard shortcuts and menu layouts, letting users write or install plugins/extensions, including powerful abstractions that can be combined in unanticipated ways, etc. can all be very helpful.
What you're saying is the orthodoxy among designers.
The author of this article is saying they disagree with that orthodoxy.
I don't think it's helpful to just repeat the orthodoxy without saying more.
In particular I'd be very happy never to see the claim "people only add settings because they're shirking their job of making a decision" again. I don't think it's true, and I think it's impolite to make such a claim without justification.
Is it? I see an awful lot of overwhelming pointless 'settings' crammed into weird corners all over the place, sometimes in ways where the default experience is just broken and long-term users just all learn they need to tick the appropriate settings to have an acceptable experience. Over time the settings proliferate and the settings page just becomes a dumping ground. Maybe designers (or project managers) need to take this 'design orthodoxy' more seriously.
The author’s own screenshots show a settings page with like 15+ separate pages of miscellaneous settings. Maybe there’s no other way to solve the design challenges in his app, but I doubt it. When he claims that “users love settings [...] just look at your own user behaviour,” he’s projecting his personal preference/compulsion for testing and analyzing trivial tweaks (maybe as a way to procrastinate from actually using the tool? or because thinking about tool design is more interesting to him than tool use?) onto other people.
E.g. when he suggests “Some details become annoying because they are so repetitive” the easy answer is: just cut those out! Why should users have to hunt around obscure corners of your tool for a way to eliminate the annoying gimmicks you added?
Note that it is entirely possible to have a very flexible, powerful set of tools that satisfy a wide variety of niche needs while having those tools available to all users in a sensible way, without any need to hunt through the "settings" page to access them. It just takes a lot of design effort to figure out how to break down user goals into parts, abstract them, make tools capable of handling those, and then teach users how to use them.
But trying to solve tool design problems without the crutch of adding extra checkboxes to your settings page doesn’t mean you have to cripple the software or prevent people from using it in their own way.
Trust me. I have gone through every settings page on iOS, WP, Samsung, Android and many more.
All of them were necessary. You would be surprised at how many non engineering people using android samsung have non designer approved fonts and themes.
> In particular I'd be very happy never to see the claim "people only add settings because they're shirking their job of making a decision" again. I don't think it's true, and I think it's impolite to make such a claim without justification.
Reading carefully, I don't think OP made this claim exactly. I suspect all three of us might agree that there are good reasons to add settings and that we should be careful of adding them for bad reasons.
I think in many cases a setting gets added not because an individual /refused/ to make a decision but rather because no individual was /empowered/ to make the decision. I find it easy to imagine a meeting (perhaps a meeting with too many participants) that gets deadlocked on some question and the only apparent way to get out before lunch is to compromise on making it a setting. And maybe compromising the design is the best way to go, but then that's how it will be.
Is it really fair to your users to presume the are clueless? Is it a good idea to take all decisions from them, and rob them of the ability to become a designer?
I have a suspicion that this is a self-fulfilling prophecy: take away agency, and you'll end up with a demographic which never wanted any.
> Is it really fair to your users to presume the are clueless?
The more charitable interpretation is that we should assume they're overloaded; they're using our application because they have to get something done, and they need to get it done as quickly and easily as possible so they can get on with their day. This doesn't always apply; if you're developing an application that will be the primary tool for some line of work, something that people will live in for hours every day, then it makes sense to give them the freedom to make it their own. But when developing something that will merely be part of someone's workflow, possibly imposed on them without their choice, then it makes sense to impose as little as possible on them.
Good. If you take away something and users don't care, it wasn't important or necessary. Perfection is achieved when there's nothing left to take away.
You measure. You measure how often that setting was used, you analyze behavioral changes before/after, you measure retention changes, you measure complaints & feedback.
I agree that you can get momentary insight into changes, but that doesn't help you understand if you are indeed alienating potential users, for two combined reasons.
First, you can't measure the preferences of those who never were your users, or those who already dropped out.
Second, software is not static, and whenever you apply changes to it - including those not related to UI - its utility to different demographics changes. And you can't know how much of the new demographic would be your users if your software had a diffrent UI.
So while you can measure the impact of UI changes on your userbase via behaviour analysis, you can't find out whether you're excluding potential users this way.