Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fragment Identifiers in Annotation Target Links #1837

Closed
shepazu opened this Issue Jan 9, 2015 · 10 comments

Comments

Projects
None yet
5 participants
@shepazu
Copy link

commented Jan 9, 2015

Currently, each annotation links back to the target document at the root level. For example, I made an annotation that links to the Web Audio API document. This is good, because the user can copy the extracted blockquote and usually find the selection via the browser's find-in-page API. (This is the same link that is sent in our custom email notifications, BTW.)

However, it would be even better if that link were more discrete, and pointed to the selection's nearest ancestor fragment identifier. For example, the annotation above would point to the "sampleRate" section of the Web Audio API document.

This is an accessibility issue (and a fairly urgent one for us), but also just a basic usability issue. It makes finding the context of the annotation much easier if the user is not coming from the sidebar (e.g. the web repo, or an email).

I don't know if this information is already collected when you find your robust anchoring selectors, but my intuition says that it is. Would this be reasonably easy to add, in the clientside and in the backend? If it's a relatively small change to our local installation, we'd like to do this in advance of any major Hypothesis/Annotator releases.

Note that this is different than #1090, because I'm asking for the direct fragment identifier link to be stored and added, but not used as the canonical target URL for determining when an annotation applies.

@tilgovi

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2015

Not collected already. Not too hard to add.

@csillag

This comment has been minimized.

Copy link
Contributor

commented Jan 19, 2015

#1872 touches on this.

@judell

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2015

Tagged with document_equivalence because it's related to that in ways I don't yet fully understand but need to.

@tilgovi

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2015

There are a few different things going on here.

First, we do collect fragment selectors. On master, there are two bugs, both solved already on anchoring-rewrite: a blank FragmentSelector is stored when there's no applicable fragment identifier and when a fragment identifier is stored it's stored with the value #id rather than simply id.

Second, there's the stream/navigational/direct-linking issue of having the link back to the source get at least to the fragment, if not to the exact quote, when the user navigates that link.

So, I would say we should maybe make sure we target the second of these with this issue.

@nickstenning

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2015

@tilgovi Can this be closed?

@tilgovi

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2015

I believe so.

@tilgovi tilgovi closed this Jul 23, 2015

@shepazu

This comment has been minimized.

Copy link
Author

commented Jul 23, 2015

Does this work, now?

@tilgovi

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2015

The stored target source URLs should not have fragments and there should be a FragmentSelector with the nearest fragment identifier from ancestors.

@shepazu

This comment has been minimized.

Copy link
Author

commented Jul 23, 2015

I'm not sure if that answers my question. My request was not about the internal model, but that the link in some views of an annotation, for example in the livestream view or an email notification (but not the sidebar view), should contain the fragment id so it navigates to the right part of the target document when it's navigated. This is a UX request.

@tilgovi tilgovi reopened this Jul 23, 2015

@nickstenning

This comment has been minimized.

Copy link
Contributor

commented Feb 10, 2016

Hi there! I'm going to close this as part of a clean-up of all issues currently open on this repo that represent ideas or features rather than reports of bugs or technical chores.

I want to be clear that this isn't intended to say anything at all about the content of this issue—it certainly doesn't mean we're no longer planning to do the work discussed here—just that we don't want to use GitHub issues to track feature requests or ideas, because the threads can get long and somewhat unwieldy.

If you're interested in what we are working on at the moment, you can check out our Trello board and, for a longer-term view, our roadmap.

And, if you're interested in following up on this issue, please do continue the discussion on our developer community mailing list. You might also want to check out our contributing guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.