Kuwait Theme: Progress Wheel Component

[FaithDaka]

PR Checklist

• PR title descriptive (can be used in release notes)

Description

plh_progress_wheel created and styled. Corresponding debug sheet: Link

Author Notes

task_progress_bar component with the following additionalparameter_list:

• wheel_title: The title attached at the bottom of the progress wheel.
• variant: Choose either a bar or wheel to track progress. Default is bar

Git Issues

Closes #2538

Screenshots

Design	Updated Style

[esmeetewinkel]

Looking great! I was wondering if it would make sense to add the gradient design that's in the Mexico app in this PR too, or that that will be a follow-up PR (I don't mind either way).

[FaithDaka]

@esmeetewinkel I think that can be done in a separate styling file for the facilitator app. That seems to be the styling architecture we are using.

[jfmcquade]

This looks really nice, and the logic is nice and straightforward.

Currently, you've exposed the task_total and task_progress parameters to set the completion percentage of the component. This would mean that an author would have to add their own logic for evaluating which tasks have been completed and pass that to the component. Instead, the component should be able to take two parameters and calculate the completion percentage itself:

1. data_list – the name of a data list containing rows that relate to tasks that can be completed
2. completed_column – the name of the column within that data list that stores the completed status of the task row

From these values, the component can then look up the data list with that name, look at the completed column and compare the total number of tasks to the number that have been completed to calculate the total progress itself.

For this reason, I think it would make sense for this component to be a variant of the existing task-progress-bar component, which already contains this logic. The task-progress-bar component does contain some other logic to support a legacy system for handling tasks, but that can be ignored.

In order to implement this wheel as a variant of the task-progress-bar component, you'll need to do the following:

• Configure the task-progress-bar component to have variants, e.g. bar and wheel, where bar is default.
  • src/app/shared/components/template/components/audio/audio.component.ts could be a good example of how to implement variants with a default
  • Likewise, the audio.component.html template can be used as an example – you'll want to wrap most of the existing template code of task-progress-bar.component.html in an @if(params.variant.includes("bar")) block, and add your code from progress-wheel.component.html in another @if() block underneath.
• Move most of your component logic into task-progress-bar.component.ts and refactor to use the existing properties
  • i.e. subtasksCompleted and subtasksTotal can be used to calculate the completion percentage in your getStrokeOffset() method

[FaithDaka]

Thanks @jfmcquade
The changes have been made and PR description updated.

[jfmcquade]

Thanks for refactoring, I think the logic fits in pretty well to the task progress bar component. I really like the animation when updating the progress on the debug template.

I have a couple of further comments (plus some minor suggestions inline):

1. I think that the component styles should be moved to src/app/shared/components/template/components/task-progress-bar/task-progress-bar.component.scss, out of the theme-level overrides (this will also allow you to merge master in without merge conflicts). It's a grey area, but I think it makes sense to expose that variant to other deployments, even though the styling is quite theme-specific for now.
2. On initial load, the component shows briefly with "10000%" completion and the animation glitches. I think you'll need to add a timeout to only display the progress once it has been calculated. See demo:

progress.wheel.glitch.mov

[jfmcquade]

Could be good to add a comment above these three properties to indicate that they relate to the "wheel" variant

[jfmcquade]

Again, would be good to have a comment here (JSDoc style) to indicate that this method relates to the "wheel" variant. It should also be explicitly tagged as public.

[FaithDaka]

Thanks for refactoring, I think the logic fits in pretty well to the task progress bar component. I really like the animation when updating the progress on the debug template.

I have a couple of further comments (plus some minor suggestions inline):

1. I think that the component styles should be moved to src/app/shared/components/template/components/task-progress-bar/task-progress-bar.component.scss, out of the theme-level overrides (this will also allow you to merge master in without merge conflicts). It's a grey area, but I think it makes sense to expose that variant to other deployments, even though the styling is quite theme-specific for now.
2. On initial load, the component shows briefly with "10000%" completion and the animation glitches. I think you'll need to add a timeout to only display the progress once it has been calculated. See demo:

progress.wheel.glitch.mov

@jfmcquade
I've transferred the wheel styling to the component scss file and it will use an ion-secondary colour so that the colour changes per theme, otherwise everything else is specific to the Kuwait theme.

For the glitching, I've added the getStrokeOffset method to the ngOnInit and made 0 the default value while the percentage gets calculated. Let me know if the way it works now makes sense. The timeout function wasn't effective on my end.