Comments & Annotations

[blackforestboi]

We want to give people the ability to interact more deeply with the content they read.
As preparation for GSoC this means implementing the ability to make one or more comments and link them to one or more pages, with respect to the Open Annotation Data Model. The more tricky part, which will then be part of GSoC is to add the ability to create annotations. Adding annotations is work dependent on the highlighting done in #236

Goals V1:

Storing, editing, deleting and displaying of one comment, no searchability yet

• creating mockups for comments @oliversauter
• storing of content in in PouchDB with Open Annotation Data Model structure
• The ability to add comments to a page in the overview & popup
• The ability to remove a comment
• The ability to edit a comment
• Developing this as a standalone module which also can be used by other projects e.g. ScienceFair
  • Abstracting UI and Logic as much as possible. (To afford UI implementation with other frameworks than ReactJS)

Goals V2:

Ability to do same with multiple, separate comment

Goals V3:

Ability to add annotations to any highlight in the text (dependent on #236 )

Goals V3:

Making comments, highlights and annotations searchable.

[migom6]

I would like to work on this issue.

[migom6]

@oliversauter,
I read the open annotation data model specs. Now, I am familiarising myself with the existing codebase.
I would like to have some sample mocks according to our discussion over slack before I propose a data model.
Below is a link of code snippet which is played for a while (for output check the console)
https://jsfiddle.net/migom6/f52uom2j/3/
I have gone through enough documentation for DOM manipulation to create highlights and on the spot annotation.
Thanks :)

[blackforestboi]

@blahah already worked on some code to make the highlighting possible.
Annotations can be built with the same highlighting/anchoring methods.
https://github.com/WorldBrain/direct-linking-client

I would like to have some sample mocks

You mean for the design for the comments? Will provide them by the end of the week.

Thanks for taking this on!

[migom6]

Yes, I think it would be of great help having the UI, then we can go through less iteration for the data
model. I'll go through the direct-linking-client as of for now.

[migom6]

I have read the code of the direct-linking-client.
And seems it is using only annotatorjs and dom-highlight-range to achieve it.
Annotatorjs has a good documentation and extensive plugins. The purpose can be solved with it easily.
Even hypothes.is is using the same!

[blackforestboi]

@migom6

Here are the mockups for the comments feature.

Results list with new icon

Every result element should have a new icon indicating the ability to add a comment

Sidebar to add new comment and edit old ones

When pressing the comment button, a sidebar opens on the right.

If there is no previous comment

If there is no previous comment the cursor already in the "new comment" box, so that people can start typing right away.
Once they make any changes to the field, the greyed out "save" button turns green and active.

If there is a comment already:

If there is a comment already, the field is automatically in edit mode and the cursor is already after the end of the available text, when opening the sidebar.
Without any changes the "update" button is greyed out.
When changes are made, the update button turns green, and a cancel button appears. (pressing 'cancel' returns field to old state (just reloading from DB, i guess), but does not close the sidebar.

Popup to add comment when visiting page

The popup basically has the same behaviour as the comments you make in the overview's sidebar.
You can get inspiration from the way the tags are handled in the popup to make the comment view possible.

Important note:

1. The mockups are with multiple comments in mind as we later aim to make for multiple comments/annotations displayable in the sidebar.
   For now we just want to implement the ability to add & edit 1 comment.
2. Keep everything as modular as possible, as we aim to implement this feature into sciencefair as well. Abstract logic from UI as much as possible and think of good APIs.
3. Make sure the data model already supports that one comment can be associated with multiple urls.
4. The text field should store and display newline.

[migom6]

Hi @oliversauter

I have made the presentational component for the comment box in the popup view. I have made a draft according to the Open Annotations Model and I am on the way of writing the HOC for it. After that I'll start working on the side bar component.
Below is the the link of the forked repo and branch link of my works on the project
https://github.com/migom6/Memex/tree/feature/comments. I'll keep posting more about my works in the issue page.

Cheers !!

[blackforestboi]

hey @migom6

Great! thanks for communicating everything you did clearly and congrats to your first progress! :)

