Hacker News Reader

Comment by commandar | Hacker News Reader

It's just terrible UI design on so many levels.

* It uses a text-input key in a modal way, when no other unmodified text keys are used modally in a web browser.

* Shifting between modes can happen inexplicitly and unintentionally.

* It's potentially destructive.

Add this all up and you have a recipe for users unintentionally and unexpectedly losing data. That's bad enough on its own.

The fact that the justification for it appears to be "because somebody made a poor UI decision 20 years ago and people don't like change" is inexcusable.

View on HN

The space key is also used modally, to scroll the page down. This creates an issue on some web games and video players: If the game/player element is not focused, and space is pressed (with the intention of pausing/playing the video, or making the game character jump) the page will scroll down.

Some websites, like Github and Facebook also use input keys modally. I'll very often trigger some UI function by mistake when starting to type a message if the text field is not focused for some reason.

The arrow keys also do the same. And scroll is modal in that a scrolling content area gets the scroll first, but when it reaches the end, the parent then gets it (i.e. the page).

The arrow keys are explicitly navigation keys. I specified text input keys for a reason.

I had overlooked space; probably because the behavior is non-destructive.

> "because somebody made a poor UI decision 20 years ago and people don't like change"

And now they did a poor UI decision by making a swipe gesture go back

Which would be ok if it wasn't for the fact that sometimes when scrolling (on anything that has 2 dimensions) you will accidentally swipe back.

I use it all the time in Safari and love it. In Chrome it's less obvious when it is being triggered though.

Yes, in Safari there's a more obvious visual indication.

I suspect that back and forth in Safari may be non-destructive as well (though I can't confirm this right now)

One of the things that makes it easy to swipe back by mistake is the apple trackpad, so I suspect Safari developers are aware of this and added the indication

> I suspect that back and forth in Safari may be non-destructive as well (though I can't confirm this right now)

I just tried swiping back and forth with this text in the Hacker News comment box and it didn't lose the content. I'm pretty sure I've had issues before, I think in relation to pages loaded by POST.

How can you accidentally put a third finger down to swipe back, if you're scrolling with two fingers?

In Chrome on OS X, either two or three fingers will both scroll and change page.

I chuckle when people boldly declare something as poor UX without acknowledging that there could be more than one true way. We have different kinds of computers, different kinds of users, and different preferences. It's subjective.

> Add this all up and you have a recipe for users unintentionally and unexpectedly losing data.

That sounds like a fixable problem, and one worth fixing no matter what your shortcuts are. I hit back and then forward in Firefox, and look, all the text I wrote is still there.

>That sounds like a fixable problem, and one worth fixing no matter what your shortcuts are. I hit back and then forward in Firefox, and look, all the text I wrote is still there.

You're operating under the assumption that a text box is the only form of data that a user can lose by navigating away from a page. It isn't.

Actually the text box was an example of data my browser does store right now.

What form of data is one the browser can have but not keep after you navigate back?

You're very right. The turn signal doubles as the ejector-seat button. This needs fixing.

Reply on news.ycombinator.com