MobileRead Forums - View Single Post

bengalih · 10-23-2023, 12:05 PM

I understand.

My opinion is that EPUBs are superior to other "editable format(s)" in how their flow works. Also, in my case I am not looking for collaborative editing (or editing at all), I am looking for collaborative discussion. Think "book club"" if you like - where multiple people are reading the same document and logging their thoughts and sharing relative passages. Again, the ability to view these thoughts in "context" would be very helpful. So the use case is 100% not to collaborate for editing, just to facilitate discussion of the books.

I too have thought of using a single user account for all users and this is what perhaps I will have to do. However this has similar privacy complications. We could all use a single account for collaborating on books in the "club" and then another one for our personal use, but this is cumbersome and also doesn't allow us to store public and private comments on the same copy of the book which may recreate work.

I definitely see that the work involved to make a granular control for opt-in would be quite a bit of work to do and I agree that adding this ability for users who want it may just as likely break the privacy barrier for those who don't. This, combined with the limitation of only one annotation per location would cause some complications with your proposed solutions.

This is why I again turn to Hypothes.is because it overcomes all of these limitations and offers an open framework for this type of collaborative discussion.

I am not a developer (though I have done some development, but have worked more in the design, QA, and integrations of products) and have barely looked at the project code on GitHub and thus may be severely underestimating the task at hand. In my mind I would see the Hypothes.is integration fairly straightforward as such:

Somewhere in the web reader (Content Server) settings would be an option to enable Hypothes.is annotations. Clicking this box would do two things:

1 - Disable whatever code is bringing up the context box when highlighting text for annotations.
2 - Add the one line script tag for the hypothes.is tool within the iframe. TBH, I'm not 100% sure this is needed, however it would definitely add functionality since even if the Chrome extension did work to inject in the frame, adding it manually would allow use on browsers that don't support extensions (like mobile Chrome).

Ofc, Disabling the option would simply do the reverse.

I know that this integration would only work in the Content Server in a browser. It would be incompatible with the Viewer and Calibre annotations - and that is OK! Calibre is such a stellar piece of work that so many want to use for it's organization and converting functions. It doesn't need to be perfect at everything and can allow some help from other services if available.

I may be way off base with what needs to be done to get this working, and I respect every minute of your development time. It just seems (on the surface) to be a fairly granular addition that does not even need to be enabled by default and thus should not impact a user's experience if they choose not to implement.

If I've been able to convince you at all, but you are wary of doing the work, as mentioned I would be willing to try (perhaps with the help of others who would desire the features). I wouldn't want to put in the time however if you would not want to integrate it into the product after a proof of concept was completed.

Thanks for your time.

10-23-2023, 12:05 PM	#5
bengalih Member Posts: 10 Karma: 10 Join Date: Oct 2023 Device: smartphone	I understand. My opinion is that EPUBs are superior to other "editable format(s)" in how their flow works. Also, in my case I am not looking for collaborative editing (or editing at all), I am looking for collaborative discussion. Think "book club"" if you like - where multiple people are reading the same document and logging their thoughts and sharing relative passages. Again, the ability to view these thoughts in "context" would be very helpful. So the use case is 100% not to collaborate for editing, just to facilitate discussion of the books. I too have thought of using a single user account for all users and this is what perhaps I will have to do. However this has similar privacy complications. We could all use a single account for collaborating on books in the "club" and then another one for our personal use, but this is cumbersome and also doesn't allow us to store public and private comments on the same copy of the book which may recreate work. I definitely see that the work involved to make a granular control for opt-in would be quite a bit of work to do and I agree that adding this ability for users who want it may just as likely break the privacy barrier for those who don't. This, combined with the limitation of only one annotation per location would cause some complications with your proposed solutions. This is why I again turn to Hypothes.is because it overcomes all of these limitations and offers an open framework for this type of collaborative discussion. I am not a developer (though I have done some development, but have worked more in the design, QA, and integrations of products) and have barely looked at the project code on GitHub and thus may be severely underestimating the task at hand. In my mind I would see the Hypothes.is integration fairly straightforward as such: Somewhere in the web reader (Content Server) settings would be an option to enable Hypothes.is annotations. Clicking this box would do two things: 1 - Disable whatever code is bringing up the context box when highlighting text for annotations. 2 - Add the one line script tag for the hypothes.is tool within the iframe. TBH, I'm not 100% sure this is needed, however it would definitely add functionality since even if the Chrome extension did work to inject in the frame, adding it manually would allow use on browsers that don't support extensions (like mobile Chrome). Ofc, Disabling the option would simply do the reverse. I know that this integration would only work in the Content Server in a browser. It would be incompatible with the Viewer and Calibre annotations - and that is OK! Calibre is such a stellar piece of work that so many want to use for it's organization and converting functions. It doesn't need to be perfect at everything and can allow some help from other services if available. I may be way off base with what needs to be done to get this working, and I respect every minute of your development time. It just seems (on the surface) to be a fairly granular addition that does not even need to be enabled by default and thus should not impact a user's experience if they choose not to implement. If I've been able to convince you at all, but you are wary of doing the work, as mentioned I would be willing to try (perhaps with the help of others who would desire the features). I wouldn't want to put in the time however if you would not want to integrate it into the product after a proof of concept was completed. Thanks for your time.