"friction" mechanism

[declann]

I love the attention to detail closeread is providing in a simple API.

Getting a little more complicated - I wonder if it would be useful to add a mechanism for "friction": where a narrative can be stuck in position for some 'time' (scroll distance), rather than always progressing on scroll.

I think this is something thats particularly useful when scrolling is triggering dynamic behavior - I guess that a user can't easily focus on multiple things moving at once! So I use "friction" a lot in this scrollama (which was overall far harder to implement than what I'm building with closeread)

Perhaps it would add too much complexity: e.g. a followup request would be to control where the message gets stuck.

Since I think the pieces around this in closeread are already nailed well, I'd be interested to hear any thoughts about how/if "friction" could fit in?

I'm thinking: something like spacer but called friction, but the implementation details behind that might be complicated.

Absent a way to do this, I almost gave up on a few things, but I had a look at the most memorable scrollytelling links I have and a tonne can clearly be accomplished without it - interested in any thoughts, though!

[jimjam-slam]

Sounds interesting, @declann! When you talk about friction, do you mean the idea of several triggers going by without the visible sticky changing?

If so, this is something you can accomplish by using the same citation on several triggers. Something like:

::::{.cr-section}

Let's talk about this plot... @cr-myplot

... and keeping talking about it... @cr-myplot

... and talk about it some more! @cr-plot

And now talk about something else @cr-anotherplot
::::

Is that what you had in mind?

PS: loved your work on that retirement example! If you make something similar with Closeread, please consider entering it in the Closeread Prize!

[declann]

Sounds interesting, @declann! When you talk about friction, do you mean the idea of several triggers going by without the visible sticky changing?

If so, this is something you can accomplish by using the same citation on several triggers. Something like:

I mean the reverse: a trigger being stuck for some scrolling while the sticky changes (in my case through dynamic OJS progress updates)

PS: loved your work on that retirement example! If you make something similar with Closeread, please consider entering it in the Closeread Prize!

Thanks! I'm planning to submit something related: a closeread for a model visualization. Maybe a template to show closereads as an approach to explain complicated modelling outputs. (edit: I spoke about this many years ago with Matthew Conlen, author of Fidyll )

As far as I can tell, in closeread a triggger is always moving up the screen. I can still work with this, but when things do get a little complicated I think it's useful to stick a trigger for some scroll distance so the user can focus on the changing visualization.

"Friction" might not be the best way to specify this.

[jimjam-slam]

Oh, I get you! I'd have to think about that a bit with @andrewpbray. But in the mean time, perhaps you could do some custom styling on an individual trigger that includes position: sticky and a top? As you can probably imagine, those CSS properties are the foundation that holds the sticky content while you scroll (until you hit the bottom of the containing section).

[andrewpbray]

Interesting idea! We'll chat about that. A straightforward API for this sort of thing doesn't jump out to me, but I'm sure there's a way we could do it.

[declann]

Yeah, I think closeread API gets to be simple because the developer doesn't need to worry about sticky/narrative heights for instance. But this probably reintroduces that need. I might get to play with something custom as @jimjam-slam suggests - and that could point to some API addition to consider.