It actually seems to me that the trouble computer-illiterate people have is often a case of insufficient compartmentalization, not too much. To take your keyboard example—they know things that work in a software domain, and know things that work in a hardware domain, and are failing to keep these separate. Kids, who start with far fewer preconceptions of how things should work, pick up the use of computers much faster.
Also, we computer-literate people probably underestimate how sheerly arbitrary many things must seem like to people who haven’t had a long exposure to computers. (How is a person to know that keyboard settings aren’t stored in the keyboard? After all, you could toggle the write-protect status of a 3½ inch disc by flipping the right tab on the disc. And the amount of region switches on a DVD drive is stored in the device itself. And once you know that electrical devices lose at least some of their settings when the power is turned off, it isn’t too unreasonable of a hypothesis that unplugging the keyboard might reset the settings.)
If the keyboard was USB I might have given unplug and plug in a shot. That’s the kind of software intervention that often works. I have never had cause to investigate where keyboard settings are configured.
In general, as the devices become more complex and “intelligent” the number of plausible hypotheses about any failure starts to rise rapidly. Also, the ability to rule out possibilities on the basis of knowledge about the system starts to drop… When I was a kid, most communications channels were analog, and unidirectional. I could bound what was failing by knowing that the transmitter had no clue what happened at the receiver. That is no longer true. “sheerly arbitrary” things are a problem—“sheerly arbitrary” things that sometimes change from release to release of code can be much worse...
It actually seems to me that the trouble computer-illiterate people have is often a case of insufficient compartmentalization, not too much. To take your keyboard example—they know things that work in a software domain, and know things that work in a hardware domain, and are failing to keep these separate. Kids, who start with far fewer preconceptions of how things should work, pick up the use of computers much faster.
Also, we computer-literate people probably underestimate how sheerly arbitrary many things must seem like to people who haven’t had a long exposure to computers. (How is a person to know that keyboard settings aren’t stored in the keyboard? After all, you could toggle the write-protect status of a 3½ inch disc by flipping the right tab on the disc. And the amount of region switches on a DVD drive is stored in the device itself. And once you know that electrical devices lose at least some of their settings when the power is turned off, it isn’t too unreasonable of a hypothesis that unplugging the keyboard might reset the settings.)
If the keyboard was USB I might have given unplug and plug in a shot. That’s the kind of software intervention that often works. I have never had cause to investigate where keyboard settings are configured.
In general, as the devices become more complex and “intelligent” the number of plausible hypotheses about any failure starts to rise rapidly. Also, the ability to rule out possibilities on the basis of knowledge about the system starts to drop… When I was a kid, most communications channels were analog, and unidirectional. I could bound what was failing by knowing that the transmitter had no clue what happened at the receiver. That is no longer true. “sheerly arbitrary” things are a problem—“sheerly arbitrary” things that sometimes change from release to release of code can be much worse...