Inconsistent behavior on bucket bar arrows

[csillag]

When we click on a tab on the bucket bar, we select the annotations signified by the given bar.

Except when we click on the up or down arrows, when we only scroll to reveal the next bucket,
but we don't change the selection.

This was sufficient when we were still using the dynamic bucket mode, but now that we have eliminated it, the old selection remains - so the sidebar still shows the annotations selected earlier, by clicking on a different bucket.

That feels inconsistent and counter-intuitive. I propose that in these cases, we interpret the user's action as if he would have also clicked only the bucket that we scroll to, and so immediately select those annotations.

[dwhly]

Let's just kill the selection altogether.

[csillag]

What would that mean?
What would happen when we click on a bucket?

Currently, we select the involved annotations; ie. they will be put in the sidebar, and everything else will be hidden. (Just like running a search query does.)

What would the new behavior be?

[dwhly]

Let's just kill the selection altogether.

Scratch that.

I favor your suggestion above. My rationale for killing the selection when we use the arrows, was based on dynamic bucket mode. Previously, scrolling the viewport to a place where we know there are annotations (the next bucket up or down) would guarantee there are related annotations in the sidebar. Now, that's not the case. So, yes, we should scroll to the next bucket and select it.

[tilgovi]

Can we kill the arrows instead?

The arrows are good for a review workflow. There is a type of reader that is served by it, particularly the one who is revisiting their notes. I suggest that such a person is looking at the notes in the sidebar with high probability, and navigating via those rather than the arrows. The arrows to jump to the annotations are kinda awkward .They have always seemed to me unsure whether they are solving a navigational or informational problem. They are a large part of our intrusion into the page design space.

Can we rip the arrows out instead?

[csillag]

Can we rip the arrows out instead?

I am fine with removing the arrows, IF

• We still provide some indication at the top and bottom of the bucket bar, so that the user can see, even with the sidebar closed, that some annotations are above/below his current viewport, AND
• We provide the same arrows, with the same functionality, inside the sidebar

[dwhly]

Can we kill the arrows instead?

For me, the utility of knowing that there are annotations below (or above, but primarily below) me is strong. Without the arrow, I can't see at a glance that the are still more, and how many more, and I can't navigate to the next easily. This is particularly helpful on longer docs w/ intermittent annotations of course.

I refer to them all the time when I'm using our app.

I'm all for radical re-thinking, and re-design, but for this one, I'd like us to think about how we improve what we have before we remove this ability.

[dwhly]

We still provide some indication at the top and bottom of the bucket bar, so that the user can see, even with the sidebar closed, that some annotations are above/below his current viewport,

Unless I'm mistaken, this sounds like up/down arrows. Maybe you're suggesting restyling them?

[tilgovi]

I refer to them all the time when I'm using our app.

Using it for what? What's your goal when you're using them? I don't mean, "go to the next annotation" I mean specifically why. What are you using Hypothesis for at all in that moment?

I am fine with removing the arrows, IF

Neither of your bullet points attempts to argue why these features are important or for whom.

You two, it's not the style I care about changing, it's getting rid of superfluous stuff. That doesn't mean we shouldn't make navigation available to someone in either a packaged consumer product or a developer interaction, but I'm not hearing anything that convinces me this needs to be in our browser extension. I have been asking for many months and I am still not convinced.

[csillag]

Unless I'm mistaken, this sounds like up/down arrows. Maybe you're suggesting restyling them?

What I was suggesting that we remove the active navigational functions (or, to be more precise, we move the navigational functions inside the sidebar), and then the things that remain in the bucket bar become pure indicators. My motivation was that @tilgovi wrote this:

They have always seemed to me unsure whether they are solving a navigational or informational problem.

So, I was proposing that we remove the navigational aspect, and then they become purely a tool for informing the user about the existence of annotations.

btw, I like it the way it is; I am just trying to find ways so that maybe @tilgovi can like it, too, preferably without crippling the thing too much.

[csillag]

I propose that in these cases, we interpret the user's action as if he would have also clicked only the bucket that we scroll to, and so immediately select those annotations.

I take back my proposal, because I realized that technically, those buckets don't really exist until we try to scroll to them. (We generate the buckets from the nearby annotations on the fly, and their content changes (joins / separates) as we scroll.) So it would be very tricky to do what I proposed.

What would be easy is to select the first annotation that we scroll towards; but that would be misleading, because if there are other annotations nearby, the user can expect to see them just as well.

So my new proposal is to simply clear the selection is those cases, which would then show all annotations in the sidebar, including the ones we have just scrolled to.

[judell]

Tagged heatmap.

[nickstenning]

Closing. Any changes to this behaviour we can discuss as part of our broader design process.