text file vs detail view

[droidgoo]

when viewing marks for a given page via the history / detail view icon the window that pops up shows the marks in the order they appear on the page, but when making a text file they appear in the order shown in the sidebar view for the page (which seems to be order they were created on the page).

marks are expected to appear in the sidebar in the order they appear on the page, and making a text file should show them in the same order as the detail view.

p.s. it might have something to do with the order multiple histories are saved to a text file. when sorted by date the newest ones appear at the top of the browser view, but they appear at the bottom of the text file... maybe related, maybe not.

[ufb]

Hi @droidgoo thanks for the help!

when viewing marks for a given page via the history / detail view icon the window that pops up shows the marks in the order they appear on the page

That must be a coincidence, because the detail view window literally cannot know about which order the highlights currently would appear in on the page.

But that being said, I just had a look into all three cases and there really are some oddities. Here is my result:

Sidebar: My highlights appear correctly -> in the order they are visible on the currently open page

Detail window: Also correct order -> chronologically (I marked in the order yellow, red, blue)

.txt download: This is really off ^^

Also, sometimes I see the correct order in the sidebar (visual order of the currently open page), sometimes they are ordered chronologically - I will have a look into this. And I will also check why the order in the downloaded text file seems so random. I remember that it used to be chronologically, but I must have done some changes overseeing the impact on this order..

In which order did you do your highlights (chronologically)? Can you pelase doublecheck the order in the detail window? Because, like explained above, if it is the order as you see them on the page, then this must be a funny coincidence - this window only knows about the data you saved, and a visual order is definately not being saved, that would be a very unwise thing to do, since the visual appearance is not necessarily the same as the acutal structure of the underlying document (or more precisely: the DOM tree)

Thanks again for your help

This issue is related to Marks export to a txt error

[droidgoo]

thanks for looking into this, i like the extension and plan to rely on it for on-line research... it's a very powerful tool.

i have noticed that the sidebar only shows them in the order created (sequentially) , and that would not be SO bad if the text and details views were to also match up... otherwise it can get very confusing when you are juggling a lots of histories with multiple marks each.

your point about the DOM is well taken, and in my mind the ultimate solution is to allow the marks to be manually re-ordered how you like to see them... then have that always be the order in every view - even if they could not be restored (greyed out but still selectable for reference).

there is also the order each history is printed in the text file being the reverse of what is shown on the history page (at least for the chronological sort)... i don't know if that's related somehow.

On Sat, Apr 25, 2020 at 7:12 PM ufb notifications@github.com wrote:

Hi @droidgoo https://github.com/droidgoo thanks for the help!

when viewing marks for a given page via the history / detail view icon the window that pops up shows the marks in the order they appear on the page

That must be a coincidence, because the detail view window literally cannot know about which order the highlights currently would appear in on the page.

But that being said, I just had a look into all three cases and there really are some oddities. Here is my result:

Sidebar: My highlights appear correctly -> in the order they are visible on the currently open page [image: order1] https://user-images.githubusercontent.com/17272252/80295325-401ec000-8772-11ea-8164-7d3e7c1b7238.jpg

Detail window: Also correct order -> chronologically (I marked in the order yellow, red, blue) [image: order2] https://user-images.githubusercontent.com/17272252/80295349-5c226180-8772-11ea-9fc9-26182297f313.jpg

.txt download: This is really off ^^ [image: order3] https://user-images.githubusercontent.com/17272252/80295378-82e09800-8772-11ea-9e3a-962e429d6c1d.jpg

Also, sometimes I see the correct order in the sidebar (visual order of the currently open page), sometimes they are ordered chronologically - I will have a look into this. And I will also check why the order in the downloaded text file seems so random. I remember that it used to be chronologically, but I must have done some changes overseeing the impact on this order..

In which order did you do your highlights (chronologically)? Can you pelase doublecheck the order in the detail window? Because, like explained above, if it is the order as you see them on the page, then this must be a funny coincidence - this window only knows about the data you saved, and a visual order is definately not being saved, that would be a very unwise thing to do, since the visual appearance is not necessarily the same as the acutal structure of the underlying document (or more precisely: the DOM tree)

Thanks again for your help

This issue is related to Marks export to a txt error https://github.com/ufb/Textmarker/issues/114

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ufb/Textmarker/issues/115#issuecomment-619468295, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANCGYGR7DB4436QSBP2WVLLROOJ7PANCNFSM4MRABOXA .

