Broadcast component changes

[digitalsadhu]

@martin-storsletten and I have been discussing various aspects of the broadcast component with regards to design, usability and implementation. We think this warrants wider discussion.

Goals

We feel that we should initially try to nail down the following 2 things

1. Clear definition of what a broadcast is
2. Clear set of guidelines as to how a broadcast should be used

Implementation

Implementation Questions

Once we nail down the goals, it should be much easier to answer a number of the following questions around how the broadcast should be implemented

• For UU reasons, the Broadcast must be placed immediately after the topbar and immediately before the main page content

  • Should it visually appear where placed or should appear somewhere else such as fixed to the bottom of the screen?

• Should the broadcast be dismiss/collapsible?

  • If so, what happens when you dismiss? can you get it back?

• Can the broadcast be included as part of the topbar?

  • Should the broadcast always be included in every page on Finn or is it limited to only some pages

• Should it be possible to have links in the broadcast?

Implementation Notes

We believe, based on discussions so far, that the following are correct

• Broadcast should be decoupled from toast completely and should not use toast mechanisms
• Broadcast must be placed after topbar and before page content

Further Ideas

• One possibility we discussed is that the broadcast could, rather than dismissible, be collapsible. This would enable the user to remove the broadcast from their immediate attention while enabling them to get it back if needed.

[adidick]

I see now that I haven't even included "Broadcast" in the Fabric documentation. We have some info in the old FINNivers documentation that I should just paste over for now and tidy up later. https://schibsted.frontify.com/d/oCLrx0cypXJM/design-system#/components/broadcast

[adidick]

Guidelines from FINNivers: "Only use when these critical errors occur, and they seems to last more than 5-10 minutes:

• Can't send messages
• Can't log in
• Can't create ad
• Can't pay

They should be located on as specific pages as possible, not the front page!

For other errors, we can inform users in the chat, help center or on the phone.

Design & Interaction Broadcast messages appears without any action from the user. The containers should have the colour "Banana" and associated text. They appear under the banners and pushes the other content down. It scrolls with the content. They should contain a dismiss button."

[digitalsadhu]

Interesting, according to that, the use cases are very restricted. I wonder if this is actually how broadcasts are used in practice today?

[digitalsadhu]

Notes from meeting

(Meeting was with members from Communication team, customer support, UX/UI and FWP)

1. Current info from Finniverse is basically on target (except as noted in the point below)
2. Scope of where broadcast is used is slightly wider than what is defined in Finniverse. eg. scam warnings
3. Links can be used but look terrible on apps (might need to get the apps team to look at this)
4. Dismissible/closable. This is needed but needs to take into account how to get it back once removed/dismissed
5. Multiple broadcasts on a page at once. This is rare but does happen. Currently this looks pretty bad.

@adidick thoughts about how we move forward from here? Feels like we need to nail UX/UI design stuff in a couple cases such as dismissible/collapsible and multiple broadcasts at once... yea?

[adidick]

I think defining a basic broadcast (without links or extra interactivity) is the first step:

Step one

• when/where to use them
• how we can standardise text or tone of voice used in them (can we make a bunch of examples that could be reused?)
• Nail the placement and accessibility in terms of keyboard navigation and screen readers
• Include a "dismiss" X

I can try and take this to design critique tomorrow afternoon to get some input.

Interactivity could be the second (much larger) step:

Step two

• What types of interactions could/should we have (link, close, expand, collapse, etc)
• some kind of place to "house" the messages, so they can be read agin
• Some guidelines as to where links would lead the user (new tab, external site, etc)

[digitalsadhu]

That sounds really good. 👍

[digitalsadhu]

@martin-storsletten I'm going to go ahead with the technical side of what @adidick describes as "step one" in his comment above. That is:

• Complete the separation of the broadcast from the toast and optimise it for placement below the header/banner and above the main content and appears inline, scrolling with the content.
• For now, dismiss button will only dismiss the broadcast until a page refresh
• Work with you to ensure that the broadcast is accessible in so far as it can be given the limited scope of "step one"

Does that sound ok?

[martin-storsletten]

Yeah, from an accessibility point of view, it sounds good. The important part there is the placement of broadcast between topbar and main, then I'm sure we'll figure out the rest of implementation stuff from there.

From an UX point of view, I still believe that a collapsable broadcast is better than dismissable, because:

1. The presence of collapsed broadcast makes it easy to see that the error/warning/issue is still pending resolution, without the entire message being an obstacle.
2. Easy and intuitive to expand the broadcast to see it again, without having to visit a dedicated status page or something.