Back Button On Modals

[Ben]

Modals need a native button when they are opened from another modal. Modals only have a closeout (X) button, which is insufficient because users expect to see the previous modal when the last modal is closed. For instance, when a user opens a modal that contains a linked list, then opens one of the linked-list items in another modal, they can’t go back to the previous modal with the linked list.

[matthieu_chateau]

I agree,

This can be done with custom code but still a basic and important feature to have for clean UX.

[Ben]

I had the same logic @matthieu_chateau, so I brought it up in a chat with Andranik, then in another community post, but unfortunately have had no action taken since early January .

Modal Opening A New Tab

Hi @Viktoria. When a modal opens another modal, the rendered modal on top closes out all modals when it is closed, sending the user back to the parent list instead of rendering the previous modal. When modals are stacked like this, users expect to see the previous modal when the current modal is closed. Can we have this latter modal behavior deployed by default, instead of them all closing together? It would work better for users and complete the user journey when an item is selected from a …

When you consider the user journey, this is not really a new feature request. This should have already been deployed as basic modal behavior.

[Ben]

Unfortunately, I have to revisit this again. Modal behaviour has been neglected. Modals opened within modals still need a back button or the x must only close the last modal opened, instead of all modals which is the current behavior.

Also, the conditional forms within modals have even less user friendly behaviour. Actions after submitting these forms open up pages within the modal instead of closing it out and opening in the existing tab.

I brought this issue up in the chat six months ago, with no resolution as of yet

[Q8T]

I strongly agree with the need for modal navigation, specifically the ability to clearly allow users to go back

[Ben]

Revisiting this yet again since items opened in a modal from linked lists in a modal all close out instead of going back to the previous modal’s linked list.

[matthew-gsdsolo]

I’m interested in this as well. From a UX perspective, the ability to go back to a previous model instead of having to start again is far easier.

Is this on the roadmap, or even in the backlog?

[Inigolv]

Upvoting this. It’s a big feature users ask and one of the most annoying things of downloading a PWA since you don’t have the back and forth arrows of your browser

[dhruv]

@Ben , @matthieu_chateau Good news.

We’ve just started working on this, thanks for your feedback

The current state of modals is not something which we were happy with, it was just a matter of prioritizing it.

We’ve already implemented a POC which makes the browser back button work as expected (it will take you to the previously open modal if there’s one, otherwise it will close it). Additionally, closing the modal after many navigations using the close button will jump back in history to the point where you first opened it. This will remove the need to click back several times if you’ve navigated within the modal a few times.

I did, however want to gather some feedback related to this as we already have some disagreements within the team as to how it should behave

A few key things we wanted to know

1. Would you expect the browser back button to work or would you use a dedicated back button in the modal header (or both)?

2. Do you expect a single modal on the page which changes its contents when you click links or would you want the whole “stack” of modals to be placed on top of each other?

[jkasman]

Jumping in to voice my opinion because I’m also very interested in this feature (not sure the proper etiquette here… hope this is okay)

1. I would think that the browser back button would take me to the previous page whereas a dedicated back button in the modal header would take me to a previous modal
2. I would be interested in a “stack”. So like first modal slides on, second modal slides on top of that. (Maybe would be cool to be able to see the edges of previous modals as a UI reminder that there is more underneath it, like a real stack of cards)

[Ben]

Better late than never @dhruv.

1. A dedicated AND LARGE back button on the modal header would work better than using the browser back button. Previous versions’ X buttons were too small.
2. A stack of models is preferable. It would remind the user that an item on a surfaced modal relates to the linked list under it. The main objective is for a user to go back and forth between items on a linked list that is on a modal. So in this scenario there would be 2 modals stacked on top of an initial list. The first modal would contain an item details block, from the original list, with a linked list block under it. The second modal, on the top of the stack, would contain item details for the items on the linked list from the 1st modal. Essentially, a back button on modals would enable a user to browse between items on a linked list, if that linked list happens to be on a modal.
3. Another option would be to simply have the closeout X button only close the modal on the top of the stack, with all previous modals remaining underneath. Before, they would all closeout, so if there was a stack of modals, you couldn’t browse linked lists on modals.
4. Either of options 2 or 3 would work as long as the content remains the same AND in the same position on the modals when they are stacked. This way when a modal is closed out, the user recognizes the content from the modal that was under it. A mobile first approach would be ideal for something like this. I hope that wasn’t too hard to follow. Thanks for following up!

[matthieu_chateau]

Hey @dhruv ,
Great news.

1. Would you expect the browser back button to work or would you use a dedicated back button in the modal header (or both) => BOTH. You have no idea how many users switch off their brain inside a business application when trying to find the “go back” button, even though they could just use the browser’s back button instead. As a Softr expert, I’ve seen this behavior so many times. Though, obviously, I expect the browser back button to behave like the button in the modal header (I’m reversing the assumption, as I think the “go back” button in the header is the primary use case).
   By the way, what I wrote above is exactly the same outside modals

2. A stack of modals can make it easier to navigate between screens.
   Though I would say the best option would be a global setting for the app like: please choose between “Stack of Modals” or “Single Page Modals” for the behaviour of the multi-page modals of your application. But for end-users navigation clarity/expectation => stack of modals is the #1 choice.
   For example, Airtable uses a stack-of-modals feature in its record details, and users seem very happy with it. It’s clear to them how to navigate.

[RonanG]

Hey @dhruv – adding another voice for stacked approach. That would be the same as how it works in Airtable, and it is very intuitive for people to re-trace their path. It feels like a pleasing approach. I agree with @jkasman that seeing the edges of previous modals could be a good idea too.