Proposal: Back button behavior

[jmckible]

This proposal is targeted at Back buttons like this one:

In the case we are navigating back to a paginated index page, the current method signature is not ideal. Rails has a built in :back option which can be used by link_to when the referrer is available. For the majority of navigation, this would allow us to easily link back to a deep pagination, rather than the first page of results.

The proposal here is to imply this behavior with our Back button element. However, we must enforce some defensive programming. In the case that no referrer is present, Rails will just output a javascript redirect to the previous page in the browser history - potentially off our site entirely. As such, the current url option will function as a fallback in the case a referrer is not available.

The other edge case is exemplified by the open/close behavior of Feedback in Engage. When updating or commenting on a feedback, we redirect back to the same show page. In this case, the Rails :back behavior would link right back to the page. Not good! To work around this, we'll check that the referrer is not the same as the current url. If is it, use the fallback url.

Finally, in the case where we want to bypass the implied behavior entirely, allow for a force: true option to override.

[jmckible]

Just realized this doesn't handle the case of an external domain referrer. Will add that...

[jonwolfe]

Hey Jordan, can you tell me more about the page this is needed on? I think that cases where we find ourselves wanting a button in the UI to go to the previous page in the browser history (rather than a specific URL) are usually a navigation smell -- even though I know it's been necessary in things I've designed. It usually happens when you have a page people navigate to by multiple paths. In the future we are thinking we can usually solve this with things like the slide-out panel on the right side of the screen.

Many of the cases I can think of where we would use an element like this in the UI, you would really not want to just go back to whatever the referring page is, but always go to a particular URL. For example, the sub-pages in CX Settings. The back button (perhaps misnamed) literally says "Settings".

So, I'm not against having an option to link back to the referring URL. I just think it should probably not be the default.

Another way to go would be separate method names for when you want to link the user to "back" vs a higher level in the hierarchy.

Thoughts, @sagoldschmidt ?

[jmckible]

Here's a typical flow for Engage:

1. Start on a feedback index page
2. Go to page 2
3. Click on piece of feedback
4. Look at the page, possibly make some changes
5. Click Back button. Would expect to be on page 2 to easily continue processing through feedback.

Similar use case on the Team page (eg navigate through a list of employees and make some changes)

So there aren't multiple paths to the page, but rather the notion of keep track of where you where in a list. Both of these would be resolved by a slide out panel.

[jonwolfe]

Sorry for the delay in responding. Agreed that a slide out panel would solve for the above use cases, but cases like the above will always exist. As will cases where you have a link in that location on the page that you want to always go to a specific location. I don't really know which case will be most common, but as long as they are both possible, I'm cool with this. If you change the default behavior, it's something we would want to make sure people know when upgrading to this Pano version.

[jmckible]

Closing this pending big changes in v4.0