Change back button action?

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 :thinking:

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

Okay, maybe there’s some other way to enable this behavior :rofl: 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!

Will read!

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

1 Like

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.

1 Like

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 :sweat_smile:

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.

2 Likes

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.

2 Likes

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

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 :rofl:

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.

1 Like

okay, some updates!!! :upside_down_face:

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.

I wasn’t able to make Swipe work :rofl: 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 :thinking:

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. :fire: :star_struck:
CleanShot 2022-01-19 at 12.12.03
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 :rofl: 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 :rofl:

1 Like

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 :thinking:

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 :sleepy:

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.

It just takes me to home screen.

But I don’t need Swipe on the Home screen :rofl: 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.
CleanShot 2022-01-20 at 12.27.51

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

  1. (:zap:) 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.
1 Like

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.
1 Like

Is this app not using a details view layout?
CleanShot 2022-01-20 at 19.18.42

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

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.

3 Likes

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.

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.
CleanShot 2022-01-21 at 15.41.37

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!

4 Likes

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.

1 Like

Thank you, some great ideas here!
I’m not in love with jumping between row details and the list, but I like the simplicity of your solution, and that it requires fewer columns than mine :rofl:

For the Swipe version though, it doesn’t allow you to go to the previous item. Although the happy path for my users is definitely “forward,” they also need to reference previous items frequently.

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.