Go back in browser is not captured.

[kaidatavis]

option 1: add another page as a new node in the historymap option 2: go back to the parent node (not adding a new node and change the 'visible page') and then add new page from there.

[Yuu-Han]

Are the options to be decided by the user? For example, there is a default setting but users can go back to the tree to change the option for specific nodes?

[kaidatavis]

It will be nice if user can choose between 1) adding the 'go back' as a new node or 2) just pointing to the previous node. Currently in the latest commit in mv3 adds 'go back' as a new node, just to have something in place. We can come back to this later.

Again, feel free to add the other option if you want to give it a try. For now, maybe #140 would have higher priority?

[Yuu-Han]

My personal preference is not adding the new node when clicking the existing node or tab. The options can happen after user interaction with the page that he went back to.

Also there can be rules customised to webpages (e.g., rules mapping to domain names)? For example, if I'm using translation software, I do not want to have a new nodes when I come back to it.

In other situations, this depends on more complex semantics. For example, when I use google scholar to search for papers, I do not want to add new nodes if I'm searching for papers related to a certain topic. However, if I come back after some time and start a new topic, I would like it to be another node. For such cases, a simple way is to let users decide. It can go quite complex as well, for example taking interaction provenance into consideration.

I'm also thinking about if we need other status attributes for the node (besides clicked)? For example to distinguish if a page has ever been opened? It would also be interesting to capture the time the user spends on the tab? Because I'm thinking that there might be period of casual browsing when users open a lot of tabs but do not come back to HistoryMap to curate the information. I would like to observe whether users can make sense of what has been explored when large amounts of nodes are added to the tree in that period.

Just to note some random thoughts coming into my mind.

[kaidatavis]

I agree in general going back to the previous node makes sense. This way histroymap better reflects the logical flow; currently it is very much time oriented (going back adds a new node). The logics for this is in hmController.js and the code is not very clean after new changes being constantly added :-).

I'm also thinking about if we need other status attributes for the node (besides clicked)? For example to distinguish if a page has ever been opened? It would also be interesting to capture the time the user spends on the tab?

Yes, the old extension tracks whether a page ever becomes visible. If we add this back, it would be interesting to track how long user spends on that page (actively). Can you create a new issue for the page open time?

[kaidatavis]

@Yuu-Han, is this completed?

[Yuu-Han]

Yes, it is.