Pressing "Back" on Android messes up navigation

closed

#1

Steps to reproduce

  • Open Dnyalist
  • Open any document with multiple levels
  • Navigate to low levels, like say zoom into an item level 1, then 2, then 3
  • Try editing stuff
  • Click on breadcrumb to go to level 1
  • Press back again
  • Reached back to level 3

Expected result

What do you expect to see after carrying out the steps above?
I expect to see after pressing back, navigation would zoom out of the current level or close the document/app.

Actual result

Instead of the expected result, what happened?
Pressing back currently sends me back to editing level 3, then 2, then 1…following the same order it happened reversely. Logically like how you would navigate backwards in a browser.

Environment

Which operating system are you using? Which browser are you using? If you’re using a desktop or mobile app, what’s the version number of Dynalist?

Android Mobile App version 1.1.13


Additional information

Anything else you think would help our investigation, like a screenshot or a log file? You can drag and drop screenshots to this box. For large amount of text, try putting them into something like Pastebin.

No current screenshot atm.


Additional comments


#2

Sorry, I might have missed something, but I don’t understand why that’s the unexpected result. We did extra work to make sure it works like the back button in a browser…


#3

Oh didn’t know that was intentional behavior. May I ask why though? It seems unefficient. On a browser if you zoom in to multiple levels, you can easily come back out by the breadcrumbs on top and there is no need to actually press the back button.

On Android however,if you zoom up to multiple layers, yes you can use the breadcrumbs on top to go back BUT just say I’m zoomed in, used it to go back one level (1>2>1). I want to close it or go back to start, usually some people close their apps by just hitting the home key (app goes in the background) and some people press back a few times just to reach “home screen” on the application. This way Dyna would go from 1>2>1>home instead of just 1>home.

Edit: just giving an example of how FB had the same issue in their search and fixed it.
Before on FB app, when you search something it left a history. If you to go edit, remove the history and confirmed. It goes to the search without the entry (which is good), but if you hit back, it goes back to reconfirming the entry to be removed…and if you went back again it goes back to the entry still being there. After a while they fixed it, so even if you removed the entry from your search, hitting back shows it not being there.


#4

May I raise the point that this is a somewhat different situation? If that’s the case in Dynalist, we’d consider it to be a bug too. Confirmation dialogues shouldn’t be shown twice since it’s annoying…

I think the analogy should be that in a browser, there’s page A which contains a link to page B, and page B contains a link to page A. If you go from Home > A > B > A and continuously press back, should it go back to B and then A and then Home, or to Home directly?

And yes, I agree that if one wants to close the app, pressing the Home button is the more obvious choice.


#5

The thing is on a browser if you used the breadcrumb links, how often do you press the Back button? Isn’t it easier to navigate via the breadcrumb links or choose a document on the side panel? On an app side of things, I would assume that the user may want to go directly to home skipping the extra steps.

Given your example "Home > A > B > A ", I don’t think the user would like to go back in that exact order “A > B> A > Home” as it seems inefficient if they just wanted to get to the top “Home”.

I mean if this is desired behaviour then this ticket can be closed. I’m new around here and just pointed out what I thought was not the desired behaviour after running a search for anything similar.


#6

I think the disagreement here is that we think we should respect the browsing order without assuming what the user wants to do. So the “back” button in a browser always goes back to the previous page, without cancelling out your browsing history, so to speak (simplifying "Home > A > B > A " to just “Home > A”). Users may have different intentions depending on the situation, and the system should provide consistent outcomes for the same behavior. At least we think so.

Our assumption was that this is the desired behavior, but all assumptions could be wrong. All I can say is that our design intention was to mimic how the back button works in a browser app.

We can post a poll in the Polls category and gather some more opinions for other users, if that’s what you’d like to do.

Let me know!


#7

I know this thread is a few months old…sorry for the way old reply. If that was intended design then it’s working as should be :smiley:. It’s just weird to me as I never used the back button while on Dynalist site as the navigation on the left side is optimal.

This would be nice in case there are others with the issue and not sure what to look for.


#8

The navigation panel on the left is only for documents and bookmarks, so if you’re zooming into an item, the back button would be useful.

It’s all up to personal preference though! :slight_smile: