Skip to content
This repository has been archived by the owner on Aug 13, 2023. It is now read-only.

Add program card component to radio-schedule #2938

Merged
merged 76 commits into from
Jan 30, 2020

Conversation

EinsteinNjoroge
Copy link
Contributor

@EinsteinNjoroge EinsteinNjoroge commented Jan 15, 2020

Resolves #2924

Overall change: The radio schedule pages are designed to show program-cards with the different states, brand titles, episode titles, summary, and duration. This PR adds and exports a ProgramCard component from the psammead-radio-schedule package. You can find the chromatic storybook builds here.

Code changes:
in this approach, we have created an entirely new component that does not extend psammead-bulletin.

  • Create and export the program card component.
  • Add snapshot tests and storybook stories.

Screenshots
live
Screen Shot 2020-01-21 at 9 34 16 AM

onDemand
Screen Shot 2020-01-21 at 9 34 03 AM

Next
Screen Shot 2020-01-21 at 9 33 53 AM


  • I have assigned myself to this PR and the corresponding issues
  • Automated jest tests added (for new features) or updated (for existing features)
  • This PR requires manual testing

@EinsteinNjoroge EinsteinNjoroge self-assigned this Jan 15, 2020
@EinsteinNjoroge EinsteinNjoroge added radio-schedules ws-home Tasks for the WS Home Team labels Jan 15, 2020
@EinsteinNjoroge EinsteinNjoroge changed the title Create radio schedule package Create program card component Jan 16, 2020
Signed-off-by: Einstein <[email protected]>
@itimirichard itimirichard self-assigned this Jan 17, 2020
@EinsteinNjoroge EinsteinNjoroge force-pushed the create-radio-schedules-component branch from 81e3ad9 to bf8b40c Compare January 28, 2020 17:52
@tochwill
Copy link
Contributor

I'm going to pull this back into code review quickly and we can discuss the UX review process with alpha components in refinement!

},
};

const sentenceCase = text =>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this just used to capitalise the duration label? Would we be able to just pass in the translation string like this, we do that elsewhere :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah it's also used below for the live label text. We have to do exactly the same in the TV and Radio bulletin I believe? Can we follow the same approach in both places?

Copy link
Contributor Author

@EinsteinNjoroge EinsteinNjoroge Jan 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tochwill we're using this on the state label as well as the duration label. If the state is live, we need to display localised LIVE and have Live as a hidden text on the card. The Radio bulletin has a hardcoded hidden-text Live regardless of the service.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the requirement should be the same for both - if we're hardcoding Live for all cases on the Bulletin and have the requirement to only do that if the translation is 'Live' for the radio schedule, we should check that this should be the case, I imagine they should be consistent. At the moment it looks like we're always displaying 'LIVE' as the visible text for the bulletin component too.

Let's check the following for bulletin and radio schedules are true:

Scenario 1 (LTR services):

  • Show a visible 'LIVE' label in english
  • Show visually hidden text with 'Live' read in an english accent

Scenario 2 (RTL services):

  • Show a visible live label, in capitals, in the service language.
  • Show visually hidden text with the translation of live read in the service language.

This is what I understood, but as you point out, currently in Simorgh we never pass a live label translation for bulletins even in RTL languages, so it defaults to 'LIVE', and the visually hidden text is hardcoded as 'Live'.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stupid question, but do our right to left scripts contain capital letters? I don't think arabic does?

Copy link
Contributor

@greenc05 greenc05 Jan 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Show visually hidden text with the translation of live read in the service language." - this is not required for services that do not have 'live' in english. Though note, in this case the diplayed 'LIVE' (translated) could not have aria-hidden on it...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just had a conversation with Catharine:

  • We only need visually hidden text for ‘Live’ in English as a hack to stop screen readers reading out ‘live’ incorrectly, we don’t need it for other languages.
  • We don’t want to read out ‘Live’ in English when we are using a different language, so it looks like the bulletin component is currently incorrect. We have no RTL languages using this component yet, so this won’t have impacted anyone.
  • We can pass in translation strings as ‘Live’ and ‘Duration’, not need the sentenceCase function, and use CSS (or toUpperCase as you are) to display the make it ‘LIVE’.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another question, can we pass the translation of 'Live' in all cases in this format, and use text-transform: uppercase in the styles for the visible live label?

This will cause UX and accessibility issues in no-CSS browsers

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm gonna move that function to a helper and use it in tests and stories

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you not just pass the translations strings in sentence case? You could still use toUpperCase for the visible label

packages/components/psammead-radio-schedule/README.md Outdated Show resolved Hide resolved
>
{`${stateLabel.toUpperCase()}`}
</LabelWrapper>
<VisuallyHiddenText {...hiddenTextProps}>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is good to merge into the alpha as long as we raise tickets to:

  • Create the timestamp correctly, using the same timestamp that is used in the start time indicator (will be easier to do when they're both merged in)
  • Get requirements for duration formatting and refactor that in here based on what they are
  • Make sure the visually hidden live label has the same logic in here, story promos, bulletins (and anywhere else it will be used). We can merge it in as is to the alpha and then pull it out and share it across each?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@EinsteinNjoroge EinsteinNjoroge merged commit 6cde596 into latest Jan 30, 2020
@sareh sareh deleted the create-radio-schedules-component branch February 21, 2020 12:30
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
radio-schedules ws-home Tasks for the WS Home Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Radio Schedules: Generalise Bulletin component to allow for programme card designs
9 participants