It's easier being a techy than a dilettante
I've spent years advising and helping friends, family and clients with computers. When I started, I wanted to teach everyone how things really worked, and couldn't understand why my enthusiastic explanations of technical detail were greeted with incomprehension or indifference. Later, I came to appreciate that the technical details that fascinated me were bewildering or dull to many people, that most people just want to use computers to get things done, and that actually I'd devoted vast quantities of time to learning what I knew, and I couldn't expect everyone else to do the same.
Since then, I have devoted a great deal of effort to translating my explanations into everyday terms, and into pointing people to systems that are easy to use and maintain without specialist knowledge, rather than the way I would do things. "Maintenance" is important: I want my friends and family to be able keep their own computers in working order: they're happier as they're more in control, and I don't get bothered with as many trivial questions. With clients the balance seems different, as they're paying me to run their systems; however, I've never been in danger of running out of things they would like me to do, so helping them run their own systems better is not going to put me out of work.
However, as time has gone on, I've found this approach to be more and more difficult. There is the practical side: I'm advising people to use systems I don't use myself, so I have to learn about them in order to help with problems. The main problem, however, is that by keeping them away from nasty technical terms and concepts, I'm keeping my users stupid. Often it's near-impossible to give them a sensible explanation of how to do something, why their systems don't work, or how to fix them. The temptation is just to fix it myself (it's quicker!) but that disempowers them and makes the situation worse.
This problem applies at all levels, from complex GUI concepts such as context menus to cross-cutting technical concerns such as DNS. Context menus, usually opened by right-clicking on an object, are a powerful and useful tool: when navigating Microsoft Windows, which I rarely use, context menus are one of the first places I look when I'm trying to do something, and they often get the job done. Yet it's hard to explain the idea behind them to a naïve user for whom pointing at things and clicking with the mouse is already a major task.
Similarly, DNS is a fairly simple concept, but it's a technical detail I usually hide. Why should users have to know about internet addresses? But without this knowledge, DNS problems are more confusing for the user and harder to explain: when DNS doesn't work a user may experience several seemingly unrelated problems, such as email not arriving, the web browser being unable to find web sites, and an inability to sign in to instant messenging. If they knew about DNS, they'd be able to recognise the uniform symptoms of an inability to turn machine names into internet addresses.
Increasingly, therefore, I divide people I advise into two categories. In the first category I place the naïve users whom it is unrealistic to expect to be able to educate technically. Usually, they rely on me for technical support. To limit the burden both on me and them, I try to identify what they want to achieve with their computers, and then aggressively simplify their environments so that, as far as possible, it presents them only with things they need. I have also tried to find ways to help them as directly as possible, for example, by using VNC to demonstrate techniques on-screen to a Windows user. For another user, on Linux, who only needed to be able to use email and browse the web, I took the radical but apparently effective step of running only a web browser for them when they logged in, thereby doing away with all the complexities of a desktop, menu and filing system.
The downside to this approach is that if the user's requirements expand, their environment may well have to be completely redesigned. Hence, setting their initial environment up with enough complexity to allow for expansion into new uses is essential. I've not yet found making this judgment to be a problem.
My second category of users includes users with some technical knowledge or aptitude, and everyone whose computing requirements are fairly complex: for example, those users who want to be able to run a wide variety of programs including office software, personal information management, internet applications and multimedia software. Sadly, there is no really simply framework that incorporates all of these; they have to use some sort of modern desktop. Also, the requirements of their applications (whether in terms of hardware, for multimedia, software, for sharing documents with other users, or both, when dealing with the internet) are complex enough that it pays to teach them about technicalities. Whether it's a question of DNS, of file formats, of filing systems, or file types, I've found technical information given in small doses with plenty of motivating explanation can be effective, allowing users to fix many small problems themselves, and, as explaining things to them is less difficult once they have some technical knowledge, it means I have time to do more for them.
There are however two even more important reasons that technical education is a good thing: security and freedom. Many readers may be wondering why I haven't mentioned security yet. The vast majority of security exploits are due to lack of user education, whether because a user opens a virus-bearing attachment in an email, or fails to understand the importance of having a firewall and anti-virus software. Sadly, these problems pretty much have to be expressed in technical terms at the moment, because of the overly technical nature of user interfaces, so users simply have to know something about file types and internet ports. This problem is known and discussed widely enough that I don't need to elaborate further here.
Less obvious is the point about freedom. The trouble with using non-technical vocabularies is that they are usually restricted to a single environment (Microsoft Windows, Mac OS, Emacs), and often a single program and therefore tie the user to that environment or program. Technical terminology is sometimes like that, but more often it's standard across a wide range of environments. This is because technical standards are just that: they are standard and widely used, and they take their terminology with them. The more I see efforts by powerful corporations to take control of intellectual property and the internet, and efforts by governments to remove individuals' rights to privacy, the more I realise that this is an issue that affects every user, and as a technical guru for many it is my responsibility to educate users about these issues too. Getting technical with them is just an extension of that.
In an ideal world, none of this would be necessary. The technical simplicity of the Canon Cat and the original Mac, and languages such as Forth and K, could bring easy computing to everyone. Sadly, many reasons, cultural as well as commercial, mean this is unlikely to happen, though there are some powerful currents (such as the drive towards simplification in the GNOME system) that are moving in the right direction. In order to make good decisions in this world, it will be necessary to learn about the technical side of computing, just as it in a democracy one must learn about government and law, and in a capitalist society one must have a grasp of finance and taxation. And techies, while still needing to devote care and thought to the way they communicate with the less techically ept, can stop apologising for their argot, and instead offer it as a powerful tool for users to understand and control their technology-dominated world.
Reuben Thomas, Paris, 13th April 2004
This is very interesting. I'm glad you've stopped attempting to explain high levels of technicality to people willy-nilly, and also that you've stopped leaping in and fixing things for people, if indeed you have. I've definitely had you fix the same things for me repeatedly when it would have been better for everyone for you to teach me how to do it myself the first time. Personally, I'd like to avoid learning techie-stuff as much as possible but will do it if I have enough motivation. If there's something I really want to be able to do then I'll learn whatever is necessary to do it. If I have no interest in being able to do the thing then no amount of persuasion is going to get me beyond that techie-boundary. Remember all those years you spent trying to convince me that LaTeX was a wonderful thing…? The more complicated issue is that sometimes you don't even know you want to do something if you don't know it's available…E
Last updated 2004/04/13