Hacker News new | comments | show | ask | jobs | submit login

I think that openness and confidence are major factors. Having taught older adults to use computers, one of the major difficulties is getting them past the fear that they might "break" the computer and the need to memorise rote instructions rather than experiment with the interface.

The body language is quite distinctive - tentatively pressing keys with an outstretched index finger as if the keyboard might jump up and bite them, pushing around the mouse with their fingertips rather than grasping it with their whole hand, leaning away from the screen as if it might explode in their face.

Some older people just can't internalise the idea of looking at the screen for clues as to how to proceed. No matter how many times they're told and shown, they just don't get the idea that computing is interactive. They try to memorise every interaction as a series of rote steps, so if something unexpected happens they're completely lost. They are completely incapable of navigating a UI without very explicit instruction, even if it's broadly similar to UIs they know how to navigate. Something as trivial as accidentally scrolling down a few lines on a website is a complete showstopper. I don't understand it, but I find it endlessly fascinating.

The part about memorizing rote steps is roughly what you would expect from any kind of beginner in any field or skill set. But the part about being all tentative seems like a difference between a beginner who is older and one who is a little kid. The old person has spent a lifetime learning that rash actions can have bad consequences, while the kid hasn't yet. In other words the kid doesn't know or care about breaking the computer, and so probably learns faster as a result. (Good thing it's hard to break the computer and the consequences are usually nil. Wouldn't necessarily recommend the same approach for something like base-jumping or neurosurgery.)

I wonder how much it would help these people if you framed it more as an interaction with a person. Which it is. For example, telling them things like "OK so the programmer who wrote this told the computer to grab that bit you just typed, and display it for you over here [point, point] for your reference." In other words I wonder whether knowing a little about what's going on inside the thing, and the fact that it was just some silly ordinary dufus that wrote the software, helps a person like that be a better end-user.

I've seen these exact behaviors countless times, ever since I was the "kid who knows computers" (in the 90's) trying to walk adults through using them.

Oh, and when you ask them to "look at the screen", they're only mentally able to process a 2-square-inch "window area" at any given moment. So you first have to direct their gaze, very specifically, before you can actually expect them to read and process anything. (Of course it doesn't help that many of them used bifocals that made it difficult to actually see anything up close, except maybe a book, without squinting at a weird angle. Not sure if that's still an issue today.)

As much as I'd agree with the symptoms you guys are describing when it comes to my parents and grandparents, I don't think this is much of an age problem at all.

The same thing happens to my kids when I present them with a bash shell. They don't understand how to read the instructions, and they're uncomfortable with text commands. They don't want to type 'man' or 'help', and they give up very quickly. Everything they use on computers and game consoles are GUIs, most of them extremely easy to use by the standards of text interfaces like bash & vi.

This is a familiarity problem. You have years and years of experience with your OSes, which is what allows you to see outside the 2-inch window when you use a new application. You know exactly what you can ignore, and exactly what you need to pay attention to. They don't. Being unfamiliar with all of it and not having any idea how any of it works is what makes it seem like they're not learning quickly, but it's more because they're trying to learn everything at once, and are overwhelmed, not because they're not learning at all.

> The same thing happens to my kids when I present them with a bash shell. They don't understand how to read the instructions

Uhm, the issue here is squarely on Bash's end, not your kid's. Even the Windows command prompt is far more intuitive to learn. I know because I vividly remember how much more confused I got when learning the former.

In Windows, when you type "help", it actually gives you helpful commands: COPY, MOVE, DEL, REN/RENAME, etc. and at least the basic commands are actually what you'd expect. At least you have a foothold somewhere that you can ground yourself, and you start learning a bit more every time.