[ufb]

plan to rely on it for on-line research

Nice. But please keep in mind that there is always a chance of a restoration failure on live sites. The main 2 reasons for this being:

• Textmarker can't rely on the page having the exact same content each time you visit it. All references to DOM nodes won't persist upon reload, therefore Textmarker has to save meta infos to each highlight in order to find the corresponding text passages indirectly.
• Textmarker will by default try to restore your highlights when the page's load is completed. But a lot of pages will alter their content programmatically at a later point in time. That's why Textmarker offers several tools to deal with this: 1) Under Settings > Misc you can switch off the automatic loading of Textmarker's content script into a newly opened page and load it manually via the icon in your URL bar once you think the page's content in question is being rendered completely. 2) You could either have Textmarker automatically retry a failed restoration after 5 seconds (Settings > History) or alternatively manually retry using the corresponding button in the sidebar -> in order for option 2) to work you'd want to make sure Textmarker doesn't give up on highlights that couldn't be restored after first trial (Settings > History)

the ultimate solution is to allow the marks to be manually re-ordered how you like to see them

Most likely a wont-do. I think such a feature would be used by less than a handful of users. I think it would be sufficient to fix the intended order: Visually in sidebar, and chronologically in downloaded text file. Textmarker is saving your highlight objects (which hold the highlighted text and a buch of meta infos) to an array which is ordered chronologically and this order is heavily relied on. Of course I could either add a second arrray to each history enty which is representing a custom ordering or adding an index field to each highlight object. But that's all just too much work for a feature that probably almost noone would even recognize. ) UX-wise anyway

[droidgoo]

Understood. The sites i'm highlighting are unlikely to change as they are mostly a matter of record, but i've already come across this failure so i know it's not fool proof. As for how gracefully the failures occur, it is my opinion that this extension tries too hard on that score to achieve 100%.

Here's what i mean. The value of the highlighted marks (to me at least) is to identify a remark or quote that has meaning to me. It furthers a narrative, or reminds me of the direction i was going with something... Whether a mark can be restored 100% to match with how the mark appeared when it was created is not NEARLY as important to me as the content of the mark and context where is was found.

So, while a mark may "fail" from the perspective of this extension, it would be preferable for me to still be able to have free access to the text anyway... rather than say "it failed" and go about all this visible effort to re-establish, i would rather it does that work quietly in the background and not bother me with it, while in the meantime showing me the mark and allowing me to do everything with it, but simply noting somehow that it is not (yet) validated.

For instance, show me the text as greyed out but still clickable for copy until it's firmed up, and ALWAYS include "lost" marks in the text file with an asterisk or something to indicate it could not be reacquired. At least that way i'm not losing anything and i'm actually GAINING the knowledge that i need to do more work to find an alternative source for that bit. Does that make sense?

As for manual re-ordering of marks in the sidebar, think it would be quite intuitive to simply be able to drag them to a different order that makes more sense to the user than how they might be laid out in the page or which order i created them (you could even re-purpose the exiting arrows for this task) Since clicking on the mark takes you that spot in the article anyway and, as you've said, the order is not linked in anyway to the DOM.

Further, i've noticed that clicking on a mark will sometimes take me to a different mark on the page, usually first and last are swapped so with the last mark expanded, it will jump to the location of the first mark in the page and vise versa, not sure if this is related at all to the array order you mentioned. Anyway, it's not a "must have" and i appreciate that you considered it.

On Mon, May 4, 2020 at 2:24 AM ufb notifications@github.com wrote:

plan to rely on it for on-line research

Nice. But please keep in mind that there is always a chance of a restoration failure on live sites. The main 2 reasons for this being:

• Textmarker can't rely on the page having the exact same content each time you visit it. All references to DOM nodes won't persist upon reload, therefore Textmarker has to save meta infos to each highlight in order to find the corresponding text passages indirectly.
• Textmarker will by default try to restore your highlights when the page's load is completed. But a lot of pages will alter their content programmatically at a later point in time. That's why Textmarker offers several tools to deal with this: 1) Under Settings > Misc you can switch off the automatic loading of Textmarker's content script into a newly opened page and load it manually via the icon in your URL bar once you think the page's content in question is being rendered completely. 2) You could either have Textmarker automatically retry a failed restoration after 5 seconds (Settings > History) or alternatively manually retry using the corresponding button in the sidebar -> in order for option 2) to work you'd want to make sure Textmarker doesn't give up on highlights that couldn't be restored after first trial (Settings > History)

the ultimate solution is to allow the marks to be manually re-ordered how you like to see them

Most likely a wont-do. I think such a feature would be used by less than a handful of users. I think it would be sufficient to fix the intended order: Visually in sidebar, and chronologically in downloaded text file. Textmarker is saving your highlight objects (which hold the highlighted text and a buch of meta infos) to an array which is ordered chronologically and this order is heavily relied on. Of course I could either add a second arrray to each history enty which is representing a custom ordering or adding an index field to each highlight object. But that's all just too much work* for a feature that probably almost noone would even recognize.

• UX-wise anyway

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ufb/Textmarker/issues/115#issuecomment-623355570, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANCGYGVDYGSB6ANSLUFXVM3RP2CVHANCNFSM4MRABOXA .

[ufb]

it is my opinion that this extension tries too hard on that score to achieve 100%

From my point of view getting as close to 100% restoration success as possible is by far the most crucial aim. For 2 reasons: 1) The more reliable the persistance of highlights across reloads the better the overall user experience (nice side effect: the less ugly user complaints). 2) Since references to DOM nodes cannot persist across reloads Textmarker has to find the correct passages indirectly, using meta data about the highlight's relative position to its "surrounding". If a text node holds more than one highlight this surrounding will include another highlight -> so these meta data can depend on eachother. Therefore the loss of one highlight could lead to the loss of other highlights.

So, while a mark may "fail" from the perspective of this extension, it would be preferable for me to still be able to have free access to the text anyway

Textmarker leaves it up to you to "forget" highlights that couldnt be restored or not. If you choose to keep "lost" highlights in memory then you can access them by downloading them to a text file (it's one of the specification options).

rather than say "it failed" and go about all this visible effort to re-establish, i would rather it does that work quietly in the background and not bother me with it

Also up to you: Just disable the corresponding notifications under Settings > Notifications

while in the meantime showing me the mark and allowing me to do everything with it, but simply noting somehow that it is not (yet) validated.

As explained above, highlights might rely on eachother, so it's a crucial part of the extension to prioritize restoration success. After all Textmarker is supposed to be a permanent web highlighter.

For instance, show me the text as greyed out but still clickable for copy until it's firmed up

That's a different story: Giving the user more options on what to do with unrestorable highlights is definately a feature for some future release.

and ALWAYS include "lost" marks in the text file with an asterisk or something to indicate it could not be reacquired. At least that way i'm not losing anything and i'm actually GAINING the knowledge that i need to do more work to find an alternative source for that bit. Does that make sense?

Sure, makes sense. But as explained above it's completely up to you - already. "ALWAYS" is not a good idea, though. I rather leave it up to the user to include lost highlights to the text file. Some other users might not want them.

As for manual re-ordering of marks in the sidebar, think it would be quite intuitive to simply be able to drag them to a different order that makes more sense to the user than how they might be laid out in the page or which order i created them (you could even re-purpose the exiting arrows for this task) Since clicking on the mark takes you that spot in the article anyway and, as you've said, the order is not linked in anyway to the DOM.

see here

Further, i've noticed that clicking on a mark will sometimes take me to a different mark on the page, usually first and last are swapped so with the last mark expanded, it will jump to the location of the first mark in the page and vise versa

Not sure I understood what you mean here. By "clicking on a mark" you mean clicking on the mark's representation in the sidebar? Or clicking the mark directly? Either way I can't reproduce this behavior. The intended functionality (which seems to work for my test cases) is as follows: Clicking a mark directly will activate it, meaning: You then can perform sidebar actions on it, for example. Clicking a mark in the sidebar should lead to the corresponding highlight being scrolled to and activate it. Using either the arrow keys in the sidebar or the arrow key shortcuts (have to be enabled under Settings > Shortcuts) should jump thru the highlights in visual order, meaning: Should scroll to the highlight being jumped to and activate it. Using arrow-down on the last highlight should jump to the first highlight, and vice versa. ) But of course, we already figured out there is a bug in establishing this order. Sometimes the visual order is not being derived correctly.

[droidgoo]

Giving the user more options on what to do with unrestorable highlights is definately a feature for some future release.

i'm looking forward to it... just restored an archive and right away had marks not be recoverable.

