AppFlowy
AppFlowy copied to clipboard
AppFlowy-IO
[FR] Remember the position of the previous viewed page
Description
It would be useful if the current position of a scrolled page would be saved when changing pages so that I don't have to scroll from top to bottom when I come back to the previous page. Especially with long pages this would be a great advantage
Impact
Users who switch across pages to work on a project or write a document
Additional Context
No response
I'm not sure if we need this. With tabs, you can now just open two tabs and the scroll persists unless you change the view in that tab.
This should be fine for now, right @annieappflowy ?
While I think tabs does improve the experience, I still think this is still a feature that's nice to have for those who don't use tabs
From my perspective it's a bit weird, I have never seen this in an application before.
I believe this request came from a lack of organisational features, however the proposed solution defies the norm and can lead to confusing UX.
I feel the core of this request depends on what is the user's intention when leaving a page. When a user chooses to leave a page, they may fall into one of the following scenarios.
- Scenario 1: The user has completed their tasks on the current page. They want to open a new page and close the previous one. In this case, the user expects every page to open from the beginning.
- Scenario 2: The user has not completed their tasks on the current page. Becuase they can only view one page at a time(at least for 0.3.1 version), they has to open a new page to access different content. In this case, they want to back to their previous location to continue from where they left off. This occurs because their initial tasks on the first page remain unfinished.
When contemplating whether to display a page from the last viewed position, we must consider which scenario it caters to: For the users who have completed their tasks (Scenario 1) or the users who have unfinished work (Scenario 2).
It is important not to mix these two scenarios. Additionally in Case 2, it is essientail to include a close button that allows users to confirm the completion of their tasks
From my perspective, in the recent 0.3.1 version:
- The normal way to open a new page from clicking the title in the sidebar is to serve Scenario 1.
- The Tabbar view mode is to serve Scenario 2.
In the future, when considering the implementation of a new page view mode (#2312), we can utilize this approach to determine whether it's necessary to show the last viewed location.
I feel the core of this request depends on what is the user's intention when leaving a page.
When a user chooses to leave a page, they may fall into one of the following scenarios.
Scenario 1: The user has completed their tasks on the current page. They want to open a new page and close the previous one. In this case, the user expects every page to open from the beginning.
Scenario 2: The user has not completed their tasks on the current page. Becuase they can only view one page at a time(at least for 0.3.1 version), they has to open a new page to access different content. In this case, they want to back to their previous location to continue from where they left off. This occurs because their initial tasks on the first page remain unfinished.
When contemplating whether to display a page from the last viewed position, we must consider which scenario it caters to: For the users who have completed their tasks (Scenario 1) or the users who have unfinished work (Scenario 2).
It is important not to mix these two scenarios. Additionally in Case 2, it is essientail to include a close button that allows users to confirm the completion of their tasks
From my perspective, in the recent 0.3.1 version:
The normal way to open a new page from clicking the title in the sidebar is to serve Scenario 1.
The Tabbar view mode is to serve Scenario 2.
In the future, when considering the implementation of a new page view mode (#2312), we can utilize this approach to determine whether it's necessary to show the last viewed location.
I agree.
One of the reasons I was partly against this request, is because I primarily experience scenario 1, and it would frustrate me. Considering I come back to a document which might have been closed for long, and end up in a previously scrolled to position, not to mention that this position might have become outdated, as the document content could have been modified since my last visit. (By someone else or myself on another device)
Users are already trained for handling scenario 2, as this is how most editors, and all web browsers work.
@Xazin Totally understandable, I also feel creating a distinct UX experience for these two scenarios is important too so that users won't get confused by its purpose. For example, for scenario 2, no matter whether the page view is a tab, panel, or other type of window, we can consider always putting page titles on the top of the page(like a web browser style). For scenario 1, put titles on the left side instead.
I'd like to add my use case here as I asked for the same feature.
My reasoning behind using this feature is that I have a long document with sections that I will come back to work on in multiple occasions and looking for where I last was could be frustrating because it either may have been a long time ago so I forgot, or the document is just big.
For those that don't want this behavior, we could just not preserve the location of the cursor if it's at the end of the document, or just have a switch in settings to not use it at all.
Tabs aren't a complete replacement for this because they will lose scroll position after the app is reopened.
It is important not to mix these two scenarios. Additionally in Case 2, it is essientail to include a close button that allows users to confirm the completion of their tasks
From my perspective, in the recent 0.3.1 version:
The normal way to open a new page from clicking the title in the sidebar is to serve Scenario 1. The Tabbar view mode is to serve Scenario 2.
What I think would also work is adding a special attribute to a node, through an option in the existing node menu. So then you could just label a document node in a page and the page will open at that position. If there's more of these special nodes then you'd open at the last one that was created.
By node menu I mean this
