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.
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ā¦
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.
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.
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.
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.
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 . 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.
. 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.