only by setting my download button to "All marks (including lost ones)" in the Settings>History tab and opening the downloaded file was i able to read the marks.

if that were visible in the side bar, and clickable so i could copy text from it, i could just manually do a find in page using my browser to see the context again.

By "clicking on a mark" you mean clicking on the mark's representation in the sidebar?

Yes. When you click on it the mark expands and the page scrolls to the mark. There were a couple of instances when that behavior did not go as expected and i cannot reproduce it now either, but it was disorienting when it happened. As i recall, when i clicked on mark 1/3 in the sidebar, it would jump to mark 3/3 in the text, and then when clicked mark 3/3 in the side bar to expand it and verify it was the wrong mark, it would jump to mark 1/3 in the page. It was a head spinner alright.

On Tue, May 5, 2020 at 8:28 AM ufb notifications@github.com wrote:

it is my opinion that this extension tries too hard on that score to achieve 100%

From my point of view getting as close to 100% restoration success as possible is by far the most crucial aim. For 2 reasons: 1) The more reliable the persistance of highlights across reloads the better the overall user experience (nice side effect: the less ugly user complaints). 2) Since references to DOM nodes cannot persist across reloads Textmarker has to find the correct passages indirectly, using meta data about the highlight's relative position to its "surrounding". If a text node holds more than one highlight this surrounding will include another highlight -> so these meta data can depend on eachother. Therefore the loss of one highlight could lead to the loss of other highlights.

So, while a mark may "fail" from the perspective of this extension, it would be preferable for me to still be able to have free access to the text anyway

Textmarker leaves it up to you to "forget" highlights that couldnt be restored or not. If you choose to keep "lost" highlights in memory then you can access them by downloading them to a text file (it's one of the specification options).

rather than say "it failed" and go about all this visible effort to re-establish, i would rather it does that work quietly in the background and not bother me with it

Also up to you: Just disable the corresponding notifications under Settings > Notifications

while in the meantime showing me the mark and allowing me to do everything with it, but simply noting somehow that it is not (yet) validated.

As explained above, highlights might rely on eachother, so it's a crucial part of the extension to prioritize restoration success. After all Textmarker is supposed to be a permanent web highlighter.

For instance, show me the text as greyed out but still clickable for copy until it's firmed up

That's a different story: Giving the user more options on what to do with unrestorable highlights is definately a feature for some future release.

and ALWAYS include "lost" marks in the text file with an asterisk or something to indicate it could not be reacquired. At least that way i'm not losing anything and i'm actually GAINING the knowledge that i need to do more work to find an alternative source for that bit. Does that make sense?

Sure, makes sense. But as explained above it's completely up to you - already. "ALWAYS" is not a good idea, though. I rather leave it up to the user to include lost highlights to the text file. Some other users might not want them.

As for manual re-ordering of marks in the sidebar, think it would be quite intuitive to simply be able to drag them to a different order that makes more sense to the user than how they might be laid out in the page or which order i created them (you could even re-purpose the exiting arrows for this task) Since clicking on the mark takes you that spot in the article anyway and, as you've said, the order is not linked in anyway to the DOM.

see here https://github.com/ufb/Textmarker/issues/115#issuecomment-623355570

Further, i've noticed that clicking on a mark will sometimes take me to a different mark on the page, usually first and last are swapped so with the last mark expanded, it will jump to the location of the first mark in the page and vise versa

Not sure I understood what you mean here. By "clicking on a mark" you mean clicking on the mark's representation in the sidebar? Or clicking the mark directly? Either way I can't reproduce this behavior. The intended functionality (which seems to work for my test cases) is as follows: Clicking a mark directly will activate it, meaning: You then can perform sidebar actions on it, for example. Clicking a mark in the sidebar should lead to the corresponding highlight being scrolled to and activate it. Using either the arrow keys in the sidebar or the arrow key shortcuts (have to be enabled under Settings > Shortcuts) should jump thru the highlights in visual order, meaning: Should scroll to the highlight being jumped to and activate it. Using arrow-down on the last highlight should jump to the first highlight, and vice versa. ) But of course, we already figured out there is a bug in establishing this order. Sometimes the visual order is not being derived correctly.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ufb/Textmarker/issues/115#issuecomment-624123982, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANCGYGS745LPTCA66XU5DCLRQAV75ANCNFSM4MRABOXA .