Change back button action?

[Tamara_Didenko]

Not sure if this is possible, but thought I’d ask!

The behavior of the default “Back” button in Glide currently doesn’t really make sense to me. Currently, it behaves exactly like the “Back” button in the browser, but as far as I know, from interacting with other apps out there (iOS and Android alike), the “Back” button at the top of the screen is supposed to take you to the previous screen in the hierarchy, not just the last screen you’ve seen. The current behavior works fine as long as you don’t get fancy with your detail screens, but for my app, I wanted to (and was able to) implement “Prev/Next” functionality on detail screens. This is super helpful, except that it breaks as soon as somebody taps the “Back” button to go up a level in the hierarchy. I’m wondering if it’s possible to assign a different action to the “Back button”?

Current behavior

To illustrate, here’s what’s happening now (I’d love to also fix transitions to “Previous” screen, but let’s focus on one thing at a time ):

The “Back” button simply acts the same as the browser “back” button, taking you to the previous screen you’ve just been on.

---

Workaround

I was able to enable what I wanted with a separate button at the bottom of the screen by assigning “Open new Detail screen” => related table row. This solves the initial problem, but now the user has to go through all the “Back” motions to get to the “Home” screen, which is also not good.

)

---

Desired behavior

Here’s what I want to happen: no matter which “child” screen you’re on, the “Back” button should always take you to the “parent screen.”

Would love to hear your thoughts on how to achieve this!

Thank you!

[Eric_Penn]

First of all what a beautiful illustration of your problem and workaround. Unfortunately we can not change the back button action… but we can hide it.

Try this inside a rich text component

Hide back button label

[image] Please try this. <pre><span><style> [data-test="back-button"] >div { display: none; }

I hope this answers your question

[Tamara_Didenko]

@Eric_Penn

but we can hide it.

Yes, I found that solution, but, unfortunately, it’s not a good idea. At that point, the workaround becomes completely unusable as there’s no way for the user to go back to the Home screen at all

Also tried the “go to tab” action there but since the user technically never leaves the “Home” tab, it doesn’t work either…

@Eric_Penn

Unfortunately we can not change the back button action…

Okay, maybe there’s some other way to enable this behavior I truly believe that this “back” button currently works against all established UX frameworks, but I think suggesting changing it as a Feature request feels a bit strong. So… Looking for solutions!

@Eric_Penn

Alternatively you could use a Custom Form

Will read!

[Eric_Penn]

Whoops I didn’t mean custom form I meant show new screen… What if back to pattern home was a show new screen

[Darren_Murphy]

@Tamara_Didenko

Yes, I found that solution, but, unfortunately, it’s not a good idea. At that point, the workaround becomes completely unusable as there’s no way for the user to go back to the Home screen at all

A bit kludgy, but what you could do at that point is add a floating “Home” button that just does a bunch of “Go Back” actions.

But hiding the back button is generally not a good idea, and often you’ll find that in “fixing” one problem you’ll create 2 or 3 more.

Regarding your larger challenge, I don’t have any bright ideas off the top of my head, but I’ll think on it.

[ThinhDinh]

I don’t want to be that crazy user, but if I click somewhat like 100 levels deep then you won’t have enough Go Backs to defeat me

I think, and have always wanted this to be a thing: the go to tab action can act dynamically, either:

• Go to wherever you left at, saying you’re 100 levels deep then when you go to that tab you’re 100 levels deep.

• Go to the parent screen.

[Robert_Petitto]

Yeah…I’ve always wanted an action ties to the Back button (Go back and clear, go back and navigate, go back and increment, etc).

@mark and I were discussing this a few months ago…nothing really came of it though.

[Tamara_Didenko]

@Eric_Penn

Whoops I didn’t mean custom form I meant show new screen… What if back to pattern home was a show new screen

This. is how my workaround works This custom form stuff is interesting. I think there might be an application here…

@ThinhDinh

I think, and have always wanted this to be a thing: the go to tab action can act dynamically, either:

• Go to wherever you left at, saying you’re 100 levels deep then when you go to that tab you’re 100 levels deep.
• Go to the parent screen.

Yeah, the Human Interface Guidelines say:

A navigation bar appears at the top of an app screen, below the status bar, and enables navigation through a series of hierarchical screens.

Granted, it doesn’t say explicitly that it should go to the parent screen, but I swear to all that’s holy that’s what it should do

Sort of curious, is the current behavior (going to the previous screen) a limitation of technology somehow or an intentional decision? It also seems that this wasn’t always the case?

@Daniel_Canup

Can a button link back to a previous page? As if the user is pressing/tapping the back button? Or to the next list item from a previous page?

[Robert_Petitto]

@Tamara_Didenko

Sort of curious, is the current behavior (going to the previous screen) a limitation of technology somehow or an intentional decision? It also seems that this wasn’t always the case?

It’s always been the case.

[Tamara_Didenko]

okay, some updates!!!

Custom forms mentioned above didn’t quite work for me. But looking around the community I found this gem and that got me thinking: swipe would be so much cooler than a text-only page, so I decided to give it a try.

@Lucas_Pires

swipeit.glideapp.io

Swipe.it

I wasn’t able to make Swipe work I set up everything 1:1 to what Lucas had in his example, but for whatever reason, Glide is just not giving me an option to select the “Swipe” layout. No idea why

That said, I was able to make my desired functionality work: users can go back and forward in rows without leaving the Detail screen for any specific row, and the “Back” button takes you back to the parent screen.

Have to work right not, but I’ll try to outline how I did it later today.

Of course, as it happens, you figure out a solution to one problem, you immediately encounter another My original screens had some interactivity related to it:

• Mark as complete
• Add notes.

I would love some ideas on how to bring this functionality to new screens as those are exactly the features my users loved as opposed to the navigation issue I fixed there that was mostly just annoying

[ThinhDinh]

@Tamara_Didenko

Glide is just not giving me an option to select the “Swipe” layout.

I think you can only select it at the parent level of a tab, it’s not available as an inline list.

[Tamara_Didenko]

@ThinhDinh

I think you can only select it at the parent level of a tab, it’s not available as an inline list.

Right, it’s not showing up though. When I’m on the parent level of a tab, my selection area is completely empty

As far as I can tell, it gives me a Swipe option when I set a destination to a column that has a list of items behind it. Because it’s pointing to a single row right now, it’s not giving me the Swipe option? But as far as I can tell, Swipe.io from the post above has the same setup and works

[ThinhDinh]

I see the “Details” text is bold, are you on a details view? If you click “Home”, it should take you to the parent view and I think you can select swipe from there.

[Tamara_Didenko]

It just takes me to home screen.

But I don’t need Swipe on the Home screen That view is set up to something else. Here’s a gif of what’s happening right now. Don’t mind the floating button galore, this is just to try few different things without disrupting the user’s workflow.

Two buttons I’m showing here are pointing to different relations.

1. () points to the “working row” table, with the same setup as swipe.io I linked above. In Swipe.io, they are able to select a Swipe layout, and I’m not. I’m guessing it might have something to do with an extra layer of hierarchy I have?
2. (⬟) points to a multiple relation row.

[ThinhDinh]

I’m not familiar with Swipe.io, but what I’m trying to say here is:

• You can only use the Swipe layout on a non-details view layout.
• At your parent level you’re using a details view layout, so there’s no option to use Swipe.

[Tamara_Didenko]

Is this app not using a details view layout?

[ThinhDinh]

The inline list is navigating to a new list itself, not a details view, that’s where your problem lies I think.

[christoph]

Maybe this is of some help.
What I do in situations when my users are coming to a screen from different directions and I want them to go back where they came from (or I want them to go to).
In all sheets of such screens I have a user specific column with the name Screen_Origin. In the action which opens that screen I’ll write a value into this ‘variable’. On these screens I’m using floating back buttons with an action to go back to the right ‘home’ screen depending on that variable and then also clearing the variable.

[Tamara_Didenko]

Thank you, @christoph. Yes, I’ve done a similar thing in my “workaround.” It works well when you only have 2 levels of hierarchy (Home > relationList), but I have 3 and if the user wants to get home from the second layer, they once again have to go through a bunch of “Back” actions.

@ThinhDinh

The inline list is navigating to a new list itself, not a details view, that’s where your problem lies I think.

That’s certainly been my experience. If I point my action button to a column with multiple related rows, it loads swipe just fine. Except that I lose an option to swipe back and forth by using the “increment” action.

However, in the original app (Swipe.io), which I copied to the T, that inline list also points to a relation to a table that ONLY HAS ONE ROW. So, two identical setups, but for Swipe.io there’s an option to do the Swipe, and for mine, it doesn’t appear so =(

---

Here’s the setup. I tried to remove ids of columns that are not related to the problem at hand, but there are def a few more in here, so I can explain further if needed. So, I have 3 tables:

1. Patterns, which contains various metadata related to each pattern, as well as some process calculations and relations to other tables.
2. Pattern Instructions, which contains row-by-row instructions for each pattern.
3. workingRow, this is a dynamic table that is related to Patterns and Pattern instructions. I send values here from Patterns using actions, and it looks up relevant columns.
   
   

The diagram above might be hard to follow, but I’m hoping it’ll work in addition to this explanation:

1. From the Home page, the user selects one of the Inline List items. At this point, this is a standard “Open Detail screen for this item” action.
2. On the Pattern home page, the user can either click one of the rows or use a floating button to open the next to-do row. Both are handled through a similar custom action, I’m only showing the floating button action here:
   • Clears values in [workingRow] table
   • Sets values in [workingRow] table
     • [Patterns] Name >>> [workingRow] Pattern
     • [Patterns] lookupNexttodo_UID >>> [workingRow] incr_Row
   • Open New Screen from [workingRow] (there’s only one row that’s related to [Patterns] table
3. Once the values in [workingRow] were set by action, the table itself does a few things:
   a. Combines Pattern and incr_Row values to get a tempCurrentRowID (template field)
   b. Finds a row with matching currentRowID in [Pattern Instructions] table
   c. Brings values of [Pattern instructions] Name, Instructions, and few other Text and Number columns into [workingRow]

So at the end of all this trickery, my [workingRow] table looks like this:

And with the “Increment” action on Prev/Next, I can achieve this result, which resolves my initial question.

Now the “Back” button works as expected, leading to the parent level. Users can also navigate between the previous and next screens.

There are, however, tradeoffs:

• I wasn’t able to figure out how to bring the “Completed” boolean operation to this final screen and make it work too. I can update values in my [Pattern instructions] table with an action of any other element, but standard Switch doesn’t work. The switch is, of course, clearer from a UX perspective, but I can figure out how to make other elements give the same signals to users with other elements.
• I will need to rethink how users could add Notes to these patterns now that they are not attached directly to this screen. I’m thinking there’s probably going to be some sort of an inline list loading notes from a separate table. Not the end of the world, although somewhat annoying =)

---

Thank you for everyone’s help! If there are any ideas on how to address the above tradeoffs, I’d love to hear it!

[Wiz.Wazeer]

Please try this. Just keep pressing the floating button. This is a simplified version of your work. I avoided relations for your example to see how it might help. For the swipe version, I used a relation but did a slight detour on swipeIt.

I try to get round the hierarchy by locking and unlocking the listed items. It’s not perfect, but im sure you and others will be able to improve on it.

Floating list navigation