I have made a draft according to the Open Annotations Model

Where did you implement it or just thought about it? Can't find it in your commits.
In any case it would be good to post the schema you have in mind as a comment here.

[migom6]

hi ! @oliversauter
Thank you for going through my commits.
I have not implemented the data model in the code and the RPCs. I have just made a rough schema for the comment(s) along with provisions for start and end ranges. I want to finalise it before I send it to you. Can I submit it by the end of this weekend since I am having exams? I will be sending a PR for code review along with the data model.
Thanks 😄

[blackforestboi]

Can I submit it by the end of this weekend since I am having exams?

Of course! Best of luck with your exams. :)

Rock it!

[migom6]

hey @oliversauter @blahah
As discussed in issue #236, should this be implemented using annotatorjs which is used by hypothesis. Annotatorjs has its own data model for most of the things and I can't see any documentation to load data to annotator without a proxy server (for annotatorjs).
I created a pull request with all the details I have worked till now
#317

[blackforestboi]

Great, just left a comment and linked the guys who built annotatorJS and worked on the implementation of the spec at Hypothes.is. :)
They hopefully have the time to give us some good feedback.

I think you can try to progress with the rest and get it running, and we change the data model later. Now we first want to get a proof of concept up.

[migom6]

@oliversauter,
I will proceed with the implementation of comments feature as of now.
If I can get the svg for these images will be of big help

Cheers! 😄

[blackforestboi]

Here you go :)

Archive 2.zip

[vamshi9666]

i wanna get involved in this . can i ?

[migom6]

@oliversauter thanks 😄
I'll start committing soon since my exams ended.

[digi0ps]

Hey @oliversauter. Few questions.

storing of content in in PouchDB with Open Annotation Data Model structure

In this issue, you have mentioned that we should be storing comments locally.

But your comment in PR #317 confuses me.

Annotations that have the same source/selector and author should have multiple bodies.
Annotations that are made on the same source/selector but by multiple authors should be multiple annotations.

