-
Notifications
You must be signed in to change notification settings - Fork 54
Add program card component to radio-schedule #2938
Conversation
Signed-off-by: Einstein <[email protected]>
Signed-off-by: Einstein <[email protected]>
Signed-off-by: Einstein <[email protected]>
Signed-off-by: Einstein <[email protected]>
Signed-off-by: Einstein <[email protected]>
Signed-off-by: Einstein <[email protected]>
Signed-off-by: Einstein <[email protected]>
…radio-schedules-component' of github.com:bbc/psammead into create-radio-schedules-component � Conflicts: � package.json
Signed-off-by: Einstein <[email protected]>
Signed-off-by: Einstein <[email protected]>
Signed-off-by: Einstein <[email protected]>
Signed-off-by: Einstein <[email protected]>
Signed-off-by: Einstein <[email protected]>
packages/components/psammead-radio-schedule/src/ProgramCard/index.jsx
Outdated
Show resolved
Hide resolved
Signed-off-by: Einstein <[email protected]>
packages/components/psammead-radio-schedule/src/ProgramCard/__snapshots__/index.test.jsx.snap
Outdated
Show resolved
Hide resolved
Signed-off-by: Einstein <[email protected]>
81e3ad9
to
bf8b40c
Compare
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 => |
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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'.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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’.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
Signed-off-by: Einstein <[email protected]>
> | ||
{`${stateLabel.toUpperCase()}`} | ||
</LabelWrapper> | ||
<VisuallyHiddenText {...hiddenTextProps}> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-Authored-By: Tom Williams <[email protected]>
Signed-off-by: Einstein <[email protected]>
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 thepsammead-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
.Screenshots
![Screen Shot 2020-01-21 at 9 34 16 AM](https://user-images.githubusercontent.com/21374761/72780993-452f1900-3c31-11ea-8327-cdc85cb5b3e0.png)
live
onDemand
![Screen Shot 2020-01-21 at 9 34 03 AM](https://user-images.githubusercontent.com/21374761/72780996-45c7af80-3c31-11ea-8e6d-e09e9546ddc4.png)
Next
![Screen Shot 2020-01-21 at 9 33 53 AM](https://user-images.githubusercontent.com/21374761/72780999-45c7af80-3c31-11ea-9bf6-4510eaf3803a.png)