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.
I agree,
This can be done with custom code but still a basic and important feature to have for clean UX.
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
.
When you consider the user journey, this is not really a new feature request. This should have already been deployed as basic modal behavior.
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 ![]()
I strongly agree with the need for modal navigation, specifically the ability to clearly allow users to go back
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.
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?
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
@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
-
Would you expect the browser back button to work or would you use a dedicated back button in the modal header (or both)?
-
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?
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)
- 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
- 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)
Better late than never @dhruv.
- 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.
- 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.
- 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.
- 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!
Hey @dhruv ,
Great news.
-
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 -
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.
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.
Hey everyone, we’ve just released an update which makes the modals play nice with the browser back button.
We’ve also added a “Back button” at the top left of the modal header which appears when you click a link within a modal that navigates to another modal.
No stacked modals for now, unfortunately, we still have to iron out the UX there, especially since it’s something that the builders might want to configure it. We’ve added to the roadmap for now.
EDIT:
Please note that you might have to wait for the browser cache to expire before you start to see this. In the meantime, you can “Hard reload” once to force clear the cache.
Another caveat is that if you’ve not opened the studio in a while, you might have to do that for the page which opens the modal for the first time. This will auto update the block to the latest version, which supports this fix
Great progress. Do you have a video guide on how this works? Not had a chance to try it out yet
Just tested this and it’s great! Also noticed the new modal expander which is awesome. Thanks ![]()
@dhruv, Thanks for your candid feedback. Love it!
-
I’d like the modals to have a dedicated back button in the header. I believe this is much more intuitive than the browser back button. With that said, the browser back button should work as well. If you have to choose one or the other I’d pick a back button in the modal. IN ADDITION: it would be great to have Next and Previous buttons when viewing a modal from a table or list block, so we can quickly navigate records.
-
Single Modal! When I recently saw the new modals opening multiple modals over each other, I was going to submit a support ticket as I thought it was broken. Multiple modal windows opening on top of each other is crazy. It’s a poor user experience. One modal should be open at a time with the option to reveal the previous modal when one modal is closed.
Thanks!
@dhruv. Modal Back Buttons show up randomly and close out all modals when they render. I “Hard reloaded” stacked modals with the browser and modal back button, as you suggested, with the same effect. Can Softr just get this right so builders don’t have to waste time configuring and performing QC on new features that don’t work please?
@Ben that sounds like a bug. Could you add support@softr.io as a collaborator so I could investigate?
@TobyMacLeod thanks for the constructive feedback
I’d like the modals to have a dedicated back button in the header. I believe this is much more intuitive than the browser back button.
This should already be enabled. If it’s not, could you add support@softr.io as a collaborator for your app and share your app’s studio link here so that I could check why it’s not appearing?
it would be great to have Next and Previous buttons when viewing a modal from a table or list block, so we can quickly navigate records.
Sounds like a useful feature. I’ll forward this to our product team to see if they can prioritize this ![]()
Single Modal! When I recently saw the new modals opening multiple modals over each other, I was going to submit a support ticket as I thought it was broken. Multiple modal windows opening on top of each other is crazy. It’s a poor user experience. One modal should be open at a time with the option to reveal the previous modal when one modal is closed.
The “Open link in modal” actions should already work like this. Are you perhaps referring to “Edit record”/”Add record” modals? If this isn’t the case, again, share your app with support + share a link here so that I can investigate.