Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Nomouse

github.com

Post reply on HN
Print view View original

111–120 of 173 posts

Re: Show HN: Nomouse

#111

Post by chousuke »

pix64 wrote: post #61
ryandrake wrote: post #53

Earlier quoted context omitted.

You forgot even more inefficiency: Lifting your hand off the keyboard and moving it to the mouse, [insert your above steps], then moving back to the home row.

Is scrolling through source code really faster line by line?

As a vim user, I don't really find myself needing to scroll "fast" ever. Instead, there are three common cases:

1) I'm reading through code, and scrolling one line at a time with j/k is fast enough.

2) I'm looking for a specific point in the code, in which case I use search to get to it.

3) I want to go to the bottom or the top of the file, in which case G/gg are much faster than scrolling.

Sometimes I might use Page up/page down to skim a file, but that's relatively rare.

Re: Show HN: Nomouse

#112

Post by btschaegg »

bbarn wrote: post #82
WesleyJohnson wrote: post #35

I've never understood the sentiment that using a mouse is bad. I see blog posts all the time about how a programmer's job is more thinking than writing code and/or writing good programs is also about taking out just as much code as you put in. So if writing programs is a deliberate and methodical process that - I'd argue it's also slow. Why then is there antithesis that mice slow you down and you need keyboard shortc…

I'm of a similar opinion. I grew up watching my mother have surgery on both of her wrists for what used to be called carpal-tunnel syndrome and now is just called repetitive strain injury. I've spent probably triple the time by 38 years old that she had in front of a computer, full time developing software, on a standard, non ergo keyboard which is nearly the same (even has clicky button switches!) as the one from he…

I don't think you can actually understand the issue if you haven't experienced it; that's just the way our brain works. I was extremely skeptical of Vim-bindings too, for example, and only learned them once I needed a powerful editor that compiles for ARM CPUs. While I don't use Vim anymore (mostly) I'd never want to go back in terms of the modal editing.

Imagine yourself working as a photographer using non-digital cameras. While you know exactly what you want a picture to look like, you can't tell how it actually looks without some major work (i.e. process your film). So, you have to a) take many pictures of the same motive and b) try again later if you're not statisfied.

Of course, you can get very proficent using analog cameras (a trained eye could e.g. certainly tell the proper aperture adjustments for a scene), but you'll have to train that rather inefficently, too. And sure, digital cameras have their drawbacks, but they have a very net positive effect on most photographer's work, that's why you almost find no one using the old methods anymore.

Now, you - as the "analogist" don't recognize all the factors that slow you down in your work. It has been that way for decades, right? It must be the proper way to do things. Now imagine I'm coming along, being used to use digital cameras and forced to use analog ones in your working environment. Can you imagine the frustration I'm going through?

I just want to make a picture of what I need and tell if it worked, if my last two seconds of activity will do. But the old thing has no screen I can use to see if the picture was to bright, to dark or even blurred. That's what the mouse-based workflow feels like after a while: It's unnecessairily slowing you down, constantly standing in your way. No matter if it's not the activity you spend most of your time with - it prevents you from going back to your real work as soon as possible. And if you're used to do the same things without it, you'll very likely get frustrated some time.

Edit: I just realized another good metaphor would be to compare old FORTRAN punch cards (punching them out, giving them to an operator and waiting until the next day for the results) vs. debugging a modern C# application. That'sessentially what you're doing with proper hotkeys: Tightening your feedback loop.

Re: Show HN: Nomouse

#113

Post by alkonaut »

A mouse is a terrific thing to use in the right context. Selecting an item among thousands or clicking an arbitrary position (for drawing something or selecting items in a graphical context) is an order of magnitude faster with a mouse.

Navigating a complex webpage with the keyboard is painful even if tab order is perfect.

Starting a command that you have a keyboard shortcut for is perhaps slower with a mouse - so use the keyboard then. But I suspect I do more of the first kind than of the second. And yes I'm a programmer.

Re: Show HN: Nomouse

#114

Post by btschaegg »

watwut wrote: post #108
jmjanzen wrote: post #73

Earlier quoted context omitted.

I think I can speak from a position of genuine dislike of mouse usage. I enjoy it for certain things, like perusing the web, or clicking through tickets while sipping on a morning coffee. The mouse is a great invention, and I would never want to get rid of it completely. That said (subjectivity ahead), the mouse becomes annoying only when I'm done thinking, and it's time for doing. Imagine you've got your window mana…

Navigating code with mouse is much faster then with keyboard only. Things like ctrl+click to see function definition or mouse over to see function documention, variable value or its type. Double click the name before I press shout cut for rename and so on and so forth.

Perhaps, if the only thing you're doing is actual navigation. As soon as you want to also edit said code, you loose said benefit since you're constantly switching between mouse and keyboard.

Als, if you do other actions than "goto definition", you'll also lose that speed very fast. In VS, "find occurrences" is burried somewhere in a rather convoluted context menu, while I can perform the according hotkey (C-k C-r) in a split second.

Re: Show HN: Nomouse

#115

Post by btschaegg »

mjw1007 wrote: post #103
chipotle_coyote wrote: post #92

Earlier quoted context omitted.

I suspect a lot more of it is perception than people imagine: keeping your hands on the keyboard all the time seems like it intuitively must be faster. Early research in human-computer interfaces suggests that this isn't actually the case, though. From 1989: "We've done a cool $50 million of R&D on the Apple Human Interface. We discovered, among other things, two pertinent facts: (1) Test subjects consistently report…

