Hacker News Reader

Comment by smacktoward | Hacker News Reader

Still - it is a good idea to steer users away from arrows, inclduing to disable them in default files if you're mentoring.

Why?

This is the line of thinking that I was intending to challenge.

A wise man once said to me -- if the user and the software don't fit together elegantly, there's only two ways you can respond: by fixing the software, or fixing the user. In nearly every case, fixing the software to work the way the user expects is easier and cheaper than trying to fix every user who ever encounters it to work the way the program wants them to.

Steering users away from arrows is trying to fix the user. It's pushing her away from what every other bit of software on her system, including the OS itself, has trained her to do, to a different pattern that this one program believes is better.

View on HN

OK thanks for clarifying. I understand your point better where I missed it before.

Still, I think there's some sense in being able to control your editor without moving your fingers from the home row, and learning unintuitive-but-powerful tools for a significant subset of users. If you spend eight hours a day most days using a text editor, then criteria like [ease-of-use to new-comers] ranks a lot lower than others, such as sheer power.

Regarding user expectations - the OS doesn't train users to use the arrows. Bash does, and only when it's in emacs mode. If you sat down at a Solaris console, often ksh would be the default prompt and arrows wouldn't work. Vi interaction would. (You can configure bash to work like this - this is how I work. set -o vi)

I realise that from the perspective of a new user, what I've said above that would feel like an insultingly meaningless technicality. That kind of thing used to drive me around the bend.

I strongly agree with your conclusion,

    Anytime you talk about how UNIX-like systems have
    evolved, there's a danger of falling into the trap of
    hailing historical cruft as "misunderstood features."
    But at the end of the day, it's still just historical
    cruft.

I loathe "it should be that way because it is that way" justifications, or arguments that defend appalling design with "oh you just need to get comfortable with how it works".

Touch-typing. It's difficult to relate to if you cant touch-type. Expert typists loathe taking their fingers off the middle row; using the arrow keys(or any other navigation keys) means taking your fingers off.

I would counter that with computer gaming. Everyone who plays computer games growing up would be familiar with the keypad, the arrow keys, or WASD. In all cases, UP is always above DOWN.

For this demographic, HJKL is just wrong.

Computer gamers are also proficient in controlling a keyboard and a mouse at the same time, so the home row argument does not apply.

Yeah, I think UHJK might really make the most sense.

j still moves you in the same direction as ctrl-j (linefeed)

h still moves you in the same direction as ctrl-h (backspace)

there's never been a good association between k or l and their ctrled equivalents; no gain or loss there

u is now up - mnemonic ftw

moving undo to ctrl-u would make redo (ctrl-r) more discoverable

Another proposal: IJKL. Your fingers don't move off the default home position.

True, but somehow I am more willing to rebind undo than insert; I am not sure this is logical. I also do like the h,ctrl-h and j,ctrl-j correspondences I mentioned - helps me remember the values in question when working with ascii (ctrl-a = 1, ctrl-b = 2, etc).

Of course, already having muscle memory for hjkl from vim, robots, hack, &c, I'm not rebinding anything standard - I find it valuable to be sufficiently at home on any system I am I find myself working on.

How about straight up WASD? It is already a defacto standard anyway.

Outside of games, I can't think of anything that uses WASD.

About those keys - with the possible exception of S - all those keys are tied to significant functionality you wouldn't want to replace.

I find the switch between hjkl and uhjk easier than the switch between asdf and wasd, but that could just be me.

Oh I agree it's not for everyone. I'm just saying what might be the reason from a historical perspective.

Gamers are proficient in their niche; game playing. However if the job is to hammer out 400 lines of code or a manual, I'd back an expert touch-typist proficient with Vim over a gamer every time.

It's difficult to explain; the kind of people I'm talking about are experts in not just typing; they are super-proficient in coding as well. They have the text in their head, they just want to feed it to the computer in the shortest time possible. I've sat and watched an Unix guru create a program from scratch with Vi - it's a marvel, it's quite like watching an expert race car driver, if you're into that sort of thing.

It's pushing her away from what every other bit of software on her system, including the OS itself, has trained her to do

But that's not true if you're the kind of user that uses VIM regularly, since many CLI (ncurses) programs use the same keys. And even on the web: Gmail, Google Reader, Google+, Reddit, Jira, Tumblr, Tiny Tiny RSS and others support J/K for up/down navigation.

You mean down/up navigation.

Anyway, adding keyboard navigation directly to a web app (instead of as a browser extension) breaks the "do one thing and do it well" philosophy.

This is why Google Chrome doesn't allow one to use Backspace to go back to the previous page (the most used shortcut for a browser) or Slash to trigger inline search. Instead, you have to use CTRL-Left and CTRL-F, as the one-key shortcuts are reserved for their web apps.

> this one program

/usr/games/robots

Reply on news.ycombinator.com