Foundation.mozilla.org: Discuss pagination on Pulse component

[xmatthewx]

Foundation site enables authors to pull in pulse projects to display on a page. Global Sprint team loves this, but didn't like the limit we set to protect bandwidth and sanity. We removed the limit for the sprint and now need to make a real plan.

Continuing conversation from https://github.com/mozilla/foundation.mozilla.org/issues/1460#issuecomment-389282566

I think we have 2 options. Ask questions. Comment. Then vote below with thumbs up or down.

[xmatthewx]

Option 1 – Paginate

• author picks any number
• frontend shows up to 24
• frontend includes a load more button if needed
• user hits load more button to load more
• pro: flexible
• con: adds complexity to frontend build
• con: answers limited use cases that could easily link over to a view in pulse
• con: does offer users the other benefits on pulse like favs, search, etc

[xmatthewx]

Option 2 – Don't Paginate

• author picks a number up to 24
• authors then uses the a new pulse button component to easily and beautifully link to more stuff in a specific view on pulse
• pro: keeps the site simple, optimized for what it does best
• pro: let's pulse carry the load for what it does best
• pro: offers users who dive deep the benefits of pulse favs, accounts, search tags, etc
• con: ignores a request from staff

[xmatthewx]

@jessevondoom @alanmoo @kristinashu @gideonthomas @gvn @mmmavis - i'd like to gather your expert opinions before we build a thing. remove yourself as an assignee after you vote.

[alanmoo]

There might be a customization option allowing more than 24 if truly necessary: add a page parameter so users could technically add multiple instances of the component in a streamfield.

[kristinashu]

I feel we should be using this Pulse embed as a way to highlight a few projects and then draw users over the Pulse for more. So in general, I think we should have a "view more on Pulse" button rather than a "load more" button.

Do you have more use cases for this feature? I suspect Global Sprint was a unique exception.

[xmatthewx]

Do you have more use cases for this feature?

Global Sprint was an exception with a strong opinion.

There might be a customization option allowing more than 24 if truly necessary: add a page parameter so users could technically add multiple instances of the component in a streamfield.

That was option 3 or 4 in my original list. I removed it b/c it's confusing for authors and also denies users of the benefit of pulse for a deep dive.

[mmmavis]

Global Sprint was an exception with a strong opinion.

I had the same question @kristinashu had (re: if Global Sprint was a unique exception). Since it WAS I would vote for option 2.

[gvn]

There might be a customization option allowing more than 24 if truly necessary: add a page parameter so users could technically add multiple instances of the component in a streamfield.

I wouldn't recommend this because it would require editors to continuously ensure that the number of "pages" of data being pulled match the number of results. This could get out of sync and result in empty blocks or other weird side effects.

[gvn]

I'm abstaining from voting on a direction. I think either is valid and it sounds like strategy/UX should dictate the ultimate decision. Either option is technically feasible.

[gideonthomas]

After chatting with @xmatthewx, I think for the current scope it makes sense to not paginate and show a limited number of entries with a button at the bottom that takes users to pulse with the same query. Ideally the pulse component on wagtail will give you a few options to select what query you want to pull entries with.

Future discussion point: Allow pulse to conditionally show UI to take you back to the foundation site based on a "referrer" query param.

[xmatthewx]

Hmmm... @alanmoo suggests we discuss this in our retro.

cc @taisdesouzalessa