A good point, but I think it's brought across a little clumsily.
What is the point of all software?
Well, in a computer science sense it is to "solve problems", but that doesn't help us, it's too abstract. So what is the point of all software used by humans? Ah, this is getting a bit closer to the matter. It is to bridge the gap between the user and "solving problems" in a computer science sense. Put a different way, the point of software is to render the machinery of computation human usable.
We can imagine doing this at a simplistic level by just exposing the guts and internals of whatever "problem solving" program we are concerned with and allowing the user to fiddle with them directly. This is the checkboxes problem. It's a control panel with a bunch of levers or toggle switches. This is certainly an interface but it is typically not a very good one. It's the Altair 8800 of interfaces, it's really only a few steps removed from toggling in boot code directly and mucking about with machine code, calling such a thing an interface at all is generous.
But consider not only the problems brought up in the article, that of levers accessible to the user which the vast majority of time you don't want to change. This reminds me of a utility program in one of the Windows NT tool kits, fragment.exe. Which does exactly what you think it does to a hard drive, obviously for testing purposes. It's not something any sane person would ever use normally, but imagine if there were a common command-line tool that had been designed to both fragment or defragment a drive, call it fragtool.exe perhaps, and it would take either --increase or --decrease options. That sort of interface skews your perception of things and it can quite easily lead people into believing that fragmenting a hard drive is not as exceptional an activity as others understand it to be.
As this example should illustrate, this is a problem that many command-line tools suffer from (I'm looking at you, git).
The goal of good software creators should be to translate their domain experience not just into a problem solving toolkit, it should also be to guide the user towards patterns of use that make sense, are more common, or are more beneficial.
Getting back to the example of poor lever-based interfaces. Imagine something not just with unnecessarily exposed likely to be detrimental "advanced options" but merely something with several options that interact with each other. This can easily create a fundamentally intractable problem for a user. Remember that toggles are like bits, so if you have, say, 4 toggles that means you have 16 different combinations, and if you have 10 toggles you have over a thousand combinations. Again, here is where the value of good software design comes in. As a coder you should be translating your knowledge of the problem space and the underlying capabilities of the software into configuration options that make more sense to the user. For example, if you have 10 toggles are there actually a thousand different equally useful configurations or are there options that tend to fall into certain patterns relative to each other or maybe there are only a small number of specific configurations which tend to be popular. So consider using an interface that abstracts the options behind a different set of higher level configurations that make sense to the user.
I forget who invented the term, but a great concept is the "pit of success". It's generally the idea that in a good design the easiest and most natural way to do something will tend to be the most beneficial. Software that guides you towards using it in the most effective way, rather than software which requires a steep learning curve just to avoid using it incorrectly, let alone to its maximum potential.
What is the point of all software?
Well, in a computer science sense it is to "solve problems", but that doesn't help us, it's too abstract. So what is the point of all software used by humans? Ah, this is getting a bit closer to the matter. It is to bridge the gap between the user and "solving problems" in a computer science sense. Put a different way, the point of software is to render the machinery of computation human usable.
We can imagine doing this at a simplistic level by just exposing the guts and internals of whatever "problem solving" program we are concerned with and allowing the user to fiddle with them directly. This is the checkboxes problem. It's a control panel with a bunch of levers or toggle switches. This is certainly an interface but it is typically not a very good one. It's the Altair 8800 of interfaces, it's really only a few steps removed from toggling in boot code directly and mucking about with machine code, calling such a thing an interface at all is generous.
But consider not only the problems brought up in the article, that of levers accessible to the user which the vast majority of time you don't want to change. This reminds me of a utility program in one of the Windows NT tool kits, fragment.exe. Which does exactly what you think it does to a hard drive, obviously for testing purposes. It's not something any sane person would ever use normally, but imagine if there were a common command-line tool that had been designed to both fragment or defragment a drive, call it fragtool.exe perhaps, and it would take either --increase or --decrease options. That sort of interface skews your perception of things and it can quite easily lead people into believing that fragmenting a hard drive is not as exceptional an activity as others understand it to be.
As this example should illustrate, this is a problem that many command-line tools suffer from (I'm looking at you, git).
The goal of good software creators should be to translate their domain experience not just into a problem solving toolkit, it should also be to guide the user towards patterns of use that make sense, are more common, or are more beneficial.
Getting back to the example of poor lever-based interfaces. Imagine something not just with unnecessarily exposed likely to be detrimental "advanced options" but merely something with several options that interact with each other. This can easily create a fundamentally intractable problem for a user. Remember that toggles are like bits, so if you have, say, 4 toggles that means you have 16 different combinations, and if you have 10 toggles you have over a thousand combinations. Again, here is where the value of good software design comes in. As a coder you should be translating your knowledge of the problem space and the underlying capabilities of the software into configuration options that make more sense to the user. For example, if you have 10 toggles are there actually a thousand different equally useful configurations or are there options that tend to fall into certain patterns relative to each other or maybe there are only a small number of specific configurations which tend to be popular. So consider using an interface that abstracts the options behind a different set of higher level configurations that make sense to the user.
I forget who invented the term, but a great concept is the "pit of success". It's generally the idea that in a good design the easiest and most natural way to do something will tend to be the most beneficial. Software that guides you towards using it in the most effective way, rather than software which requires a steep learning curve just to avoid using it incorrectly, let alone to its maximum potential.