[Feature Request]: Redesign the lesson player

[seanlip]

Is your feature request related to a problem? Please describe.

The aim of this project is to redesign the lesson player based on feedback we have received from users. We want to make it intuitive to navigate, easy to add features to in the future, and more engaging for younger audiences.

All features of the lesson player must work well on mobile, desktop and tablet device sizes, and all features should work in all languages (including both RTL and LTR languages).

See https://docs.google.com/document/u/1/d/1922aE9_TEFTbHyA3jrXy9cTxo2JgvjfEvKHlxqxG-Rw/edit for a mini-PRD.

Describe the solution (or solutions) you'd like

The lesson player should be redesigned according to these mocks (see the columns on the right half of the Figma file): https://www.figma.com/file/YWe7SqfUVjxlJLKTUn0UZa/Project-2?type=design&node-id=7076-365949&mode=design&t=v3mhfxAkI0l9V53z-0 . It should work fully on mobile and desktop.

From a technical standpoint, this is a large project. I suggest that we gate this behind a feature flag and develop the feature behind the /lesson URL (which can, for now, redirect to the same backend handlers as /explore). The order of development could probably follow the order of the mocks:

• Overall skeleton layout
• Add cards and answer fields within it, with hints/feedback
• Add voiceover bar
• Handle side buttons
• Add checkpoints
• Add next steps at end of lesson

Note that the new UI must work fully on desktop and mobile before it can be launched.

Describe alternatives you've considered and rejected

N/A

Additional context

This is filed based on the design issue here: oppia/design-team#58

[seanlip]

Also /cc @juliafalarini, the designer for this project, who can answer questions if needed.

[akshayw1]

I would like to work on this!Please assign

[yash1378]

@seanlip sir is this issue still opwn to work on ?

[seanlip]

@yash1378, please do not comment on a whole bunch of issues with the same question. This creates a lot of unnecessary email noise.

We have guidelines at https://github.com/oppia/oppia/wiki/Contributing-code-to-Oppia#choosing-a-good-first-issue for new contributors. Please read that page carefully and follow those instructions. It provides info on what issues to pick and the steps you need to take to claim them.

For this issue, I recommend that you do not take it as a first issue. It is large and not straightforward, and I recommend that you consider picking something smaller instead to start with. Thanks.

[yash1378]

@seanlip so sorry sir i will take of that and in future will not make unnecessary comments

[Vir-8]

@seanlip Hey, while this is pretty huge, I'd love to work on it if possible!

I checked out the Figma designs thoroughly, we'd have to refactor a lot in the exploration-player-page directory, mainly -

• Have the chapter name at the top with an exit ('X') button to the far right
• Redesign the audio-bar component
• Move the progress bar from lesson-info, 'previous', and 'continue' buttons to the footer
• Move hints and solution popups from footer to be in the main exploration player, as a part of the conversation
• Create an expandable sidebar component that has the lesson name and rating, and have the help, feedback, share and report buttons moved there
• Create following dialog boxes -
  • "Help" dialog box having options for lesson information and restarting the tutorial
  • "Save Progress" dialog box as seen in the design
  • "Exit" dialog box with an option to save before exiting
• Implement following tooltips -
  • View the lesson here
  • Listen to this lesson
  • Move forward
  • Reached a checkpoint
  • Click to enter answer
  • Explore menu options
  • Restart tutorial
• Add next steps at the end of lesson where the user can rate the lesson and have options of where to go next, depending on the user, as seen in the design

Order of approach -

1. Change current layout, adding the sidebar component and moving components where they should be
2. Make the sidebar component's frontend including buttons and make it expandable
3. Make the footer's frontend, that includes the previous, continue, save buttons and the progress bar
4. Make the audio bar's frontend
5. Make the dialog boxes for the sidebar buttons and exit button
6. Move hints and solutions to the conversation
7. Add next steps
8. Add tooltips

Let me know if I'm missing something! Only things I'm not 100% sure about are the tooltips and the next steps. Would really appreciate any advice or suggestions. Thanks!

[seanlip]

Hi @Vir-8, thanks for the notes! Normally I am a bit reluctant to assign a larger project like this to newer folks, but I think your recent PRs have been great so I'd be happy with you taking it up :)

Some notes:

• For implementation let's gate behind a new feature flag, something like NEW_LESSON_PAGE, because we still need to deploy releases while this project is in progress. Users should not see any change in functionality until that flag is turned on. Please read the guidance here in detail: https://github.com/oppia/oppia/wiki/Launching-new-features#how-do-you-as-a-developer-use-feature-flags
• We need to keep things organized so that we don't mix up all the old and new stuff. I think we can reuse the services but we probably want to create new components for the new things. Maybe what you could do is:
  • Reorganize the current core/templates/pages so that stuff that will be reused (like services) is in that folder, and other stuff that won't be reused is in its own subfolder e.g. .../current-lesson-page-components, and all new stuff goes in .../new-lesson-page-components (there should be a README in the latter folder explaining the context and pointing to this issue, we should delete that README after we switch to the new version).
  • Be really careful when modifying services as this would impact both the new and old functionality. On the other hand if you see logic in current component files that should really be in a service, feel free to make a small PR to refactor it accordingly.
  • Make sure nothing depends on stuff in .../new-lesson-page-components.
• It is important that your UI works for both mobile/desktop and also for RTL/LTR languages. Don't leave handling these till the end, develop them properly as you go.

I think your overall order of tackling things seems good. I suggest making separate small PRs rather than a huge one, it'll be easier to review.

I'm not sure what your concern/question is about the tooltips and next steps. Could you clarify the specific question you have, please?

In any case, I'll assign you to this issue -- I suggest that you break it down into milestones and list them here with a planned due date for each. Then we can use that as a basis for planning.

Thanks, and feel free to ask if you have further questions!

[Vir-8]

Hey @seanlip, thank you so much for the response, means a lot! It's amazing to have this opportunity, I really appreciate your advice. I'll be coming up with a timeline soon, I don't have any concerns regarding next steps now but regarding tooltips - I'm not quite sure how to integrate them into the player, would you be aware of any PR that could serve as a reference? Thanks again!

[seanlip]

@Vir-8 Not sure, will need some investigation. Try to do it in a generic way though -- e.g. make a common component and reuse it.

[Vir-8]

@seanlip Here are some tentative target dates by which the corresponding step should be completed, certainly don't want to underestimate how long it would take, please take a look

20 Jan - Make the sidebar component and move components according to the new layout

(Will be travelling from 21st-28th)

2 Feb - Have the sidebar component ready, and make the layout responsive
6 Feb - Rework the footer component, having a functional progress bar and previous, continue and save buttons
10 Feb - Rework the audio component (assuming we are adding the speed functionality currently absent)
16 Feb - Make the modals/dialog boxes for the sidebar buttons and the exit button
20 Feb - Rework hints and solutions
24 Feb - Add next steps
28 Feb - Add tooltips

Hope this seems OK, don't want to rush it but not sure if this is a lot of time, kindly let me know if you have any feedback or suggestions

[seanlip]

Hi @Vir-8 -- this looks roughly fine. Thanks! Look forward to seeing your first PR.

[Vir-8]

@seanlip Just confirming, I'd have to make a PR introducing the feature flag and whatever changes there may be first, and after it gets merged, I will be making following PRs from the same branch?

[seanlip]

The first part is correct, but you should generally make subsequent changes by checking out a new branch from the develop branch after the first PR is merged, so that you get others' changes in as well.

[Vir-8]

Hey @seanlip, I have the second PR ready with the routing changes and a rough layout, but I am repeatedly facing this unusual error trying to push the changes, it says linter checks failed but doesn't say what the linting issues are... Already fixed a bunch of linting issues and then this started happening. Any suggestions?

[seanlip]

@Vir-8 Can't help you on this one, sorry, I'm a bit overloaded atm. My advice is to look at the stacktrace and the line in question -- start from the error message. If you need to log any info to get more clarity then go ahead and do that. But it looks like these problems are valid and need to be fixed.

[prafulbbandre]

Hi @Vir-8 ,
Can you please provide the expected date of opening a the next Pr for this issue.

[Vir-8]

@prafulbbandre Mostly by 30th, I am unavailable this week

[Vir-8]

Hey @seanlip, shall I wait for previous PRs to be accepted before making new ones or how should I go about it? Since new PRs would include changes from previous PRs that haven't been merged yet

[seanlip]

@Vir-8 OK to make new PRs that are checked-out from the branch you're working on. Just merge the "closer to develop" branch into that branch (and develop to the branch once the older PR is merged) every so often so it doesn't fall out of date.

That said, dealing with chains of PRs is more complex. So, feel free to also ping reviewers and ask them to expedite review if possible; make sure to explain that you have other PRs that are blocked on this one.

[Vir-8]

Hey @seanlip, were the TS tests changed recently or something? I've been trying to make the next PR but I fail a large amount of typescript checks for completely unrelated code that I haven't touched at all, like Element implicitly has an 'any' type because expression of type 'number' can't be used to index type 'string | Object'. for example. Not sure if it's an issue on my end when I haven't changed anything, but couldn't find anything helpful...

[seanlip]

Hi @Vir-8 -- sorry, I don't know offhand, but I do know something that might be related. IIRC there is a bug where, if you have made a particular TS typing error, all the existing errors in the codebase get printed out. So fixing the error you introduced might fix this.

I think this is because the "exclude files" logic in the TS script is behaving incorrectly but this hasn't been fixed yet. See #17236