Go-back button on Galaxy phones...horrible location

[gnelson]

So I’ve always been an Apple guy. However my first customer is required to use Galaxy S7 by their customer, so I got one to be familiar with it.

So far I see a BIG problem with the location of their go-back button. It’s located on the bottom to the right of the home button, well at least that’s what we iOS people know it as. Well I keep accidentally hitting this button going back to the previous page. Then it’s not intuitive to go forward to where I was.

Is there a trick to prevent this behavior? I see many many problems caused by this. IMO this is a horrible design.

Thanks for any advice anyone can give me.

Thanks

[fayewatson]

Hi @gnelson I’m in a similar boat! One way, which may or may not work with your app’s setup/workflows, is when a group is hidden and a different group is shown (though the User stays on the same page), set the last workflow to be a ‘go to page’ action (to the page they’re already on) with an additional parameter.

For example, if the User just opened the app and is on the index page, the URL is www.website.com.

Then the User clicks the “Material Request Button”. Keep all of the actions you already have for that button, but add the Go to Page action as the last step in the workflow, with the setup as:
Go to page: Index
Click to Add Parameter
p = material_request

This changes the url to: www.website.com?p=material_request

This way, if the User is viewing the material_request group and hits the back button, they’re taken from www.website.com?p=material_request to www.website.com

I haven’t tested this with all actions, but it seems to work even with custom states. The custom state values aren’t refreshed with the go-to-page action, I believe because the page isn’t reloaded when the User is navigated to the page they’re already on. Feel free to let me know if it gives you trouble or if you need any help setting this up

[gnelson]

WOW! Thanks Faye! I’ll give that a try. I hadn’t even thought about custom state values. That makes the situation even worse. Your instructions are clear. I’ll try it and report back.

[fayewatson]

My pleasure! I should say it’s not required to have a custom state to change which elements are visible, but I thought you might have them in there already if you have many groups on a page. A few different ways to set this up

[scottb50]

@fayewatson to the rescue once again!

As described:

To make sure the refresh behaves as you want, add an action to When Page is loaded that looks for the var and sets the state appropriately.

Above, “stage” is the name of the state that governs when groups are visible. ~SESSIONVARS is a blank group that holds all the page states.

Thanks Faye!

[fayewatson]

Thank YOU, @scottb50!! Excellent instructions!!