Hacker News new | ask | show | jobs
by danShumway 1711 days ago
There are a lot of things that contribute to learned helplessness, but in my opinion one underrated cause (for computers) is lack of security.

Particularly with touchscreens, it's really easy to break settings or delete something if you're doing something fiddly. I think people underestimate how powerful concepts like the recycling bin are, history, etc... in making people feel a bit more confident about experimenting.

How to translate that stuff to completely computer-illiterate people is a big challenge. But my experience is that when people feel like it's really easy to revert mistakes, they tend to experiment more and they tend to be bolder about trying to solve their own problems. And in the opposite direction, as they learn more that computers are dangerous even in specific areas, that can bleed over into other contexts and make them scared of trying things in other programs and with other devices.

When I see people who aren't willing to try and figure out what a URL bar is or who are scared to move files around or organize a directory or bookmarks, I sometimes wonder what the rest of their computer looks like and if they're channeling anxieties with other programs.

Of course, that's only one aspect of the problem though, it's an issue with multiple causes.

1 comments

> Particularly with touchscreens, it's really easy to break settings or delete something if you're doing something fiddly.

I think this is correct. Turning the steering wheel never randomly creates a bunch of new problems for the user that they don't understand. It works the same way every time over the course of the user's entire life. I've probably made millions of turns of a steering wheel and all it's ever done is turn the wheels.

The "learned helplessness" here is on us, not the users.

> The "learned helplessness" here is on us, not the users.

I think the big problem here is everyone of the big players “giving up” and trying to obscure and abstract as much as possible rather than make things clear.

Most people understand a phone number +[country] (area) (number).

Basic URL parts like (http/https)://(server)/(address) is not that much more complicated, is it really?

Google and Apple have really set the trend here in making it feel more difficult for users. Things like “unified bar” and hiding the address are just two concrete examples in two decades of “making it easier”.

> Basic URL parts like (http/https)://(server)/(address) is not that much more complicated, is it really?

Yes. http[s]://www.facebook.com/my/profile?token=goes_here&other_params and http[s]://evil.co/facebook.com/my/profile?token=goes_here&other_params are very different things, but naïvely presented the visual weight is not on the important parts.

+1 800 555-1234 and +1 900 555-1234 are also very different things, with one being toll-free and the other being pay-per-call, and people seem to be able to understand that
A lot of people don’t, I didn’t even know that 900 means that. But ignoring that, you’re able to verify that the person on the other line almost certainly isn’t who you intended by just having them say anything, whereas evil.co might look literally identical to Facebook. There are security and performance issues that are totally invisible to you when you use http vs https, and the errors you get aren’t just a “that number you dialed is unavailable” but instead some arcane issue about SSL certificates or something, which you didn’t know even existed, whose error page is designed to make you feel literally unsafe. The length of a phone number in a given locality is generally constrained, whereas URIs can be extremely long and complicated, and the effects of a different URI or query parameter are unbounded and differ from website to website based on no consistent pattern, and on top of that as you’re navigating a site you don’t explicitly interact with the URL at all whatsoever, whereas with phone numbers the input pretty much ends the moment you connect your call.

So yes, URLs are way more complex.

> Most people understand a phone number +[country] (area) (number)

I’d wager most Americans don’t know what our country code is or what country codes are. Just say’n.

> Turning the steering wheel never randomly creates a bunch of new problems for the user that they don't understand.

Having seen the kind of situations (untrained) drivers get themselves into while looking at a complete loss of how to proceed, I would like to vehemently disagree.

That's why most western countries have something that passes for "training" as an requirement to be allowed to drive.

No such thing with computers.

With this analogy I suppose an omnibar would be like a self-driving car? Or maybe just an automatic transmission?

I do think consistency is also an important part of interface design, so I don't think GP is wrong to bring it up as something that modern software often fails at, but the type of consistency they're talking about isn't what I'm talking about with safety to experiment.

For me, a better car analogy would be something like the fact that your radio controls can't mess with your brakes. You don't have to worry that if you change your radio station that your car suddenly won't start. This means that you probably don't feel nearly as worried about messing with those controls in an unfamiliar rental car. The entertainment system is never going to brick your car and make it impossible to drive (well, in most cars it can't).

----

That's still a kind of tortured analogy though, so I'll dispense with the analogies entirely and just talk technology. When I teach people how to use Git, some of the most important early commands I teach them after the basic data model are:

`git reflog`

`git reset <ref>`

`git rebase -i <ref>` (and importantly, I wire this up to something other than Vim)

I have observed anecdotally that people who have a good grasp of `git reflog` are much more likely to experiment with branching strategies, rebases, and merges, and are much more likely to come up with creative ways to solve their problems. Why? Because they're no longer scared of blowing up their entire repo.

I used to leave those more "complicated" commands out of early conversations with people because I felt like I would be dropping too many concepts on them too quickly, but without that kind of confidence that says "I can undo any Git operation, swap my head to any reference, and reorder, merge and customize any set of commits from any branch", people treated Git more like a set of arcane symbols and they were scared to ever experiment or try to extrapolate to solve their problems, even when their problems could be solved using commands they already knew.

Git could be a lot better about this stuff; the lesson I take is that I want to have very clear designations between dangerous and safe operations, and I want my interfaces to teach people where the undo key is first.

----

You can probably think of other Linux tools that demonstrate this issue as well. It took us a long time to get safety locks around `rm -rf /`. In some ways, the point of those safety locks isn't just to help protect the reckless people who do irresponsible things without thinking. It's also to give more confidence to people who are learning basic terminal commands/Bash that they're not going to accidentally mess up a pipe or regex expression and delete their entire hard drive if they try to experiment a little bit.

We can take that even a step further, one of the best things you can do if you're learning Linux is get a good, reliable hard drive clone pushing regularly to a backup. You'll be in a better position to learn how the low-level system works if you know in the back of your head that you can always just blow the entire thing a way and rewind back a few days whenever you want.