Thus, annotatorjs.org was made optional in Tiki18, and will live in parallel to Inline comments until we figure out a better solution.
February 24, 2017: https://hypothes.is/blog/annotation-is-now-a-web-standard/
It's time to improve Tiki to
- Make Tiki inline comments much nicer visually
- It should be clearer what the note is, and what is comment. Perhaps a call-out? Nicer colors...
- permit inline comments not just on Tiki content , but also images and embedded content (ex.: PDF)
- Permit annotations beyond text (ex.: drawing, and later audio)
- Private annotations (perhaps we could have a new concept of private comments)
- Public annotations
- Not just on wiki pages
- Comments on embedded content
- Drawing on a screencapture (which needs to be modernized to HTML5 and be working with Openfire Meetings's screen capture)
- ViewerJS content (especially PDF) https://github.com/hypothesis/pdf.js-hypothes.is and https://hypothes.is/blog/epub-js-bringing-open-annotation-to-books/
- Business process management viewer: http://trunk.notre.website/bpmn-test
- Marc to receive a few Bizagi HTML and MediaWiki exports to test
- others: https://indieweb.org/annotation-use-cases
- We need a way to identify ID or text snippet to attach comment to. Like we have with https://github.com/mustardamus/brosho-plugin to pick and change colors
- it apparently allows annotating (through plugins) on images, video, text, and they claim in their website, PDF's
- used by many organizations
- previously funded by Shuttleworth Foundation and the Open Knowledge Foundation, so I presume that they have had good support to reach a decent feature set already.
Last commit is Nov 13, 2015 https://github.com/openannotation/annotator/commits/master so there is a little risk of slowdown of the project, but if it's the best, let's go for it
2016-08-30 Project enters Apache incubator: http://incubator.apache.org/projects/annotator.html
This is something that could tricky. The annotation should be associated to the tracker item and not the wiki page...
The most complex issue is to identify where the note must be displayed, since the note must not be stored in the source of the object, and since contents can change. "Intra-document anchoring" in a way designed to keep working despite changes is called Robust Anchoring.
We store the annotated text. When the user comes back, we need to display the note on that text only. We must ensure that the text is unique when it is selected. Otherwise, we must ask the user to select more content.
Alternatively, instead of storing only the text selected, we could also store some text preceding and following the annotated text. That would reduce the risk of confusing 2 instances of the annotated text.
No matter how smart anchoring will be, that strategy may fail. It is necessary to provide for the case where, following modifications, the content of the annotated text will have several occurrences in the object, or none. If no occurrence remains, we should display a dialog offering the user to delete the annotation or to keep it orphan. Orphan annotations should display at the bottom. If contents occur several times, we should display a warning that some annotations are not displayed correctly and display the contents of the annotation at each occurrence of the annotated text's content.
If a note which is displayed several times is deleted, what should be done? We must prevent the annotation from disappearing from the location where it really belongs after the user removes it because it displays somewhere it does not belong.
Currently, the whole paragraph containing the annotated text is highlighted.
This issue is complex. It would be useful to research the solutions chosen by other projects.
The documentation of the Annotator library does not indicate how it deals with anchoring, but it uses XPath. As Annotator was designed for annotating immutable documents, the current version (1) does not deal with modifications of the annotated document. A plugin was created for that. Version 2 changes anchoring, but is alpha and it remains to be seen how well it handles changes.
This topic has been the object of work from several organizations. See for example:
To ensure proper anchoring, we could add an anchor in the source using something like an ANAME plugin. This way, the comment could be stored outside of the annotated text, so it could remain private. This has the disadvantage of adding "noise" which editors will see in the source, though. And it requires users who add annotations to have permission to edit (unless adding annotations is considered as a special case bypassing edit permissions).
This could perhaps help (suggested by Jonny): https://github.com/tilgovi?utf8=✓&tab=repositories&q=dom-anchor&type=&language=
In my first tests in 17.0 with annotator 1.x inline comments, when you move the paragraph to the end of the document, the highlighted area with links to the comments stays at the source position and is not updated to the end where the real paragraph went. Pending to see how well annotator.js 2.x is, or if some extra annotatorjs plugin is needed to improve the situation.
- http://www.webodf.org/demo/ci/wodotexteditor-0.5.9/localeditor.html can do annotations
This research needs a refresh and be done in the context of Rubix ML