Hacker News new | ask | show | jobs
by n3k5 1843 days ago
> Even the back button is wrong in the new version. Previously it spanned up to the left edge of the window.

When you actually try it instead of comparing screenshots, you'll see that its clickable area still goes all the way to the edge of the window. The button hasn't moved to the right; there's just more negative space because they removed the circle around it. Deleting that space would actually move the button to the left and make it more difficult to hit. As it is, it's as easy to hit as ever, and the “empty space” isn't there “for no reason”. (Moving it closer to the edge would actually be a mistake; there needs to be some margin for situations where pointing close to the edge changes the cursor's function to resizing the window.)

> lacks immediate feedback

How so? As soon as the mouse pointer touches the clickable area, the button lights up; after a second of hovering, I get a tool-tip explaining what it does, what the keyboard shortcut is, and how I can use it to show the tab's history. Again, that seems the same as it used to be?

1 comments

After I move the mouse over the back "button" at first nothing happens, it's surely nothing happening "as soon as the pointer" enters the area.

Then after some delay, the "area" of the button is shown, but not inclunding the newly "empty" space, which you claim is clickable.

But what is highlighted starts to the right. If my mouse is already close to the edge, it visually signals that it's not over the button, that is, that I moved the mouse too far.

It's very awful experience: not having the limits of the button drawn (which doesn't give me any hint of the area I can target), then not showing the limits fast enough once the pointer is there, then misleading about the limits (forcing me to move the mouse to the right even if I was already on the right place), drawing with the thinner line the arrow (also making it less obvious where it is): four wrongs in just one enforced update which is claimed to "improve" UI. On the most used button.

That sounds like a "you" issue, not an "everyone" issue. You may have a corrupted settings. You can reset them (and customize the toolbar to your liking) by going to the hamburger menu and selecting More Tools --> Customize Toolbar.
Hmm, it seems like what I've observed (I only tried MacOS so far) is what's supposed to happen, and what you got is bugged; hopefully they'll fix that soon.

In the case when the button does light up the instant it becomes clickable, I don't get the perception of ‘I've moved the mouse too far’ — instead, it's easier to see why the highlight isn't bigger: I don't just get a “hint of the area I can target”, I see exactly a standard-sized button, which I'm aiming for — but when I miss a bit, there's also a bonus area where the click still works.

Without the immediate feedback, the highlight seems ‘off’ (in the sense of displaced) in some arbitrary way. But really it's way more sophisticated (an overly pedantically detailed elaboration follows; I promise this is not apologetics on behalf of the Firefox UI designers, but illustrating a point I will attempt to make in the end and that I couldn't be bothered to put in fewer paragraphs out of sheer laziness):

1) There's a bonus area to the left. It's nice to have when you happened to click a bit too far to the left. But how far off you can be in that direction depends on the exact circumstances: E.g. in my case, in windowed mode I can approach the edge to within 1 or 2 px before the mouse cursor switches to ‘resize window’, whereas in fullscreen mode, I can go to 0 px, but pushing beyond that triggers the dock which otherwise lingers beyond that edge of the screen. So that's why it's a bonus area: It'll try to do the right thing, but it's not a promise that clicking there will work. And by directing your focus to the standard-sized button that would ordinarily be all you can click, it's more likely that you'll hit the intended target.

2) There's no bonus area to the right. Because the forward button is to the right. Instead of extending the standard-sized click target, hoping that this is what you meant to do, the GUI refuses to interpret your click as something that could be the exact opposite of what you meant to do.

3) There's a bonus area upwards. On MacOS, moving up even farther gets you to the buttons for closing and minimising the window, but they're a good few px away from the bottom of the title/tab bar, so we can approach that border all the way without risking a wrong click.

4) There's no bonus area downwards. Because that's where the web page you're viewing is, and making the top left corner of the page a link (e.g. to the home page of the site) is really common, so ignoring ambiguous clicks wins out over risking doing something you didn't want.

Thank you for your attention — you made it to the end where I attempt to make a point: AFAICT, the click target is the exact same it has always been. I understand that it can be annoying that they removed the circle when you're used to the circle being there; but I assure you, the circle never was the actual clickable area — it was just the visual target you were aiming for. You want ”the limits of the button drawn”? The circle doesn't do that. The button is a rectangle, and the clickable area is another rectangle that is almost the same, but a bit more generous in exactly those cases where the extra leeway can't do any harm.

> Wait, It's All Ohio? Always Has Been refers to an exploitable template in which two astronauts are in space. One looks at Earth and realizes the entire Earth is made up of something other than what is expected, and asks "Wait, it's all X?" The other astronaut, preparing a gun, says "Always has been."

https://knowyourmeme.com/memes/wait-its-all-ohio-always-has-...

That was a long text claiming the opposite of what is clearly visible and repeatable:

https://postimg.cc/ThCLM7mK

The button area is visible as soon as one hovers with the mouse over the button.

Above: when the new code is turned on.

Below: when the new code is turned off.

The problem is: the area covered on hover should match the clickable area. If left of the button can't be clicked, the button is wrongly positioned. If it is intentionally bigger, the visual feedback should match it. The new code doesn't do that.