Provide a way to prevent auto-collapsing of tall annotations
(Context added by @robertknight after in-person discussion with Steel)
Instructors use annotations to add media and interactive H5P exercises to pages in books published online using PressBooks. See this book page for example. These media and exercises result in tall annotations which often get auto-collapsed by the client, showing a subtle "More" link at the bottom which has to be clicked to see the full content of the annotation. This auto-collapsing behaviour often hides important content in the annotations and students do not realize when they look at the annotations that there is additional content to look at or interactive exercises to complete.
It would be useful to have a way to prevent this auto-collapsing behavior in this context.
Original description:
We're using the WP hypothesis plugin to add hypothesis as an annotation tool within an instance of Pressbooks. Each book (child site on our WP multi-site install) can choose to activate hypothesis for their book, and choose which page(s) it appears on by default. One of the things I'm working on is building a functionality plugin which would give the user a few more options for their book. One option I'd like to provide is the option to have their first-level annotations appear expanded by default (rather than truncated). My understanding is that this functionality is controlled by this variable:
https://github.com/hypothesis/client/blob/d2eaac97b7b36abc6fc54b52b895cac2d7dee19f/src/sidebar/components/annotation.js#L89
Would you be open to producing some kind of custom action hook that would allow us to change the default value of this variable on a book by book basis via an external functionality plugin in WP? What I have in mind would be something like a checkbox on our settings page that says "Show annotations as fully expanded by default:". If the book author selects that setting, then we'd be able to change this variable to false. If they leave it unselected, collapseBody would remain at its default true value.
@robertknight or @judell Any updates on whether this would be possible for us?
@robertknight or @judell -- just wanted to +1 this issue and see whether you had any new thoughts on it. Seems a fairly simple issue, but would make a big difference to us ...
@robertknight and I have discussed a possible enhancement to the core client: namely, to set the default display value to expanded (i.e. self.collapsebody = false) when a single annotation is selected for display.
I just explored some possible solutions for this with Steel. A few things that came up:
-
The "More" and "Less" links and shadow indicating that an annotation is collapsed are quite subtle and easily missed by a user not familiar with Hypothesis. We could perhaps address this with some design tweaks. Here I have moved "More/Less" from the right-hand side of the annotation over to the left (to the left of any tags) and added an Up/Down arrow:
-
Students will typically interact with annotations by reading through the page and clicking on highlights to reveal the annotation. When clicking on a single highlight, the sidebar hides all annotations except the selected one. Since there is no advantage to collapsing an annotation when there is only one visible, we could auto-expand the annotation when it is selected.
-
Finally Steel's original proposal was a client configuration setting, together with a corresponding option in the WordPress plugin to give the integrator control over the default behaviour.
Hi @robertknight -- where are we at with this as a configuration setting? Is your commit referenced above something that could be merged into core? We'd love to use if/when it's available ...
@ajpeddakotla -- this is the thread referenced in the post about H5P embeds: https://github.com/hypothesis/client/issues/509. Any possibility for @robertknight's branch here https://github.com/robertknight/client/commit/794b4779b763980aef41983ce52ec03a1645e5ec to be merged into core?
Same comment on this one: https://github.com/hypothesis/client/issues/509#issuecomment-424151867
Hi @ajpeddakotla any news or movement on this issue and/or #509 ? We're approaching the start of a semester again, and folks would love to use both of these with greater confidence in our production workflows. If there's anything I can do to help with getting a PR in place or approved, I'm happy to do (or try to do) whatever might be needed ...