hypothesis
Preview annotations
Feature Request Form
Problem you are trying to address with this feature
In order to get any information about the annotations on a page, you have to open the sidebar.
Your solution
Many have suggested that being able to preview on hover over highlights would be a significant usability enhancement.
Since highlights can overlap, with infinite depth (i.e. annotations) potentially being stacked over eachother, you'd want to probably limit the preview to only the first 2-3 annotations w/ short snippets for each (and usernames?) for each, w/ an "X more annotations" underneath to indicate the balance.
Clicking on the hovered preview would open the sidebar w/ the appropriate annotation selected-- clicking on the X more annotations area would open the sidebar w/ all annotations selected as though you'd clicked on the stacked highlight.
This was first described here: https://github.com/hypothesis/h/issues/2109
I'm actually kind of skeptical of the value of details on hover, for a couple of reasons. First, it's a desktop-only feature, no use on touch interfaces, which includes all mobile users. Second, it gets complicated really quickly on heavily-annotated pages, and I'm wary of features that get worse as our adoption grows.
Showing 2-3 annotations in a popup (even in abbreviated form) sounds like a lot of info for a very small, ephemeral space. Also, how do we choose which annotations to pull forward (for highlights with a lot of annotations)? Latest? "Top," once we implement voting? Is that a setting somewhere? Are replies eligible to appear? I'm concerned that we're talking about a pretty complicated view, which might be ill-suited to a hover panel.
There's also the issue of how soon the popup/panel appears - imagine moving your cursor across a heavily-annotated page - which we could mitigate somewhat with a short delay, but might still cause overwhelm.
To be clear, I'm not against details-on-hover in general. I think it makes perfect sense to show an abbreviated user profile when hovering over usernames, for example. I just have questions about implementing it for annotations.
I'm with @dwolfe on this one. It sounds like there is a need to surface more annotation information, but I tend towards skepticism about hover for a11y (it's hard for a family member of mine with some mobility issues to accurately hover with a pointing device) and cross-platform reasons. Not to bury the problem, which sounds real—a better, easy way to surface key annotation details?
I have a11y questions too, but I haven't done enough research to figure out if/how hover effects can be done accessibly.
I'd like to dig a bit more on the user problem this attempts to solve. In my understanding, hover previews are mostly useful to help the user decide whether to "invest" in an action that has a cost, say, leaving the page they're on. Take the example of an inline username - clicking on it navigates to that user's profile, so a hover preview either gives you the information you're looking for (maybe you want to see the user's avatar, their activity stats, etc.) or, failing that, helps you decide whether you want to leave the page you're on and view the full profile. The value here is that you're not incurring the expense of a page load.
For annotations, there isn't a page load involved. Given that the click just shows the sidebar, what information can we provide in a hover preview that would be valuable as an intermediate step before showing the sidebar?
Thanks for these notes.
BTW, I finally found the original issue, which was described here: https://github.com/hypothesis/h/issues/2109
Which links to a drafty set of notes for this that we wrote back in 2015.
Also-- the original title was perhaps overly prescriptive, so I've modified it from "... on hover" to simply "Preview annotations".
TL;DR yes, lets keep an open mind to how to solve the problem. Prototyping a few approaches to get feedback might be worthwhile.
I responded to a few things though...
... the problem, which sounds real—a better, easy way to surface key annotation details?
Yes. If I had to put a finer point on the problem/opportunity, it's one of efficiency in quickly navigating lots of information. On any given page of annotations, I may only be interested in some of them-- perhaps for instance on a particular passage I'm reading.
For annotations, there isn't a page load involved. Given that the click just shows the sidebar, what information can we provide in a hover preview that would be valuable as an intermediate step before showing the sidebar?
I think it's about clicks vs page loads. In this case, zero clicks vs at least two each time you open and close the sidebar. If you're scanning through a long document, perusing a number of annotations, that's zero clicks vs ... many. Tens? Hundreds? Partly this is exacerbated by our sidebar that covers the text. You want the sidebar out of the way while you're reading.
If I can quickly scan, getting a sense from the first sentence or so of an annotation or so what the gist is, before deciding to zero in on the few that interest me, that might be a significant gain in time / clicks / cognitive load, etc. Over the years many have suggested this to us-- in fact it was one of the very first pieces of feedback we received. I myself have thought the same. It's currently #2 on my own list of usability improvements we should solve for (which is meaningless other than that the stuff higher up is what i tend to hear more often).
First, it's a desktop-only feature, no use on touch interfaces, which includes all mobile users.
True? (e.g. https://knackforge.com/blog/karalmax/how-deal-hover-touch-screen-devices, et al). Presumably there are modern, cross-browser ways to achieve this?
But even if not.... I believe strongly in a mobile friendly and accessible future for us, however I don't believe in the contrapositive-- namely that if a feature isn't inherently mobile friendly or accessible that it shouldn't be done. To say that there cannot be a single power user feature for desktop users if we can't introduce it also on touch (or for screenreaders) seems a bridge too far. (cf. Github and Wikipedia recent desktop-only hover features).
Second, it gets complicated really quickly on heavily-annotated pages, and I'm wary of features that get worse as our adoption grows.
I think the notion is that short previews would be an accelerant in a majority of use cases. But when information is dense and it needs the full resolution of the sidebar to explore, then voila -- click to open. Casual investigation: First 300 documents from /search only show one w/ > 50 annotations total (53).
Presumably you'd set a threshold (2, 3, 5, 7?) for any given stack after which we collapse any remaining previews into "and X more". So, the feature doesn't get worse as adoption grows, it simply has an operating range of density that covers most of the territory.
Also, I'll point out on the a11y side that there might be approaches to decorating our spans with some of the preliminary text from the annotations that could provide screenreaders the same benefits as a hover (or other) solution for other folks.
Thanks for listening...
Are the problems with presenting information in the small space of a hover card the same as the problems of getting Hypothesis to work on small mobile screens? (How to scale as the number and density of annotations on a page increases, how to show multiple annotations in one popup, a lot of info in a small ephemeral space, which annotations to show first, how and whether to show replies, ...) A hover card seems roughly the same size as a phone screen.
Could accessibility problems with show-on-hover be addressed by not having show-on-hover be the only way to show the hover cards? E.g. have some permanently on screen next and prev buttons or keyboard shortcuts that show the hover cards (and move to the next card, scrolling the document as necessary) so you can click through them that way? So they're "hover cards" in that they "hover" ovee the document :) but not in that they're (only) activatable with a mouse hover. (In other words is the a11y issue only with show-on-hover or is it with the idea of cards itself?) (Apparently Wikipedia's ones work on keyboard focusing of a link / you can tab through them. I'm not sure whether they work with screen readers though, but it seems not impossible?)
As far as a11y goes, I need to learn more about the accessibility of hover states before I can comment there.
Generally speaking, I have a gut feeling that previewing annotations is a response to a problem with the sidebar, and a better solution might be to make improvements there rather than introduce additional elements to the page. Having said that, I need to think more about some of the points raised here.
A hover card seems roughly the same size as a phone screen.
We could make a hover card that approximates the size of a mobile screen, but I wonder again why the intermediate step, instead of going directly to the full client view? I've been thinking of the current client view (428px wide) as basically the full-screen mobile view, so that's where I feel like there's equivalence. Admittedly that's based on available real estate rather than content, and I'm not clear on exactly what content we would surface in a preview.
Presumably there are modern, cross-browser ways to achieve this?
Well, the problem is that the physical action just doesn't exist on touch screen devices, not that we can't apply the behavior as a response to a different event. Indeed, that's the approach of that jQuery plugin - it triggers the hover state on the first tap, and the click action on the second, which works, but forces the user to tap twice to activate a link, which is an annoyance when you know you want the full click. Incidentally, mobile Safari did this when it was first released, but Apple quickly pulled it.
Funnily enough, I do think that behavior is acceptable for the user profile example, because of the page load.
if a feature isn't inherently mobile friendly or accessible that it shouldn't be done.
Not suggesting this at all. I think it's more of a priority issue, and this feels like an enhancement rather than core functionality, of which we have a lot to work on. But part of the value of thinking mobile-first is that a solution that works well on a mobile touch screen device will definitely work in a desktop browser with a keyboard and a mouse, but the reverse isn't true. It's easier to move all your stuff into a bigger house, than to cram everything you own into a tiny apartment, as the saying goes.
I think it's about clicks vs page loads. In this case, zero clicks vs at least two each time you open and close the sidebar.
That makes sense. I need to think more about it, but this is the part that makes me think we can address this elsewhere, and make the product better in an accessible and mobile-friendly way without introducing a new, fairly complex component. Maybe we start with the user profile example when the time comes, and try to reuse and adapt that implementation?
