combine "forward" and "next page" buttons

[Danielle Foré]

in the current back/forward set, the forward button is almost always insensitive. In other words, most of the time it's wasted space. In the case where it is sensitive and there are also pages present, it's pretty safe to assume that "forward" also means "next page"

In this way, *only* when "forward" is insensitive it should inherit the behavior of "next page" as kind of a predictive history ;)

[Grzegorz G. (grzesiek1e5)]

Or do as Mozilla did: remove "next page" and show "forward" only if there is anything to forward to.

[Nichita Uțiu (nikita.utiu)]

I agree with Gregorz G., the forward button is pretty much superflouous if you are at the top of the stack of pages and that is more often than not the case. Also being practically an "undo" for back, hidinig it by default seems the most sensible solution.

[Cris Dywan (kalikiana)]

I made the Forward button hide when it's insensitive, so you will only see Next most of the time.

[gue5t gue5t (gue5t)]

Why is forward special? It's inconsistent to hide forward when the user is unable to go forward without doing the same for *at least* back, and hiding any toolbar buttons based on what actions are currently possible seems to conflate visibility and sensitivity. If a user is clicking forward multiple times to try to reach the front of the back-forward list, there's a pretty good chance they'll make a click after forward becomes insensitive, doing something they didn't intend. Keeping the principle of least astonishment in mind, I think it's a good idea to encourage users to have a clear mental model of what the difference between previous/next and back/forward is; if they don't understand the difference they'll be confused when both forward and next buttons are present and when the one present button doesn't do what they expect. Even for power users I doubt there's an expectation for forward to appear and disappear or for the other buttons in the toolbar to move around solely as a result of going back/forward. For less experienced users it may be even more frustrating to not be able to find the forward button when looking for it, whereas having it present and insensitive provides a clear visual cue that has a long history in UI design and should be familiar to users of many systems.

I'm all for making UI improvements, but making unguided special-case changes without a clear usage case doesn't make sense. "Copying Mozilla" is not an effective design strategy.

[Danielle Foré (danrabbit)]

I have to agree with gue5t. The original intent of this bug report was to make the forward button more useful by making it sensitive more often, not to create a jumpy UI

[Cris Dywan (kalikiana)]

The way I see it, Forward + Next is much like Stop + Reload. Most of the time, only one of them is actually useful. Forward is most of the time meaningless. This is very different to Back: It is sensitive as soon as you click any link, even if you open a new tab.

I'm not sure why you say jumpy. The reason why I didn't create a combined ForwardNext is that it's in some cases ambiguous. But maybe we should do that to make it easier?

Btw I personally have no idea what Mozilla is supposedly doing, I'm not aware that it has this feature at all - I know Opera has it as a separate button like Midori does. I was going by the comments on this bug, which seem to suggest that Back is rarely useful, which I agree with.
Please be less vague and I'm happy to experiment with other solutions.

[Cris Dywan (kalikiana)]

I exchanged the changing visibility with a merged NextForward button much like StopReload. The separate buttons remain available in the toolbar editor and in the form of hotkeys.