Try that in Bash, and good luck learning out how to do anything in Bash on your own. Oh, you want help? I gotchu! I'm guessing you're looking for job_spec, bg, compopt, coproc, disown, shopt, or trap? Oh I'm so sorry, you said all you wanted was to just copy a file? Haha I'm just a shell! You can't expect me to know how know what it means to "copy" a file! I can't even find that command! But if you need help, type "man -k" (what kind of a name is that??) to find out more about other commands. Oh, so you typed "man -k"? Okay, "apropos what?"??? (You, thinking to yourself: is 'apropos' even an English word?? I literally just typed in man -k like they told me to, and I got back a question I don't understand...) And on and on and on, until weeks later you realize the darn command was helpfully named 'cp' and not 'copy'...

Fully agree with the crapiness of learning Bash 100%. Bash is very hard to learn compared to, say, the OS UI in Android or Nintendo Switch.

But, my point is that my kids lose all their confidence and all their patience, and they become tentative and fearful. They show all the same symptoms that were mis-attributed to age in the above comments.

On a game console, my kids are not afraid to explore every menu and push every button. In a text interface, they are lost and they don't try things. They seem to learn slowly and they don't seem to listen to instruction because of how different text UIs are from the GUIs they know. When I get a new text interface, I know all kinds of things to try, and I do so without much fear.

> In Windows, when you type "help", it actually gives you helpful commands: COPY, MOVE, DEL, REN/RENAME, etc. and at least the basic commands are actually what you'd expect. At least you have a foothold somewhere that you can ground yourself, and you start learning a bit more every time.

Yes, this. I recall back in the MS-DOS days that I frequently used a text-GUI help menu that showed all the commands you could do and what each one did.

Personally, this is what I struggle with on *nix shells - I can do the very basics but there's little guidance showing you a broad overview of what is possible. Granted, the world is bigger now but if you asked me how to do a random task I'd probably google it first instead of reading a man page.

> Personally, this is what I struggle with on *nix shells

Once you learn the 8000 or so commands, it becomes incredibly intuitive.

Don't forget all the little tricks in chaining them! And all the magic you can do with pipes.

> Personally, this is what I struggle with on *nix shells

It's not just the shells! ;)

Only problem is, those commands are useless. COPY won't back up a directory tree. You need XCOPY. Oops, XCOPY chokes for weird reasons and terminates with a strange error message because a path was more than 255 bytes. It needs a bazillion options to do the equivalent of GNU's "cp -a". If you go online to get help with this, the best advice you get is to download and install something called RoboCopy.

Yes, MS-DOS was easy to learn. XCOPY worked in MS-DOS.


"copy doesn't copy directory structures, it will only copy the files, hence the error message you're encountering. To do a deep copy such as this you can enlist either the tar command and use the construct tar cvf - --files-from=... | (cd /home/tmp/test/files/; tar xvf -) or you can just use rsync."

That's so much better..

cp most certainly does copy directory structures. Just not filtered ones whereby just certain entries are arbitrarily selected from the source tree and only those are replicated in the destination tree.

The issue in the question is that the person has expanded, into the cp command line, a bunch of full paths, effectively like "cp a/b/c/file1 a/b/d/file2 .... dest" and wants those relative paths to be re-created under dest as dest/a/b/c/file1 and so on. Indeed, cp does not do that; it simply puts the specified objects file1 file2 ... into dest.

An option to create each object's relative path under dest would be useful, but it would be a pretty awful default behavior.

GNU cp has this option:

     Form the name of each destination file by appending to the target
     directory a slash and the specified name of the source file.  The
     last argument given to `cp' must be the name of an existing
     directory.  For example, the command:

          cp --parents a/b/c existing_dir

     copies the file `a/b/c' to `existing_dir/a/b/c', creating any
     missing intermediate directories.
GNU Coreutils is in active development, unlike the Windows command line which is basically abandonware (as, to be even-handed, is the Unix (tm) command line.)

When talking with people who struggle, I talk about the that the difference between being able to see a footprint to track a new animal in the forest and you being able to use a somewhat novel computer interface are based on the same principles of experience and ignoring the piles of useless information.

Agree, they just not familiar the computer as us.

As an engineer myself, I'd say one of the harder aspects of my job is using all the freaking GUIs and interfaces presented to me. Granted, I wouldn't consider many of these interfaces to even be considered "good" by most standards, but so many designs are unintuitive I really think thats the root of the problem.

It is tough because there definitely are people who are very nervous about trying things on a computer. We just had a lady today worried about using a Mac as she is used to Windows. It is a slightly different paradigm in terms of finding programs and I remember being a bit lost at first. But I also have confidence with computers and am okay with trying things and searching for how to do things.

If you lack that basic curiosity and courage, I don't really know how "intuitive" anything can be. Isn't "intuition" driven by understanding concepts behind things? The best way to get that intuition is through a bit of instruction and a lot of experimentation.

Yeah, but I can understand this mindset. Like, I think about home maintenance. Some screw-ups are no big deal and some of them I'm going to do a lot of damage and need help fixing it. I'm not exactly gung-ho about knocking walls down with a sledge hammer without knowing what I'm doing.

Now, you might answer that you can't really break anything that badly with software, but I'd say that's not right. I could delete documents I needed with no way to recover them, or end up with ransomware, or end up putting my credit card number somewhere I shouldn't have, or whatever, and I'll likely be bewildered and unsure what happened, if I don't know anything about computers.

That's true, it is just difficult to know what level of expertise your users are at and what responsibility do you have to educate them?

Well, it can certainly be extremely frustrating to deal with user education, especially with users who clearly don't really want to learn. But it helps to imagine that all of us are like this in some ways. I think experience in a call center and as a junior system administrator has made me a more empathetic developer, anyway.

I notice the same thing. At least in my experience, I think it's generational experience not age or ignorance. I'll use my father as an example. He grew up poor, having to build or fix things for his family. Guy could build anything, build and rebuild engines, appliances, even electronics. But what these all have in common...they aren't interactive, at all. It's a process, and even a tiny mistake can ruin the entire thing or get yourself hurt. Compound that with being told as a kid not to touch expensive things (say, TV) or you'll break it, dangers of being shocked by capacitors, etc. In the end I think you end up with people who really are scared of computers. It's a new way of thinking (interactive vs process), and years of fear of breaking expensive things. Compound that further from experiences of trying to use a computer freely, getting scammed or getting a virus, getting gouged for money by Geek Squad and losing all their files/bookmarks...of course they're afraid of messing up. Just my opinion, of course, I have no hard data to back it up.

> Having taught older adults to use computers, one of the major difficulties is getting them past the fear that they might "break" the computer

This is the exact same problem I've always had many times when tinkering with electronics, so I can wholeheartedly understand it. Fortunately with computers you can pretty much promise laymen that any problem they cause fixable with no cost (except time), but in the case of electronics I find it much more difficult to overcome the fear that I might actually physically fry something and need to buy a new one. Anyone have tips for that?

I've been tinkering with electronics for about 30 years. Can do some cool stuff like assembling a power supply from scratch or an amplfier, can also put together projects with arduinos, raspberries, etc. I still fry components once in a while. But it's fun! If you are a programmer one hour of your time is worth a lot more than the cost of the components of many fun projects.

A few tips: - Do not touch anything you cannot afford to lose. - Buy at least twice as many components as needed for a project, if this is too expensive, that's a good sign you might want to get more experience with more simple projects before taking on this one. - Avoid soldering as much as possible, at least at the beginning. - If you want to learn how to solder do it with very simple circuits like those that only include LEDs and resistors. Practice a lot and then use your skills on a project you like. - If possible, measure components before installing, do not trust your knowledge of color codes or nomenclature or pins configurations in the case of diodes and transistors. - When tinkering with digital circuits try to use only 5V level components, avoid 3.3V components. Of course you can use converters to interface but it's nice to avoid that complexity at the beginning.

Hope this helps.

Cool, thanks! :)

>but in the case of electronics I find it much more difficult to overcome the fear that I might actually physically fry something and need to buy a new one. Anyone have tips for that?

Set yourself a learning budget and accept that blowing things up is part of the experience. It's not terribly expensive to buy a large stock of basic components. Sellers like Banggood offer assortments of resistors, capacitors, diodes and transistors for a few bucks. Arduino Nano clones are about $2 each on Aliexpress, so buy half a dozen. The Aneng AN8008 multimeter is more than good enough for student use and costs less than $25; a Daniu DT832 is perfectly usable for basic measurements and costs about $5, so it's no tragedy if you blow it up. You can find an old analog oscilloscope on eBay for about $50.

If you're getting into repair, ask your local thrift stores for broken electronics or buy a job lot of cheap broken stuff on eBay. If you can't fix it, you can always scavenge it for components.

Thanks, yeah. Though it's not necessarily so much the money (at least for cheap components), but the hassle of (a) figuring out if things are actually broken or if you're doing it wrong, and (b) actually going through the trouble of getting new components. Nice thing about software is you can use the same equipment for a while :)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact