Hacker News Reader

Comment by hrombach | Hacker News Reader

I think if you need to measure this kind of thing, you're missing the point in the first place. I don't want to be chasing some absolute productivity metric, I want a setup that doesn't break my flow. For many people, reaching for the mouse breaks their flow and feels wrong, which is oftentimes worse than being a second slower, because it takes you out of the mental frame you were in.

For me, using my mouse while I'm working feels natural, so trying to change my workflow to learn how to navigate everything by keyboard would be a huge amount of extra effort just to maybe possibly save a little bit of time in some situations.

View on HN

I think this is unhealthy self-handicapping. Your "flow" is just habits, things you've taught yourself to do. You weren't born with the ability to use either a keyboard or a mouse, there is no "natural" or "intuitive" way to operate a computer. It's all 100% learned behaviors that can be altered.

>Your "flow" is just habits, things you've taught yourself to do

By this logic a person who were comfortable with mouse should never grow to like VIM.

> there is no "natural" or "intuitive" way to operate a computer.

Fundamentally a computer is something that execute instructions. It is pretty poor interface to pick instructions from 100 options using a mouse as opposed to type it using a keyboard. A mouse hides the power of the computer behind a set of fixed clickable options. That is a pretty poor interface.

> By this logic a person who were comfortable with mouse should never grow to like VIM.

Quite the opposite, my argument is that habits are changeable.

> Fundamentally a computer is something that execute instructions. It is pretty poor interface to pick instructions from 100 options using a mouse as opposed to type it using a keyboard. A mouse hides the power of the computer behind a set of fixed clickable options. That is a pretty poor interface.

You continue to argue for my point. OP was claiming that measured efficiency does not matter because it's about "flow". I argue that one can teach oneself to flow differently, the commands can be learned.

Picking from 100 options is what the mouse is best for. Keyboards require learning so they are best for the options you do often enough to learn. I know about 10 different vi commands of the hundreds.

There is more than selecting options. Selecting text is normally better with a mouse.

>Keyboards require learning

We are not talking about keyboard shortcuts (key combinations that you press to do something) by the way, and about the actual typing of commands in the terminal/shell/repl what ever...

> there is "natural" or "intuitive"

Your argument is sound but this overstates your case a bit. There's a reason we don't type with our toes.

Reaching for the mouse doesn't break my flow. It makes the thing I was doing invisible in the flow. Keyboard shortcuts require me to think, which makes it FEEL like I'm doing something, and that something is in the flow so it feels like I'm productive. However the mouse doesn't even enter into the flow at all, I just do the thing and get on with the real work without breaking flow.

Again, there is no universal correct answer. Sometimes the keyboard really is better. However sometimes the mouse really is better and because I'm proficient in it I don't break my flow to use it.

I have an anecdote to contribute.

I been doing a lot of Bender. Keyboard on left hand and Mouse on right. The keyboard shortcuts in Blender are excellent, but there are _many_.

I know this sounds silly, but what really breaks my flow is moving my mouse from the middle of the screen where my model is, to the top of the screen where the menus is.

I bought a Stream Deck which is a programmable keyboard with 32 buttons and a screen behind them. I've programmed my most common commands there, so I can just reach across with a finger and smash a button rather than move the mouse away from the center of the screen.

It saves about 1 second, but really makes a huge difference.

I use blender a lot too. I bind space to search and then use that instead of shortcuts for pretty much everything that isn't the few shortcuts I've memorised (and g/s/r xyz etc)

Most knowledge about human computer interfaces was obtained through metrics. Groupings, menu bars, corner buttons, context menu orderings, and other things didn't just spawn into existence. There was a time where human pattern recognition and physiology was an active consideration for user interfaces. One of the reasons mouse input became popular is precisely because interfaces were created to be easy to use with it.

All of this brings me to my questions: Why do you reject measuring how good an interface is? Or given your dismay over keyboard based workflows, why do you think they would win most of the time?

I'd wager that if actually tested, in only a few scenarios the keyboard would win, while hybrids (with both mouse and keyboard input) perform best for most people.

> "I'd wager that if actually tested,"

https://danluu.com/keyboard-v-mouse/ - """The widely cited studies on mouse vs. keyboard efficiency are completely bogus ... <testing, reading, etc.> When I look at various tasks myself, the results are mixed, and they’re mixed in the way that most programmers I polled predicted. This result is so boring that it would barely be worth mentioning if not for the large groups of people who believe that either the keyboard is always faster than the mouse or vice versa."""

Sigh, I don't know why a blog-post against micro benchmarks should alter my opinion on this topic. There are more metrics than just "speed" regarding an interface. You also want it to be discoverable and visually distinct.

How someone interacts with your software is absolutely measurable and the results will vary by how a user is likely to use it in frequency and variety of function. Someone that needs to do something specific with your software every day will interact with it quite differently than someone that just hops onto it every now and then to do a different task each time.

All of this requires actual studies and observation of users over time. Micro benchmarks have no space there. Testing how fast a find and replace is is meaningless. In case of software for writing text you'd test a user actually writing prose, changing font sizes, title colors, and maybe replace a word over the file too. You would have commonly used functions mixed in with less commonly used functions over how the software is used under a specific use case. (For example, writing text, revising text, and polishing a graph representation are different use cases)

This is not easy, which probably why it's not done all too often, but it is also most definitely unlike a micro benchmark (which your link argues against).

All that being said, I don't know of any person strictly pitting mouse against keyboard when testing UI for possible improvements.

Reply on news.ycombinator.com