US-GHG-Center / veda-config-ghg

Veda config for GHG
https://ghg-demo.netlify.app
Other
3 stars 14 forks source link

Improve announcements feature #288

Open j08lue opened 4 months ago

j08lue commented 4 months ago

We have recently added a feature for temporary announcements in the form of a narrow banner that overlays part of the page

image

The need for us to display these kinds of announcements will continue: we want to use the website as part of the comms/outreach for GHG Center related events.

But the form has some issues - the banner currently overlays part of the header, including the logo - so it could use a revision. It does not necessarily have to be a banner either. Maybe there is a different way to inform users about (outreach/engagement) events?

Acceptance criteria

slesaad commented 4 months ago

CSDA has a banner feature for its website and @alukach gave me a detailed overview of how it works. We can probably take inspiration from that.

Here’s what we’re doing: we have a Django app called banners: https://github.com/NASA-IMPACT/csdap_data_authorization/tree/staging/banners Here’s the model for the data: https://github.com/NASA-IMPACT/csdap_data_authorization/blob/staging/banners/models.py#L13-L61 We ran with the following fields:

  • id: unique identifier for banner
  • level: severity of message, controls how the banner will be styled
  • heading: text header for the banner
  • body: markdown text field for banner content
  • can_close: allows the user to control whether they can close the banner
  • starts_at, ends_at: when the banner should be active. this is nice for scheduling banners

An API serves the JSON-serialized versions of the models to the frontend.

Our frontend (React + NextJS app) has a banners component: https://github.com/NASA-IMPACT/csdap-frontend/blob/develop/components/banners.tsx That component is rendered at the root of our app (ie available on all views): https://github.com/NASA-IMPACT/csdap-frontend/blob/develop/components/common/app.js#L40

When the component renders for the first time, it queries the banners API for all banners. The only particularly unique thing is that we want to allow a user to close banners. The key thing about the closing of banners is that you don’t want them to reappear next time the user opens the app. So what we do is configure the frontend to write a cookie with an array of IDs of the banner that have been closed. When the frontend sends requests to the API, it includes that cookie and the backend uses those IDs in the DB query to exclude those records from the results. The cookie is nice because it allows other apps that also render the same banners to share state about what has been seen (ie I close a banner in app A and open app B, I won’t see the closed banner). Sharing a cookie between services is easy for us because all of our apps run on the same origin (csdap.earthdata.nasa.gov). If you are hosting your services cross origin, it may be easier to just have the frontend include the excluded banners as query parameters being that you only have one app to render the banners.

Recorded demo video: https://www.loom.com/share/2b06c0947df143f18d10a2ccf2ea472e

j08lue commented 4 months ago

Nice overview! 🤩 The functionality of this feature looks great:

  1. Different severity levels of banners (info, warning, alert)
  2. Accessible admin interface for adding/changing banners
  3. Scheduled banners
  4. Cross-site banners and even user view state tracking

We'll have to see which of these are high priority for our app. Since VEDA UI does not run on Django, we cannot copy much of this solution except some of the design choices, if applicable.