If we are taking multiple authors into consideration, we would first need to way to identify users (like creating an account first and being logged in) and we would have to store the data in an online server (like maybe the proxy server in PR #236). But if we are storing the comments locally, we wouldn't be requiring an author field at all, since all the comments are created by one user only.

Can you clarify?

[blackforestboi]

If we are taking multiple authors into consideration, we would first need to way to identify users (like creating an account first and being logged in

This was just a comment to clarify the structure of annotations > to basically rephrase what Randall has been saying.
For now, we only have one author, the user himself, so everything is stored locally and no need to have a signup right now. So everything is the first case:
"Annotations that have the same source/selector and author should have multiple bodies."

However later, when sharing functionality is implemented, it will certainly be the case that multiple authors have annotations displayed on a single users machine.
Then this this is relevant:
"Annotations that are made on the same source/selector but by multiple authors should be multiple annotations."

Does that clarify?

[migom6]

As for now, we are focusing on a single user. There can be multiple comments for a single selector and multiple selectors for a single page.
We will be using dexie js for storage, not pouch db, and everything will be done locally.

[digi0ps]

Got it thanks!

[090max]

I would like to work on this issue

[migom6]

Hi @090max ! I am working on this issue. Let me know if I can help with this
Thanks 😄

[090max]

Ya, I actually need help as I am first time working for gsoc and wanted help on what can we do in this comments and annotation that proves suitable.

…

On 24 Mar 2018 8:07 p.m., "Madhurjya Pegu" ***@***.***> wrote: Hi @090max <https://github.com/090max> ! I am working on this issue. Let me know if I can help with this Thanks 😄 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#301 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ae3Ai5wfxx72H_h4V11kJr96xDrkKXKIks5thloogaJpZM4SEKNB> .

[migom6]

@090max
ask @oliversauter on this matter since he is the one maintaining all of the GSOC stuff.
You can start by going through the pr #317

[blackforestboi]

@migom6 thanks for jumping in to clear up the situation.

@090max
unfortunately it is now too late to apply for GSoC.
The deadline is on the 27. and it is expected to flesh out a proposal for the summer project until then and bring first code contributions.
The students we are going to work with this year have been in contact with us for over 1 month in order to deeply understand the work that needs to be done.
Next year maybe, sorry 😞

Tips i can give you look around early for the projects you want to contribute to. Usually the mentoring organisations are announced mid February.

Until next year!

[blackforestboi]

@digi0ps

I made some new mockups for the sidebar content to display highlights/comments/annotations

Notes for Content Types

• We need to keep all time stamps of editing changes for later use. Keep this in mind as you work with the database to store information. This could be to show a edit history, or to be able to filter by times of edit, even if you dont remember the last time, but only a time.
• In both the highlight, and the comment/annotation body, we want to keep the line breaks in tact when displaying
• If the content is more than 300 characters or 5 lines, we want to break it and let people “show more”
• the right side icon on each card with the arrow pointing in the middle should open the page, and the sidebar. it means basically "show on page". **Important: ** it is not shown for the sidebar in the page itself.

Notes for sidebar

• This sidebar UX is valid for the overview but also for in-page view.
• The trigger in the overview is clear, the "comment" button in each result item
• The trigger for in-page view, is either "open in page" icon on cards in the overview-version of the sidebar, or through the ribbon appearing on every website.

Notes for ribbon

• the 'X' icon is there to temporarily remove the ribbon
• the 'settings' icon is there to go to the settings and disable the ribbon forever if desired.
• the ribbon needs to be super lightweight and produce no lag when loading the page.

[digi0ps]

Sidebar Injection

Since we are going to be having the Comments/Annotations Sidebar present in every website, I was researching on some neat ways to inject it.

I liked styled-components before, but thinking of it now, it wouldn't be suitable for us since it uses custom React components and would require some messing of webpack config.

The first approach we can try is the same way we have done with both Memex.Link tooltip and SearchInjection. That is inserting all the components into the DOM of the website in content script. Relatively easier method but has a downside to this approach, CSS overrides. We won't be having clashing classnames (thanks to modular CSS classnames), but global overrides for specific tags can be annoying. Shadow DOM might be an easy solution for us, but Firefox sadly doesn't support it.

Second approach is how hypothesis has done it. Mostly similar to the previous approach but instead of inserting the Sidebar itself they have inserted an iFrame which points to a chrome extension page. So here we will have to create a new Sidebar module and add a separate webpack entry for it.

The iFrame approach seems good to me (until Shadow DOM is implemented in Firefox) as it solves the CSS problems and has been working well with hypothesis. I am not sure about any downsides to this approach. But @poltak was against using the iFrame approach, are there any caveats to this?

@ShishKabab @oliversauter Any say in this?

[poltak]

Note that I don't have much experience in this problem domain at all, so please take what I say with a grain of salt. If you've done your own research into the different options and consider iframe to be the best option as of now, I completely support that :) Ngày 9 thg 6, 2018, vào lúc 02:27, Sriram <notifications@github.com> viết:

…

Sidebar Injection Since we are going to be having the Comments/Annotations Sidebar present in every website, I was researching on some neat ways to inject it. I liked styled-components before, but thinking of it now, it wouldn't be suitable for us since it uses custom React components and would require some messing of webpack config. The first approach we can try is the same way we have done with both Memex.Link tooltip and SearchInjection. That is inserting all the components into the DOM of the website in content script. Relatively easier method but has a downside to this approach, CSS overrides. We won't be having clashing classnames (thanks to modular CSS classnames), but global overrides for specific tags can be annoying. Shadow DOM might be an easy solution for us, but Firefox sadly doesn't support it. Second approach is how hypothesis has done it. Mostly similar to the previous approach but instead of inserting the Sidebar itself they have inserted an iFrame which points to a chrome extension page. So here we will have to create a new Sidebar module and add a separate webpack entry for it. The iFrame approach seems good to me (until Shadow DOM is implemented in Firefox) as it solves the CSS problems and has been working well with hypothesis. I am not sure about any downsides to this approach. But @poltak was against using the iFrame approach, are there any caveats to this? @ShishKabab @oliversauter Any say in this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Victor239]

This seems complete currently.