I wish people would stop citing that old AskTOG article. The $50 million (in 1989) research figure sounds impressive, but they don't say how much of that was keyboard-vs-mouse research and the answer is quite likely "very little". It seems that, like most UX research, they were testing how well novices manage rather than how well people do after weeks of experience (the latter is expensive to test!). When you get to…

This this this. Citing articles like this and completely ignoring the setup of the experiments is one of the major pet peves I have with discussions like this one.

You could certainly reproduce those results - if the only program you test them with is MS Wordpad. If you're doin surveys involving editors that have a thought-through keyboard interface and with people who are actually trained in it, the result would never even be in the same ballpark. What we're looking for is the skill ceiling, not the skill floor.

Re: Show HN: Nomouse

#116

Post by tempodox »

WesleyJohnson wrote: post #35

I've never understood the sentiment that using a mouse is bad. I see blog posts all the time about how a programmer's job is more thinking than writing code and/or writing good programs is also about taking out just as much code as you put in. So if writing programs is a deliberate and methodical process that - I'd argue it's also slow. Why then is there antithesis that mice slow you down and you need keyboard shortc…

There is no mouse in vim. You're a new-schooler.

Re: Show HN: Nomouse

#117

Post by atnnn »

WesleyJohnson wrote: post #35

I've never understood the sentiment that using a mouse is bad. I see blog posts all the time about how a programmer's job is more thinking than writing code and/or writing good programs is also about taking out just as much code as you put in. So if writing programs is a deliberate and methodical process that - I'd argue it's also slow. Why then is there antithesis that mice slow you down and you need keyboard shortc…

Using a mouse is distracting. It steals our focus away.

Programming can seem like a slow process because the bulk of the process happens in our minds. Keeping our focus on our precious mental models makes us more productive.

Keyboard shortcuts become mechanical. When we're in the middle of editing code, whether we type "F8" "C-c C-l" or ":make", we can keep your focus where it belongs. But if we use a mouse to click on the "Build" button instead, we lose part of our focus looking for and aiming at the button. Menus and file explorers are especially bad at this: when opening a menu item or looking for a nested file, every single subfolder or submenu steals more of our focus away.

I know a few programmers who never use auto-completion for file names or methods. It surprised me and frustrated me a lot at first. Typing long file names without tab completion can be so. much. slower. But then I realised we can be much more efficient that way! Auto-completion interrupts our focus. We need to take in new information and make decisions. It's all about eliminating the step where we ask ourself "Why did I open this file?" or "What goes next?". It is easier to think about what arguments we want to pass to a method when we're not focused on selecting that method from a drop-down list. That is also why precise touch-typing is so important. We don't want to focus on either the pointer or the keyboard, we want to focus on our code.

The mouse itself isn't the problem, in fact some editors such as ACME or Blender make very good use of the mouse. The problem is inefficient UI design that interrupts our concentration.

Re: Show HN: Nomouse

#118

Post by btschaegg »

chousuke wrote: post #111
pix64 wrote: post #61

Earlier quoted context omitted.

Is scrolling through source code really faster line by line?

As a vim user, I don't really find myself needing to scroll "fast" ever. Instead, there are three common cases: 1) I'm reading through code, and scrolling one line at a time with j/k is fast enough. 2) I'm looking for a specific point in the code, in which case I use search to get to it. 3) I want to go to the bottom or the top of the file, in which case G/gg are much faster than scrolling. Sometimes I might use Page…

Actually, this is also a point worth stressing for people without Vim-experience: Searching is a "first-class citizen" (as the FP-guys put it with functions).

It's only ever one to two keystrokes away. You press '/', enter your phrase, and press ENTER. Stepping is done with 'n' and 'N'. There really are no convoluted hotkeys for this - which means that you do it much more liberally once you're accustomed to it.

Also there's '*' and '#' to quickly find the next/previous positions of the word your cursor is currentl located on. The same thing applies there.

Re: Show HN: Nomouse

#119

Post by d33 »

hahajk wrote: post #91
gwu78 wrote: post #87

Earlier quoted context omitted.

I constructed a proper URL and submitted an upvote. upvote " rel="nofollow">https://news.ycombinator.com/vote?id=13847301&how=up&auth=f4...

I'm sorry, is this satire?

It could be. It's about leaking the auth token :D

Re: Show HN: Nomouse

#120

Post by mtdewcmu »

mjw1007 wrote: post #103
chipotle_coyote wrote: post #92

Earlier quoted context omitted.

I suspect a lot more of it is perception than people imagine: keeping your hands on the keyboard all the time seems like it intuitively must be faster. Early research in human-computer interfaces suggests that this isn't actually the case, though. From 1989: "We've done a cool $50 million of R&D on the Apple Human Interface. We discovered, among other things, two pertinent facts: (1) Test subjects consistently report…

I wish people would stop citing that old AskTOG article. The $50 million (in 1989) research figure sounds impressive, but they don't say how much of that was keyboard-vs-mouse research and the answer is quite likely "very little". It seems that, like most UX research, they were testing how well novices manage rather than how well people do after weeks of experience (the latter is expensive to test!). When you get to…

I don't understand what task the users were doing when the mouse was discovered to be faster. The keyboard and mouse are not generally interchangeable; the task will generally favor one or the other. I'm assuming that the users were doing something like manipulating a GUI that favored the mouse and was awkward with the keyboard. The purpose of the study was probably to convince people to buy Apple's new mouse-centric computers.

Here is what's annoying: having to frequently move back and forth between the keyboard and mouse. Having to glance down to find the mouse to do one thing and then back to keyboard starts to break one's train of thought.

Post reply on HN